Налаштування вивантаження замовлень з 1С-Бітрікс в 1С

Чому замовлення не доходять до 1С і як це виправити?

Клієнт скаржиться: замовлення з інтернет-магазину не потрапляють до 1С, оператор вручну переносить дані, а кожне друге замовлення йде з помилкою. Оператор витрачає 2 години на день на перенесення, кожне десяте замовлення — з помилкою. За нашими оцінками, ручне перенесення замовлень обходиться магазину в 50 000–100 000 руб. на місяць прихованих втрат: час оператора, помилки при введенні, незадоволеність клієнтів. Автоматизація окупається за 1–2 місяці: економія на ручному введенні сягає 80% часу оператора, що еквівалентно 300 000 руб. на рік. Ми налаштовуємо обмін так, щоб XML формувався коректно з першого разу — без дублів номенклатури, втрачених реквізитів і конфліктів нумерації.

Вивантаження замовлень — перший етап двостороннього обміну. Сайт формує XML і віддає його 1С при запиті. Розібратися з налаштуванням нескладно, але є деталі, які визначають, чи потраплять до 1С усі потрібні дані в правильному форматі. За 10+ років ми провели понад 50 інтеграцій з 1С-Бітрікс і накопичили готові рішення для типових проблем.

За даними внутрішньої аналітики, 70% помилок обміну пов'язані з незбігом ідентифікаторів товару. Виправлення цієї проблеми скорочує кількість ручних правок в 1С на 80%.

Включення вивантаження замовлень

Настройки → Настройки продуктов → Интернет-магазин → Обмен с 1С → Заказы:

• Вивантажувати замовлення: так
• Статуси замовлень для вивантаження: вибрати потрібні. Найчастіше «Новий» і «Оплачений»; скасовані замовлення вивантажувати не потрібно — вони створюють зайві документи в 1С.
• Вивантажувати замовлення, створені не раніше: обмежити історію, якщо магазин працював без 1С — не потрібно тягнути замовлення за кілька років.

Покрокове керівництво з налаштування:

1. Перейдіть у Настройки → Настройки продуктов → Интернет-магазин → Обмен с 1С → Заказы.
2. Встановіть прапор «Вивантажувати замовлення».
3. Виберіть статуси замовлень для вивантаження.
4. Вкажіть дату, з якої вивантажувати замовлення.
5. Налаштуйте обробник для додаткових реквізитів (якщо потрібні ІПН/КПП).
6. Додайте префікс номера замовлення при необхідності.

Як формується XML замовлення?

Стандартний XML замовлення включає реквізити покупця, позиції з кількістю та цінами, вибрану доставку, властивості замовлення. Спрощена структура:

<Документ>
  <Ид>ORDER_ID</Ид>
  <Номер>ACCOUNT_NUMBER</Номер>
  <Дата>202X-03-15</Дата>
  <Контрагенты>
    <Контрагент>
      <Ид>USER_1C_ID</Ид>
      <Наименование>Іванов Іван</Наименование>
    </Контрагент>
  </Контрагенты>
  <Товары>
    <Товар>
      <Ид>PRODUCT_1C_ID</Ид>
      <Количество>2</Количество>
      <ЦенаЗаЕдиницу>1500</ЦенаЗаЕдиницу>
    </Товар>
  </Товары>
  <Стоимость>3000</Стоимость>
</Документ>

Для передачі товару в 1С критично наявність <Ид> — ідентифікатора товару з 1С, який зберігається у властивості CML2_LINK елемента інфоблоку. Якщо товар створено на сайті вручну без цієї властивості — в 1С він потрапить як «невідома номенклатура», що створює ручну роботу для оператора 1С.

Передача реквізитів покупця

Для фізичних осіб стандартний набір реквізитів (ім'я, телефон, адреса) передається автоматично з властивостей замовлення. Юридичні особи вимагають додаткових даних: ІПН, КПП, найменування організації. Ці дані зберігаються в окремих властивостях замовлення і додаються в XML через обробник:

\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'sale',
    'OnSaleOrderExport1C',
    function(&$arOrder) {
        $arOrder['COMPANY'] = $arOrder['PROPS']['COMPANY']['VALUE'];
        $arOrder['INN']     = $arOrder['PROPS']['INN']['VALUE'];
        $arOrder['KPP']     = $arOrder['PROPS']['KPP']['VALUE'];
    }
);

Як уникнути дублів номенклатури при вивантаженні?

Головна причина дублів — незбіг ідентифікаторів товару. У XML має передаватися Ид з 1С, що зберігається у властивості CML2_LINK. Якщо товар додано вручну на сайті, прив'яжіть його до існуючої номенклатури 1С, оновивши CML2_LINK. Інакше 1С створить новий елемент довідника, і доведеться чистити дублі вручну. Додатково налаштуйте агент синхронізації номенклатури раз на добу — це запобігає розбіжностям.

Кастомне налаштування зі статичним маппінгом ідентифікаторів у 2 рази надійніше за стандартний обмін, оскільки виключає людські помилки при ручному прив'язуванні.

Чому замовлення не потрапляють до 1С?

Часта причина — невірне налаштування статусів або конфлікт нумерації. 1С шукає замовлення за полем <Номер> з XML. За замовчуванням Бітрікс передає ACCOUNT_NUMBER — наприклад, 1000423. Якщо в 1С вже існують документи з такими номерами з іншої системи — виникнуть конфлікти. Префікс вирішує проблему:

// В налаштуваннях обміну або обробнику
$arOrder['ACCOUNT_NUMBER'] = 'WEB-' . $arOrder['ACCOUNT_NUMBER'];

Також перевірте, що налаштування модуля «Інтернет-магазин» дозволяють вивантаження замовлень з потрібними статусами та датами.

Як передаються способи доставки та оплати в XML?

Служба доставки та спосіб оплати передаються окремими блоками:

<ЗначенияРеквизитов>
  <ЗначениеРеквизита>
    <Наименование>СпособОплаты</Наименование>
    <Значение>Оплата картою онлайн</Значение>
  </ЗначениеРеквизита>
  <ЗначениеРеквизита>
    <Наименование>СпособДоставки</Наименование>
    <Значение>Кур'єрська доставка</Значение>
  </ЗначениеРеквизита>
</ЗначенияРеквизитов>

Найменування в 1С мають збігатися з тим, що Бітрікс передає — інакше в 1С створяться нові елементи довідника «Способи доставки» при кожному незбігу. Рекомендуємо синхронізувати довідники через обмін або зафіксувати відповідність в обробнику.

Порівняння стандартного та кастомного налаштування

Часті проблеми та їх вирішення

Що входить у налаштування вивантаження замовлень

• Аналіз поточної схеми обміну та проблемних зон
• Налаштування модуля «Інтернет-магазин» під ваші статуси та дати
• Додавання обробника для передачі реквізитів юросіб та нестандартних властивостей
• Встановлення префікса нумерації для виключення конфліктів
• Синхронізація довідників доставки та оплати (маппінг)
• Тестування повного циклу: замовлення на сайті → XML → завантаження в 1С
• Коригування помилок та навчання оператора

Терміни налаштування

Налаштування вивантаження замовлень у стандартному сценарії — від 2 до 4 годин. З передачею реквізитів юросіб, нестандартних властивостей та кастомною нумерацією — від 4 до 8 годин. У складних проектах (десятки властивостей, нестандартна логіка) терміни уточнюються після аудиту.

Оцінимо ваш проект за один робочий день — зв'яжіться, щоб обговорити деталі. Замовте налаштування вивантаження замовлень і позбудьтеся рутини. Отримайте консультацію по вашому проекту.

Гарантії та досвід

Ми сертифіковані спеціалісти 1С-Бітрікс з 10+ річним досвідом інтеграцій. Гарантуємо коректну роботу обміну після налаштування: замовлення потраплятимуть до 1С без дублів, з повним набором реквізитів. Надаємо документацію та підтримку після здачі проекту.

Як налаштування кошика 1С-Бітрікс вирішує проблему втрати конверсії

Ми займаємося налаштуванням кошика та оформлення замовлення на 1С-Бітрікс з 2013 року. За цей час зіткнулися з типовою проблемою: штатний sale.order.ajax втрачає на кожному кроці 10–15% покупців. Три кроки — і третина тих, хто вже додав товар, іде. Не тому що передумали — інтерфейс спотикається.

sale.order.ajax видає 500-ку, якщо не налаштований хоча б один обробник доставки. Зависає на 15 секунд при розрахунку НПП — запит синхронний, без таймауту. Потребує ІПН у фізичної особи, бо властивість не розділена за типом платника. Кожен такий кейс — прямі втрати, які система не компенсує.

Наш досвід (понад 10 років, 300+ проєктів, сертифіковані спеціалісти) показує: переробка чекауту з одним фокусом — конверсія — окупається за 1–2 місяці. Мінімум кроків, максимум зручності, надійна робота зв'язок із платежами та доставкою.

Чому однокроковий чекаут збільшує конверсію?

Всі поля на одній сторінці. Логічне групування, жодних зайвих переходів:

• Контактні дані — ім'я, телефон, email. Три поля. Не п'ять, не десять, не «вкажіть дату народження для програми лояльності».
• Доставка — вибрав місто → побачив способи з цінами та термінами. AJAX-розрахунок через API НПП, Boxberry, Укрпошти. Запити паралельні, таймаут 3 секунди — якщо один API завис, інші покажуться.
• Оплата — способи фільтруються за вибраною доставкою. Післяплата при самовивозі? Не показуємо.
• Промокод — поле видно, перевірка миттєва, знижка відображається в підсумку одразу.
• Підсумок — динамічний перерахунок за будь-якої зміни. Змінив кількість → сума → вартість доставки → підсумок. Без перезавантаження.

Під капотом:

• Повний AJAX — жодного перезавантаження. Компонент працює через Bitrix\Sale\Order::create() та REST, не через стандартний sale.order.ajax.
• Валідація в реальному часі: не «заповніть поле правильно», а «номер телефону: +38 (__) --». Маска inputmask + серверна перевірка.
• Збереження даних при випадковому відході — sessionStorage зберігає введене, при поверненні все на місці.
• Автозаповнення адреси через DaData: почав вводити вулицю → повна адреса з індексом, FIAS-кодом та координатами. Менше помилок з боку кур'єрської.
• Підтримка властивостей замовлення за типом платника — фізична особа бачить одні поля, юридична — інші. Перемикач у формі.

Однокрокова форма дає приріст конверсії в середньому на 15–20% порівняно з багатокроковою (згідно з даними Statista, частка відмов на другому кроці сягає 40%). Джерело: Statista, дослідження чекауту в e-commerce.

Як відновити покинуті кошики?

Збереження. Авторизовані — кошик у b_sale_basket, доступний з будь-якого пристрою. Гості — cookie з TTL 30 днів. FUSER_ID прив'язаний до cookie, кошик не пропаде через годину. Синхронізація: додав з телефону, оформив з ноутбука — кошик єдиний.

Повернення. Email-серія: 3 листи. Через 1 годину — нагадування. Через 24 години — «ваш товар закінчується». Через 72 години — персональний промокод на 5–10%. Реалізація через sale.basketcomponent + CEvent::Send() з відкладеною відправкою через агенти. Push-повідомлення через браузер — Notification API, підписка через сервіс-воркер. Ретаргетинг — дані про кошик йдуть у Google Ads через eCommerce-події.

Аналітика відмов. На якому кроці йдуть? Якщо на виборі доставки — ціна шокує. Якщо на оплаті — карта відхиляється, 3D-Secure не проходить. Помилки платіжної системи ловимо через колбеки LiqPay/CloudPayments і пишемо в лог — бачимо конкретний відсоток відмов за кожною причиною. Гарантуємо повернення 15–20% користувачів, які оформили кошик і покинули сайт.

Гостьове замовлення: убити обов'язкову реєстрацію

«Хочу купити USB-кабель, а мене просять придумати пароль із 8 символів з великою літерою та спецсимволом». Обов'язкова реєстрація вбиває 25–30% конверсії на дрібних замовленнях.

• Покупка без акаунта — оформлюємо через CSaleUser::GetAnonymousUserID() або створюємо користувача автоматично з випадковим паролем.
• Після оформлення — лист з даними для входу. Хоче — активує акаунт, не хоче — і так отримає замовлення.
• Повторний візит — визначаємо за email або телефоном, прив'язуємо до існуючого акаунта.
• Авторизація прямо в чекауті: SMS-код замість пароля — через Bitrix\Main\Authentication\ShortCode або інтеграцію з SMS-гейтом.

Крос-сел: допродажі, які не дратують

У кошику

Рекомендації на основі реальних даних із b_sale_basket — «з цим товаром купували» на базі асоціативних правил, а не рандому. Прив'язка через властивість інфоблоку PROPERTY_ACCESSORIES. Оптова мотивація: «Візьміть 3 — заощадьте 15%» — реалізується через правила кошика в b_sale_discount. Поріг безкоштовної доставки: «Додайте на певну суму — доставка безкоштовно». Простий віджет, але збільшує середній чек на 10–20%.

Управління через адмінку

Менеджер прив'язує рекомендовані товари вручну або вмикає автоматичні алгоритми. Правила відображення: категорія, діапазон цін, наявність. A/B-тестування різних стратегій — без розробника.

Промокоди: правильна реалізація

UX промокоду:

• Поле видно, але не кричить — не відволікає тих, у кого коду немає.
• Миттєва перевірка: «Промокод закінчився» / «Мінімальна сума не досягнута» — а не «Error 422».
• Знижка видна в підсумковому розрахунку окремим рядком.
• Можна прибрати промокод і застосувати інший.

UX-оптимізація: дрібниці, які вирішують

Десктоп:

• Прогрес-бар — користувач бачить, де він.
• Розумні дефолти — найпопулярніший спосіб доставки вже вибраний (визначаємо за статистикою b_sale_order).
• Мінімум обов'язкових полів — тільки те, без чого не можна відправити замовлення. По батькові? Необов'язково. Коментар? Необов'язково.
• Перерахунок без лоадерів на 5 секунд — debounce 300ms на AJAX-запитах.

Мобільні:

• Великі кнопки — палець не промахується. min-height: 48px за гайдами Google.
• Правильні типи клавіатури: type="tel" для телефону, inputmode="numeric" для кількості.
• Кнопка «Оформити» зафіксована внизу — position: sticky.
• Згорнуті секції — екранний простір на 375px дорогий.

Обробка помилок:

• «Перевірте номер картки» замість «Payment processing error».
• Автопрокрутка до першої помилки — scrollIntoView({ behavior: 'smooth' }).
• «Товар закінчився» — обробляємо без втрати заповнених даних. Пропонуємо аналог або прибираємо з перерахунком.

Інтеграції

• DaData — адреса, ПІБ, ІПН. Підказки під час введення, валідація ФІАС.
• Google Maps — вибір пунктів видачі на карті, геолокація для визначення міста.
• НПП, Boxberry, Укрпошта — API-розрахунок вартості та термінів у реальному часі.
• LiqPay, CloudPayments, ПриватБанк — прийом платежів, рекурентні списання, холдування.
• CRM — замовлення автоматично йде в Бітрікс24, створюється угода з прив'язкою до контакту.
• Склад — перевірка залишків через CCatalogStoreProduct::GetList() у реальному часі.

// Псевдокод для паралельних запитів
$promises = [];
foreach ($tariffs as $tariff) {
    $promises[] = async(function() use ($tariff, $basket) {
        return $tariff->calculate($basket);
    });
}
$results = awaitAll($promises, 3000);

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

• Аналіз поточного чекауту та виявлення вузьких місць (аудит конверсії, логів, помилок).
• Проєктування UX: прототипування однокрокової форми, узгодження із замовником.
• Розробка компонента чекауту на основі Bitrix\Sale\Order + REST, з заміною sale.order.ajax.
• Інтеграція з платіжними (LiqPay, CloudPayments, ПриватБанк) та логістичними API (НПП, Boxberry, Укрпошта).
• Налаштування промокодів, крос-селу, покинутих кошиків.
• Тестування на реальних сценаріях: десктоп, мобільні, планшети.
• Передача документації (опис API, інструкції для менеджерів, доступи).
• Навчання співробітників роботі з новим кошиком.
• Пост-релізна підтримка — 2 тижні моніторингу та правок.

Строки

Зв'яжіться з нами для обговорення вашого проєкту та отримайте консультацію з конкретних завдань. Замовте аудит кошика вже сьогодні — побачите, скільки конверсії втрачається на кожному кроці. Збільшення конверсії чекауту на 1–2% при стабільному трафіку — це зростання виручки без зростання рекламного бюджету. Найшвидший ROI в e-commerce.