Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The primary method for setting rules is using the POSID Assignment Method cafeteria setting. There are 7 possible values for this setting:

District Assigned

NOTE: I know that this statement is made below (all too subtly) so I am repeating it in big red letters above!!! If a Customer already has a District assigned POS ID, the POS ID will not be rebuilt to coincide with the range entered as the minimum and maximum values.

  • 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.

...

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.