This task allows the user to add new seats or change or delete existing seats in a PNR/BF.
Transaction Name:
PNRBFManagement_12
Can any other transaction(s) perform this same task?
Previous versions of PNRBFManagement, PNRBFBuildModify_7_7_1, and PNRBFReservationModify_5_0_2 support the processing of seats in a PNR/BF.
PNRBFReservationModify_5_0_2 can be used to create a PNR in a sessioned or non-session environment, but cannot be used to maintain PNR/BF data because PNRBFReservationModify_5_0_2 does not include a PNR/BF retrieve process.
Can this task be performed in a sessionless environment?
This task cannot be performed in a sessionless environment unless the Seat Processing task is combined with the other tasks that create a PNR/BF. The minimum necessary tasks include PNR/BF Maintenance for Primary Fields, Air Segment Sell via Direct Sell, and Finish Active PNR/BF.
Are the request and response identical on both the Apollo and Galileo systems? If not, describe the differences.
The request and response for this task are identical on both the Apollo and Galileo systems.
Industry-specific knowledge required to understand this task.
This task uses an NWB structure versus a KLR structure. An NWB is a string of data set up as specified in the NWB documentation. Seat data can be added, deleted, and changed within the same NWB.
Special limits or distinct restrictions to the input data.
Seats cannot be added to a PNR/BF until there is at least one Name and one Air Segment present in the PNR/BF.
The maximum time limit for seating for a direct link from the vendor is 362 days. For a non-direct link availability from the CRS, the maximum time limits is 330 days. However, the actual time limits vary by vendor.
Request:
For Seat requests, <SeatSellMods> (3030 5.0) is required with the data included in <SeatSellMods>. All data to be maintained (added, changed, or deleted) is sent in one element with the number of each type of modification specified in fields in the request. Each type of modification has a specified layout. Details of all the various layouts are in the request documentation.
Prerequisite tasks:
For Seat data to be changed or deleted, or for Seat data to be added to an existing PNR/BF, the PNR/BF must first be retrieved. For information on this see the documentation for the transaction AgencyPNRBFDisplay_9_0.
A seat map for the flight, if available, can be requested using the SeatMap_5_0 transaction. However, SeatMap_5_0 is a stand-alone transaction, and is not a required prerequisite to seat assignment.
Expected response:
The response from a Seat request is always <SeatSell> (3031). A matching response for each request (if multiple types of modifications are requested) will be returned. Each response contains the associated request number (from the <SeatSellMods>) and a status for the response. Based on the type of request and the status of the response, additional data may also be returned in the <SeatSell>.
Error and warning responses:
The following are the possible status returns for the <SeatSell>. Not all status returns apply to all types of requests.
00 Modify was successful and flight/seat information follows
01 No segment matching input in PNR/BF
02 Cancel/modify request, but no seats this segment
03 Cancel request failed
04 Seat modify general error
05 Seat modify failed due to new seats not available
06 General seat request error
07 System error occurred
08 Seat request date is out of range
09 Requested seats not available
10 Generic seating no supported on this airline
11 Invalid seat number
12 Invalid seat characteristic
13 No seating this flight
14 Seat data already exists
15 General error occurred
Follow-on requests:
There are no follow-on requests.
|
<SeatSellMods> |
Terminal Equivalents: |
Apollo __9S, 9C, 9X__ |
Galileo __S., S.@____ |
|
||||
|
Ordering |
NWB |
Min/Max |
XML Tag |
||||
|
|
3030 |
0 1 |
<SeatSellMods> |
||||
|
<SeatSell> |
|
|
||||
|
Ordering |
NWB |
Min/Max |
XML Tag |
||
|
|
3031 |
0 1 |
<SeatSell> |
||