1. Описание
2.   Теория туров
3.   Ресурсы
4.   Билеты
5. API
6.   API просчета тура
7.   API сохранения тура
8.   API бронирования тура и получения документов

Форма бронирования является тонким клиентом к SaaS web-сервису tourservice.net. Формат взаимодействия клиента с сервером приложений - Ajax, формат данных - JSON. В большинстве случаев нет разницы - использовать POST или GET. Имейте ввиду, что при передаче GET-параметров есть ограничения браузера и сервера приложений на длину URL (5000 символов для сервера приложений).

Теория туров
Тур, потребляемый туристом, состоит из разнородной информации:

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

• Перечня возможных продуктов, как обязательных к употреблению в составе тура, так и дополнительных, от которых можно отказаться.
• Набора стран и курортов, в которых происходит потребление туров. Чаще всего это одна страна и один-два-три курорта, но могут быть и сложные туры.
• Набора ресурсов в рамках продукта и цен этих ресурсов. Цены могут быть разными для разных периодов, количества туристов, возраста туристов и других параметров. Например, ресурс номеров в отеле фиксирован и конечен - 5 номеров класса Люкс и 10 - класса Стандарт, каждый со своим номером комнаты.
• Набора возможных дат начала и конца туров (жесткие рамки туров) или же возможности начинать и заканчивать тур в рамках наличия ресурсов (индивидуальные туры). Например, 11дневный тур с 5 мая по 15 мая, следующий возможен лишь с 18 мая по 28 мая.
• Набора возможных конфигураций группы туристов (чаще всего ограничителем является максимальная вместимость номера в отеле). Например, два взрослых и ребенок не старше 6 лет.
• Набора политик цены и комиссии агента для каждого из продуктов. Политика цены (не цена) - это инструкция по высчитыванию цены в особенных или в общих случаях. Например, задние кресла в автобусе для пенсионеров дешевле.

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

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

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

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

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

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

1. Подбор пакетов, их продуктов и ресурсов и просчет цены тура. Этап REST-совместим (не хранит состояние между запросами). Не требует аутентификации (если иное не настроено конкретным туроператором).
2. Оформление заявки на тур и ее сохранение. Этап REST-несовместим - выполняется изменение серверной части и хранение результатов между запросами. Требует аутентификации.
3. Бронирование заявки и распечатка документов. Этап REST-несовместим. Требует аутентификации.
4. Оплата заявки. Этап REST-несовместим.

API просчета тура
1. Сначала получаем список доступных турпакетов (и их базовых параметров), выставленных на просчет тура:

{
"variants":[{
	"a_currency":"KZT",
	"a_locations":"[\"Киргизия\",\"база Каракол\",\"Бишкек\",\"Каракол\"]",
	"a_sale2agents":1,
	"a_start_town":"Алматы",
	"a_hide4agents":1,
	"pid":11
},{
	"a_currency":"KZT",
	"a_locations":"[\"Казахстан\",\"Акши\",\"Коктума\"]",
	"a_sale2agents":0,
	"a_start_town":"Алматы",
	"pid":31
}],
"packets":{
	11: { name="ГОРНОЛЫЖНЫЙ СЕЗОН В КИРГИЗИИ", desc="горнолыжные базы, выезды по выходным. Включен трансфер, подъем на гору, проживание."},
	31: { name="Алаколь 2014", desc=""}}
}

{
"variants":[{
	"293":{
		"pid":11
		"t_program":"[\"Транспорт туда\",1,0,0],[\"Транспорт обратно\",2,0,0],[\"Подъем до горнолыжной базы\",3,0,0],[\"Размещение\",4,1,1]",
		"t_max_days":12
		"t_min_days":3
	}
},{
	"352":{
		"t_program":"[\"Размещение\",0,1,1,0,0],[\"Питание\",0,0,0,0,0]",
		"pid":31
	}
}],
"packets":{
	11: { name="ГОРНОЛЫЖНЫЙ СЕЗОН В КИРГИЗИИ", desc="горнолыжные базы, выезды по выходным. Включен трансфер, подъем на гору, проживание."},
	31: { name="Алаколь 2014", desc=""}}
}

{
"variants":[
	["Alateniz HV","Акши","Казахстан","5","genfrom:1;per_baseclient:1"],
	["Алаколь","Акши","Казахстан","2",""],
	["Аласу","Акши","Казахстан","2","genfrom:1;nosale"],
	["Асуан","Коктума","Казахстан","2",""],
	["Варадеро","Акши","Казахстан","2","genfrom:1"],
	["Варадеро","Акши","Казахстан","2",""],
	["Грин Хаус","Акши","Казахстан","2",""],
	["Зодиак","Коктума","Казахстан","2","genfrom:1"],
	["Коктума","Коктума","Казахстан","2",""],
	["Пеликан","Акши","Казахстан","2","genfrom:1"],
	["Черный Камень","Акши","Казахстан","2","genfrom:1"]
],
"dictname":"hotels"
}

{
"variants":[
	{
		"92":
		{
			"pid":"31",
			"p_cost_mode":"night",
			"p_dictid":"9",
			"p_resourcedictid":"0",
			"p_name":"Размещение",
			"offertype":"location",
			"p_pricedictid":"13",
			"p_cancellable_right":"ManageTickets"
		},
		"90":
		{
			"pid":"31",
			"p_cost_mode":"client",
			"p_dictid":"97",
			"p_resourcedictid":"50",
			"p_name":"Транспорт туда",
			"offertype":"transfer_to",
			"p_pricedictid":"121"
		},
		"91":
		{
			"pid":"31",
			"p_cost_mode":"client",
			"p_dictid":"97",
			"p_resourcedictid":"50",
			"p_name":"Транспорт обратно",
			"offertype":"transfer_from",
			"p_pricedictid":"121"
		}
	}
],"packets":{
	31: { name="Алаколь 2014", desc=""}}
}

{
"variants":[
	["Азимут Трэвел",null,"2014-06-05"],
	["Азимут Трэвел",null,"2014-06-12"],
	["Азимут Трэвел",null,"2014-06-15"],
	["Азимут Трэвел",null,"2014-06-19"],
	["Азимут Трэвел",null,"2014-06-22"],
	["Азимут Трэвел",null,"2014-06-24"],
	["Азимут Трэвел",null,"2014-06-26"],
	["Азимут Трэвел",null,"2014-06-30"],
	["Азимут Трэвел",null,"2014-07-02"],
	...
],"dictname":"int_transfer_res"
}

{
"variants":[
	{
		"placescheme":"",
		"number":"1",
		"block_start":"1",
		"floatable":"0",
		"rowid":"1939",
		"saled":"2",
		"dictid":"50",
		"block_end":"4",
		"reserved":"0",
		"available":"48"
	},{
		"placescheme":"mersedes",
		"number":"2",
		"block_start":"1",
		"floatable":"0",
		"rowid":"2131",
		"saled":"4",
		"dictid":"50",
		"block_end":"4",
		"reserved":"16",
		"available":"51"
	}
],
"dictname":"int_transfer_res"
}

{
	"variants":[
		{"ticket":"7"},
		{"ticket":"8"},
		{"ticket":"5"},
		{"ticket":"6"},
		{"ticket":"9"},
		{"ticket":"12"},
		{"ticket":"11"},
		...
	]
}

10. После рассадки группы по местам ресурса (в этом документе не освещена задача выбора отельных ресурсов, как неактуальная на данный момент и ресурсоемкая), остается две задачи - просчет цены и оформление заявки. Для подачи запроса на просчет нужно сформировать cookie, содержащий кодированную через функцию javascript escape() структуру данных JSON-формата и сделать Ajax-вызов функции сервера приложений. Это формат продиктован особенностями построения оригинальной клиентской части. Пример cookie:

{
	"query":{
		"country":"Казахстан",
		"town":"Акши",
		"hotel":"Аласу",
		"date_from":"2014-06-05",
		"date_to":"2014-06-19",
		"packetid":"31",
		"adults":"1",
		"pensioners":"1",
		"childs":"2",
		"childs_ages":"5,8",
		"infants":"0",
		"start_town":"Алматы"
	},
	"90":{
		"selected":1,
		"rowid":"1939",
		"tickets":[24,23,24],
		"provider":"Азимут Трэвел"
	},
	"91":{
		"selected":1,
		"rowid":"2008",
		"tickets":[22,21,20],
		"provider":"Азимут Трэвел"
	},
	"92":{
		"selected":0,
		"roomname":0,
		"roomid":0,
		"tickets":[],
		"bindrid":0
	}
}

{
	"price":14000
}

• settings - Блок настроек отображения формы. Неактуален для построения агентской формы бронирования.
• offer - Перечень структур для добавления новых услуг, не включенных в тур изначально. Неактуален для построения агентской формы бронирования.
• element - Перечень полей ввода для основных параметров тура. Каждый блок подструктуры является хешем и его нужно разместить в POST-форме сохранения заявки в виде скрытого элемента, например: <input type="hidden" name="q_date_from" value="2014-06-05">. Кроме того, нужно вычислить количество дней в туре и присвоить это значение скрытому элементу q_days. Например, если дата начала тура 2014-10-01, а дата завершения тура 2014-10-02, то код будет следующим:<input type="hidden" name="q_days" value="2">.
• offers - Перечень структур услуг (продуктов), купленных в рамках тура. Обрабатывается следующим образом:
  • Для каждого элемента в подструктуре element на POST-форме создается скрытый элемент вида <input type="hidden" name="name_N" value="value">. Поля name и value берутся из соответствующего хэша в массиве element. Часть в имени элемента N содержит в себе номер хэша продукта в списке offers. Например, для первого продукта какой-либо элемент может выглядеть так: <input type="hidden" name="productid_0" value="90">
  • Каждый хэш в массиве offers снабжается скрытым элементом с именем offertype_N, где N - порядковый номер продукта в массиве offers, и со значением, равным значению ключа type этого продукта в массиве offers. Например, <input type="hidden" name="offertype_1" value="transfer_to">
• client - Блок ввода данных туриста. Для построения агентской формы бронирования может быть проигнорирован и заменен следующей структурой:

  <input name="c_name_0" value="">
  <input name="c_nmeng_0" value="">
  <input type="hidden" name="c_borned_0" value="1970-01-01">
  

  Здесь c_name_0 - это фио туриста, желательно полностью, c_nmeng_0 - это ФИО туриста в транслитерации на латиннице, c_borned_0 - это дата рождения туриста в формате ISO. Дата обязательна, так как сочетание ФИО и даты рождения позволяет вычислить уникальность туриста в рамках БД и избежать ненужных коллизий. Но, принимая во внимание, что во внутреннем туризме категорически не принято узнавать дату рождения, дата может быть фиктивной, лучше всего 1970-01-01 (0 секунд по UNIX-времени) - это условная дата, ее постоянство будет указывать на фиктивность.
• Прочие элементы, которые нужно вычислить и послать наряду с перечисленными:
  • <input type="hidden" name="formid" value="2">. Цифра 2 здесь индивидуальна для каждого туроператора (не турагента!).
  • <input type="hidden" name="firmid" value="100">. Цифра 100 уникальна для каждого турагента. То есть если вы являетесь турагентом, эта цифра для вас всегда будет одинаковой.
  • <input type="hidden" name="clientcounter" value="1">. Число туристов. Так как для внутреннего туризма указывается только первый турист - скорее всего, этот параметр всегда будет равен 1. Для внешнего туризма - столько туристов, сколько указал покупатель (те, которые указаны со всеми паспортными данными).
  • <input type="hidden" name="offercounter" value="5">. Число услуг, продаваемых клиенту. Равно количеству элементов в массиве offers.

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