In the article titled "What is a POS end-of-day falling into batch upload?" we referred to the situation where the transactions on the POS do not match the transactions on the HOST when end-of-day processing is initiated as the end-of-day falling into batch upload.
When the end-of-day falls into batch upload, the POS is expected to send all successful transactions to the HOST using the 320 message. The HOST is then expected to respond to the transactions sent by the POS with the 320 message using the 330 message.
In managing this process, transactions sent from the POS device can be written directly into the cumulative tables. If there are transactions that exist on the HOST but were not sent by the POS device, they can be kept on a separate screen for review.
After the end-of-day falls into batch upload, it is important for the batch number to be incremented by 1 on the POS side.
It is also very important to investigate why end-of-day processes fall into batch upload.
Recommendations for monitoring the process
Whether batch upload messages are processed successfully should be monitored, and alerts should be generated for records that cannot be processed. Since there is a risk of the same transaction being processed twice, an idempotency check is also required.
By tracking the daily batch upload rate, the operations team can identify problematic POS models or software versions. For terminals that frequently fall into batch upload, a software fix or parameter check should be performed.
