Як інтегрувати POS та доставку з сайтом ресторану на 1С-Бітрікс

Властивості елемента (страви):

• WEIGHT — числове, грам. Виводиться на картці та в Schema.org розмітці
• CALORIES — числове, ккал. Опціонально — розширений блок: білки, жири, вуглеводи (три окремі властивості PROTEINS, FATS, CARBS)
• ALLERGENS — множинний список: глютен, лактоза, горіхи, морепродукти, яйця, соя. Фільтрація по алергенах через CIBlockElement::GetList() з PROPERTY_ALLERGENS у фільтрі
• PRICE — числове. Не через модуль catalog, якщо не потрібен кошик — звичайна властивість інфоблоку. Якщо потрібна онлайн-оплата — підключення до торговельного каталогу через CCatalog::Add()
• PHOTO — файл. Основне фото страви. Додаткові фото — множинна властивість MORE_PHOTOS
• IS_NEW — чекбокс. Позначка «Новинка» для виділення в списку
• IS_SPICY — чекбокс. Позначка гострої страви
• STOP_LIST — чекбокс. Страва тимчасово недоступна (закінчився інгредієнт). Елемент не видаляється, а приховується за фільтром у шаблоні компонента
• SORT_ORDER — числове. Порядок всередині розділу, дозволяє шеф-кухарю через адмінку виставити фірмові страви першими

Для ресторанів із сезонним меню додається властивість SEASON (множинний список: весна, літо, осінь, зима) та фільтрація за поточним сезоном у component.php.

Бронювання столиків

Кастомний компонент project:table.reservation з формою: дата, час, кількість гостей, ім'я, телефон, коментар. Дані записуються в Highload-блок «Бронювання». Столики — окремий Highload-блок. При бронюванні компонент перевіряє доступність: вибірка з Highload-блоку бронювань по DATE + TIME з вікном ±2 години, зіставлення з місткістю вільних столиків. Якщо вільних столиків немає — пропозиція найближчого доступного часу.

Інтеграція з Бітрікс24 CRM: кожне бронювання створює лід через CRest::call('crm.lead.add', [...]). Хостес бачить бронювання в CRM та підтверджує їх. Статус ліда «Підтверджено» → обробник оновлює STATUS у Highload-блоці → клієнту приходить SMS.

Фотогалерея та оптимізація зображень

Фуд-фотографія — важкі файли (5-10 МБ). На сайті потрібні три розміри: thumbnail (400x300), середній (800x600), full-size (1600x1200). Ресайз через CFile::ResizeImageGet(). Для WebP — конвертація через imagewebp(). srcset для Retina:

<img src="/upload/resize_cache/menu/800x600/dish.webp" srcset="/upload/resize_cache/menu/400x300/dish.webp 400w, /upload/resize_cache/menu/800x600/dish.webp 800w, /upload/resize_cache/menu/1600x1200/dish.webp 1600w" sizes="(max-width: 640px) 400px, (max-width: 1024px) 800px, 1600px" loading="lazy" alt="Меню ресторану: стейк рібай — опис страви" > 

Атрибут loading="lazy" — нативне ліниве завантаження. Для старих браузерів — IntersectionObserver. На сторінці меню з 50+ стравами це економить 30-40 МБ початкового завантаження.

Mobile-first: 80% трафіку з телефонів

За даними дослідження компанії DataReportal, понад 80% відвідувачів ресторанних сайтів заходять з мобільних пристроїв. Шаблон будується mobile-first:

• Меню категорій — горизонтальний скрол з overflow-x: auto, не випадаючий список
• Картка страви — фото на всю ширину, назва, вага, ціна. Кнопка «Додати» зафіксована внизу екрану через position: sticky
• Форма замовлення — мінімум полів. Телефон + адреса. Ім'я та коментар — опціонально. Автозаповнення адреси через Dadata API (POST https://suggestions.dadata.ru/suggestions/api/4_1/rs/suggest/address)
• Форма бронювання — нативні <input type="date"> та <input type="time"> замість кастомних datepicker-ів

Адаптивність — CSS Grid + Flexbox. Breakpoint-ів три: 375px, 768px, 1280px. Тестування через Lighthouse: цільові показники Performance > 90, LCP < 2.5s.

Мультимовне меню

Для ресторанів у туристичних зонах — меню кількома мовами. Реалізується через окремий сайт в системі багатосайтовості: LID = s1 для української, s2 для англійської. Інфоблоки прив'язані до обох сайтів, властивості NAME_EN, DESCRIPTION_EN — додаткові текстові властивості. Різні URL (/menu/ та /en/menu/), коректні hreflang-теги, незалежні SEO-налаштування.

Schema.org: Restaurant + Menu

У result_modifier.php формується JSON-LD розмітка для Rich Snippets у пошуковій видачі. Типи Restaurant, Menu, MenuItem — окремі сутності Schema.org.

Акції та спецпропозиції

Інфоблок «Акції» (тип promotions). Властивості: DATE_START, DATE_END, PROMO_TYPE, DISCOUNT_PERCENT, LINKED_DISHES. Виведення на головній через news.list з фільтром по датах. Для бізнес-ланчу — окремий розділ меню з обмеженням за часом (12:00-16:00).

Заходи ресторану

Інфоблок «Заходи» — для анонсів: жива музика, тематичні вечори, дегустації. Виведення — стрічка на головній (три найближчі заходи) та окрема сторінка /events/. Минулі заходи переміщуються в архів автоматично.

Інтеграція з зовнішніми системами

Онлайн-замовлення ресторан та інтеграція з POS-системами

Це технічно найнавантаженіша частина проєкту. Ресторан працює з касовою системою — iiko, r_keeper або Poster. Сайт має не просто приймати замовлення, а передавати їх у касу в реальному часі та отримувати зворотний зв'язок: підтвердження, час приготування, статус.

Архітектура взаємодії з iiko:

iiko надає iiko Transport API (раніше iiko Biz API). Авторизація — по apiLogin, отримання токена через POST /api/1/access_token. Токен живе 60 хвилин, кешується в $_SESSION або в Highload-блоці з TTL.

Створення замовлення — POST /api/1/deliveries/create. Тіло запиту містить:

{ "organizationId": "...", "order": { "phone": "+380...", "orderTypeId": "...", "items": [ { "productId": "iiko-product-uuid", "amount": 2, "modifiers": [...] } ], "address": { "street": "...", "house": "...", "flat": "..." }, "comment": "Без цибулі" } } 

Критичний момент — маппінг productId. В інфоблоці Бітрікс у кожної страви зберігається властивість IIKO_PRODUCT_ID (рядок, UUID з iiko). При синхронізації меню через GET /api/1/nomenclature завантажується повний каталог iiko та зіставляється з елементами інфоблоку за цим UUID. Синхронізація запускається агентом CAgent раз на 15 хвилин або по вебхуку з iiko.

Синхронізується з iiko в Бітрікс:

• Наявність страви (стоп-лист). iiko надсилає POST на webhook-endpoint /api/iiko-stoplist/. Обробник оновлює властивість STOP_LIST у відповідного елемента інфоблоку через CIBlockElement::SetPropertyValuesEx()
• Ціна. Якщо ресторан змінює ціни в касі, вони мають приїхати на сайт. Обробник в агенті порівнює ціни з /api/1/nomenclature з PRICE в інфоблоці та оновлює розбіжності
• Модифікатори (добавки, гарніри). Зберігаються в окремому інфоблоці «Модифікатори» з властивістю IIKO_MODIFIER_ID

Відправляється з сайту в iiko:

• Замовлення з позиціями, адресою, коментарем
• Тип оплати (онлайн або при отриманні)
• Промокод, якщо є — знижка розраховується на стороні iiko

Інтеграція з r_keeper:

r_keeper використовує UCS DeliveryPOS API. Принцип аналогічний, але протокол — XML-RPC. Запити обгорнуті в XML-конверт, відповіді парсяться через SimpleXMLElement. Маппінг товарів — по MenuItemID. Основна складність — r_keeper вимагає VPN-тунель до сервера ресторану, тоді як iiko працює через хмару.

Інтеграція з Poster POS:

Poster надає REST API з OAuth-авторизацією. Створення замовлення — POST /api/incomingOrders.createIncomingOrder. Poster простіший в інтеграції: JSON API, хмарне розгортання, webhook для оновлення статусу замовлення. Маппінг — по product_id з Poster.

Обробка статусів замовлення: два підходи — polling (агент раз на 60 секунд) або webhook (переважний для iiko та Poster). Статуси: «Прийнято», «Готується», «В дорозі», «Доставлено». Відображаються клієнту на сторінці /my-orders/ через AJAX-опитування кожні 30 секунд.

Інтеграція з агрегаторами доставки

Яндекс.Їжа та Delivery Club надають API для ресторанів-партнерів. Інтеграція двостороння:

• Вивантаження меню — формування XML/JSON-фіда з позиціями, цінами, фото, стоп-листом. Фід генерується агентом раз на 30 хвилин з інфоблоку «Меню»
• Прийом замовлень — webhook від агрегатора на /api/aggregator-order/. Обробник створює замовлення в Highload-блоці та передає в POS-систему

Етапи та вартість розробки

1. Проєктування (1-2 тижні) — структура інфоблоків, схема інтеграції з POS, прототипи сторінок, маппінг даних
2. Дизайн (1-2 тижні) — макети: головна, меню, бронювання, доставка, акції
3. Бекенд (2-4 тижні) — інфоблоки, компоненти, інтеграція з POS, CRM, обробка замовлень
4. Фронтенд (1-3 тижні) — адаптивні шаблони, оптимізація зображень, форми, AJAX-оновлення
5. Інтеграції (1-2 тижні) — POS, агрегатори, SMS, платіжна система
6. Тестування (1-2 тижні) — функціональне, тестові замовлення, мобільне, навантажувальне
7. Запуск (3-5 днів) — деплой, моніторинг синхронізації, перевірка на реальних замовленнях

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

• Документація з архітектури та API
• Доступи та демо-доступ для замовника
• Навчання адміністратора та офіціантів
• Підтримка протягом 30 днів після запуску

Орієнтовна вартість

Терміни та вартість залежать від обраної POS-системи, кількості мов та вимог до особистого кабінету. Пишіть нам — оцінимо ваш проект безкоштовно.