Fee Application fields for Policies

This feature can be enabled in the API request by including:

"control": {
    "features": [
        "policy_fee_application"
    ]
}

Overview

This feature allows clients to extend their change and refundability UTA response with additional policy information related to penalty fees to assess penalty fees for the entire journey.

This feature allows clients to extend their change and refundability UTA response with an additional policy information to penalty fees to assess penalty fees for the entire journey. This feature will show the field called fee_application:

• Refundability policies would deliver two new nested fields containing information on how to apply the policy to the journey; whereas,
• Change policies would deliver single integer value. The data for these fields is based on the filed fare policy data in Category 31 and Category 33, however Category 16 will not support that and whenever the policy is coming from Category 16 it will default to "fee_application": 0 for Advance Change and to "application": 0 and "method": "N" for Cancellation.

This feature only provides additional details for clients to calculate the overall penalty fees for the entire journey should they decide to assess it. Below shows the information for clients to use the fee application values to assess the resulting fees.

Voluntary Changes Penalty Fees

Once change policy information is returned in the API for each fare component, including fee application details, the data in the Fee Application field will specify how to assess the change fee. For the purposes of this field, a fare component is considered changed if one or more ticketed flights and/or the ticketed price of the fare component have changed. A pricing unit is considered changed if one or more of its fare components is changed.

Advance Change values

If all fare components have the same value in the Fee Application Field, then proceed with assessing the penalty fee as described in the table above. If that is not the case, then the following processing logic applies when all fare components on the ticket do not have the same values in the Fee Application field (byte 105).

1. Is the validating carrier (reissuing carrier) the fare owner of one or more fare components on 
   the previous ticket?
   i. If yes:
      a. Determine the highest Fee Application value of all fare components on the previous ticket 
         that are owned by the validating carrier according to this hierarchy, reading from left 
         to right: 3 -> 2 -> 5 -> 4 -> 1
      b. Process all fare components on the previous itinerary as if each contained the value of 
         Fee Application (byte 105) found in Step 1.i.a.
   ii. If no:
      a. Determine the highest Fee Application (byte 105) value of all fare components on the 
         previous ticket according to this hierarchy, reading from left to right: 2-> 5 -> 4-> 1 -> 3
      b. Process all fare components on the previous itinerary as if each contained the value 
         of Fee Application (byte 105) found in Step 1.ii.a.

Advance Change example response

"advance_change": [
    {
        "assessment": "benefit",
        "description": "Change allowed for free",
        "fee": {
            "amount": 0,
            "currency": "USD"
        },
        "fee_application": 1,
        "headline": "Free",
        "id": "1"
    }
],

Voluntary Refunds Penalty Fees

Once refund policy information is returned in the API for each fare component, including fee application details, the data in the Fee Application object will specify how to assess the change fee.

Cancellation values

Application Value Processing

Application field specifies whether the penalty amount for the fare component being validated has a Fare Component ( value 1) or Pricing Unit (value 2) application. When application value is 1, the penalty amount is assessed for the fare component being validated. When the penalty amount is expressed as a percentage, the percentage is applied to the value of the fare component. When penalty amount is 100%, then the penalty is 100% of the value of the fare component. When application value is 2, processing compares all Pricing Unit penalties for fare components governed by all carriers in the pricing unit encompassing the fare component being validated on the ticket being presented for refund. The highest Pricing Unit penalty is assessed. Comparison is across carriers; only one penalty amount will be assessed for the pricing unit (each carrier’s penalty charges are not individually assessed).

• When the penalty amount is expressed as a specified amount, take the highest dollar amount on the pricing unit.
• When the penalty amount is expressed as a percentage, the percentage is applied to the total base fare for the pricing unit (total value of the pricing unit). When the penalty amount is 100%, then the penalty is 100% of the total value of the pricing unit.
• When there is a mixture of highest percentage and highest dollar amount within the pricing unit, calculate the highest percentage on the total fare for the pricing unit and compare the result to the highest specified dollar amount and then take the higher of those two figures.

When fare components within the pricing unit are a mixture of value 1 and value 2, the application is dependent upon the data in the method value (A or B).

Method Value Processing

This field specifies how to assess the penalty when there is a mixture of values in application for fare components within the pricing unit.

• Value A = Method A (Pricing Unit) - When there is a mixture of values in application field for fare components within the pricing unit, all penalties are assessed on the pricing unit, and processing applies the highest penalty. This applies when owning carriers within the pricing unit are the same carrier or different carriers.
• Value B = Method B (Higher of Fare Component and Pricing Unit) - When there is a mixture of values in application field for fare components within the pricing unit, processing applies the higher of the fare component and pricing unit penalties. This applies when owning carriers within the pricing unit are the same carrier or different carriers. If there is a mixture of method values within the pricing unit, value A takes precedence and processing will employ Calculation Option Method A.

Cancellation example response

"cancellation": [
    {
        "assessment": "benefit",
        "description": "Change allowed for free",
        "fee": {
            "amount": 0,
            "currency": "USD"
        },
        "fee_application": {
            "application": 1,
            "travel_portion": "A"
        },
        "headline": "Free",
        "id": "1"
    }
],