14-siffriga GTIN från ICA: samma artikel, ny kod – och varför EDI-ordern kan fastna

Nyligen fick en av våra kunder – en producent av ekologiska livsmedel som levererar till ICA – ett besked: ICA går över till att orderlägga på DFP-nivå (detaljistförpackning) med 14-siffriga GTIN för artiklar som i dag beställs med 13 siffror. I praktiken blir en förpackningskod som 7350012345679 i stället 07350012345679. Masterdatan uppdaterades i Validoo – men skulle EDI-ordrarna fortfarande landa rätt i affärssystemet?

En helt rimlig fråga. För CloudOffice var svaret ”ja, klart samma eftermiddag” – men frågan i sig förtjänar en närmare titt. Det här är precis den typen av liten förändring som i tysthet får orderflöden att stanna i många system.

Vad ICA ändrar – och varför

GS1:s förpackningshierarki har tre nivåer i svensk dagligvaruhandel: konsumentförpackning (KFP), detaljistförpackning (DFP) – den kolli butiken beställer – och pall. Varje nivå kan ha sitt eget GTIN. Historiskt har många leverantörer identifierat kollit med ett eget GTIN-13, eller helt enkelt återanvänt konsumentförpackningens kod. Att orderlägga på DFP-nivå med GTIN-14 gör förpackningsnivån tydlig i själva koden, och det är så GS1 rekommenderar att handelsenheter identifieras. För kedjan innebär det renare masterdata och färre missförstånd om hur många enheter som egentligen beställdes.

Kodens anatomi: 13 eller 14 siffror

Ett GTIN-14 består av en indikatorsiffra, de tolv siffrorna från GTIN-13 utan kontrollsiffra, och en ny kontrollsiffra. Indikatorsiffran talar om vad det är för slags kod:

Två saker följer av detta. En inledande nolla ändrar inte kontrollsiffran – nollan tillför inget i mod 10-beräkningen – så ”0” + GTIN-13 är ett giltigt GTIN-14 som identifierar samma artikel. Men ett GTIN-14 med indikator 1–8 är en annan identitet: den kan inte ”normaliseras” tillbaka till 13 siffror genom att stryka första siffran. Därför rekommenderar GS1 att alla GTIN lagras i ett 14-siffrigt fält, högerjusterat och nollutfyllt, och att 14-siffersformen betraktas som den kanoniska.

Var systemen brister

I EDIFACT-ordern ser orderraden ungefär så här ut: LIN+1++07350012345679:SRV' (äldre profiler använder kvalificeraren EN). Affärssystemet eller EDI-konvertern tar koden och slår upp artikeln. Fyra typiska felkällor:

• Exakt strängjämförelse. Artikelkortet säger 7350012345679, ordern säger 07350012345679. Samma artikel, olika sträng – ingen träff. Orderraden hamnar som ”okänd artikel”, eller i värsta fall avvisas hela ordern med ett fel i ORDRSP.

• Ett enda GTIN-fält per artikel. Många system har ett ensamt ”EAN”-fält på artikelkortet. När ICA vill ha 14 siffror och en annan kedja fortfarande skickar 13 finns det ingenstans att lägga den andra koden – man tvingas välja vem som ska få fel.

• Svaret går tillbaka med fel kod. Även om ordern läses in kan systemet ”normalisera” koden till sitt eget format och skicka 13 siffror i orderbekräftelse (ORDRSP), leveransavisering (DESADV) och faktura (INVOIC) – medan kedjan nu förväntar sig 14. Då fastnar flödet ett steg senare, hos kedjan, och felet är svårare att hitta.

• Hårdkodad mappning i EDI-konvertern. Ibland ligger matchningen utanför affärssystemet, i en konverter eller en mappningstabell hos VAN-operatören som någon annan underhåller. Då betyder ändringen ett supportärende, en ledtid och en faktura – för en nolla.

Observera att inget av detta syns förrän den första 14-siffriga ordern kommer. Masterdatan i Validoo kan vara helt korrekt medan ordern ändå fastnar.

Fem frågor att ställa om ditt eget system

1. Kan samma artikel ha flera GTIN samtidigt – till exempel både den 13- och den 14-siffriga formen av kollits kod?

2. Behandlar uppslagningen 7350012345679 och 07350012345679 som samma kod?

3. Vad händer med en orderrad vars GTIN är okänt: avvisas ordern, parkeras den för granskning, eller skapas den tyst med en tom rad?

4. Svarar systemet – i ORDRSP, DESADV och INVOIC – med exakt den kodform som stod i ordern, eller normaliserar det allt till ett eget format?

5. Vem underhåller mappningen, hur lång tid tar ändringen och vad kostar den?

Om det ärliga svaret på fråga fem är ”ett ärende hos EDI-leverantören och några dagar” är det kedjans deadline som styr er tidplan – inte ni.

Så fungerar det i CloudOffice

I CloudOffice kan en artikel ha flera GTIN samtidigt – till exempel både den 13- och den 14-siffriga formen av samma kollikod – och inkommande EDI-ordrar matchas mot alla. (Olika förpackningsnivåer är däremot olika artiklar: ett kolli och en pall med samma innehåll har var sitt artikelkort och var sitt GTIN, precis som i GS1:s hierarki.)

Det viktiga händer i nästa steg: CloudOffice svarar alltid med den kodform som kedjan själv använde i ordern. Kom ordern med 14 siffror får kedjan 14 siffror tillbaka i orderbekräftelse, leveransavisering och faktura; kom den med 13 får den 13. Levererar ni till flera kedjor och en av dem går över till 14-siffriga GTIN medan de andra stannar på 13, behöver ingen samordna något – var och en får sin egen kod tillbaka, och ni gör inget alls.

För kunden ovan lades de 14-siffriga koderna till på ICA-artiklarna samma eftermiddag. Inget ändrades i orderflödet, prislistorna eller de dokument som följer efter ordern. ICA kan börja skicka de nya koderna när de vill; ordrar med de gamla koderna fungerar under tiden.

Det är samma princip som i hela vår EDI-lösning: kedjans krav ändras, leverantörens vardag ska inte göra det.

Osäker på hur ditt system hanterar 14-siffriga GTIN?

Skicka oss en exempelorder från din kedja – vi visar live hur den läses in i CloudOffice, från order till faktura.

Boka en demo

Företagsuppgifter och referenser lämnas på begäran.