1 alkaen Venäjällä on otettu käyttöön tavararyhmän pakollinen merkintä. 2019. maaliskuuta 1 alkaen kengät kuuluivat tämän lain piiriin. Kaikilla ei ollut aikaa valmistautua, ja sen seurauksena laukaisu siirrettiin heinäkuun 2020. Lamoda on yksi niistä, jotka onnistuivat.
Siksi haluamme jakaa kokemuksemme niiden kanssa, jotka eivät ole vielä merkitseneet vaatteita, renkaita, hajuvesiä jne. Artikkelissa kuvataan useita alan standardeja, joitain lakisääteisiä asiakirjoja ja henkilökohtaista kokemusta. Artikkeli on tarkoitettu ensisijaisesti integraattoreille ja kehittäjille, jotka eivät ole vielä ymmärtäneet tätä projektia.
Huomaa, että sääntelykehys muuttuu usein, eikä kirjoittajalla ole mahdollisuutta jatkuvasti päivittää materiaalia. Siksi osa tiedoista saattaa olla jo vanhentunutta lukuhetkellä.
Kirjoittaja sai henkilökohtaista kokemusta sekä Datamatrix-projektin puitteissa Lamodassa että oman ilmaisen BarCodesFx-merkintäsovelluksen kehittämisessä.
1 lähtien Venäjällä on ollut voimassa laki pakollisista merkinnöistä. Laki ei koske kaikkia tavararyhmiä, ja tuoteryhmien pakollisten merkintöjen voimaantulon ajankohta vaihtelee. Nyt tupakka, turkikset, kengät ja lääkkeet ovat pakollisia merkintöjä. Lähitulevaisuudessa otetaan käyttöön renkaat, vaatteet, hajuvedet ja polkupyörät. Kutakin tavararyhmää säännellään erillisellä hallituksen asetuksella (GPR). Siksi jotkut väittämät, jotka koskevat kenkiä, eivät välttämättä pidä paikkaansa muiden tuoteryhmien kohdalla. Mutta voimme toivoa, että tekninen komponentti ei vaihtele suuresti eri tuoteryhmien välillä.
merkkiMerkintöjen pääidea on, että jokaiselle tavarayksikölle on annettu yksilöllinen numero. Tällä numerolla voit seurata tietyn tavaran historiaa valmistus- tai maahantuontihetkestä kassalla tapahtuvaan hävittämiseen asti. Se kuulostaa hyvältä, mutta käytännössä se on erittäin vaikea toteuttaa. Konsepti on kuvattu tarkemmin rehellisen merkin virallisella verkkosivustolla.
Yleisiä termejä ja käsitteitä
UOT - tavaroiden kiertoon osallistuja.
CRPT on kehittyneen teknologian kehittämiskeskus. Yksityinen yritys, ainoa osavaltio. merkintäprojektin urakoitsija. Se toimii julkisen ja yksityisen sektorin kumppanuusjärjestelmän (PPP) puitteissa. Valitettavasti hankkeen muista tarjouskilpailuun osallistuneista ei ole tietoa, eikä myöskään itse tarjouskilpailusta.
TG - hyödykeryhmä. Kengät, vaatteet, renkaat jne.
GTIN - itse asiassa artikkeli, ottaen huomioon värin ja koon. Myönnetty GS1:ssä tai kansallisessa luettelossa kunkin tuotteensa maahantuojan tai valmistajan osalta. Valmistajan tai maahantuojan on ensin kuvattava tämä tuote.
PPR - Venäjän federaation hallituksen asetus. Kengät - 860.
KM - merkintäkoodi. Tietylle kohteelle määritetty yksilöllinen merkkijoukko. Kenkien osalta se koostuu GTIN:stä, sarjanumerosta, vahvistuskoodista ja salauspäästä.
GS1 on kansainvälinen organisaatio, joka myöntää GTIN-tunnuksia. Myös useiden merkintästandardien laatijat.
Kansallinen luettelo - CRPT:n kehittämä GS1:n analogi.
kryptotail - digitaalisen allekirjoituksen analogi, joka vahvistaa CM:n laillisuuden. Sen on oltava leiman datamatriisissa. Tallennus tekstimuodossa on kielletty. Tulostuksen jälkeen leima on poistettava CRPT:n kanssa tehdyn sopimuksen mukaisesti. Varsinaisia käyttötapauksia ei tunneta.
CPS - tilaustenhallintaasema. Järjestelmä, jossa KM:t tilataan tuotteelle.
EDO - sähköinen asiakirjojen hallinta.
UKEP — tehostettu hyväksytty sähköinen allekirjoitus.
Tämän artikkelin soveltamisalaan kuuluvat termit ja käsitteet
ChZ - rehellinen merkki.
LK - Henkilökohtainen alue.
Merkitse - painettu merkintäkoodi.
Prosessi on seuraava: ensin osallistuja (UOT) antaa sähköisen allekirjoituksen (ECES), rekisteröityy rehelliseen merkkiin (CHZ), kuvailee tuotetta kansallisessa luettelossa tai GS1:ssä ja vastaanottaa GTIN-tunnukset tuotteelle. Rehellisen merkin verkkosivustolla nämä vaiheet on kuvattu yksityiskohtaisesti, joten emme käsittele niitä.
Tilaus- ja vastaanottokoodit
Saatuaan GTIN-tunnukset osallistuja (UOT) tekee kooditilauksen (KM) CPS-järjestelmään.
Tärkeää, mutta ei ilmeistä.
- Voit pyytää koodeja enintään 10 GTIN:lle tilausta kohden. Periaatteessa käsittämätön rajoitus. Maahantuojan, jolla on 14 000 GTIN-numeroa, on luotava 1400 XNUMX tilausta.
- Yhdessä tilauksessa voidaan pyytää enintään 150 000 koodia.
- Työssä on 100 tilauksen raja. Eli enintään 100 tilausta voidaan käsitellä samanaikaisesti. Jos niitä on enemmän kuin 100, API alkaa palauttaa virheilmoituksen tilausluettelon sijaan. Ainoa tapa korjata tämä virhe on sulkea osa tilauksista verkkokäyttöliittymän kautta. API ei tarjoa parametria tilausten osittaiseen näyttämiseen.
- Pyyntöjen määrä on rajoitettu - enintään 10 pyyntöä sekunnissa. Tietojeni mukaan tämä rajoitus ei näy asiakirjoissa, mutta se on olemassa.
Henkilökohtaisesta kokemuksesta KM-merkintäkoodien tilauksista CMS-sovellusliittymän kautta.
- Pyyntö (itse json) on allekirjoitettava GOST-allekirjoituksella. Tämä on työtä kryptopron kanssa. Meidän on tarkkailtava huolellisesti, että käytetty kehys tai kirjasto ei muuta alkuperäistä json-tiedostoa yhdellä tavulla. Muussa tapauksessa allekirjoitus lakkaa olemasta voimassa välittömästi.
- Tilauksen allekirjoitus. Tilaus voidaan allekirjoittaa minkä tahansa asiakkaan allekirjoituksella. Jos allekirjoitus on kelvollinen, KMS-järjestelmä hyväksyy sen. Integraation aikana pyyntö oli mahdollista allekirjoittaa jonkun muun testivarmentajan allekirjoituksella. CPS:n taistelupiiri käsitteli käskyn ja julkaisi koodit. Minusta tämä on tietoturva-aukko. Kehittäjät reagoivat vikaraporttiin "nähdään". Toivottavasti se on korjattu.
Ole siis erittäin varovainen, jos yhdellä työpaikalla työskentelee useampi kuin yksi oikeushenkilö. kasvot. Tänään CPS hyväksyy nämä pyynnöt ja huomenna pyynnöt tarkistetaan uudelleen ja puolet koodeista poistetaan jonkun muun allekirjoituksen takia. Ja periaatteessa he ovat muodollisesti oikeassa.
- Tilausten automaattinen allekirjoitus ei ole enää käytettävissä sisällönhallintajärjestelmässä. Sen toimintaa varten vaadittiin avaimen yksityinen osa lataaminen rehellisen merkin henkilökohtaiselle tilille. Tämä on keskeinen kompromissi. Ja nykyisen lainsäädännön mukaan, jos tehostettu hyväksytty sähköinen allekirjoitus vaarantuu, omistajan on ilmoitettava asiasta varmennekeskukselleen (CA) ja peruutettava UKES. Jos tämä toiminto palautetaan, varmista huolellisesti, että avaimen yksityinen osa ei poistu tietokoneesta.
- Helmikuussa Center for the Development of Advanced Technologies (CRPT) asetti hiljaa rajoituksen KMS API:n pyyntöjen lukumäärälle. Enintään yksi pyyntö sekunnissa. Sitten hän yhtä odottamatta ja hiljaa poisti tämän rajoituksen. Siksi suosittelen, että järjestelmään otettaisiin mahdollisuus rajoittaa CRPT API:n pyyntöjen määrää uusiutuessa. Nyt on tietoa 10 pyynnön rajasta sekunnissa.
- Myös helmikuussa KMS API:n käyttäytyminen muuttui merkittävästi ilman varoitusta. API:lla on pyyntö saada tilausten tila. Tila ilmaisi puskurit ja niiden tilan. Yksi GTIN = yksi puskuri. Se osoitti myös, kuinka monta koodia puskurista on käytettävissä. Eräänä kauniina päivänä kaikkien puskureiden luku oli -1. Minun piti kysyä kunkin puskurin tila erikseen erillisellä menetelmällä. Yhden pyynnön sijasta minun piti tehdä yksitoista.
Koodien rakenne
Joten koodit tilataan ja luodaan. Ne voidaan poimia apin kautta tekstimuodossa, pdf-muodossa tarroina tulostettaviksi ja csv-tiedostona tekstineen.
API on jo kirjoitettu edellä. Mitä tulee kahteen muuhun tapaan. Aluksi CPS salli sinun poimia koodit vain kerran. Ja jos otettiin pdf-tiedosto, niin koodit oli mahdollista saada tekstimuodossa vain skannaamalla uudelleen kaikki datamatriisit pdf:stä. Onneksi he lisäsivät mahdollisuuden poimia koodeja useita kertoja, ja tämä ongelma ratkesi. Kahden päivän kuluessa koodit ovat edelleen ladattavissa uudelleen.
Jos poimit csv-muodossa, älä koskaan, missään olosuhteissa, avaa sitä excelissä. Ja älä anna kenenkään. Excelissä on automaattinen tallennusominaisuus. Tallennushetkellä Excel voi muokata koodejasi arvaamattomimmalla tavalla. Suosittelen käyttämään Notepad++:aa koodien katseluun.
Jos avaat tiedoston CMS:stä Notepad ++:ssa, näet tämän kaltaiset rivit. Kolmas koodi on virheellinen (sillä ei ole GS-erottimia).
Yhteistyökumppanit antoivat meille koodit tavaroidensa merkitsemiseen. Paljaalla silmällä voit nähdä, mitkä tiedostot on luotu Excelillä - jopa 5 % koodeista oli virheellisiä.
Suosittelen lukemaan aiheesta GS1. Standardin kuvaus sisältää vastaukset moniin DataMatrixin muodostusta koskeviin kysymyksiin.
Tunnistekoodi koostuu GTIN:stä ja sarjanumerosta. GS1-standardin mukaan ne vastaavat sovellustunnisteita (UI) 01 ja 21. Huomaa, että sovellustunnisteet eivät ole osa GTIN- ja sarjanumeroa. Ne osoittavat, että sovellustunnistetta (UI) seuraa GTIN tai sarjanumero. Tämä on erityisen tärkeää ohjelmoitaessa POS-ohjelmistoa. Tunnisteen 1162 täyttämiseen tarvitaan täsmälleen GTIN ja sarjanumero ilman sovellustunnisteita.
UTD (universal transfer document) ja muiden asiakirjojen osalta päinvastoin tarvitaan useimmiten täydellinen tietue sovellustunnisteineen.
GS1-standardin mukaan GTIN:n kiinteä pituus on 14 merkkiä ja se voi koostua vain numeroista. Sarjanumero on muuttuvapituinen ja se on kuvattu standardin sivulla 155. Siellä on myös linkki taulukkoon symboleilla, jotka löytyvät sarjanumerosta.
Koska sarjanumerolla on vaihteleva pituus, erotin GS osoittaa sen päättymisen. ASCII-taulukossa sen koodi on 29. Ilman tätä erotinta mikään ohjelma ei ymmärrä, missä vaiheessa sarjanumero päättyi ja muut tietoryhmät alkoivat.
Tarkemmat tiedot merkintäkoodista (KM) löydät osoitteesta .
Kenkien sarjanumero on kiinteä 13 merkkiä, mutta sen kokoa voidaan muuttaa milloin tahansa. Muissa tuoteryhmissä (TG) sarjanumeron pituus voi vaihdella.
DataMatrixin sukupolvi
Seuraava vaihe on muuntaa tiedot DataMatrix-koodiksi. Venäjän federaation hallituksen asetuksessa 860 määritellään GOST, jonka mukaan on tarpeen muodostaa DataMatrix. Lisäksi PPR 860 määrittää sovellustunnisteiden pakollisen käytön. Huomaa, että DataMatrix-standardissa ei ole käsitettä "sovellustunnisteet". Ne ovat vain GS-1 DataMatrix -standardissa. Osoittautuu, että PPR 860 edellyttää implisiittisesti GS-1 DataMatrixin käyttöä. Onneksi standardit ovat samanlaiset. Tärkein ero: GS-1 DataMatrixissa ensimmäisen merkin on oltava FNC1. GS-symbolin ei tarvitse olla ensin DataMatrixissa, vain FNC1.
FNC1:tä ei voi yksinkertaisesti ottaa ja lisätä riville GS:nä. DataMatrixin luovan ohjelman on lisättävä se. Useita , jolla voit tarkistaa luotujen DataMatrix-koodien oikeellisuuden.
Se on tärkeää. Rehellinen merkkisovellus hyväksyy virheellisen DataMatrixin. Jopa QR-koodit. Se, että tuotemerkki tunnistetaan ja tuotetiedot näytetään, ei tarkoita, että DataMatrix on muodostettu oikein. Vaikka kryptopyrstö vaihdettiin, CZ-sovellus tunnisti tuotemerkin ja näytti tiedot tuotteessa.
Myöhemmin CZ julkaistiin kuinka luodaan koodit oikein. Virhekoodien suuren määrän vuoksi he tunnistivat kelvollisiksi koodit ilman FNC1:tä, mutta suosittelevat kuitenkin GS-1 DataMatrixin generoimista.
Valitettavasti melko suuri osa kumppaneiden datamatriiseista sisälsi virheitä. CZ:n selvitysten ansiosta kysymys "Onko mahdollista käydä kauppaa tällaisella tuotteella 1. heinäkuuta jälkeen vai ei?" ratkesi täysin. Spoileri - voit.
painatus
Kiinnitä huomiota tapaan, jolla postimerkit tulostetaan. Lämpötulostimella painettaessa leima haalistuu nopeasti, eikä tuotetta voi enää myydä. Lukematon leima rikkoo PPR 860:ta. Tämä johtaa tavaroiden takavarikointiin, sakkoihin ja rikosoikeudelliseen vastuuseen.
Käytä lämpösiirtotulostusta. Tässä tapauksessa leima ei ole niin herkkä haalistumista. Tarramateriaali määrittää myös sen, kuinka herkkä merkki on mekaanisille vaurioille. Jos koodia ei voida lukea mekaanisten vaurioiden vuoksi, tämä merkitsee tuotemerkin puuttumista kaikista siitä aiheutuvista seurauksista.
Valitse tulostin suunnitelluista tulostusmääristä. Pöytätulostimia ei ole suunniteltu tulostamaan 100 000 tarraa päivässä.
Tulostuksen lopettaminen ja aloittaminen lisää tulostimen kulumista. Jotkut ohjelmat lähettävät tulostustyön yksi tarra kerrallaan. On parempi olla käyttämättä tällaisia ohjelmia.
Työskentele asiakirjojen kanssa
Kun postimerkit on painettu ja liimattu, kaikki muut toiminnot niillä tapahtuvat asiakirjojen tai henkilökohtaisen rehellisen merkinnän kautta.
Kun työskentelet suurella määrällä koodeja, voit luoda tarvittavat koodit sisältävät xml-tiedostoja ja ladata nämä tiedostot API:n tai henkilökohtaisen tilisi verkkokäyttöliittymän kautta.
XSD-skeema voidaan ladata LC CZ:n "ohje"-osiosta.
Kiinnitä huomiota seuraaviin kohtiin.
- LC CZ:n Xsd-skeemat sisältävät virheitä TIN-tarkistuksessa ja rajoituksia rivin pituudelle. Vain korjaamalla virheet voit käyttää kaavioita. Onneksi virheet ovat ilmeisiä, joten tämän tekeminen ei ole vaikeaa.
- Kaava koostuu useimmiten kahdesta osasta - yhteinen kaikille asiakirjoille ja erillinen tietylle tyypille. Yleinen skeema lisätään tuonnin kautta tiettyyn skeemaan. Molemmat mallit sijaitsevat LC ChZ:n ohjeosiossa.
- CM:n pakenemissäännöt eroavat XML:n yleisesti hyväksytyistä säännöistä, tämä on kirjoitettu CZ:n virallisessa dokumentaatiossa, kiinnitä tähän huomiota. Tässä sivulla 4 kaikki säännöt.
- Älä yritä syöttää 150 000 koodia kiertoon yhdessä tiedostossa. Silminnäkijöiden mukaan yli 30 000 tiedostoa menee yleensä läpi.
- Xml-tiedosto voidaan kääriä virheilmoituksella ”xml validation error”, ja viiden minuutin kuluttua sama tiedosto hyväksytään ilman ongelmia.
- Jos tiedosto sisältää koodin, joka on jo liikkeeseen laskettu, liikkeelle laskettua tiedostoa ei todennäköisesti hyväksytä.
- Lähetys- ja vastaanottoasiakirjoja käytetään väliaikaisena ratkaisuna. Jatkossa ne aikovat poistaa ne ja siirtyä UPD:hen PPR 860:n mukaisesti.
- Myytti 60 päivästä. On olemassa mielipide, että koodit, joita ei lasketa liikkeeseen, "palavat loppuun" 60 päivän kuluttua. Tämä on myytti, lähde tuntematon. Koodit "palavat loppuun" vain, jos et ole noutanut niitä CPS:ltä 60 päivän kuluessa. Kerättyjen koodien käyttöikää ei ole rajoitettu.
Johtopäätös
Kun kehitin ilmaista merkintäsovellustani BarCodesFX, integrointi KMS API:n kanssa tehtiin alun perin. Kun rehellinen merkki toisen kerran yllättäen muutti API:n logiikkaa, integraatio jouduttiin luopumaan. Toivon, että tulevaisuudessa CZ pystyy vakauttamaan kehityksen ja API:n, koska. ei-kaupallisen tuotteen osalta minun on erittäin kallista tarkistaa joka päivä, onko API:ssa tapahtunut muutoksia, ja tarkentaa sitä nopeasti.
Kun otat käyttöön merkinnän, lue huolellisesti TG-tuoteryhmäsi säädösdokumentaatio, tulosta GS1-DataMatrix oikein ja varaudu odottamattomiin muutoksiin reilusta CZ-merkistä.
Fort Alliance on luonut tietotilan (, sähke, seminaarit, webinaarit), josta löydät hyödyllistä ja ajantasaista tietoa merkinnöistä kaikilla toimialoilla.
Lähde: will.com