A partir de 1º de julho de 2019, a Rússia introduziu a marcação obrigatória para um grupo de produtos. A partir de 1º de março de 2020, o calçado deveria estar incluído nesta lei. Nem todos conseguiram se preparar a tempo, e, como resultado, o lançamento foi adiado para 1º de julho. A Lamoda está entre aqueles que se prepararam.
Portanto, queremos compartilhar nossa experiência com aqueles que ainda precisam marcar roupas, pneus, perfumes, etc. O artigo descreve uma série de padrões da indústria, alguma documentação normativa e experiências pessoais. O artigo é destinado principalmente a integradores e desenvolvedores que ainda precisam entender este projeto.
Observe que a base normativa muda frequentemente e o autor não tem a capacidade de atualizar o material constantemente. Portanto, no momento da leitura, algumas informações podem já estar desatualizadas.
A experiência pessoal do autor foi adquirida tanto na execução do projeto Datamatrix na Lamoda, quanto no desenvolvimento de seu próprio aplicativo gratuito para marcação BarCodesFx.
A partir de 1º de julho de 2019, uma lei sobre a marcação obrigatória está em vigor na Rússia. A lei não se aplica a todos os grupos de produtos, e os prazos de implementação da marcação obrigatória para grupos de produtos variam. Atualmente, tabaco, peles, calçados e medicamentos estão sujeitos à marcação obrigatória. Em breve, isso será aplicado a pneus, roupas, perfumes e bicicletas. Cada grupo de produtos é regulamentado por uma resolução do governo específica (PPR). Portanto, algumas afirmações que são corretas para calçados podem ser incorretas para outros grupos de produtos. Mas podemos esperar que o componente técnico não varie muito entre os diferentes grupos de produtos.
MarcaçãoA ideia principal da marcação é atribuir um número único a cada item de produto. Com esse número, é possível rastrear a história de um item específico desde a produção ou importação para o país até a sua saída na caixa registradora. Parece bonito, mas na prática é extremamente difícil de realizar. O conceito é descrito em mais detalhes no site oficial do Selo Justo.
Termos e conceitos comuns
UOT — participante do comércio de produtos.
CRPT — centro de desenvolvimento de tecnologias avançadas. Empresa privada, único contratante público do projeto de rotulagem. Opera sob o esquema de parceria público-privada (PPP). Infelizmente, não há informações sobre outros participantes da licitação do projeto, assim como sobre a licitação em si.
TG — grupo de mercadorias. Calçados, roupas, pneus, etc.
GTIN — essencialmente, um artigo considerando cor e tamanho. Fornecido no GS1 ou no catálogo nacional para cada importador ou fabricante de seu produto. Inicialmente, o fabricante ou importador deve descrever este produto.
PPR — decreto do governo da RF. Para calçados — 860.
CM — código de rotulagem. Conjunto único de caracteres atribuído a uma unidade específica de mercadoria. Para calçados, é composto por GTIN, número de série, código de verificação e crypto-sufixo.
GS1 — organização internacional que emite GTINs. Também redatores de várias normas de rotulagem.
Catálogo Nacional — análogo ao GS1, desenvolvido pelo CRPT.
Crypto-sufixo — análogo à assinatura digital, que confirma a legalidade do CM. Deve estar obrigatoriamente no datamatrix da etiqueta. O armazenamento em formato texto é proibido. Após a impressão da etiqueta, deve ser removido conforme o contrato com o CRPT. Não há registro de sua utilização real.
SUZ — estação de gerenciamento de pedidos. Sistema no qual os CMs são solicitados para o produto.
EDO — troca eletrônica de documentos.
UKEP — assinatura eletrônica qualificada reforçada.
Termos e definições no âmbito deste artigo
CZ — sinal honesto.
LC — painel pessoal.
Etiqueta — código de rotulagem impresso.
O processo é o seguinte: inicialmente, o participante (UOT) emite uma assinatura eletrônica (UKEP), registra-se no sinal honesto (CZ), descreve o produto no catálogo nacional ou GS1, obtém GTINs para o produto. No site do sinal honesto, esses passos são detalhados, portanto, não vamos nos deter neles.
Pedido e recebimento de códigos
Após receber os GTINs, o participante (UOT) faz o pedido dos códigos (CM) no sistema SUZ.
Importante, mas não óbvio.
- Em um pedido, é possível solicitar códigos para no máximo 10 GTINs. De qualquer forma, uma limitação estranha. Um importador com 14.000 GTINs precisa criar 1.400 pedidos.
- Em um pedido, é possível solicitar no máximo 150.000 códigos.
- Há uma limitação de 100 pedidos em processamento. Ou seja, pode haver no máximo 100 pedidos sendo processados simultaneamente. Se houver mais de 100, a API começará a retornar um erro em vez da lista de pedidos. A única maneira de corrigir esse erro é fechar alguns pedidos através da interface web. Não há parâmetro na API para exibir pedidos parcialmente.
- Há um limite de solicitações — não mais que 10 requisições por segundo. Segundo a minha pesquisa, esse limite não está especificado nos documentos, mas ele existe.
Da minha experiência pessoal com os pedidos de códigos de marcação KM através da API do sistema SUZ.
- A solicitação (o próprio json) deve ser assinada com a assinatura conforme a norma GOST. Isso envolve trabalhar com criptografia. É importante garantir que o framework ou biblioteca utilizada não altere o json original nem em um byte. Caso contrário, a assinatura deixa de ser válida instantaneamente.
- Assinatura do pedido. O pedido pode ser assinado com qualquer assinatura de qualquer cliente. Se a assinatura for válida, o sistema SUZ a aceitará. Durante a integração, foi possível assinar uma solicitação com uma assinatura de terceiros, emitida por uma autoridade certificadora teste. O sistema operacional do SUZ processou o pedido e emitiu os códigos. Na minha opinião, isso é uma brecha de segurança. Os desenvolvedores responderam ao relatório de bug com "iremos verificar". Espero que tenham corrigido.
Portanto, tenha extrema cautela se mais de uma entidade jurídica estiver operando em um mesmo local de trabalho. Hoje o SUZ aceitará essas solicitações, mas amanhã as solicitações poderão ser reavaliadas e meia dúzia de códigos serão revogados devido a uma assinatura de outra parte. E, de forma geral, estarão formalmente corretos.
- A autoassinação de pedidos não está mais disponível no SUZ. Para sua operação, era necessário carregar a parte privada da chave na área pessoal do sinal honesto. Isso constitui uma comprometimento da chave. E, de acordo com a legislação vigente, em caso de comprometimento de uma assinatura eletrônica qualificada avançada, o proprietário deve informar sua autoridade certificadora (AC) e revogar a assinatura. Se essa funcionalidade for retomada, tenha cuidado para que a parte privada da chave não saia do computador.
- Em fevereiro, o Centro de Desenvolvimento de Tecnologias Emergentes (CDTE) impôs silenciosamente uma restrição no número de solicitações à API do SUZ. Não mais do que uma solicitação por segundo. Depois, de forma igualmente inesperada e silenciosa, essa restrição foi removida. Portanto, recomendo incorporar na sistema a possibilidade de limitar o número de solicitações à API do CDTE, caso isso ocorra novamente. Atualmente, há informações sobre o limite de 10 solicitações por segundo.
- Além disso, em fevereiro, o comportamento da API do SUZ mudou significativamente sem aviso prévio. A API possui uma solicitação para obter o status dos pedidos. No status eram indicados os buffers e seu estado. Um GTIN = um buffer. Também era especificado quantos códigos estavam disponíveis para retirada do buffer. Em um belo dia, a quantidade de todos os buffers se tornou -1. Foi necessário consultar o estado de cada buffer separadamente usando um método distinto. Em vez de uma solicitação, foram necessárias onze.
Estrutura dos códigos
Então, os códigos foram solicitados e gerados. Eles podem ser retirados através da API em formato de texto, em PDF como etiquetas para impressão e como arquivo CSV com o texto.
Sobre a API já foi mencionado acima. Quanto aos outros dois métodos, inicialmente, o SUZ permitia retirar os códigos apenas uma vez. E se um arquivo PDF fosse retirado, os códigos em formato de texto só poderiam ser obtidos reescaneando todos os datamatrix do PDF. Felizmente, foi adicionada a possibilidade de retirar os códigos várias vezes, e esse problema foi resolvido. Os códigos ainda estão disponíveis para download repetido por dois dias.
Se você retirar no formato CSV, nunca, sob nenhuma circunstância, abra-o no Excel. E não permita que ninguém faça isso. O Excel possui uma função de salvamento automático. No momento em que o arquivo é salvo, o Excel pode modificar seus códigos de maneira imprevisível. Recomendo usar o Notepad++ para visualizar os códigos.
Ao abrir o arquivo do SUZ no Notepad++, você pode ver linhas desse tipo. O terceiro código é inválido (ele não possui separadores GS).
Os parceiros nos enviaram códigos para a marcação de seus produtos. A olho nu, é visível quais arquivos foram gerados com o Excel - até 5% dos códigos estavam inválidos.
Recomendo fortemente a leitura sobre GS1. Na descrição do padrão, há respostas para muitas perguntas sobre a formação do DataMatrix.
O código de identificação consiste no GTIN e no número de série. De acordo com o padrão GS1, eles correspondem aos identificadores de aplicação (IA) 01 e 21. Note que os identificadores de aplicação não fazem parte do GTIN e do número de série. Eles indicam que, após o identificador de aplicação (IA), segue-se o GTIN ou o número de série. Isso é especialmente importante ao programar softwares de caixa. Para preencher a tag 1162, são necessários exatamente o GTIN e o número de série, sem os identificadores de aplicação.
Para o UPD (documento de transição universal) e outros documentos, pelo contrário, geralmente é necessário o registro completo com os identificadores de aplicação.
No padrão GS1, está estipulado que o GTIN tem um comprimento fixo de 14 dígitos e pode consistir apenas de números. O número de série tem um comprimento variável e está descrito na página 155 do padrão. Lá também há um link para uma tabela com os símbolos que podem aparecer no número de série.
Como o número de série tem um comprimento variável, o delimitador GS indica seu término. Na tabela ASCII, ele possui o código 29. Sem esse delimitador, nenhum programa entenderá em que momento o número de série terminou e outros grupos de dados começaram.
Leia mais sobre o código de marcação (CM) em .
Para calçados, o número de série é fixado em 13 dígitos; no entanto, seu tamanho pode ser alterado a qualquer momento. Para outros grupos de produtos (GP), o comprimento do número de série pode ser diferente.
Geração de DataMatrix
O próximo passo é a conversão dos dados em código DataMatrix. No decreto do governo da Federação Russa 860, está especificado o GOST, conforme o qual o DataMatrix deve ser formado. Também no PPR 860 é indicado o uso obrigatório dos identificadores de aplicação. Note que no padrão DataMatrix não existe o conceito de "identificadores de aplicação". Eles existem apenas no padrão GS-1 DataMatrix. Assim, o PPR 860 implicitamente obriga o uso do GS-1 DataMatrix. Felizmente, os padrões são semelhantes. A principal diferença: no GS-1 DataMatrix, o primeiro símbolo deve ser FNC1. O símbolo GS não deve estar na primeira posição do DataMatrix, apenas o FNC1.
O FNC1 não pode ser simplesmente adicionado à sequência como o GS. Ele deve ser adicionado pelo programa que gera o DataMatrix. Nos recursos da Aliança Fortes, estão disponíveis várias , que podem ser usadas para verificar a correção dos códigos DataMatrix gerados.
É importante. O aplicativo Honest Sign aceita DataMatrix inválidos. Até mesmo QR Codes. O fato de a marca ter sido reconhecida e a informação sobre o produto exibida não indica que o DataMatrix foi gerado corretamente. Mesmo com a substituição do cryptotail, o aplicativo CHZ reconheceu a marca e exibiu os dados do produto.
Mais tarde, o CHZ lançou , sobre como gerar códigos corretamente. Devido ao grande número de códigos com erros, eles reconheceram os códigos sem FNC1 como válidos, mas ainda assim recomendam gerar GS-1 DataMatrix.
Infelizmente, uma porcentagem considerável de DataMatrix dos parceiros apresentava erros. Graças às explicações do CHZ, a questão 'Pode-se comercializar tais produtos após 1º de julho ou não?' foi totalmente resolvida. Spoiler — é possível.
Impressão
Atenção no método de impressão das marcas. Ao imprimir em impressoras térmicas, a marca desbota rapidamente, e esse produto não pode mais ser vendido. Uma marca ilegível é uma violação da PPR 860. O que leva à apreensão do produto, multas e responsabilidade criminal.
Use impressão por transferência térmica. Nesse caso, a marca não estará tão sujeita ao desbotamento. O material do rótulo também influencia o quanto a marca está sujeita a danos mecânicos. Se o código não for legível devido a um dano mecânico, isso equivale à ausência da marca, com todas as consequências decorrentes.
Escolha a impressora de acordo com os volumes de impressão planejados. Impressoras de mesa não são feitas para imprimir 100.000 rótulos por dia.
Interrupções e reinícios da impressão aumentam o desgaste da impressora. Alguns programas enviam a tarefa de impressão etiqueta por etiqueta. É melhor não usar esses programas.
Trabalho com documentos
Após a impressão e colagem das marcas, todas as operações subsequentes com elas ocorrem através de documentos ou do painel pessoal do Honest Sign.
Ao trabalhar com uma grande quantidade de códigos, é possível criar arquivos xml com os códigos necessários e carregá-los através da API ou da interface web do painel pessoal.
O esquema XSD pode ser baixado na seção 'ajuda' na conta do CHZ.
Preste atenção nos seguintes pontos.
- Os esquemas XSD na conta do CHZ contêm erros na validação do CNPJ e limitações no comprimento da string. Somente corrigindo os erros é que se pode usar os esquemas. Felizmente, os erros são evidentes, portanto, não é difícil fazer isso.
- O esquema geralmente consiste em duas partes – uma geral para todos os tipos de documentos e outra específica para um tipo particular. O esquema geral é adicionado através da importação no específico. Ambos os esquemas estão localizados na seção de ajuda na área do cliente da ČZ.
- As regras de escape para KM diferem daquelas comumente aceitas para XML; isso está descrito na documentação oficial da ČZ, por favor, preste atenção a isso. Aqui está na página 4 todas as regras.
- Não deve haver uma tentativa de introduzir 150.000 códigos em circulação em um único arquivo. Pelos relatos, arquivos com mais de 30.000 geralmente são aceitos.
- Um arquivo XML pode ser recusado com o erro 'erro de validação XML', mas após cinco minutos, o mesmo arquivo pode ser aceito sem problemas.
- Se o arquivo contiver um código que já foi introduzido em circulação, é provável que o arquivo de entrada não seja aceito.
- Os documentos de envio e recebimento são usados como uma solução temporária. No futuro, planejam abolir isso e passar para UPD conforme PPR 860.
- O mito dos 60 dias. Há uma crença de que os códigos não introduzidos em circulação 'expiram' após 60 dias. Isso é um mito, a fonte é desconhecida. Os códigos 'expiram' apenas se você não os retirar do SUZ dentro de 60 dias. O prazo de validade dos códigos retirados não é limitado.
Conclusão
Ao desenvolver meu aplicativo gratuito para rotulagem BarCodesFX, a integração com a API do SUZ foi feita inicialmente. Quando o sinal honesto inesperadamente alterou a lógica de funcionamento da API pela segunda vez, foi necessário renunciar à integração. Espero que no futuro a ČZ consiga estabilizar o desenvolvimento e a API, pois para um produto não comercial é bastante oneroso verificar diariamente se houve alterações na API e atualizar rapidamente.
Ao implementar a rotulagem, familiarize-se cuidadosamente com a documentação normativa do seu grupo de mercadorias TG, imprima corretamente o GS1-DataMatrix e esteja preparado para quaisquer mudanças imprevistas por parte do sinal honesto ČZ.
A Aliança Fort criou um espaço informativo (, no Telegram, seminários, webinars), onde você pode encontrar informações úteis e atualizadas sobre rotulagem em todos os setores.
Fonte: habr.com
