Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Children Display | ||||||
---|---|---|---|---|---|---|
|
Common questions
How to access the product environment?
What types of passengers are used in the API?
3 types of passengers are used:
adult (ADT) — passengers from 12 years and older
child (CHD) — passengers from 2 to 12 years
infant (INF) — passengers under 2 years
Note | ||
---|---|---|
| ||
|
What types of payment can be used?
Only one payment method is used - invoice
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
<Type>
<Code>MS</Code>
</Type>
<Other>
<Remarks>
<Remark>IN*A*AGENT_NAME</Remark>
</Remarks>
</Other> |
where
MS — payment type code (invoice)
IN*A*AGENT_NAME — agent details
Note | ||
---|---|---|
| ||
|
How can I get information about flights commissions and manage agency fees?
You need to contact the sales department.
Enviroment
Is the Multi-City method implemented in API?
Yes
How does the standard ticketing scenatio looks?
searchFlight (AirShoppingRQ) → book (OrderCreateRQ) → reprice (ItinReshopRQ) → demandTicket (AirDocIssueRQ)
You can read about it here Scenarios
Is it possible to use social categories of passengers - pensioners, youth, sailors, students, etc.?
No. Only 3 types of passengers are used: ADT, CHD, INF.
Can I get a terminal text vuew of the current PNR data? Or just build a template from an XML response?
No, currently only XML display is available.
Can I add DOCO DOCA information?
No, currently only DOCS, FOID and FQTV SSRs are available.
- Нужен доступ к WSDL-схеме сервиса. В документе приведена ссылка https://qa-gaia.s7.ru/agent-api/wsdl/0.21?wsdl
Но по ней получаем ошибку HTTP 400 No required SSL certificate was sent. Скорее всего это означает, что доступ закрыт.
- Нужен доступ к WSDL-схеме сервиса. В документе приведена ссылка https://qa-gaia.s7.ru/agent-api/wsdl/0.21?wsdl
Доступ предоставляется агентам владеющим: basic-auth, сертификатом. Не имея таковых – агенты получают ошибку доступа. Прошу попросить представителей Портбилета оформить в jira задачи на выдачу сертификата, basic-auth.
How to access the test environment?
Подробности по созданию можно найти здесь: создание запроса на сертификат
- В документации не описана возможность получения маршрутной сетки.
Запроса на предоставление маршутной сети S7 – нет.
- Все ли тарифы S7 брендированные? Если нет, то может возникнуть проблема с получением всех тарифов для небрендированных тарифов, в документации это не описано.
Тарифы брендированные.
Is the refund method implemented in API?
No, currently the refands are not implemented.
- При попытке послать запрос на API, через SOAPUI, получаем в ответ 'Unknown operation.'
Подозреваю, что не прописана версия в http header. Указывали версию? Первичная настройка инструмента SoapUI
Expand | ||
---|---|---|
| ||
Прекрасно, выполнить следующие шаги Prod NDC API
Мы используем три типа пассажиров: ADT - старше 12-ти лет, CHD - младше 12-ти лет, но старше 2-х лет, INF - до 2-х лет.
Все оплаты происходят только через Invoice. Отметим, что обработка платежей происходит не на нашей стороне. Invoice <ns3:Type> где MS — константа, IN*A*AGENT_NAME — реквизиты агента
По данной информации стоит обратиться в Департамент продаж (ДП)
QA — https://qa-gaia.s7.ru/agent-api/gaia PROD — https://api.s7.ru/agent-api/gaia
Нет
Да, такую ситуацию мы учитываем.
Создаём бронирование (OrderCreateRQ) > Уточняем цену (ItinReshopRQ) > Выписываем билет (AirDocIssueRQ)
Социальных категорий нет. Используем три типа пассажиров:
Терминальный текст не реализован.
Данный функционал не реализован
Доступ предоставляется агентам владеющим: basic-auth, сертификатом. Не имея таковых – агенты получают ошибку доступа. Прошу попросить представителей Портбилета оформить в jira задачи на выдачу сертификата, basic-auth.
Подробности по созданию можно найти здесь: создание запроса на сертификат
Запроса на предоставление маршутной сети S7 – нет.
Тарифы брендированные.
На текущий момент возвраты, очереди не реализованы в API.
Подозреваю, что не прописана версия в http header. Указывали версию? Первичная настройка инструмента SoapUI |
Expand | ||
---|---|---|
| ||
Данный блок описывает штрафы соответствующие определённому FareGroup. Штрафы имеют несколько типов: ADE (After departure), PDE (Prior to departure) - это штрафы, если человек обратится после вылета или до, NS (noshow) - неявка на рейс.
AirShopping выполняет поиск предложений с минимальной стоимостью (Y - эконом, C - бизнес). BFAirShoppingRQ это уже поиск предложений для тарифной сетки: basicEconomy, flexEconomy, basicBusiness, flexBusiness. Slice0 показывает варианты для полёта туда, а Slice1 - обратно.
Проверьте верность реквизитов доступа к сервису NDC API в блоке Party к выбранной площадке (QA, Prod).
Поддерживаем два решения. Можно не указывать вообще или поставить 0.
Поиск с опцией на диапазон дат не реализован, но планируется (подробности будут после разработки). Но если зададим поиск,
Есть
Рейсы S7, GH и codeshare. Появление интерлайнов планируем выкатить в prod/qa в скором времени, проинформируем дополнительно об этом.
В circuityLimit нельзя установить значение равное 0, стоит просто его убрать, если не желаете применять. На своей стороне мы определили оптимальные значения circuityLimit и durationLimit, которые соответствует выдаче, как на сайте s7.ru.\ Да, мы можем регулировать выдачу прямые рейсы или нет — отвечает значение DirectPreferences: Exclude - прямые + трансферы, Preferred - только прямые.
Упоминаемые Вами суффиксы пассажиров разных типов мы не указываем на ответе AirShoppingRS. Эти данные можно найти в ответе запроса ItinReshopRQ.
Указывайте всегда на QA/ PROD <ns3:AircraftCode>ref</ns3:AircraftCode>. ref — заглушка.
Штрафы имеют несколько типов: ADE (After departure), PDE (Prior to departure) - это штрафы, если пассажир обратится после вылета или до, NS (no-show) - неявка на рейс. Возвраты в API ещё не реализованы, а правила можно посмотреть в ответе запроса FareRulesRQ.
На сколько помню, то у нас сейчас таких рейсов на текущий момент нет. Но этот момент мы должен быть учтён в рамках flightinfo.
Информация о типе питания есть в ответе запроса flightinfo.
Тайм-лимит для выписки мы не предоставляем на этапе шоппинга, только после создания брони.
Да, такую ситуацию мы учитываем. |
title | Бронирование |
---|
Какие типы документов поддерживаются?
Номер документа в бронировании указывать можно какой угодно. Но тип документа – всегда 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"/>
Вводите символы, которые не поддерживаются, например: ; : * ' " ^ { } [ ] < > & # ! ` = %
Note |
---|
Хотим обратить ваше внимание: |
На этапах создания брони (OrderCreateRQ), репрайса (ItinReshopRQ) полётные сегменты стоит распределить по блокам OriginDestination по соответствующим направлениям, т.е. рейсы туда вставляем в один OrginDestination, а рейсы обратно в другой блок OriginDestination.
Например, RT DME-SIP:
Code Block | ||
---|---|---|
| ||
<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) система выдает только сверхнормативный багаж, который платный? Или есть еще другие опции?
BaggageCharges — предоставляет дополнительный багаж по определенному перелету. Да, он платный и ввод свободного текста не нужен.
Expand | ||
---|---|---|
| ||
Для внесения доп.услуг в существующий PNR - используем запрос OrderChange. На текущий момент запрос позволяет добавить места, ремарки в бронь, а со временем реализуем такую же возможность и для багажа.
Да, возможно. Добавление мест, багажа.
Поддерживается изменение паспортных данных и FOID |
Expand | ||
---|---|---|
| ||
ETK - электронный билет. EMD (Electronic Miscellaneous Document) - квитанция разных сборов (выбор места, до.багаж). Стоит отметить, что запросах на зачитку/войдирование Type"Code" для ETK - 702, а для EMD - Y.
Нет. ETK (электронный билет) оформляется на все сегменты маршрута. Но выписывается ETK на каждого пассажира, указанного в брони.
На текущий момент — нет.
После выписки ETK.
Выдача терминальнго вида квитанции EMD не реализована в API. Данные о выписанном бланке EMD можно посмотреть с помощью метода AirDocDisplayRQ.
Да, необходимо указывать. |
title | Войдирование |
---|
- Пытаемся завойдировать билет, но ничего не выходит! Что не так?
Правило: какой валидатор выписывает билет, тот же валидатор и войдирует.
Проверьте, что валидаторы одинаковые.
- Есть какие-то особенности при войдировании ETK, EMD?
- Есть какие-то особенности при войдировании 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, если билет не использован.
Table of contents:
Table of Contents |
---|