Configuring Order Import from 1C-Bitrix to 1C:UT
Transferring orders from Bitrix to UT is the second half of the bidirectional exchange. Prices and items flow "top-down" (from 1C to the website), orders flow "bottom-up" (from the website to 1C). This direction is critical for day-to-day operations: managers must not manually re-enter website orders into the accounting system.
What Is Transmitted in an Order
When an order is exported from Bitrix in CommerceML format, the following is transmitted:
- Order header: number, date, status, comment
- Counterparty: full name / organization name, tax ID, address, phone, email
- Order items: XML_ID of the product (or SKU), quantity, price, total amount
- Delivery: delivery method, address, cost
- Payment: payment method, payment status
- Additional properties: custom order fields, if transmitted
In UT, the order is created as a "Customer Order." The counterparty is searched by tax ID (for legal entities) or by full name (for individuals). If not found — a new one is created.
Status Mapping: the Primary Failure Point
Order statuses in Bitrix are string codes (N = new, P = paid, F = fulfilled). In UT — an enumeration (NewOrder, InProgress, Completed). The mapping must be configured explicitly.
In the Bitrix exchange node settings (Settings → Store → 1C Integration), a status mapping table is available. Typical configuration:
| Bitrix status | UT status |
|---|---|
| N (new) | NewOrder |
| P (paid) | InProgress |
| F (completed) | Completed |
| C (cancelled) | Cancelled |
Reverse mapping (from UT to Bitrix) — when a manager changes an order status in UT, the website must reflect the change. This is configured similarly, in the reverse direction. Without reverse mapping, buyers cannot see the current status of their order in their personal account.
Creating a Counterparty in UT
An individual buyer from the website arrives in UT as a "Private Individual" in the "Counterparties" directory. Identification — by phone or email (not by full name, which is not unique).
Recommendation: add a BITRIX_USER_ID field (user ID) to Bitrix order properties and transmit it in AdditionalAttributes of the order. UT saves this as the external ID of the counterparty. On repeat orders — the counterparty is found by this ID, no duplicates are created.
// In the order export handler, add the user ID
$arOrderProps['BITRIX_USER_ID'] = $order->getUserId();
For legal entities — search by tax ID. The tax ID must be a required field during checkout in the B2B section of the website.
Order Items: Linking to UT Items
Each order item in XML contains ProductId — the XML_ID of the Bitrix infoblock element. This XML_ID must match the GUID of the item (or characteristic) in UT.
If the XML_ID in Bitrix does not match the GUID in UT — UT will not find the item and will create an "unknown product" or reject the order creation. This happens when:
- Products are manually created in Bitrix (without an exchange)
- Items are imported from another source
- The Bitrix database is restored from an old backup
Diagnostic step: before launching order transmission, run a test export of a single order and verify that all ProductId values are found in UT.
Delivery and Shipping Methods
The delivery method from the Bitrix order is transmitted in the Delivery → DeliveryMethod field. In UT, this must be an element of the "Delivery Services" directory. The mapping must be configured in the exchange node.
If the website has multiple delivery services (courier, Post, CDEK, pickup), UT must have corresponding services. Without the mapping configured, the order is created without a delivery service and the manager in UT must add it manually.
Delivery address. Transmitted in Counterparty → Addresses → Address with type "Delivery." UT saves the address in the counterparty record. If a buyer has multiple delivery addresses — each order transmits the current address.
Case Study: Store with Manual Order Assembly
An industrial equipment distributor: all orders are assembled manually by a warehouse worker based on a printed pick list. An order from Bitrix must arrive in UT, go through approval (manager confirms availability), then proceed to assembly.
The following status chain was implemented:
- Order from the website → UT (status "New")
- Manager in UT checks availability → moves to "Confirmed" → status sent back to Bitrix, buyer receives an email
- After shipment → "Completed" → Bitrix updates the status
Exchange interval: orders → every 3 minutes; statuses back → every 5 minutes. Delay between manager action and buyer email — no more than 8 minutes.