DataMatrix ou comment bien étiqueter les chaussures

Depuis le 1er juillet 2019, la Russie a mis en place l'obligation d'étiquetage pour certains groupes de produits. À partir du 1er mars 2020, les chaussures devaient également être concernées par cette loi. Toutefois, tout le monde n'a pas pu se préparer à temps, ce qui a entraîné un report de son application au 1er juillet. Lamoda fait partie de ceux qui étaient prêts.

Nous souhaitons donc partager notre expérience avec ceux qui doivent encore étiqueter des vêtements, des pneus, des parfums, etc. Cet article décrit une série de normes sectorielles, quelques documents réglementaires et notre expérience personnelle. Cet article est principalement destiné aux intégrateurs et aux développeurs qui vont aborder ce projet.

Veuillez noter que le cadre réglementaire change fréquemment, et l'auteur n'a pas les moyens de tenir à jour constamment le matériel. Par conséquent, au moment de la lecture, certaines informations peuvent déjà être obsolètes.

L'expérience personnelle de l'auteur a été acquise à la fois dans le cadre du projet Datamatrix chez Lamoda et lors du développement de sa propre application gratuite pour l'étiquetage BarCodesFx.

Depuis le 1er juillet 2019, une loi sur l'étiquetage obligatoire est en vigueur en Russie. Cette loi ne s'applique pas à tous les groupes de produits, et les délais d'entrée en vigueur de l'étiquetage obligatoire varient selon les groupes de produits. Actuellement, l'étiquetage obligatoire concerne le tabac, les fourrures, les chaussures et les médicaments. Dans un avenir proche, il sera étendu aux pneus, aux vêtements, aux parfums et aux vélos. Chaque groupe de produits est régi par un arrêté séparé du gouvernement (PRP). Par conséquent, certaines affirmations qui sont correctes pour les chaussures peuvent être incorrectes pour d'autres groupes de produits. Mais on peut espérer que l'élément technique ne variera pas beaucoup entre les différents groupes de produits.

ÉtiquetageL'idée principale de l'étiquetage est qu'un numéro individuel est attribué à chaque unité de produit. Ce numéro permet de suivre l'historique d'une unité de produit précise depuis sa fabrication ou son importation dans le pays jusqu'à son retrait à la caisse. Cela semble beau, mais en pratique, c'est extrêmement complexe à réaliser. Le concept est décrit plus en détail sur le site officiel du signe de bonne foi.

Termes et concepts acceptés

UOT — participant à la circulation des produits.
CRPT — centre de développement des technologies avancées. Entreprise privée, unique entrepreneur public pour le projet de marquage. Fonctionne selon un modèle de partenariat public-privé (PPP). Malheureusement, il n'y a pas d'informations sur d'autres participants à l'appel d'offres du projet, ni sur l'appel d'offres lui-même.
TG — groupe de produits. Chaussures, vêtements, pneus, etc.
GTIN — en essence, c'est un article prenant en compte la couleur et la taille. Délivré par GS1 ou le catalogue national pour chaque importateur ou producteur pour son produit. Au préalable, le producteur ou l'importateur doit décrire ce produit.
PPR — décret du gouvernement de la Fédération de Russie. Pour les chaussures — 860.
KM — code de marquage. Ensemble unique de symboles attribué à une unité de produit spécifique. Pour les chaussures, il se compose de GTIN, numéro de série, code de vérification et crypto-suffixe.
GS1 — organisation internationale délivrant les GTIN. Également rédacteurs de plusieurs normes de marquage.
Catalogue national — équivalent de GS1, développé par le CRPT.
Crypto-suffixe — équivalent d'une signature numérique, confirmant la légalité du KM. Doit obligatoirement être présent dans le data-matrix sur l'étiquette. Le stockage sous forme texte est interdit. Après l'impression de l'étiquette, il doit être supprimé conformément au contrat avec le CRPT. Aucun cas d'utilisation réelle n'est connu.
SUZ — station de gestion des commandes. Système où les KM pour les produits sont commandés.
EDO — gestion électronique des documents.
UKEP — signature électronique qualifiée renforcée.

Termes et concepts dans le cadre de cet article

CZ — marque honnête.
LK — espace personnel.
Marque — code de marquage imprimé.

Le processus se déroule comme suit : d'abord, le participant (UOT) émet une signature électronique (UKEP), s'inscrit à la marque honnête (CZ), décrit le produit dans le catalogue national ou GS1, obtient les GTIN pour le produit. Sur le site de la marque honnête, ces étapes sont décrites en détail, donc nous ne nous attarderons pas dessus.

Commande et réception des codes

Après avoir reçu les GTIN, le participant (UOT) passe une commande pour les codes (KM) dans le système SUZ.
Important, mais pas évident.

1. Dans une commande, vous pouvez demander des codes pour un maximum de 10 GTIN. En principe, c'est une restriction peu compréhensible. Un importateur avec 14 000 GTIN doit créer 1 400 commandes.
2. Dans une commande, il est possible de demander un maximum de 150 000 codes.
3. Il existe une limite de 100 commandes en traitement. Cela signifie qu'il ne peut y avoir plus de 100 commandes en cours à la fois. Si le nombre de commandes dépasse 100, l'API commencera à retourner une erreur au lieu de la liste des commandes. Le seul moyen de résoudre cette erreur est de fermer certaines commandes via l'interface web. L'API ne prévoit pas de paramètre pour une affichage partiel des commandes.
4. Il y a une limite sur le nombre d'appels - pas plus de 10 requêtes par seconde. D'après mes données, cette limite ne figure pas dans les documents, mais elle existe.

D'après mon expérience personnelle avec les commandes de codes de marquage KM via l'API du système SUZ.

1. La requête (le json lui-même) doit être signée avec une signature conforme aux normes GOST. C'est un travail avec Cryptopro. Il faut faire attention à ce que le cadre ou la bibliothèque utilisée ne modifie pas le json d'origine, sinon la signature deviendra immédiatement invalide.
2. Signature de la commande. Une commande peut être signée avec n'importe quelle signature, celle de n'importe quel client. Si la signature est valide, le système SUZ l'acceptera. Lors de l'intégration, il a été possible de signer la requête avec une signature étrangère, émise par une autorité de certification de test. Le circuit opérationnel du SUZ a traité la commande et émis les codes. À mon avis, c'est une faille de sécurité. Les développeurs ont réagi au bug report en disant « nous allons examiner cela ». J'espère qu'ils ont corrigé le problème.

   Soyez donc extrêmement vigilant si plus d'une entité légale travaille sur un même poste de travail. Aujourd'hui, le SUZ acceptera ces requêtes, demain les requêtes seront vérifiées et la moitié des codes seront rappelés en raison d'une signature étrangère. Et en principe, ils auront formellement raison.

3. L'auto-signature des commandes est une fonctionnalité qui n'est plus disponible dans le SUZ. Pour son fonctionnement, il était nécessaire de charger la partie privée de la clé dans le compte personnel du signe honnête. Cela constitue une compromission de la clé. Et selon la législation en vigueur, en cas de compromission de la signature électronique qualifiée renforcée, le propriétaire doit informer son autorité de certification (AC) et révoquer la QES. Si cette fonctionnalité devait être réintroduite, assurez-vous que la partie privée de la clé ne quitte pas l'ordinateur.
4. En février, le centre de développement des technologies prometteuses (ЦРПТ) a silencieusement introduit une restriction sur le nombre de requêtes à l'API SUZ. Pas plus d'une requête par seconde. Puis, de manière tout aussi inattendue et silencieuse, cette restriction a été levée. Par conséquent, je recommande d'inclure dans le système la possibilité de limiter le nombre de requêtes à l'API ЦРПТ en cas de récidive. Actuellement, il y a des informations sur la limite de 10 requêtes par seconde.
5. Également en février, le comportement de l'API SUZ a changé considérablement sans préavis. L'API comprend une requête pour obtenir le statut des commandes. Le statut indiquait les buffers et leur état. Un GTIN = un buffer. Il y avait aussi une indication du nombre de codes disponibles à obtenir à partir du buffer. Un jour, le nombre de tous les buffers est devenu -1. J'ai dû interroger l'état de chaque buffer séparément par un autre moyen. Au lieu d'une requête, il a fallu en faire onze.

Structure des codes

Ainsi, les codes ont été commandés et générés. Ils peuvent être récupérés via l'API sous forme de texte, en PDF comme étiquettes à imprimer et sous forme de fichier CSV avec le texte.

L'API a déjà été mentionnée ci-dessus. En ce qui concerne les deux autres façons. Initialement, le SUZ ne permettait de récupérer les codes qu'une seule fois. Et si un fichier PDF était récupéré, il était nécessaire de rescanner tous les datamatrix depuis le PDF pour obtenir les codes sous forme de texte. Heureusement, la possibilité de récupérer les codes plusieurs fois a été ajoutée, et ce problème a été résolu. Les codes restent disponibles pour un nouveau téléchargement pendant deux jours.

Si vous récupérez au format CSV, n'ouvrez jamais, en aucune circonstance, le fichier dans Excel. Et ne le permettez à personne. Excel a une fonction de sauvegarde automatique. Au moment de la sauvegarde, Excel peut modifier vos codes de manière imprévisible. Je recommande d'utiliser Notepad++ pour visualiser les codes.

Si vous ouvrez le fichier du SUZ dans Notepad++, vous pouvez voir des lignes de ce type. Le troisième code est invalide (il manque des séparateurs GS).

Les partenaires nous ont transmis des codes pour marquer leurs produits. À l'œil nu, on peut voir quels fichiers ont été générés avec Excel — jusqu'à 5 % des codes étaient invalides.

Je recommande vivement de lire sur les normes GS1. Dans la description de la norme, il y a des réponses à de nombreuses questions concernant la formation de DataMatrix.

Le code d'identification se compose du GTIN et du numéro de série. Selon la norme GS1, ils correspondent aux identifiants d'application (IA) 01 et 21. Notez que les identifiants d'application ne font pas partie du GTIN et du numéro de série. Ils indiquent que, après l'identifiant d'application (IA), se trouve le GTIN ou le numéro de série. Cela est particulièrement important lors de la programmation du logiciel de caisse. Pour remplir la balise 1162, il est nécessaire d'avoir le GTIN et le numéro de série, sans les identifiants d'application.

Pour l'UPD (document de transfert universel) et d'autres documents, en revanche, il est souvent nécessaire d'avoir l'enregistrement complet avec les identifiants d'application.

La norme GS1 stipule que le GTIN a une longueur fixe de 14 chiffres et ne peut être composé que de chiffres. Le numéro de série a une longueur variable et est décrit à la page 155 de la norme. Il y a aussi une référence à un tableau avec des symboles qui peuvent apparaître dans le numéro de série.

Étant donné que le numéro de série a une longueur variable, le séparateur GS indique sa fin. Dans la table ASCII, il a le code 29. Sans ce séparateur, aucun programme ne comprendra à quel moment le numéro de série s'est terminé et d'autres groupes de données ont commencé.

Pour plus de détails sur le code de marquage (CM), vous pouvez lire dans la documentation officielle.

Pour les chaussures, le numéro de série est fixé à 13 chiffres, cependant, sa taille peut être modifiée à tout moment. Pour d'autres groupes de produits (GP), la longueur du numéro de série peut différer.

Génération de DataMatrix

La prochaine étape est la conversion des données en code DataMatrix. Dans le décret du gouvernement russe 860, une norme est indiquée selon laquelle il est nécessaire de former DataMatrix. Le décret 860 précise également l'utilisation obligatoire des identifiants d'application. Notez qu'il n'existe pas de notion d'« identifiants d'application » dans la norme DataMatrix. Ils n'existent que dans la norme GS-1 DataMatrix. Ainsi, le décret 860 oblige implicitement à utiliser précisément GS-1 DataMatrix. Heureusement, les normes sont similaires. La principale différence : dans GS-1 DataMatrix, le premier symbole doit être FNC1. Le symbole GS ne doit pas être en première position dans DataMatrix, uniquement FNC1.

Le FNC1 ne peut pas simplement être ajouté à la chaîne comme GS. Il doit être ajouté par le programme qui génère le DataMatrix. Sur les ressources de l'Alliance Fortes, plusieurs applications mobiles, qui peuvent être utilisés pour vérifier la validité des codes DataMatrix générés.

Important. L'application Honest Sign accepte des DataMatrix non valides. Même des QR codes. Le fait que la marque ait été reconnue et que les informations sur le produit s'affichent ne signifie pas que le DataMatrix a été correctement généré. Même en remplaçant le crypto-suffixe, l'application CS a reconnu la marque et affiché les données du produit.

Plus tard, CS a publié une explication, sur la manière de générer correctement les codes. En raison du grand nombre de codes erronés, ils ont reconnu les codes sans FNC1 comme valides, mais recommandent néanmoins de générer des DataMatrix GS-1.

Malheureusement, un pourcentage relativement élevé de DataMatrix provenant de partenaires était erroné. Grâce aux explications fournies par CS, la question 'Peut-on vendre ce produit après le 1er juillet ou pas ?' a été complètement résolue. Spoiler : oui.

Impression

Faites attention à la manière d'imprimer les marques. Lors de l'impression avec une imprimante thermique, la marque s'estompe rapidement, et ce produit ne peut plus être vendu. Une marque illisible constitue une violation de la PPR 860. Ce qui peut entraîner le retrait du produit, des amendes et des poursuites pénales.

Utilisez l'impression par transfert thermique. Dans ce cas, la marque est moins sujette à l'estompage. L'état du matériel d'étiquette influence également la résistance de la marque aux dommages mécaniques. Si le code n'est pas lisible en raison de dommages mécaniques, cela équivaut à l'absence de marque, avec toutes les conséquences qui en découlent.

Choisissez une imprimante en fonction des volumes d'impression prévus. Les imprimantes de bureau ne sont pas conçues pour imprimer 100 000 étiquettes par jour.

L'arrêt et le démarrage de l'impression augmentent l'usure de l'imprimante. Certains programmes envoient des travaux d'impression étiquette par étiquette. Il vaut mieux ne pas utiliser de tels programmes.

Travail avec des documents

Après l'impression et le collage des marques, toutes les opérations ultérieures se font via des documents ou le tableau de bord de l’honest sign.

Lors du traitement d'un grand nombre de codes, il est possible de créer des fichiers XML contenant les codes requis et de télécharger ces fichiers via l'API ou l'interface web du tableau de bord.

Le schéma XSD peut être téléchargé dans la section 'aide' du tableau de bord CS.

Faites attention aux points suivants.

1. Les schémas XSD dans le tableau de bord CS contiennent des erreurs de validation pour le NIF et des limites sur la longueur des chaînes. Il est seulement possible d'utiliser les schémas après avoir corrigé les erreurs. Heureusement, les erreurs sont évidentes, donc ce n'est pas difficile à faire.
2. Le schéma se compose généralement de deux parties : une partie commune à tous les types de documents et une partie spécifique à un type particulier. Le schéma commun est ajouté par importation dans le schéma spécifique. Les deux schémas sont situés dans la section d'aide de votre compte personnel.
3. Les règles d'échappement pour la KM diffèrent de celles généralement acceptées pour XML, cela est précisé dans la documentation officielle de la CHZ, veuillez y prêter attention. Voici ici à la page 4 toutes les règles.
4. Il ne faut pas essayer d'introduire 150 000 codes en circulation avec un seul fichier. D'après des témoins, les fichiers de plus de 30 000 passent généralement.
5. Un fichier XML peut être refusé avec l'erreur “erreur de validation XML”, puis être accepté sans problème cinq minutes plus tard.
6. Si le fichier contient déjà un code introduit en circulation, le fichier d'entrée en circulation ne sera probablement pas accepté.
7. Les documents d'expédition et de réception sont utilisés comme solution temporaire. Dans un avenir proche, ils devraient être supprimés et remplacés par des UPD conformément au PPR 860.
8. Le mythe des 60 jours. Il est commun de penser que les codes non introduits en circulation « expirent » après 60 jours. C'est un mythe, la source est inconnue. Les codes « expirent » uniquement si vous ne les avez pas récupérés de la SUZ dans les 60 jours. La durée de vie des codes récupérés n'est pas limitée.

Conclusion

Lors de la conception de mon application gratuite de marquage BarCodesFX, une intégration avec l'API de la SUZ a été réalisée à l'origine. Lorsque le signe honnête a soudainement modifié la logique de fonctionnement de l'API pour la deuxième fois, il a fallu renoncer à l'intégration. J'espère que la CHZ réussira à stabiliser le développement et l'API à l'avenir, car il m'est très coûteux de vérifier chaque jour les éventuels changements dans l'API pour un produit non commercial et de le mettre à jour rapidement.

Lors de l'implémentation du marquage, veuillez vous familiariser attentivement avec la documentation réglementaire relative à votre groupe de produits TG, imprimer correctement le GS1-DataMatrix et être prêt à tout changement imprévu de la part du signe honnête CHZ.

L'alliance Fort a créé un espace d'information (wiki, chats sur Telegram, séminaires, webinaires) où vous pouvez trouver des informations utiles et à jour sur le marquage dans tous les secteurs.

Source : habr.com