Usually when POS needs data files it will connect to Merchant Central Server and download the required information. If you have lots of POS or lots of items, this can have a real impact on the system, especially if the reloads are all done at the same time.
The idea of prepared POS reloads is to help alleviate this impact and give you more control over when the data for POS is extracted.
The concept is as follows:
You set up a POS Data directory in System Settings. This is the root directory where the POS data will be stored.
Run an EOD job to tell the system to prepare the POS data for a given location (group/store). This will result in the preparation of the datafiles which will be stored in the POS Data directory. The system will create a subdirectory for each till. If you have multiple POS at one location the process is smart enough to consolidate the queries. So for data that is location specific (rather than POS specific), such as items and discounts, the system will only run the query once for the location, instead of once for each POS. This can result in significant savings by itself.
Using Till Control you issue a command to tell the POS that a Prepared Reload is available. This is similar to sending a command to tell the system to do a Full Reload or a Config Reload.
When the POS gets the reload command it will contact Merchant Central Server to request the download. The server will simply send down the data that has already been provided.
There are some checks the system will do when POS requests a Prepared Reload to ensure the data is valid.
When the POS asks for the prepared data, the system will check the age of the data file. If it older than a certain period of time, the system will do a full reload. This prevents the POS from getting data that could be considered too old. The allowed period of time is defined in the Max Age Of Prepared Data (Hrs) option in System Settings.
The system will do a check to ensure the data is for the required version. When the prepared data is actually created, the system will check the expected file version of the system (by checking the FILEVERSIONS table). This is recorded along with the actual data. When POS asks for the data, the system will check the version of the POS compared to the expected version recorded with the data. If the two are different, a full reload is done. The implication here is that you must update the file versions (see Upgrading Client Programs for more details).
When it receives a command from Till Control telling it to do a Prepared Reload.
When the file version of POS has changed. When a new version of POS is started, the system has always done a reload and will continue to do so. However, now it will request a prepared reload. This means you can use a set of files already prepared at head office.
Because of the file version checks, you can prepare POS data for the new version of POS and avoid the full reloads normally associated with a version upgrade.
Install the new programs at head office.
Update the File Versions.
Run Prepare POS Data to generate the POS data for the new version number.
Client starts POS. It detects that a new version is available and starts new version.
When new version is started it will do a Prepared Reload (simply because of the version number change).
Since the data generated by the Prepare POS Data is for the new version number, POS will simply download the prepared data and start working with it.
Converted from CHM to HTML with chm2web Pro 2.85 (unicode) |