BMS. Доработка загрузки заказов из XML

• BMS разрабатывает мобильное приложение для ресторанов Молли
• Мобильное приложение будет интегрировано с Юпитером через API JPOS (документация)
• Мобильное приложение выступает в роли JPOS
• В мобильном приложении можно будет оплатить заказ бонусами BMS. Нужно в Юпитере реализовать возможность принимать оплату бонусами.
• Для этого нужно сделать доработки сервера JPOS:
  • Добавляем новый режим работы сервера "Работа с системой BMS". Включается в ролях.
  • В запросе  файле с заказом, BMS передает параметры:
    • Сумма потраченных бонусов bonus_trat
    • Сумма накопленных бонусов bonus_nach
  • Если bonus_trat или bonus_nach !== 0, то Юпитер добавляет в заказ бонусную операцию BMS.
  • Алгоритм работы с бонусными операциями такой же как и при работе с бонусами на кассе. За исключением некоторых особенностей: 
    • Юпитер НЕ вызывает функции из DLL BMS (т.е. не отправляет никакие запросы)
    • Юпитер фиксирует в заказе признак, что эта бонусная операция с приложения. Если в заказе стоит признак, что бонусная операция пришла с приложения, то отмена операции должна выполняться по особому алгоритму (описан ниже).
    • Т.к. у бонусной операции с приложения нет RNN, нужно скорректировать процедуры добавления бонусных операций, так чтобы отсутствие RNN не считалось ошибкой.

 

Порядок добавления бонусной операции:

• В заказ добавляется скидка "Скидка ВсеВПлюсе" на сумму потраченных бонусов (параметр bonus_trat)
• В заказ добавляется наценка "принято в счет оплаты бонусов" на сумму накопленных бонусов  (параметр bonus_nach)
• Заказ блокируется для любых последующих изменений. Для разблокировки, нужно отменить операцию на кассе.
• При закрытии заказа сумма операции накопления выделяется в отдельный вид оплаты "Оплата зач.карт" (фискальный 3 или 4)
• При этом НИКАКИЕ запросы и вызовы команд из DLL BMS Юпитер не делает

Порядок отмены бонусных операций с приложения:

• Если в заказе стоит признак, что бонусная операция пришла с приложения, то
• Вместо вызова DLL, Юпитер отправляет запрос:

POST {URL}?retail_point_id={TT_ID}
--header 'AuthorizationDelivery: Basic {API_KEY}' \
--header 'ProjectID: {PRJ_ID}' \
--header 'Content-Type: appl	ication/json' \
--data-raw '{
  "order_id": {ORDER_ID}",
}'

Пример:
curl --location --request POST 'https://delivery-bmsadmin.bms.group/orders/cancel?retail_point_id=number' \
--header 'AuthorizationDelivery: Basic string' \
--header 'ProjectID: string' \
--header 'Content-Type: application/json' \
--data-raw '{
  "order_id": "string",
}'
>>>>>>>>>>>>>>>>>
{
    "status": “ok”
}

• • URL - должен задаваться в настройках Юпитера (config.json)
  • TT_ID - идентификатор точки, такой же как в QR. Задается в торговом зале, поле "Код для внешних систем".
  • API_KEY - должен задаваться в настройках Юпитера (config.json)
  • PRJ_ID - должен задаваться в настройках Юпитера (config.json)
  • ORDER_ID - uid заказа в Юпитере
• Если Юпитер не получил в ответ status = ok, то операция отмены не выполняется. Заказ остается заблокированным.