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

Уявіть: менеджер змінив ціну на сайті вручну, а за годину прийшло вивантаження з 1С за протоколом CommerceML і скинуло її. Знайома ситуація? При односторонньому вивантаженні це штатна поведінка — і це потрібно враховувати. Одностороннє вивантаження — сценарій, коли 1С є єдиним джерелом істини для каталогу: ціни, залишки, характеристики товарів керуються тільки в 1С і передаються на сайт через регламентні завдання. Сайт нічого не надсилає назад. Простота схеми — її головна перевага. Але водночас це головне джерело проблем при неправильному налаштуванні. Ми налаштовуємо обмін так, щоб контент залишався під керуванням сайту, а облікові дані синхронізувалися без конфліктів. Вартість визначається після аналізу, але зазвичай окупається за рахунок запобігання помилкам у каталозі. Наприклад, базове налаштування «під ключ» коштує від 300 доларів, а економія від запобігання помилкам може сягати до 50% часу на корекцію даних.

Коли одностороннє вивантаження виправдане?

• Контент товарів (описи, фото) ведеться на сайті, а облікові дані (ціни, залишки, артикули) — в 1С.
• Немає ризику конфлікту версій — 1С завжди перезаписує дані на сайті.
• Простота обслуговування важливіша за гнучкість, а обмін налаштовують один раз надовго.

Помилка: використовувати одностороннє вивантаження і при цьому редагувати ціни або залишки на сайті вручну. При наступному обміні всі зміни перезапишуться без попередження. Це головна причина інцидентів у магазинах з новими менеджерами. Щоб цього уникнути, потрібно чітко розмежувати джерела даних.

Як захистити контент від перезапису?

Ключове завдання — чітко визначити, які поля приходять з 1С, а які керуються на сайті.

У налаштуваннях модуля обміну (Налаштування → Налаштування продуктів → Інтернет-магазин → Поля для оновлення) рекомендується:

Для тонкого контролю на рівні коду — обробник OnIBlockElementBeforeUpdate:

\Bitrix\Main\EventManager::getInstance()->addEventHandler( 'iblock', 'OnIBlockElementBeforeUpdate', function(\Bitrix\Main\Event $event) { $fields = $event->getParameter('fields'); $protectedFields = ['DETAIL_TEXT', 'PREVIEW_PICTURE']; foreach ($protectedFields as $field) { unset($fields[$field]); } return new \Bitrix\Main\EventResult( \Bitrix\Main\EventResult::SUCCESS, ['fields' => $fields] ); } ); 

Цей обробник гарантує, що навіть якщо в XML-файлі CommerceML прийдуть контентні поля, вони не будуть застосовані. Використовуйте його в зв'язці з налаштуваннями модуля для подвійного захисту.

Чому важливо деактивувати відсутні товари?

Опція «Деактивувати товари, не передані при обміні» — небезпечна, але часто потрібна. Якщо в 1С товар знято з продажу — він має зникнути з сайту. Вмикайте її тільки переконавшись, що повне вивантаження дійсно включає весь активний асортимент. Часткові вивантаження (тільки змінені позиції) з цією опцією разом не працюють — вони деактивують все, чого не було у файлі.

Порівняйте з двостороннім вивантаженням: одностороннє у 2–3 рази знижує ризики втрати даних, якщо контент ведеться на сайті. Нижче — зведена таблиця.

Порівняння схем вивантаження: одностороння vs двостороння

Одностороннє вивантаження особливо підходить для магазинів з великим каталогом, де контент готують окремо, а облік ведеться в 1С. Детальніше про протокол CommerceML можна прочитати в офіційній документації.

Наприклад: кейс із захистом контенту

Для одного клієнта з каталогом у 15 000 товарів ми налаштували одностороннє вивантаження з 1С: захистили контентні поля через обробник, налаштували регламентне завдання на щогодинну синхронізацію. У результаті менеджери змогли змінювати описи на сайті без ризику їх перезапису, а ціни та залишки оновлювалися автоматично з 1С. Інцидентів через випадкове перезаписування контенту більше не виникало. Економія часу на виправлення помилок склала близько 40%.

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

• Аналіз поточної схеми обміну та структури каталогу.
• Проектування правил вивантаження з урахуванням розділення полів.
• Налаштування модуля обміну на стороні сайту та 1С (регламентне завдання).
• Захист контентних полів через обробник OnIBlockElementBeforeUpdate.
• Тестування всіх сценаріїв: повне вивантаження, часткове, деактивація.
• Документація щодо схеми обміну для ваших співробітників.
• Навчання менеджерів правилам роботи з каталогом.
• Післяпродажна підтримка протягом 30 днів.

Терміни та вартість

Базове налаштування одностороннього вивантаження із захистом полів — 4–8 годин. Якщо потрібно розібратися з історичними даними та привести до єдиного вигляду існуючий каталог — 1–2 дні. Вартість розраховується індивідуально, орієнтовно від 300 доларів за базовий пакет. Гарантуємо стабільну роботу обміну після впровадження. Наш досвід — понад 10 років інтеграцій та більше 40 успішних проектів.

Переваги одностороннього вивантаження

• За простотою обслуговування одностороння схема в 2 рази виграє у двосторонньої.
• Мінімум конфліктів даних завдяки єдиному джерелу істини.
• Швидке налаштування (від 4 годин) та низька вартість підтримки.

Покрокова інструкція з налаштування

1. Налаштуйте модуль обміну в адмінпанелі Бітрікс: Адміністрування → Налаштування → Налаштування продуктів → Інтернет-магазин.
2. Вимкніть передачу контентних полів (DETAIL_TEXT, PREVIEW_PICTURE тощо).
3. Додайте обробник OnIBlockElementBeforeUpdate для захисту.
4. Налаштуйте регламентне завдання на стороні 1С для автоматичного вивантаження.
5. Протестуйте обмін: повне вивантаження, часткове, сценарій деактивації.

Замовте налаштування одностороннього вивантаження «під ключ» у нас — забезпечимо стабільну роботу. Для консультації пишіть на пошту або залиште заявку — ми безкоштовно оцінимо ваш проект. Наша компанія працює з 2014 року, має 10+ років досвіду, 40+ реалізованих проектів та сертифікацію 1С-Бітрікс.