Integration of 1C-Bitrix with 1C-EDO

1C-Bitrix Integration with 1C-EDO

1C-EDO is the built-in electronic document interchange service in 1C configurations (Accounting, Trade Management, ERP). When a company already uses 1C-EDO for document interchange, the integration task with a 1C-Bitrix website is defined as follows: orders from Bitrix automatically flow into 1C, and UPD documents, invoices, and acts are generated and sent via 1C-EDO without duplicate data entry.

This is not a direct "Bitrix → Diadoc" integration. It is a "Bitrix → 1C → 1C-EDO" integration. The critical link is the synchronization between 1C-Bitrix and the 1C accounting system.

Interaction Scheme

Bitrix (order created/paid)
  → Standard bitrix→1C exchange (CommerceML/REST)
    → 1C: realization/act created
      → 1C-EDO: document sent to counterparty via operator
        → 1C: signing status received from operator
          → 1C→Bitrix: document status updated in order

Bitrix is the order source in this scheme. 1C is where accounting documents are formed. 1C-EDO is the transport layer.

Bitrix ↔ 1C Exchange Setup

The standard exchange uses bitrix:catalog and bitrix:sale.export via the CommerceML 2.10 protocol. In 1C it is connected through "Website Exchange" in the configurator.

For automatic order transfer to 1C — configure the export schedule: every 15–30 minutes or event-driven via \Bitrix\Main\EventManager. When a fast API exchange via 1C REST is available, near real-time is achievable: the OnSaleOrderPaid event in Bitrix triggers a POST request to the 1C REST service.

Payment Event Handler

\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'sale', 'OnSaleOrderPaid',
    function (\Bitrix\Main\Event $event) {
        $order = $event->getParameter('ENTITY');
        if ($order->isPaid()) {
            // Push the order to 1C immediately (do not wait for cron)
            \Local\OneCIntegration\OrderSync::pushOrderToOnec($order->getId());
        }
    }
);

The 1C REST service (PublishedHTTPServices) receives the order and creates a "Sales of Goods and Services" document in 1C, posts it, and queues it in 1C-EDO for delivery. After that, 1C-EDO automatically (based on 1C settings) or on manual confirmation sends the UPD to the counterparty.

Return Flow: Statuses from 1C Back to Bitrix

When the counterparty signs the document in their EDO system, 1C receives confirmation from the operator. 1C can then call a Bitrix webhook or pass the status during the next scheduled exchange.

// Endpoint in Bitrix to receive status updates from 1C
// /local/ajax/onec_edo_status.php
$data = json_decode(file_get_contents('php://input'), true);

if ($data['action'] === 'update_edo_status') {
    $orderId   = (int)$data['order_id'];
    $edoStatus = $data['edo_status']; // 'signed', 'rejected', 'annulled'

    // Write to a custom order field
    $order = \Bitrix\Sale\Order::load($orderId);
    if ($order) {
        $props = $order->getPropertyCollection();
        $prop  = $props->getItemByOrderPropertyCode('EDO_STATUS');
        if ($prop) {
            $prop->setValue($edoStatus);
        }
        $order->save();

        // Notify the manager
        if ($edoStatus === 'rejected') {
            \CEvent::Send('EDO_DOCUMENT_REJECTED', SITE_ID, [
                'ORDER_ID' => $orderId,
                'REASON'   => $data['reason'],
            ]);
        }
    }
}

Case Study: Integration for a Manufacturing Company

An industrial equipment manufacturer. 1C Trade Management 11.5 with 1C-EDO. Website on 1C-Bitrix Site Management — for accepting B2B orders from dealers. Requirement: a dealer places an order on the website, a UPD is automatically created and dispatched via EDO; neither the accountant nor the manager creates documents manually.

Problems encountered:

1. The standard CommerceML exchange had a 30-minute delay and did not pass legal entity data (INN, KPP) — the fields existed in Bitrix but the CommerceML schema did not include them.

2. 1C-EDO in the configuration did not support automatic sending — it required manual confirmation by the accountant.

3. The signing status was not visible in Bitrix at all.

Solutions:

1. Extended the CommerceML export via OnBeforeSaleOrderExport — added legal entity fields to the order XML schema. In 1C, a loading handler was written to recognize these fields and populate the counterparty details.

2. In 1C, an automatic EDO rule was configured: when a realization is created with a specific contract type — automatic queuing for dispatch via 1C-EDO. The accountant only periodically reviews the error log.

3. A reverse synchronization script was developed: 1C calls a Bitrix webhook every 15 minutes with document statuses from the past hour.

EDO Status Mapping to Bitrix Order Statuses

Notes on Multi-Operator EDI

1C-EDO supports roaming between operators: a document sent via the sender's operator is delivered to the counterparty via their operator. In Bitrix code this is transparent — routing logic resides entirely in 1C.

Scope of Work

• Audit of the Bitrix ↔ 1C exchange scheme: CommerceML or REST
• Extension of the export schema for EDO data (INN, KPP, document type)
• 1C configuration: auto-send rules via 1C-EDO
• Reverse synchronization: webhook or status polling
• EDO status display within the Bitrix order
• Notifications for rejection and cancellation events

Timeline: with an existing working Bitrix-1C exchange — 2–4 weeks for the EDO portion. If the exchange needs to be configured from scratch — add 2–3 weeks.