POS Register and 1С: Why It "Can't See" the Device and Receipts Aren't Fiscalized

"Error determining available cash registers", the register disappeared after a configuration update, a receipt with marked goods won't print due to tag 1162 — almost all complaints about the 1С↔POS integration come down to a break at the exact same point in the chain: configuration → driver → equipment profile → workplace. Let's analyze where it breaks and how to fix it.

1. How the integration between 1С and a physical cash register works#

1. 1С configuration (Retail, Trade Management, Accounting with commercial equipment) contains the "Peripherals" catalog — where the physical cash register is registered as an object and linked to a specific workstation.
2. Vendor driver (ATOL DTO, SHTRIH-M equivalent, etc.) is a component that 1С calls for actual data exchange with the cash register via port/USB; 1С itself does not communicate directly with the fiscal recorder.
3. 1С processing module — code inside the configuration that knows which receipt details to pass to the driver (including FFD tags, marking codes). The driver and processing module must be updated synchronously — updating them separately is a common source of failures (see the driver test procedure in the article about ATOL cash register errors, §3).

A break at any of these three levels produces different symptoms — we will examine each of them separately.

2. "Error determining available CRE cash registers" (Retail/UT)#

Check in order from top to bottom — the first two points resolve most requests without involving an engineer.

3. "CRE device ID is not filled in"#

The factory serial number of the fiscal recorder must be specified in the equipment card in the "Peripherals" directory — without it, 1С cannot uniquely link the database record to a specific physical device, even if the driver and port are configured correctly. Check the serial number on the POS housing or in the device passport and enter it manually into the card.

4. Receipts are not fiscalized after updating 1С#

A typical cause is an incompatibility between the driver version and the processing module version after updating only one side: the configuration was updated, but the fiscal register driver or its version for 1С remained outdated (or vice versa). Troubleshooting steps:

1. Check the connection at the driver level — run the DTO test separately from 1С (the procedure is covered in detail in the article on ATOL cash register errors, §3): if the test prints a document, the issue is not with the cash register, but with the 1С-processing module/driver link.
2. Check with your configuration vendor/integrator for the commercial equipment processing module version required for the new 1С version.
3. Update both the driver and the processing module at the same time, rather than separately — a version mismatch is the typical reason why "receipts are not fiscalized" right after an update.

5. FFD 1.2 on legacy configurations (UT 10.3 and similar)#

Legacy configurations and data processors were written before the introduction of marking and FFD 1.2 and are physically unable to assemble a receipt with the required M-tags (marking code attributes) — an attempt to print such a receipt fails with an error regardless of whether the POS hardware itself is functional. Options:

• Configuration update to a version where the data processor supports FFD 1.2 — the most reliable path, but requires data migration.
• External processor from the CRE vendor — some cash register manufacturers release a separate (external) processor for legacy configurations that handles M-tags without modifying the configuration itself — check with your POS hardware manufacturer.
• Replacing the configuration with an up-to-date one (for example, a newer version of UT or Retail) — considered if the old configuration already needs replacement for other reasons.

6. Tag 1162/1163 error (marking code)#

Tags of the "product code" group in FFD 1.2 define the format in which the marking code must pass from 1С to the cash register driver. The error usually means that the code sent by 1С does not match the format expected by the driver: the tail of the code was truncated during scanning/entry, GS1 control separators were lost (GS/FNC1 — the same code parsing mechanics as in the article about barcode scanners), or the code in the receipt document in 1С was entered manually with an error. First check the marking code itself in the item card/document, then check the version of the data processor responsible for generating this tag.

7. Cash Register Emulator for Testing#

A fiscal register emulator is a legitimate tool for developing and debugging data exchange between 1С and a cash register without a physical device: it allows you to test receipt generation logic and response handling without using up the resource of a real fiscal register and without creating actual fiscal documents. Using an emulator instead of a real cash register for actual sales is unacceptable — a receipt generated by the emulator is not a fiscal document and is not sent to the OFD.

8. One cash register for two workstations#

Technically, one physical fiscal register is connected to only one computer (workstation), but it can serve multiple order entry points:

1. Receipt fiscalization takes place from one dedicated workstation physically connected to the cash register.
2. Other workstations either connect to the same computer via remote desktop (RDP) or send documents for fiscalization through a queue/exchange service processed by the main workstation.
3. The queue processing must be sequential — simultaneous printing from two workstations to a single cash register is not supported in 1С and causes a port access conflict.

9. Example#

A store running 1С:Retail, FFD 1.2, updated the configuration along with a scheduled processing module update — after the update, some receipts with marked goods failed with a product code attribute error. The DTO driver test outside of 1С passed normally, ruling out issues with the cash register and port. After checking with the configuration vendor for the processing module version compatible with the new configuration and current DTO version, they updated the processing module in the same run — and the error disappeared.

10. How to do this in Cenaly#

• If a fiscal receipt is issued by a POS running on 1С:Retail/UT, this entire chain (processing ↔ driver ↔ "Peripherals") remains on the 1С side — Cenaly does not replace it.
• If Cenaly POS serves as the checkout terminal instead of 1С:Retail/UT, the connection to the physical fiscal printer goes directly through Cenaly Hardware Bridge — without the "Peripherals" catalog, a separate DTO driver, or 1С retail equipment data processor.
• A separate 1С:Accounting integration in Cenaly solves a different task — synchronizing items and counterparties via OData into the catalog and supplier directory; it has no relation to receipt fiscalization.
• Both schemes can be combined: manage inventory accounting in 1С while printing receipts via Cenaly Hardware Bridge, or vice versa — keep fiscalization on 1С while synchronizing only the item catalog from it.

11. Frequently Asked Questions#

The driver was updated, but 1С "doesn't see" the cash register — what's wrong? The driver and the 1С processing module are different things, and they need to be updated in sync; for a detailed analysis, see the article on ATOL cash register errors.

Can the KKT emulator be left on a live workstation "just in case"? No — if the emulator accidentally becomes active instead of the real cash register during sales at this workstation, receipts will not become fiscal documents and will not be transmitted to the OFD.

Can I maintain inventory tracking in 1С and issue receipts via Cenaly POS at the same time? Yes, these are two independent tasks: 1С can synchronize the item catalog and suppliers with Cenaly via OData, while fiscalization goes through Cenaly Hardware Bridge, not through 1С.

Is UT 10.3 completely unable to work with FFD 1.2? The configuration itself can continue to work, but it will require either an external processing module from the cash register vendor for M-tags or a configuration update/replacement — check with your 1С supplier and cash register manufacturer which option is supported for your setup.

Related articles: ATOL cash register errors · SHTRIH-M cash register errors · marking at the POS · 1С:Accounting integration in Cenaly

This material is for reference purposes only and does not replace consultation with a 1С integrator or KKT service center. Primary sources: 1С:Enterprise documentation, technical documentation from KKT manufacturers, FFD 1.2 FTS (kkt-online.nalog.ru).