Налаштування обміну 1С:Громадське харчування і 1С-Бітрікс
Громадське харчування — галузева конфігурація з власною логікою номенклатури: тут є страви, техкарти, модифікатори, напівфабрикати. Інтернет-магазин або сайт доставки їжі на Бітрікс очікує іншу структуру даних, ніж звичайний товарний каталог. Це і є головна складність інтеграції.
Номенклатура в Громадському харчуванні: що відрізняється
У 1С:Громадське харчування довідник «Номенклатура» розширено специфічними видами: Страви, Напівфабрикати, Товари, Послуги. Для сайту доставки потрібні тільки «Страви» (іноді «Товари» — напої в упаковці). Напівфабрикати на сайт не вивантажуються — це внутрішні об'єкти виробництва.
Модифікатори. Страва «Піца Маргарита» може мати модифікатори: розмір (25/30/35 см), тип тіста (тонке/пишне), додаткові топінги. У 1С:Громадське харчування модифікатори — це окремий довідник, прив'язаний до страви через «Групи модифікаторів». У CommerceML стандартного тегу для модифікаторів немає — їх потрібно передавати через ДодатковіРеквізити або через характеристики.
На стороні Бітрікс модифікатори реалізуються як торговельні пропозиції (SKU) або як кастомні властивості з JSON-структурою. Обидва підходи робочі; SKU простіший для стандартного каталогу, JSON — гнучкіший для складних комбінацій.
Схема передачі модифікаторів через характеристики
Налаштування в 1С:Громадське харчування: у вивантаженні вмикаємо передачу груп модифікаторів як характеристики страви.
<!-- Приклад XML для страви з модифікаторами -->
<Товар>
<Ід>abc-123</Ід>
<Найменування>Піца Маргарита</Найменування>
<ХарактеристикиТовару>
<ХарактеристикаТовару>
<Ід>size-25</Ід>
<Найменування>Розмір 25 см</Найменування>
<Ціна>450</Ціна>
</ХарактеристикаТовару>
<ХарактеристикаТовару>
<Ід>size-30</Ід>
<Найменування>Розмір 30 см</Найменування>
<Ціна>650</Ціна>
</ХарактеристикаТовару>
</ХарактеристикиТовару>
</Товар>
Бітрікс читає характеристики і створює SKU. Для кожного SKU — своя ціна. Це працює для простих модифікаторів (розмір). Для складних комбінацій (розмір × тісто × топінги) кількість SKU вибухово зростає: 3 розміри × 2 тісти × 10 топінгів = 60 SKU на одну страву. У такому випадку правильніше передавати модифікатори як JSON у користувацькому властивості страви і обробляти їх на фронтенді.
Меню та категорії
У 1С:Громадське харчування меню — це окремий об'єкт, який прив'язує страви до торгових точок і часу доби. На сайті це зазвичай просто розділи каталогу (Гаряче, Холодне, Напої). Маппінг: «Тип номенклатури» або «Група номенклатури» у Громадському харчуванні → розділ інфоблоку в Бітрікс.
Проблема: одна страва може входити до кількох категорій меню (наприклад, «Бізнес-ланч» і «Основні страви»). Стандартний CommerceML передає одну групу. Множинну прив'язку до розділів потрібно реалізовувати через кастомний обробник або додаткову властивість «Додаткові категорії».
Обмін замовленнями: від Бітрікс до Громадського харчування
Замовлення доставки їжі з сайту повинні потрапляти в 1С:Громадське харчування як «Замовлення на доставку» або «Продаж». Стандартний CommerceML створює замовлення покупців, але в Громадському харчуванні потрібна прив'язка до адреси доставки, часу доставки та зони.
Адреса доставки передається через властивості замовлення. У Бітрікс — стандартні поля профілю покупця. У XML замовлення вони потрапляють до секції Контрагент → Адреси. Громадське харчування при імпорті може не прочитати нестандартні поля адреси — потрібен обробник на стороні 1С.
Кейс: мережа піцерій
Мережа з 8 піцерій: єдиний сайт на Бітрікс, у кожній точці — своя база 1С:Громадське харчування (не центральна). Завдання: єдиний каталог із цінами (ціни однакові), але замовлення повинні потрапляти до бази конкретної точки за зоною доставки.
Рішення: центральне вивантаження каталогу з «майстер»-бази Громадського харчування в Бітрікс (один раз на добу). Замовлення маршрутизуються на сайті: визначається зона доставки за адресою → вибирається endpoint конкретної точки → замовлення надсилається до потрібної бази Громадського харчування.
Кожна база Громадського харчування має власний URL обміну в Бітрікс (кілька вузлів обміну в Бітрікс, один на кожну точку). Маршрутизатор — кастомний компонент у local/components/.
Час впровадження: 12 робочих днів з урахуванням тестування всіх точок.