Okay, That is really the purpose of “negative stock” to allow you to sell items on hand that for some reason are not in inventory.
However, consider the following:
I have a client that has a fleet of trucks that sell items to commercial customer right from the back of the truck. The drivers load their truck early in the morning and set out on their routes to sell product.
Since the drivers MUST use the Stock Entry system to load their trucks, and their POS profiles limits them to the inventory on their truck (each truck is a valid warehouse), then you most definitely want for the driver to NOT be able to sell a product that may be on their truck but not not in their inventory.
Why you ask… Well, the drivers are responsible for loading the truck and there are so many of them working on the dock in the morning to load up, it is impossible to monitor them for keeping everything accurate.
If they encounter a product they are trying to sell and it is not in their inventory, then they must call into the home office to have their inventory updated for the item and then the home office will trigger a spot inventory check of the drivers truck to see if it was a single incident or a sneaky practice to steal from the warehouse and sell for cash.
Sometimes the strictest implementation of the perpetual inventory concept makes a great deal of sense when you are a small business and you cannot police every stock transfer or sales transaction.
To this end, I am opposed to taking away the potential for the strictest level of implementation because I have witnessed how such a client can use it to cut back on shrinkage and theft.
At this point though, the problem with perpetual inventory does NOT lay with the POS delayed sales invoice issues.
The problem is that with every Sales Invoice transaction, when perpetual inventory is enabled, the “Submit” function of the transaction triggers a complete financial re-calculation of all warehouses and all inventory to see if the totals match up. If you have a thriving business and many thousands of transaction during the week, then in a very short time you will find that ANY sales transaction takes forever because in order to submit it, the system wants to balance check the total of ALL inventory against the general ledger recorded values. When the number of historical sales transactions gets into the hundreds of thousands, the time to complete the calculation can take a minute or more.
This means that in v13, even a small convenience store owner that makes 5 thousand sales transactions a week, will have close to 150 thousand historical transactions after only 6 months of using the system. So sales transactions that would complete in less than a second at the beginning of the year would now be taking 13 to 15 seconds to complete. How do you think that will be impacting their ability to continue making 5k sales transactions per week? This is using a single sales terminal. Imagine how the system would be affected if there were multiple users trying to make sales transactions at the same time. The delay times would be impossible.
The point is that perpetual inventory as implemented by frappe in v13 is really making the ERPNext system useless for any business that relies on sales transactions.
The argument about POS being within the perpetual inventory rules no longer matters. The system is no longer usable anyway.