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