AIR Product Posting Setup (Table 51307)
The AIR Product Posting Setup table defines which G/L Accounts are used when posting sales orders created from AIR bookings. Each row maps a specific combination of business posting group, product type, and booking type to a set of accounts.
Receivables accounts are configured elsewhere: card customers (Credit Card Provider = FirstCard/Diners) get theirs from AIR Setup, invoice customers from their Customer Posting Group.
Page
Accessible via the AIR Product Posting Setup page (search for "AIR Product Posting Setup" in Business Central).
All setup tables have dedicated pages in Business Central. For smaller datasets or initial setup, entering data directly in the UI may be more practical than building a config package. Config packages are most useful when you have many rows to import or want a repeatable setup across environments.
Primary Key Structure
The table uses a composite primary key with 3 fields. All three are part of the lookup — see How Matching Works.
| Field ID | Field Name | Data Type | Values |
|---|---|---|---|
| 1 | Gen. Bus. Posting Group | Code[20] | References standard BC Gen. Business Posting Group |
| 2 | AIR Product Type | Enum | Other, Flight, GroundTransport, Train, Hotel, CarRental |
| 3 | AIR Booking Type | Enum | (blank), BSP, UCCCF, Ghost, Voucher, Confirmation, Standard |
Account Fields
| Field ID | Field Name | Data Type | Description |
|---|---|---|---|
| 10 | Sales Account | Code[20] | G/L Account for sales revenue. Used on every AIR booking line, and as the balancing account for markup and Confirmation netting |
| 11 | Purchase Account | Code[20] | G/L Account for purchases. Used for Confirmation netting (vendor pays) and for the UCCCF fare adjustment on Flight/UCCCF and GroundTransport/UCCCF rows |
| 12 | Markup Account | Code[20] | G/L Account for markup revenue. Only used for booking types BSP, UCCCF, Ghost, Voucher, Standard |
| 13 | Service Fee Account | Code[20] | G/L Account for service fee revenue. Read from the row matched for the parent booking line — see below |
All account fields reference the G/L Account table, filtered to Account Type = Posting and Blocked = false.
How Matching Works
The lookup is a single exact Get() on all three key fields. If no row exists with exactly that combination, posting fails with an error — the system does not fall back to a less specific row, and blank key values are not wildcards.
The error is raised during posting (Sales-Post), not during AIR import. A booking can therefore import cleanly, produce a sales order, and only fail when someone tries to post it.
The error message names the exact combination that was missing, for example:
AIR Product Posting Setup not found.
Gen. Bus. Posting Group: INRIKES
Product Type: Flight
Booking Type: BSP
Use that message to create the missing row verbatim.
Which values the system actually derives
Because the values are derived from the document, most theoretically possible key combinations can never occur — and, importantly, blank values never occur. A row with blank Booking Type will simply never be matched.
Gen. Bus. Posting Group — taken from the sales line / general posting setup being posted.
AIR Product Type — from the sales line. Note that AIR order processing currently produces Flight, Hotel, CarRental and GroundTransport lines; Train lines are not generated by the AIR import.
AIR Booking Type — derived per line, never left blank in practice:
| Product Type on the line | Resulting Booking Type |
|---|---|
| Flight, Form of Payment is a card charge (CCDC/CCCA) | UCCCF |
| Flight, import is a ghost booking or an NDC ticket | Ghost |
| Flight, all other cases | BSP |
| Hotel / CarRental, line Voucher Type = Voucher | Voucher |
| Hotel / CarRental, line Voucher Type = Confirmation | Confirmation |
GroundTransport flight taxi (Amadeus service type VTAX), card FoP (CCDC/CCCA) | UCCCF |
| GroundTransport, any other case | Standard |
GroundTransport never gets Voucher/Confirmation — that flow applies to hotel and car rental only. Only flight taxi is debited to the travel account by Amadeus; all other ground transport (bus, transfer, train segments — or taxi without card FoP) is Standard: the agency settles with the supplier and the full amount stays on the customer receivable. For card customers, that receivable goes to the card provider's receivables account like BSP flights — the card partner bills the customer and pays out the full amount.
Service fee lines
Service fee lines (and ancillary lines) carry AIR Product Type = Other. They do not get their own posting setup row. Instead the system:
- Finds the parent booking line — the last preceding line on the document with a Sequence No and a product type other than Other
- Looks up the posting setup row for that parent line's product type and booking type
- Uses the row's Service Fee Account
Consequently, Product Type = Other rows are never matched and the Service Fee Account must be filled in on the booking rows (Flight/BSP, Hotel/Voucher, and so on). If a service fee line has no preceding booking line, posting fails with "Service fee line %1 has no parent booking line".
Example Configuration
Every row below is a combination that can actually occur. Replace INRIKES with the customer's Gen. Bus. Posting Groups and repeat the block for each one that AIR lines can carry — the full matrix is typically 10 rows per posting group:
| Gen. Bus. Post. Group | Product Type | Booking Type | Sales Acc. | Purch. Acc. | Markup Acc. | Service Fee Acc. |
|---|---|---|---|---|---|---|
| INRIKES | Flight | BSP | 3010 | 3015 | 3020 | |
| INRIKES | Flight | UCCCF | 3010 | 4010 | 3015 | 3020 |
| INRIKES | Flight | Ghost | 3010 | 3015 | 3020 | |
| INRIKES | Hotel | Voucher | 3030 | 3035 | 3040 | |
| INRIKES | Hotel | Confirmation | 3030 | 4030 | 3040 | |
| INRIKES | CarRental | Voucher | 3050 | 3055 | 3060 | |
| INRIKES | CarRental | Confirmation | 3050 | 4050 | 3060 | |
| INRIKES | GroundTransport | Standard | 3070 | 3075 | 3080 | |
| INRIKES | GroundTransport | UCCCF | 3070 | 4070 | 3075 | 3080 |
| INRIKES | Train | Standard | 3070 | 3075 | 3080 |
The UCCCF rows only ever match card-paying customers (UCCCF requires card FoP), but they cost nothing to include for everyone.
Config Package Notes
- This is a multi-row table — include every row the customer's bookings can produce
- Minimum requirement: one row per complete 3-key combination that can occur — there is no catch-all row that covers the gaps
- A practical way to size it: for each Gen. Bus. Posting Group the customer's AIR lines can carry, include the product/booking type combinations from the tables above (typically 10 rows per group)
- Fill in Service Fee Account on the booking rows, not on any Other row
- Fill in Purchase Account on every Confirmation row and on every UCCCF row (Flight and GroundTransport)
- Fill in Markup Account on BSP, UCCCF, Ghost, Voucher and Standard rows
Common Pitfalls
- Missing rows fail at posting, not at import. The order is created and looks fine; the error appears when a user posts it. Test by actually posting, not only by importing.
- Blank key values are not wildcards. A row with blank Booking Type is dead data — the runtime never produces that value, so the row can never match.
- Purchase Account on UCCCF rows is mandatory (Flight and GroundTransport). The UCCCF fare adjustment calls
TestField("Purchase Account")— if it is blank, posting a UCCCF document fails. - UCCCF documents must be in local currency. The fare adjustment refuses documents with a Currency Code.
- G/L Accounts must exist, be of type Posting, and not be blocked, before importing this table.