Desde el 1 de julio de 2019, en Rusia se introdujo la obligatoriedad de etiquetar un grupo de productos. Desde el 1 de marzo de 2020, el calzado debía incluirse en esta ley. No todos lograron prepararse a tiempo y, como resultado, el lanzamiento se pospuso hasta el 1 de julio. Lamoda es una de las que se preparó a tiempo.
Por lo tanto, queremos compartir nuestra experiencia con aquellos que aún tienen que etiquetar ropa, neumáticos, perfumes, etc. El artículo describe una serie de estándares del sector, cierta documentación normativa y experiencias personales. Este artículo está destinado principalmente a integradores y desarrolladores que recién comienzan a familiarizarse con este proyecto.
Tenga en cuenta que la base normativa cambia con frecuencia, y el autor no tiene la capacidad de actualizar constantemente el material. Por lo tanto, para el momento de la lectura, parte de la información puede ya estar desactualizada.
La experiencia personal del autor se ha obtenido tanto en el marco del proyecto Datamatrix en Lamoda como en el desarrollo de su propia aplicación gratuita para etiquetar BarCodesFx.
Desde el 1 de julio de 2019, en Rusia está en vigor la ley de etiquetado obligatorio. La ley no se aplica a todos los grupos de productos, y los plazos de entrada en vigencia de la etiquetación obligatoria varían según el grupo de productos. Actualmente, el etiquetado obligatorio se aplica a tabacos, pieles, calzado y medicamentos. En breve se introducirá para neumáticos, ropa, perfumes y bicicletas. Cada grupo de productos está regulado por un decreto gubernamental diferente (PPR). Por lo tanto, algunas afirmaciones que son correctas para el calzado pueden ser incorrectas para otros grupos de productos. Sin embargo, se puede esperar que la parte técnica no varíe mucho entre los diferentes grupos de productos.
EtiquetadoLa idea principal del etiquetado es asignar un número único a cada unidad de producto. A través de este número, se puede rastrear la historia de una unidad específica de producto desde su producción o importación al país hasta su salida en la caja. Suena bien, pero en la práctica es extremadamente difícil de implementar. Más detalles sobre el concepto están disponibles en el sitio web oficial de la señal honesta.
Términos y conceptos aceptados
UOT — participante en el tráfico de productos.
CRPT — centro de desarrollo de tecnologías avanzadas. Empresa privada, único contratista gubernamental para el proyecto de etiquetado. Opera bajo un esquema de asociación público-privada (APP). La información sobre otros participantes de la licitación del proyecto, así como sobre la propia licitación, lamentablemente no está disponible.
TG — grupo de productos. Calzado, ropa, neumáticos, etc.
GTIN — en esencia, un artículo considerando color y tamaño. Se emite en GS1 o en el catálogo nacional para cada importador o fabricante de su producto. Previamente, el fabricante o el importador debe describir este producto.
PPR — decreto del gobierno de la Federación Rusa. Para calzado — 860.
KM — código de marcado. Conjunto único de símbolos asignados a una unidad específica de producto. Para calzado consiste en GTIN, número de serie, código de verificación y criptotag.
GS1 — organización internacional que emite GTINs. Además, es responsable de varios estándares de etiquetado.
Catálogo Nacional — análogo de GS1, desarrollado por el CRPT.
Criptotag — análogo de la firma digital, que confirma la legalidad del KM. Debe estar presente en el datamatriz de la etiqueta. El almacenamiento en formato de texto está prohibido. Después de imprimir la etiqueta, debe ser eliminado de acuerdo con el contrato con el CRPT. No se conoce ningún caso de uso real.
SUZ — estación de gestión de órdenes. Sistema donde se solicitan los KMs para el producto.
EDO — intercambio electrónico de documentos.
UKEP — firma electrónica calificada reforzada.
Términos y conceptos en el marco de este artículo
CZ — signo honesto.
LK — área personal.
Etiqueta — código de marcado impreso.
El proceso se ve de la siguiente manera: primero, el participante (UOT) emite una firma electrónica (UKEP), se registra en el signo honesto (CZ), describe el producto en el catálogo nacional o GS1, y recibe GTINs para el producto. En el sitio web del signo honesto, estos pasos están detallados, por lo que no nos detendremos en ellos.
Pedido y recepción de códigos
Después de recibir los GTINs, el participante (UOT) hace un pedido de códigos (KM) en el sistema SUZ.
Importante, pero no evidente.
- En un pedido se pueden solicitar códigos para un máximo de 10 GTINs. En principio, una restricción poco clara. Un importador con 14,000 GTINs tiene que crear 1,400 pedidos.
- En un pedido se pueden solicitar un máximo de 150,000 códigos.
- Hay un límite de 100 pedidos en proceso. Esto significa que simultáneamente no puede haber más de 100 pedidos en tratamiento. Si hay más de 100, la API comenzará a devolver un error en lugar de la lista de pedidos. La única forma de solucionar este error es cerrar algunos pedidos a través de la interfaz web. La API no tiene un parámetro para mostrar los pedidos parcialmente.
- Hay un límite en la cantidad de solicitudes: no más de 10 solicitudes por segundo. Según lo que sé, este límite no se menciona en la documentación, pero existe.
Desde mi experiencia personal en el manejo de pedidos de códigos de marcado KM a través de la API del sistema SUZ.
- La solicitud (el json mismo) debe firmarse con la firma de acuerdo a GOST. Esto implica trabajar con criptografía. Es necesario prestar atención para que el marco o biblioteca utilizada no altere ni un byte el json original. De lo contrario, la firma deja de ser válida inmediatamente.
- Firma del pedido. El pedido puede ser firmado con cualquier firma de cualquier cliente. Si la firma es válida, el sistema SUZ la aceptará. Durante la integración, se logró firmar la solicitud con una firma ajena, emitida por un centro de certificación de prueba. El entorno operativo del SUZ procesó el pedido y emitió los códigos. En mi opinión, esto es una brecha de seguridad. Los desarrolladores respondieron al informe de error con "lo revisaremos". Espero que lo hayan solucionado.
Por lo tanto, tengan mucho cuidado si en un mismo lugar de trabajo operan más de una entidad legal. Hoy, el SUZ aceptará estas solicitudes, y mañana revisarán las solicitudes y retirarán la mitad de los códigos debido a una firma ajena. Y, en principio, estarán formalmente en lo correcto.
- La autoposición de pedidos es una funcionalidad que ya no está disponible en el SUZ. Para su funcionamiento, era necesario cargar la parte privada de la clave en el área personal de Honest Sign. Esto compromete la clave. Según la legislación vigente, en caso de compromiso de una firma electrónica cualificada avanzada, el propietario debe informar a su centro de certificación (UC) y revocar la clave. Si esta funcionalidad se va a restaurar, asegúrate de que la parte privada de la clave no salga de la computadora.
- En febrero, el Centro de Desarrollo de Tecnologías Prometedoras (ЦРПТ) impuso en silencio una restricción en el número de solicitudes a la API de SUZ. No más de una solicitud por segundo. Luego, de manera igualmente inesperada y silenciosa, levantó esa restricción. Por lo tanto, recomiendo incluir en el sistema la capacidad de limitar el número de solicitudes a la API de ЦРПТ por si acaso se repite la situación. Actualmente hay información sobre un límite de 10 solicitudes por segundo.
- También en febrero, sin previo aviso, se modificó significativamente el comportamiento de la API de SUZ. En la API hay una solicitud para obtener el estado de los pedidos. En el estado se indicaban los búferes y su estado. Un GTIN = un búfer. Ahí también se indicaba cuántos códigos estaban disponibles para obtener del búfer. En un día cualquiera, la cantidad de todos los búferes se volvió -1. Tuve que consultar por separado el estado de cada búfer a través de otro método. En lugar de una solicitud, tuve que hacer once.
Estructura de los códigos
Así que los códigos han sido pedidos y generados. Se pueden recuperar a través de la API en formato de texto, en PDF como etiquetas para imprimir y como archivo CSV con el texto.
Ya se ha mencionado sobre la API anteriormente. En cuanto a los otros dos métodos. Inicialmente, SUZ permitía recuperar los códigos solo una vez. Y si se recuperaba un archivo PDF, solo se podía obtener los códigos en formato de texto volviendo a escanear todos los datamatrices del PDF. Afortunadamente, se añadió la posibilidad de recuperar los códigos varias veces, y este problema se resolvió. Durante dos días, los códigos siguen disponibles para su descarga repetida.
Si descargas en formato CSV, nunca, bajo ninguna circunstancia, lo abras en Excel. Y no se lo permitas a nadie. En Excel hay una función de auto-guardado. En el momento de guardar, Excel puede transformar tus códigos de la manera más impredecible. Recomiendo usar Notepad++ para ver los códigos.
Si abres el archivo de SUZ en Notepad++, puedes ver líneas de este tipo. El tercer código es no válido (le faltan los separadores GS).
Los socios nos enviaron códigos para marcar sus productos. A simple vista se puede ver qué archivos se formaron con Excel: hasta el 5% de los códigos eran no válidos.
Recomiendo encarecidamente leer sobre GS1. En la descripción del estándar hay respuestas a muchas preguntas sobre la formación de DataMatrix.
El código de identificación consiste en GTIN y un número de serie. Según el estándar GS1, les corresponden los identificadores de aplicación (IA) 01 y 21. Tenga en cuenta que los identificadores de aplicación no son parte del GTIN ni del número de serie. Indican que después del identificador de aplicación (IA) viene el GTIN o el número de serie. Esto es especialmente importante al programar software de caja. Para completar la etiqueta 1162 se necesitan precisamente el GTIN y el número de serie, sin los identificadores de aplicación.
Para el UPD (documento de transferencia universal) y otros documentos, por el contrario, a menudo se necesita la entrada completa con los identificadores de aplicación.
En el estándar GS1 se establece que el GTIN tiene una longitud fija de 14 caracteres y puede consistir únicamente en números. El número de serie tiene una longitud variable y se describe en la página 155 del estándar. Allí también hay un enlace a una tabla con símbolos que pueden aparecer en el número de serie.
Dado que el número de serie tiene una longitud variable, el delimitador GS indica su final. En la tabla ASCII tiene el código 29. Sin este delimitador, ningún programa podrá entender en qué momento terminó el número de serie y comenzaron otros grupos de datos.
Puede leer más sobre el código de marcado (CM) en .
Para el calzado, el número de serie está fijado en 13 caracteres, sin embargo, su tamaño puede cambiar en cualquier momento. Para otros grupos de productos (GP), la longitud del número de serie puede ser diferente.
Generación de DataMatrix
El siguiente paso es transformar los datos en un código DataMatrix. En la resolución del gobierno de la Federación Rusa 860 se indica la norma, según la cual es necesario formar DataMatrix. También en el PPR 860 se menciona el uso obligatorio de identificadores de aplicación. Tenga en cuenta que en el estándar DataMatrix no existe el concepto de "identificadores de aplicación". Solo están en el estándar GS-1 DataMatrix. Por lo tanto, el PPR 860 obliga implícitamente a utilizar precisamente GS-1 DataMatrix. Afortunadamente, los estándares son similares. La principal diferencia: en GS-1 DataMatrix, el primer símbolo debe ser FNC1. El símbolo GS no debe estar en la primera posición en DataMatrix, solo FNC1.
FNC1 no se puede simplemente agregar a la cadena como GS. Debe ser añadido por el programa que genera DataMatrix. En los recursos de la Alianza Fortes se han publicado varias , con las que se puede verificar la corrección de los códigos DataMatrix generados.
Es importante. La aplicación 'Znak' acepta DataMatrix no válidos. Incluso códigos QR. El hecho de que la marca haya sido reconocida y se haya mostrado información del producto no indica que el DataMatrix esté correctamente formado. Incluso al reemplazar el crypto-tail, la aplicación 'Znak' reconoció la marca y mostró los datos del producto.
Más tarde, 'Znak' publicó , sobre cómo generar códigos correctamente. Debido al gran número de códigos defectuosos, reconocieron como válidos los códigos sin FNC1, pero aún así recomiendan generar DataMatrix GS-1.
Lamentablemente, un porcentaje considerable de DataMatrix de socios llegaba con errores. Gracias a las aclaraciones de 'Znak', se resolvió completamente la cuestión de si se puede comerciar con este producto después del 1 de julio o no. Spoiler: sí se puede.
Impresión
Presta atención al método de impresión de las marcas. Al imprimir en una impresora térmica, la marca se desvanece rápidamente y este producto ya no se puede vender. Una marca ilegible es una violación de la normativa 860, lo que conlleva la retirada del producto, multas y responsabilidad penal.
Utiliza impresión por transferencia térmica. En este caso, la marca no está tan expuesta al desvanecimiento. También depende del material de la etiqueta qué tan propensa esté la marca a daños mecánicos. Si el código no se puede leer debido a daños mecánicos, es como si no hubiera marca, con todas las consecuencias derivadas.
Elige la impresora en función de los volúmenes de impresión previstos. Las impresoras de escritorio no están diseñadas para imprimir 100,000 etiquetas al día.
Los parones y el inicio de la impresión aumentan el desgaste de la impresora. Algunos programas envían trabajos de impresión uno por uno. Es mejor no utilizar dichos programas.
Trabajo con documentos
Después de que las marcas se imprimen y se pegan, todas las operaciones posteriores se realizan a través de documentos o del área personal de 'Znak'.
Al trabajar con un gran número de códigos, se pueden crear archivos XML con los códigos requeridos y cargar estos archivos a través de la API o la interfaz web del área personal.
El esquema XSD se puede descargar en la sección 'ayuda' en el área personal de 'Znak'.
Presta atención a los siguientes puntos.
- Los esquemas XSD en el área personal de 'Znak' contienen errores en la validación del NIF y restricciones en la longitud de la cadena. Solo corrigiendo los errores se pueden usar los esquemas. Afortunadamente, los errores son evidentes, por lo que no es complicado corregirlos.
- El esquema generalmente consta de dos partes: una común para todos los tipos de documentos y otra específica para un tipo concreto. El esquema común se agrega a través de la importación al específico. Ambos esquemas se encuentran en la sección de ayuda en el área personal del Cuerpo de Z.
- Las reglas de escape para el CM difieren de las generalmente aceptadas para XML, sobre esto está escrito en la documentación oficial del Cuerpo de Z, tenga en cuenta esto. Aquí está en la página 4 todas las reglas.
- No se debe intentar introducir 150,000 códigos en circulación en un solo archivo. Según testimonios, los archivos de más de 30,000 suelen pasar..
- El archivo XML puede ser rechazado con el error 'error de validación XML', y cinco minutos después el mismo archivo puede ser aceptado sin problemas.
- Si en el archivo aparece un código que ya ha sido introducido en circulación, es probable que el archivo de entrada no sea aceptado.
- Los documentos de envío y aceptación se utilizan como solución temporal. En el futuro, se planea abolirlos y pasar a UPD según PPR 860.
- El mito de los 60 días. Circula la opinión de que los códigos no introducidos en circulación 'caducan' después de 60 días. Este es un mito, la fuente es desconocida. Los códigos 'caducan' solo si no los has retirado del SUZ dentro de los 60 días. La vida útil de los códigos retirados no está limitada.
Conclusión
Al desarrollar mi aplicación gratuita para etiquetar BarCodesFX, inicialmente se hizo la integración con la API de SUZ. Cuando Honest Sign cambió inesperadamente la lógica de trabajo de la API por segunda vez, se tuvo que renunciar a la integración. Espero que, en el futuro, el Cuerpo de Z pueda estabilizar el desarrollo y la API, ya que para un producto no comercial me resulta muy costoso verificar todos los días si ha habido cambios en la API y tener que adaptarla rápidamente.
Al implementar la etiquetado, consulte detenidamente la documentación normativa para su grupo de productos TG, imprima correctamente el GS1-DataMatrix y esté preparado para cualquier cambio imprevisto por parte de Honest Sign del Cuerpo de Z.
La Alianza Fort creó un espacio informativo (, en Telegram, seminarios, webinars), donde puede encontrar información útil y actual sobre el etiquetado en todas las industrias.
Fuente: habr.com
