Налаштування синхронізації 1С та Бітрікс — стабільний обмін замовленнями

Клієнт скаржиться, що замовлення зависло в статусі "Обробляється" тижнями? Або 1С не бачить нові замовлення, і менеджери передзвонюють кожному покупцю вручну. Ми стикалися з такими кейсами десятки разів — налаштування обміну замовленнями між 1С та 1С-Бітрікс вимагає розуміння механіки CommerceML та
Послуги, які ми пропонуємо
Показано 1 з 1Усі 1626 послуг
Налаштування синхронізації 1С та Бітрікс — стабільний обмін замовленнями
Простий
~1 день

Наші компетенції:

Часті запитання

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1454
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    1018
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Розробка на базі Бітрікс, Бітрікс24, 1С для компанії Development of an Online
    760
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Розробка на базі 1С Підприємство для компанії МИРСАНБЕЛ
    879
  • image_crm_dolbimby_434_0.webp
    Розробка сайту на CRM Бітрікс24 для компанії DOLBIMBY
    803
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    1162

Клієнт скаржиться, що замовлення зависло в статусі "Обробляється" тижнями? Або 1С не бачить нові замовлення, і менеджери передзвонюють кожному покупцю вручну. Ми стикалися з такими кейсами десятки разів — налаштування обміну замовленнями між 1С та 1С-Бітрікс вимагає розуміння механіки CommerceML та мапінгу статусів. За 10+ років інтеграцій ми виробили процес, який гарантує прозору синхронізацію без втрат. Оцінимо ваш проект за 1 день, пишіть.

Проблеми, які вирішуємо

Статуси не синхронізуються. Стандартний мапінг у Бітрікс (Магазин → Налаштування → Статуси замовлень) задає відповідність коду статусу в 1С та на сайті. Помилка — 1С повертає "Невідомий статус", оновлення не застосовується. Ми перевіряємо кожну пару та додаємо запасні варіанти. Якщо статуси перейменували в 1С після оновлення — мапінг летить. Ми автоматизуємо перевірку відповідності в перший день.

Замовлення дублюються. Якщо сеанс обміну перервався після передачі файлу, при наступному запуску замовлення передаються повторно. Захист — унікальний ідентифікатор замовлення (ACCOUNT_NUMBER) та перевірка існування документа в 1С. У складних випадках підключаємо REST API, який атомарно підтверджує прийом. Це знижує навантаження на CRM та виключає ручне звіряння.

Втрати властивостей замовлення. UTM-мітки, промокоди, тип клієнта — стандартний CommerceML їх не передає. Додаємо через обробник OnSaleOrderExport1C. Контролюємо, щоб у 1С були створені відповідні реквізити. Без цього аналітика по рекламі буде неповною.

Чому статуси не синхронізуються?

Типова причина — невідповідність ідентифікаторів. Приклад стандартного мапінгу для УТ 11:

Статус в 1С Код статусу Бітрікс Опис
В роботі P Прийнято, передано в обробку
Підготовлено до відвантаження D Комплектується / Готово
Передано кур'єру F Доставляється
Виконано FF Доставлено, закрито
Скасовано клієнтом C Скасовано

Якщо коди не збігаються — статус не оновиться. Також проблеми виникають при перейменуванні статусів в 1С після оновлення конфігурації. Ми додаємо логування кожного виклику, щоб швидше знайти невідповідність.

Як прискорити обмін замовленнями?

CommerceML працює за розкладом (раз на кілька хвилин або годин). Якщо потрібен real-time — використовуємо REST API 1С. Швидкість передачі на порядок вища, і замовлення з'являється в 1С одразу після оформлення. Порівняння:

Характеристика CommerceML REST API
Затримка від 1 хвилини до 1 години 1-5 секунд
Контроль цілісності через XML, можливі помилки HTTP-статуси, ідемпотентність
Складність налаштування низька середня
Надійність залежить від cron вища, атомарні операції

REST API швидший за CommerceML у десятки разів, але потребує більше роботи з боку 1С. Ми використовуємо гібридний підхід: базовий обмін через CommerceML, а для критичних замовлень — REST. Це баланс між вартістю та швидкістю.

Типові помилки при налаштуванні

  • Неправильний мапінг статусів (коди не збігаються)
  • Відсутність перевірки унікальності замовлення (ACCOUNT_NUMBER)
  • Не налаштовані права на запис у папку обміну
  • Закінчилося місце на диску для XML-файлів
  • Застаріла версія CommerceML (рекомендуємо 2.11+)

Як ми це робимо

Налаштування проходить у кілька етапів:

  1. Аналіз — вивчаємо конфігурацію 1С (УТ, УПП, ERP), версію Бітрікс, поточні обробники.
  2. Проектування — визначаємо список замовлень для вивантаження, мапінг статусів, передавані властивості. Якщо є нестандартні обробники (OnSaleOrderExport1C), готуємо код.
  3. Реалізація — вмикаємо вивантаження в адмінці (Налаштування → Налаштування продуктів → Інтернет-магазин → Обмін замовленнями). Задаємо статуси: зазвичай N (Новий) та P (Оплачений). Період — з дати останнього обміну, щоб не дублювати.
  4. Тестування — створюємо тестове замовлення, перевіряємо його появу в 1С, оновлення статусу на сайті. Логуємо запити.
  5. Деплой — переносимо на бой, налаштовуємо моніторинг (наприклад, телеграм-бот при помилці синхронізації).

Приклад push-відправки через подію OnSaleOrderSaved:

\Bitrix\Main\EventManager::getInstance()->addEventHandler( 'sale', 'OnSaleOrderSaved', function(\Bitrix\Main\Event $event) { $order = $event->getParameter('ENTITY'); if ($order->isNew()) { \MyProject\Exchange\OrderPusher::push($order->getId()); } } ); 

Що входить у роботу

  • Документація: схема обміну, мапінг статусів, опис обробників.
  • Доступи: налаштування прав для 1С та сайту.
  • Навчання: інструкція для менеджерів по роботі з замовленнями.
  • Підтримка: 2 тижні безкоштовного супроводу після запуску.

Ми гарантуємо стабільну синхронізацію. Досвід — більше 50 проєктів по інтеграції 1С та Бітрікс. Сертифіковані спеціалісти. Зв'яжіться для консультації — оцінимо проєкт за 1 день. Інвестиції в налаштування окупаються за рахунок автоматизації. Вартість розраховується індивідуально та залежить від складності.

Строки орієнтовно

Складність Строк
Базова (CommerceML + мапінг) 4–8 годин
Середня (нестандартні властивості, обробники) 1–2 дні
Складна (REST API + real-time) 2–4 дні

Вартість розраховується індивідуально. Пишіть — зробимо точну оцінку.