As of July 1, 2019, mandatory labeling was introduced for a group of goods in Russia. As of March 1, 2020, this law was supposed to cover footwear. Not everyone was able to prepare in time, and as a result, the launch was postponed to July 1. Lamoda was among those who managed to get ready.
Therefore, we want to share our experience with those who still need to label clothing, tires, perfume, etc. The article describes a number of industry standards, some regulatory documentation, and personal experience. It is primarily intended for integrators and developers who are just beginning to navigate this project.
Please note that the regulatory framework often changes, and the author does not have the capacity to continuously update the material. Thus, by the time you read this, some of the information may already be outdated.
The personal experience was gained by the author both within the framework of the Datamatrix project at Lamoda and while developing their own free labeling application, BarCodesFx.
As of July 1, 2019, the law on mandatory labeling is in effect in Russia. The law does not apply to all groups of goods, and the deadlines for mandatory labeling differ for various product groups. Currently, mandatory labeling applies to tobacco, furs, shoes, and medicines. Soon, it will also include tires, clothing, perfumes, and bicycles. Each group of goods is regulated by a separate government decree (PPR). Therefore, some statements that are correct for footwear may be incorrect for other groups of goods. However, we can hope that the technical aspects will not vary significantly for different product groups.
LabelingThe main idea of labeling is that each product unit is assigned a unique number. This number allows you to track the history of a specific product unit from the moment of production or import into the country until the moment of sale at the checkout. It sounds great, but it is extremely difficult to implement in practice. The concept is described in more detail on the official Honest Sign website.
Commonly Accepted Terms and Concepts
UOT — participant in the turnover of goods.
CRPT — center for the development of promising technologies. A private company, the only government contractor for the labeling project. Operates under a public-private partnership (PPP) scheme. Unfortunately, there is no information on other tender participants for the project or the tender itself.
TG — commodity group. Footwear, clothing, tires, etc.
GTIN — essentially, an article considering color and size. Issued in GS1 or the national catalog for each importer or manufacturer for their product. The producer or importer must describe this product in advance.
PPR — government decree of the Russian Federation. For footwear — 860.
KM — labeling code. A unique set of symbols assigned to a specific unit of goods. For footwear, it consists of GTIN, serial number, verification code, and crypto tail.
GS1 — an international organization issuing GTINs. Also, the creators of several labeling standards.
National Catalog — akin to GS1, developed by CRPT.
Crypto Tail — similar to a digital signature, confirming the legality of the KM. Must be on the data matrix of the label. Storage in text form is prohibited. After printing the label, it must be deleted according to the contract with CRPT. No cases of actual usage are known.
UZ — order management station. A system where KM codes for products are ordered.
EDI — electronic document management.
UKEP — enhanced qualified electronic signature.
Terms and concepts within the scope of this article
ChZ — honest marking.
LK — personal account.
Label — printed marking code.
The process looks as follows: first, the participant (UOT) issues an electronic signature (UKEP), registers in the honest marking (ChZ), describes the product in the national catalog or GS1, and obtains GTINs for the product. These steps are detailed on the honest marking website, so we will not dwell on them.
Ordering and receiving codes
After receiving GTINs, the participant (UOT) places an order for codes (KM) in the UZ system.
Important, but not obvious.
- In one order, a maximum of 10 GTIN codes can be requested. In principle, this is an unclear limitation. An importer with 14,000 GTINs has to make 1,400 orders.
- In one order, a maximum of 150,000 codes can be requested.
- There is a limit of 100 orders in progress, meaning no more than 100 orders can be processed simultaneously. If there are more than 100, the API will start returning an error instead of the order list. The only way to resolve this error is to close some orders through the web interface. There is no parameter in the API for partial display of orders.
- There is a limit on the number of requests — no more than 10 requests per second. According to my information, this limit is not mentioned in the documentation, but it exists.
From personal experience working with the marking code orders through the API of the SUZ system.
- The request (the JSON itself) needs to be signed with a GOST signature. This involves working with cryptography. It is essential to ensure that the framework or library used does not change the original JSON by even a byte. Otherwise, the signature will immediately become invalid.
- Order signature. An order can be signed by any signature from any client. If the signature is valid, the SUZ system will accept it. During integration, it was possible to sign a request with another person's signature issued by a test certification authority. The operational SUZ circuit processed the order and issued codes. In my opinion, this is a security loophole. The developers responded to the bug report with 'we'll take a look'. I hope it has been fixed.
Therefore, be extremely careful if more than one legal entity is working at the same workplace. Today, the SUZ will accept these requests, but tomorrow the requests will be rechecked, and half of the codes will be revoked due to a foreign signature. Formally, they will be right.
- Auto-signing of orders is a feature that is no longer available in the SUZ. It required uploading the private part of the key in the personal account of the honest mark. This constitutes a compromise of the key. According to current legislation, in case of a compromise of the enhanced qualified electronic signature, the owner must inform their certification authority (CA) and revoke the EQES. If this functionality is to be returned, make sure that the private part of the key does not leave the computer.
- In February, the Center for Development of Promising Technologies (CRPT) quietly imposed a limit on the number of requests to the SUZ API. No more than one request per second. Then, unexpectedly and silently, this restriction was lifted. Therefore, I recommend incorporating a system feature to limit the number of requests to the CRPT API in case of recurrence. Currently, there is information about a limit of 10 requests per second.
- Also in February, the behavior of the SUZ API changed significantly without warning. The API includes a request for the status of orders. The status indicated the buffers and their condition. One GTIN = one buffer. It also specified how many codes were available for retrieval from the buffer. One fine day, the quantity for all buffers became -1. It was necessary to poll each buffer separately through a different method. Instead of one request, it turned into eleven.
Code Structure
So, the codes have been ordered and generated. They can be retrieved via the API in text format, as PDF labels for printing, and as a CSV file with text.
The API has already been discussed above. Regarding the other two methods, initially the SUZ allowed codes to be retrieved only once. If a PDF file was retrieved, the codes in text format could only be obtained by rescanning all data matrices from the PDF. Fortunately, a feature to retrieve codes multiple times was added, resolving this issue. For two days, the codes remain available for re-download.
If you are retrieving in CSV format, never, under any circumstances, open it in Excel. And don’t allow anyone else to do so. Excel has an auto-save feature. At the moment of saving, Excel can unpredictably alter your codes. It is recommended to use Notepad++ for viewing the codes.
If you open a file from SUZ in Notepad++, you can see lines like this. The third code is invalid (it lacks GS delimiters).
Partners sent us codes for labeling their products. It is evident to the naked eye which files were generated using Excel — up to 5% of the codes were invalid.
I strongly recommend reading about GS1. The description of the standard provides answers to many questions regarding the formation of DataMatrix.
The identification code consists of the GTIN and the serial number. According to the GS1 standard, they correspond to application identifiers (AI) 01 and 21. Please note that application identifiers are not part of the GTIN and serial number. They indicate that following the application identifier (AI) is either the GTIN or the serial number. This is especially important when programming cash register software. To fill out tag 1162, you need the GTIN and serial number specifically, without the application identifiers.
For the Universal Transfer Document (UTD) and other documents, on the contrary, it is often necessary to have the complete entry with application identifiers.
The GS1 standard states that GTIN has a fixed length of 14 digits and can consist only of numbers. The serial number has a variable length and is described on page 155 of the standard. There is also a reference to a table with symbols that may appear in the serial number.
Since the serial number has a variable length, the GS separator indicates its end. Its code in the ASCII table is 29. Without this separator, no program will understand when the serial number ends and other data groups begin.
You can read more about the marking code (MC) in .
For footwear, the serial number is fixed at 13 digits, however, its size may change at any time. For other product groups (PG), the length of the serial number may vary.
DataMatrix Generation
The next step is to convert the data into a DataMatrix code. Government Decree 860 of the Russian Federation specifies the GOST according to which DataMatrix must be formed. It also mandates the use of application identifiers. Note that the DataMatrix standard does not include the concept of 'application identifiers.' They only exist in the GS-1 DataMatrix standard. Therefore, Decree 860 implicitly requires the use of GS-1 DataMatrix. Fortunately, the standards are similar. The main difference is that in GS-1 DataMatrix, the first character must be FNC1. The GS symbol must not be in the first position in DataMatrix, only FNC1.
FNC1 cannot simply be added to the string like GS. It must be added by the program generating the DataMatrix. Several resources from the Alliance Fort are available to check the correctness of generated DataMatrix codes. , which can be used to verify the correctness of generated DataMatrix codes.
It is important. The Honest Sign application accepts invalid DataMatrix codes, including QR codes. The fact that the brand was recognized and product information was displayed does not indicate that the DataMatrix is correctly formatted. Even when replacing the crypto tail, the Honest Sign application recognized the brand and displayed the product data.
Later, the Honest Sign released , on how to properly generate codes. Due to the large number of erroneous codes, they accepted codes without FNC1 as valid, but still recommend generating GS-1 DataMatrix.
Unfortunately, a significant percentage of DataMatrix codes from partners were received with errors. Thanks to explanations from the Honest Sign, the question of whether it is possible to sell such products after July 1 has been fully resolved. Spoiler — it is possible.
Printing
Pay attention to the method of printing labels. When printed with a thermal printer, the label fades quickly, and this product can no longer be sold. An unreadable label is a violation of PPR 860, which leads to product confiscation, fines, and criminal liability.
Use thermal transfer printing. This way, the label is less prone to fading. The durability of the label material also affects how susceptible the label is to mechanical damage. If the code is unreadable due to mechanical damage, this is equivalent to the absence of a label, with all the ensuing consequences.
Choose a printer based on the planned print volumes. Desktop printers are not designed to print 100,000 labels a day.
Stopping and starting printing increases printer wear. Some programs send print jobs one label at a time. It is better not to use such programs.
Document Management
Once the labels are printed and applied, all further operations with them occur through documents or the personal account of the Honest Sign.
When working with a large number of codes, you can create XML files containing the required codes and upload these files via API or the web interface of the personal account.
The XSD schema can be downloaded from the 'help' section in the Honest Sign personal account.
Please pay attention to the following points.
- XSD schemas in the Honest Sign personal account contain errors in the validation of TINs and string length restrictions. Only by correcting these errors can the schemas be used. Fortunately, the errors are obvious, so it’s not difficult to fix them.
- The schema typically consists of two parts — a common one for all document types and a separate one for a specific type. The common schema is added via import into the specific one. Both schemas are located in the help section of the personal account of the Identifier.
- The escaping rules for KM differ from the generally accepted ones for XML, as stated in the official documentation from the Identifier; please pay attention to this. Here is all the rules on page 4.
- You should not attempt to input 150,000 codes into circulation in a single file. According to eyewitnesses, files over 30,000 usually go through.
- An XML file can be rejected with the error 'XML validation error', and five minutes later, the same file can be accepted without issues.
- If a code that has already been put into circulation appears in the file, the input file will most likely be rejected.
- Shipping and acceptance documents are used as a temporary solution. They plan to abolish them in the future and switch to UPD according to the PPR 860.
- The myth about 60 days. There's a belief that codes not put into circulation 'burn out' after 60 days. This is a myth; the source is unknown. Codes only 'burn out' if you haven't retrieved them from the SUZ within 60 days. The lifespan of retrieved codes is not limited.
Conclusion
In developing my free BarCodesFX labeling application, integration with the SUZ API was originally made. When the Honest Sign unexpectedly changed the API logic for the second time, integration had to be abandoned. I hope that in the future, the Identifier will stabilize the development and API, as it's quite costly for me to check every day if there were any changes in the API for a non-commercial product and to promptly adapt.
When implementing labeling, carefully familiarize yourself with the regulatory documentation for your product group TG, print the GS1-DataMatrix correctly, and be prepared for any unforeseen changes from the Honest Sign Identifier.
The Fort Alliance has created an information space (, on Telegram, seminars, webinars), where you can find useful and relevant information on labeling across all industries.
Source: habr.com
