Rollup Example

A example scenario can illustrate how rollup transactions can be created given common rollup settings.

The transactions in this example are simplified to illustrate the rollup logic. Real-world transactions contain more fields, and rollup transactions will typically summarize dozens – if not hundreds – of individual register transactions.

a) Example Settings

Assume the following settings:

• Filters: Marketing Customers
• Group By: no options selected (use default grouping of payment method, store and tax schedule)
• Limit: Transaction Age of 1 day

b) Example Register Transactions

Transaction # 100

Transaction # 101

Transaction # 200

Transaction # 103

Transaction # 104

Transaction # 105

c) ASI Transactions

From the above examples, the rollup task ignores Transaction 103 because it was created for an accounting customer. The Fusion ASI will process the transaction instead, and send it directly to the ERP.

d) Resulting Rollup Transactions

In total, the rollup task will create three rollup transactions from the example source transactions that are defined above.

Rollup # 1

This rollup transaction can summarize multiple transactions because the group by criteria are the same (e.g. payment method and store) and the time period limit is the same.

Note how individual line items are merged. In our example, the distinct combination of SKU, lot number and UOM each require their own line item.

While the source transaction #200 falls on the same time period (limit) as the other transactions, a separate rollup must be created because of the following group by criteria are different for this transaction:

• Payment method is different
• Store is different