De la 1 iulie 2019, în Rusia a fost introdusă marcarea obligatorie pentru anumite grupuri de produse. De la 1 martie 2020, acest regulament ar fi trebuit să se aplice și încălțămintei. Nu toată lumea a reușit să se pregătească, iar lansarea a fost amânată până la 1 iulie. Lamoda este printre cei care s-au pregătit.
De aceea, dorim să împărtășim experiența noastră cu cei care urmează să marcheze îmbrăcămintea, anvelopele, parfumurile etc. Articolul descrie o serie de standarde industriale, o parte din documentația normativă și experiența personală. Articolul este destinat în principal integratorilor și dezvoltatorilor care urmează să se familiarizeze cu acest proiect.
Vă rugăm să rețineți că baza normativă se schimbă frecvent, iar autorul nu are posibilitatea de a actualiza constant materialul. Prin urmare, la momentul lecturii, o parte din informație poate fi deja învechită.
Experiența personală a fost obținută de autor atât în cadrul proiectului Datamatrix la Lamoda, cât și în dezvoltarea unei aplicații gratuite pentru marcarea BarCodesFx.
De la 1 iulie 2019, există o lege privind marcarea obligatorie în Rusia. Această lege nu se aplică tuturor grupurilor de produse, iar termenele de intrare în vigoare a marcării obligatorii pentru grupurile de produse variază. În prezent, marcarea obligatorie se aplică tutunului, blănurilor, încălțămintei și medicamentelor. În curând, va fi implementată pentru anvelope, îmbrăcăminte, parfumuri și biciclete. Fiecare grup de produse este reglementat de o hotărâre guvernamentală separată (PPR). Prin urmare, unele afirmații corecte pentru încălțăminte pot fi incorecte pentru alte grupuri de produse. Dar putem spera că componenta tehnică nu va varia semnificativ pentru diferite grupuri de produse.
MarcareaIdeea principală a marcării este că fiecărui produs îi este atribuit un număr unic. Prin acest număr, se poate urmări istoria unui anumit produs din momentul producției sau importului în țară până la momentul vânzării la casă. Sună frumos, dar în practică este extrem de dificil de realizat. Conceptul este descris mai detaliat pe site-ul oficial al semnului onest.
Termeni și concepte acceptate general
UOT — participant la circulația bunurilor.
CRPT — centru de dezvoltare a tehnologiilor promițătoare. Companie privată, singurul contractor guvernamental pentru proiectul de marcaj. Funcționează pe baza parteneriatului public-privat (PPP). Din păcate, nu există informații despre alți participanți la licitația proiectului, nici despre licitația în sine.
TG — grup de produse. Încălțăminte, îmbrăcăminte, anvelope etc.
GTIN — de fapt, un articol care ia în considerare culoarea și dimensiunea. Este emis de GS1 sau de catalogul național pentru fiecare importator sau producător pentru bunul său. Prealabil, producătorul sau importatorul trebuie să descrie acest bun.
PPR — hotărârea guvernului Federației Ruse. Pentru încălțăminte — 860.
KM — cod de marcaj. Un set unic de simboluri atribuit unei unități specifice de produs. Pentru încălțăminte constă din GTIN, numărul de serie, codul de verificare și cripto-urmă.
GS1 — organizație internațională care emite GTIN-uri. De asemenea, redactori ai unor standarde pentru marcaj.
Catalog național — analog cu GS1, dezvoltat de CRPT.
Crypto-urmă — analog cu semnătura digitală, care confirmă legalitatea KM. Trebuie să fie obligatoriu în matricea de date de pe marcă. Stocarea sa în format text este interzisă. După imprimarea mărcii, trebuie să fie șters conform contractului cu CRPT. Nu se cunoaște niciun caz de utilizare reală.
SUZ — stația de gestionare a comenzilor. Sistemul în care sunt comandate KM-urile pentru bunuri.
EDO — circulație electronică a documentelor.
UKEP — semnătură electronică calificată întărită.
Termeni și concepte în contextul acestui articol
ChZ — semnul onest.
LK — cabinet personal.
Marcă — codul de marcaj tipărit.
Procesul arată astfel: mai întâi, participantul (UOT) emite o semnătură electronică (UKEP), se înregistrează în semnul onest (ChZ), descrie bunul în catalogul național sau GS1, obține GTIN-uri pentru bun. Pe site-ul semnului onest, acești pași sunt descriși în detaliu, așa că nu ne vom lăsa asupra lor.
Comandarea și obținerea codurilor
După obținerea GTIN-urilor, participantul (UOT) face o comandă de coduri (KM) în sistemul SUZ.
Important, dar nu evident.
- Într-o comandă pot fi solicitate coduri pentru maximum 10 GTIN-uri. Este, în principiu, o limitare neclară. Importatorului cu 14 000 GTIN-uri îi este necesar să creeze 1400 de comenzi.
- Într-o comandă pot fi solicitate maximum 150 000 de coduri.
- Există o limită de 100 de comenzi în curs de lucru. Asta înseamnă că, simultan, pot fi procesate nu mai mult de 100 de comenzi. Dacă sunt mai mult de 100, API-ul va începe să returneze o eroare în loc de lista comenzilor. Singura modalitate de a remedia această eroare este să închideți o parte din comenzi prin interfața web. API-ul nu prevede un parametru pentru afișarea parțială a comenzilor.
- Există un limită de apeluri — nu mai mult de 10 cereri pe secundă. Din câte știu eu, această limită nu este menționată în documente, dar există.
Din experiența personală de lucru cu comenzile codurilor de marcaj KM prin API-ul sistemului SUZ.
- Cererea (json-ul propriu-zis) trebuie semnată cu o semnătură GOST. Aceasta este o muncă cu criptopro. Trebuie să urmăriți cu atenție ca framework-ul sau biblioteca utilizată să nu schimbe cu un byte json-ul inițial. Altfel, semnătura încetează să mai fie validă imediat.
- Semnătura comenzii. Comanda poate fi semnată cu orice semnătură, de orice client. Dacă semnătura este validă, atunci sistemul SUZ o va accepta. În timpul integrării, s-a reușit semnarea cererii cu semnătura altcuiva, emisă de un UCA de test. Circuitul de producție al SUZ-ului a procesat comanda și a eliberat codurile. În opinia mea, aceasta este o breșă de securitate. La raportul de eroare, dezvoltatorii au răspuns „vom verifica”. Sper că au remediat.
De aceea, fiți extrem de atenți dacă pe un singur loc de muncă activează mai mult de o persoană juridică. Astăzi SUZ va accepta aceste cereri, iar mâine cererile vor fi revizuite și se vor retrage jumătate din coduri din cauza semnăturii străine. Și, în principiu, formal vor avea dreptate.
- Semnarea automată a comenzilor — este o funcționalitate care nu mai este disponibilă în SUZ. Pentru funcționarea acesteia era necesar să încărcați partea privată a cheii în cabinetul personal al semnului de încredere. Aceasta reprezintă o compromitere a cheii. Și conform legislației în vigoare, în cazul compromiterii unei semnături electronice calificate avansate, proprietarul trebuie să informeze centrul său de certificare (UCA) și să revoce SEC. Dacă această funcționalitate va fi restituită, atunci urmăriți cu atenție ca partea privată a cheii să nu părăsească computerul.
- În februarie, Centrul de Dezvoltare a Tehnologiilor Perspectivă (CRTP) a introdus în tăcere o limită asupra numărului de cereri către API-ul SUZ. Nu mai mult de o cerere pe secundă. Apoi, la fel de neașteptat și în tăcere, a anulat această limită. Prin urmare, recomand să se includă în sistem posibilitatea de a limita numărul de cereri către API-ul CRTP în cazul unui recidiv. Acum, există informații despre o limită de 10 cereri pe secundă.
- De asemenea, în februarie, comportamentul API-ului SUZ s-a schimbat semnificativ fără avertisment. Există o cerere în API pentru obținerea statusului comenzilor. Statusul includea buffer-ele și starea acestora. Un GTIN = un buffer. De asemenea, se indica câte coduri sunt disponibile pentru a fi obținute din buffer. Într-o zi perfectă, numărul tuturor buffer-elor a devenit -1. A trebuit să interoghez starea fiecărui buffer printr-o metodă separată. În loc de o cerere, am fost nevoit să fac unsprezece.
Structura codurilor
Așadar, codurile sunt comandate și generate. Acestea pot fi obținute prin API în format text, în pdf ca etichete pentru imprimare și ca fișier csv cu text.
Despre API s-a scris deja mai sus. În ceea ce privește celelalte două metode. Inițial, SUZ permitea obținerea codurilor doar o singură dată. Și dacă se obținea un fișier pdf, codurile în format text puteau fi obținute doar prin rescanarea tuturor datamatrix-urilor din pdf. Din fericire, au adăugat posibilitatea de a obține codurile de mai multe ori, iar această problemă s-a rezolvat. În următoarele două zile, codurile sunt încă disponibile pentru descărcare repetată.
Dacă obțineți în format csv, atunci niciodată, în niciun caz, nu deschideți-l în Excel. Și nu permiteți altora să o facă. Excel are o funcție de salvare automată. În momentul salvării, Excel poate modifica codurile într-un mod total imprevizibil. Recomand să folosiți notepad++ pentru a vizualiza codurile.
Dacă deschideți fișierul din SUZ în notepad++, puteți vedea linii de acest fel. Al treilea cod este nevalid (nu are separatori GS).
Partenerii ne-au transmis coduri pentru marcarea produselor lor. Cu ochiul liber se poate observa ce fișiere au fost generate cu ajutorul Excel-ului — până la 5% din coduri erau nevalide.
Recomand cu tărie să citiți despre GS1. În descrierea standardului există răspunsuri la multe întrebări legate de generarea DataMatrix.
Codul de identificare este format din GTIN și numărul de serie. Conform standardului GS1, acestea corespund identificatorilor de aplicație (IA) 01 și 21. Rețineți că identificatorii de aplicație nu sunt parte din GTIN și numărul de serie. Ei indică faptul că după identificatorul de aplicație (IA) urmează GTIN sau numărul de serie. Acest lucru este deosebit de important când se programează software-ul de casă. Pentru completarea etichetei 1162 sunt necesare exact GTIN și numărul de serie, fără identificatorii de aplicație.
Pentru UPD (documentul de transfer universal) și alte documente, dimpotrivă, cel mai adesea este necesară înregistrarea completă cu identificatorii de aplicație.
În standardul GS1 este stipulat că GTIN are o lungime fixă de 14 caractere și poate consta doar din cifre. Numărul de serie are o lungime variabilă și este descris pe pagina 155 a standardului. Acolo este inclus și un link la un tabel cu simbolurile care pot apărea în numărul de serie.
Dat fiind că numărul de serie are o lungime variabilă, separatorul GS indică sfârșitul său. În tabelul ASCII are codul 29. Fără acest separator, niciun program nu va înțelege când s-a terminat numărul de serie și au început alte grupuri de date.
Pentru mai multe detalii despre codul de marcaj (CM), puteți citi în .
Pentru încălțăminte, numărul de serie este fixat la 13 caractere, însă dimensiunea acestuia poate fi schimbată în orice moment. Pentru alte grupuri de produse (GP), lungimea numărului de serie poate varia.
Generarea DataMatrix
Următorul pas este transformarea datelor în codul DataMatrix. În hotărârea Guvernului Federației Ruse 860 este specificat GOST, conform căruia este necesară formarea DataMatrix. De asemenea, în PPR 860 este menționată utilizarea obligatorie a identificatorilor de aplicație. Rețineți că în standardul DataMatrix nu există conceptul de „identificatori de aplicație”. Acestea există doar în standardul GS-1 DataMatrix. Așadar, PPR 860 obligă implicit utilizarea exclusiv a GS-1 DataMatrix. Din fericire, standardele sunt asemănătoare. Principala diferență: în GS-1 DataMatrix, primul simbol trebuie să fie FNC1. Simbolul GS nu trebuie să fie la prima poziție în DataMatrix, ci doar FNC1.
FNC1 nu poate fi pur și simplu adăugat în șir ca GS. Acesta trebuie să fie adăugat de programul care generează DataMatrix. Pe resursele Alianței Fortes sunt disponibile câteva , cu ajutorul cărora se poate verifica corectitudinea codurilor DataMatrix generate.
Este important. Aplicația 'semnul corect' acceptă DataMatrix nevalide. Chiar și codurile QR. Faptul că marca a fost recunoscută și informațiile despre produs au fost afișate nu este un indicator că DataMatrix a fost generat corect. Chiar și în cazul înlocuirii cozii criptografice, aplicația CЗ a recunoscut marca și a afișat datele despre produs.
Mai târziu, CЗ au publicat , despre cum să generați coduri corect. Din cauza numărului mare de coduri cu erori, au recunoscut codurile fără FNC1 ca fiind valide, dar, totuși, recomandă generarea GS-1 DataMatrix.
Din păcate, un procent destul de mare de DataMatrix de la parteneri a venit cu erori. Datorită explicațiilor de la CЗ, a fost complet rezolvată problema „Pot comercia cu acest produs după 1 iulie sau nu?”. Spoiler — se poate.
Tipărire
Acordați atenție modului în care sunt tipărite mărcile. La tipărirea pe imprimante termice, marca se decolorează rapid, iar acest produs nu mai poate fi vândut. O marcă ilizibilă este o încălcare a PPR 860, ceea ce duce la confiscarea produsului, amenzi și răspundere penală.
Utilizați tipărirea prin transfer termic. În acest caz, marca nu este expusă atât de mult decolorației. De asemenea, materialul etichetei influențează cât de mult este expusă marca la deteriorări mecanice. Dacă codul nu este citit din cauza deteriorării mecanice, aceasta este echivalentă cu absența mărcii, cu toate consecințele care decurg din aceasta.
Alegeți imprimanta în funcție de volumele planificate de tipărire. Imprimanteledesktop nu sunt concepute pentru a tipări 100.000 de etichete pe zi.
Oprirea și pornirea tipăririi cresc uzura imprimantei. Unele programe trimit sarcini de tipărire pe câte o etichetă. Este mai bine să nu folosiți astfel de programe.
Lucrul cu documentele
După ce mărcile sunt tipărite și aplicate, toate operațiunile ulterioare cu acestea au loc prin documente sau prin contul personal al semnului corect.
Când lucrați cu un număr mare de coduri, puteți crea fișiere XML care vor conține codurile necesare și le puteți încărca prin API sau prin interfața web a contului personal.
Schema XSD poate fi descărcată în secțiunea 'asistență' din contul personal al CЗ.
Acordați atenție următoarelor aspecte.
- Schemile XSD din contul personal al CЗ conțin erori în validarea INN și restricții privind lungimea șirului. Doar după corectarea erorilor puteți utiliza schemele. Din fericire, erorile sunt evidente, deci nu este greu de realizat.
- Schema constă cel mai adesea din două părți - una comună pentru toate tipurile de documente și alta specifică pentru un anumit tip. Schema comună este adăugată prin import în cea specifică. Ambele scheme sunt plasate în secțiunea de ajutor din contul utilizatorului al sistemului.
- Regulile de escapare pentru KM diferă de cele obișnuite pentru XML, acest lucru este menționat în documentația oficială a sistemului, vă rugăm să acordați atenție. Iată pe pagina 4 toate regulile.
- Nu ar trebui să încercați să introduceți 150.000 de coduri în circulație într-un singur fișier. Din spusele martorilor, fișierele mai mari de 30.000 trec, de obicei..
- Fișierul XML poate fi respins cu eroarea "eroare de validare XML", iar după cinci minute același fișier poate fi acceptat fără probleme.
- Dacă în fișier apare deja un cod introdus în circulație, este foarte probabil ca fișierul de introducere în circulație să nu fie acceptat.
- Documentele de livrare și primire sunt utilizate ca o soluție temporară. Mai departe, se planifică abolirea lor și trecerea la UPD conform PPR 860.
- Mitul despre 60 de zile. Există o opinie că codurile care nu sunt introduse în circulație „expiră” după 60 de zile. Acesta este un mit, sursa fiind necunoscută. Codurile „expiră” doar dacă nu au fost preluate din SUZ în termen de 60 de zile. Perioada de valabilitate a codurilor preluate nu este limitată.
Concluzie
În dezvoltarea aplicației mele gratuite pentru etichetarea BarCodesFX, inițial a fost realizată o integrare cu API-ul SUZ. Când sistemul onest a schimbat brusc logica de funcționare a API-ului pentru a doua oară, a trebuit să renunț la integrare. Sper că în continuare sistemul va reuși să stabilizeze dezvoltarea și API-ul, deoarece pentru un produs non-profit este foarte costisitor să verific zilnic dacă au fost schimbări în API și să fac modificări rapide.
La implementarea etichetării, familiarizați-vă cu documentația normativă pentru grupul dumneavoastră de produse TG, imprimați corect GS1-DataMatrix și fiți pregătiți pentru orice schimbări neprevăzute din partea sistemului onest.
Alianța Fort a creat un spațiu informațional (, în Telegram, seminarii, webinarii), unde puteți găsi informații utile și actuale despre etichetare în toate domeniile.
Sursa: habr.com
