Aggregating Guest Check Details versus Displaying Guest Check Details

The data returned from the getGuestChecks API can be used to aggregate totals or to display the original check details as they were displayed to a guest. The difference between the two use cases is within the fields that are being used to achieve each:

• dspTtl, dspQty: Represent the amounts and counts shown when displaying the check.

• aggTtl, aggQty: Represent the amounts and counts to aggregate this line.

During operations on a check, a line may be duplicated to a new position or a new check. When this occurs the "copy" of the line must be displayed on the new check, but the values contained still need to be aggregated with the original attributes. To accomplish this, the dspTtl are always moved to the new line but the aggTtl are left on the original entry so that it may aggregate with the correct time and employee information.

The following examples outline instances where this occurs but do not indicate all possible permutations of these values.

Example 1: Splitting a Check

A soda and a hot dog are rung onto a check at $5 each. This is shown in the following table.

Check Number	Item	dspQty	dspTtl	aggQty	aggTtl	dtlUTC	doNotShowFlag
1	Soda	1	5	1	5	3:00	False
1	Hot dog	1	5	1	5	3:00	False

The hot dog is then split to a different check 20 minutes later. This is shown in the following table.

Check Number	Item	dspQty	dspTtl	aggQty	aggTtl	dtlUTC	doNotShowFlag
1	Soda	1	5	1	5	3:00	False
1	Hot dog	1	5	1	5	3:00	True
2	Hot dog	1	5	0	0	3:20	False

The aggTtl stays with the original check, allowing the aggQty and aggTtl to be aggregated to the original transaction time when it was sold. This also allows association with the original check owner/transaction owner.

To indicate the dspTtl/dspQty on the original hot dog should not be displayed, the do not show flag is set to true. When the check is displayed, the first check will only show the soda and second check will only show the hot dog.

Example 2: Prorated Subtotal Discounts

A soda and a hot dog are rung onto a check at $5 each. This is shown in the following table.

Check Number	Item	dspQty	dspTtl	aggQty	aggTtl	dtlUTC	doNotShowFlag	dtlId	parDtlId
1	Soda	1	5	1	5	3:00	False	1	NULL
1	Hot dog	1	5	1	5	3:00	False	2	NULL

A $5 discount is applied to the check. It is defined as a prorated subtotal discount in the POS system. This is shown in the following table.

Check Number	Item	dspQty	dspTtl	aggQty	aggTtl	dtlUTC	doNotShowFlag	dtlId	parDtlId
1	Soda	1	5	1	5	3:00	False	1	NULL
1	Hot dog	1	5	1	5	3:00	False	2	NULL
1	Dollar off	1	-1	1	-0.5	3:10	False	3	1
1	Dollar off	1	-0.5 Foot 1	0	-0.5	3:10	True	4	2

^Footnote 1 The dspTtl for the second discount line still contains -0.5. This occurs because only the dspTtl for the first line is manipulated during transformation to show the full discount amount and the rest gets the do not show flag set.

To accommodate the display, only the first line of the discount record will be shown, and this line carries the full amount of the discount in the display total column -$1. So the check, when displayed in Reporting and Analytics, appears the same as it did on the POS: two items and one discount.

The aggregation information is broken apart for each row of proration. This is done so that the discount can be properly aggregated to the menu item it was applied to. In the example above, the first line of the discount contains -0.5 in the aggTtl field. This will be applied as the discounted amount against the item soda. The second line contains -0.5 in the aggTtl field as well since these two items had the same price. This will be applied in aggregation against menu item hot dog.

The aggQty is only populated in the first line since the discount must only be counted once. There is no direct relationship between this field and the discounts applied against menu items. Otherwise, the same discount would be counted twice.