• 1. Бизнес-логика
• 1.1. Выходные документы
• 1.1.1. Приходно-кассовый ордер
• 1.1.2. Расходно-кассовый ордер
• 1.1.3. Акт выполненных работ и счет-фактура
• 1.1.4. Скидочный купон
• 1.1.5. Исходящий платеж
• 1.1.6. Счет-накладная на авиабилеты
• 1.1.7. Счет на оплату
• 1.1.7. Договор с туристом
• 1.1.8. Приложение №1 к договору
• 1.1.9. Дополнительное соглашение к договору
• 1.1.10. Заявка-бронь (Ваучер, путевка)
• 1.1.11. Посадочный талон и талон к путевке
• 1.1.12. Страховой полис
• 1.2. Агентская комиссия
• 1.3. Подсчет прайсов
• 1.3.1 СПО
• 1.3.2 Стоп-листы
• 1.4 Бронирование онлайн
• 1.4.1 Билеты
• 2. Состав конфигурации
• 3. Шаблоны входных форм
• 3.1. Внутренний туризм
• 3.2. Международный туризм
• 3.3. Офисные расходы
• 4. Шаблоны выходных документов
• 4.1. Приходно-кассовый ордер
• 4.2. Расходно-кассовый ордер
• 4.3. Акт выполненных работ и счет-фактура
• 4.4. Скидочный купон
• 4.5. Исходящий платеж
• 4.6. Счет-накладная на авиабилеты
• 4.7. Договор с туристом
• 4.8. Приложение №1 к договору
• 4.9. Дополнительное соглашение к договору
• 4.10. Заявка-бронь
• 4.11. Посадочный талон и талон к путевке
• 4.12. Страховой полис
• 5. Серверные скрипты и пакеты скриптов
• 5.1. Пакет ts_sale
• 5.2. Пакет ts_price
• 5.3. Пакет helper
• 5.4. checksumquery
• 5.5. concatsimilaroffers
• 5.6. finance_report
• 5.7. genclientnames
• 5.8. getcurrencyrate
• 5.9. managetickets
• 5.10. nsk_insurance
• 5.11. params_control
• 5.12. speller
• 5.13. switchquerybymoney
• 5.14. total_report
• 5.15. genTicketsNumbers
• 6. Шаблоны отчетов
• 7. Шаблоны пакетных форм
• 8. Шаблоны поисковых форм
• 9. Справочники
• 9.1 Организации / organizations
• 9.2 Агенты / agents
• 9.3 Операторы / operator
• 9.4 Дополнительные данные ператоров / operator_extra_data
• 9.5 Курс валют / currency
• 9.6 DOC: Работы по заявке / query_works
• 9.7 DOC: Номера авиабилетов / doc_flights_tickets
• 9.8 Счета
• 9.8.1 Счета
• 9.8.1 Движения по счетам
• 9.8.2 Депозиты у операторов
• 10. Особенности
• 10.1 Хаки

Этот раздел описывает логические структуры и взаимосвязи рабочей конфигурации по умолчанию для модуля "Турпутевка". Техническая информация при этом дается в отдельном блоке внизу и отмечена другим цветом.

Бизнес-логика приложения полностью реализуется в конфигурации модуля «Турпутевка», оставляя на долю кода самого модуля и остального движка лишь обеспечение хранения ресурсов, авторизации, разделения прав пользователей и базового веб-интерфейса. К бизнес-логике относится настройка параметров сущностей, подключение ресурсов, документная база, солидная часть рабочих интерфейсов пользователя и, главное, скриптовая обработка данных перед сохранением и выдачей ресурса.

Например, TODO

После создания приходно-кассового ордера добавляется движение по выбранному счету, баланс счета увеличивается на сумму приходно-кассового ордера. Валюта счета должна быть либо в главной валюте, либо в валюте заявки, транзакция в счете в третьей валюте будет заблокирована.

Перед созданием приходно-кассового ордера производится проверка средств на указанном счету. Если средств недостаточно, создание приходно-кассового ордера блокируется. После создания расходно-кассового ордера добавляется движение по выбранному счету, баланс счета уменьшается на сумму расходно-кассового ордера. Валюта счета должна быть либо в главной валюте, либо в валюте заявки, транзакция в счете в третьей валюте будет заблокирована.

Акт выполненных работ может быть сформирован, когда заявка находится в статусе Оплачена (в статусе Частично оплачена или Переплачена документ недоступен) и при условии что у пользователя есть право формировать финансовые документы (Управление фин. документами, англ. ManageFinances).

Счет-фактура становится доступной для создания только после создания документа Акт выполненных работ в этой заявке.

При создании акта выполненных работ:

• По умолчанию автоматически подставляется номер по порядку (программа сама ищет среди всех уже ранее выписанных актов акт с максимальным номером и выдает следующий, больший на 1). Вы не сможете указать номер, меньший или равный самому максимальному номеру ранее созданного акта выполненных работ, но есть возможность указать отличный от порядковой нумерации номер акта выполненных работ (в поле номер акта указать больший номер, в тех случаях когда один или несколько предыдущих актов были созданы не в программе).
• Дата акта может быть выставлена равной или большей, чем максимальная дата ранее выписанных актов, чтобы сохранилась логическая взаимосвязь номеров и дат выставления актов.

При создании счет-фактуры:

• По умолчанию автоматически подставляется номер по порядку (программа сама ищет среди всех уже ранее выписанных счетов счет с максимальным номером и выдает следующий, больший на 1). Вы не сможете указать номер, меньший или равный самому максимальному номеру ранее созданной счет-фактуры, но есть возможность указать отличный от порядковой нумерации номер счет-фактуры (в поле номер счет-фактуры указать больший номер, в тех случаях когда один или несколько предыдущих счетов были созданы не в программе).
• Дата счет-фактуры не может быть выставлена меньшей, чем максимальная дата ранее выписанных счет-фактур, а также меньшей чем дата акта выполненных работ в этой заявке. Эта защита нужна, чтобы сохранилась последовательность номеров и дат выставления счет-фактур.

При распечатке созданных документов:
В справочнике агентов (если документы выставляются агенту) и в справочнике организаций (если документ для юр/лица) необходимо заполнить все реквизиты фирмы-получателя, иначе будет выдано соответствующее сообщение о том, какие данные отсутствуют. Если это произошло и при распечатке видно предупреждение, необходимо внести реквизиты в справочник и нажать кнопку ПЕЧАТЬ напротив соответствующего документа на странице просмотра заявки.

Порядковые номера документов начинаются с 1 в начале каждого года.

Скидочный купон уменьшает сумму к оплате заявки. Купон может быть выписан в любой момент, пока заявка не закрыта (ended).

В отношении туроператор (ТО) - турагент (ТА):

• Каков бы ни был размер скидок, размер фактической комиссии агента останется неизменным - он зависит только от стоимости заявки. То есть при стоимости заявки $1000 и комиссии 10%=$100, туроператор, делая скидку в $200, на руки получит $700, а турагент всё те же $100. Это реализуется посредством вычисления комиссии агента от общей суммы пакета, а не от суммы к оплате.

Перед созданием исходящего платежа производится проверка средств на указанном счету. Если средств недостаточно, создание платежа блокируется. После создания платежа добавляется движение по выбранному счету, баланс счета уменьшается на сумму платежа. Валюта счета должна быть либо в главной валюте, либо в валюте заявки, транзакция в счете в третьей валюте будет заблокирована.

Привязка платежа к конкретной услуге возможна только через менеджер оплаты (меню "Счета и платежи"). Если создавать платеж вручную, платеж будет привязан только к заявке и не будет учитываться при просчете рентабельности продаж каких-либо услуг.

Документ счет-накладная на авиабилеты может быть сформирован, когда заявка находится в статусе Оплачена (в статусе Частично оплачена или Переплачена документ недоступен) и при условии что у пользователя есть право формировать финансовые документы (Управление фин. документами, англ. ManageFinances).

При создании счет-накладной на авиабилеты:

• По умолчанию автоматически подставляется номер по порядку (программа сама ищет среди всех уже ранее выписанных счетов-накладных документ с максимальным номером и выдает следующий, больший на 1). Вы не сможете указать номер, меньший или равный самому максимальному номеру ранее созданного документа, но есть возможность указать отличный от порядковой нумерации номер документа (в поле номер акта указать больший номер, в тех случаях когда один или несколько предыдущих документов были созданы не в программе).
• Дата счета-накладной может быть выставлена равной или большей, чем максимальная дата ранее выписанных актов, чтобы сохранилась логическая взаимосвязь номеров и дат выставления документов.
• Сумма стоимости всех указанных авиабилетов не может быть выше, чем сумма к оплате заявки. Пока вы не исправите стоимость билетов так, чтобы их сумма не стала меньше или равной сумме к оплате заявки, создание документа будет заблокировано.
• В том случае, если из услуг в заявке существуют только авиаперелеты, используется и вторая проверка: cумма стоимости всех указанных авиабилетов не может быть ниже, чем сумма к оплате заявки. Пока вы не исправите стоимость билетов так, чтобы их сумма не стала равной сумме к оплате заявки, создание документа будет заблокировано.

Расчет агентской комиссии производится следующим образом:

1. Если куплены все услуги в пакете, берется комиссия, указанная для всего пакета. Если она не указана, используется процент комиссии агента. При этом в пакете могут отсутствовать услуги с фрагментарным покрытием (доступные не для всех туров или пакетов).
2. Если агент (или обслуживающий его оператор со стороны ТО) отказался от одной или более услуг (покупка неполного пакета), то для всех оставшихся в пакете услуг ищется формула индивидуальной комиссии. Если она найдена, комиссия высчитывается по формуле, иначе для этой конкретной услуги берется комиссия, указанная для всего пакета. Если она не указана, используется процент комиссии агента.
   Например: Куплен турпакет для взрослого и младенца. Из услуг выбраны авиабилет и страховой полис, от других услуг пакета отказались: проживание и экскурсии. Индивидуальная формула комиссии указана только для авиабилетов: $50 для взрослого или ребенка и 0 комиссии для младенца. Общая комиссия пакета 10%. В результате агентская комиссия составит $50 + 10% от стоимости страхового полиса с накруткой.
3. Если ID фирмы-агента совпадает с ID собственного агента оператора (оператор сам продает пакет непосредственному туристу), комиссия всегда равна 0.
4. Если заявка турпакетная и пакет куплен в рамках действия СПО, проверяется установленная опция (галка) Цена нетто (без комиссии). Если она указана, комиссия всегда равна 0.
5. Округление комиссии до целого числа производится в последний момент после сложения комиссии за каждый продукт в общую сумму.

Периоды в исходном прайсе отелей могут быть указаны "встык" и "внахлест". "Встык" - если один период заканчивается одним числом, следующий начинается другим числом. "Внахлест" - если дата конца предыдущего периода равна дате начала следующего. Выбор активного периода для вычисления цены граничной ночи производится в зависимости от настроек продукта в пакете.

После просчета прайса и выставления его для онлайн-продаж не блокируется возможность менять настройки накруток цены в продуктах. Сделано это для того, чтобы можно было параллельно создавать другие прайсы (или дописывать в текущий) - в рамках выпуска СПО или для подстройки цены на примере одного вылета или одной гостиницы (для успешной конкуренции). На практике это чревато противоречивостью цен, которые выставлены для онлайн-продаж и цены, с которой будет сохранена заявка, купленная после момента изменения накрутки. Произойти это может потому, что при заполнении заявки цена высчитывается заново на основании формулы накрутки в пакете и в теории может отличаться от той, которая сохранена в прайсе.
Чтобы избежать подобной ситуации, которая агентом будет расценена не иначе, как мошенничество (завлечение одной ценой и продажа по факту по другой цене), в конфигурации предусмотрен механизм создания и восстановления слепков состояния пакета на момент просчета базового прайса или СПО. В момент покупки заявки пересчет цены производится на основе данных слепка, сохраненного в момент просчета прайса с этой ценой, а не по актуальной формуле накруток, которая присутствует в прайсе сейчас. Для того, чтобы обновить слепок и, соответственно, цены в прайсе и онлайн-продажах, нужно просто выбрать нужный номер СПО (или не выбирать его - для просчета базовых цен) и запустить пересчет прайса. ВНИМАНИЕ: таким образом, изменение настроек пакета никак не влияет на покупку заявок по просчитанным прайсам - вам придется пересчитать прайс, чтобы обновить настройки пакета для продажи заявок. Это стоит иметь ввиду, ищзменяя пакет в ходе продаж.
Имейте в виду, что при пересчете активного прайса, по которому в системе существуют уже оформленные, но еще не забронированные заявки, возможны ситуации изменения стоимости еще не забронированных заявок. Делать пересчет базовой цены уже в сезон, когда идут продажи - не слишком правильное решение, продиктованное разве что форс-мажором. Для временной корректировки цен предусмотрены СПО.

Специальное предложение оператора (СПО) представляет собой другую цену пакета, действующую в течение определенного времени. Несколько цен пакета сосуществуют параллельно в одном прайсе, но пакет может быть куплен только по одной из этих цен (что логично). При онлайн бронировании на один и тот же отель и тип номера при одном из нескольких существующих СПО будут показаны все цены, включая базовую и агент обязан сам выбрать цену покупки пакета. При выгрузке прайса и существовании нескольких СПО необходимо точно определить номер СПО, для которого прайс будет выгружен, иначе цены будут неверными. СПО может касаться изменения цен только для одного продукта или сразу для нескольких. СПО имеет срок действия. Доступность СПО автоматически теряется при еженочном обслуживании базы, если период действия СПО закончился. Также можно вручную включить или отключить доступность СПО для онлайн-бронирования.

В конфигурации реализуется следующими шагами:

• Если в СПО изменены цены (себестоимость) отелей: залить в продукт отеля новый прайс с измененными ценами отелей от принимающего туроператора с указанием номера СПО (при этом старые цены остаются нетронутыми, имея номер СПО=0)
• Если в рамках СПО изменяется политика накрутки: добавить условие в политику накрутки одного или нескольких продуктов, указав номер СПО.
• Создать настройку типа "СПО", указав в ней перечень туров, подпадающих под действие СПО, название СПО и прочие атрибуты.
• Указать в прайсе (чаще всего активном) номер СПО и запустить пересчет прайса. При этом просчитаются и заменятся новыми цены только в рамках туров и цен указанного СПО.

Прочие особенности СПО:

• Галочка "Цена нетто (без комиссии)" при выборе приводит к тому, что при покупке заявки в рамках этого СПО комиссия любому агенту всегда будет равна нулю. Скажем, если базовая цена пакета составляет 1000$, комиссия 10% составит 100$. При выпуске СПО и падении цены пакета до 800$ выплачивать еще и комиссию в 80$ невыгодно, цена выставляется как есть (нетто) и агент сам уже регулирует конечную цену для потребителя.

Для возможности бронирования онлайн должны быть выполнены следующие шаги:

• Хост, на котором работает модуль «Турпутевка», должен быть доступен из сети интернет.
• Создан как минимум один пакет, с настройками, позволяющими покупку пакета. Если этот пакет не предполагает построения индивидуальных туров и основывается на ограниченных рейсах авиа- или наземного транспорта, должен быть просчитан хотя бы один прайс для этого пакета и выставлен в онлайн.
• Если бронирование онлайн будет выполняться не только сотрудниками туроператора, но и внешними фирмами-агентами, должна быть настроена авторизация агентов (см. соответствующие параметры на странице администраторской настройки модуля «Турпутевка»).
• Агентство, собирающееся делать покупки онлайн, должно зарегистироваться через форму регистрации агентов и затем заключить договор с туроператором. После заключения договора статус агента в системе позволит ему совершать покупки через систему онлайн-бронирования. Чтобы заключить договор с агентом, зарегистрировавшимся в системе, выставить ему комиссионный процент, распечатать договор и изменить статус на активного покупателя, следует использовать пункт меню "Поиск" и соответствующую вкладку "Агенты". Это действие может совершить лишь тот сотрудник, который обладает правом Управление Агентами (ManageAgents).
• Со стороны туроператора должен быть выделен один или несколько сотрудников, осуществляющих обработку поданых агентами заявок на бронирование. Каждому такому сотруднику требуется назначить право Управление билетами (ManageTickets).

После авторизации агент имеет право через любую форму поиска купить пакет и получить заполненную заявку. В случае индивидуального подбора тура (специальная форма поиска и соответствующий пакет) результатом покупки также будет заполненая форма заявки. На этом этапе от агента требуется заполнение данных туристов. После сохранения заявки агент может отредактировать ее, отменить, либо отправить на бронирование нажатием соответствующей кнопки. При успешной проверке всех введенных данных и бронировании (или постановки под запрос) происходит оповещение о новой заявке всем сотрудникам, имеющим право управления билетами (ManageTickets). Затем заявка ожидает, чтобы кто-то из этих сотрудников взял ее в работу (именно ему начислятся бонусы за эту заявку, если они предсмотрены): проверил данные, создал в ней документы, принял деньги и завершил ее жизненный цикл.

1. Поиск тура/пакета
2. Покупка (автозаполнение услуг заявки)
3. Заполнение данных о туристах
4. Сохранение заявки
5. Бронирование заявки
6. Возможное ожидание подтверждения брони
7. Оплата заявки любым способом
8. Распечатка созданных туроператором документов заявки

Если первые пять пунктов бронирования выполняются линейно и в целом однообразно, то возможность и порядок выполнения последующих действий зависят от многих факторов. Рассмотрим типовые сценарии в подробностях:

• Идеальный: все услуги в заявке имеют достаточное количество ресурсов мгновенного подтверждения и после попытки бронирования агентом заявка сразу переходит в статус "Подтверждена". Происходит рассылка оповещений сотрудникам оператора. Один из сотрудников берет заявку в работу. С этой момента он является владельцем заявки. Теперь он может создавать и распечатывать документы для этой заявки. Одним из первых документов чаще всего бывает счет на оплату агенту. При этом счет, будучи созданным, доступен агенту для распечатывания в своем офисе. Также на стадии работы с деньгами используются приходный и расходный кассовые ордеры. Кроме того, он может создавать и распечатывать любые другие специфичные для пакета и формы документы, Заявка переходит в статус частично оплачена или оплачена и готова для архивации. Агент видит состояние заявки и те документы, которые ему разрешено видеть.
• Отказ от заявки по разным причинам: сотруднику оператора потребуется отменить заявку. Если заявка не была оплачена, тогда доступна кнопка "Отменить". При этом снимается бронь на все услуги, если она была, вне зависимости от статуса (под запрос, подтверждена). Если же была полная или частичная оплата, отмена заявки производится через расходный кассовый ордер с выбором соответствующей галочки. Ответственность за возможно необходимые выплаты (например, отелю) при снятии брони лежит на туроператоре и конкретнее - на плечах сотрудника-владельца заявки, поэтому он должен принимать во внимание сроки в условиях снятия брони каждой услуги заявки. Эта политика не реализована в автоматике программы.
• Коррекция заявки сотрудником туроператора: в процессе подтверждения и оплаты заявки выяснилось, что данные заявки не удовлетворяют клиента или неверны. Требуется отредактировать заявку нажатием соответствующей кнопки. Доступна она владельцу заявки (после взятия заявки в работу это сотрудник туроператора). При удалении из заявки во время редактирования одной или нескольких услуг, которые имеют ресурс и были забронированы (или поставлены под запрос), билеты удаляются, подтвержденная бронь снимается и ресурс освобождается. При этом можно добавить другие услуги, как простые, так и имеющие ресурс (например, отели или авиаперелеты).. Также возможна смена принимающей стороны - с целью получения более привлекательных цен или наличия ресурса, не подтвержденного предыдущей принимающей стороной.

• При бронировании агентом заявки. В зависимости от того, все ли ресурсы подтвердились мгновенно или нет, меняется текст оповещения. Получатели: все, кто обладает правом управления билетами.
• При создании какого-либо документа, в свойствах которого во входной форме подключено оповещение. Например, при создании счета - оповещение агента о его доступности.
• При отмене заявки. Получатели: агент.
• При подтверждении заявки (переход в статус Подтверждена), если в момент подтверждения владельцем заявки являлся не агент, а сотрудник оператора. Чаще всего это происходит при подтверждении ресурсов под запросом (например, отель).

Также работает оповещение пользователей, обладающих правом Управление агентами (ManageAgents) при регистрации нового агента (пользователь должен проверить реквизиты, выставить размер комиссии агенту и заключить с ним договор, после чего уйдет еще одно оповещение - уже агенту - с его логином и паролем).

Поддержка билетов осуществляется записями в таблице vchr_tickets. Сделано это на уровне платформы (не конфигурации). Каждый билет имеет привязку к справочнику ресурса, номеру услуги (они сквозные для всех заявок - через этот номер - и к заявке тоже), ID клиента, статус билета, его номер, наличие места, и дату последнего изменения.

Для того, чтобы создавался билет к какой-либо услуге из пакета, у услуги должен быть указан справочник ресурсов.

Поля типового справочника ресурсов:

В пакетной заявке также в цепочку статусов добавляется два новых статуса, отражающие состояние билетов.
Обычная заявка: "Не завершена" => "Частично оплачена" => "Оплачена" => "Заблокирована" => "Архивная".
Пакетная заявка: "Не завершена" => "Под запросом" => "Забронирована" => "Частично оплачена" => "Оплачена" => "Заблокирована" => "Архивная".

Финансовые документы в пакетной заявке на стадиях "Не завершена" и "Под запросом" избирательно доступны только в некоторых случаях. Условия:

1. Если заявка уже взята в работу одним из операторов (то есть сейчас автор - агент). Иначе недоступны все документы и нижеследующие пункты не действуют.
2. При продаже заявки туроператором непосредственно туристу (ID фирмы в заявке совпадает с ID основной фирмы в настройках) доступен приходно-кассовый ордер. При этом создание этого документа не переводит заявку в статус "Частично оплачена" или "Оплачена" (как обычно) - до тех пор, пока не будет завершена цепочка состояний билетов. В этом случае после подтверждения (мгновенного или после статуса "Под запросом") - заявка сразу перейдет в статус "Частично оплачена" или "Оплачена".
3. На стадиях "Под запросом", "Забронирована" и "Частично оплачена" доступен Скидочный купон.
4. На стадии "Забронирована" доступен Счет на оплату.

Доступные действия над билетами заявки и описание того, что при них происходит:

Резервирование билетов (бронирование): Происходит при нажатии на кнопку "Бронировать" на странице просмотра заявки.

1. Происходит проверка сумм, возрастов клиентов, даты действий документов и прочие проверки. В случае сбоя любой проверки бронирование отменяется и нажимающему выводится сообщение.
2. Если справочник указан в продукте пакета, но пуст (или не содержит записи для этого тура и этого номера отеля), но идет резервирование билета, автоматически создается новая строка. При этом поля жесткого и мягкого блоков будут равны нулю (что воспринимается платформой как бесконечный мягкий блок).
3. Число ресурсов может не совпадать с числом билетов. Так, если в пакете цена продукта указана за тур (tour), то вне зависимости от количества клиентов в заявке, будет потрачен один экземпляр ресурса (например, комната в отеле), это будет отражено в билете первого туриста (взрослого или ребенка). Иначе, если цена указана за клиента (client), или client*day, client*night - количество билетов и потраченных ресурсов чаще всего будет одинаковым - в этом случае места (ресурсы) не достаются только infant-ам (младенцам).
   Пример 1: услуга отеля, три туриста - три билета, но только один ресурс потрачен и прикреплен к первому туристу.
   Пример 2: услуга авиаперелета, два туриста - один взрослый и один младенец. Будет два билета, но тоже только один ресурс - прикрепленный к билету взрослого.
4. Билет персонализирован - закреплен за отдельным клиентом. Это означает что для одного клиента на одну услугу в заявке может быть только один билет (но есть исключение для внутреннего туризма). Связь между билетом и клиентом видна при просмотре заявки во вкладке услуг.
5. Кнопка бронирования доступна до тех пор, пока все билеты по всем услугам не перейдут в статус подтвержденных - и, соответственно, сама заявка тоже. Также заявка может быть редактируемой до подтверждения всех билетов - при этом можно добавить новых туристов. Билеты новых туристов после нажатия на кнопку бронирования в услугах, доступных только по запросу, перейдут в статус "по запросу", даже если билеты других туристов на эту услугу были подтверждены ранее.
6. После перехода заявки в статус ожидания подтверждения билетов нельзя удалить туристов из заявки или изменить их данные. Для исключения одного или нескольких туристов из заявки придется отменить заявку и создать новую.
7. Если все ресурсы одной или нескольких услуг в заявке выкуплены (нет свободных мест), и по логике должен быть отказ, но в продукте указан принцип "под запрос" при окончании ресурсов, то билеты создаются (только "под запрос"). Но подтвердить их нельзя, если суммарное количество продаваемых мест больше, чем доступных. Это сделано для максимального наполнения мест.
8. Если на одном из ресурсов мест нет, выводится ошибка и ресурсы не бронируются, билеты не создаются (ко всем услугам).
9. Заявка может быть создана и забронирована как агентом, так и оператором самого туроператора, имеющим право CreateAnyQuery (если он собирается оформить заявку от имени другой фирмы-агента) или оформляющим заявку от имени собственной фирмы (непосредственная продажа пакета туристу). Если заявка создана агентом, оповещение о заявке приходит всем операторам туроператора, которые имеют право ManageTickets. После этого предполагается, что один из операторов первым возьмет заявку на себя, нажав кнопку "Взять в работу". В дальнейшем он считается автором этой заявки и получит процент с ее продажи. Если же заявка создана оператором самой турфирмы, отсылки писем не произойдет (в случае если заявка перешла в состояние "под запрос", иначе см. следующий пункт).

Подтверждение билетов: Происходит при создании документа "Подтверждение брони", либо автоматически - если все ресурсы имеют достаточный свободный жесткий блок.

1. При создании документа можно выбрать одну или несколько подтверждаемых услуг (из тех услуг, которые имеют билеты под запрос).
2. Если после создания подтверждения не останется ни одного билета на подтверждение, заявка перейдет в статус "Забронирована".
3. Если все билеты подтверждены (заявка перешла в статус "Забронирована"), то становятся доступными все стандартные финансовые документы.
4. Оповещение о переходе заявки в статус "Забронирована" придет на почтовый ящик агента, который указан в справочнике агентов.
5. В случае непосредственной продажи пакета своему туристу (оператор выступает одновременно и в роли агента) и принятии денег от туриста до момента подтверждения брони (с созданием Приходно-кассового ордера) заявка может из статуса "Не завершена" или статуса "Под запросом" после автоматического или ручного подтверждения брони сразу перейти в статус "Частично оплачена" или "Оплачена".

Продажа билетов:

1. Происходит автоматически при полной оплате заявки, которая может наступить только после того, как все билеты подтверждены. Билеты меняют свой статус на "проданные", заявка меняет свой статус на "оплачена". После этого нельзя редактировать заявку, можно лишь отменить её.

Отмена ожидающих подтверждения билетов:

1. Происходит автоматически при удалении из заявки услуги, билеты к которой находятся в статусе "под запросом". Сделать это можно через редактирование заявки.
2. Редактирование заявки на этапе "Под запросом" доступно оператору, принявшему заявку в работу от агента (или создавшему заявку самостоятельно).

Отмена заявки и отмена билетов:

1. Происходит при создании документа "Расходно-кассовый ордер" с выбранной опцией "Отменить заявку", либо при нажатии кнопки "Отменить" для заявки (кнопка доступна только для оператора с правом ManageFinances и только в статусе "Забронирована"). При этом билеты удаляются, ресурсы освобождаются. Статус билетов и стадия продажи ресурсов (резерв, продано) - не имеет значения.

Этот раздел описывает наборы объектов всех типов конфигурации. Здесь указана только техническая информация, причины построения и логическое обоснование указаны в предыдущем разделе.

Конфигурация состоит из следующих частей:

1. Шаблонов входных форм,
2. Шаблонов выходных документов,
3. Шаблонов отчетов,
4. Шаблонов турпакетов,
5. Шаблонов поиска туров,
6. Связующих серверных скриптов и скриптовых пакетов,
7. Связующих web-скриптов (ECMAScript), выполняемых в браузере пользователя,
8. Набора справочников модуля libdict, наполненных и связанных определенным образом.

Предназначен для обработки заявки при покупке ее из турпакета оператора. Выполняет следующие операции:

1. Заполняет заявку при покупке ее через модуль онлайн-бронирования (URL: /Voucher/partner/packets/<PACKETID>/buy/<PACKETROWID>). При этом для пересчета актуальной цены используются функции из ts_price.
2. Корректирует внешний вид заявки при просмотре ее агентом (скрываются данные, доступные только оператору), (URL: /Voucher/partner/queries/<QUERYID>/view).
3. Защищает форму редактирования заявки от изменения жестко заданных пакетом параметров (на стадии создания и редактирования заявки) (URL: /Voucher/partner/queries/<QUERYID>/edit).
4. Корректирует агентскую комиссиию с учетом настроек турпакета.
5. Проверяет форму перед бронированием большим количеством проверок и при наличии проблемы блокирует бронирование, выводя ошибку.
6. Продает, бронирует, подтверждает билеты к продуктам с ресурсами. При этом вызывается из скрипта managetickets. Связка выполняется именно таким образом, потому что нельзя прописывать во входной форме этот скрипт напрямую - его название должно браться из конкретного турпакета - так как одна и та же входная форма может использоваться для покупки пакета разными турпакетами, основанными на разных турпакетных формах. Здесь скрипт managetickets определяет имя скрипта, занимающегося билетами, беря его из конфигурации конкретного турпакета, чей ID указан в заявке.

Предназначен для создания массивов прайсовых справочников и выгрузки их в виде файла. Выполняет следующие операции:

1. Считает стоимость туров в турпакете в разрезе по каждому номеру каждой гостиницы.
2. Увеличивает стоимость согласно формуле вычисления прибыли - по каждому продукту в туре.
3. Подготавливает выгрузку прайса в виде файла (перечень форматов файлов определяется движком. На момент создания конфигурации поддерживается два формата: XLS и HTML)

Особенности:

1. При просчете прайсов в целях уменьшения потребления оперативной памяти используется метод загрузки данных в базу из файла. Для того, чтобы БД могла это сделать, пользователю, под которым осуществляется подключение к базе, необходим грант FILE. Имя пользователя базы данных можно найти в файле /cfg/config.pm относительно корня виртуалхоста клиента. Команда выдачи гранта под суперпользователем базы:
   grant file on *.* to имя_пользователя@localhost;
   Будьте внимательны, выдача этого гранта фактически позволяет пользователю, под которым работает виртуалхост, иметь доступ на чтение и запись файлов с правами пользователя mysql.

Важные функции:

• keymap - возвращает хэш-массив названий переменных всех переменных входных форм, пакетных форм, документов, полей справочников и т.д. Рекомендуется использовать в качестве исходного массива имен везде, где упоминаются переменные этого рода. Использование позволит сократить места упоминания имени переменной в скриптах до одного, что облегчает возможную смену имени переменной.

Работает следующим образом: берет все данные заявки и ищет в них услуги типа flight и flight_from, ищет в них билеты. В каждой услуге пытается найти предоставителя услуги (o_provider). Если предоставитель найден, делает запрос в справочник operator_extra_data (который привязан к справочнику operator), ищется для этого оператора существующий ключ operator_key=last_flight_ticket. Значение ключа operator_value из этой строки используется в качестве исходного для генерации номеров билетов - каждый билет имеет номер больше предыдущего на единицу, начиная с указанного в ключе + 1. Например, если исходное значение ключа равно 520090001, то первый билет будет иметь номер 520090002, второй - 520090003 и т.д.

Конфигурация активно использует системные справочники, а также добавляет свои собственные.

organizations - системный справочник, создаваемый на стадии инсталляции модуля. Содержит поля названия, реквизитов и адреса организаций, с которыми контактирует турфирма. Является базовым для подключения других справочников, несущих в себе специфичность роли организации. Имена организаций уникальны, для запрета дублирования.

agents - системный справочник, создаваемый на стадии инсталляции модуля. Связан со справочником организаций (organizations). Содержит специфичные поля, характерные для агентов и не актуальные для остальных организаций. Одна организация может быть только один разу использована в списке агентов (для исключения дубляжей). Осуществляется это через галочку уникальности поля связки (bindrid).

operator - справочник, содержащий перечень операторов и прочих предоставителей услуг, с которыми контактирует турфирма в процессе обработки заявок и пакетов. Связан со справочником организаций (organizations). Содержит специфичные поля, характерные для операторов и не актуальные для остальных организаций. Одна организация может быть только один разу использована в списке операторов (для исключения дубляжей). Осуществляется это через галочку уникальности поля связки (bindrid).

operator_extra_data - справочник, привязанный к справочнику operator и содержащий какие-то уникальные параметры операторов, которые достаточно редки, чтобы их на постоянной основе указывать в качестве полей в справочнике операторов. Здесь поля превращены в пару ключ=значение, а строки выполняют роль полей (классический перевертыш, обеспечивающий бесконечное количество полей за счет избыточности в столбце ключей). Поля:

currency - системный справочник, создаваемый на стадии инсталляции модуля. Содержит курс валют для конвертации цен в заявках. Обязан содержать по умолчанию курс основной валюты, равной 1.00 (например, currency=KZT rate=1.00). Остальные валюты нужно указывать по мере необходимости. Изменение курса валюты производится не редактированием уже существующей строки, а добавлением новой - для обеспечения истории смен курсов. При добавлении необязательно (и не рекомендуется) указывать дату и время наступления нового курса валюты - она заполнится автоматически текущим временем.

query_works - справочник, содержащий перечень услуг заявки, отображаемых в документах Акт выполненных работ и счет-фактура. Поля:

doc_flights_tickets - справочник, содержащий перечень цен, номеров и направлений авиабилетов для туристов заявки, отображаемых в документе Счет-накладная на авиабилеты. Поля:

• Название города при обработке его формой индивидуального тура не должно содержать знаков двоеточия и круглых скобок, иначе это вызовет невозможность продажи заявки и её сохранения.
• В имени ресурса номера отеля (room_name) не должно быть знака плюс (+) - из-за особенностей CGI он превращается в пробел и заявка не может быть забронирована

• В форме индивидуального тура: если создать отель с классом 10, он будет автоматически выбран по умолчанию (если URL не диктует иной отель). Употребимо при продаже только авиабилетов, чтобы автоматически подставить точку назначения "Аэропорт".
• Если нужно прикрепить продажу ТОЛЬКО авиабилетов к пакетной форме, нужно создать второй пакет, с одинаковыми турами, но только нужными продуктами. У него может быть своя накрутка и комиссия на продукты. Форму поиска для этого пакета указать "Индивидуальный тур". Затем ID этого тура нужно указать в первом, пакетном туре в разделе "управление турами" (создать одну настройку такого типа) в пункте "Привязка другого пакета". После этого появится соответствующая кнопка на интерфейсе пакетного онлайн-бронирования.
• Если в идивидуальном туре пакета у одного из продуктов указать длину "Последние 2(Два) дня тура", то тур будет увеличен на один день. Будьте осторожны с продуктами, которые в этом туре имеют длину "Весь тур", их длительность будет тоже увеличена соответственно.