We have noticed that once in a while an invoice that is paid (Not draft) while the PoS module is offline might have issues been submitted when offline invoice is eventually synced. The invoice is thus stuck and is not submitted to the server. It will not show up in the invoice list on the server.
This is not a big deal and is to be expected.
The challenge we have is that once an invoice is stuck like this, all other invoices created on that particular computer are also stuck, even of there is no problem with them. It appears that the stuck invoice blocks the pipe and prevents all other invoices from been submitted.
This is a big deal.
I will recommend that the PoS script be adjusted to allow stuck invoices to be skipped while subsequent invoices are submitted without fail.
I hope the team can look at this and address it.
I have created a github issue for this as highlighted below
Might it be better (at least in the short term) to identify the problem causing the “Stuck Invoice” and alter the POS settings to allow similar ones to pass in the future?
When I tried offline POS I found this same issue and in my case it was due to errors in the inventory counts of the warehouse. A miscount meant there were actually many more of an Item in stock than the system had on record. So by not allowing negative stock, the invoices would back up on the browser terminal. We had to allow negative stock to stop this from happening again. However that meant we had to pay closer attention to when stock numbers went negative and get the issues fixed.
There are several possible other causes but identifying them and setting the system up to allow them to pass may be your short term solution until it can be addressed by the developers.
Offline POS is really a compromise operation. You use it when internet service is not consistent. However, as a compromise, it is not a perfect solution and may never be really. So, doing the best we can to make it work as reliably as possible is the real goal.
Your suggested solution is what we do at the moment. But sometimes the problem is not as simple as negative stock.
At the moment we have a stuck invoice situation that does not throw up any error at the error log list and we have no idea what the situation is.
If the PoS could skip the stuck record it would be easy to identify the offending invoice , flush the cache and repost that one single invoice. Right now I have 113 stuck invoices with no idea what the problem is.
This is why it would be really convenient if my suggested ammendment could be looked into.
This is already implemented, if there is any error in particular invoice, system not stuck the other invoices in the queue. If all the invoices are stuck which meant there is an issue in all the invoices, any error in the error log related to POS?
If operating in OFFLINE mode, would the rest of the system even be able to get enough information to post errors? Or would the errors to be reported also be stuck in the queue?
Initially we had an error log where an item was inactivated before the offline transaction, but this was corrected and after that no more error log entries for PoS.
When was this implemented ? Could you cross check and confirm that trully this has been implemented?