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

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.

Regards

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?

https://github.com/frappe/erpnext/issues/10617

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

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)

Cheers!

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.

Regards

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

BKM

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.

@System19
@olamide_shodunke

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.

BKM

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

My clients do not allow this.

Regards

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.

BKM

1 Like

Yes your “Misc” service item is exactly what I was trying to describe.
A popular till system used here in Australia (Vend) deals with negative stock like this.
The chashier scans all the customer items. When “Tinned Plums” are scanned an error message pops up telling the cashier that there is no stock and do they want to add it to the sale anyway. The cashier then has to click yes to continue or the sale will not proceed. Vend then just adjusts the stock level to -1.
If when a negative stock issue occurs in ERPNext would the solution above combined with adding a not in stock suffix (NIS) to “Tinned Plums” on the sale receipt be enough of a searchable flag to prevent fraud in your business?
When vend is offline a UI warning banner appears at the top of the screen making the cashier aware that the register cannot connect to the central DB. I imagine that stock numbers are loaded into Local Storage along with Item Name and Price etc.

Internet connections here in central Sydney (Australia’s most populated city) drops out at least once every 2 months. Yes I know thats crap. As such most ADSL 2+ modems now come with a 4G mobile network sim card for Fail Over situations.

@bkm @olamide_shodunke

@rohit_w

Rohit, Thank you for the update about Online POS. This is exactly what I needed. Will this be in the Master update next week?

I cannot run developer mode in my client site testing unit, so I must wait for it to be available in production mode. Any idea when that could be?

Thank you and your team for making this a priority fix.

BKM

thanks. that is actually not acceptable in retail. I keep saying it, most people are not using erpnext for true retail processes. I wonder how @wale runs those stores on v8? maybe he has a custom online only pos but if its the one we know then there must be serious issues and we cant tell how much agitation he has from the client, we have all tested it, its unusable for business as is, period. maybe you use it just for office style invoicing but for fast-paced retail. no way Sir. the team are working on it cus theres an obvious problem so I wonder how you got it to work

1 Like