IK-EØS 001-2026 Kolonialvarer til produksjonskjøkken i Bergen kommune og samarbeidsparter

Bilag 8 «Krav til elektronisk samhandling» regulerer gjennomføring av elektronisk samhandling mellom Bergen kommune og leverandør, inkludert obligatorisk elektronisk bestilling via angitte bestillingsalternativer (katalog og Punch Out), samt krav til meldingsutveksling (EHF/PEPPOL), implementering/oppdatering av elektroniske kataloger og prosesser for ordre, ordrebekreftelse og varemottak (pakkseddel).

• Leverandør skal sende versjon 1 av elektronisk katalog til godkjenning minst 3 uker før avtalestart (katalog, dersom katalog er angitt som bestillingsløsning).Kilde: Punkt 3.1 «Oppstart og frister»
• Leverandør skal ha katalog klar til bruk minimum 1 uke før avtalestart.Kilde: Punkt 3.1 «Oppstart og frister»
• Leverandør skal sende oppdatering av katalog ved avtalt endring av sortiment innen maksimum 1 uke etter avtalt endring.Kilde: Punkt 3.1 «Oppstart og frister»
• Leverandør skal sende oppdatering av katalog etter avtalt prisregulering innen maksimum 1 uke før iverksettelse av prisjustering (pris kan først gjøres gjeldende etter at oppdatert katalog er godkjent).Kilde: Punkt 3.1 «Oppstart og frister»
• Leverandør skal sende EHF grunnlinjekatalog til Bergen kommunes aksesspunkt før kontraktens oppstart når Punch Out er brukt.Kilde: Punkt 1.2 (grunnlinjekatalog ved Punch Out) og punkt 4.4 «Grunnlinjekatalog»
• Leverandør skal sende oppdatert grunnlinjekatalog med avtalte produkter/tjenester og priser med oppdateringsintervall spesifisert som 6 måneder.Kilde: Punkt 4.4 «Grunnlinjekatalog»
• Før kontraktsoppstart: leverandør skal oversende teknisk informasjon (URL med passord (SMS)) tre uker før kontraktens oppstartsdato og få Punch Out oppsett godkjent (test) to uker før oppstart (gjelder Punch Out).Kilde: Punkt 4.3 «Oppstart og frister»
• EHF grunnlinjekatalog mottatt via aksesspunkt en uke før kontraktens oppstartsdato (gjelder Punch Out).Kilde: Punkt 4.3 «Oppstart og frister»

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

31.08.2026

Språk

norsk, English

Elektronisk katalog

Obligatorisk

• Elektronisk bestilling er obligatorisk for alle enheter i Bergen kommune og for tilsluttede samarbeidsparter som har e-handel; leverandøren skal ikke motta bestillinger via telefon, e-post, i butikk eller andre kanaler (unntak kun avtalt på forhånd med kontraktsforvalter).Kilde: Punkt 1.1 «Innledning»
• Leverandør skal sikre at underleverandør/tredjepart knyttede tekniske/økonomiske/bestillingsløsninger oppfyller kravene i avtalen.Kilde: Punkt 1.1 «Innledning»
• Dersom leverandør forårsaker at det ikke er mulig å gjennomføre elektronisk samhandling i en periode på 14 kalenderdager uten forhåndsavtale, regnes dette som kontraktsbrudd.Kilde: Punkt 1.1 «Innledning»
• All meldingsutveksling skal skje via EHF transportinfrastruktur (PEPPOL) i henhold til avtalte formater, og leveres til adresse angitt i PEPPOL SML (med mindre alternativt format er avtalt).Kilde: Punkt 2 «Meldingsutveksling»
• EHF-katalog og EHF Punch Out/EHF-ordre (standard ordreformat) er angitt som valgte prosesser; alternative formater: OCI kan benyttes inntil leverandør har støtte for EHF Punch Out; e-post ordre kan aksepteres i en begrenset periode på 12 måneder fra oppstart (krav til standard e-postadresse).Kilde: Punkt 2.1 og 2.2
• Krav til katalogfeltkvalitet for alle katalogoppdateringer: Produktnavn 100%, Produktbeskrivelse 100%, Bilde 99%, Kategorisering (UNSPSC) 100%, Nøkkelord 99%, Leverandørens artikkelnummer 100%, Produsentnavn/artikkelnummer 99%, Vedlegg ved relevante produkter 100%, sertifisering/miljømerker kodet 99%.Kilde: Punkt 3.2 «Krav til kvalitet i visse katalogfelt»
• Kataloginnhold skal inkludere angitte felt (ikke uttømmende), bl.a. KatalogID, Katalognavn, språk (NO), aksjonskode (Add/Replace), gyldighetsdatoer, kontraktsnummer, organisasjonsidentifikasjon, priser/valuta (NOK), leverandørens artikkelnummer, UNSPSC (versjon 18 nivå 4), produktinformasjon, HMS/merking for farlig gods/risikoprodukter og øvrige oppgitte feltkrav.Kilde: Punkt 3.3 «Kataloginnhold»
• Ved farlig gods/risikoprodukter skal HMS-datablad lenkes opp eller vedlegges katalogen som dokument; andre vedlegg (f.eks. bruksanvisninger) skal lenkes opp eller vedlegges dersom kontraktsfestet.Kilde: Punkt 3.2 (**) og punkt 3.2 (beskrivelse av HMS-datablad) / punkt 3.3 (HMS datablad)
• Punch Out-løsning: Kun avtalt sortiment og avtalepriser skal vises; søk skal ha indeksert fritekst med nøkkelord/synonymer; filtrering i kategorier/underkategorier og for merkeordninger knyttet til miljø/sosialt ansvar; handlekurvfunksjon (opprette og lagre).Kilde: Punkt 4.1 «Krav til kvalitet i leverandørens nettbutikk/løsning»
• Punch Out-løsning produktvisning skal inneholde: produktnavn, produktbeskrivelse, bilde, leverandørens artikkelnummer, produsentens navn, (lenker ved relevant), HMS-lenke for farlig gods/risiko, merking av sertifisering/merkeordninger og egenskapsvalg (nedtrekksliste e.l.).Kilde: Punkt 4.1 «Krav til kvalitet i produktvisning»
• Punch Out tekniske krav: enhetsbetegnelser iht. Bergen kommunes enhetsbetegnelser; SSO automatisk pålogging fra Bergen kommunes bestillingsløsning; bruk av UNSPSC koder på lavest mulig nivå (fortrinnsvis nivå 4); leverandør skal kontinuerlig arbeide for å rette feil ved nedetid; tilrettelegging for at kontraktsnummer returneres i overføringen (EHF/OCI tilleggsfelter).Kilde: Punkt 4.2 «Tekniske krav»
• Oppstart og tidslinje for Punch Out/testing/levering av grunnlinjekatalog samt godkjenning før oppstart er kontraktsstyrende (URL/ passord, test av Punch Out og EHF-ordre, mottak av grunnlinjekatalog på aksesspunkt).Kilde: Punkt 4.3 «Oppstart og frister»
• Grunnlinjekatalog brukes til analyse- og kontraktoppfølgingsformål og skal speile avtalens produkter/tjenester og priser; skal sendes før kontraktens oppstart og deretter oppdateres iht. intervall.Kilde: Punkt 4.4 «Grunnlinjekatalog»
• For bestilling/ordre/ordrebekreftelse/pakkseddel skal meldingsutveksling og informasjonsinnhold følge EHF-spesifikasjon og PEPPOL-registrering (med mindre annet er avtalt).Kilde: Punkt 5 «Andre forutsetninger»
• Leverandør kan benytte bekreftelser med status «Akseptert med endring» for angitte endringstyper (bl.a. endret leveringsdato, kvantumsreduksjon, erstatningsprodukt, endret pris under spesifikke forutsetninger, splitting av leveransen/restordre m.fl.).Kilde: Punkt 5.2
• Kjøpers håndtering av «Akseptert med endring»: et av avtalte prinsipper skal gjelde (i teksten er «Stilltiende aksept»/«Kansellering og ny bestilling»/«Endringsordre» listet; stilltiende aksept angir at kjøper anses å ha akseptert med mindre kjøper gir respons innen «XX dager» (ingen verdi spesifisert i teksten), og «Endringsordre» krever aksept/avvisning innen 3 dager).Kilde: Punkt 5.3

• Dokumentteksten gjengir ikke verdi for «XX dager» i prinsippet «Stilltiende aksept» (punkt 5.3).
• Dokumentet viser at frister knyttet til EHF-faktura/testing er omtalt, men selve EHF-faktura-detaljene er ikke spesifisert utover at implementeringen omfatter EHF-faktura (punkt 1.1).
• Kravene for punkt 5.1 «Presisering av informasjonsinnhold ved bestilling» er ikke utfylt i den gjengitte teksten (kun overskrift).
• Flere feltkrav i kataloginnholdstabellen er gjengitt delvis/uklart kuttet (f.eks. «Volumpris / minstekvantum» linjebrudd).

Punkter der konkurransedokumentene åpner for tolkning, og der en presisering fra oppdragsgiver kan ha betydning for prising og risiko. Spørsmål kan stilles innen fristene som er angitt i konkurransegrunnlaget.

1. I punkt 5.1 «Presisering av informasjonsinnhold ved bestilling» står det en overskrift, men det er ikke oppgitt hvilke konkrete datofelt/tilpasninger som kreves. Kan dere beskrive nøyaktig hvilke ekstra presiseringer/krav som skal være tilgjengelige ved bestilling i denne avtalen (inkl. hvilke EHF-felt det gjelder og hva leverandøren skal gjøre/tilrettelegge)?

   Hvorfor det er verdt å spørre: Leverandøren må vite hvilke informasjonskrav som gjelder for å kunne konfigurere integrasjon og katalog/ordrelogikk riktig.

   Kilde: 5.1 Presisering av informasjonsinnhold ved bestilling

2. I punkt 5.3 «Kjøpers håndtering av bekreftelse med endring» er prinsippet «Stilltiende aksept» beskrevet, men parameteren «XX dager» er ikke utfylt. Hva er korrekt antall dager for kjøpers respons (dvs. frist for å gi leverandøren respons innen), og regnes fristen fra mottak hos kjøper eller fra en annen milepæl?

   Hvorfor det er verdt å spørre: Manglende frist kan gi vesentlig risiko for restordre/leveringsansvar og må avklares før implementering og risikoprising.

   Kilde: 5.3 Kjøpers håndtering av bekreftelse med endring

3. I punkt 1.1 «Aksesspunktinformasjon» listes det EHF-tilknytninger for flere kommuner (Bergen + Alver + Bjørnafjorden + Masfjorden + Osterøy + Ullensvang). Kan dere bekrefte om leverandøren skal levere én felles implementasjon mot alle disse (samme tekniske oppsett), og eventuelt hvilke GLN/identifikatorer og eventuelle per-enhet forskjeller som er relevante for: (i) EHF-katalog, (ii) EHF-ordre, (iii) ordrebekreftelse og (iv) pakkseddel?

   Hvorfor det er verdt å spørre: Riktig routing/identifikatorer per virksomhet påvirker teknisk design, testing og drift (særlig ved flere aksesspunkter/organisasjoner).

   Kilde: 1.1 Aksesspunktinformasjon

4. I punkt 2.2 «Alternative meldingsutveksling eller format» står det at leverandøren kan motta ordrer på e-post i en begrenset periode på tolv måneder, og at leverandøren skal oppgi en standard e-postadresse. Kan dere bekrefte: (a) hvordan e-postordrer skal formateres/vedleggstyper (f.eks. PDF/EHF-vedlegg), (b) hvor lenge og fra hvilken dato “oppstart av kontrakt” regnes, og (c) hvordan dere ønsker at leverandøren skal sende ordrebekreftelse ved e-post-ordre (gjelder pkt. om ordrebekreftelse med e-post)?

   Hvorfor det er verdt å spørre: Dette påvirker leverandørens mottaksrutiner og kostnadsbildet for midlertidig prosess (12 måneder).

   Kilde: 2.2 Alternative meldingsutveksling eller format

5. I punkt 2.1 og 4.1 fremgår det at Punch Out er valgt for varer, og at OCI kan benyttes alternativt inntil leverandør har støtte for EHF Punch Out. Kan dere beskrive forventet overgang: Når anser dere at leverandør «har støtte», og må vi bytte fra OCI til EHF Punch Out ved et bestemt tidspunkt/innen en bestemt frist (og i så fall hvilken)?

   Hvorfor det er verdt å spørre: Leverandøren trenger å forstå tidshorisont og endringsplikt for å prise utvikling/oppgradering riktig.

   Kilde: 2.1 Formater i meldingsutvekslingen / 4. Punch Out

6. I punkt 3.1 «Oppstart og frister» stilles frister for katalogversjon 1 (sendes minimum tre uker før avtalestart), godkjenning (maks en uke), og at katalog skal være klar minimum en uke før avtalestart. Kan dere bekrefte hvilken dato som faktisk brukes som “avtalestart” i deres systemgrunnlag, og om det er leverandørens ansvar å rette og re-sende katalog dersom oppdragsgiver ikke rekker godkjenning innen maks en uke?

   Hvorfor det er verdt å spørre: Tydelig startdato og ansvar ved forsinket godkjenning påvirker planlegging, bemanning og risiko for manglende bestillingsberedskap.

   Kilde: 3.1 Oppstart og frister

7. I punkt 3.2 «Krav til kvalitet i visse katalogfelt» opereres det med prosentmål (f.eks. bilde 99 %, nøkkelord 99 %, produsentnavn/artikkelnummer 99 %, og 99 % for sertifiserte produkter). Hvordan skal disse prosentene måles i praksis (tellingsgrunnlag og metode): gjelder det antall varer/andel av linjer, og hvordan håndteres endringer i sortiment/pris i samme periode?

   Hvorfor det er verdt å spørre: Ulike målemetoder gir ulik compliance- og rework-risiko; leverandøren må kunne dokumentere kvaliteten.

   Kilde: 3.2 Krav til kvalitet i visse katalogfelt

8. I punkt 4.2 «Tekniske krav» punkt 5 «Kontraktsnummer på varelinje» står det at det skal legges til rette for at kontraktsnummer blir returnert i overføringen (EHF/OCI). Kan dere angi hvilke felt/tilleggfelter som konkret skal bære kontraktsnummeret (navn/kolonne/tag), og om dette er obligatorisk for begge overføringsmåter (EHF Punch Out og OCI) eller kun for én av dem?

   Hvorfor det er verdt å spørre: Leverandøren må vite nøyaktig datakontrakt for å unngå avvisning/misrouting av linjedata.

   Kilde: 4.2 Tekniske krav / Krav til Punch Out (punkt 5)