Vanaf 1 juli 2019 is verplichting van de etikettering van bepaalde productgroepen in Rusland van kracht. Vanaf 1 maart 2020 zou dit ook voor schoenen gelden. Niet iedereen was op tijd voorbereid en daardoor is de startdatum uitgesteld naar 1 juli. Lamoda is een van de bedrijven die er klaar voor was.
Daarom willen we onze ervaringen delen met degenen die zich nog moeten voorbereiden op de etikettering van kleding, autobanden, parfums, enzovoort. In dit artikel wordt een aantal branche-standaarden, relevante regelgeving en persoonlijke ervaringen beschreven. Het artikel is voornamelijk bedoeld voor integratoren en ontwikkelaars die zich in dit project moeten verdiepen.
Let op dat de regelgeving vaak verandert en de auteur niet in staat is om het materiaal voortdurend bij te werken. Daarom kan het zijn dat een deel van de informatie verouderd is tegen de tijd dat het gelezen wordt.
De persoonlijke ervaring van de auteur is opgedaan zowel in het kader van het Datamatrix-project bij Lamoda als bij de ontwikkeling van een eigen gratis etiketteringsapplicatie genaamd BarCodesFx.
Sinds 1 juli 2019 is de wet op de verplichte etikettering in Rusland van kracht. De wet is niet van toepassing op alle productgroepen, en de termijnen voor de invoering van verplichte etikettering verschillen per productgroep. Momenteel vallen tabak, bontjassen, schoenen en medicijnen onder de verplichte etikettering. Binnenkort wordt het ook ingevoerd voor autobanden, kleding, parfums en fietsen. Elke productgroep wordt geregeld door een afzonderlijk regeringsbesluit (PPR). Daarom kunnen sommige uitspraken die voor schoenen correct zijn, verkeerd zijn voor andere productgroepen. Maar we kunnen hopen dat de technische component niet veel zal variƫren tussen de verschillende productgroepen.
EtiketteringHet belangrijkste idee van etikettering is dat elke producteenheid een uniek nummer krijgt. Met dit nummer kan de geschiedenis van een specifieke producteenheid worden gevolgd, vanaf de productie of import in het land tot het moment van afvoer bij de kassa. Dit klinkt mooi, maar is in de praktijk uiterst moeilijk te realiseren. Meer details over het concept zijn te vinden op de officiƫle website van het eerlijke teken.
Algemene termen en begrippen
UOT ā deelnemer in de handelsketen van goederen.
CRPT ā centrum voor de ontwikkeling van vooruitstrevende technologieĆ«n. Een privĆ©bedrijf, de enige staatcontractant voor het merkproject. Werkt volgens het model van publiek-private samenwerking (PPS). Helaas is er geen informatie over andere deelnemers aan de aanbesteding of over de aanbesteding zelf.
TG ā goederen groep. Schoenen, kleding, banden, enzovoort.
GTIN ā in wezen een artikelnummer rekening houdend met kleur- en maatvarianten. Wordt uitgegeven door GS1 of de nationale catalogus voor elke importeur of producent voor hun product. De producent of importeur moet dit product van tevoren beschrijven.
PPR ā besluit van de regering van de Russische Federatie. Voor schoenen ā 860.
KM ā code voor merkregistratie. Een unieke reeks symbolen toegewezen aan een specifiek product. Voor schoenen bestaat het uit GTIN, serienummer, controlecode en cryptografische staart.
GS1 ā internationale organisatie die GTIN's uitgeeft. Ook de opstellers van een aantal normen voor merkregistratie.
Nationale catalogus ā vergelijkbaar met GS1, ontwikkeld door CRPT.
Cryptografische staart ā vergelijkbaar met een digitale handtekening die de legaliteit van de KM bevestigt. Moet verplicht aanwezig zijn in de datamatrix op het etiket. Opslag in tekstvorm is verboden. Na het afdrukken van het etiket moet het worden verwijderd volgens het contract met CRPT. Er is geen geval bekend van daadwerkelijk gebruik.
SUZ ā besturingsstation voor bestellingen. Een systeem waarin KM's voor producten worden besteld.
EDO ā elektronische documentverwerking.
UKEP ā versterkte gekwalificeerde elektronische handtekening.
Terminologie en definities in het kader van dit artikel
CZ ā eerlijke markering.
LK ā persoonlijk account.
Merk ā afgedrukte code voor merkregistratie.
Het proces ziet er als volgt uit: eerst uitgever (UOT) genereert een elektronische handtekening (UKEP), registreert zich bij de eerlijke markering (CZ), beschrijft het product in de nationale catalogus of GS1, en ontvangt GTIN's voor het product. Deze stappen zijn gedetailleerd beschreven op de website van de eerlijke markering, dus daar gaan we niet verder op in.
Bestellen en ontvangen van codes
Na het ontvangen van de GTIN's plaatst de deelnemer (UOT) een bestelling voor codes (KM) in het SUZ-systeem.
Belangrijk, maar niet voor de hand liggend.
- In Ć©Ć©n bestelling kunnen maximaal 10 GTIN's worden aangevraagd. Dit is in wezen een onduidelijke beperking. Een importeur met 14.000 GTIN's moet 1.400 bestellingen plaatsen.
- In Ć©Ć©n bestelling kunnen maximaal 150.000 codes worden aangevraagd.
- Er is een limiet van 100 bestellingen in behandeling. Dit betekent dat er gelijktijdig niet meer dan 100 bestellingen verwerkt kunnen worden. Als er meer dan 100 zijn, zal de API een foutmelding beginnen te retourneren in plaats van een lijst met bestellingen. De enige manier om deze fout te verhelpen, is door een deel van de bestellingen via de webinterface te sluiten. De API heeft geen parameter voor het gedeeltelijk weergeven van bestellingen.
- Er is een limiet voor het aantal verzoeken - niet meer dan 10 verzoeken per seconde. Voor zover ik weet, wordt deze beperking niet genoemd in de documentatie, maar hij bestaat.
Uit persoonlijke ervaring met het verwerken van codebestellingen via de API van het Systeem voor de Identificatie van Zendingen (SUZ).
- Het verzoek (de json zelf) moet worden ondertekend met een GOST-handtekening. Dit betreft werken met cryptopro. Het is belangrijk om ervoor te zorgen dat het gebruikte framework of de bibliotheek de oorspronkelijke json niet met een byte verandert. Anders wordt de handtekening onmiddellijk ongeldig.
- Bestelling ondertekenen. Een bestelling kan met elke handtekening van elke klant worden ondertekend. Als de handtekening geldig is, zal het SUZ-systeem deze accepteren. Bij de integratie was het mogelijk om een verzoek te ondertekenen met de handtekening van een andere partij, uitgegeven door een testcertificeringsinstantie (UC). Het operationele SUZ-systeem heeft de bestelling verwerkt en codes vrijgegeven. Naar mijn mening is dit een beveiligingslek. De ontwikkelaars hebben op het bugrapport gereageerd met 'we zullen kijken'. Ik hoop dat ze dit hebben opgelost.
Wees daarom uiterst voorzichtig als er meer dan Ć©Ć©n rechtspersoon op dezelfde werkplek werkt. Vandaag accepteert SUZ deze verzoeken, maar morgen zal men de verzoeken opnieuw controleren en de helft van de codes intrekken vanwege een vreemde handtekening. En in principe zouden ze formeel gelijk hebben.
- Autonome ondertekening van bestellingen - deze functionaliteit is niet langer beschikbaar in SUZ. Voor de werking ervan was het vereist om het gesloten deel van de sleutel in de persoonlijke ruimte van de eerlijke handtekening te laden. Dit vormt een compromittering van de sleutel. En volgens de geldende wetgeving dient de eigenaar in het geval van compromittering van de versterkte gekwalificeerde elektronische handtekening zijn certificeringsinstantie (UC) te informeren en de EKP in te trekken. Als deze functionaliteit wordt teruggebracht, zorg er dan voor dat het gesloten deel van de sleutel de computer niet verlaat.
- In februari heeft het centrum voor de ontwikkeling van veelbelovende technologieĆ«n (Š¦Š ŠŠ¢) stilletjes een limiet ingesteld op het aantal verzoeken aan de API van SUZ. Niet meer dan Ć©Ć©n verzoek per seconde. Daarna werd deze limiet ook onverwacht en stilletjes opgeheven. Daarom raad ik aan om in het systeem de mogelijkheid in te bouwen om het aantal verzoeken aan de API van Š¦Š ŠŠ¢ te beperken voor het geval dit opnieuw gebeurt. Momenteel zijn er informatie over een limiet van 10 verzoeken per seconde.
- Eveneens in februari veranderde het gedrag van de API van SUZ aanzienlijk zonder waarschuwing. De API heeft een verzoek voor het ophalen van de status van bestellingen. In de status werden de buffers en hun toestand aangegeven. ĆĆ©n GTIN = Ć©Ć©n buffer. Ook werd aangegeven hoeveel codes beschikbaar waren om uit de buffer te halen. Op een mooie dag werd het aantal voor alle buffers -1. Het was nodig om via een aparte methode de toestand van elke buffer afzonderlijk te controleren. In plaats van Ć©Ć©n verzoek moest ik er elf doen.
Structuur van codes
Dus, de codes zijn besteld en gegenereerd. Ze kunnen via de API worden opgehaald in tekstformaat, als pdf-labels voor afdrukken en als csv-bestand met tekst.
Over de API is hierboven al geschreven. Wat betreft de andere twee methoden. Aanvankelijk stond SUZ alleen toe om de codes Ć©Ć©n keer op te halen. En als een pdf-bestand werd opgehaald, konden de codes in tekstformaat alleen worden verkregen door alle datamatrices uit de pdf opnieuw te scannen. Gelukkig is er de mogelijkheid toegevoegd om de codes meerdere keren op te halen, en dit probleem is opgelost. Binnen twee dagen zijn de codes nog steeds beschikbaar voor herhaalde downloads.
Als je het in csv-formaat ophaalt, open het dan nooit, onder geen enkele omstandigheid, in Excel. En geef niemand toestemming om dat te doen. In Excel is er een autosave-functie. Op het moment van opslaan kan Excel je codes op de meest onvoorspelbare manier wijzigen. Ik raad aan om notepad++ te gebruiken voor het bekijken van codes.
Als je het bestand uit SUZ in notepad++ opent, kun je regels van dit soort zien. De derde code is ongeldig (de scheidingstekens GS ontbreken).
Partners hebben codes aan ons doorgegeven voor de labeling van hun producten. Met het blote oog is te zien welke bestanden zijn aangemaakt met behulp van Excel ā tot 5% van de codes waren ongeldig.
Ik raad ten zeerste aan om te lezen over GS1. In de beschrijving van de standaard zijn er antwoorden op vele vragen over de formatie van DataMatrix.
De identificatiecode bestaat uit een GTIN en een serienummer. Volgens de GS1-norm komen hieraan de toepassingsidentificaties (TI) 01 en 21 overeen. Let op, de toepassingsidentificaties maken geen deel uit van de GTIN en het serienummer. Ze geven aan dat na de toepassingsidentificatie (TI) de GTIN of het serienummer volgt. Dit is vooral belangrijk bij het programmeren van kassasoftware. Voor het invullen van tag 1162 zijn precies de GTIN en het serienummer nodig, zonder toepassingsidentificaties.
Voor UTD (universelend transportdocument) en andere documenten is het daarentegen vaak nodig om de volledige vermelding met toepassingsidentificaties op te nemen.
In de GS1-norm is vastgelegd dat de GTIN een vaste lengte heeft van 14 cijfers en uitsluitend uit cijfers kan bestaan. Het serienummer heeft een variabele lengte en wordt beschreven op pagina 155 van de norm. Daar is ook een verwijzing naar een tabel met symbolen die in het serienummer kunnen voorkomen.
Aangezien het serienummer een variabele lengte heeft, geeft de GS-scheidingstekens het einde aan. In de ASCII-tabel heeft het de code 29. Zonder deze scheidingstekens begrijpt geen enkele software wanneer het serienummer eindigt en de andere gegevensgroepen starten.
Meer informatie over de markeercode (KM) kan worden gelezen in .
Voor schoenen is het serienummer vastgelegd op 13 cijfers, maar de grootte kan op elk moment worden gewijzigd. Voor andere productgroepen (PG) kan de lengte van het serienummer verschillen.
Generatie van DataMatrix
De volgende stap is het omzetten van gegevens naar de DataMatrix-code. In het besluit van de Russische regering 860 wordt een GOST genoemd, volgens welke de DataMatrix moet worden gevormd. Ook in het PPR 860 is het verplicht gebruik van toepassingsidentificaties vermeld. Let op, in de DataMatrix-norm bestaat het begrip 'toepassingsidentificaties' niet. Deze zijn alleen aanwezig in de GS-1 DataMatrix-norm. Het lijkt erop dat de PPR 860 impliciet verplicht om precies GS-1 DataMatrix te gebruiken. Gelukkig zijn de normen vergelijkbaar. Het belangrijkste verschil: in GS-1 DataMatrix moet het eerste symbool FNC1 zijn. Het GS-symbool mag niet op de eerste plaats in de DataMatrix staan, alleen FNC1.
FNC1 kan niet gewoon aan de string worden toegevoegd zoals GS. Dit moet worden toegevoegd door het programma dat de DataMatrix genereert. Op de resources van Alliance Fortis zijn verschillende , waarmee je de correctheid van de gegenereerde DataMatrix-codes kunt controleren.
Belangrijk. De app van het eerlijke teken accepteert ongeldige DataMatrix-codes. Zelfs QR-codes. Het feit dat het merk herkend werd en de productinformatie werd weergegeven, betekent niet dat de DataMatrix correct is gegenereerd. Zelfs bij het vervangen van de cryptotail herkende de CZ-app het merk en toonde de productgegevens.
Later heeft CZ , hoe je codes correct moet genereren. Vanwege het grote aantal codes met fouten erkenden zij de codes zonder FNC1 als geldig, maar zij raden toch aan om GS-1 DataMatrix te genereren.
Helaas kwam er een behoorlijk groot percentage van de datamatrijzen van partners met fouten aan. Dankzij de verduidelijkingen van CZ werd de vraag helemaal opgelost "Mag je dit product verkopen na 1 juli of niet?" Spoiler ā ja, dat mag.
Afdrukken
Let op de manier van afdrukken van de merken. Bij het afdrukken met een thermische printer vervaagt het merk snel, en dit product kan al niet meer verkocht worden. Een onleesbaar merk is een schending van de PPR 860. Dit leidt tot inbeslagname van het product, boetes en strafrechtelijke aansprakelijkheid.
Gebruik thermotransfer-afdrukken. In dit geval is het merk minder vatbaar voor vervaging. Ook het materiaal van het etiket beĆÆnvloedt hoe kwetsbaar het merk is voor mechanische schade. Als de code niet gelezen kan worden vanwege mechanische schade, is dit gelijk aan het ontbreken van het merk, met alle gevolgen van dien.
Kies een printer op basis van de verwachte afdrukvolume. Desktopprinters zijn niet ontworpen om 100.000 etiketten per dag af te drukken.
Stoppen en starten met afdrukken verhoogt de slijtage van de printer. Sommige programma's sturen de afdruktaken per Ć©Ć©n etiket. Het is beter om zulke programma's niet te gebruiken.
Documenten beheren
Nadat de merken zijn afgedrukt en geplakt, vinden alle verdere handelingen met hen plaats via documenten of het persoonlijke account van het eerlijke teken.
Bij het werken met een groot aantal codes kunnen xml-bestanden worden aangemaakt, waarin de vereiste codes staan, en deze bestanden kunnen worden geĆ¼pload via de API of de webinterface van het persoonlijke account.
Het XSD-schema kan worden gedownload in de sectie āhelpā in het persoonlijke account van CZ.
Let op de volgende punten.
- XSD-schema's in het persoonlijke account van CZ bevatten fouten in de validatie van het BTW-nummer en limieten op de lengte van de string. Pas nadat je de fouten hebt gecorrigeerd, kun je de schema's gebruiken. Gelukkig zijn de fouten duidelijk, dus het is niet moeilijk om ze op te lossen.
- Het schema bestaat meestal uit twee delen: een algemeen deel voor alle documenten en een specifiek deel voor een bepaald type. Het algemene schema wordt toegevoegd via import in het specifieke. Beide schema's zijn te vinden in de sectie hulp in het persoonlijk account van CHZ.
- De escaperegels voor KM verschillen van de algemeen aanvaarde voor XML, hierover staat iets in de officiƫle documentatie van CHZ, let daarop. Hier is op pagina 4 alle regels.
- Probeer niet om 150.000 codes in Ć©Ć©n bestand in omloop te brengen. Volgens ooggetuigen verlopen bestanden met meer dan 30.000 meestal...
- Een XML-bestand kan worden afgewezen met de foutmelding 'XML-validatiefout', maar vijf minuten later kan hetzelfde bestand zonder problemen worden geaccepteerd.
- Als er in het bestand al een code zit die in omloop is gebracht, dan zal het invoerbestand waarschijnlijk niet worden geaccepteerd.
- Verzend- en ontvangstdocumenten worden gebruikt als tijdelijke oplossing. Later is gepland om deze af te schaffen en over te stappen op UPD volgens PPR 860.
- De mythe over 60 dagen. Er gaat het gerucht dat niet ingevoerde codes na 60 dagen 'verlopen'. Dit is een mythe, de bron is onbekend. Codes 'vervallen' alleen als je ze niet binnen 60 dagen uit de SUZ hebt gehaald. De levensduur van de opgehaalde codes is onbeperkt.
Conclusie
Bij de ontwikkeling van mijn gratis applicatie voor het labelen BarCodesFX, werd oorspronkelijk integratie met de SUZ API gemaakt. Toen het eerlijke teken de logica van de API onverwacht voor de tweede keer veranderde, moest de integratie worden opgezegd. Ik hoop dat CHZ in de toekomst de ontwikkeling en de API kan stabiliseren, aangezien het voor een non-profitproduct erg kostbaar is om elke dag te controleren of er wijzigingen in de API zijn en deze snel aan te passen.
Bij de implementatie van de labeling, zorg ervoor dat je goed vertrouwd bent met de normatieve documentatie voor jouw productgroep TG, print de GS1-DataMatrix correct en wees voorbereid op onvoorziene wijzigingen van het eerlijke teken CHZ.
De Fort Alliance heeft een informatie-ruimte gecreƫerd (, op Telegram, seminars, webinars), waar je nuttige en actuele informatie over labeling in alle sectoren kunt vinden.
Bron: habr.com
