Desde o 1 de xullo de 2019, introduciuse en Rusia a etiquetaxe obrigatoria dun grupo de bens. A partir do 1 de marzo de 2020, os zapatos debían estar baixo esta lei. Non todos tiveron tempo para prepararse e, como resultado, o lanzamento aprazouse para o 1 de xullo. Lamoda está entre os que o fixeron.
Por iso, queremos compartir a nosa experiencia con aqueles que aínda teñen que etiquetar roupa, pneumáticos, perfumes, etc. O artigo describe unha serie de estándares da industria, algunha documentación regulamentaria e experiencia persoal. O artigo está destinado principalmente a integradores e desenvolvedores que aínda non comprenden este proxecto.
Teña en conta que a normativa cambia con frecuencia e que non é posible que o autor actualice continuamente o material. Polo tanto, no momento en que o leas, é posible que parte da información xa estea desactualizada.
O autor adquiriu experiencia persoal tanto como parte do traballo no proxecto Datamatrix en Lamoda, como ao desenvolver a súa propia aplicación gratuíta de etiquetaxe BarCodesFx.
Desde o 1 de xullo de 2019, unha lei sobre etiquetaxe obrigatoria está en vigor en Rusia. A lei non se aplica a todos os grupos de produtos, e as datas para a entrada en vigor da etiquetaxe obrigatoria para os grupos de produtos varían. Actualmente, o tabaco, os abrigos de pel, os zapatos e os medicamentos están suxeitos á etiquetaxe obrigatoria. Presentarase en breve para pneumáticos, roupa, perfumes e bicicletas. Cada grupo de bens está regulado por unha resolución gobernamental (GPR) separada. Polo tanto, algunhas afirmacións que son certas para os zapatos poden non ser certas para outros grupos de produtos. Pero podemos esperar que o compoñente técnico non varíe moito para os distintos grupos de produtos.
MarcadoA idea principal da etiquetaxe é que a cada unidade de bens se lle asigna un número individual. Usando este número, pode rastrexar o historial dun artigo específico de mercadorías desde o momento da produción ou importación ao país ata o momento da eliminación na caixa. Parece fermoso, pero na práctica é moi difícil de implementar.O concepto descríbese con máis detalle no sitio web oficial do sinal honesto.
Conceptos e termos comúns
UOT - Participante na circulación de mercadorías.
CRPT — Centro para o desenvolvemento de tecnoloxías prometedoras. Empresa privada, a única estatal contratista do proxecto de sinalización. Funciona baixo un esquema de colaboración público-privada (APP). Desafortunadamente, non hai información sobre outros participantes na licitación do proxecto, así como sobre a propia licitación.
TG - Grupo de produtos. Calzado, roupa, pneumáticos, etc.
GTIN - fundamentalmente, un artigo tendo en conta a cor e o tamaño. Emitido en GS1 ou no catálogo nacional de cada importador ou fabricante do seu produto. O fabricante ou importador debe primeiro describir o produto.
PPR - Decreto do Goberno da Federación Rusa. Para zapatos - 860.
КМ - código de marcación. Un conxunto único de caracteres asignados a un produto específico. Para os zapatos, consta dun GTIN, número de serie, código de verificación e cripto-cola.
GS1 é unha organización internacional que emite GTIN. Tamén son os compiladores dunha serie de normas de etiquetaxe.
Catálogo nacional - un análogo de GS1, desenvolvido por CRPT.
Cola criptográfica - un análogo dunha sinatura dixital que confirme a legalidade do CM. Debe estar na matriz de datos do selo. Prohíbese o almacenamento en forma de texto. Despois da impresión, os selos deben retirarse segundo o acordo co CRPT. Non se coñecen casos de uso real.
CPS - estación de xestión de pedidos. O sistema no que se solicitan os KM de mercadorías.
EDI - Xestión electrónica de documentos.
UKEP — Sinatura electrónica cualificada mellorada.
Termos e conceptos no ámbito deste artigo
ChZ - un sinal honesto.
ЛК - Área persoal.
Marcar - Código de marcado impreso.
O proceso é o seguinte: primeiro, o participante (UOT) emite unha sinatura electrónica (UKEP), rexístrase nunha marca honesta (CH), describe o produto no catálogo nacional ou GS1 e recibe os GTIN do produto. Estes pasos descríbense en detalle no sitio web de signos honestos, polo que non nos deteremos neles.
Pedido e recepción de códigos
Despois de recibir os GTIN, o participante (UOT) realiza un pedido de códigos (KM) no sistema CPS.
Importante, pero non obvio.
- Podes solicitar códigos para un máximo de 10 GTIN nun único pedido. En principio, unha limitación incomprensible. Un importador con 14 GTIN ten que crear 000 pedidos.
- Pódense solicitar un máximo de 150 códigos por pedido.
- Hai un límite de 100 pedidos en curso. É dicir, non se poden procesar máis de 100 pedidos ao mesmo tempo. Se hai máis de 100, a API comezará a devolver un erro en lugar dunha lista de pedidos. O único xeito de corrixir este erro é pechar algúns pedidos a través da interface web. A API non proporciona un parámetro para a visualización parcial de pedidos.
- Hai un límite no número de solicitudes: non máis de 10 solicitudes por segundo. Segundo a miña información, esta restrición non aparece nos documentos, pero existe.
Desde a experiencia persoal de traballo con pedidos de códigos de marcado KM a través da API do sistema CPS.
- A solicitude (o propio json) debe estar asinada cunha sinatura GOST. Isto está a traballar con cryptopro. Debes asegurarte coidadosamente de que o marco ou a biblioteca utilizada non cambia o json orixinal nin sequera nun byte. En caso contrario, a sinatura deixa de ser válida inmediatamente.
- Sinatura do pedido. O pedido pode ser asinado por calquera sinatura de calquera cliente. Se a sinatura é válida, o sistema CPS aceptaraa. Durante a integración, foi posible asinar a solicitude coa sinatura doutra persoa emitida na proba CA. O circuíto de combate do sistema de control procesou a orde e emitiu códigos. Na miña opinión, isto é un buraco de seguridade. Os desenvolvedores responderon ao informe de erro con "xa veremos". Espero que estea arranxado.
Polo tanto, teña moito coidado se máis dunha persoa xurídica traballa nun lugar de traballo. caras. Hoxe o CPS aceptará estas solicitudes e mañá volveranse comprobar as solicitudes e revogaranse a metade dos códigos debido á sinatura doutra persoa. E, en principio, formalmente terán razón.
- A sinatura automática de pedidos é unha función que xa non está dispoñible en KMS. Para que funcionase, foi necesario cargar a parte privada da chave na conta persoal do signo honesto. Este é un compromiso da clave. E segundo a lexislación vixente, no caso de comprometer unha sinatura electrónica cualificada mellorada, o titular deberá informar ao seu centro de certificación (CA) e revogar a ECEP. Se se devolve esta funcionalidade, teña coidado de asegurarse de que a parte privada da chave non saia do ordenador.
- En febreiro, o Centro para o Desenvolvemento de Tecnoloxías Avanzadas (CRPT) introduciu silenciosamente un límite no número de solicitudes á API de CPS. Non máis dunha solicitude por segundo. Entón, igual de inesperado e silenciosamente, levantou esta restrición. Polo tanto, recomendo que o sistema se integre coa capacidade de limitar o número de solicitudes á API CRPT en caso de recaída. Agora hai información sobre un límite de 10 solicitudes por segundo.
- Tamén en febreiro, o comportamento da API de CPS cambiou significativamente sen previo aviso. A API ten unha solicitude para obter o estado dos pedidos. O estado indicaba os buffers e o seu estado. Un GTIN = un buffer. Tamén indicou cantos códigos estaban dispoñibles para recibir do búfer. Un bo día, o número de todos os buffers converteuse en -1. Tiven que usar un método separado para consultar o estado de cada búfer por separado. En lugar dunha solicitude, tiven que facer once.
Estrutura do código
Entón, os códigos foron ordenados e xerados. Pódense obter a través da API en forma de texto, en pdf como etiquetas para imprimir e como ficheiro csv con texto.
A API xa foi escrita arriba. En canto aos outros dous métodos. Inicialmente, o sistema de control permitíache recoller códigos só unha vez. E se se tomou un ficheiro pdf, era posible obter os códigos en forma de texto só escaneando de novo todas as matrices de datos do pdf. Afortunadamente, engadiron a posibilidade de recoller códigos varias veces, e este problema resolveuse. Os códigos aínda están dispoñibles para volver descargar dentro de dous días.
Se o levas en formato csv, nunca, baixo ningunha circunstancia, o abras en Excel. E non deixes que ninguén. Excel ten unha función de gardado automático. No momento de gardar, Excel pode modificar os seus códigos das formas máis imprevisibles. Recomendo usar notepad++ para ver os códigos.
Se abres un ficheiro do CMS en notepad++, podes ver liñas coma esta. O terceiro código non é válido (non ten delimitadores GS).
Os nosos socios déronnos códigos para etiquetar os seus produtos. A simple vista pode ver que ficheiros se xeraron mediante Excel: ata o 5% dos códigos non eran válidos.
Recomendo encarecidamente ler sobre GS1. A descrición do estándar contén respostas a moitas preguntas relativas á formación de DataMatrix.
O código de identificación consta dun GTIN e un número de serie. Segundo o estándar GS1, estes corresponden aos identificadores de aplicación (AI) 01 e 21. Teña en conta que os identificadores de aplicación non forman parte do GTIN nin do número de serie. Indican que o identificador da aplicación (UI) vai seguido dun GTIN ou número de serie. Isto é especialmente importante cando se programa un software de caixa rexistradora. Para cubrir a etiqueta 1162, só precisa o GTIN e o número de serie, sen os identificadores da aplicación.
Para UTD (documento de transferencia universal) e outros documentos, pola contra, a maioría das veces necesita o rexistro completo cos identificadores da aplicación.
O estándar GS1 establece que o GTIN ten unha lonxitude fixa de 14 caracteres e só pode constar de números. O número de serie ten unha lonxitude variable e descríbese na páxina 155 da norma. Tamén hai unha ligazón a unha táboa con símbolos que poden aparecer no número de serie.
Dado que o número de serie ten unha lonxitude variable, o separador GS indica o final do número de serie. Na táboa ASCII ten o código 29. Sen este separador, ningún programa entenderá en que momento rematou o número de serie e comezaron outros grupos de datos.
Podes atopar máis detalles sobre o código de marcado (KM) en .
Para os zapatos, o número de serie está fixado en 13 caracteres, non obstante, o seu tamaño pódese cambiar en calquera momento. Para outros grupos de produtos (TG), a lonxitude do número de serie pode diferir.
Xeración DataMatrix
O seguinte paso é converter os datos en código DataMatrix. O Decreto 860 do goberno ruso especifica GOST, segundo o cal é necesario crear unha DataMatrix. Ademais, o PPR 860 especifica o uso obrigatorio dos identificadores de aplicacións. Teña en conta que o estándar DataMatrix non ten o concepto de "identificadores de aplicación". Só están dispoñibles no estándar GS-1 DataMatrix. Resulta que o PPR 860 obriga implícitamente ao uso de GS-1 DataMatrix. Afortunadamente, os estándares son similares. Diferenza clave: en GS-1 DataMatrix, o primeiro carácter debe ser FNC1. O símbolo GS non debe aparecer primeiro no DataMatrix, só FNC1.
FNC1 non se pode engadir á liña como GS. Debe ser engadido polo programa que xera o DataMatrix. Hai varios publicados nos recursos de Alliance Forts , co que pode comprobar a corrección dos códigos DataMatrix xerados.
É importante. A aplicación de signo honesto acepta unha DataMatrix non válida. Incluso códigos QR. O feito de que a marca fose recoñecida e que se mostrase a información do produto non indica que o DataMatrix estea formado correctamente. Mesmo cando se substituíu a cola criptográfica, a aplicación ChZ recoñeceu a marca e mostrou datos sobre o produto.
Máis tarde lanzouse ChZ , como xerar códigos correctamente. Debido á gran cantidade de códigos con erros, recoñeceron que os códigos sen FNC1 eran válidos, pero aínda así recomendaron xerar un DataMatrix GS-1.
Desafortunadamente, unha porcentaxe bastante grande das matrices de datos dos socios presentaban erros. Grazas ás explicacións de ChZ, a pregunta "É posible intercambiar un produto deste tipo despois do 1 de xullo ou non?" foi completamente resolta. Spoiler - podes.
impresión
Preste atención á forma en que se imprimen os selos. Cando se imprime nunha impresora térmica, o selo desaparece rapidamente e o produto xa non se pode vender. Un selo ilexible é unha violación do PPR 860. Isto leva á incautación de bens, multas e responsabilidade penal.
Use impresión por transferencia térmica. Neste caso, a marca non é tan susceptible ao esvaecemento. O material da etiqueta tamén determina como é susceptible a marca a sufrir danos mecánicos. Se o código non se pode ler debido a un dano mecánico, isto equivale á ausencia dunha marca con todas as consecuencias derivadas.
Seleccione unha impresora dos seus volumes de impresión planificados. As impresoras de escritorio non están deseñadas para imprimir 100 etiquetas ao día.
Parar e iniciar a impresión aumenta o desgaste da impresora. Algúns programas envían un traballo de impresión unha etiqueta á vez. É mellor non usar estes programas.
Traballar con documentos
Despois de imprimir e pegar os selos, todas as transaccións posteriores con eles realízanse mediante documentos ou a conta persoal do sinal honesto.
Cando traballas cun gran número de códigos, podes crear ficheiros xml que conteñan os códigos necesarios e cargalos mediante a API ou a interface web da túa conta persoal.
O esquema XSD pódese descargar na sección "axuda" do ChZ LC.
Teña en conta os seguintes puntos.
- Os esquemas Xsd en LC ChZ conteñen erros na validación TIN e restricións na lonxitude da liña. Só despois de corrixir os erros pode usar os diagramas. Afortunadamente, os erros son obvios, polo que non é difícil facelo.
- A maioría das veces, o esquema consta de dúas partes: comúns para todos os tipos de documentos e separadas para un tipo específico. O esquema xeral engádese mediante importación ao específico. Ambos os diagramas están publicados na sección de axuda do ChZ LC.
- As regras de escape para CM difiren das xeralmente aceptadas para XML, isto está escrito na documentación oficial de ChZ, preste atención a isto. Aquí Todas as regras están na páxina 4.
- Non debe tentar introducir 150 códigos en circulación nun ficheiro. Segundo testemuñas presenciais, adoitan pasarse arquivos de máis de 000.
- Un ficheiro XML pódese envolver co erro "erro de validación xml" e cinco minutos despois pódese aceptar o mesmo ficheiro sen problemas.
- Se o ficheiro contén un código que xa se puxo en circulación, o ficheiro posto en circulación probablemente non será aceptado.
- Os documentos de envío e recepción úsanse como solución temporal. No futuro, planean abolilos e cambiar a UPD de acordo co PPR 860.
- O mito sobre 60 días. Hai unha opinión de que os códigos que non se poñen en circulación "queiman" despois de 60 días. Este é un mito, fonte descoñecida. Os códigos só caducan se non os recolleu do sistema de control nun prazo de 60 días. A vida útil dos códigos recollidos é ilimitada.
Conclusión
Ao desenvolver a miña aplicación gratuíta de etiquetaxe BarCodesFX, realizouse inicialmente a integración coa API de CPS. Cando un sinal honesto cambiou inesperadamente a lóxica da API por segunda vez, tivo que abandonar a integración. Espero que no futuro ChZ poida estabilizar o desenvolvemento e a API, porque Para un produto non comercial, é moi caro para min comprobar todos os días se houbo cambios na API e mellorala rapidamente.
Ao implementar marcas, lea atentamente a documentación regulamentaria do seu grupo de produtos TG, imprima GS1-DataMatrix correctamente e prepárese para calquera cambio imprevisto por parte da marca ChZ honesta.
The Fort Alliance creou un espazo de información (, en telegram, seminarios, seminarios web), onde podes atopar información útil e relevante sobre etiquetaxe en todas as industrias.
Fonte: www.habr.com