Fra den 1. juli 2019 blev obligatorisk mærkning af varer indført i Rusland. Fra den 1. marts 2020 skulle sko også omfattes af denne lov. Ikke alle var klar, og derfor blev lanceringen udsat til den 1. juli. Lamoda er blandt dem, der nåede det.
Derfor ønsker vi at dele erfaringer med dem, der stadig skal mærke tøj, dæk, parfume osv. Artiklen beskriver en række branchestandarder, relevant lovgivning og personlige erfaringer. Artiklen er primært beregnet til integratorer og udviklere, som skal til at forstå dette projekt.
Bemærk, at den normative base ofte ændrer sig, og forfatteren har ikke mulighed for at opdatere materialet konstant. Derfor kan dele af informationen allerede være forældet, når du læser dette.
Forfatterens personlige erfaring er opnået både gennem arbejdet med Datamatrix-projektet hos Lamoda og ved udviklingen af sin egen gratis applikation til mærkning, BarCodesFx.
Fra den 1. juli 2019 er loven om obligatorisk mærkning i Rusland trådt i kraft. Loven gælder ikke for alle varegrupper, og datoerne for ikrafttrædelse af obligatorisk mærkning varierer for de forskellige varegrupper. I øjeblikket omfattes tobaksvarer, pelze, sko og lægemidler af den obligatoriske mærkning. Snart vil det blive indført for dæk, tøj, parfumer og cykler. Hver varegruppe reguleres af 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 del ikke vil variere meget mellem de forskellige varegrupper.
MærkningHovedideen med mærkning er, at hver vare tildeles et unikt nummer. Dette nummer gør det muligt at spore historien for den specifikke vare fra produktions- eller importtidspunktet til det tidspunkt, den forlader kassen. Det lyder godt, men det er ekstremt svært at gennemføre i praksis. Detaljer om konceptet kan findes på den officielle hjemmeside for den ærlige mærkning.
Almindeligt accepterede termer og begreber
UOT — deltager i vareomsætningen.
CRPT — centrum for udvikling af fremtidige teknologier. En privat virksomhed, den eneste statslige kontraktør for mærkningsprojektet. Arbejder efter modellen for offentligt-private partnerskaber (OPP). Desværre er der ingen oplysninger om andre deltagere i udbuddet på projektet, ligesom der ikke er nogen oplysninger om selve udbuddet.
TG — varegruppe. Sko, tøj, dæk osv.
GTIN — i princippet en artikelnummer, der tager hensyn til farve og størrelse. Udstedes af GS1 eller nationalkataloget for hver importer eller producent for deres varer. Forud for det skal producenten eller importøren beskrive denne vare.
PPR — regeringsbestemmelse i Den Russiske Føderation. For sko — 860.
KM — mærkningskode. Et unikt tegnsæt tildelt en bestemt vare. For sko består det af GTIN, serienummer, kontrolkode og kryptohale.
GS1 — den internationale organisation, der udsteder GTIN-nummer. Desuden forfatteren af en række standarder for mærkning.
Nationalkatalog — en analog til GS1, udviklet af CRPT.
Kryptohale — en analog til digital signatur, der bekræfter legitimiteten af KM. Skal være til stede i datamatrisen på mærket. Opbevaring i tekstformat er forbudt. Efter udskrivning af mærket skal den fjernes i henhold til kontrakten med CRPT. Ingen tilfælde af reel brug er kendt.
SUZ — kontrolstation for bestillinger. Systemet, hvori KM bestilles til varen.
EDO — elektronisk dokumenthåndtering.
UKEP — forstærket kvalificeret elektronisk signatur.
Termer og begreber inden for denne artikel
CHZ — ærlig mærke.
LK — brugerkonto.
Mærke — den trykte mærkningskode.
Processen ser således ud: først udsteder deltageren (UOT) en elektronisk signatur (UKEP), registrerer sig i det ærlige mærke (CHZ), beskriver varen i nationalkataloget eller GS1, og modtager GTIN-nummer for varen. På hjemmesiden for det ærlige mærke er disse trin beskrevet i detaljer, så vi vil ikke gå nærmere ind på dem.
Bestilling og modtagelse af koder
Efter modtagelse af GTIN-numrene bestiller deltageren (UOT) koder (KM) i SUZ-systemet.
Vigtigt, men ikke åbenlyst.
- I én bestilling kan der maks. anmodes om koder for 10 GTIN-numre. Grundlæggende er det en uklar begrænsning. En importør med 14.000 GTIN-numre må oprette 1.400 bestillinger.
- I én bestilling kan der maks. anmodes om 150.000 koder.
- Der er en grænse på 100 ordrer i behandling. Det vil sige, at der kan være højst 100 ordrer, der behandles samtidigt. Hvis der er mere end 100, begynder API'en at returnere en fejl i stedet for en liste over ordrer. Den eneste måde at løse denne fejl på er at lukke nogle ordrer gennem webgrænsefladen. API'en understøtter ikke en parameter til delvis visning af ordrer.
- Der er en grænse for antallet af forespørgsler — højst 10 forespørgsler pr. sekund. Ifølge mine oplysninger fremgår denne grænse ikke i dokumenterne, men den eksisterer.
Fra mine personlige erfaringer med bestilling af mærkningskoder gennem API'en i SUZ-systemet.
- Forespørgslen (selve json) skal underskrives med en GOST-underskrift. Dette involverer arbejdet med kryptopro. Man skal være opmærksom på, at den anvendte ramme eller bibliotek ikke ændrer den oprindelige json med så meget som et byte. Ellers vil underskriften straks blive ugyldig.
- Ordreunderskrift. En ordre kan underskrives med hvilken som helst underskrift fra en hvilken som helst kunde. Hvis underskriften er gyldig, vil SUZ-systemet acceptere den. Under integrationen lykkedes det at underskrive forespørgslen med en anden parts underskrift, der var udstedt af et testende certifikatcenter. Den operative cirkel i SUZ behandlede ordren og udstedte koder. Efter min mening er dette en sikkerhedssvaghed. Udviklerne reagerede på bug-reporten med "vi ser på det". Jeg håber, de har rettet det.
Derfor skal man være yderst forsigtig, hvis der er mere end én juridisk enhed, der arbejder på det samme arbejdssted. I dag vil SUZ acceptere disse forespørgsler, men i morgen vil forespørgslerne blive genstand for kontrol, og halvdelen af koderne vil blive tilbagekaldt på grund af en anden parts underskrift. Og i princippet vil de være formelt i deres ret.
- Automatisk underskrivelse af ordrer er en funktion, der ikke længere er tilgængelig i SUZ. For at den kunne fungere, var det nødvendigt at uploade den lukkede del af nøglet i den personlige konto for den ærlige mærke. Dette udgør en kompromittering af nøglen. Ifølge gældende lovgivning skal ejeren af en kompromitteret kvalificeret elektronisk underskrift informere sit certifikatcenter (CA) og tilbagekalde den kvalificerede underskrift. Hvis denne funktionalitet skulle genindføres, skal man sørge for, at den lukkede del af nøglen ikke forlader computeren.
- I februar indførte Center for Udvikling af Perspektivfulde Teknologier (ЦРПТ) stille og roligt en grænse for antallet af anmodninger til API SУЗ. Ikke mere end én anmodning pr. sekund. Så fjernede de også denne begrænsning lige så uventet og stille. Derfor anbefaler jeg at inkludere mulighed for at begrænse antallet af anmodninger til API СРТ på tilfælde af et tilbagefald. Der er nu oplysning om en grænse på 10 anmodninger pr. sekund.
- Også i februar ændrede adfærden af API СУЗ sig markant uden forudgående advarsel. API'et har en anmodning til at få status på ordrer. I statusen blev der angivet buffere og deres tilstand. Én GTIN = én buffer. Der blev også angivet, hvor mange koder der var tilgængelige til hentning fra bufferen. En skønne dag blev antallet for alle buffere -1. Du måtte bruge en separat metode til at spørge om status på hver buffer individuelt. I stedet for én anmodning måtte du lave elleve.
Struktur af koder
Så koderne er bestilt og genereret. De kan hentes gennem API'et i tekstformat, i PDF som etiket til udskrivning og i CSV-fil med tekst.
API'et er allerede nævnt ovenfor. Hvad angår de to andre metoder, tillod СУЗ oprindeligt kun at hente koder én gang. Og hvis du hentede PDF-filen, kunne koderne kun hentes i tekstformat ved at scanne alle datamatrixer fra PDF'en. Heldigvis blev det tilføjet muligheden for at hente koder flere gange, og dette problem blev løst. Koderne er tilgængelige for download igen i to dage.
Hvis du henter i CSV-format, så åbn aldrig, under nogen omstændigheder, dette i Excel. Og lad ingen andre gøre det. Excel har en autosave-funktion. På tidspunktet for gemme kan Excel på den mest uforudsigelige måde ændre dine koder. Jeg anbefaler at bruge Notepad++ til at se koderne.
Hvis du åbner en fil fra СУЗ i Notepad++, kan du se linjer af denne art. Den tredje kode er ugyldig (den har ikke GS-separatorer).
Partnere har sendt os koder til mærkning af deres varer. Med det blotte øje kan man se, hvilke filer der er blevet dannet med hjælp fra Excel - op til 5% af koderne var ugyldige.
Jeg anbefaler kraftigt at læse om GS1. I beskrivelsen af standarden findes svar på mange spørgsmål vedrørende dannelse af DataMatrix.
Identifikationskoden består af GTIN og serienummer. Ifølge GS1-standarden svarer de til anvendelsesidentifikatorer (AI) 01 og 21. Bemærk, at anvendelsesidentifikatorerne ikke er en del af GTIN og serienummeret. De angiver, at der efter anvendelsesidentifikatoren (AI) følger GTIN eller serienummer. Dette er særligt vigtigt ved programmering af kasseprogrammer. For at udfylde tag 1162 er det netop GTIN og serienummer, uden anvendelsesidentifikatorer.
For UDD (universal overførselsdokument) og andre dokumenter er det derimod oftest nødvendigt at have hele posten med anvendelsesidentifikatorerne.
I GS1-standarden er det angivet, at GTIN har en fast længde på 14 tegn og kun kan bestå af cifre. Serienummeret har en variabel længde og er beskrevet på side 155 i standarden. Der er også et link til en tabel med tegn, der kan forekomme i serienummeret.
Da serienummeret har en variabel længde, angiver GS-separatoren slutningen af det. I ASCII-tabellen har det kode 29. Uden denne separator vil intet program forstå, hvornår serienummeret slutter, og andre datagrupper begynder.
Du kan læse mere om mærkningskode (MK) i .
For sko er serienummeret fastlagt til 13 tegn, men dets størrelse kan ændres når som helst. For andre varegrupper (VG) kan længden af serienummeret variere.
Generering af DataMatrix
Næste skridt er konvertering af data til DataMatrix-koden. I den russiske regeringsafgørelse 860 er der angivet en standard, der kræver, at DataMatrix skal dannes. I PPR 860 er der også angivet obligatorisk brug af anvendelsesidentifikatorer. Bemærk, at der ikke er nogen begreb om „anvendelsesidentifikatorer“ i DataMatrix-standarden. De findes kun i GS-1 DataMatrix-standarden. Det betyder, at PPR 860 indirekte forpligter til at bruge netop GS-1 DataMatrix. Heldigvis er standarderne ens. Den primære forskel: i GS-1 DataMatrix skal det første tegn være FNC1. GS-tegnet må ikke være det første tegn i DataMatrix; kun FNC1.
FNC1 kan ikke bare tilføjes til strengen som GS. Det skal tilføjes af det program, der genererer DataMatrix. På Alliance Forts ressourcer er der offentliggjort flere , som kan bruges til at kontrollere rigtigheden af de genererede DataMatrix-koder.
Vigtigt. Applikationen ærlige tegn accepterer ugyldige DataMatrix. Selv QR-koder. Det faktum, at mærket blev genkendt og informationen om produktet blev vist, er ikke en indikator på, at DataMatrix er korrekt dannet. Selv ved udskiftning af kryptosvansen genkendte appen ČZ mærket og viste dataene om produktet.
Senere udgav ČZ , hvordan man korrekt genererer koder. På grund af det store antal fejlbehæftede koder anerkendte de koder uden FNC1 som gyldige, men de anbefaler alligevel at generere GS-1 DataMatrix.
Desværre kom en ret stor procentdel af datamatricerne fra partnere med fejl. Takket være forklaringerne fra ČZ blev spørgsmålet "Kan man handle med sådanne produkter efter den 1. juli eller ej?" helt afklaret. Spoiler - ja, det kan man.
Udskrivning
Vær opmærksom på måden at udskrive mærker på. Ved udskrivning på termisk printer falmer mærket hurtigt, og dette produkt kan ikke længere sælges. Et ulæseligt mærke er en overtrædelse af PPR 860, hvilket fører til inddragelse af varen, bøder og strafferetligt ansvar.
Brug termotransferudskrivning. På denne måde er mærket ikke så meget udsat for falming. Materialet i etiketten påvirker også, hvor meget mærket er udsat for mekaniske skader. Hvis koden ikke kan læses på grund af mekanisk skade, er det det samme som at mangle et mærke med alle de deraf følgende konsekvenser.
Vælg printeren ud fra de planlagte udskrivningsvolumener. Kontorprintere er ikke designet til at udskrive 100.000 etiketter om dagen.
Stop og start af udskrivning øger slid på printeren. Nogle programmer sender printjob på en etiket ad gangen. Det er bedre ikke at bruge sådanne programmer.
Arbejder med dokumenter
Når mærkerne er blevet udskrevet og påført, foregår alle efterfølgende operationer med dem gennem dokumenter eller den personlige konto for ærlige tegn.
Ved arbejde med et stort antal koder kan der oprettes xml-filer, som indeholder de nødvendige koder, og disse filer kan uploades via API eller webgrænsefladen til den personlige konto.
XSD-skemaet kan downloades i afsnittet "hjælp" i LK ČZ.
Vær opmærksom på følgende punkter.
- XSD-skemaer i LK ČZ indeholder fejl i validering af CVR-nummer og begrænsninger på længden af strengen. Kun ved at rette fejlene kan skemaerne anvendes. Heldigvis er fejlene åbenlyse, så det er ikke svært at gøre.
- Skemaen består oftest af to dele - en fælles for alle dokumenttyper og en specifik for en bestemt type. Den fælles skema er tilføjet gennem import i det specifikke. Begge skemaer findes i sektionen hjælp i den personlige konto.
- Reglerne for escapering for KM adskiller sig fra de almindeligt accepterede for XML, dette er beskrevet i den officielle dokumentation fra ČZ, vær venlig at bemærke dette. Her er alle regler på side 4.
- Man bør ikke forsøge at indføre 150.000 koder på én gang. Ifølge vidner går filer med mere end 30.000 normalt igennem...
- En XML-fil kan blive afvist med fejlen “xml-valideringsfejl”, og fem minutter senere kan den samme fil accepteres uden problemer.
- Hvis der i filen findes en kode, der allerede er blevet indført, vil filen til indførsel sandsynligvis ikke blive accepteret.
- Dokumenterne til forsendelse og modtagelse bruges som en midlertidig løsning. I fremtiden er der planer om at afskaffe dem og overgå til UPM i henhold til PPR 860.
- Myten om 60 dage. Der cirkulerer en opfattelse af, at koder, der ikke er indført, "udløber" efter 60 dage. Dette er en myte, kilde ukendt. Koder "udløber" kun, hvis du ikke har hentet dem fra SUZ inden for 60 dage. Levetiden for de hentede koder er ikke begrænset.
Konklusion
Da jeg udviklede min gratis applikation til mærkning BarCodesFX, blev der oprindeligt lavet en integration med SUZ API. Da ærlig tegn uventet ændrede API-logikken for anden gang, måtte jeg opgive integrationen. Jeg håber, at ČZ i fremtiden vil stabilisere udviklingen og API’et, da det er meget omkostningsfuldt for mig som udvikler af et ikke-kommercielt produkt at tjekke for ændringer i API’et dagligt.
Ved implementering af mærkning skal du nøje gøre dig bekendt med de normative dokumenter for din varegruppe TG, korrekt udskrive GS1-DataMatrix og være forberedt på enhver uventet ændring fra ČZ.
Fort Alliance har skabt et informationsrum (, i Telegram, seminarer, webinarr), hvor du kan finde nyttige og aktuel information om mærkning i alle brancher.
Kilde: habr.com
