Example: 12.0001.00002
Store = 12
Assigned from Business Info File, not changeable. If working with a multi-unit chain it is imperative that this number be the same as their corporate store id.
Journal ID = 1
Assigned from first Journal.dat. Starts at 1 on first day customer opens. Customer data is available for import into the onePOS above store solution after this date.
Check Number = 2
Assigned from TransNum.dat. It is normally reset to 0 during the end of day process.
If a check is partially closed, the part that is pushed to the POS Journal receives a new check number, but is also tagged with the original check number.
If this partial check is reopened, it will receive a new check number, but it is link to the original check number. The number it was reassigned to is lost. Any subsequent orders on this check will print with the original check number.
If a check or guest is transferred onto another check, the original from check number is lost. Any subsequent orders on this check will print with the new check number.
If a check is transferred to a new server or table, the check number is not affected.
Our goal is to ensure that the customer’s receipt reflects a consistent check number. While internally we might be using a different number to track the sales, we also are tracking the transaction by its original check number. In our above store solution, you will be able to query a check by its check number as printed on the customer’s receipt, no matter how many different ways it was closed or re-opened. The only time we will be unable to provide this level of functionality is when a guest or check is transferred onto to an already existing check.