Implementing On-Demand Customer and Items Strategies and Optimizations
STOP
On-Demand Customer and Items should not be considered if your customer or item syncs happen at an acceptable speed; generally when there are less than 20,000 items and 40,000 customers.
On-Demand Customers
On-Demand Customers should only be implemented if your sync performances are not acceptable or if you are not tracking customers because of your sync performance. How you implement On-Demand Customers will depend on your desired goals, your retail mix of customers and priorities in terms of initial customer access.
Case 1. Retailer only uses the "Anonymous" customer for most transactions.
It is unlikely that this type of retailer will have a lot of customer records. As such, On-Demand Customers SHOULD NOT be considered.
Case 2: Retailer with many (or one) store(s) and an emphasis on tracking customers.
A Default Customer Saved Search could be used (versus a POS Settings Saved Customers Search) and that search should contain the "Anonymous Customers" for every store. If speed of syncs is important you can set up a POS Settings Saved Search that only pulls in the specific Anonymous Customers. By definition, this will mean that all customers are on-demand.
The Hybrid Approach
In some cases, a higher availability of customers may be required. In these instances, a hybrid approach would be to pull into the Default Active Saved Search only customers that have (say) purchased in the last year. Alternatively, if your customer base is centered around specific stores, you could set up a POS Settings Saved Search that pulls in such customers and confine them to a specific store. This will leave your most popular customers available locally and if they are not found, the customer can be pulled on-demand.
On-Demand Items
On-Demand Items should only be implemented if your sync performances are not acceptable or if you are using Quantity-Based Pricing (which can result in high effective item counts). How you implement On-Demand Items will depend on your desired goals, your retail mix of items and priorities in terms of initial item access.
Barcoding
For on-demand items to work effectively; it is best that all your items are bar coded.
Quantity-based Pricing
Quantity-based pricing requires not only the item record to be retrieved but also the quantity break levels and price level matrix (to get the correct pricing). So, for example if you have 4 price levels and 3 quantity breaks essentially 12 items records have to be retrieved on the first scan. This may take a bit longer than you would like; but subsequent scans will not have to do that.
Case 1. Retailer has less than 20,000 items.
On-Demand Items SHOULD NOT be considered.
Case 2. Retailer has a lot of items (available in most stores) and syncs are slow.
A Default Saved Items Search could be used (versus a POS Settings Saved Search) and that search should only contain items that are required in the POS Settings record; namely the Tip, Surcharge and Always Available On Return Items. By definition, all Items are On-Demand.
The Hybrid Approach
Where speed is the utmost priority, it may be prudent to fine tune either the Default Saved Item Search or the POS Settings Saved Search (store specific) to only pull in (say) items unique to a specific store, or that have been sold in the last year or are faster moving. This will result in these items being highly available, yet pull in on-demand the items that are not.
With any Hybrid approach it may be necessary to regularly perform "Forced" (from Settings or Terminal Record) or "Manual" Full Syncs in order to ensure that Items and Customers are current. In a lot of searches that uses columns (eg. inventory count), the underlaying record is not updated and therefore will not be reflective during Differential Syncs which uses "Last Modified Date"