Products and Prices

Why FBO One for pricing?

The core business of an FBO is selling and re-selling products and services. Much of the power of FBO One comes from its sophisticated pricing module.

The pricing module for FBO One is designed to keep simple price lists simple, and to keep complex price structures organized.

  • Straightforward
  • Mature, operational at over 120 FBO locations on all continents
  • Easy to manage, by breaking up complex prices into smaller components
  • Promotes reuse of price components, between similar contracts and similar products
  • Easy to support, test and analyze
  • Powerful out of the box, supporting all the aviation industry specifics
  • Previous pricing is kept, and planned price changes can take effect at a future date
  • Extensible using plug-in calculators

Orders in FBO One

Orders in FBO One are structured as follows:

├─ References the FBO location that controls the handling
├─ References the handling station (airport) where the ground handling takes place
├─ References the aircraft registration
├─ References the aircraft operator
├─ References the trip support organization
├─ Has bulletin board notes
├─ Has parking history records (on-blocks / off-blocks times with reference to parking position)
├─ Has Inbound and outbound flight leg information. These describe arrival and departure times, origin and destination, etc.
│  └─ Has passenger/crew name records
└─ Has Orders
    ├─ References a debtor for the amount due
    ├─ References a form of payment for the amount due
    │  └─ References a currency
    ├─ References its current workflow status
    ├─ Has payments
    │  └─ References a form of payment for the paid amount
    │     └─ References a currency
    └─ Has Order lines
       ├─ References a local product
       │  └─ Has a list of price agreements
       ├─ References a workflow status
       └─ References its parent order line
├─ References one or more orders
├─ References a debtor
└─ References a form of payment for the amount due
   └─ References a currency


A Handling is created for tracking all information with regards to an arrival and a subsequent departure. Simplifications can be made by using a tailored workflow. Virtually all information in a handling is optional. For example, for an over the counter sale of a simple product such as a can of oil, a handling is still created, but it would not contain any of the references. It would also follow a simple OTC order workflow that does not prompt the user for any flight-related information.

Handling orders can be thought of as projects, in this case for the purpose of arriving, parking and departing an aircraft. 


Each handling has one or more Orders. An order contains all items to be paid for by a distinct customer. In many cases, a handling has just a single order. Separate orders may be needed in case items need to be charged to different customer accounts. A typical example is fuel, which often is paid for by a fuel broker. The fuel is then placed on a secondary, related order while the other services, such as rented ground handling equipment remain on the first order. Other uses for secondary, related orders are:

  • Credit orders for refunding some or all services charged incorrectly on a prior order
  • Follow-up orders to charge for services that could not be included on orders that have already been paid for or that are already invoiced

Orders contain references to:

  1. The paying customer's account; the Debtor
  2. The current status in the workflow.
    Order workflows are divided in three stages: Quote → Open in Front Office Operations → Back Office Accounting. For each stage, one or more states can be defined.

    For an aircraft handling workflow for a VIP flight with a prior reservation, an example of the workflow is:
    1. Open Quote (Quote stage)
    2. Confirmed handling request (Front office)
    3. Arrived (Front office)
    4. Checkout completed  (Front office)
    5. Departed (Front office)
    6. Awaiting invoice approval (Back office)
    7. Invoiced (Back office)

    For a straightforward fuel sale to an aircraft visiting without a prior request, a simpler workflow can be set up: 
    1. Open (Front office)
    2. Checkout completed (Front office)
    3. Invoiced (Back office)

Order line

Each order has a list of order lines. These are also casually referred to as services. Order lines come in three categories: Chargeable Services, Headers, and Price Components.

Chargeable services are charges on the order for real products and services provided. 

#   Product                Unit price  Quantity   Amount
1   Ground power unit          100.00    2 hour   200.00
2   Can of Oil                  20.00    2 quarts  40.00
                                         Total:   240.00

In the example above, lines 1 and 2 are both chargeable services. They have an Amount that adds up towards the order's grand total.

Headers are for grouping services.

#   Product                              Unit price  Quantity   Amount   Type
1   In-house services                        200.00                      Header  
2   .  Ground power unit                     200.00    2 hour   200.00   Chargeable service 
3   Third party services                     200.00                      Header   
5   .  Catering by Private Catering          100.00    1 item   100.00   Chargeable service 
5   .  Ground transport by Private Drive     100.00    1 item   100.00   Chargeable service 
6   .  Disbursement fee 15%                   30.00    1 item    30.00   Price component
                                                       Total:   415.00

Headers only have a cosmetic value, using headers will not impact the order's total; the Amount column for a Header is always blank. The order lines below each header are called children of the header line. Child-lines are indented on the receipt; this creates a tree of order lines - similar to how a family tree of parents, children and grandchildren is visualized.
Note that the Unit Price column of each header shows the subtotal of its children. The subtotal of the Third party services is used as the input for calculating the Disbursement fee.

Price components 

The disbursement fee on line 6 above covers the costs for the FBO for collecting the catering and ground transport charges and for disbursing these amounts to the suppliers. In the example, the fee is 15% of all third-party services. The fee is a child of the Third Party Services header line. Because the price of the disbursement fee is dependent on the subtotal of its parent header, it is a price component. A key difference between chargeable services and price components is that chargeable services can be independently added to an order and can be moved from one order to another, while price components cannot. Price components are always created for a specific parent and are moved only together with that parent.

Price components can be used to structure complex prices by breaking the price down into simpler parts. This is commonly used to define fuel prices.

#   Product                       Unit price  Quantity   Amount   Type
1   Anti icing additive             0.03       100 usg     3.00   Chargeable service
2   JET A UPLIFT | Ticket 123344    1.660000   100 usg            Chargeable service | Group product
3   . JET A Uplift Base price       1.610000   100 usg            Price component
4   . . JET A Uplift Platts                                       Price component
5   . . . JET A Platts              0.500000   100 usg   50.00    Price component
6   . . . Contract differential     1.110000   100 usg  111.00    Price component
7   . JET A Duty tax                0.050000   100 usg    5.00    Price component
8   Hotel                         100.00       2 item   200.00    Chargeable service
9                                                Total: 369.00

The JET A UPLIFT in line 2 has a tree of price components. Because it has this breakdown, chargeable services such as the JET A UPLIFT are commonly called group-products.

Tailoring orders for different audiences

Orders in FBO One are displayed and printed differently based on the intended audience. Audiences include:

  • In-house pricing managers and billing staff. This audience gets to see the 'Expanded Receipt'. They are presented with all price components.
  • Captains and pilots are presented with a receipt for onsite order sign-off and payment processing.  The audience name for this is 'Receipt'. Depending on the product definition, for this audience, trees of price components can be collapsed into a single line. Collapsing group-products into a single line is also called collapsing a tree.
    If certain services on the final invoice will be paid by a third-party broker, the receipt will hide the unit price and amount for those services and print 'Contract' instead.
  • Front office customer service representatives. These users will see the 'Receipt' - but viewing the receipt is allowed only if the user has the 'view pricing' permission. This prevents that unauthorized staff can discover price agreements while viewing orders.
  • Clients that receive an invoice. Invoices cover one or more orders for payment on-account. The invoice is generated in the back office. On the invoice, the lines are displayed in in the same way as on the order's receipt. Any lines not intended for the invoice's debtor will not be included on the invoice, but have been moved to a related order which is invoiced separately to the broker.
  • Invoices issued to third party brokers paying for fuel or other services, at a contracted price. On the broker's invoice, the broker's contract prices and payable amount are shown.
  • Processors of electronic payments receive an electronic receipt; this is called the Online Payment audience. It contains the same information as the regular Receipt that is presented to the captain. If needed, FBO One can map (rename) an in-house product name to a product name required by the payment processor. Payment processors often require the use of a restricted set of product names, in order for them to be able to present detailed and categorized purchase reports to their card holders. Contract prices are excluded from the online payment, only the quantities are specified. The contract prices are maintained by the contract-client and they will pay the FBO based on what they assume their contracted rate is. In FBO One, the contract price is also maintained, and it is used to generate a broker-invoice in the back office. This invoice can be used to validate and reconcile the wire-transfer payment, once it is received. 

Master data - Products and Price Agreements

The handlings and orders in FBO One are generated day to day; they represent the business transactions taking place at the FBO.

In order ensure that creating orders is simple, FBO One is setup with so-called master data. The master data is an umbrella-term for all entities and records that don't change on a daily basis, and that provide the structure for the various types of handlings, orders and order lines. For understanding pricing in FBO One, the following master data types are most relevant.

Product (A product or service definition)
├─ References a unit of measure
└─ Has local products (An activation of the product for a specific FBO location)
    ├─ Has Child product assignments (links a child product to one or more parents)
    └─ Has Price agreements, which define the applicable unit price
       └─ References a currency and unit of measure, and filter criteria such as customer account and aircraft size
Auto-Add Product (Provides the default charges for an order type)
└─ References: FBO location, order workflow, Local product

Product and local product

Each order line always references exactly one local product. Examples of products are JET A UPLIFT, HANDLING FEE, and DISCOUNT. Products are uniquely identified by their product code, which is usually spelled in capital case and kept brief. The product code is displayed on-screen and is used in the Add Service selection box. Products also have a description, which is displayed on the receipt as the order line Product text. By having both an internally facing code and an externally facing description, scenarios can be supported where different products can be selected by in-house staff, while the client only sees a single description. For example, two products can be setup for a ground power unit, GPU IN-HOUSE and GPU BY THIRD PARTY. Each may have a different ledger or workflow. On the receipt, they can both be simply described as 'Ground power unit'.

Products have properties and settings, which define the type, unit of measure, appearance, grouping and unit price of the product.

Products can be shared between multiple FBO locations, as long as these locations are part of the same back-office administration. In order to activate a product for a specific FBO location, a local product must be created. This assigns the product to the location. The local product also has a properties and settings, allowing it to be customized on a per-location basis. Examples of these localizable properties are the accounting ledger code and the description displayed on the receipt. The decision to create independent products for each location or to use a single product that is re-used between locations is not always an easy judgement. When locations are in close proximity and managed by closely cooperating teams, keeping the number of products small can be beneficial and can help keep all FBOs following the same structure. When there is less coordination between the FBOs it is usually best to keep the products completely separate. Any changes made in the interest of one of the FBOs will have a lower risk of interfering with the other FBOs accidentally.

Auto-adding products

For each type of order, products can be added by default. This is defined by the list of auto-add products. Typical products that are present on the auto-add list are Parking charges, Jet A uplift and Avgas uplift. Each auto-add product has a set of filter criteria that determine when it is applicable. For example, an auto-add product for a Jet A uplift will usually have a filter value set for the aircraft fuel type to be jet fuel. Auto-add products are re-evaluated each time an order is updated. This means that over time, order lines may be automatically removed, and new ones may be added. For example, when the aircraft registration reference of a handling is edited, and changes from an aircraft that needs jet fuel to one that requires Avgas, the Jet A uplift service will be removed and the Avgas service is added.

For group products - such as a fuel uplift with a tree of price components - each child product assignment can be flagged as auto-add. This allows for automatically adding price components when inserting the group product on a new order.

When a product is a child of a header product, the header line will automatically be added to the order when the order contains any of its child products. If the header has price components, such as the third-party disbursement fee in the example above, these will be auto-added and auto-removed along with their parent.


Orders are recalculated on every change. During recalculation prices are applied to each order line and the quantity may be updated. For example, the number of hours parked for a Parking charges service will be updated based on the most actual on- and off-blocks times, and the price will be looked up based on the parking category used, such as outside parking or hangar.

All lines on the order are recalculated in turn:

  1. Refresh the applicable auto-add services
  2. Refresh placement of any fuel-additive lines
    1. Additives to fuel (Prist) may need to be moved from their current order to a related order; it is not always allowed to charge Prist together with fuel. This is specified in the contract of the debtor. 
  3. Group all order lines by the product's assigned priority.
    1. Usually, all products have the same priority value 0. For calculating surcharges to the overall order, such as a credit card fee, it is useful to have the fee assigned a higher priority. This ensures that the credit card fee is calculated after the regular charges, and therefore the fee can be based on the amounts of the services calculated before it.
  4. For each group, go over each of the order line trees
    1. For each order line in the tree, calculate the unit price, quantity and amount
      1. First calculate the order lines that have a price that is independent of the subtotal of their parent
      2. Then calculate line lines that are relative to the subtotal of its parent - a line that reflects a 15% discount for example.

Recalculating each line involves:

  1. Calculate the quantity
    1. The default quantity for an auto-add product is specified in in the auto-add product list. For manually added products, the user has to enter the quantity when adding the product to an order. The quantity can be automatically calculated by assigning a calculator to the product. There are calculators for calculating the duration of parking, duration of equipment used, credit card fees, and aircraft weight related fees.
  2. Calculate the unit price
    1. When a product has no applicable price agreements, the unit price on the order line will remain blank. This is fine for headers, group products, and products marked as IsTaskWithoutPrice. For other products, the unit price column will display 'To follow' and the user will need to specify the price manually. In the product, a formula can be specified to override the unit price based on the applicable price agreement and properties of the aircraft.
  3. Calculate the amount
    1. The amount is always equal to quantity * unit price
  4. In case value added tax (VAT) applies, lookup the applicable VAT rate and calculate the VAT amount

For each of the above steps, FBO One provides default behavior. 

Price agreements

Unit prices in FBO One are defined for each local product. The common name for these unit price specifications is price agreement.

Introduction by example: handling with a discount

Suppose we create orders with a handling fee, and the handling fee can have a discount that needs to be presented as a child of the Handling fee line. For this setup, we create the Handling fee and Discount products, and set up the discount to be an automatically added child product of the Handling fee. Before price agreements are defined, the receipt will show like this:

#   Product          Unit price  Quantity   Amount
1   Handling fee      To follow  1 item     0.00
2   . Discount        To follow  1 item     0.00

To create a default price of $200 for the handling fee, we create a price agreement as follows:

#  Product        Unit price
1  Handling fee       200.00

To set a default discount of 10%, we create a price agreement that specifies the percentage and that specifies that it applies only where the Discount is used as child of the Handling fee product. This allows us add the discount as a child to another product later on, and to be able to specify a different price or percentage there.

#  Product        Child product    Percentage
1  Handling fee   Discount         -10  

The overall list of price agreements will therefore be as follows:

#  Product        Child product    Unit price   Percentage
1  Handling fee                        200.00
2  Handling fee   Discount                      -10  

Based on the above price agreements, the order will recalculate as follows:

#   Product           Unit price  Quantity   Amount
1   Handling fee          200.00    1 item   200.00
2   . Discount 10%        -20.00    1 item   -20.00
3                                   Total:   180.00

Unit price lookup

To find the applicable unit price for an order line, the order calculator looks through the list of price agreements in the following sequence.

  1. Sort the price agreements. The most specific price agreements are on top of the list. This sort order is also applied when displaying price agreements, in a Product page or in the Administration | Price Agreements page. 
    1. Price agreements have filter criteria that determine when they are valid. Filter properties include for example the debtor, aircraft registration, origin and destination of the aircraft, and the order line quantity. The more specific the filters for a price agreement, the higher it will be in the list.
  2. Look for a unit price. Starting from the top of list, the first price agreement is taken that has a unit price and that matches all filter properties.
  3. Look for a percentage. Again, starting from the top of list, the first matching price agreement is taken.
  4. If only a unit price is found, then that will be the resulting unit price. This is the case for the Handling fee line in the example above.
  5. If only a percentage is found, it will be multiplied by the Amount calculated for the parent order line. This how the Discount line in the example is calculated.
  6. If both a unit price and a percentage are found, they will be multiplied and returned as the resulting unit price. This allows for setting surcharges or discounts expressed as a percentage over the standard rate, without having to create a separate product and child order line.