POS still not actually saving the transactions properly. All are DRAFT

Hi @bkm

Sincere apologies for seemingly ‘hijacking’ your thread. I was actually trying to help and didn’t start out expecting the conversation to draw out this long

Just so you know… all my ERPNext instances (along with their POS apps) are on the latest version (V8)

apologies once again

Kind regards,

Thank you @bkm for this response.

Practically nothing more to say, you said it all.

Some of us are willing to support this project, both by giving our opinions based on our experience as well as contributing financially.

A product can only get better if we all agree on the issues and move towards addressing them. PoS on V8 is not currently usable in a commercial environment. If you make your client use it, you expose them to financial loss. That is a fact.

I am however optimistic that the fixes currently been worked on by the ERPNext team will solve some of the critical issues.


1 Like

I am optimistic as well. Over the weekend my sponsored changes to POS were finally ready and setup in GitHub. So I think in the next update to the master we will be able to use the barcode scanners directly in the POS module with no search delays that were causing errors before. So in another week or two it may actually be available in the production configuration.

I did get confirmation the browser cache issue is nearly done as well and it may also be ready in a few weeks.



Hi @olamide_shodunke @bkm

While syncing offline transactions if any issue has encounter system will keep that transaction in the draft, so user can manually changes the necessary data and submit it.

@bkm did you tried to submit the draft sales invoice? Did you getting any validation error? Kindly share the screenshots or traceback of an error. It will helpful for us to debug the issue.

We always has the priority to provide bug free solution to our end users, but some issues was not encountered at our side. Online POS first development part has completed. Currently the PR of online POS is under review and soon we’ll release it.


Rohit, the quoted process flow is totally wrong from a retail perspective. Once a transaction is printed in retail it is considered completed. User should not be able to manually change the necessary data and submit it. And in your flow printing is possible even while the transaction is still in draft mode. In a retail environment this is totally not acceptable.

Retail is different from an accounting department in that regard. The process needs to be changed.

While this is still the case I will opt not to use the offline mode and I am happy the offline option is been made optional.

Thank you for the changes been made so far. We will review it once its updated and give you our feedback.


If you set the data properly in the POS profile and keep the stock level up or allowed negative stock, you will not get any error and system will submit the invoices successfully.

1 Like

Hi @rohit_w

Trust you’re doing great. Maybe we could consider adding a setting for this?


Kind regards

1 Like

Also limits on max discount can throw server side error and leave everything in draft. Maybe you could make alist of all the server side error check that goes on behind the scenes which prevents the submission of the POS sales orders. So people can temporarily change the thresholds to pass and then put it back.

If there is a server side error, the doc shouldn’t be created in the first place. In a retail environment, the transaction will most likely already be completed and customer long gone before you would know this.

1 Like

Hi @felix

Trust you’re doing great. The idea is for the validations to happen ‘before’ submission of the document on the POS side so that nothing hinders submission on the server side. There will however need to be some trade-offs like allowing negative stock and probably accepting that the last synced value for max discount is what will be applied (if working in offline mode)


Hi @wale

These are acceptable trade offs. In a retail environment negative stock is usually allowed though not encouraged. There is no point in preventing a customer buying a product because of backend inventory errors. Once the item is on the shop floor it should be sellable. So this is acceptable.


@olamide_shodunke Allowing negative stock in erpnext could post a great challenge in stock accounting in erpnext.Tread carefully and see the logic of stock valuation in the system

1 Like

I am not advocating negative stock in ERPNext or any other retail system. Back end processes should be in place to prevent this.

My position is this …if an item is going to negative at the point of sale (for whatever reason) are you going to prevent the shop floor staff from attending to the customer till they call HQ to correct whatever error there is? What if the sale is happening on a Sunday?

In retail the sale goes on and you resolve the back end issues later.

That is reality.

Hey can you guys list the server side validations that caused syncing errors (e.g. limits on max discount) maybe if those validations are replicated at the client side and their related data are also cached, the synching errors for offline pos would be greatly reduced

1 Like

Totally agree. Point well noted…

Ahh… This is where I differ with you. In my case, retail sales take place off the back of a mobile truck. Inventory is loaded onto the truck every morning to restock it like a mini rolling store.

If something ends up on the truck that was not tracked when loading the truck, then I want the sale of the item to be denied. I need to stop the transaction at that moment and force a manager to find out how we got to this situation in the first place.

  • Did the driver and warehouse person scheme to defraud the company by putting inventory on the truck (essentially a transfer from main warehouse to a rolling one) that would not be recorded?

  • Are some items in the inventory labeled incorrectly causing inventory items to be moved under a wrong identity?

  • How did excess inventory end up in a truck to be sold? Was it stolen and sold for cash to hide it?

In any of these cases, when the ‘exception’ is not detected until long after the fact, we are leaving room for fraud. In a retail environment, you are assuming that the items got to the shop floor by some proper transaction. The reality is that many times the stock was placed on the floor by the cashier (especially in small business) that will wait for it to come to the counter and make it a cash sale, pocketing the cash.

If you run a very large operation where the rest of the inventory movements are handled by persons other than those that might actually sell them, then your idea of operating with negative inventory is valid as the mistakes will be very few. However, in small business, this is not the case and the business owner would be left open to fraud.

This is the very reason I am replacing an older system with ERPNext right now. The dis-jointed configuration of multiple systems that must talk to each other in order to have POS and inventory control in the same business are the weak points that some in the company have already been caught exploiting. The shrinkage this caused represented as much as 18% of monthly profit. That was a huge piece of the bottom line accounting and needs to be stopped.

The only way to make this work is to have a system that will not process transactions unless there is valid inventory to sell. That requires a live connection to the database and really excludes any browser caching of transactions.

Other problems with current configuration:

  • Browser cache is held in the device. In the case of the the mobile stores (trucks) there would be nothing to prevent the driver from using the company supplied tablet to run the transactions that use credit for purchases and then log off the tablet and log in with their personal smartphone to record transactions where cash is involved. By turning off the mobile data on their phone they can effectively buffer all those transactions on a device they own and the company never knows. Browser caching of trqnsactions is bad here.

  • With mobile sales reps, when transactions are stuck in ‘draft’ or some other mode of limbo, the actual sales may not get recorded for a long period of time (if at all). The remote sales reps do not go to the main office except once every 6 to 8 weeks. We would not want them to have administrative control over their transactions in order to prevent fraud, yet an administrator at the main office may not see the sales device (tablet) for up to 2 months at a time. This leaves much room for even accidental loss of revenue.

  • Remote sales reps are good at making the company money because their strengths are in their people skills (not in I.T. skills) and trying to train them on the mechanics of the ERPNext offline type of system would only cause them to move on to other places where they do not have to worry about the extra electronic record keeping problems of ERPNext. In this case, not only are the sales transactions in danger, but so is the best talent of the company.

To sum it up… In a perfect retail environment and perfect store inventory system, browser caching may be less of a problem. However if you really had those perfect conditions, then why would you need it in the first place? Your internet connection would likely be near perfect as well because you have already invested a great deal into making everything else work perfect. Keeping a bad internet service would seem very out of character for such a business.

In my opinion, and based on what I have laid out here, I believe the cached transactions should be defaulted to OFF and only turned ON if the company is willing to expose itself to the possible bad circumstances that go with such an unreliable configuration. The staffing and extra man hours required to be constantly tracking down individual devices and making sure they are properly synced can be a big impact on operating costs. Cashiers and sales reps should not have to also be IT wizards in order to figure out if transactions are being processed. That should not even be in their job description. Yet, with such browser caching, that is exactly what would be required.

Cashiers make $8/hr locally. Sales reps make 9% to 12% of sales. Information Technology workers capable of figuring out how to find and fix “stuck” transactions get paid $18-$24/hr and usually require extra benefits in order to keep them on staff. Now finding one of the later that is also willing to be a cashier or sales rep… near impossible. Finding a IT worker that is also willing to track down dozens of portable devices to look for stuck transactions… definitely impossible.

I just do not find the current configuration of POS to be really very workable. It MUST be simple enough for a low wage, low education, cashier to use without the possibility of loosing tack of transactions. Mobile stores (truck drivers) are very similar, but harder to track down at any given time.


Would adding a “In Case Of Emergency” item that doesn’t require stock to be present solve this issue?
Say someone comes to the till with a tin of plums but there has been a stock keeping error. The cashier would just call up the “In Case Of Emergency” Item and enter the price of a tin of plums and completes the sale.


Many of us implementing ERP systems already use something like this. We create an “Item” called “Misc” (miscellaneous). This is a non-stock item and in some cases we list is as a service in order to get it to show up on an invoice or sales order. Whatever value or price is used here represents the missing item that they were trying to sell. The selling agent is then required to post a note with the sale explaining the use of the Misc item.

On the backend, all transactions containing Misc are flagged and someone is required to investigate the use of the item and take any corrective action in the system.

This is only works where you can forbid the sale of items not correctly placed in inventory. When you use a system in this manner, you have blocked an easy path to fraud and forced accountability on the user processing the sale.

When a system like ERPNext openly allows negative stock and browser caching of transactions, the ability to commit fraud by users is exponentially increased.


This will also only work where you allow cashiers to change prices of goods at the PoS.

My clients do not allow this.


While that may be true in the limited abilities of ERPNext, in most of the other systems I have running a “Service” is priced at time of sale and is outside the bounds pricing rules because of how services are recorded. Services are usually not treated the same as Items.


1 Like