Home > System Administration > Overnight Processing > Concepts > Getting Item Data To The POS

Getting Item Data To The POS

There are several ways to get the item data to the POS.

Item Reload

An item reload is the easiest method of getting item data to the POS. When you do a reload, the POS will get all the data required for the POS to run correctly (including items, operators, discounts, and so on). A reload can be done manually from the Supervisor menu in POS or it can be initiated at the back office using the Till Control function. The Till Control function can also be automated to issue a reload as part of the end of day processing. The advantage to this process is that it gets all required information at the same time so you know you have up to date information. The disadvantage is that this can take some time if you have lots of items. If only some items have changed it can be wasteful.

Tickets

If your stores need to print tickets for price changes, you would include the Generate Tickets process as part of the end of day schedule. This will generate a batch of tickets for the items that have changed. The store would use the Print Tickets function to print the tickets. Once the tickets have been hung, the user comes back to Print Tickets, finds the ticket batch and presses the Send To POS button. The system will generate a request for each item in the ticket batch to be sent to POS.

The advantage with this approach is that you only send down the items that have actually changed. The disadvantage is that sending down individual items is less efficient than sending all items in a reload. However, if the number of items is reasonable small, this will still be a more effective approach than doing a full reload. The other disadvantage is that you don't know for sure when the change actually gets to POS (although it is possible to write an alert that would indicate problems).

Trickle Feed Items

If your stores do not print tickets, you can include the Trickle Feed Items process as part of the end of day schedule. This works in a similar manner to the tickets process, in that it will look for any item changes since the last time the process was run. The system will generate a request for any changed item to be sent to the POS.

The advantage with this approach is that you only send down the items that have actually changed. The disadvantage is that sending down individual items is less efficient than sending all items in a reload. However, if the number of items is reasonable small, this will still be a more effective approach than doing a full reload. The other disadvantage is that you don't know for sure when the change actually gets to POS (although it is possible to write an alert that would indicate problems).

Converted from CHM to HTML with chm2web Pro 2.85 (unicode)