This task enables the user to create and modify manual fares. This task is very useful when:
Transaction Name:
DocProdFareManipulation_10
Can any other transaction(s) perform this same task?
No other transaction can perform this task.
Can this task be performed in a sessionless environment?
This task must be used in a sessioned environment.
Are the request and response identical on both the Apollo and Galileo systems?
The request and response are similar in some ways between the Apollo and Galileo cores, but they also vary in what data is provided and how it is provided.
List any industry-specific knowledge required to understand this task in terms of the specific business process.
An understanding of ticketing, pricing, and fares is beneficial for this task.
Explain any special limits or distinct restrictions to the input data that may not be readily apparent.
The limitation is on the Apollo (1V) system. The following modifiers can be entered at the time of Manual Fare pricing and cannot be updated later:
Galileo (1G) Description
Request:
Unless otherwise specified, use ALL CAPS in any request data.
Following are the steps required to carry out this task:
Create a Booking File; file Manual Fares.
The <ManualFareUpdateSaveMods> (4016 1.2) is used for Manual Fare Update. The following
requests are sent for
with this entry:
| Element | Description |
| <FareNumInfo> | Establishes the Fare Relationship. |
| <GenQuoteDetails> | Generates a General Quote Information response. |
| <AgntEnteredPsgrDescInfo> | Generates a Passenger Description entered by the user. |
| <FareConstruction> | Generates the Fare Construction response. |
| <SegRelatedInfo> | Specifies Segment Specific Information response. |
| <PsgrFacilityCharge> | Specify the Passenger Facility Charge Information response. |
| <InfoMsg> | Generates the Informational Messages response. |
| <TaxBreakdown> | Generates the Fare Quote Tax Breakdown response. |
| <AssocPsgrs> | Specifies the Passenger Relationship. |
| <AssocSegs> | Specifies the Itinerary Relationship. |
| <PlatingAirVMod> | Specifies the Plating Carrier. |
Prerequisite tasks:
The Booking File must be present in the AAA.
Expected response:
The response <ManualFareUpdate> (4017) includes the <FareNumInfo> and the <DPOK> tags.
Error and warning responses:
If there is an error, it is sent back with <ErrText> tag in the <ManualFareUpdate> (4017) response.
Follow-on requests:
None.
Apollo (1V) Description
Request:
Unless otherwise specified, use ALL CAPS in any request data.
The <ManualFareUpdateSaveMods> (4016) is used to request Manual Fare pricing equivalent to the ‘HHPR’ action code on the terminal emulation. Currently on terminal emulation, the manual pricing is a step-by-step process that consists of filling/re-submitting the required information for the Manual Fares in different Fill-In-Format screens. The request for Manual Fares through XML Select, however, contains ALL of the information used to build or update the Manual Fares in the PNR, including all tax related information. This process is not an iterative or step-by-step process:
All of the information required for Manual Pricing (Create/Update) is sent by the client with the <ManualFareUpdateSaveMods> in the respective requests. The relationship between the information submitted back on the terminal emulation path in the form of FIF Screens for Manual Pricing and information submitted back on the structured data path in form of requests is:
|
Terminal Emulation Manual Pricing Information |
XML Select |
Comments |
|
$NME FIF Screen |
||
|
Base Fare Details, Equivalent Fare Details, Total Fare Details |
<GenQuoteDetails> |
|
|
Commission Amount/Percentage |
<Commission> |
|
|
$TA FIF Screen |
||
|
Tax Details |
<GenQuoteDetails> |
|
|
PFC Details |
<PsgrFacilityCharge> |
|
|
ROE (Rate of Exchange) |
<RateOfExchangeMod> |
|
|
$ZP FIF Screen |
||
|
Tax Break down for ZP Tax |
<TaxBreakdown> |
|
|
$UC FIF Screen |
||
|
Determine Undecodable Cities from PNR Air Itinerary |
<CityCodeMod> |
At the time of Manual Fares Setup <ManualFareSetup_1_0>, pre-requisite for Manual Fares Create |
|
Undecodable City Codes and their corresponding description |
<ItineraryCity> |
At the time of Manual Fares Create or Manual Fares Setup <ManualFareSetup_1_0> |
|
$FC FIF Screen |
||
|
Fare Construction free-form text |
<FareConstruction> |
At the time of Manual Fares Create or Manual Fares Setup <ManualFareSetup_1_0> |
|
Maximum Fare Construction length information based on the Ticket Type |
<FareConstructionLength> |
At the time of Manual Fares Setup <ManualFareSetup_1_0>, pre-requisite for Manual Fares Create or Manual Fares Update |
|
Predefined text length Information for respective FOPs in case of ‘ATB’ Printer Type |
<FareFOPLength> |
At the time of Manual Fares Setup <ManualFareSetup_1_0>, pre-requisite for Manual Fares Create or Manual Fares Update |
In addition, the following requests must be sent in by the client at the time of the Manual Fare Create or the Manual Fare Update for the Segment information and the Passenger information:
|
Structured Data Manual Pricing Information |
Tag |
Comments |
|
Segment details containing the information on Not Valid Before Date (NVB), Not Valid After Date (NVA), Fare Basis Code, Ticket Designator (GTD), Fare for this segment |
<SegRelatedInfo> |
|
|
Open Segment data request containing details of Flight Number (sent as word “OPEN” for open flight number), Class of Service, Date of Travel, Time of Travel, Segment Status |
<SegmentData> |
One should exist for each <SegRelatedInfo> tag if the segment is an open segment and should be immediately followed by the corresponding <SegRelatedInfo> tag. |
|
Segment Mapping request |
<SegMapping> |
Contains details of number of segments. The FIC code in this request should be ‘Y’ or ‘N’ for the respective segments in this request. This request is used for validation of number of Segments from the PNR both when pricing is done for all segments in PNR and also when segment selection is made. |
|
Passenger details request contains the details of the passenger to which the particular Quote (<GenQuoteDetails> tag) fare details apply. It carries the details of passengers as an array item which is grouped under a common quote (<GenQuoteDetails> tag). It also carries a field which says ‘PFC APPLIES’, this should be ‘Y’ if the ‘PFC‘ and ‘XF’ taxes have been specified. The passenger array item should contain all three fields:
|
<AgntEnteredPsgrDescInfo> |
There may exist multiple <AgntEnteredPsgrDescInfo> tags depending on if different Quote details applies to the passengers being Manually Priced (different <GenQuoteDetails> tags as in the terminal emulation case of ‘HBT’). Otherwise, we may have a single <AgntEnteredPsgrDescInfo> tag with array items for passenger data if the same Quote applies to all the passengers being Manually Priced (one <GenQuoteDetails> tag as in the terminal emulation case of ‘HBTA’). |
|
Passenger Selection request |
<AssocPsgrs> |
If a Passenger selection is made at the time of the Fare Quote (as in an HHPRN1|2 from terminal emulation) then, in addition to the passenger details sent in by the client in the <AgntEnteredPsgrDescInfo> tag, separate <AssocPsgrs> tags must be sent for the respective Passengers being selected. |
|
Service fee association modifier |
<ServiceFees> |
This tag has information about thet Service Fee association ticketing modifier. For example, Service fee number (mandatory), Pseudo city code (Optional), Date (optional), which needs to be associated with the ticket. |
Prerequisites tasks:
A PNR with air segments in the itinerary must be present in AAA.
Additionally, the ManualFareSetup_1_0 transaction must be entered to provide necessary data used to build the Manual Fare. The Manual Fare Setup transaction will provide data that is needed by the client when building the Fare Construction data in the <FareConstruction> element. <FareConstruction> provides how much data the user is allowed to enter based on fixed data that is included. See the Special Rules section in this document for how the length values are used.
The following is a summary of specific fields in some Manual Fare responses:
1. The Unique Key field is used in the relationship between the other GF/DP KLRs that follow in the request/update for Manual Fares. Although this request is defined as an Alphanumeric field, it acts like a Numeric field. The Unique Key field must always be sent in by the client as right-justified, zero-filled numeric data (e.g., if the data value is “1”, it must come in as “0001” because the field size is four characters).
2. The Amount fields must come in from the client without the decimal places, in the following formats:
Currency with no decimal places:
For an Amount “343”, this value
must come in as “00000000343” (right-justified, zero-filled, for a field
size of 11 characters).
Currency with
one decimal place:
For an Amount “343”, this value must come in as “00000003430”
(right-justified, zero-filled, for a field size of 11 characters).
Currency with two decimal places:
For an Amount “343”, this value must
come in as “00000034300” (right-justified, zero-filled, for a field size
of 11 characters).
Currency with three decimal places:
For an Amount “343”, this value must
come in as “00000343000” (right-justified, zero-filled, for a field size
of 11 characters).
The amount fields are:
|
Field Description |
XML Element |
|---|---|---|
|
Base decimal places |
<BaseDecPos> |
| Base fare amount | <BaseFareAmt> | |
| Equivalent decimal places | <EquivDecPos> | |
| Equivalent amount | <EquivAmt> | |
| Total decimal places | <TotDecPos> | |
| Total amount | <TotAmt> |
3. If the Tax fields in this request are omitted, the following fields must be omitted from the <GenQuoteDetails> element:
|
Field Description |
XML Element |
Field Specific Data |
|
Taxdata | <TaxdataAry> | Array |
|
Taxdata Element | <Taxdata> | FieldSet |
|
Tax country code | <Country> | Alphanumeric 2 (GRGTXC) |
|
Tax amount | <Amt> | Alphanumeric 8 (GRGTXA) |
4. The Tax Amounts field must be sent left-justified, blank-filled, with the decimals. These amounts must match the currency of the Equivalent Fare, if present, otherwise these amounts match the currency of the Base Fare, if the Equivalent Fare is not present. The field is:
|
Field Desctiption |
XML Element |
Field Specific Data |
|
Tax amount | <Amt> | Alphanumeric 8 (GRGTXA) |
These Amount fields should come in from the client with the decimal places with the format as follows:
Currency with no decimal places:
For an Amount “25”, this value
must come in as “25 ” (left-justified, blank-filled, for a field
size of 8 characters).
Currency with one decimal place:
For Amount as “25” this value must
come in as “25.0 ” (left-justified, blank-filled, for a field size of
8 characters).
Currency with two decimal places:
For Amount as “25” this value must
come in as “25.00 ” (left-justified, blank-filled, for a field size of
8 characters).
Currency with three decimal places:
For Amount as “25” this value must
come in as “25.000 ” (left-justified,
blank-filled, for a field size of 8 characters).
The Amount field may be specified as EXEMPTED instead of an amount.
5. There are a maximum of 20 Tax items in the repeating Tax Array. If there are more than 20 items, the CRS returns an error.
6. The Tax Codes must not be duplicated.
7. If the ‘XF’ is specified, then the PFCs (Passenger Facility Charge) must be specified, unless the amount for ‘XF’ tax is specified as EXEMPTED.
8. The total of the Amount specified with ‘XF’ must equal the sum of the amounts specified with the respective PFCs, if either of the following is true:
If the ‘XF’ Tax has been specified and the currency of the Equivalent Fare (if present) is ‘USD’ or
If the Equivalent Fare is not present and the currency of the Base Fare is ‘USD’
The following are fields used in this KLR for Manual Pricing:
|
Field Description |
XML Tag |
Field Specific Data |
Additional Information |
|
Unique Key | <UniqueKey> | ||
|
Quote number | <QuoteNum> | ||
|
Quote type | <QuoteType> | ||
|
Base fare currency code | <BaseFareCurrency> | ||
|
Base fare amount | <BaseFareAmt> | ||
|
Base decimal places | <BaseDecPos> | ||
|
Equivalent currency code | <EquivCurrency> | ||
|
Equivalent amount | <EquivAmt> | ||
|
Equivalent decimal places | <EquivDecPos> | ||
|
Total currency code | <TotCurrency> | ||
| Total amount | <TotAmt> | Total of base fare and taxes | ||
| Total decimal places | <TotDecPos> | |||
| Number of tax fields | <TaxDataCnt> | |||
| Taxdata | <TaxdataAry> | Array | ||
| Taxdata Element | <Taxdata> | FieldSet | Repeating Tax Items (if any) | |
| Tax country code | <Country> | Repeating Tax Items (if any) | ||
|
Tax amount | <Amt> | Repeating Tax Items (if any) |
1. A maximum of four PFC items can be specified.
2. There is an exception for Unique Key field in this request. One PFC applies across all the passenger quotes irrespective of whether all the passengers being Manually Priced fall under the same <GenQuoteDetails> element or under their respective <GenQuoteDetails> element. Therefore, the data for this field must always be “0000” for a four-character unique key field.
|
Field Description |
XML Element |
|---|---|---|
|
Unique Key |
<UniqueKey> |
3. At present, the Currency Code for the respective PFC items must be in ‘USD’, irrespective of the currency of the Base Fare and/or the Equivalent Fare.
|
Field Description |
XML Element |
|---|---|---|
|
PFC Currency Code |
<Currency> |
4. The PFC Amounts are sent as left-justified, blank-filled with two decimals because the PFC is in ‘USD’ currency.
|
Field Description |
XML Element |
|---|---|---|
|
PFC Amount |
<Amt> |
An amount specified as “4” is automatically stored as “4.00”. An amount specified as ”4.0” is stored as”4.00”
5. There are a maximum of four PFC items in the repeating PFC item array; otherwise, the CRS returns an error.
The following fields are used in this request for Manual Pricing:
|
Field Description |
XML Element |
Field Specific Data |
Additional Information |
|
Unique Key | <UniqueKey> | ||
|
Quote number | <QuoteNum> | ||
|
Number of PFC Items | <PFCCnt> | ||
|
PFC Code Array | <PFCAry> | Array | |
|
PFC Code Array Element | <PFC> | FieldSet | Repeating PFC Items (if any) |
|
PFC Airport Code | <Airp> | Repeating PFC Items (if any) | |
|
PFC Amount | <Amnt> | Repeating PFC Items (if any) | |
|
PFC Currency Code | <Currency> | Repeating PFC Items (if any) |
This request is used for the ‘ZP’ tax breakdown. If the ‘ZP’ taxes have been specified as a part of the Tax Array in the <GenQuoteDetails> tag, then the client must send in <TaxBreakdown> for the breakdown of ‘ZP’ taxes.
1. The Unique Key field is used for relationship between this request and the <GenQuoteDetails> element, for which this Tax Breakdown exists. For example, if <GenQuoteDetails> comes in with a Unique Key of “0001”, then this <TaxBreakdown> element must carry the same Unique Key of ”0001”. Likewise, if there are multiple <GenQuoteDetails> elements and corresponding multiple <TaxBreakdown> elements for the respective Tax Breakdowns, then the corresponding Unique Keys between them must be synchronized.
|
Field Description |
XML Tag |
|---|---|---|
|
Unique Key | <UniqueKey> |
2. The Tax Breakdown amounts are sent right-justified, zero-filled, without the decimals. These amounts must be specified based on the ‘USD’ currency:
|
Field Description |
XML Tag |
|
|---|---|---|
| Tax amount | <Amt> |
These Amount fields must come in from the client without the decimal places, where the format is:
Currency with two decimal places (USD):
For an Amount “4”, this value must be entered as “400” (right-justified, zero-filled, for a field size of 11 characters)
3. There are a maximum of 20 ‘ZP’ Tax Breakdown items in the repeating Tax Breakdown Array, otherwise the HOST will return an error.
The following fields are used in this KLR for Manual Pricing:
|
Field Description |
XML Tag |
Field Specific Data |
Additional Information |
|
Unique Key | <UniqueKey> | ||
|
Quote number | <QuoteNum> | ||
|
Spares | <Spare1> | ||
|
Tax Code | <TaxCode> | ||
|
Tax Currency Code | <TaxCurrency> | Always “USD” for “ZP” tax | |
|
Tax Decimal Places | <DecPos> | ||
|
Spare Indicator Byte | <Spare2> | These just come in as empty tags | |
| Number of Taxes | <TaxCnt> | |||
| Tax Array | <TaxAry> | Array |
Repeating TAX Break Down items |
|
| Tax Array Element | <Tax> | FieldSet |
Repeating TAX Break Down items |
|
| Tax city Code | <City> |
Repeating TAX Break Down items |
||
| Tax amount | <Amt> |
Repeating TAX Break Down items |
||
| Spare | <Spare3> |
Repeating TAX Break Down items |
This element is used to pass on the segment related information for the Air Segments in the PNR. A <SegRelatedInfo> element must exist for each Air Segment in the PNR that is being manually priced in the request for Manual Fare Create/Update.
1. This field is used in the relationship between this element and the <GenQuoteDetails> element for which this segment information applies. For example, if the <GenQuoteDetails> comes in with a Unique Key of “0001”, then this<SegRelatedInfo> tag must carry the same unique key of ”0001”. Likewise, if we have multiple <GenQuoteDetails> element sand corresponding multiple <SegRelatedInfo> elements, then the corresponding Unique Keys between them must be synchronized.
|
Field Description |
XML Element |
|
|---|---|---|
| Unique Key | <UniqueKey> |
2. Each <SegRelatedInfo> tag corresponding to the segments being Manually Priced must carry a Relative Segment number in the order of their sequence.
|
Field Description |
XML Element |
|
|---|---|---|
| Relative Segment Number | <RelSegNum> |
3. The ‘Fare for this Segment’ amounts are sent left-justified, blank-filled, with the decimal places. The decimal place specification in the ‘Fare for this Segment’ amount must be based on the Base Fare Currency, if not, the CRS generates an error.
|
Field Description |
XML Element |
|
|---|---|---|
| Fare for this Segment | <Fare> |
NOTE: Based on CRS constraints, the ‘Fare for this Segment’ amount is mandatory, and the sum of the respective ‘Fare for this Segment’ amounts must match the Base Fare. This constraint does not apply if the Fare Construction is specified for the particular Fare <GenQuoteDetails>.
The following fields are used in this element for Manual Pricing:
|
Field Description |
XML Element |
Field Specific Data |
| Unique Key | <UniqueKey> | ||
| Quote number | <QuoteNum> | ||
| Relative Segment Number | <RelSegNum> | ||
| Not valid before Date | <NotValidBeforeDt> | YYYYMMDD | |
| Not valid after Date | <NotValidAfterDt> | YYYYMMDD | |
| Stopover Indicator | <Stopover> | ||
| Fare Basis Code | <FIC> | ||
| Ticket Designator Code | <TkDesignator> | ||
| Fare for this Segment | <Fare> |
This element is used to carry the Open Segment information required in case of manual pricing. For an Open Air Segment, this KLR must follow the <SegRelatedInfo> for the corresponding Air Segment.
1. The Relative Segment number in the itinerary. This must match the Relative Segment number from the <SegRelatedInfo>.
|
Field Description |
XML Element |
|
|---|---|---|
| Relative Segment Number | <RelSegNum> |
2. If the data specified for this field is left-justified, blank-filled, and the field is all blanks, it indicates that no Flight Number was specified. If no flight number is present/specified, the user must send the Flight Number as the word ‘OPEN’, to indicate the flight is OPEN.
|
Field Description |
XML Element |
|
|---|---|---|
| Flight Number | <FltNum> |
3. If the Flight Number is valid numeric data (i.e., it is not ‘OPEN’), then the Date of Travel and the Time of Travel is mandatory.
|
Field Description |
XML Element |
Field Specific Data |
| Date of Travel | <StartDt> | YYYYMMDD | |
| Time of Travel | <TmTrav> |
The format is:
24-hour format GMT, 0001-2400 (right-justified, zero-filled).
For example, 11:00 PM is sent as "2300". Null
data is specified as zeros.
Note: When “0000” is a
legitimate value, it is sent as “2400”.
The following fields are used in this element for Manual Pricing:
|
Field Description |
XML Element |
|
|---|---|---|
| Relative Segment Number | <RelSegNum> | |
| Flight Number | <FltNum> | |
| Class of Service | <BIC> | |
| Date of travel | <StartDt> | |
| Time of Travel | <TmTrav> | |
| Segment Status | <SegStatus> |
1. The Unique Key field is used for the relationship between this element and the <GenQuoteDetails> element (for which this passenger information exists).
|
Field Description |
XML Element |
|
|---|---|---|
| Unique Key | <UniqueKey> |
If <GenQuoteDetails> is sent with a Unique Key of “0001”, then <AgntEnteredPsgrDescInfo> must carry the same unique key as ”0001”. If there are multiple <GenQuoteDetails> elements and corresponding multiple <AgntEnteredPsgrDescInfo> elements for the respective passengers to which the ‘Fare as Specified’ in the <GenQuoteDetails> elements applies, then the corresponding Unique Keys between these elements must be synchronized.
2. If a PFC (Passenger Facility Charge) exists in <PsgrFacilityCharge> for this fare, and this passenger is in the <GenQuoteDetails>, then the PFC Applies field is sent as a “Y” to make the PFC applicable.
|
Field Description |
XML Element |
|
|---|---|---|
| PFC Applies | <PFCApplies> |
The following fields are used in this element for Manual Pricing:
|
Field Description |
XML Element |
Field Specific Data |
| Unique Key | <UniqueKey> | ||
| PFC Applies | <PFCApplies> | ||
| PFC Applies | <PFCApplies> | ||
| Pax Descs | <ApplesToAry> | ||
| Pax Descs Element | <AppliesTo> |
Passenger description array |
|
| Last Name Number | <LNameNum> |
Passenger description array |
|
| First Name Number | <FNameNum> |
Passenger description array |
|
| Absolute Name Number | <AbsNameNum> |
Passenger description array |
This is the Segment Mapping element that carries the array of all the Air Segments to be manually priced.
1. This element is not used, and should be an empty element.
|
Field Description |
XML Element |
|
|---|---|---|
| Unique Key | <UniqueKey> |
The following fields are used in this element for Manual Pricing:
|
Field Description |
XML Element |
Field Specific Data |
Additional Information |
| Unique Key | <UniqueKey> | (no data should be sent in this field) | ||
| Number of Segments | <SegCnt> | |||
| Segment Numbers | <SegAry> | Array |
Segment Mapping Description |
|
| Segment Numbers Element | <SegInfo> | FieldSet |
Segment Mapping Description |
|
| PNR Segment Number | <Seg> |
Segment Mapping Description |
||
| FIC entered | <FIC> | 'Y' if FIC entered (GZ6IND) |
Segment Mapping Description |
This tag element is used to carry the Commission, either in the format of a percentage or an amount, with respect to the passengers being Manually Priced under a given <GenQuoteDetails> element.
1. This field is used in the relationship between this element and <GenQuoteDetails> for which this passenger information exists.
|
Field Description |
XML Element |
|
|---|---|---|
| Unique Key | <UniqueKey> |
If the <GenQuoteDetails> element is sent with a Unique Key of “0001”, then this <Commission> element must carry the same Unique Key as ”0001”. If there are multiple <GenQuoteDetails> elements and corresponding multiple <Commission> elements for the respective passengers to which the Fare as Specified in <GenQuoteDetails> , then the corresponding Unique Keys between them must be synchronized.
2. The Commission can be specified as either an amount or as a percentage. It cannot be present both as an amount and as a percentage, or an error is returned by the CRS.
Commission, when specified as an amount, is left-justified, blank-filled, with decimals. The decimals must match the decimal places as specified by the Equivalent Fare Currency (if present); otherwise, it must match the decimal places as specified by the Base Fare Currency.
|
Field Description |
XML Element |
|
|---|---|---|
| Commission Amount | <Amt> |
Commission, when specified as a percent, is always not more than two decimal places.
|
Field Description |
XML Element |
|
|---|---|---|
| Commission Percentage | <Percent> |
3. The Commission is mandatory only for Canadian BSP.
The following fields are used in this element for Manual Pricing:
|
Field Description |
XML Element |
|
|---|---|---|
| Unique Key | <UniqueKey> | |
| Commission Amount | <Amt> | |
| Commission Percentage | <Percent> |
This tag is used to carry the Rate of Exchange information for the respective <GenQuoteDetails> element .
1. This field is used in the relationship between this element and the <GenQuoteDetails> element, for which this passenger information exists.
|
Field Description |
XML Element |
|
|---|---|---|
| Unique Key | <UniqueKey> |
If the <RateOfExchangeMod> is sent with a Unique Key of “0001”, then this <RateOfExchangeMod> element must carry the same Unique Key as ”0001”. If there are multiple <GenQuoteDetails> element and corresponding multiple <RateOfExchangeMod> element for the respective passengers to which the Fare as Specified in <GenQuoteDetails> applies, then the corresponding Unique Keys between these elements must be synchronized.
2. The Rate of Exchange, if specified, is left-justified, blank-filled, and required to come in with decimal places (if present).
|
Field Description |
XML Element |
|
|---|---|---|
| Rate Of Exchange | <ROE> |
The following fields are used in this element for Manual Pricing:
|
Field Description |
XML Element |
|
|---|---|---|
| Unique Key | <UniqueKey> | |
| Rate Of Exchange | <ROE> |
This tag is used to carry the undecodeable City Code information. It carries the three character undecodable City Code along with the corresponding description for that undecodable city.
1. There can be a maximum of 30 undecodable cities. The City Codes are identified as decodable/undecodable by GMT.
The following fields are used in this element for Manual Pricing:
|
Field Description |
XML Element |
|
|---|---|---|
| City Code | <CityCode> | |
| City Name | <CityName> |
This element carries the free-form Fare Construction text as input by the user.
The information on the maximum Fare Construction text that can be entered on the Client-end, based on the respective printer type, is already sent to the client before Manual Fare Create/Update as a part of Manual Fare Setup. The client uses this to restrict the user, at the client, from keying more free-form text than is actually allowed.
In addition, for the ATB printer types, the predefined text length information for the respective FOP types is sent to the client at the time of the Manual Fare Setup. This is further used to calculate the amount of free-form text that can actually be keyed in by the user at the client. This information is used by the client along with a formula to restrict the free-form text that can actually be keyed in by the user at the client. (Note: The run-time free-form text calculation formula is explained in the following Exception Processing section.)
Expected Response:
If the Manual Fare transaction completes successfully, it returns the <DPOK> tag.
Exception Processing
The free-form Fare Construction field in the <FareConstruction> element, provides an area to build the actual construction of the fare. The amount of data, which can be provided in this field, is dependent on a number of variables.
First, the Ticket Type assigned to the agency. This information is provided from the Manual Fare Setup transaction, and indicates both the Ticket Type and the maximum length available for the Fare Construction.
Second, when the Ticket Type is ‘AB’ (ATB1 or ATB2), then the maximum length of the Fare Construction needs to be reduced by the length value corresponding to the Form of Payment used for this Fare. The length values for each type of Form of Payment are provided by the Manual Fare Setup function.
Third, the special ‘rules’ given below will help calculate the amount of spaces required for the Tax information, thus further reducing the available length of the Fare Construction.
1. If
the Rate of Exchange (ROE) data is provided, it is listed as “ROE nnn”, where
‘nnn’ is the ROE percentage.
For example: “ROE 1.25” is
a total of 9 characters that must be counted.
2. Airport
cities in the itinerary that charge a US Aviation Excise Tax ($TA on Terminal
Entries) are listed as three-character City Codes. This data is preceded by
the three characters ‘ZP’.
For example: “ZPDENEWRORD” is a total
of 12 characters that must be counted.
3. The Tax Field section begins with the four characters ' XT ', where there is space on either side of 'XT'.
4. All
individual Taxes consist of the tax dollar amount, including decimal, followed
by a two character Tax Code, such as ‘US’ or ‘ZP’.
For example: “26.80US
25.19AU” is a total of 16 characters that must be counted.
5. Airport
cities in the itinerary that have a Passenger Facility Charge (PFC) are listed
as three-character city codes with the PFC amount in truncated form. The
dollar amounts have the zeros removed, so that “4.50” becomes “4.5” and “3.00”
becomes “3”. This data is preceded with the total PFC amount and the
characters ‘XF’.
For example: “16.50XFOKC3DEN4.5SFO4.5DEN4.5” is a total of 29 characters that
must be counted.
By using all this information, the Client can build their process to dynamically to determine how much space is remaining for the user to provide Fare Construction text, thus reducing the likelihood that the CRS system returns an error indicating that the Fare Construction field exceeds the allowed length.
Example:
As a result of the Manual Fare Setup transaction, the client determines from the CRS that the Printer Type is “AB” (ATB1 or ATB2), with a maximum Fare Construction length of 242 characters. As the Manual Fare data is entered, the Form of Payment is determined to be “CASH” and the itinerary contains airport cities that have both ‘Excise Tax’ and ‘PFC’ to be included.
The above information results in the host system appending the following data: “FC CASH” and “ROE 1.25 ZPDENEWRORD XT 9.00ZP 12.00XFDEN4.5EWR3ORD4.5” for a total of 7+ 55 = 62 characters.
Note: Do NOT include this information in the Fare Construction data, use it only to determine the available free-form Fare Construction length available. In this example, this calculation reduces the total Fare Construction length from 242 – 62 = 180, or 180 characters available for the free-form Fare Construction data to be entered.
Error and warning responses:
If the Manual Fare transaction encounters an error, the error message is returned in the <ErrText> element. The following error messages may be received:
0011 - SYSTEM ERROR OCCURRED
8760 - BASE CURR ERROR
8761 - BASE CURR MANDATORY
8762 - BASE FARE MANDATORY
8763 - BASE FARE ERROR
8764 - EQUV CURR ERROR
8765 - EQUV FARE ERROR
8766 - SEGMENT FARE MANDATORY
8767 - SEGMENT FARE ERROR
8768 - FAREBASIS MANDATORY
8769 - FAREBASIS ERROR
8770 - NVB ERROR
8771 - NVA ERROR
8772 - GTD ERROR
8773 - ISO TAXCD ERROR
8774 - TAXAMT WITHOUT TAXCD ERROR
8775 - TAXCD WITHOUT TAXAMT ERROR
8776 - TAXAMT ERROR
8777 - ROE ERROR
8778 - PFC AMT ERROR
8779 - AIRPORTCD ERROR
8780 - XF MUSTEQUAL TOTPFC
8781 - PFC MANDATORY
8782 - PFC REQUIRED ONLYIF XF
8783 - ZP TAXAMT ERROR
8784 - UC CITY NAME ERROR
8785 - OPENSEG DATE ERROR
8786 - OPENSEG TIME ERROR
8787 - OPENSEG STATUS ERROR
8788 - OPENSEG FLTNBR ERROR
8789 - OPENSEG DATE MANDATORY
8790 - OPENSEG TIME MANDATORY
8791 - TAXCD DUPLICATE ERROR
8792 - ZP CURR ERROR
8793 - PFC CURR ERROR
8794 - ZP CITYCD WITHOUT TAX ERROR
8795 - ZP TAX WITHOUT CITYCD ERROR
8796 - PFC CITYCD WITHOUT AMT
8797 - PFC AMT WITHOUT CITYCD
8798 - UC CITY NAME MANDATORY
8799 - COMMISSION ERROR
8800 - COMMISSION MANDATORY
8801 - EXCEED MAX TAXCODES ALLOWED
8802 - EXCEED MAX PFC ITMS ALLOWED
8803 - EXCEED MAX ZP BRKDN ITMS
8804 - FCONSTRUCTION ERROR
8805 - COMM AMT AND COMM PCT NOT TOGETHER
8806 - SEGMENT MAPPING KLR ERROR
8807 - SEGMENT MAPPING SEGNO ERROR
8808 - TOT SEGFARE NOT EQUAL BASE FARE
8809 - OPENSEG CLASSOF SVC ERROR
8810 - SEGMENT CONN STOPOVR ERROR
8811 - TICKET DESIGNATOR CANNOT CHANGE
8812 - FLIGHT NUMBER CANNOT CHANGE
8813 - DATE OF TRAVEL CANNOT CHANGE
8814 - TIME OF TRAVEL CANNOT CHANGE
8815 - SEGMENT STATUS CANNOT CHANGE
8816 - BASE FARE CURRENCY CANNOT CHANGE
8817 - EQUIVALENT FARE CURRENCY CANNOT CHANGE
8818 - FARE CONSTRUCTION UNCHANGEABLE
8819 - NVB CANNOT CHANGE
8820 - NVA CANNOT CHANGE
For Apollo (IV) only:
0259 - INVALID FORMAT/DATA
9078 - PCC NOT ALLOWED – NO AGREEMENT
9136 - SERVICE FEE ALREADY ASSOCIATED
9137 - SERVICE FEE NOT AVAILABLE IN DATABASE, ASSOCIATION NOT COMPLETED
Follow-on:
The Enable Stored Fare task is often used as a follow-on entry to enable the Manual Fare built.
Additional capabilities:
Manual Fares can be created passenger-wise as well as segment-wise.
|
<ManualFareUpdateSaveMods> |
Terminal Equivalents: |
Apollo: see below |
Galileo: FBC, FBUFB/YUA, FBF |
|
|
Ordering |
KLR |
Min/Max |
XML Tag |
|
A |
DPFI |
1-1 |
<FareNumInfo> |
|
B |
GFGQ |
1-1 |
<GenQuoteDetails> |
|
C |
GFZ8 |
1-1 |
<AgntEnteredPsgrDescInfo> |
|
D |
GFFC |
1-1 |
<FareConstruction> |
|
E |
GFSR |
1-2 |
<SegRelatedInfo> |
|
F |
GFPF |
1-1 |
<PsgrFacilityCharge> |
|
G |
GFMM |
1-1 |
<InfoMsg> |
|
H |
GFTS |
1-1 |
<TaxBreakdown> |
|
I |
DPPI |
1-1 |
<AssocPsgrs> |
|
J |
DPII |
1-1 |
<AssocSegs> |
|
K |
DP0H |
1-1 |
<PlatingAirVMod> (Pricing/ Ticketing) |
|
<ManualFareUpdate> |
|
|
|
Ordering |
KLR |
Min/Max |
XML Tag |
|
A |
DPFI |
1-1 |
Fare Relationship |
|
B |
DPOK |
0-1 |
Document Production OK |
|
<ManualFareUpdate> |
|
|
|
Ordering |
KLR |
Min/Max |
XML Tag |
|
A |
DPFI |
1-1 |
<FareNumInfo> |
|
B |
EROR |
0-1 |
<ErrText> |
|
<ManualFareUpdateSaveMods> |
Terminal Equivalents: |
Apollo: HHPR |
Galileo: see above |
|
|
Ordering |
KLR |
Min/Max |
XML Tag |
|
A |
DPFI |
1-1 |
<FareNumInfo> |
|
B |
GFZ6 |
1-1 |
<SegMapping> |
|
C |
GFGQ |
1-9 |
<GenQuoteDetails> NOTE – This request acts as a separating request between passengers which are manually priced differently, i.e., with reference to manual pricing on the terminal emulation, this acts as a separator between different passengers which have been manually priced with ‘HBT’. We support a maximum of 9 different manually priced fares, i.e., 9 <GenQuoteDetails> tag in one Manual Fare Create / Update Transaction. |
|
D |
GFZ8 |
1-9 |
<AgntEnteredPsgrDescInfo> NOTE – Maximum of 99 passengers (in the form of an array items) but falling under a maximum of 9 fares. |
|
E |
GFTS |
0-9 |
<TaxBreakDown> (‘ZP’Tax BreakDown) NOTE – May be one per <GenQuoteDetails> tag at the maximum. |
|
F |
GFPF |
0-1 |
<PsgrFacilityCharge> NOTE – May be one <PsgrFacilityCharge> tag per Manual Fare Create / Update transaction. |
|
G |
GFSR |
1-16 |
<SegRelatedInfo> NOTE – The set of <SegRelatedInfo> tags may be replicated if we have passengers being manually priced differently, i.e. passengers falling under different <GenQuoteDetails> tags. So these may be 16 per <GenQuoteDetails> tag at the maximum which can be at max 9 * 16. |
|
H |
DPOP |
0-15 |
<SegmentData> NOTE – This request should immediately follow the corresponding <SegRelatedInfo> tag. So these may be 15 per <GenQuoteDetails> tag at the maximum Which can be at max 9 * 15. |
|
I |
DPCM |
0-9 |
<Commission> NOTE – May be one per <GenQuoteDetails> tag at the maximum. |
|
J |
DPRO |
0-9 |
<RateOfExchangeMod> NOTE – May be one per <GenQuoteDetails> tag at the maximum. |
|
K |
GFFC |
0-9 |
<FareConstruction> NOTE – May be one per <GenQuoteDetails> tag at the maximum. |
|
L |
DPUC |
0-1 |
<ItineraryCity> NOTE - One <ItineraryCity> tag per Manual Fare Create / Update transaction. |
|
M |
DP57 |
0-1 |
<ServiceFees> NOTE - Service Fee association modifier |
Note: When initially creating the Manual Fare, Ticketing modifiers may
also be included. See the DocProdFareRequote_1_0
Task Update Modifiers for Ticket Only for a complete list of potential Ticketing modifier
requests. The Ticketing
modifier requests can be sent in any order, but must be sent just after the <FareNumInfo>
tag and prior to the <SegMapping> tag. The Ticketing modifiers can NOT be sent with a
Manual Fares update request. Instead, the Update Modifiers task in the
DocProdFareRequote_1_0 transaction
must be used to change this data.
|
<ManualFareUpdate> |
|
Ordering |
KLR |
Min/Max |
XML Tag |
|
|
|
DPOK |
1-1 |
<DPOK> |
|
<ManualFareUpdate> |
|
|
|
Ordering |
KLR |
Min/Max |
XML Tag |
|
|
EROR |
1-1 |
<ErrText> |
|
|
DPFI |
0-1 |
<FareNumInfo> |
|
|
GFZ6 |
0-1 |
<SegMapping> |
|
|
GFGQ |
0-1 |
<GenQuoteDetails> |
|
|
GFZ8 |
0-1 |
<AgntEnteredPsgrDescInfo> |
|
|
GFTS |
0-1 |
<TaxBreakDown> |
|
|
GFPF |
0-1 |
<PsgrFacilityCharge> |
|
|
GFSR |
0-1 |
<SegRelatedInfo> |
|
|
DPOP |
0-1 |
<SegmentData> |
|
|
DPCM |
0-1 |
<Commission> |
|
|
DPRO |
0-1 |
<RateOfExchangeMod> |
|
|
GFFC |
0-1 |
<FareConstruction> |
|
|
DPUC |
0-1 |
<ItineraryCity> |
Note: The <ErrText> tag may be accompanied by the actual response that caused the error. In this way, the data in error is provided.
DocProdFareManipulation_10_s10
DocProdFareManipulation_10_s11
DocProdFareManipulation_10_s12
DocProdFareManipulation_10_s13
DocProdFareManipulation_10_s14