Для полноценной работы API доставки необходимо выполнить несколько дополнительных настроек. API работает с версиями RK7 7.6.4+ На версии RK7 7.6.2 - работать не будет.
Для возможности получения меню внешней системой необходимо определить для доставки список блюд, видимых через API.
Важно!
API доставки не поддерживает комбо-блюда, а также блюда с дробным количеством (весовые).
Для предотвращения программных ошибок и проблем с сохранением заказов воздержитесь от использования таких блюд для внешних заказов.
Для автоматического добавления блюд из интернет заказа необходимо добавить скрипт в форму редактирования заказа доставки.
procedure DesignFormOnShowScript(Sender: TObject); var res:string; iport:string; begin iport := '192.168.1.7:11011'; //IP адрес и порт DeliveryHatch if not RKCheck.valid then Exit; if httpget('http://'+iport+'/api/int/orderitems?guid='+RKCheck.CurrentOrder.guidstring, res) <> 0 then begin GUI.ShowMessage('Minidlv/orderitems. '+iport+' Не доступен.'); end; end;
При настройке использования схемы форм с данной формой не задавайте категорию заказа. «Старый серый» интерфейс кассы рк7 использовать нельзя.
Чтобы иметь возможность получать с сайта (через API) заказы с уже произведённой оплатой - в rk7 должно быть включено использование предоплат. Оплата заказа через API добавляется в заказ как «Предоплата». Так сделано для того, чтобы заказ не закрывался сам сразу же, а оставался «висеть» в списке заказов до тех пор, пока персонал ресторана не закроет его вручную.
Для корректной работы такого механизма следует настроить параметр: Настройки → Параметры → Использование опций → Печатные документы → Учет предоплат → Не учитывать
Нужно выбрать именно значение «Не учитывать», это не то же самое что «без предоплат». Если в ресторане предоплаты используются по настоящему - сделайте исключение параметра и привяжите его категории заказа доставки.
Валюта и причина внесения денег для приема предоплат указывается в DeliveryHatch.ini - rkPayCode и rkPayReasonCode соответственно.
В стандартном случае, когда платёжным шлюзом является «Робокасса» и подключена услуга «Робочеки» - валюту «Олата на сайте» есть смысл делать нефискальной, т. к. фискальный чек гостю отправляет «Робокасса» от своего имени и повторно печатать его нет необходимости. Пример настроек валюты и причины внесения:
В файл DeliveryHatch.ini в секцию [RK] добавьте новый параметр: rkMenuCateg
Этот параметр определяет классификацию блюд, с которой будет работать API доставки.
Значением данного параметра необходимо указать идентификатор классификации «Использовать для интернет-заказов»
С версии 3.0.5.1053 в секцию [RK] можно добавить параметр rkHitCateg
Параметр определяет категорию меню для пометки блюд как «Популярное» во внешних системах
Значением данного параметра необходимо указать идентификатор категории «Да» классификации «Популярно для доставки»
C версии 3.1.8.1521 в доставку добавлена поддержка модификаторов блюд.
С версии 3.1.8.1616 добавлен механизм фильтрации служебных модификаторов по весу. Теперь через API доступны только модификаторы, вес которых больше нуля. Отключить фильтрацию по весу можно в DeliveryHatch.ini в сексии RK с помощью параметра rkFilterModiWeights. Установить значение - 0.
В том же файле добавьте новую секцию «[APITOKEN]», в которой перечислите все токены, с которыми смогут работать внешние системы.
Токен для каждой внешней системы нужно придумать самостоятельно!!!
Сделать это можно при помощи генераторов паролей
Один токен-одна строка-один внешний клиент. Строка обязательно должна заканчиваться символом «=». Символ «=» обозначает окончание токена и не принадлежит ему. Т.е. в запросах токен использовать БЕЗ знака «=»
Для чего нужно использовать несколько разных токенов? \\ Пример: Наш ресторан принимает заказы с собственного сайта, а так же сотрудничает с 2-мя агрегаторами. Все эти источники работают через одно и то же API мини-Доставки. На этапе подключения заводим для каждого источника уникальный токен. В случае если мы перестаем работать с каким то из агрегаторов, то достаточно будет удалить выданный им токен из конфигурационного файла и данный источник не сможет больше выполнять запросы к API ресторана.
После редактирования DeliveryHatch.ini перезапустите модуль мини-доставки.
Последним этапом необходимо открыть сетевой порт для внешнего IP заведения, ведущий в порт доставки. Как это сделать - зависит от конкретного оборудования в заведении.
Важно помнить, что доставка ограничивает доступ к стандартному WEB интерфейсу для запросов, адресованых не на один из IP адресов, принадлежащих компьютеру, где установлена доставка.
То есть невозможно получить доступ к стандартному графическому интерфейсу не из локальной сети.
Для этого есть сервис тестирования: https://dev.carbis.ru/test
Необходимо ввести параметры подключения к вашему экземпляру, если при работе с API планируется использование оплат, то включить соответствующий параметр, и после этого запустить проверку. При корректно выполненной настройке, в модуле мини-Доставка появится новый внешний заказ и оплата (если был выставлен соответствующий признак). Если на каком то этапе тестирования возникнут ошибки, то в будут указаны возможные причины их возникновения и рекомендации по их устранению. PS Сервис находится в режиме beta-тестирования. В случае получения ошибки вида «Access Violation XXX» просто запустите тест еще раз.