Test Mode
Test mode lets you push bookings through the whole import flow even when the underlying setup is incomplete. Instead of stopping with an error, the system substitutes fallback values so that an order is still created.
Test mode does not create test documents and does not block posting. The orders it produces are ordinary sales orders that can be posted and invoiced like any other. The risk is not that nothing happens -- it is that an order looks perfectly valid while carrying the wrong item, the wrong customer, or the wrong salesperson.
When Test Mode Is Useful
The typical use is importing AIR files that do not belong to your own business -- for example a file borrowed from another agency or market to try something out. Such a file almost always fails on the first hurdle: its customer or salesperson does not exist in your company. Test mode substitutes the fallback customer and salesperson so the file gets all the way through, and you can look at the result.
When you test this way, read the warnings in the AIR Import Log rather than just checking that an order was created. Each fallback leaves its own warning, and they mean different things:
- Customer or salesperson fallback -- expected. The file belongs to another business, so of course they are missing.
- Item mapping fallback -- worth a closer look. If the booking's product type, region, and service type combination is one your own business also uses, this warning is telling you a mapping row is missing in your configuration.
What test mode is not for is verifying a finished configuration -- the same fallbacks that let a foreign file through also mask real gaps in your own setup. Verify with test mode off.
What Changes in Test Mode
| Situation | Normal behaviour | With test mode on |
|---|---|---|
| No item mapping found for the booking | Import fails with an error | The fallback booking item and fallback service fee item are used, and a warning is logged |
| The customer from the booking does not exist | Import fails with an error | The fallback customer is used, and a warning is logged |
| The salesperson from the booking does not exist | Import fails with an error | The fallback salesperson is used, and a warning is logged |
| The service fee item has no price for the customer | Import fails with an error | The line is created with a zero amount, and a warning is logged |
Every import summary shows Test Mode: ENABLED when test mode was on during processing, and each entry in the AIR Import Log records whether test mode was active. That is how you tell afterwards which orders were created with fallbacks.
Before You Switch It On
Test mode relies on four fallback records, all on the AIR Setup page under Default Test Items. None of them may be left blank, so fill them in first:
| Field | Used when |
|---|---|
| Test Mode Booking Item | No item mapping is found for the travel line |
| Test Mode Service Item | No item mapping is found for the service fee line |
| Test Mode Default Customer | The customer in the booking cannot be resolved |
| Test Mode Default Salesperson | The salesperson in the booking cannot be resolved |
Enabling Test Mode
- Search for AIR Setup.
- Make sure the four fallback fields are filled in.
- Switch Test Mode Enabled on. You are asked to confirm, because the setting bypasses validations that normally protect your data. Answer no to cancel.
- Choose Validate Setup to confirm the fallback items and customer exist and are not blocked, and that the fallback salesperson exists.
To switch test mode off again, simply clear the toggle.
Important Warning
Do not leave test mode enabled in a production environment. Orders created while it is on may reference the fallback item, customer, or salesperson rather than the real ones, and nothing stops them from being posted. Always confirm test mode is off before processing real bookings, and review any order created during a test period before invoicing it.