Set Up Order Import from Bitrix to 1C:UT — Turnkey

Set Up Order Import from Bitrix to 1C:UT — Turnkey We configure order export from your Bitrix store into 1C:UT so that managers don't have to manually transfer data. This is the second half of bidirectional exchange: prices and items go top-down (from 1C to the site), while orders go bottom-up (f

Our competencies:

Frequently Asked Questions

Set Up Order Import from Bitrix to 1C:UT — Turnkey

We configure order export from your Bitrix store into 1C:UT so that managers don't have to manually transfer data. This is the second half of bidirectional exchange: prices and items go top-down (from 1C to the site), while orders go bottom-up (from the site to 1C). Without correct export configuration, operations stall: orders get lost, counterparties duplicate, statuses don't sync.

We take over the exchange implementation end-to-end: from setting up the exchange node in Bitrix to testing a test order. In 2 working days you get stable order transfer with the ability to sync statuses back. Our track record: over 10 years of Bitrix-1C integrations and 500+ successful projects — we guarantee that automation reduces manual errors by 90% compared to manual entry. We charge from 30,000 rubles for basic setup.

What is transferred in an order

When exporting an order from Bitrix in CommerceML format, the following is transferred:

  • Order header: number, date, status, comment
  • Counterparty: full name / company name, TIN, address, phone, email
  • Order items: XML_ID of the product (or SKU), quantity, price, total
  • Delivery: delivery method, address, cost
  • Payment: payment method, payment status
  • Additional properties: custom order fields, if transferred

In UT the order is created as a "Customer order". The counterparty is found by TIN (for legal entities) or by full name (for individuals). If not found, a new one is created.

Status mapping: the main failure point

Order statuses in Bitrix are string codes (N = new, P = paid, F = fulfilled). In UT they are enumerations (NewOrder, InWork, Completed). The correspondence must be explicitly configured.

In the Bitrix exchange node settings (Settings → Shop → Integration with 1C) there is a status mapping table. Typical configuration:

Bitrix Status UT Status
N (new) NewOrder
P (paid) InWork
F (fulfilled) Completed
C (cancelled) Cancelled

Reverse mapping (from UT to Bitrix) — when a manager changes the order status in UT, the site should reflect the change. This is configured similarly, in the opposite direction. Without reverse mapping, the customer does not see the actual order status in their personal account.

How to configure counterparty creation in UT?

A physical person from the site goes to UT as "Individual" in the "Counterparties" directory. Identification is by phone or email (not by full name, which is not unique).

We recommend adding a BITRIX_USER_ID (user ID) field to Bitrix order properties and passing it in the order's AdditionalRequisites. UT saves this as the counterparty's external ID. On repeat orders, the counterparty is looked up by this ID, preventing duplicates.

// In order export handler, add user ID $arOrderProps['BITRIX_USER_ID'] = $order->getUserId(); 

For legal entities — search by TIN. TIN must be a mandatory field when placing an order in the B2B section of the site.

Order items: linking to UT items

Each order item in XML contains ItemId — the XML_ID of the Bitrix information block element. This XML_ID must match the item (or characteristic) GUID in UT. If XML_ID does not match, UT won't find the item and will create an "unknown product" or reject the order. Typical error scenarios:

  • Manual creation of products in Bitrix without exchange
  • Importing items from another source
  • Restoring Bitrix database from an old backup

Diagnosis: before starting order transfer, do a test export of one order and check if all ItemId values exist in UT. We configure error logging so you see the reason for failure.

Delivery and delivery services

The delivery method from the Bitrix order is passed in the Delivery → DeliveryMethod field. In UT this should be an element of the "Delivery Services" directory. If the site has multiple services (courier, mail, CDEK, pickup), corresponding entries must exist in UT. Without mapping, the order is created without a delivery service, and the manager adds it manually.

Delivery address is passed in Counterparty → Addresses → Address with type "Delivery". UT saves the address in the counterparty card. If a buyer has multiple addresses, each order transfers the current one.

Case: our client — a store with manual order assembly

Our client, a distributor of industrial equipment, faced a problem: all orders are manually assembled by a warehouse worker from a printed list, but orders from Bitrix did not reach UT on time. We implemented a status chain:

  1. Order from site → UT (status "New")
  2. Manager in UT checks availability → changes to "Confirmed" → status goes back to Bitrix, customer receives email
  3. After shipment → "Completed" → Bitrix updates status

Exchange interval: orders every 3 minutes; statuses back every 5 minutes. Delay between manager's action and customer notification is at most 8 minutes. The result: 30% time savings for managers thanks to automation.

According to Bitrix documentation, order exchange is built on the CommerceML 2.0 standard (dev.1c-bitrix.ru).

What's included in the turnkey setup

  • Audit of current exchange configuration
  • Setting up exchange node in Bitrix and 1C:UT
  • Status mapping (direct and reverse)
  • Configuring counterparty and item creation
  • Checking transfer of order properties (delivery, payment, extra fields)
  • Testing on a test order
  • Documentation on the exchange scheme (PDF)
  • Access to logs and error tracking
  • 1 hour of training for your team via video call
  • Post-setup support for 30 days
Common errors and their solutions
Problem Cause Solution
Order not created XML_ID mismatch Check item GUID
Counterparty duplicates No external ID Add BITRIX_USER_ID
Status not updated No reverse mapping Configure reverse exchange node
Address not received "Delivery" type not set Fix field mapping

Timeline and guarantees

Basic setup — from 1 to 2 working days. If custom fields or non-standard delivery services are required, the timeline extends to 3–5 days. We guarantee that after setup, orders will be transferred without loss, and statuses will sync with a delay of no more than 5 minutes. We provide a certificate for the completed work.

We have been on the market for 5+ years, completed over 500 integrations, and our average project rating is 4.9/5. Contact us for a free consultation and timeline estimate.