DataMatrix eller hvordan man korrekt markerer sko

Fra 1. juli 2019 trådte en obligatorisk mærkningslov for varegrupper i Rusland i kraft. Fra 1. marts 2020 skulle sko være omfattet af denne lov. Ikke alle nåede at forberede sig, og derfor blev lanceringen flyttet til 1. juli. Lamoda er blandt dem, der nåede det.

Derfor ønsker vi at dele erfaringerne med dem, der endnu kun skal til at mærke tøj, dæk, parfume osv. Artiklen beskriver en række branchestandarder, nogle normative dokumenter og personlige erfaringer. Artiklen er primært beregnet til integratorer og udviklere, der først skal finde ud af dette projekt.

Bemærk venligst, at den normative base ofte ændrer sig, og forfatteren har ikke mulighed for konstant at opdatere materialet. Derfor kan en del af informationen være forældet ved læsningstidspunktet.

Forfatterens personlige erfaring er opnået både i forbindelse med arbejdet med Datamatrix-projektet i Lamoda og ved udviklingen af sin egen gratis applikation til mærkning BarCodesFx.

Fra 1. juli 2019 gælder loven om obligatorisk mærkning i Rusland. Loven gælder ikke for alle varegrupper, og tidsfristerne for obligatorisk mærkning varierer for de forskellige varegrupper. I øjeblikket er tobaksvarer, pelsfrakker, sko og lægemidler omfattet af obligatorisk mærkning. Snart vil det også gælde for dæk, tøj, parfume og cykler. Hver varegruppe reguleres ved en særskilt regeringsbeslutning (PPR). Derfor kan nogle udsagn, der er korrekte for sko, være forkerte for andre varegrupper. Men man kan håbe, at den tekniske komponent ikke vil variere meget mellem de forskellige varegrupper.

MærkningHovedideen med mærkning er, at hver enkelt vare tildeles et unikt nummer. Ved hjælp af dette nummer kan man spore historien om den specifikke vare fra produktionen eller importen til landet, til den forlader kassen. Det lyder godt, men i praksis er det ekstremt svært at implementere. Konceptet er yderligere beskrevet på den officielle hjemmeside for den ærlige mærkning.

Almindeligt accepterede termer og begreber

UOT — en deltager i varehandelen.
CRPT — sentrum for utvikling av fremtidsrettet teknologi. Privat selskap, eneste statlige kontraktør for merkingsprosjektet. Opererer etter modellen for offentlig-privat partnerskap (OPP). Dessverre finnes det ingen informasjon om andre deltakere i anbudet for prosjektet, eller om selve anbudet.
TG — varegruppe. Sko, klær, dekk osv.
GTIN — i bunn og grunn en artikkel med hensyn til farge og størrelse. Utstedt av GS1 eller nasjonal katalog for hver importør eller produsent for deres vare. På forhånd må produsenten eller importøren beskrive denne varen.
PPR — regjeringens forskrift. For sko — 860.
KM — merkekode. En unik kombinasjon av tegn som tildeles en spesifikk vare. For sko består den av GTIN, serienummer, kontrollkode og kryptosvans.
GS1 — internasjonal organisasjon som utsteder GTIN-er. Også ansvarlig for en rekke standarder for merking.
Nasjonal katalog — som GS1, utviklet av CRPT.
Kryptosvans — analog til digital signatur, som bekrefter gyldigheten av KM. Må alltid være i datamatrisen på merket. Oppbevaring i tekstformat er forbudt. Etter utskrift må den fjernes i henhold til avtalen med CRPT. Det er ikke kjent om det har blitt brukt i praksis.
SUZ — bestillingsstyringsstasjon. Systemet der KM-er bestilles for varer.
EDO — elektronisk dokumentflyt.
UKEP — forsterket kvalifisert elektronisk signatur.

Termer og begreper innenfor rammen av denne artikkelen

ČZ — ærlig tegn.
LK — personlig konto.
Merket — trykt merkekode.

Prosessen ser ut som følger: først utsteder deltakeren (UOT) en elektronisk signatur (UKEP), registrerer seg i det ærlige tegnet (ČZ), beskriver varen i den nasjonale katalogen eller GS1, og mottar GTIN-er for varen. På nettstedet til det ærlige tegnet er disse trinnene detaljert beskrevet, så vi vil ikke gå inn på dem.

Bestilling og mottak av koder

Etter å ha mottatt GTIN-ene, bestiller deltakeren (UOT) koder (KM) i SUZ-systemet.
Viktig, men ikke åpenbart.

1. I en bestilling kan man maksimalt be om koder for 10 GTIN-er. Dette er i grunnen en uforståelig begrensning. En importør med 14 000 GTIN-er må lage 1400 bestillinger.
2. I en bestilling kan man maksimalt be om 150 000 koder.
3. Det er en grense på 100 aktive bestillinger. Det vil si at det ikke kan være mer enn 100 bestillinger i behandling samtidig. Hvis det er flere enn 100, vil API-en begynne å returnere en feil i stedet for bestillingslisten. Den eneste måten å løse dette problemet på er å lukke noen bestillinger gjennom webgrensesnittet. API-en støtter ikke et parameter for delvis visning av bestillinger.
4. Det er en grense for antall forespørsel — ikke mer enn 10 forespørsel per sekund. Så vidt jeg vet nevnes ikke dette begrensningen i dokumentene, men den eksisterer.

Fra personlig erfaring med bestilling av KMs etiketter via API-en i SUZ-systemet.

1. Forespørselen (selve json-en) må signeres med en GOST-signatur. Dette er arbeid med kryptografi. Man må være nøye med å sjekke at rammeverket eller biblioteket som brukes ikke endrer den opprinnelige json-en med et eneste byte. Ellers vil signaturen umiddelbart bli ugyldig.
2. Bestillingssignatur. Bestillingen kan signeres med hvilken som helst signatur fra hvilken som helst kunde. Hvis signaturen er gyldig, vil SUZ-systemet godta den. I integrasjonen klarte vi å signere forespørselen med en annen kundes signatur, utstedt av et test-sertifikat. Den operative SUZ-linjen behandlet bestillingen og utstedte koder. Etter min mening er dette et sikkerhetshull. Responsen på bug-rapporten fra utviklerne var “vi skal se på det”. Jeg håper de har fikset det.

   Derfor må dere være svært oppmerksomme hvis mer enn én juridisk enhet jobber på samme arbeidsplass. I dag vil SUZ godta disse forespørslene, men i morgen vil forespørslene bli dobbeltsjekket, og halvparten av kodene vil bli tilbakekalt på grunn av en annen signatur. Og generelt sett, formelt vil de ha rett.

3. Automatisk signering av bestillinger er ikke lenger funksjonalitet tilgjengelig i SUZ. For å få det til å fungere, måtte man laste opp den private delen av nøkkelen i brukerkontoen til den ærlige merkevaren. Dette utgjør en kompromittering av nøkkelen. I henhold til gjeldende lovgivning, ved kompromittering av en styrket kvalifisert elektronisk signatur, må innehaveren informere sitt sertifiseringsorgan (SO) og tilbakekalle SKS. Hvis denne funksjonaliteten skal gjenopprettes, vær oppmerksom på at den private delen av nøkkelen ikke forlater datamaskinen.
4. I februar innførte Senter for utvikling av avanserte teknologier (ЦРПТ) stille en begrensning på antall forespørsel til API-en for SUZ. Ikke mer enn én forespørsel per sekund. Så fjernet de denne begrensningen like uventet og stille. Jeg anbefaler derfor å legge inn i systemet muligheten til å begrense antall forespørsel til API-en for ЦРПТ i tilfelle det skjer igjen. Nå er det informasjon om en grense på 10 forespørsel per sekund.
5. Også i februar endret oppførselen til API-en for SUZ seg betydelig uten forvarsel. API-en har en forespørsel for å hente status på bestillinger. I statusen ble buffere og deres tilstand angitt. En GTIN = en buffer. Der var det også angitt hvor mange koder som var tilgjengelige for henting fra bufferen. En vakker dag ble antallet for alle buffere -1. Man måtte derfor spørre om tilstanden til hver buffer separat gjennom en annen metode. I stedet for én forespørsel måtte man gjøre elleve.

Strukturen til kodene

Så, kodene er bestilt og generert. De kan hentes gjennom API-en i tekstformat, i PDF som etiketter for utskrift, og som en CSV-fil med tekst.

Om API-en er det allerede skrevet tidligere. Når det gjelder de to andre metodene. Opprinnelig tillot SUZ å hente koder bare én gang. Og hvis man hentet PDF-filen, kunne man bare få kodene i tekstformat ved å skanne alle datamatrisene fra PDF-en. Heldigvis ble muligheten til å hente koder flere ganger lagt til, og dette problemet ble løst. I løpet av to dager er kodene fortsatt tilgjengelige for nedlasting på nytt.

Hvis du henter i CSV-format, så åpne det aldri, under noen omstendigheter, i Excel. Og gi ingen lov til å gjøre det. Excel har en autosave-funksjon. På tidspunktet for lagringen kan Excel på de mest uforutsigbare måtene endre kodene dine. Jeg anbefaler å bruke Notepad++ for å se på kodene.

Hvis du åpner filen fra SUZ i Notepad++, kan du se linjer av denne typen. Den tredje koden er ugyldig (den mangler GS-avgrenserne).

Partnere har sendt oss koder for merking av varene sine. Med blotte øyne er det klart hvilke filer som ble dannet med Excel – opptil 5 % av kodene var ugyldige.

Jeg anbefaler på det sterkeste å lese om standarder GS1. I beskrivelsen av standarden finnes det svar på mange spørsmål angående dannelsen av DataMatrix.

Identifikasjonskoden består av GTIN og serienummer. I henhold til GS1-standarden har de bruksidentifikatorer (BI) 01 og 21. Vær oppmerksom på at bruksidentifikatorene ikke er en del av GTIN eller serienummeret. De angir at GTIN eller serienummer kommer etter bruksidentifikatoren (BI). Dette er spesielt viktig når man programmerer kasseprogramvare. For å fylle ut tag 1162 kreves det spesifikt GTIN og serienummer, uten bruksidentifikatorene.

For UTD (universelt transportdokument) og andre dokumenter, derimot, er det oftest nødvendig å inkludere hele registreringen med bruksidentifikatorer.

I GS1-standarden er det fastslått at GTIN har en fast lengde på 14 tegn og kun kan bestå av tall. Serienummeret har variabel lengde og er beskrevet på side 155 av standarden. Der finnes også en lenke til tabellen med symbolene som kan forekomme i serienummeret.

Siden serienummeret har variabel lengde, angir GS-separatoren slutten av det. I ASCII-tabellen har den kode 29. Uten denne separatoren vil ingen programvare forstå når serienummeret slutter, og andre datagrupper begynner.

Mer informasjon om merkekoden (MK) kan leses i den offisielle dokumentasjonen.

For sko er serienummeret fastsatt til 13 tegn, men størrelsen kan endres når som helst. For andre varegrupper (VG) kan lengden på serienummeret variere.

Generering av DataMatrix

Neste steg er å konvertere dataene til DataMatrix-koden. I vedtaket fra den russiske regjeringen 860 er det angitt en GOST-standard som må følges for å danne DataMatrix. Det er også i PPR 860 angitt obligatorisk bruk av bruksidentifikatorer. Merk at standarden for DataMatrix ikke inneholder begrepet «bruksidentifikatorer». De finnes kun i GS-1 DataMatrix-standarden. Dermed forplikter PPR 860 indirekte til å bruke nettopp GS-1 DataMatrix. Heldigvis er standardene like. Hovedforskjellen er at i GS-1 DataMatrix må det første tegnet være FNC1. GS-tegnet må ikke være først i DataMatrix, kun FNC1.

FNC1 kan ikke bare legges til i strengen som GS. Det må legges til av programvaren som genererer DataMatrix. På nettstedene til Alliance Forties er det lagt ut flere mobile applikasjoner, som kan brukes til å sjekke riktigheten av de genererte DataMatrix-kodene.

Viktig. Applikasjonen Ærlig Merke tar imot ugyldige DataMatrix-koder. Selv QR-koder. Det faktum at merket ble gjenkjent og informasjon om produktet ble vist, er ikke en indikator på at DataMatrix er riktig generert. Selv med erstatning av kryptosvansen, gjenkjente appen ÆM merket og viste produktdata.

Senere ga ÆM ut en forklaring, om hvordan man riktig genererer koder. På grunn av det store antallet koder med feil, har de anerkjent koder uten FNC1 som gyldige, men de anbefaler likevel å generere GS-1 DataMatrix.

Dessverre kom et ganske stort prosentandel av datamatører fra partnere med feil. Takket være forklaringene fra ÆM ble spørsmålet "Kan man handle slike varer etter 1. juli eller ikke?" helt løst. Spoiler — det kan man.

Utskrift

Vær oppmerksom på måten merker skrives ut på. Når man skriver ut med termisk skriver, ble merket raskt bleket, og dette produktet kan ikke lenger selges. Et uleselig merke er et brudd på PPR 860. Dette fører til inndragning av varer, bøter og straffereaksjoner.

Bruk termotransfer-utskrift. I så fall er ikke merket så utsatt for bleking. Materialet på etiketten påvirker også hvor utsatt merket er for mekaniske skader. Hvis koden ikke leses på grunn av mekanisk skade, er dette likestilt med fravær av merket, med alle de påfølgende konsekvensene.

Velg skriver basert på de planlagte utskriftsvolumene. Bordskrivere er ikke laget for å skrive ut 100 000 etiketter per dag.

Stopp og start av utskrift øker slitasjen på skriveren. Noen programmer sender utskriftsjobben ett enkelt etikett av gangen. Det er best å unngå slike programmer.

Jobbe med dokumenter

Etter at merkene er skrevet ut og klistret på, skjer alle videre operasjoner med dem gjennom dokumenter eller personlig konto i Ærlig Merke.

Når man arbeider med et stort antall koder, kan man opprette XML-filer som inneholder de nødvendige koder, og laste opp disse filene via API eller webgrensesnittet til den personlige kontoen.

XSD-skjemaet kan lastes ned i delen "hjelp" i den personlige kontoen til ÆM.

Vær oppmerksom på følgende punkter.

1. XSD-skjemaene i den personlige kontoen til ÆM inneholder feil i gyldigheten av organisasjonsnummer og begrensninger på lengden av strengen. Bare ved å rette opp feilene kan man bruke skjemaene. Heldigvis er feilene åpenbare, så det er ikke vanskelig å fikse dem.
2. Skjemaet består som oftest av to deler – en generell for alle dokumenttyper og en egen for den spesifikke typen. Den generelle skjemaet er lagt til via import i den spesifikke. Begge skjemaene er plassert i hjelpeseksjonen i LK CHZ.
3. Reglene for escaping for KM avviker fra de vanlige for XML, dette er beskrevet i den offisielle dokumentasjonen fra CHZ, vær oppmerksom på dette. Her er her på side 4 alle reglene.
4. Du bør ikke prøve å introdusere 150 000 koder i omløp med én fil. Ifølge vitner går filer større enn 30 000 vanligvis gjennom.
5. XML-filen kan bli avslått med feilen "valideringsfeil i xml", og etter fem minutter kan den samme filen bli akseptert uten problemer.
6. Hvis filen inneholder en kode som allerede er introdusert i omløp, vil filen sannsynligvis ikke bli akseptert.
7. Frakt- og mottaksdokumenter brukes som en midlertidig løsning. I fremtiden planlegges det å avskaffe dem og gå over til UPD i henhold til PPR 860.
8. Myten om 60 dager. Det går en mening om at koder som ikke er introdusert i omløp "utløper" etter 60 dager. Dette er en myte, kilden er ukjent. Koder "utløper" bare hvis du ikke har hentet dem fra SUZ innen 60 dager. Levetiden for hentede koder er ikke begrenset.

Konklusjon

Ved utviklingen av min gratis applikasjon for merking BarCodesFX, ble det opprinnelig gjort en integrasjon med SUZ API. Da den ærlige merket uventet endret logikken til API for andre gang, måtte integrasjonen oppgis. Jeg håper at CHZ i fremtiden vil stabilisere utviklingen og API-et, da det for et ikke-kommersielt produkt er veldig ressurskrevende for meg å sjekke hver dag om det har vært endringer i API, og raskt oppdatere.

Ved implementering av merking, vær nøye med å bli kjent med forskriftsdokumentasjonen for din varegruppe TG, skriv ut GS1-DataMatrix riktig, og vær forberedt på eventuelle uforutsette endringer fra den ærlige merket CHZ.

Forta-alliansen har opprettet et informasjonsrom (wiki, chatter i Telegram, seminarer, webinarer), hvor du kan finne nyttig og aktuell informasjon om merking i alle bransjer.

Kilde: habr.com