Чтобы осуществить успешность внедрения общеупотребительной программы любому отдельно взятому клиенту, необходимо повторить бизнес-процессы, уже наработанные клиентом до начала пользования программой, а не предлагать ему жесткий безвариантный подход. Это много раз доказано на практике, но не всегда применяется из-за невозможности предусмотреть на этапе проектирования программы все возможные условия и взаимосвязи в бизнес-процессах каждого отдельного клиента. Альтернативный подход заключается в создании платформы с набором возможностей, а сама конфигурация и взаимосвязи правятся в процессе внедрения программы у клиента с учетом всех его пожеланий. Именно этот подход используется в этой программе. Минусы этого подхода заключаются в освоении и поддержке отдельного языка или же синтаксического набора условий (конфигурационного файла), описывающего настраиваемые сущности и увеличении стоимости и длительности внедрения. Скрасить ситуацию может подготовленный перед внедрением набор заготовок и часто используемых условий. Собственно, в туризме, где каждое турагентство или туроператор работают по-своему, гибкость и управляемость программы может быть поставлена во главу угла.
В этой программе полем для настроек под клиента являются главным образом шаблоны входных форм. Шаблоны входных форм описывают саму входную форму для набивки данных заявки, возможные действия над заявкой при определенных её состояниях, а также набор и политику выходных документов, каждый из которых в момент создания может влиять на заявку и на другие выходные документы. Набор входных форм способен охватить все разнообразие поставляемых услуг и поддержать условия каждого отдельного направления туризма. Скажем, внутренний туризм отличается от внешнего количеством необходимых входных данных клиента, набором и разнообразием услуг, соответственным набором выходных документов, и, быть может, даже логикой обработки заявки. Для реализации этой разницы достаточно создать два шаблона входных форм - для внешнего и для внутреннего туризма, а затем прикрепить к каждому соответствующий набор выходных документов.
Технически код выходного документа состоит из двух частей:
Агенты не являются обычными пользователями в системе. Они работают с правами гостя, хотя и проходят авторизацию. Авторизация агентов создана с возможностью централизации базы аккаунтов для облегчения администрирования нескольких независимых филиалов оператора или нескольких операторов. Каждый агент имеет только один агентский логин для входа на сайты ТО, которые привязаны к одному центру авторизации агентов. Уникальность логинов обеспечивается привязкой к уникальным параметрам юридического лица (финансовые и юридические данные). Логин генерируется транслитерацией и упрощением имени организации агента, пароль генерируется автоматически случайным набором символов.
Привязка конкретного сайта конкретного ТО к единому центру авторизации (или к своему собственному), а также поддержка авторизации агентов и регистрации новых агентов настраивается администратором на странице администраторских параметров модуля «Турпутевка» следующими параметрами: VoucherAgentAuth, VoucherCentralGateURI, VoucherAgentRegisterNew. Для запуска демона авторизации на сайте ТО или центральном сайте нескольких ТО (филиалов ТО) нужно запустить команду tsvchr_xmlrpcd с привязкой к конкретному виртуалхосту TS-движка, сконфигурированному на этом же хосте. Для привязки используется к виртуалхосту ключ командной строки --host. Прочие параметры смотрите в справке команды. Для корректной работы демона в виртуалхосте должен быть включены модули «Турпутевка» и «Справочники», а также должен существовать справочник agents_accounts, обладающий следующими полями:
| Имя поля | Примечание | Тип | Размер | Уникальность | Индекс |
|---|---|---|---|---|---|
| orgname | Имя организации | char | 255 | Да | Да |
| orgtype | ИП, ТОО, ОАО и т.д. | char | 5 | ||
| address | char | 255 | |||
| phone | char | 64 | |||
| char | 128 | ||||
| chieffname | Имя директора | char | 128 | ||
| base_doc | Правоустанавливающий документ директора (устав, приказ, доверенность) | char | 128 | ||
| bankinfo | Адрес банка и его наименование | char | 255 | ||
| rnn | По этом полю и следующему производится проверка на уникальность агента | char | 12 | Да | |
| bin | См. выше. Эти поля - казахстанская специфика регистрации юрлиц. | char | 12 | Да | |
| bik | Банковский индивидуальный код (код банка) | char | 8 | ||
| iik | Счет в банке | char | 20 | ||
| license | Номер лицензии агента (казахстанская специфика, необязательное) | char | 32 | ||
| kbe | Казахстанская специфика регистрации юрлиц, необязательное | char | 1 | ||
| login | Автоматически формирующееся поле на основании orgname | char | 32 | Да | |
| pass | Автоматически формирующееся поле | char | 18 | ||
| pass_hash | Автоматически формирующееся поле | char | 27 |
Каждый оператор (или филиал оператора) имеет свой список агентов, могущих авторизоваться в его системе под своим логином. То есть имея один и тот же логин для нескольких операторов, агент может иметь право авторизоваться у одного оператора и не иметь - у другого. Возможность авторизации зависит от того, в каком статусе находится запись об агенте в справочнике агентов у конкретного ТО.
На виртуалхосте ТО должен существовать справочник agents, являющийся стандартным для модуля «Турпутевка». Поля этого справочника, относящиеся к централизованной авторизации агентов:
| Имя поля | Примечание | Тип | Размер | Уникальность | Индекс |
|---|---|---|---|---|---|
| orgname | Имя организации | varchar | 255 | Да | Да |
| ...Пропущены стандартные поля для организаций... | |||||
| license | Номер лицензии агента (казахстанская специфика, необязательное) | varchar | 32 | ||
| kbe | Казахстанская специфика регистрации юрлиц, необязательное | varchar | 1 | ||
| login | Автоматически формирующееся поле на основании orgname | varchar | 32 | Да | |
| pass | Автоматически формирующееся поле | varchar | 18 | ||
| pass_hash | Автоматически формирующееся поле | varchar | 27 | ||
Агент (как и любой другой пользователь-гость) может производить поиск туров без авторизации. Если до поиска агент не был авторизован, после попытки покупки найденного тура, он перейдет на окно авторизации агента. После авторизации он попадет на страницу покупки пакета (создания заявки). Внешний вид и функционал поиска тура зависит от того, какой шаблон поиска используется в турпакете.
Просмотр и редактирование заявок:При работе под агентом в заявке может отображаться меньше информации, чем под обычным пользователем, имеющем право на просмотр заявки и/или ее редактирование. Каждый агент может видеть список только своих заявок.
Обработка заявок операторами ТООператор (обычный пользователь ТО), обладающий правами CreateAnyQuery или ManageTickets, может принять заявку в работу, если она находится в определенном статусе (настраивается в конфигурации). Для этого посредством конфигурационных шаблонов так или иначе пользователь должен перейти по URL: /Voucher/queries/<QUERYID>/takeown. Если заявка уже взята в работу другим пользователем, выведется ошибка.
Для того, чтобы полноценно пользоваться возможностями движка, входная (заявочная) форма может иметь некоторые особенности, описание которых дано ниже:
Отличительная особенность скриптов обслуживания пакетов в том, что названия переменных их имен жестко заданы на уровне модуля и их всего два: скрипт пересчета прайсов (переменная пакета pricescript и скрипт продажи пакетов (salescript). Вызываются эти скрипты довольно часто и с разными параметрами. Скрипты являются связью между конфигурацией (которая не известна модулю) и запросами со стороны модуля к объекту пакета. Ниже определен перечень возможных параметров и их описание:
pricescript, первый параметр запуска:При запуске пересчета прайса предыдущие строки в прайсе будут удалены лишь в последний момент перед заливкой посчитанных цен в базу. Это сделано для того, чтобы сохранить прайс при возможных ошибках просчета и следующем останове просчета. Таким образом, если это активный прайс для онлайн бронирования, максимально увеличивается время доступности прайса и поиска пакетов. Если скрипт вычисления прайса помимо данных вернет специальный ключ clear_only в формате hash, то будут удалены только те строки прайса, которые удовлетворяют набору условий ключ=значение этого хеша.
Выгружаемый файл XLS-формата создается для текущей версии прайса единожды, при первом щелчке по ссылке для выгрузки. Все последующие выгрузки просто отдают уже ранее сформированный файл. Сделано это для снижения нагрузки на сервер, так как выгрузка большого объема данных очень ресурсоемка. Файл обновляется (создается из справочника прайса), если дата изменения пакета позже, чем дата создания файла. Для этого достаточно просто сохранить пакет, щелкнув "Продолжить" на вкладке ресурсов. Также файл удаляется после успешного пересчета прайса и последующей автоматической заливки его в справочник-родитель файла. Файл HTML-формата каждый раз формируется на лету.