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 so that this record will be continuously re-evaluated for possible POSID assigment everytime the build process runs until a valid POSID is found.
The primary method for setting rules is using the POSID Assignment Method cafeteria setting. There are 7 possible values for this setting:
District Assigned
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 posid. 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 POSID nor the legacy POSID values are valid or available, the system will assign the first available POSID in the defined range.
Grade-Range
- Grade-range POSID assignment uses the per-grade ranges defined in cafeteria setup in the POSID / Grade Ranges tab. If the customer's current grade is not in the list, then the cafeteria's POSID Assignment Range minimums and maximum range will be used
Student Number
- If a customer has a numeric student number, then that value will be the only legal value for POSID assignment. If the student number is blank or contains letters or punctuation, then the cafeteria's POSID Assignment Range minimums and maximum range will be used
SIS Data
- This works just like the Student Number method except that the SIS Data value is used rather than the Student Number value.
Legacy System
- Each cafeteria-specific POS CUSTOMER has a corresponding central office CUSTOMER record. A CUSTOMER record may have a legacy POSID value associated with it (from running an import 3rd party or convert legacy from WinFSCM). If a legacy POSID exists, then that value will be the only legal value for POSID assignment. If no legacy POSID exists for the CUSTOMER record, then the cafeteria's POSID Assignment Range minimums and maximum range will be used
Random
- The cafeteria's POSID Assignment Range minimums and maximum range will be used
Last Part of Student Number
- This works just like Student Number and SIS Data methods, except that only the last part of the student number is used. The cafeteria setting Last Part of Student Number for POSIDs determines how many characters are used. If you set this to 5, for example, then the last 5 characters of the student number will be checked. If it is a valid number, then that value will be the only legal value for POSID assignment. If the student number is blank or contains letters or punctuation in the last part, then the cafeteria's POSID Assignment Range minimum and maximum range will be used.
When editing a POS Customer record, you can manually set the POSID for only if the value you are manually setting falls within the valid range defined by the rules outlined above.
Whenever a range of POSIDs is allowed based on the above rules, and a district-assigned POSID exists on a given POS Customer (e.g. the customer exists at another cafeteria that is set to district-assigned), then that value will be used if it falls within the valid range and is not already in use. If it is invalid or in use, the first available value in the range will be used. Similarly, if a legacy POSID exists for the customer, that value will be preferred if it is valid for the range and not in use, even if the method is not set to legacy system.
It is important to note that when assigning POSIDs, situations can be encountered wherein one pos customer has a specific POSID that it needs while another pos customer does not have a specific need but has the POSID currently assigned to it that the first pos customer requires. Consider the following example:
- The cafeteria is set to use Legacy System as the assignment method.
- John has a legacy POSID of 123
- Mary does not have a legacy POSID
- The cafeteria's POSID Assignment Range is 1 to 1000
- The build POS customer process needs a POSID to assign to Mary. Since she doesn't have a legacy POSID, it randomly assigns one in the 1 to 1000 range.
- Suppose it picks 12,
- The build POS customer process now needs to assign a POSID to John. Based on the rules, the only valid number is 123, but it is in use by Mary. Since a valid POSID cannot be assigned, he is given a dummy (large negative number) POS ID
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 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 posids) 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.