API has mechanisms to detect duplicate sales records (by analyzing input parameters) and prevent them from getting into the system. It analyzes every incoming saveSalesDocument and savePayment request; and if it concludes with high confidence that the "same" document or payment already exists in the system, it discards the sent data and returns a fake response (the ID of the "original" sales document or payment).
This is necessary because duplicates are, to some extent, unavoidable. It is natural that POS might not receive an answer for a network request; in that case, the most appropriate action is to attempt to re-send. If the original request, however, did reach the server, and the second request gets processed as well, the system may end up with two copies of the data.
Thus, data submissions require a certain degree of "idempotence", or tolerance for repetition.
Invoices and payments do not, however, have any intrinsic "identity", and therefore the checks must be designed considering:
As an example: it is entirely possible to have two sales documents with the same date and same number (if multiple copies of Offline POS are run in parallel, logged into the same register). Thus, having same number and same date is not sufficient to detect one document as a "duplicate" of the other one.
For the duplicate check to take place, the following fields must be present in the request:
For Berlin POS, the conditions are different. For the duplicate check to take place, the following fields must be present in the request:
For the duplicate check to take place, the following fields must be present in the request:
API client must be one of the following: 'TouchPOS', 'POS2020', or 'offline_POS'