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