1 Introduction
2 New Roles/Entities
3 Requirements / Limitations
4 Flows
- 4.1 OrderRetrieve
- 4.2 OrderChange - Payment
  - 4.2.1 With CorporateSender
  - 4.2.2 Without CorporateSender
- 4.3 ServiceList
- 4.4 OrderChange - Add Ancillary
5 Errors

Introduction

This functionality allows one IATA Travel Agent to access another IATA Travel Agents bookings, as long as they are both using the same Aggregator, and said Aggregator has the necessary functionality in place to manage the security. This is similar to the legacy concept known as “Extended Office Security”, “Branch Access” or “Bridging”.

This does not affect AirShopping, OfferPrice and OrderCreate which continues to be done by a single Travel Agent as always. After Order creation most services can be called using IATA Delegation. This applies to pre and post payment/ticketing. This allows bookings to be; booked by one travel agency office and then ticketed by another, such as a centralised location; serviced by another Travel Agent, often within the same chain of agencies/organisation, either before or after the payment and issuance of the Order.

The IATA used to issue the documents in the first instance is the one that will be used to issue any and all subsequent documents (ETKT, EMD).

New Roles/Entities

For the purpose of this functionality, two new roles/entities have been created:

Responsible_IATA
- This is the Travel Agent who is responsible for the booking. Initially, and where IATA Delegation is not used, it is the Travel Agent who creates the booking. However, when IATA Delegation is used, and a Travel Agent, who is not the creator pays for and issues the tickets, then the Travel Agent who has paid for the booking and “issued” the tickets becomes the “Responsible_IATA” from that moment onwards, and will not change.
Servicing_IATA
- This is the Travel Agent who is executing the servicing requests.

These two new roles/entities only need to be identified in the messages when they are both TravelAgentParticipants and the Sender is a CorporateSender. Otherwise, when using IATA Delegation, the Sender is the Servicing_IATA and the TravelAgentParticipant is the Responsible_IATA.

<Party>
  <Sender>
      <TravelAgencySender>
        <IATA_Number>11111111</IATA_Number>
        <AgencyID>AGENCIA_B</AgencyID>
      </TravelAgencySender>
  </Sender>
  <Participants>
      <Participant>
        <TravelAgencyParticipant SequenceNumber="1">
            <IATA_Number>22222222</IATA_Number>
            <AgencyID>AGENCIA_A</AgencyID>
        </TravelAgencyParticipant>
      </Participant>
      <Participant>
        <AggregatorParticipant SequenceNumber="2">
            <AggregatorID>99999999</AggregatorID>
        </AggregatorParticipant>
      </Participant>
  </Participants>
</Party>

<Party>
  <Sender>
      <CorporateSender>
        <ID>ABC123</ID>
      </CorporateSender>
  </Sender>
  <Participants>
      <Participant>
        <TravelAgencyParticipant SequenceNumber="1">
            <Name>Agency_B</Name>
            <Type>SERVICING_IATA</Type>
            <Contacts>
              <Contact>
                  <EmailContact>
                    <Address>foo.bar@agency_b.com</Address>
                  </EmailContact>
                  <PhoneContact>
                    <Application>BUSINESS</Application>
                    <Number>+34111222333</Number>
                  </PhoneContact>
                  <Name>
                    <Surname>Doe</Surname>
                    <Given>John</Given>
                  </Name>
              </Contact>
            </Contacts>
            <IATA_Number>11111111</IATA_Number>
            <AgencyID>AGENCIA_B</AgencyID>
        </TravelAgencyParticipant>
      </Participant>
      <Participant>
        <TravelAgencyParticipant SequenceNumber="2">
            <Type>RESPONSIBLE_IATA</Type>
            <IATA_Number>22222222</IATA_Number>
            <AgencyID>Agency_A</AgencyID>
        </TravelAgencyParticipant>
      </Participant>
      <Participant>
        <AggregatorParticipant SequenceNumber="3">
            <AggregatorID>99999999</AggregatorID>
        </AggregatorParticipant>
      </Participant>
  </Participants>
</Party>

Requirements / Limitations

In order to use this functionality the following points must be taken into consideration:

Only Aggregators and IATA Travel Agents that are registered and certified with Iberia’s NDC API are eligible to use this functionality.
Both the Aggregator and Travel Agent and must have signed an addendum to our Terms & Conditions taking responsibility for data protection and fraud control prior to implementation. This will be part of the certification process.
- Please open a service desk here to request access to use this functionality.
Delegation between different Aggregators is not permitted. The servicing of an Order can only be undertaken using the same Aggregator participant that was used for its creation.
Cross-border IATA Delegation is not supported. All Travel Agents, both Servicing and Responsible must be in the same country.
For Corporate Fares/Products, a valid relationship must be in place, in the Iberia Sales Database, between all the Travel Agents (IATA’s) involved and the Corporate entity
For Private Leisure Fare products, all Travel Agents (IATA’s) involved must have access to the same private fare products
The IATA used to issue documents is checked and reported to the BSP NDC Risk Management APIs.
The Travel Agent who’s IATA is used to issue all documents (the Responsible_IATA) is responsible for any and all settlement.
Any and all additional documents (re-issues, EMDs, etc.) will be issued and reported to BSP/ARC using the Responsible_IATA’s credentials.
If a change results in a Split, the new Order will maintain the Responsible_IATA of the original Order.
All confirmation emails will be sent to the Travel Agents email stored in the Order.
OrderList API is excluded from this functionality.
The OrderID must be used, and not the 5/6 digit BookingReference, in messages when this functionality is being used.

Flows

The initial shopping and ordering flows are not impacted in any way, as IATA Delegation is only applicable in the servicing flows.

OrderRetrieve

In the OrderRetrieveRQ the Servicing_IATA is the Sender, and the Responsible_IATA is sent as a Participant, together with the original AggregatorParticipant. Remember you must use the OrderID.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:ns="http://www.iata.org/IATA/EDIST/2017.2">
    <soapenv:Header/>
    <soapenv:Body>
        <OrderRetrieveRQ Version="5.000" PrimaryLangID="es"
            xmlns="http://www.iata.org/IATA/EDIST/2017.2">
            <PointOfSale>
                <Location>
                    <CountryCode>ES</CountryCode>
                </Location>
            </PointOfSale>
            <Document>
                <ReferenceVersion>5.000</ReferenceVersion>
            </Document>
            <Party>
                <Sender>
                    <TravelAgencySender>
                        <Name>TestTravelAgency</Name>
                        <Contacts>
                            <Contact>
                                <EmailContact>
                                    <Address>agentsemail@email.com</Address>
                                </EmailContact>
                                <PhoneContact>
                                    <Application>MOBILE</Application>
                                    <Number>+34123123123/Number>
                                </PhoneContact>
                                <Name>
                                    <Surname>Perez</Surname>
                                    <Given>Pepe</Given>
                                </Name>
                            </Contact>
                        </Contacts>
                        <IATA_Number>11111111</IATA_Number>
                        <AgencyID>TestTravelAgency</AgencyID>                        
                    </TravelAgencySender>
                </Sender>
                <Participants>
                    <Participant>
                        <TravelAgencyParticipant SequenceNumber="1">
                            <Name>AnotherTestAgency</Name>
                            <Contacts>
                                <Contact>
                                    <EmailContact>
                                        <Address>anotheremail@email.com</Address>
                                    </EmailContact>
                                    <PhoneContact>
                                        <Application>BUSINESS</Application>
                                        <Number>+34666666555</Number>
                                    </PhoneContact>
                                    <Name>
                                        <Surname>Martinez</Surname>
                                        <Given>Pepe</Given>
                                    </Name>
                                </Contact>
                            </Contacts>
                            <IATA_Number>22222222</IATA_Number>
                            <AgencyID>AnotherTestAgency</AgencyID>
                        </TravelAgencyParticipant>
                    </Participant>
                    <Participant>
                        <AggregatorParticipant SequenceNumber="2">                           
                            <AggregatorID>33333333</AggregatorID>
                        </AggregatorParticipant>
                    </Participant>
                </Participants>
            </Party>
            <Query>
                <Filters>
                    <OrderID Owner="IB">IB48082d51f50c474d966a06efa4c5ed19OC</OrderID>
                </Filters>
            </Query>
        </OrderRetrieveRQ>
    </soapenv:Body>
</soapenv:Envelope>

In the OrderViewRS the Servicing_IATA is returned as the Sender, and the Responsible_IATA is returned as the Participant. The AggregatorParticipant is not included, as is normal in our implementation.

Remember that Iberia does not use the <AgencyID> element and due to it being mandatory in the schema we simply return the same as the <Name>.

OrderChange - Payment

When a Servicing_IATA is paying for and issuing an Order, created previously by the Responsible_IATA, the Servicing_IATA sends the OrderReshop (to Reprice) and the OrderChange (with Payment). From this moment onward, once paid and issued, the Servicing_IATA paying and issuing the Order becomes the Responsible_IATA.

With CorporateSender

The following examples are when the servicing messages use the CorporateSender in the Party section:

As the Responsible_IATA has now changed to the IATA that has paid for and issued the documents, only their details are returned in the OrderViewRS, with the previous Responsible_IATA’s details.

Without CorporateSender

The following examples are when the CorporateSender in the Party section is not included in the servicing messages. In these cases we use the CorporateID stored in the Order at creation:

As the Responsible_IATA has now changed to the IATA that has paid for and issued the documents, only their details are returned in the OrderViewRS, with the previous Responsible_IATA’s details, and without the AggregatorParticipant details.

ServiceList

OrderChange - Add Ancillary

Remember the additional documents are issued and reported with the IATA of the Resposible_IATA who issued the original tickets.

Errors

There are 7 error codes applicable to this functionality: NDC_DIST_IAD_0001 through 7. They all carry the same text, and due to security issues the reason for each one is kept internal within Iberia. All of them generally mean you have not met the security requirements to use this functionality.