Perpetual Inventory -vs.- POS They cannot coexist

[bkm]

@JayRam

you hate to encounter a situation where you have a customer with your product in one hand and money in the other and your counter sales guys say, sorry, can’t sell you that as I cannot see it in stock.

@olamide_shodunke

And I agree with you, in all my retail establishments negative stock is turned on.

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.

BKM

[Manan_Shah]

Facing Issues with this validation

1. Cannot correct errors since ERPNext validates the value between Stock and Accounting Ledgers on all accounting/stock transactions. It is like a Catch 22 situation. How does one overcome this? Turn off Perpetual Inventory for a while?
2. Stock and Accounting Value Comparison Report is scary. It shows all transactions as Mismatch when the default Stock Account set on Company master is set on the Report. This makes it difficult to fix these errors

Posting a Journal Entry cannot be the only way to fix this problem, it is a temporary workaround but it posts value to P&L account “Stock Adjustment” which is hard to justify on P&L. Therefore, there should be a way to fix these errors at source.

[JayRam]

Hi Miles,

You are way ahead of me on this. Are you saying you don’t like the POS implementation on ver 13? Is it because it does not post the counter sales transactions in real time?

Does POS Awesome post POS transactions in real time? Do you know? Or do we have to ask the master himself? @youssef?

Thanks

Jay

[youssef]

Hello all
That’s true, POS Awesome is creating directly Sales Invoice and it post transactions in real-time.

And for the speed issue, I used a technique to enqueue the submission of the invoices, there an option for that in POS Profile, this will make a huge difference in performance.

I hope this will help.

[bkm]

@JayRam

Are you saying you don’t like the POS implementation on ver 13? Is it because it does not post the counter sales transactions in real time?

YES, That is exactly what I am saying!!

Not only does it appear to violate the true interpretation of perpetual inventory, it also creates situations where you can really anger your customers when you sell them something that you do not actually have in inventory!!

The current implementation of POS only really works for the smallest of small businesses that might only have a single POS terminal. Any business larger than this has the potential to sell the same single item from inventory multiple times during the day.

• How then do you decide which customer gets the Item?
• Is it based on which cashier closes out first?
• Is it based on the time of the day the item was sold?
• What do you tell the other 2 or 3 customers that bought that item and cannot get it?

It was this very problem that turned off a whole chain of furniture stores that sell limited production custom furniture. They have multiple sales reps in multiple locations around the city, but they all sell from the same warehouse.

Do you have any idea how ridiculous I sounded when the only thing I could think to recommend was that the sales rep close out and reopen after each sale!

Needless to say, their opinion of ERPNext is quite low and I was asked to leave.

Furniture stores are NOT the only businesses that operate within this sales model. After being thrown out of the furniture business by the accountant, I realized the problem and canceled my demonstration with a close out appliance store. They use the exact same sales model except the product is a limited supply of appliances.

Making the POS module work ONLY in the open/close cashier mode is only good for places that will always have the same inventory and will never have a problem restocking like drug stores or candy stores. In those locations the inventory is in the same building as the cashier. In all other sales models this method of POS only creates bad reviews for the business from angry customers.

Who would ever adopt a system that perpetuates such anger with their customers?!?

When the dev team decided to move POS to this new model, they completely alienated the other half of their client base.

BKM

[Muzzy]

Sorry to say but the core team never allowed us to assist in development of new app. We have given many recommendations on what and how the features need to be there. Heck, i had even designed a layout that would have assisted the user to increase transaction. There are so many important button not available in the new POS.

We have worked with many retailers and have also installed other retail software, not just ERPNext. Our recommendations were based on real use case, users feedback and by working on other software. Sadly, work went ahead in silos. You can check historic thread that was made to discuss new POS. Folks in the forum have given some excellent suggestions

I agree with @bkm the new POS is not inline with the real world requirement. Fortunately, @youssef has made an excellent POS.

[federico_calvo]

The little ones are also affected! If you have an ecommerce or amazon synchronizing stock both ways, there you have a big problem.

An angry live customer is not the same as a bad rating on the web.

Invoices are another roll, because in places where you have to give a fiscal invoice, give an alternative voucher, where then at the end of the day the fiscal one will be generated.

Likewise I am more concerned about the issue returns on stock calculations that came out based on the discussion of the pos. Because I do not see anyone from frappe intervening.

[fkardame]

After looking at the new POS in V13 and the way it post invoices, I have already advised my management to start working on a new POS either online or offline something similar to Pos Awesome to replace v13 core pos.

Core pos is not very practical to implement in a production environment. The UI looks good but ther layout keeps changing from right side to left side which is not very user friendly when the till have long queue of customers. Number of clicks needed to close a single invoice was also counted and informed in the thread where core pos development was discussed.
Many of the things were discussed before about Core Pos here but looks like the core team was not interested in community comments and they did what they wanted to do from their point of view.

I propose to enhance pos awesome and use it on v13, We all can contribute to @youssef to make it more stable and user friendly.
Looking at Core development at this point, I do not think the core team will do anything in v13 anymore, if there is any other way things can change then please share it out.

Will appreciate the advice on making pos awesome to be used as retail pos on v13, @bkm @Muzzy @youssef @olamide_shodunke @JayRam @Manan_Shah @brian_pond

[JayRam]

@youssef can comment better on this but POS Awesome works independent of the Ver 13 POS. Yet it uses many of the same settings.

@bkm: Have you test ridden POS Awesome? You should. It works on both Ver 12 and Ver 13.

So we already have an alternative to the native ver 13 POS of ERPNext. I mean trying to make POS Awesome the default native POS on ERPNext 13 is really too big a decision. I think that the next version of the Native ver 13 POS will likely use many of POS Awesome Features. I hope!!

Thanks

Jay

Thanks

Jay

[bkm]

@fkardame

I propose to enhance pos awesome and use it on v13, We all can contribute to @youssef to make it more stable and user friendly.

While this idea is a good idea, it really then puts pressure on @youssef to build a permanent organization around a single module (POS) when all he was trying to do was satisfy his own customers like the rest of us.

The better approach would be to add his code base to the core and get it into the regular support of those developers that volunteer to support core functions.

@youssef is a single developer that spearheaded a great project to get a newer and more useful POS module, but can he support it long term as the frappe framework and erpnext are constantly changing possibly causing breaking changes to his module?

That would seem like a very heavy load to carry. Afterall, his development work was specifically targeted to fix problems the core team were ignoring. What is to prevent them from continuing to ignore the issues? W cannot expect that @youssef would always be able to surge major development efforts to fix breaking changes that the core team could be releasing multiple times per year. He made a wonderful module so he could solve a problem he was facing. He as been gracious enough to keep it working already over multiple version updates.

However, if the development team does not care about his work and does not wish to include it in the core system then at what point can he move on to other projects necessary to help his clients? We cannot condemn him to supporting his wonderful POS app when it is going to be constantly fighting against a core team that does not care.

What happens if the core team decides to partially fix their own POS by completely refactoring the Sales Invoicing system. Are you then going to bully @youssef into recreating his application?

I am sorry, but this makes no sense to me. The effort here should be to either get his code accepted into the core or the core code fixed to mimic his application.

My point is NOT to minimize the effort and excellent craftsmanship of POS Awesome. My point is that it’s creation is a symptom of a larger problem and it should have only have to be a temporary fix until the core problem is addressed.

Frustration aside. I must admit that in order to adopt POS Awesome for some of the systems I install KNOWING full well that it will someday become the landmine in the road that I will have to deal with when the core dev team implements changes that break POS Awesome beyond repair. It will happen. It always does. They break their own code all the time so we cannot expect that the frappe functions that he depends on would somehow be spared.

BKM

[fkardame]

@bkm

he was trying to do was satisfy his own customers like the rest of us.

That is true but atleast he is listening to the community and adding features on request.

@bkm

The better approach would be to add his code base to the core and get it into the regular support of those developers that volunteer to support core functions.

This would be the perfect thing to do but will the core team accept it is the question.

@bkm

is a single developer that spearheaded a great project to get a newer and more useful POS module, but can he support it long term as the frappe framework and erpnext are constantly changing possibly causing breaking changes to his module?

That the community members can decide and setup a fund either through bounty or open collective or something.

@bkm

That would seem like a very heavy load to carry.

I have accepted this fact, unless the core team becomes serious about the pos.

@bkm

W cannot expect that @youssef would always be able to surge major development efforts to fix breaking changes that the core team could be releasing multiple times per year.

We have developers too and can put their time on this app when needed.

@bkm

We cannot condemn him to supporting his wonderful POS app when it is going to be constantly fighting against a core team that does not care.

We do not have to depend only on him, as mentioned about we do have developers where we can put their time on this, atm it is not a priority for us, if we get a client who wants our pos bahrain functions on v13 then we will have to look into pos awesome.

@bkm

The effort here should be to either get his code accepted into the core or the core code fixed to mimic his application.

This would be the perfect solution but I dont see core team commenting much on these issues.

If there are github issues related to v13 pos then we should move there but again that would only be to fix the issues which are currently present, it will not switch completely to what we all are expecting from it.

[brian_pond]

‘Hope’ is not a strategy.

@bkm

The effort here should be to either get his code accepted into the core or the core code fixed to mimic his application.

@bkm, let’s assume the core simply will not budge and collaborate. What’s your best, alternative path forward?

[olamide_shodunke]

I love the various directions this conversation is going.

I also love the fact that POS Awesome is getting so much love.

By the Way In a few days time POS Awesome will be delivering an amazing version 2. Yousef and I have been working on this delivery for a few months now and it is really really cool, loads of new features. Exciting new features.

POS Awesome is here to stay long term. That is a guarantee. It is currently been used by dozens of very serious minded retailers who are willing to put their money where their mouth is. And it is open source. Other developers are already sending valuable pull requests to it. Mohammad and his team @ havenir basically contributed the credit sales and credit note functionality to POS Awesome.

I appreciate @bkm’s fear of obsolesce, but that is not about to happen anytime soon. POS Awesome is just getting started.

I know I am super stoked about the solution, you cannot blame me, the inbuilt POS in ERPNext has thoroughly frustrated me and led to many lost clients. Investing in POS Awesome was a no brainer, and my team has had the added benefit of working with @youssef and his amazing team.

@bkm I will suggest that you overcome your fear, maybe let your dev guys have a look beneath the hood of POS Awesome? There is still so much to do in the road map and we can collaborate with Youssef and his team to get there faster. What do you think?

Also note that the inbuilt POS itself keeps introducing breaking changes too, so your fear for POS Awesome also applies to the inbuilt POS.

PS…Really watch out for Version 2, I am not Joking, it will be exciting.

[bkm]

@brian_pond

@bkm, let’s assume the core simply will not budge and collaborate. What’s your best, alternative path forward?

That would be to adopt the POS Awesome application as my POS module and once again LOCK my versioning to whatever level I have it working with no further changes for a few years.

I may be able to test future versions with POS Awesome, but once there are breaking changes, I am locked out of further upgrades.

This is NOT that path I would prefer to be walking right now, but it may be the only path available.

BKM

[bkm]

@olamide_shodunke

Also note that the inbuilt POS itself keeps introducing breaking changes too, so your fear for POS Awesome also applies to the inbuilt POS.

Thanks @olamide_shodunke

Your encouragement reminds me a great deal of how an old friend John Clarke would have responded. You may have become the forums new calming influence.

Okay, I get it now. core POS is always going to go it’s own way and we cannot influence that, so it is time to accept POS Awesome as my new normal. As much as I was hoping to get away from 3rd party apps, it seems inevitable that I will have to use them.

And you are so very right. @youssef is very much interested in keeping a working POS function alive. I had a phone conversation with him not long ago and he is just as genuine as you describe him.

Thanks again for taking time to talk me back from the edge of the idiot cliff I was racing toward.

While I can agree to embrace POS Awesome, I am not sure it matters unless we can get a fix for the perpetual inventory system creating such slow invoice submit times.

BKM

[brian_pond]

While they are definitely cross-module impacts, it’s important to remember this thread is really discussing 2 separate issues.

1. POS-specific Challenges.
   • Example: The problem where you cannot trust the On Hand quantities being reported, because they are not synchronized.

Implementing POS Awesome can easily resolve things like this.

2. General ERPNext Challenges:
   • Example: The way Perpetual Inventory is implemented, resulting in 30+ seconds to post an invoice.
   • This impacts many ERPNext Users. Not just those using POS.

This is more complicated. There are 3 ways of fixing these types of issues:

1. Improve the official upstream repository. This is ideal.

2. Each ERPNext user makes their own fixes (self-fix, contracted developer, etc.). Because these are not POS-specific issues. Therefore, it’s unreasonable to expect POS Awesome to solve them.

3. We sponsor a new, standalone App. Name it “PerformanceAwesome” or “BugFixAwesome”. Or the “Unofficial Patch for ERPNext”. This App is just a set of guerilla patch (monkey patch) code. Designed to alter the Frappe framework code at runtime, and fix headaches such as Perpetual Inventory. Until such time as the maintainers of the official code introduce their own fixes.

The problem with #3? It’s always ‘chasing’ a moving target. Every time ERPNext moves to a new minor release (13.4, 13.5, 13.6), the App would have to be tested again. To ensure its patch code is still valid and correct.

Then again, ERPNext is a moving target too. Earlier versions didn’t have these inventory and invoice performance issues. Now they do. Demonstrating how a New Version is not always a Better Version.

[Not_a_countant]

I think there is strength in numbers here. So I guess someone will have to keep up the good work and follow newer versions of ERPNext. And since so many retailers are building on the same POS Awesome, it is better to stand behind it.

@brian_pond

Periodically , the finance department runs reports. To compare the value of the inventory according to the inventory sub-system, versus what is in the General Ledger accounts.

• If everything is configured properly, and no one has made manual Journal Entries, everything should tie out.
• Otherwise, if there are discrepancies, Finance reconciles and adjusts

This works well in a company that has a “finance department”. Or has someone that understands stock revaluation and reconciliation. For most small companies that manage some stock, this kind of stuff doesn’t happen often. If we say ERPNext is designed for these mom and pop stores, this is the right approach. However, if you have a “finance department” that knows what it is doing (other than creating invoices), then ERPNext needs a different approach as @brian_pond mentions.

Maybe, someone could chose “periodic stock” instead of “perpetual stock” and write a custom module to update stock periodically? I don’t know how that would work, but seems like a way out. Maybe a few of us need to come together on this and find way forward?

[Not_a_countant]

By the way, is this one of the reason why standard costing is used so often is to kinda get out this rut?

All differences to a standard cost (of material, production etc) are posted to a variance account such as material variances, production variances and logistics variances. Consequently you get a standards based P&L and a few variance lines. At the beginning of the next year, all products are revaluated and posted as a gain / loss to P&L.

This could also be a solution to process manufacturing. One theoretically consumes stock as per a standard BOM and posts material variances to the P&L either as a gain or a loss. So in the period, it nets out.

[brian_pond]

Standard costing certainly offers some potentially useful trade-offs. Most of my clients didn’t want to lose the COGS accuracy. But there’s nothing wrong with it. Certainly a tried-and-true costing method.

But there’s just no reason for Perpetual Inventory to be implemented with expensive, realtime calculations (ie. summing huge quantities of transactions, each time you post an invoice). Just post the debits and credits to the GL.

It should not be the responsibility of 1 invoice to validate that GL and Inventory are reconciled for the entire part number’s history.

Or fail to post altogether because the validation failed.

[Not_a_countant]

COGS accuracy!

Specially accurate when you allocate the strippers tips from the CEO into your Widget’s ABC costing.

On sometimes in corporate we like to call it “getting it precicely wrong”.