DataMatrix eller hur man korrekt märker skor

Sedan 1 juli 2019 trädde obligatorisk märkning av en viss varugrupp i kraft i Ryssland. Från och med den 1 mars 2020 skulle skorna omfattas av denna lag. Inte alla hanterade att förbereda sig i tid, och därför sköts lanseringen fram till den 1 juli. Lamoda är en av dem som lyckades.

Därför vill vi dela med oss av erfarenheter till dem som ännu måste märka kläder, däck, parfymer osv. Artikeln beskriver en rad branschstandarder, viss lagstiftning och personlig erfarenhet. Artikeln är främst avsedd för integratörer och utvecklare som just ska börja sätta sig in i detta projekt.

Observera att den regulatoriska grunden ofta förändras, och författaren har inte möjlighet att ständigt uppdatera materialet. Därför kan en del information redan vara föråldrad vid tidpunkten för läsningen.

Den personliga erfarenheten har författaren fått både genom arbetet inom Datamatrix-projektet på Lamoda och genom utveckling av den egna gratisapplikationen för märkning, BarCodesFx.

Sedan 1 juli 2019 gäller lagen om obligatorisk märkning i Ryssland. Lagen omfattar inte alla varugrupper, och tidsfristerna för obligatorisk märkning för varugrupper skiljer sig åt. Just nu omfattar obligatorisk märkning tobaksprodukter, pälsar, skor och läkemedel. Snart kommer det att införas för däck, kläder, parfymer och cyklar. Varje varugrupp regleras av ett särskilt regeringsbeslut (PPR). Därför kan vissa uttalanden som är sanna för skor vara felaktiga för andra varugrupper. Men man kan hoppas att de tekniska aspekterna inte kommer att variera mycket mellan olika varugrupper.

MärkningHuvudidén bakom märkningen är att varje enskild produkt får ett unikt nummer. Med detta nummer kan man spåra historien för just den produkten från produktion eller import till landet, fram till dess att den säljs i kassan. Det låter bra, men är oerhört svårt att genomföra i praktiken. Mer om konceptet beskrivs på den officiella hemsidan för den ärliga märkningen.

Allmänt accepterade termer och begrepp

UOT — deltagare i varucirkulationen.
CRPT — centrum för utveckling av framtida teknologier. Ett privat företag, den enda statliga leverantören för märkningsprojektet. Verkar enligt en modell för offentlig-privat partnerskap (PPP). Tyvärr finns det ingen information om andra deltagare i anbudet för projektet, liksom om själva anbudet.
TG — varugrupp. Skor, kläder, däck, etc.
GTIN — i princip, artikelnummer med avseende på färg-storlek. Utfärdas i GS1 eller nationella katalogen för varje importör eller tillverkare av deras produkt. Först måste tillverkaren eller importören beskriva denna produkt.
PPR — föreskrift från den ryska regeringen. För skor — 860.
KM — märkningkod. En unik uppsättning tecken som tilldelas en specifik produkt. För skor består den av GTIN, serienummer, kontrollkod och kryptotail.
GS1 — en internationell organisation som utfärdar GTIN. Också utarbetare av en rad standarder för märkning.
Nationell katalog — motsvarighet till GS1, utvecklad av CRPT.
Kryptotail — motsvarighet till digitalt signatur som bekräftar lagligheten av KM. Måste finnas i datamatrixen på märkningen. Förvaring i textformat är förbjuden. Efter utskrift av märkningen måste den tas bort enligt avtalet med CRPT. Ingen känd fall av verklig användning.
SUZ — system för beställning av märkningar (KM). Ett system där KM beställs för produkten.
EDO — elektronisk dokumenthantering.
UKEP — förstärkt kvalificerad elektronisk signatur.

Termer och begrepp inom ramen för denna artikel

CZ — ärlig märkning.
LK — personligt konto.
Märkning — tryckt märkningkod.

Processen ser ut som följande: först utfärdar deltagaren (UOT) en elektronisk signatur (UKEP), registrerar sig i den ärliga märkningen (CZ), beskriver produkten i den nationella katalogen eller GS1, får GTIN för produkten. På webbplatsen för den ärliga märkningen är dessa steg detaljerat beskrivna, så vi kommer inte att stanna vid dem.

Beställning och mottagning av koder

Efter mottagandet av GTIN gör deltagaren (UOT) en beställning av koder (KM) i systemet SUZ.
Viktigt, men inte uppenbart.

1. I en beställning kan man begära koder för högst 10 GTIN. I princip en otydlig begränsning. En importör med 14 000 GTIN måste skapa 1400 beställningar.
2. I en beställning kan man begära högst 150 000 koder.
3. Det finns en begränsning på 100 beställningar i arbete. Det betyder att högst 100 beställningar kan behandlas samtidigt. Om det finns fler än 100 börjar API:et returnera ett fel istället för listan över beställningar. Det enda sättet att åtgärda detta fel är att stänga vissa beställningar via webbgränssnittet. API:et har ingen parameter för delvis visning av beställningar.
4. Det finns en gräns för antalet förfrågningar – högst 10 anrop per sekund. Enligt mina uppgifter nämns inte denna begränsning i dokumenten, men den finns.

Utifrån min personliga erfarenhet av att arbeta med beställningar av iOS-identifieringskoder via systemet SUZ API.

1. Begäran (json) måste signeras med GOST-signatur. Detta innebär arbete med kryptopro. Man måste vara noga med att den använda ramverket eller biblioteket inte ändrar den ursprungliga json med ett enda byte. Annars slutar signaturen att vara giltig direkt.
2. Beställningssignatur. En beställning kan signeras med vilken signatur som helst, från vilken klient som helst. Om signaturen är giltig kommer systemet SUZ att acceptera den. Vid integration har jag lyckats signera en begäran med en annan signatur som utfärdats av en testcertifieringsmyndighet. Den operativa SUZ-konturen behandlade beställningen och utfärdade koder. Enligt min mening är detta en säkerhetsbrist. Utvecklarna reagerade på buggrapporten med 'vi ska undersöka det'. Jag hoppas att de har åtgärdat det.

   Därför är det extremt viktigt att vara försiktig om mer än en juridisk enhet arbetar på en och samma arbetsplats. Idag kommer SUZ att acceptera dessa förfrågningar, men imorgon kommer förfrågningarna att kontrolleras och hälften av koderna återkallas på grund av en främmande signatur. Formellt sett kommer de att ha rätt.

3. Automatisk signering av beställningar är inte längre tillgänglig i SUZ. För dess funktionalitet krävdes det att ladda upp den privata delen av nyckeln i den personliga portalen för den ärliga signaturen. Detta är en kompromettering av nyckeln. Enligt nuvarande lagstiftning ska ägaren informera sin certifieringsmyndighet (CA) och återkalla den kvalificerade elektroniska signaturen (QES) om den kommit i orätta händer. Om denna funktionalitet ska återinföras, se till att den privata delen av nyckeln inte lämnar datorn.
4. I februari införde centrumet för utveckling av lovande teknologier (ЦРПТ) tyst ett begränsning av antalet förfrågningar till API för SUZ. Inte mer än en förfrågan per sekund. Sedan avskaffades denna begränsning lika plötsligt och tyst. Därför rekommenderar jag att bygga in möjlighet i systemet att begränsa antalet förfrågningar till API för ЦРПТ ifall det skulle inträffa igen. Just nu finns det information om en gräns på 10 förfrågningar per sekund.
5. Även i februari förändrades beteendet hos API för SUZ utan förvarning. I API:t finns det en begäran för att få status på beställningar. Statusen angav buffrar och deras tillstånd. En GTIN = en buffer. Där angavs även hur många koder som fanns tillgängliga för att hämta från bufferten. En dag blev antalet för alla buffrar -1. Man var tvungen att fråga tillståndet för varje buffer separat via en annan metod. Istället för en förfrågan fick man göra elva.

Strukturen av koder

Så, koderna har beställts och genererats. De kan hämtas via API i textformat, i pdf som etiketter för utskrift och som csv-fil med text.

API:t har redan nämnts ovan. När det gäller de två andra alternativen. Ursprungligen tillät SUZ att hämta koder endast en gång. Om en pdf-fil hämtades kunde koderna i textformat endast erhållas genom att skanna alla datamatrixar från pdf. Som tur var, lade man till möjligheten att hämta koder flera gånger, och detta problem löstes. Inom två dagar är koderna fortfarande tillgängliga för nedladdning.

Om du hämtar i csv-format, öppna aldrig, under några omständigheter, det i Excel. Och tillåt ingen annan att göra det. I Excel finns det en autospara-funktion. Vid sparande kan Excel på de mest oförutsägbara sätten ändra dina koder. Jag rekommenderar att använda notepad++ för att visa koderna.

Om du öppnar filen från SUZ i notepad++, kan du se rader av detta slag. Den tredje koden är ogiltig (den saknar GS-avskiljare).

Partners har skickat oss koder för märkning av sina produkter. Det är tydligt att vilka filer som har skapats med hjälp av Excel — upp till 5% av koderna var ogiltiga.

Jag rekommenderar starkt att läsa om standarder GS1. I beskrivningen av standarden finns svar på många frågor om skapande av DataMatrix.

Identifier-koden består av GTIN och serienummer. Enligt GS1-standarden motsvarar de tillämpningsidentifiera (TI) 01 och 21. Observera att tillämpningsidentifiera inte är en del av GTIN och serienummer. De anger att GTIN eller serienummer följer efter tillämpningsidentifieraren (TI). Detta är särskilt viktigt vid programmering av kassasystem. För att fylla i taggen 1162 behövs just GTIN och serienummer, utan tillämpningsidentifiera.

För UTD (universalöverföringsdokument) och andra dokument krävs å sin sida oftast en fullständig post med tillämpningsidentifiera.

I GS1-standarden anges att GTIN har en fast längd på 14 tecken och endast kan bestå av siffror. Serienumret har variabel längd och beskrivs på sida 155 av standarden. Där finns också en hänvisning till en tabell med tecken som kan förekomma i serienumret.

Eftersom serienumret har variabel längd indikerar GS-avskiljaren dess slut. I ASCII-tabellen är den kod 29. Utan denna avskiljare förstår inget program när serienumret avslutades och andra datagrupper började.

Mer information om märkningkoden (ФК) kan läsas i den officiella dokumentationen.

För skor är serienumret fastställt till 13 tecken, men dess storlek kan ändras när som helst. För andra produktgrupper (PG) kan längden på serienumret variera.

Generering av DataMatrix

Nästa steg är att konvertera data till DataMatrix-kod. I den ryska regeringens förordning 860 anges en GOST som anger hur DataMatrix ska bildas. I samma förordning anges att användningen av tillämpningsidentifierare är obligatorisk. Observera att termen 'tillämpningsidentifierare' inte finns i DataMatrix-standarden. De finns endast i GS1 DataMatrix-standarden. Det innebär att förordning 860 implicit kräver användning av just GS1 DataMatrix. Lyckligtvis liknar standarderna varandra. Huvudskillnaden: i GS1 DataMatrix måste den första symbolen vara FNC1. GS-symbolen får inte stå först i DataMatrix, bara FNC1.

FNC1 kan inte helt enkelt läggas till i strängen som GS. Den måste lägga till av programmet som genererar DataMatrix. På Allians Fortas resurser finns flera mobilapplikationersom kan användas för att kontrollera korrektheten av de genererade DataMatrix-koderna.

Viktigt. Appen Ärlig Tecken accepterar ogiltiga DataMatrix. Även QR-koder. Det faktum att varumärket har identifierats och informationen om produkten har visats betyder inte att DataMatrix är korrekt genererad. Även med ett utbytt kryptosvans identifierade appen ÄT varumärket och visade produktdata.

Senare släppte ÄT en förklaring, om hur man korrekt genererar koder. På grund av det stora antalet koder med fel erkände de koder utan FNC1 som giltiga, men rekommenderade trots allt att generera GS-1 DataMatrix.

Tyvärr kom en ganska stor andel av DataMatrix från partner med fel. Tack vare förklaringarna från ÄT löstes frågan helt "Kan man sälja en sådan produkt efter den 1 juli eller inte?" Spoiler — det kan man.

Utskrift

Observera hur märken skrivs ut. Vid utskrift på termiska skrivare bleknar märket snabbt, och denna produkt kan inte längre säljas. Ett oläsligt märke är en överträdelse av PPR 860. Det leder till konfiskering av produkten, böter, och straffansvar.

Använd termotransferutskrift. I det här fallet är märket inte så utsatt för blekning. Även etikettens material avgör hur mycket märket är utsatt för mekaniska skador. Om koden inte kan läsas på grund av mekanisk skada är det detsamma som att vara utan märke med alla följder som det innebär.

Välj skrivare utifrån de planerade utskriftsvolymerna. Skrivare för skrivbord är inte avsedda för att skriva ut 100 000 etiketter per dag.

Stopp och start av utskrift ökar slitaget på skrivaren. Vissa program skickar utskriftsuppdrag en etikett i taget. Det är bättre att inte använda sådana program.

Arbete med dokument

När märkena har skrivits ut och klistrats fast, sker alla ytterligare operationer med dem via dokument eller Ärlig Teckens personliga konto.

Vid hantering av ett stort antal koder kan man skapa xml-filer med de nödvändiga koderna och ladda upp dessa filer via API eller webbgränssnittet för det personliga kontot.

XSD-schemat kan laddas ner i avsnittet "hjälp" i ÄT:s personliga konto.

Observera följande punkter.

1. XSD-scheman i ÄT:s personliga konto innehåller valideringsfel i INN och begränsningar på stränglängden. Endast genom att rätta till felen kan scheman användas. Lyckligtvis är felen uppenbara, så det är inte svårt att göra detta.
2. Schemat består oftast av två delar — en gemensam för alla dokumenttyper och en separat för den specifika typen. Den gemensamma schemat läggs till genom import i den specifika. Båda schemana finns i hjälpavsnittet i Konto för Tjänsteleverantör.
3. Reglerna för escaping för KMs skiljer sig från de allmänt accepterade för XML, detta är beskrivet i den officiella dokumentationen från Tjänsteleverantör, var vänlig notera detta. Här är här på sidan 4, alla regler.
4. Försök inte att registrera 150 000 koder i omlopp med en enda fil. Enligt vittnen passerar filer med över 30 000 vanligtvis..
5. XML-filen kan returneras med felmeddelandet "XML-valideringsfel", och fem minuter senare accepteras samma fil utan problem.
6. Om filen innehåller en kod som redan har registrerats, kommer filen sannolikt inte att accepteras för registrering.
7. Fraktdokument och mottagningsdokument används som en tillfällig lösning. I framtiden planeras de att avskaffas och övergå till UPP enligt PPR 860.
8. Myten om 60 dagar. Det finns en uppfattning om att koder som inte registrerats "utslocknar" efter 60 dagar. Detta är en myt, källan är okänd. Koder "utslocknar" endast om du inte har hämtat dem från SUZ inom 60 dagar. Livslängden för hämtade koder är obegränsad.

Slutsats

Vid utvecklingen av min kostnadsfria applikation för märkning BarCodesFX gjordes det ursprungligen en integration med SUZ:s API. När den Ärliga Symbolen plötsligt ändrade API-logiken en andra gång, fick vi överge integrationen. Jag hoppas att Tjänsteleverantör i framtiden kan stabilisera utvecklingen och API:t, eftersom det är mycket kostsamt för mig som icke-kommersiell produkt att varje dag kontrollera om någon förändring har skett i API:t och snabbt modifiera.

Vid implementeringen av märkningen, bekanta dig noggrant med de normerande dokumenten för din varugrupp TG, skriv ut GS1-DataMatrix korrekt och var beredd på alla oväntade förändringar från den Ärliga Symbolen.

Fort Alliance har skapat ett informationsutrymme (wiki, chattar i Telegram, seminarier, webbinarier), där du kan hitta användbar och aktuell information om märkning inom alla branscher.

Källa: habr.com