Rollup Details

The rollup task performs a series of steps to accomplish its processing. This topic describes those steps in more technical details.

a) Detect Transactions

The rollup task must detect new, unposted source transactions in the POSXActHeader table.

This query is the same as the ASI currently does:

• Check the Status field for unposted transactions.
• Ensure SaveComplete is true.

IMPORTANT: there is a potential timing issue with how KensiumComm transfers XAct* transaction records. It appears to send POSXActHeader records before other XAct records. There is a chance that the query will pick up header records before the other records have finished transferring. This can be fixed by ensuring that KensiumComm saves transaction records after all other XAct records have been transferred.

Any new transactions are processed individually with the steps described next.

b) Filter Transaction

The rollup task should filter the source transaction to determine whether it should be included in a rollup. The service checks the transaction against the Rollup Filter settings – e.g. the customer type filter.

IMPORTANT: to avoid adding complexity to the rollup, the service will also exclude any transaction that:

• Involves an Accounting customer
• Has open (unfulfilled) items
• Has multiple payment methods (e.g. split between cash and credit card)

The service will continue to process the transaction if the filter settings match, and the transaction has not been excluded by the criteria above. Otherwise, the service updates the transaction so that the standard ASI will process it instead:

• ThePOSXActHeader table includes a new PostHandler field that records the post .
  • As the ASI will use this field, this field is added (if it is not already present) by both the POS server and the Register database migrations.
• Field values can be:
  • Unknown – it is unknown how the transaction will be posted.
  • Rollup – the transaction will be posted via a rollup.
  • Individual – the transaction will be posted individually via the ASI.
• For unmatched/excluded transactions, the service sets the field value to Individual.
• The ASI has been modified so that it only processes transactions with the Individual value set to its PostHandler field. The ASI will only perform this check if it is configured to do so – this configuration enables the ASI to continue working for legacy installations without requiring installation of POS.

c) Identify/Create Rollup

The rollup task then examines the Rollup Grouping settings to determine whether it needs to record the transaction against an existing rollup, or create a new rollup.

The service should:

• Select the grouping field values from the transaction
• Query existing, unposted rollups by their grouping fields
• If no rollup matches the group fields, create a new rollup.
• Otherwise, the matching rollup will be used handle the transaction.

The Payment Method grouping is always required, as the target ERP/Accounting system needs to know which GL accounts are associated with the transactions (and this is done at the payment method level). Similarly, the Store and Tax Schedule groupings are always required as the rollup can only use one tax schedule.

d) Apply Transaction

The rollup task then should apply the source transaction to the rollup. This is done by iterating through each line item in the transaction:

• Find the matching rollup line item, and apply the quantity, extended price and discount information of the source line item to it.
  • Matching means that the following fields match:
    • SKU
    • Serial/lot #
    • UOM
    • Unit Price
    • Warehouse (location)
    • Tax Class
  • If no match exists, create a new rollup line item.
• The rollup should maintain a table that links source transaction line items to rollup line items – the rollup should create a row to record the match.

While iterating each line item, the rollup task must check whether applying the line item would exceed the limits specified in the Rollup Limit Settings – for example, the maximum dollar amount or number of line items. If the line items would exceed the limits, the service should:

• Mark the rollup status as Pending so that it can be picked up for further processing (e.g. by the ASI).
• Create a new rollup, and continue processing line items by adding them to the new rollup.

Processing of a source transactions should be performed within a database transaction, to ensure that updates to the rollup are performed all-or-none.

e) Initiate Posting

The background task is responsible for enforcing the Transaction Age Rollup Setting. Any rollups older than the age setting – and that have a status of Building should be upgraded to a Pending status.