Setting up exchange between 1C:Managing Our Company (UNF) and 1C-Bitrix

Configuring Exchange Between 1C:Managing Our Company (UNF) and 1C-Bitrix

UNF is the choice for small businesses that want to manage CRM, inventory, and sales in one place without the excessive complexity of ERP. Integration with Bitrix works differently here than with UT or KA: UNF lacks a full CommerceML exchange mechanism in the classic sense, but it does offer REST API and Bitrix Drive — the official connector from 1C.

Two Integration Paths for UNF with Bitrix

Path 1: CommerceML (classic). UNF supports the standard exchange protocol via /bitrix/admin/1c_exchange.php. Product catalog, prices, stock levels, and orders are transferred. It works, but with limitations: no full-featured item characteristics, no serial tracking, and CRM documents are not transmitted.

Path 2: REST API + webhooks. Starting with version 1.6, UNF includes a built-in HTTP service. Bitrix can poll it or receive push notifications about changes. This path is more flexible but requires development on both sides.

For most tasks (catalog + orders), CommerceML is sufficient. REST is needed when non-standard objects must be transferred: CRM deals, tasks, documents.

Setting Up CommerceML in UNF

Section: Company → Integration → Website Exchange.

Parameters:

• Site address and credentials
• Product catalog: select groups for export
• Prices: price type (retail / wholesale)
• Stock: which warehouses to include

UNF specifics: items in UNF can have "variants" — analogous to characteristics in UT. Variants are exported to CommerceML as separate entries with the ProductCharacteristic attribute. Bitrix reads them and creates trade offers (SKUs). This chain works as long as variants have no nested dependencies (e.g., variant price does not depend on another variant).

Orders from Bitrix to UNF

Orders are created in UNF as "Customer Orders." The counterparty is created automatically from the order data.

Critical point: statuses. In UNF, an order progresses through: New → In Progress → Completed / Cancelled. Bitrix has its own status chain. The mapping is configured in the exchange node. Without configuration, orders in UNF will remain stuck in "New" status.

Reverse status synchronization. When a manager changes an order status in UNF, that change must reach Bitrix. The standard exchange supports this: at the next exchange session, the order status is updated in Bitrix. However, there is a delay equal to the exchange interval (typically 5–15 minutes).

Case Study: UNF + Bitrix in the Service Industry

A technical repair center: UNF manages the CRM (client requests, repair history), while the website handles a request form and client personal account.

Goal: a request submitted on the website must arrive in UNF as an "Inquiry," and the client must see the repair status in their personal account on the site.

Solution: the REST API of UNF was used. When the form is submitted on the website:

1. Bitrix creates an order in its own system
2. A script sends a POST request to the UNF HTTP service, creating an inquiry
3. UNF returns the inquiry ID; Bitrix saves it in a custom order field

For reverse status synchronization — a webhook from UNF: when the inquiry status changes, a POST request is sent to the Bitrix endpoint, which updates the order status.

Status synchronization delay: 0 (instant via webhook) instead of 5 minutes with polling.

UNF Limitations in Integration

UNF is well suited for integration when the catalog is small (up to 20,000 items) and there are no complex characteristics. If the business is growing — plan for a possible migration to KA or UT without reworking the site (preserve the XML_ID of catalog items).