Вызовы внешнего протокола зависят от настроек системы лояльности на объекте. Теоретически, на каждом объекте могут быть свои настройки и определяет это администратор системы, на практике обычно вся сеть объектов работает по одному правилу.
В любом случае, при настройках интеграции с CRM-системой стоит убедиться, что объект использует актуальную версию программного обеспечения Премьера.
Рассмотрим различные случаи настроек.
Наиболее простой случай - на объекте нет интеграции с карточной системой (системой лояльности). Не нужно использовать функцию Login, любые запросы можно выполнять без указания параметра CardCode, в том числе запросы для продажи - SaleReservation / SaleApproved.
Общий механизм вызова запросов:
Формат указания CardCode (в т.ч. префиксы, постфиксы) зависит исключительно от настроек системы / формата карточных счетов, определяется и согласовывается с администрацией объекта.
Авторизация карты происходит с помощью вызова запроса Login, указывая код карты CardCode, при этом обязательно нужно указать Password или CardPIN (фейковый, если в самой карточной системе не реализована аутентификация карт). Далее карта считается авторизованной то количество времени, которое указано в настройках протокола (по умолчанию 15 минут).
В течение этого времени можно выполнять запросы, указывая CardCode. Стоит обратить внимание, что CardCode нужно заполнять в том числе для не продажных запросов (например, GetHallPlan), поскольку ответ этих запросов может отличаться для разных клиентов (для разных CardCode).
Если на объекте настроена система лояльности, а продажу нужно провести для потенциально неизвестного гостя, то применяют один из двух подходов:
В первом случае в системе лояльности нужно завести особый карточный счет по согласованию с администрацией объекта и именно его указывать в параметре &CardCode. В этом случае протокол будет связываться с карточной системой, валидировать карту и отправлять CRM-системе данные о транзакциях.
Во втором случае протокол НЕ будет связываться с карточной системой и CRM-система ничего не узнает о продажах, проведенных для гостей.
Данный режим активируется, если среди остальных параметров запроса указать параметр &IgnoreCSError=1.
Допустимо в случае наличия карточной системы вместо передачи валидного CardCode указывать данный параметр с учетом особенностей, указанных выше. Делать авторизацию карты в таком случае не нужно.
Стоит учесть, что параметр IgnoreCSError появился в последних версиях протокола 3.22.R8.
Если нужно, чтобы клиенту начислялся бонус за покупку, то следует в запросе SaleReservation указывать параметр BonusID, согласованный с администрацией объекта. При этом BonusID зависит не от номера карты и/или клиента, а от типа бонуса, который будет начислен клиенту за данную покупку.
Это описано в запросе SaleApproved:
Параметр PayByBonus должен быть вида: [payan=AN], где:
Пример запроса
ServiceID=1&QueryCode=SaleApproved&CardCode=101&ReservationID=kk005&Seasons=&Encoding=Windows-1251&Expect=&PayByBonus=[payan=01.00004.00000615.0001]
Частично оплачивать не стоит.
Ошибки, касающиеся бонусов:
Чтобы купить билет со скидкой - нужно в запросе на резервирование указывать параметр discount (описано в статье про SaleReservation) для каждого места.
Например, клиент покупает билет за 100 рублей, применил скидку 20%. Оплатил рублями. Система настроена, что с каждых 10 рублей идет бонус 1. В итоге, в CRM мы имеем три транзакции:
Вся эта информация отсылается в систему лояльности.
Существуют два типа отмены из-за двухфазности процесса продаж:
При валидном указании параметра «CardCode» при вызове SalePayReturn на объекте с настроенной системой лояльности автоматически будут списаны бонусы, начисленные при продаже. Также, в случае, если оплата была бонусами - то они будут возвращены на бонусный счет клиента.