POS ID (or POS number) assignment in Newton works by using sets of rules. Whenever POS customers are built (when a cafeteria is selected or connected, or a system admin performs a housekeeping), each POS customer is checked to see if his or her current POSID is valid for the current rules. If it is not valid, then a new POSID that does comply with the rules is assigned. If there are no POSIDs available based on the rules, then a dummy POSID (a very large negative number) will be assigned. The dummy POSID will not be valid for the ruleset rule set so that this record will be continuously re-evaluated for possible POSID assigment everytime assignment every time the build process runs until a valid POSID is found.
...
This method uses a district-wide unique POS number. Each cafeteria-specific POS CUSTOMER has a corresponding central office CUSTOMER record. A CUSTOMER record may have a district-assigned POSID associated with it. If so, the District Assigned method will use the already associated District POSID. If it does not have a District POSID assigned, one will be assigned by the build POS CUSTOMER process which will be then be used by this and all future builds.
Assignment of district POSIDs is range based. The range is defined by the global settings District-Assigned POSID Range configured in System Setup. The system will try to find the POS CUSTOMER's currently assigned cafeteria-specific POSID if one exists. If that value is within the District- Assigned POSID Range, and it is not already assigned to another CUSTOMER record in the district, that value will be used as the district-assigned posidPOSID. If not, and a legacy POSID value exists for the customer record, it will be checked if it is valid for the range and not in use, and use it if possible. If neither the currently assigned cafeteria-specifc specific POSID nor the legacy POSID values are valid or available, the system will assign the first available POSID in the defined range.
...
It is important to note that when assigning POSIDs, situations can be encountered wherein one pos POS customer has a specific POSID that it needs while another pos POS customer does not have a specific need but has the POSID currently assigned to it that the first pos POS customer requires. Consider the following example:
...
To prevent this scenario, it would be best to set the POSID Assignment Range for the cafeteria to something outside of the values from the legacy system (1000000 to 2000000 for example) while the method is still set to Legacy System and then rebuild the pos POS customers. Since Mary does not have a legacy POSID, she would require a value of 1000000 to 2000000 and her current value of 123 would be invalid and she would get reassigned. John however, has a legacy POSID of 123, which would now become available and he would be assigned that number. After the build POS customer process is complete, then the rules could be changed back to Random with the POSID Assignment Range set to 1 to 1000. Now when the build is performed, Mary's 1000000+ number would be too high and she would be assigned a POSID in the range of 1 to 1000. Since 123 is now taken by John (and all the customers with legacy values already have their legacy posidsPOSIDs) Mary will be assigned something that doesn't conflict with the legacy system. Even though the method is no longer set to Legacy System, John's POSID of 123 is already valid for the 1 to 1000 range, so it will not be changed. Any new student added to the cafeteria later will, like Mary, be assigned a new POSID between 1 and 1000 that does not conflict with the legacy system's POSIDs.
...