What's the difference between 'Customer' and 'POS Customer' records?

Newton has both 'Customer' records and 'POS Customer' records. A 'Customer' record represents an individual person, usually a student attached to a WinFSFR, but it can also be a teacher or other adult faculty member added directly to Newton. A 'POS Customer' is a customer's account record at a given cafeteria. A student who has eaten at multiple cafeterias over the course of a school year will have a single 'Customer' record and multiple 'POS Customer' records. Customer records contain the demographic information (name, address, student number, dob, etc), balance, status, and other information that is common to all cafeterias about a given customer. The 'POS Customer' record contains information that is specific only to a given cafeteria, such as the POSID, charging limits, and effective price category (price category is computed from the customer's status using the rules for each cafeteria)

What is meant by 'Building POS Customers' and when should it be performed?

The information in the POS Customer record needs to be recomputed whenever certain changes to the Customer record or configuration settings of the cafeteria are made. The system keeps track of which POS customer records may be affected by certain changes and will automatically update those records the next time the build process is performed. The build process will also add new POS customer records as needed.

The main purpose of the build process is to maintain the POSID and Price Category fields in the POS Customer record. When a POS Customer record is built, the current POS ID is checked against the rules assigned to the cafeteria. If it is valid for the rules, it will not be changed. If it is not valid for the current rules, it will be assigned a new POS ID that is valid for the rules. If a valid POS ID cannot be found (e.g. all available POS IDs in the valid range are in use by other POS Customers), then a special 'dummy' POSID will be assigned as a very large negative number. This POS Customer record will be marked as needing rebuilding until a valid POSID is eventually found.

There are two types of build-- full and quick. Full mode checks every POS customer in a cafeteria to see if it is up-to-date. The quick build checks only those POS customer records that are flagged as needing to be checked. A quick build is performed automatically every time a cafeteria performs a quick synchronization, which includes logging in to Newton and anytime a meal is started. A full build is performed automatically every time a cafeteria performs a full synchronization.

Generally speaking, you should never have to worry about building POS customers. The system will do it automatically. There are, however, certain times that you may want to perform a build on POS customers without waiting for the automatic rebuilds to occur. This is generally when you in the central office and need to get POS customer records up-to-date without waiting for the cafeteria to log in or start a meal. If you are performing exports of POS customer data, it would be a good idea to rebuild POS customer for all cafeterias before running the export.

What is the difference between the 'Rebuild POS Customers' utility and the 'Housekeeping' utility?

The 'Rebuild POS Customers' utility will allow you to rebuild POS customers for the currently selected cafeteria. The 'Housekeeping' utility will rebuild POS customers for all cafeterias. You can choose whether to perform a full or quick rebuild when you perform housekeeping. Housekeeping will also check for other problems and repair them if detected.

What is Local DB Synchronization and when should I do it?

Local database synchronization is the process of updating a database on the local storage (hard drive) of the main cafeteria workstation from the information stored in SQL Server database in the central office. This local database is used for working offline as well as for storage for all unposted transactions. Whenever you perform a Local DB Synchronization for a cafeteria, POS Customer records for that cafeteria are built first before the synchronization is performed. There are two modes of local DB synchronization-- quick and full. Quick mode will add, update, and delete only records that appear to have been changed since the last synchronization. The full mode will update every record. A full synchronization should never be necessary, unless there was a problem that caused the cafeteria workstation to somehow get out of sync with the central office SQL server database. Every time you select a cafeteria, a quick synchronization is performed. The first time you select a cafeteria from a given workstation, a full synchronization will be performed instead of a quick synchronization, in order to create the initial database. A quick synchronization is also performed automatically every time a meal is started.

Generally speaking, you should never have to worry about performing a local DB synchronization. The system will do it automatically. There are situations however where it may be convenient to perform a synchronization without having to start a meal or quick Newton and log back in. If a student has been updated in the Free & Reduced system during the day and a cafeteria manager would like to receive those updates immediately instead of waiting until the next meal is started, he or she could perform a local DB synchronization. Also, a technician may want to perform a local db synchronization when checking on POS ID assignment changes, legacy imports, etc. A local DB sync is sometimes more convenient than switching to the utilities menu to run a rebuild POS customers operation; and, since the local db synchronization performs a POS customer rebuild, it is useful as a shortcut in this way.

MCS

Browser not supported