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
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.
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.
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
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.
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.
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
@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
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
That is true but atleast he is listening to the community and adding features on request.
This would be the perfect thing to do but will the core team accept it is the question.
That the community members can decide and setup a fund either through bounty or open collective or something.
I have accepted this fact, unless the core team becomes serious about the pos.
We have developers too and can put their time on this app when needed.
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.
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.
‘Hope’ is not a strategy.
@bkm, let’s assume the core simply will not budge and collaborate. What’s your best, alternative path forward?
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.
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
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
While they are definitely cross-module impacts, it’s important to remember this thread is really discussing 2 separate issues.
Implementing POS Awesome can easily resolve things like this.
This is more complicated. There are 3 ways of fixing these types of issues:
Improve the official upstream repository. This is ideal.
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.
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.
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.
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?
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.
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. 
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”.
Suggestion: on submission of fiscal year-end closing. system do this balance check for 1 year transactions only year-on-year and saved in separate table e.g. Stock Ledger balance? So ongoing fiscal transactions no need to scan through all stock ledger entry records to just get stock balance…
I agree with @brian_pond it doesn;t make sense to me, currently on every stock transaction, erpnext validates sum of whole stock ledger entry records and compare it with GL balance.
I think yo can move the call of get_stock_and_account_balance method inside the block (accounts/general_ledger.py)
if gl_map[0].voucher_type=="Journal Entry":
since it’s only called to validate Journal Entry submission