Arrival Export Logic Explained
The Export that is generated by Arrival and used by CRM systems to prompt customers that they have a pre-arrival task to complete in Arrival went through deep-dive analysis and testing due to several reports of exported customers not aligning 100% with expectations of who should be contacted. The result of the export revisions ensures:
Canceled order items are always omitted from the report.
Ensures sale location codes defined in Arrival administration are used to filter results.
Ensures customers needing waivers relies fully on authentication type codes defined for the Location in Arrival Admin.
Detailed Logic Explanation
The Arrival export functionality is used to export information about guests that have tasks to complete in Arrival. It can be used to generate emails to those guests to notify them of the actions that they have to complete.
The export is generated in 2 steps:
Initial processing: An overnight process initially prepares the data and stores it in the Arrival database.
Export API or Report: When the API is called or the report is run, that pulls the data from the Arrival database table and can apply further filtering on the data.
Authorizations/Waivers Logic
Check for guests who have prepaid access, a transaction, or an open order line that requires an authorization as follows:
Includes open prepaid access where there is a component (either the access or another component on the same header) that requires a waiver. Product/transaction date does not matter.
Includes transactions that were not part of the above prepaid access query where a component on the header requires an authorization. Product date must be yesterday or up to 5 months in the future.
Includes open order lines where a component on the header requires an authorization. Product date must be yesterday or up to 5 months in the future.
Other details:
The transaction or order header sale location must be as define on the Arrival location in Arrival admin either by Resort (Business Unit) or Sale Location.
When the export report or API is run (step 2 as described above), only Authorization Profile Types as define for that Arrival location are returned.
The Authorization configuration on the product component, including Validation Date, is used to determine if the guest needs to complete a new authorization.
The Product Date returns in the export is set to NULL if the prepaid access expiration type is DATE or if it is DAYS and the days are >31. This is meant to distinguish a season pass.
We are adding a configurable date that will filter to only transactions back to that date. This is not implemented yet.
Rental Logic
The product component must have Rental Profile Required Rule. Main Queries as follows:
Transaction lines where the product date is today or greater and rental profile required component.
Can’t be returned.
Open order lines where product date is today or greater and rental profile required component.
Extra notes:
Transaction or order header sale location must be from Arrival admin as descried above.
Checks active rental profile (there can only be one).
Right now, the export does NOT filter based on the Effective Days in Arrival Admin. When you log into arrival to complete a task, it does indeed filter by those and considers a profile with an update date prior to the Expiration Days as not being satisfactory.
Child Registration Logic
This logic is the same as that used for rental. The product component must have Child Registration Profile Required Rule. Main Queries include:
Transaction lines where the product date is today or greater and child reg required component.
Can’t be returned.
Open order lines where product date is today or greater and child reg required component.
Extra notes:
Transaction or order header sale location must be from Arrival admin as descried above.
Checks active child reg profile (there can only be one).
Right now, the export does NOT filter based on the Effective Days in Arrival Admin. When you log into arrival to complete a task, it does indeed filter by those and considers a profile with an update date prior to the Expiration Days as not being satisfactory.
Photos Logic
Product rules include ‘Image Required’ Indicator on pass media component or “IMAGEREQUIRED” component rule used to trigger photo behavior. Must have active, unprinted pass media for photos to work (not from the same transaction, they just must have it).
Check for guests who have prepaid access, a transaction, or an open order line that requires a photo as follows:
Includes open prepaid access where there is a component that requires a photo.
Product/transaction date does not matter for prepaid access, just must be open and expire today or in the future.
Includes transactions that were not part of the above prepaid access query where a component on the header requires a photo. For non-prepaid access, product date must be yesterday or up to 5 months in the future.
Includes open order lines where a component on the header requires a photo. Product date must be yesterday or up to 5 months in the future.
Extra notes:
Transaction or order header sale location must be from Arrival admin as descried above.
Also checks to see if items is printable, looks for SKIDATEPRINTONPUB or AXESSPRINTONPUB rules.
NOTE: Potentially a proc update could remove the unprinted requirement but a request to your Aspenware representative would need to be submitted.