1) Перевірка ліцензій.
--
Для роботи необхідно мати наступний перелік ліцензій (актуально для LT-клієнтів):
- АРІ Payment
- API Cloud
- Delivery
Якщо чогось з цього немає - дозамовити, попередньо погодивши вартість ліцензій з клієнтом

2) API-ключ
--
Заходимо в веб-офіс клієнта. В розділі Зовнішні замовлення переходимо в Live API Settings (скрін 1) і натискаємо Створити інтеграцію (скрін 2). В налаштуваннях вказуємо для нього відповідне ім'я, пошту і обов'язково вказуємо для нього Шаблон прав - Усі права (скрін 3). В заключення, додаємо доступ цьому ключу до необхідних закладів на вкладці Підключені точки (скрін 4). За вебхуки в інструкції немає нічого, тому цей пункт пропускаємо

3) Включити API Transport в термінальній групі
--
В цьому пункті спочатку з'ясувати з клієнтом, куди саме мають приходити замовлення з Чойсу. Можливо доведеться виводити конкретний термінал в окрему групу (всі ж пам'ятають, що замовлення з інтеграцій приходять на головний термінал в групі, правда?)
Згідно з цією йдемо на вкладку Ресторани, вибираємо заклад, який нас цікавить (скрін 1), і ставимо галку про активацію API Transport в необхідній групі (скрін 2). Після цього, натискаємо на кнопку в стовпчику Id і передаємо те що нам скопіювалось в буфер обміну, клієнту або інтегратору (скрін 3). Це айді термінальної групи, куди будуть приходити доставки

4.1) Плагін на касі \ створення співробітника
Сам плагін - тут
Підкидуємо на головну касу, куди мають приходити доставки (ту що ми вибрали в попередньому пункті).
Більше з плагіном на касі нічого не робимо.

Паралельно в цьому ж пункті можна перевірити, чи нормально йде обмін даними з API Transport на касі
--
Для цього відкриваємо лог plugin-Resto.Front.Api.iikoTransportX (де Х - це версія плагіну. Наприклад plugin-Resto.Front.Api.iikoTransportV9.Preview2). В ньому ми маємо побачити рядок:
Handshake was successful; RMQ connection is alive [HandshakeInterval: 00:01:00, LogLevel: Info].
Якщо в лозі бачимо це - значить все добре і переходимо до наступного кроку. Як ні - виправляємо і йдемо далі

4.2) Щодо співробітника - він створюється за наступними принципами:
Якщо заклад в Chain - створювати в Chain + пошарити на всі точки
Якщо звичайний РМС без Chain - відповідно створюємо в РМС

• Ім'я в системі: choice
• Логін і пароль: choice
• ПІН-код: згенерувати і надати колегам з Чойсу
• Посада: Choice (створити нову посаду)
• Обов'язково встановлена галка: "Тільки для плагінів" (!)
• Права доступу:

5) Вивантаження меню
В цьому пункті наша задача - проговорити з клієнтом нюанси того. як це робити. Тут є декілька ключових тез.

5.1) Яким чином клієнт буде робити вивантаження меню?
Нагадуємо, що вивантаження меню може відбуватися за двома сценаріями, а саме:
5.1.1) Окремо у кожному РМСі (по дефолту)
5.1.2) Централізовано з Chain'y (потрібно включити, приклад заявки на цю тему: #EJG-30603)
Це ми з клієнтом маємо проговорити ПЕРШОЧЕРГОВО, до початку всіх інших налаштувань щодо вивантаження меню!

Чи працював клієнт з вивантаженням меню раніше?
Якщо працював - перепитуємо у Choice (чи клієнта відправляємо перепитати) - як то має бути
Якщо ні - то проговорюємо, що для вивантаження меню треба створити кореневу папку CHOICE і всі страви для вигрузки додавати саме в неї

В заключення даємо відео-інструкцію і перепитуємо чи впораються самостійно
Відео-інструкція нижче (поки що тут пусто, чекаємо на перезйомку від Максима)

6) Додаткові номенклатурні позиції
В цьому пункті нам треба створити дві послуги і дві страви:

6.1) "Доставка"
--
Тип номенклатури - Послуга
Галка "Не бере участі в русі по складу"
Галка "Вільна ціна"
Тип місця приготування - ОБОВ'ЯЗКОВО проговорюється з клієнтом в залежності від того, на яку касу має закриватись позиція і чи має виходити на неї зустрічка

6.2) "Чайові"
--
Тип номенклатури - Послуга
Галка "Не бере участі в русі по складу"
Галка "Вільна ціна"
Тип місця приготування - ОБОВ'ЯЗКОВО проговорюється з клієнтом в залежності від того, на яку касу має закриватись позиція і чи має виходити на неї зустрічка

6.3) "Пакування"
--
Тип номенклатури - Страва
Галка "Вільна ціна"
Тип місця приготування - ОБОВ'ЯЗКОВО проговорюється з клієнтом в залежності від того, на яку касу має закриватись позиція і чи має виходити на неї зустрічка
Тех. карта - або порожня, або внести туди пакування, яке потрібно враховувати клієнту

6.4) "Прибори"
--
Тип номенклатури - Страва
Галка "Вільна ціна"
Тип місця приготування - ОБОВ'ЯЗКОВО проговорюється з клієнтом в залежності від того, на яку касу має закриватись позиція і чи має виходити на неї зустрічка
Тех. карта - або порожня, або внести туди прибори, які потрібно враховувати клієнту

7) Типи оплат
--
В цьому пункті потрібно налаштувати додаткові ТО для Чойсу, АЛЕ спочатку потрібно обговорити з клієнтом деякі нюанси цих типів оплати:
7.1) Чи мають ці типи оплати фіскалізуватись? Бо якщо не мають, потрібно буде перероблювати схему роботи
7.2) На який ФОП мають закриватись такі оплати? Бо може бути що клієнт завів під Чойс собі окремого ФОПа і ніде його не налаштував, відповідно треба буде робити під нього окрему касу/групу і налаштовувати роботу
7.3) Спочатку для стандартних ТО "Готівка" і "Банківська картка" потрібно включити можливість прийматись ззовні (галка Може прийматися ззовні) і вказати коди CASH та CARD відповідно.

Далі налаштування окремих типів оплати:
--
Найменування - CHOICE
Тип - Банківська картка
Галка Може прийматися ззовні
Проведення оплати - Як ззовні, так і на стороні ресторану
Код - CHOI
Галка Є фіскальним (в залежності від того, чи погодили його фіскальність в розмові з клієнтом)

Найменування - Online
Тип - Банківська картка
Галка Може прийматися ззовні
Проведення оплати - Як ззовні, так і на стороні ресторану
Код - ONLI
Галка Є фіскальним (в залежності від того, чи погодили його фіскальність в розмові з клієнтом)

Найменування - Bolt Online
Тип - Банківська картка
Галка Забороняти вводити вручну (зняти при необхідності роботи з цією інтеграцією через Чойс. По замовчуванню - ставимо, щоб не вибирали на касі)
Галка Може прийматися ззовні
Проведення оплати - Як ззовні, так і на стороні ресторану
Код - BOLT
Галка Є фіскальним (в залежності від того, чи погодили його фіскальність в розмові з клієнтом)

Найменування - Glovo Cash
Тип - Банківська картка
Галка Забороняти вводити вручну (зняти при необхідності роботи з цією інтеграцією через Чойс. По замовчуванню - ставимо, щоб не вибирали на касі)
Галка Може прийматися ззовні
Проведення оплати - Як ззовні, так і на стороні ресторану
Код - GCAS
Галка Є фіскальним (в залежності від того, чи погодили його фіскальність в розмові з клієнтом)

Найменування - Glovo Online
Тип - Банківська картка
Галка Забороняти вводити вручну (зняти при необхідності роботи з цією інтеграцією через Чойс. По замовчуванню - ставимо, щоб не вибирали на касі)
Галка Може прийматися ззовні
Проведення оплати - Як ззовні, так і на стороні ресторану
Код - GONL
Галка Є фіскальним (в залежності від того, чи погодили його фіскальність в розмові з клієнтом)

8) Робота з доставками
--
В заключення, перепитати у клієнта, чи працював він з доставками.
Якщо так - то все добре

Якщо клієнт НЕ працював з розділом "Delivery" - то потрібно передати задачу команді впровадження, бо далі точно підуть ось такі питання:
8.1) Права доступу. Які права потрібні адміністраторам на точці для роботи з доставками, які права треба кур'єрам і т.д.
8.2) БагатоФРність. Яким чином будуть розподілятись по касам замовлення Чойса. Дивимось п. 7 для цього.
8.3) Кур'єрський додаток. Чи будуь користуватись? Чкщо так - проговорити вартість
8.4) Тонкі налаштування доставки. Все що стосується пунктів "Загальні налаштування" та "Графік роботи та картографія" в блоці Доставка
8.5) Довідник вулиць. Якщо в них немає - залити вулиці