Standard configurations without unnecessary customization
ERP, Trade Management, Accounting, Small Business, and Retail already include labeling functionality. We configure and align processes while preserving configuration updateability.
We implement TS PIoT in 1C and Chestny Znak exchange turnkey: certified module migration, permit mode, and FFD 1.2 cash registers. Timelines are on markirovka.ru.
Our clients
We connect 1C to Chestny Znak: exchange with CRPT and SUD (OMSID, token), receipt of UTDs with codes via EDI (1C-EDI, Diadok, SBiS), sales at checkout with FFD 1.2, aggregation, returns, and write-offs. We work with standard configurations - ERP, Trade Management, Accounting, UNF, Retail: usually setup and process alignment are needed, not custom development. Statuses in 1C and GIS MT match at every step: the exchange log records duplicates, breaks, and "not your" codes before shipping and sale - the error is visible before it blocks the operation.
ERP, Trade Management, Accounting, Small Business, and Retail already include labeling functionality. We configure and align processes while preserving configuration updateability.
From issuance request in SIZ to withdrawal from circulation: Data Matrix printing, aggregation into boxes and pallets, receiving, sales, returns, and write-offs.
2D scanners, handheld terminals, label printers, and a cash register with FFD 1.2 work in one chain with 1C and OFD - with no gaps between warehouse and checkout.
The exchange log records duplicates, missing codes, and status mismatches. Problem codes are caught before they block a sale.
Labeling requires disciplined data: without a GTIN, HS code, and labeling group in the product card, the system will not accept codes. Before connecting exchange, we define scanning checkpoints (receiving, shipping, return) and perform an item master audit.
Marking groups, data exchange with CRPT and SUD, code printing and tracking, aggregation, commissioning, EDI, sales, returns, write-offs, and status checks. The setup covers the full code lifecycle - from emission order to withdrawal from circulation, so statuses in 1C and GIS MT match at every step.
Sales are blocked, the warehouse stops. We pull the codes from EDI and match them to the item master before the document is signed.
Shortages before signing are caught by the "Marking Code Check" report - the discrepancy never enters accounting.
CRPT returns an error. It is fixed by scanning at every stage and blocking manual entry of marking codes.
According to GIS MT, the product is still with the supplier or has already left circulation. The status is checked before shipping - automatically, not by eye.
A defect or return is not documented - the code no longer matches stock. We configure write-offs and returns through a correction invoice and a return receipt.
Incorrect OMSID or token. Checking the SUZ parameters and resending on schedule restores the exchange.
Almost all common failures come down to a gap between the physical event and how it is recorded in accounting - the 1C exchange log shows where the chain broke. A deep dive into marking rules and common mistakes is in the article Chestny Znak in 1C: how to work with codes without losing them.
TS PIoT (technical means for obtaining product information) is the new mandatory certified module at the cash register.
It performs permit-mode checks using Chestny Znak and GIS MT data to determine whether a specific marking code can be sold. Chestny Znak is not replaced; the verification method changes: instead of direct token-based API access (X-API-KEY), the cash register works through a single certified TS PIoT module. 1C has released updates for Retail, UT, and UNF for TS PIoT, but at scale and in nonstandard setups, the transition requires compatibility checks, configuration, and testing.
Ministry of Industry and Trade Order No. 2044 dated 25.04.2025 (registered
by the Ministry of Justice on 27.06.2025, No. 82740) and the decree
Government Decree No. 1944 dated 21.11.2023 on permit mode.
The deadlines for mandatory use and the end of direct token exchange have been postponed several times; check markirovka.ru for current dates.
A detailed breakdown of what it is and how the migration works is in the article TS PIoT: marking migration for retail and 1C.
We compare 1C releases, cash registers, OFD, and product groups against TS PIoT requirements and record what needs to be updated.
We install the certified TS PIoT module from the CRPT registry and connect it to cash registers and legal entities.
We update the configuration for permit mode, set up code checks, and configure exchange with GIS MT.
We test offline scenarios and errors on one group, then scale to all stores and cash registers with monitoring.
KKT vendors usually handle installation of the certified module on the cash register turnkey. The value and the risk lie in the 1C/ERP ↔ TS PIoT ↔ OFD ↔ WMS/PIM chain, so checks do not interrupt sales and accounting.
At scale, what matters is not a single cash register, but consistency across all locations, exchange load, and repeatable setup. Our focus is a single API for 200+ 1C:Retail systems.
Offline mode, blocking responses, status mismatches, returns, and write-offs. We design cash register and 1C behavior in advance, not after a failure occurs.
Turnkey TS PIoT
We will check the compatibility of your 1C configuration, cash registers, and OFD, plan the migration to the certified TS PIoT module, and roll it out across all stores. Write directly: clients@kt.team.
We discuss goals, product groups, the current 1C and EDI setup, and expected results.
Item master audit (GTIN, HS code, labeling groups) and scanning checkpoints: receiving, shipping, return.
Set up exchange with SUZ and EDI, pilot on one product group, then scale to the remaining groups and warehouses.
We train the team to work with codes, errors, and exchange statuses, and support the environment after launch.
Integration with Chestny Znak works when it does not require manual oversight.
We connect 1C to the labeling system and configure code exchange, aggregation, printing, and write-offs around your actual process.
Scanning at every stage and blocking manual entry of marking codes removes duplicates and mismatches, and automatic status checks show the problematic code before shipment.
Based on KT.Team integration practice: a single API for 200+ 1C:Retail systems and stabilizing the Track&Trace marking setup for FM Logistic.
The cost of a marking error is set out in the Administrative Offenses Code: circulation of unmarked goods - a fine for legal entities of 50,000-300,000 rubles with product confiscation (Part 2, Article 15.12 of the Code of Administrative Offenses of the CIS), failure to submit or inaccurate data in GIS MT - 50,000-100,000 rubles (Article 15.12.1 of the Code of Administrative Offenses of the CIS); for alcohol and tobacco, the fines are higher.
Proper exchange removes these risks through the process itself: codes are verified before the UTD is signed, and statuses are checked before shipping and sale.
FAQ
The timeline depends on how ready the setup is: if you already have an enhanced qualified signature, an EDI provider, and an account, and the item master is filled out, a standard setup takes days, not months. We finalize the exact plan after auditing the item master and processes. Is 1C configuration customization needed? Usually not. Standard 1C ERP, Trade Management (UT), Accounting, Small Business (UNF) and Retail editions already include marking functionality — configuration and process alignment are usually enough.
Customization is needed only for non-standard scenarios, and we implement it without breaking upgradability. What do you need from us to start? A Chestny Znak account, a qualified electronic signature (UKEP), an EDI operator, access to OMS/SUZ (OMSID and a token from GIS MT), an up-to-date 1C release, and filled-in GTIN, HS codes (TN VED) and marking groups.
The full readiness checklist is above on this page. The UTD is signed, but the marking codes are not entered in 1C - what should be done? In a configured setup, codes are pulled from EDI and matched to the item master, while shortages before signing are caught by the "Marking Code Check" report. If the document has already been signed, the break is visible in the exchange log - the chain can be restored from it. The register says "not your code" - why? According to GIS MT, the item is still registered with the supplier or has already left circulation.
The code status must be checked before shipment; in a properly configured setup, 1C does this automatically. How much does integration cost? We provide an estimate after assessment: the scope depends on the number of product groups, warehouses, and cash registers. We calculate the impact of changes, not just hours. Is TS PIoT needed if 1C already exchanges data with Chestny Znak? Yes. TS PIoT is a new mandatory certified module in the cash register that checks permit mode using Chestny Znak and GIS MT data.
It does not replace Chestny Znak: it is a single certified verification layer instead of direct token-based API calls. We check your 1C configuration for compatibility and set up the transition. From when is TS PIoT mandatory for 1C? The requirements are introduced by Ministry of Industry and Trade Order No. 2044 of 25.04.2025 and Government Decree No. 1944 of 21.11.2023 on permit mode.
According to industry publications, the requirement is counted from the end of 2025, and direct token-based exchange is planned to be shut down in 2026, but the deadlines have been postponed repeatedly - check the current dates on markirovka.ru. What does KT.Team handle for TS PIoT, and what does the cash register vendor handle? KKT vendors usually handle installation of the certified module on the cash register turnkey.
KT.Team is responsible for the surrounding integration: the 1C/ERP ↔ TS PIoT ↔ OFD ↔ WMS/PIM chain at scale, a large number of SKUs and stores, fault tolerance, and handling edge cases. The foundation is a case of a single API for 200+ 1C:Retail systems.
Consultation
We will review your 1C configuration, product groups, and EDI setup, show how exchange with CRPT and SIZ will work, and prepare a launch plan with stages and timelines. Write directly: clients@kt.team.
Testimonials
The KT.Team team is a mature development partner. The delivery process is very clearly organized, and the smooth collaboration within the engineering team deserves special mention. When the team sees that the development process needs fine-tuning, it does it. During discussions, the team digs into the essence of the tasks and seeks to understand the business context. The work is aimed not at formally fulfilling the specification but at solving the real problem. Thanks to strong engineering expertise and product thinking, the team can be trusted not only with implementation but also with the architecture of the entire system.
The Muztorg group of companies has been working successfully with the KT.Team team for more than two years. The high professionalism of our partners helps us a great deal, as does their ability to combine well-structured project management with minimal formal constraints. I would especially like to note the friendliness and openness of the KT.Team staff.
The best — both the developers and the management, and the owners are in a league of their own! What was done at Snow Queen would have taken other companies 10 times longer. And thank you for assessing development sensibly and not stretching out the timelines.
You set a high standard for working with contractors. After you, dealing with others leaves a feeling of falling short of expectations.
After several years of joint, productive work, I want to thank our colleagues at KT.Team. Together we have come a long way, solved thousands of tasks, survived 3 Black Fridays already, and developed and successfully launched several large projects estimated at more than 2,000 person-hours. Both I and the company's management are pleased with our collaboration.
Before KT we had another contractor — a large, well-known integrator — and every change was expensive and painful. We even considered abandoning Magento altogether! kt.team took on a huge amount of work. A great team!
Code of Administrative Offenses of the CIS, Article 15.12 "Production, introduction into circulation, or sale of goods without labeling"
- www.consultant.ru/document/cons_doc_LAW_34661/c8a8c13d283fa3416f79b91b3f36da068225c15b/ (checked on: 03/07/2026).
Code of Administrative Offenses of the CIS, Article 15.12.1 "Failure to submit information to the operator of the goods circulation monitoring GIS for goods subject to mandatory labeling"
- www.consultant.ru/document/cons_doc_LAW_34661/3312fbb50868eeb5b0a66db39b355958c676aeac/ (checked on: 03/07/2026).
of CIS dated 25.04.2025 No. 2044 (registered
by the Ministry of Justice on 27.06.2025, No. 82740) - alta.ru/tamdoc/25a02044 (verification date: 08.07.2026).
Operator of the Chestny Znak state labeling system, sections on permit mode and TS PIoT - markirovka.ru (verification date: 08.07.2026).