Інтеграція 1С-Бітрікс з 1С-ЕДО

Інтеграція 1С-Бітрікс з 1С-ЕДО

1С-ЕДО — вбудований сервіс електронного документообігу в конфігураціях 1С (Бухгалтерія, УТ, ERP). Коли компанія вже працює через 1С-ЕДО для внутрішнього документообігу, завдання інтеграції з сайтом на 1С-Бітрікс формулюється так: замовлення з Бітрікс автоматично потрапляють до 1С, а УПД, накладні та акти формуються і відправляються через 1С-ЕДО без дублювання введення даних.

Це не інтеграція «Бітрікс → Діадок» напряму. Це інтеграція «Бітрікс → 1С → 1С-ЕДО». Ключова ланка — синхронізація 1С-Бітрікс з обліковою системою 1С.

Схема взаємодії

Бітрікс (замовлення створено/оплачено)
  → Стандартний обмін bitrix→1С (CommerceML/REST)
    → 1С: створена реалізація/акт
      → 1С-ЕДО: документ відправлено контрагенту через оператора
        → 1С: статус підписання отримано від оператора
          → 1С→Бітрікс: статус документа оновлено у замовленні

Бітрікс у цій схемі — джерело замовлень. 1С — система, де формуються облікові документи. 1С-ЕДО — транспорт.

Налаштування обміну Бітрікс ↔ 1С

Стандартний обмін працює через bitrix:catalog і bitrix:sale.export за протоколом CommerceML 2.10. У 1С підключається через «Обмін із сайтом» у конфігураторі.

Для автоматичної передачі замовлень у 1С — налаштування розкладу вивантаження: кожні 15–30 хвилин або за подією через \Bitrix\Main\EventManager. При наявності швидкого API-обміну через REST 1С — можна налаштувати практично real-time: подія OnSaleOrderPaid у Бітрікс тригерить POST-запит до REST-сервісу 1С.

Обробник події оплати

\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'sale', 'OnSaleOrderPaid',
    function (\Bitrix\Main\Event $event) {
        $order = $event->getParameter('ENTITY');
        if ($order->isPaid()) {
            // Відправляємо замовлення у 1С негайно (не чекаємо cron)
            \Local\OneCIntegration\OrderSync::pushOrderToOnec($order->getId());
        }
    }
);

REST-сервіс 1С (PublishedHTTPServices) приймає замовлення і створює документ реалізації. Після цього 1С-ЕДО автоматично (за налаштуваннями у 1С) або після підтвердження відправляє УПД контрагенту.

Зворотній потік: статуси з 1С у Бітрікс

Коли контрагент підписує документ у своїй системі ЕДО, 1С отримує підтвердження через оператора. 1С у відповідь може викликати webhook Бітрікс або передати статус під час наступного планового обміну.

// Endpoint у Бітрікс для прийому статусів від 1С
// /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'

    // Записуємо у користувацьке поле замовлення
    $order = \Bitrix\Sale\Order::load($orderId);
    if ($order) {
        $props = $order->getPropertyCollection();
        $prop  = $props->getItemByOrderPropertyCode('EDO_STATUS');
        if ($prop) {
            $prop->setValue($edoStatus);
        }
        $order->save();

        // Сповіщення менеджеру
        if ($edoStatus === 'rejected') {
            \CEvent::Send('EDO_DOCUMENT_REJECTED', SITE_ID, [
                'ORDER_ID' => $orderId,
                'REASON'   => $data['reason'],
            ]);
        }
    }
}

Кейс: інтеграція для виробничої компанії

Виробник промислового обладнання. 1С УТ 11.5 з 1С-ЕДО. Сайт на 1С-Бітрікс Управління Сайтом — для прийому B2B-замовлень від дилерів. Завдання: дилер оформлює замовлення на сайті, УПД автоматично створюється і відправляється через ЕДО, ні бухгалтер, ні менеджер не створюють документи вручну.

Проблеми, з якими зіткнулися:

1. Стандартний CommerceML-обмін працював із затримкою 30 хвилин і не передавав дані юрособи (ІНН, КПП) — поля були у Бітрікс, але CommerceML-схема їх не включала.

2. 1С-ЕДО у конфігурації не налаштовувався на автоматичну відправку — вимагав ручного підтвердження бухгалтером.

3. Статус підписання у Бітрікс не відображався взагалі.

Рішення:

1. Розширили CommerceML-вивантаження через OnBeforeSaleOrderExport — додали поля юрособи до XML-схеми замовлення. У 1С написали обробник завантаження, який розпізнає ці поля і заповнює реквізити контрагента.

2. У 1С налаштували автоматичне правило ЕДО: при створенні реалізації з певним видом договору — автоматична постановка у чергу відправки через 1С-ЕДО. Бухгалтер лише періодично перевіряє журнал помилок.

3. Розробили скрипт зворотної синхронізації: 1С кожні 15 хвилин викликає webhook Бітрікс зі статусами документів за останню годину.

Маппінг статусів ЕДО у статуси замовлень Бітрікс

Особливості при роботі з кількома операторами ЕДО

1С-ЕДО підтримує роумінг між операторами: документ, відправлений через оператора відправника, доставляється контрагенту через його оператора. У коді Бітрікс це прозоро — логіка маршрутизації повністю на стороні 1С.

Склад робіт

• Аудит схеми обміну Бітрікс ↔ 1С: CommerceML або REST
• Розширення схеми вивантаження під дані ЕДО (ІНН, КПП, тип документа)
• Налаштування у 1С: правила автовідправки через 1С-ЕДО
• Зворотна синхронізація: webhook або polling статусів
• Відображення статусу ЕДО у замовленні Бітрікс
• Сповіщення при відмові, анулюванні

Терміни: при наявності робочого обміну Бітрікс-1С — 2–4 тижні на ЕДО-частину. Якщо обмін потрібно налаштовувати з нуля — додати 2–3 тижні.