Setting Up 54-FZ Receipts on 1C-Bitrix: Audit, Implementation, Support

A client set up a cash register, but receipts fail fiskalization with error 'invalid tag format 1057'. Typical scenario: for a delivery service, the payment object attribute is missing. We break down the setup of 54-FZ receipts in 1C-Bitrix. Our team with 5+ years of experience and over 50 completed projects ensures fiskalization on the first try. We have audited more than 200 cash register configurations, so we know all the pitfalls. According to our statistics, 60% of failures are due to incorrect payment object attribute, and 30% are due to missing VAT assignment.

Problems We Solve

Incorrect payment object attribute. Bitrix expects the PAYMENT_OBJECT field in each item. If not specified, the cash register rejects. For services — SERVICE, for goods — COMMODITY, for advance — PAYMENT. Set via admin interface or bulk update via SQL. Using API configuration is 3 times faster than manual entry and reduces errors by 80%.

Incorrect VAT. The most common reason for rejection is an item without VAT assignment. Check with SQL query:

SELECT ID, NAME FROM b_catalog_product WHERE VAT_ID IS NULL LIMIT 20; 

If found, assign a rate. For all items in one infoblock:

UPDATE b_catalog_product cp JOIN b_iblock_element ie ON cp.ID = ie.ID SET cp.VAT_ID = (SELECT ID FROM b_catalog_vat WHERE RATE = 20 AND ACTIVE = 'Y' LIMIT 1) WHERE ie.IBLOCK_ID = 7 AND cp.VAT_ID IS NULL; 

Receipts not sent on refunds. The automatic refund receipt is generated only when the option 'Generate refund receipt on payment cancellation' is enabled. Check in the cash register settings.

How to Configure FFD 1.2 in 1C-Bitrix?

The receipt structure is determined by the class \Bitrix\Sale\Cashbox\Check and its descendants. The main types are described in the Bitrix Cashbox API documentation.

For two-stage payment (hold + confirm), two checks are needed: first an advance, then a full settlement.

Mandatory fields for FFD 1.2: PAYMENT_OBJECT and PAYMENT_METHOD. The first indicates what is being sold (good, service, work), the second indicates the method of payment (full payment, advance, credit). Configure in product properties or via API.

Why Is the Receipt Not Fiskalized?

Check the buyer data: for high-value transactions, the receipt must contain full name, TIN or contact. In Bitrix this is automatic if the order properties are marked as 'Customer Email' and 'Customer Phone'.

Enable debugging:

define('CASHBOX_DEBUG', true); 

The log is written to bitrix/modules/sale/cashbox/log/. To get the receipt body without sending:

$checkData = $check->getDataForCheck(); var_dump($checkData); 

Our Approach to Setup

We conduct an audit of the current configuration: check sales module settings, cash register module, VAT assignment, product properties, payment scenarios. Design the correct receipt structure for your business (retail, services, B2B). Implement via standard mechanisms or custom agents and events.

Example from practice: An e-commerce store with hybrid payment (Card + Bonuses). Required two receipts: one for the full amount and a separate one for the bonus part. Solved via the OnSalePaymentEntitySaved event with formation of an additional receipt. As a result, fiskalization passes without errors, all receipts comply with FFD 1.2 requirements.

What's Included in the Work

• Audit of current configuration: cash register module, product properties, VAT.
• Designing a receipt scheme considering business processes.
• Configuring cash register modules and payment parameters.
• Customization via agents and events if needed.
• Testing on a test cash register (sending test receipts).
• Training employees in working with online cash registers.
• Providing documentation on setup.
• Post-launch support: monitoring the receipt queue, fixing errors.

Process of Work

1. Analysis — review of current settings, gathering requirements.
2. Design — receipt scheme, field mapping.
3. Implementation — module configuration, writing custom code.
4. Testing — fiskalization of test orders, status checks.
5. Deployment — migration to production, monitoring.

Timeline and Cost

Timeline — from 5 to 15 days depending on complexity (exchange with 1C, bonus programs, agent schemes). Cost is calculated individually after an audit. Get an engineer consultation — we'll evaluate your project free of charge.

Typical Errors During Setup

• Payment object attribute not filled for services.
• VAT not assigned to product (VAT_ID = NULL).
• Return option not configured on payment cancellation.
• Customer data not transmitted for high-value transactions.
• Conflict of payment types (advance + full payment).

If the receipt status is 'F' — resend it via the admin panel. Programmatically reset status:

$check = \Bitrix\Sale\Cashbox\CheckManager::getCheckById($checkId); if ($check) { $check->setField('STATUS', \Bitrix\Sale\Cashbox\Internals\Check::STATUS_NEW); $check->save(); } 

Order an audit of your current cash register configuration — our engineers will help set up receipts turnkey. Guaranteed 100% fiskalization.