Какие типы документов поддерживаются?
Номер документа в бронировании указывать можно какой угодно. Но тип документа – всегда PP. Например для младенца будет PP VIIMU123456 – свидетельство о рождении.
Можно ли указать второй email, моб.телефон?
EmailContact - методом book допускается указание одного адреса. В дальнейшем есть возможность редактировать контакты существующего бронирования используя метод changeBook. Например добавить произвольное кол-во email контактов.
PhoneContact - для CountryCode и AreaCode максимальное количество символов = 15, логика позволяет использовать буквенные символы. Методом book допускается указание произвольного кол-во телефонных контактов.
Тайм-лимит вводится вручную?
Можно установить вручную или автоматически.
- При выполнении запроса OrderChangeRQ получаем ошибку <ns3:Error Type="LOC" Tag="Property change_book_request can not be empty" RecordID="CHNG_BOOK_RQ_IS_EMPTY"/>
Вводите символы, которые не поддерживаются, например: ; : * ' " ^ { } [ ] < > & # ! ` = %
На этапах создания брони (OrderCreateRQ), репрайса (ItinReshopRQ) полётные сегменты стоит распределить по блокам OriginDestination по соответствующим направлениям, т.е. рейсы туда вставляем в один OrginDestination, а рейсы обратно в другой блок OriginDestination.
Например, RT DME-SIP:
<ns3:OriginDestination>
<ns3:OriginDestinationKey>OD1</ns3:OriginDestinationKey>
<ns3:Flight>
<ns3:SegmentKey>FL1</ns3:SegmentKey>
<ns3:Departure>
<ns3:AirportCode>DME</ns3:AirportCode>
<ns3:Date>2016-10-04</ns3:Date>
<ns3:Time>08:50</ns3:Time>
</ns3:Departure>
<ns3:Arrival>
<ns3:AirportCode>SIP</ns3:AirportCode>
<ns3:Date>2016-10-04</ns3:Date>
<ns3:Time>11:20</ns3:Time>
</ns3:Arrival>
<ns3:MarketingCarrier>
<ns3:AirlineID>S7</ns3:AirlineID>
<ns3:FlightNumber>263</ns3:FlightNumber>
</ns3:MarketingCarrier>
<ns3:OperatingCarrier>
<ns3:AirlineID>S7</ns3:AirlineID>
</ns3:OperatingCarrier>
<ns3:ClassOfService>
<ns3:Code>W</ns3:Code>
<ns3:MarketingName></ns3:MarketingName>
</ns3:ClassOfService>
</ns3:Flight>
</ns3:OriginDestination>
<ns3:OriginDestination>
<ns3:Flight>
<ns3:SegmentKey>FL2</ns3:SegmentKey>
<ns3:Departure>
<ns3:AirportCode>SIP</ns3:AirportCode>
<ns3:Date>2016-10-06</ns3:Date>
<ns3:Time>12:10</ns3:Time>
</ns3:Departure>
<ns3:Arrival>
<ns3:AirportCode>DME</ns3:AirportCode>
<ns3:Date>2016-10-06</ns3:Date>
<ns3:Time>14:45</ns3:Time>
</ns3:Arrival>
<ns3:MarketingCarrier>
<ns3:AirlineID>S7</ns3:AirlineID>
<ns3:FlightNumber>264</ns3:FlightNumber>
</ns3:MarketingCarrier>
<ns3:OperatingCarrier>
<ns3:AirlineID>S7</ns3:AirlineID>
</ns3:OperatingCarrier>
<ns3:ClassOfService>
<ns3:Code>S</ns3:Code>
<ns3:MarketingName></ns3:MarketingName>
</ns3:ClassOfService>
</ns3:Flight>
</ns3:OriginDestination>
- Обязательно ли внесение отчества при создании бронирования? Какие элементы внесения данных пассажира обязательны?
Отчество необязательно. Необходимы: фамилия и имя, контакты пассажира, полётный сегмент.
- Соответствует ли установление автоматического тайм лимита при создании брони правилам применения тарифа авиакомпании?
Не получится ли, что срок выкупа билета истечет раньше, чем установленный автоматический тайм лимит?
Автоматический тайм-лимит присутствует.
- Для чего нужен ручной тайм лимит?
Более ручной тайм-лимит можно не использовать. Автоматический полностью соответствует актуальным правилам тайм-лимита и исключает ситуацию из вашего 6 вопроса.
- Нужно ли менять установленный автоматический тайм лимит в зависимости от ремарок авиакомпании о сроках выкупа (SSR). Есть ли такое понятие в NDC?
Установки автоматического тайм-лимита происходит согласно правилам, которые используется при покупке на сайте.
- Если необходимость корректировать тайм лимит в зависимости от полученной ремарки авиакомпании имеет место, то какой метод это позволяет?
Такой метод не предусмотрен.
- В каком формате вносятся паспортные данные пассажира? (DOCS? FOID ?)
Присутствуют SSR DOCS, FOID. Ниже пример из терминала при открытии, созданной брони через API.
- Почему во внесении данных о пассажирах есть обязательное поле – даты выдачи документа, а в отображении PNR данного поля нет. Или оно не обязательное?
Это поле можно не указывать. Бронь сформируется без него.
- Почему нет паспортных данных по младенцу?
У младенца нет паспорта, однако есть свидетельство о рождении. Данные свидетельства так же вносятся в запросе OrderCreate в блоке <ns3:PassengerDocument>
- Гражданство – это <ns3:CountryOfResidence>? А национальность? - <ns3:BirthCountry>? Или это одно и тоже? В чем разница?
<ns3:BirthCountry> </ns3:BirthCountry> — код страны выдачи документа; <ns3:CountryOfResidence> </ns3:CountryOfResidence> — гражданство.
- Почему нет ассоциации младенца с взрослым?
Ассоциация младенца со взрослым происходит. Привожу текст из документации:
- Будет ли отображаться информация о EMD, если EMD будет выписано?
Да, информация о EMD будет указана аналогично EMD.
- Правильно ли я поняла: когда мы через API вносим паспортные данные, то они вносятся в PNR в 2х форматах автоматически: SRDOCR и SRFOID ? При изменении данных обновление информации также производится в обоих ремарках?
Всё верно. В инициирующем запросе на формирование брони (OrderCreateRQ) агент указывает только паспортные данные. SSRCode="DOCS" и SSRCode="FOID" самостоятельно агент не указывает – это наша забота.
- Какие коды SSR реализованы? Можете прислать список?
SSR DOCS, FOID, CHLD (ребёнок от 2 до 12 лет), INFT (ребёнок до 2 лет), FQTV (информация по мильной программе постоянного пассажира), TKNE (номер ETK), XBAG (сверхнормативный багаж), EXST (доп.место)
- DOCA и DOCO - это одни из кодов SSR, которые есть согласно вашего ответа в п.14. Если не реализованы эти коды, то как агенты добавляют данную информацию? или S7 не летает по маршрутам, где требуется внесение данных визы и места пребывания?
Опишу подробнее, в созданном PNR можем корректировать SSR, а именно: контакты (телефон, емайл), паспортные данные (DOCS) и FOID, FQTV.
Что касается DOCA/DOCO, то действует принцип, как при покупке билета через сайт. Информация о визе указывается на этапе регистрации на рейс при полётах в Германию, Испанию, США, т.е. на этапах создания брони, выписки билета мы не требуем данные визы. Такой же принцип используется на API.
- Установление автоматического тайм лимита гарантирует автоматическое снятие брони системой в указанное в тайм лимите время? Не будет заморозки мест?
Да, гарантирует и заморозки не будет.
- VOID билета разрешен как обычно до 23.59 текущих суток выписки? По какой тайм зоне?
Тайм-зона — GMT +0
- При запросе дополнительного сервиса – багаж (BaggageCharges) система выдает только сверхнормативный багаж, который платный? Или есть еще другие опции?
Нужен ли ввод какого-то свободного текста, чтоб забронировать багаж? (например, вес и размеры) или такие данные уже заложены автоматически.
BaggageCharges — предоставляет дополнительный багаж по определенному перелету. Да, он платный и ввод свободного текста не нужен.
- Пытаемся завойдировать билет, но ничего не выходит! Что не так?
Правило: какой валидатор выписывает билет, тот же валидатор и войдирует.
Проверьте, что валидаторы одинаковые.
- Есть какие-то особенности при войдировании ETK, EMD?
- ETK, EMD могут быть войдированы до конца текущих суток, когда они были выписаны.
- Войдировать может только тот валидатор, которым была произведена выписка ETK, EMD.
- В запросе AirDocVoidRQ стоит обратить внимание на код:
<ns3:Type>
<ns3:Code>702</ns3:Code> ——> для войдирования ETK
</ns3:Type>
<ns3:Type>
<ns3:Code>Y</ns3:Code> ——> для войдирования EMD
</ns3:Type>
- VOID билета разрешен как обычно до 23.59 текущих суток выписки? Есть ли еще какие-нибудь ограничения на VOID?
Более ограничений нет, кроме обычного — войдирование производится до 23-59 (GMT +0) текущих суток выписки.
- По поводу VOID – а если вылет в день выписки? За сколько часов до вылета можно VOID сделать. Или можно даже и после вылета до 23.59, если билет не использован.
Главное не допустить NO SHOW – ситуация, когда пассажир не явился на рейс, не поставив в известность а/к. Если предупредили, места сняли — войдировать легально после вылета до 23:59, но желательно лучше выполнить до вылета.