The whole reason behind the custom apps (most especially those that add core functions) is the “…please contribute…” model is not working!!
When apps or core functions are offered as PR there are very few that ever get reviewed and even less that make it into the core. Yet these functions are so badly needed that the community developers are spending their time and effort to develop these things they need as core functions and making them the only way they can… as custom apps in frappe.
As you indicated, in the vision of monolithic development, everything should be in the core, but with no path for the user base to get functions into the core, they develop their own.
If you really want this practice to end, then you would have to alter the path of the entire project away from a volunteer developer model to something that more closely resembles a non-profit corporate model that follows a board of directors (i.e. users) to set the development path. I do not see the current leadership being open to such a drastic move.
In order to keep the volunteer developer model, you will have to expect the custom apps because the community does not see a way to get the functions they want in the project added the core at this time.
You say the market place concept is “strongly against the ERPNext development path” but you do not offer a valid way to solve the problem of users needing functions the current developers are creating that either oppose the needs of the user base or simply refuse to fill those needs at all. You cannot have it both ways.
If you wish to keep the current development model, then you cannot complain about how the user base develops their own apps to get the functions they desperately need.
And YES this thread did wander off topic… sort of (but not really). Since it is one of the very core functions (frappe’s weird implementation of perpetual inventory) that has made POS (or any sales invoice submit function) unusable, this actually seems to still fit the topic.
What I meant exactly… all this long, everyone is encouraged to contribute to the core, but many times they are discouraged by the process which result in frustration and they develop their own solution in the form of custom apps. So the term contribute should expand to include the ecosystem (in terms of coding), not only to the monolith core of ERPNext, i.e by providing custom apps.
From the beginning, I think, the marketplace is not encouraged in the development path of ERPNext. As I mentioned above, my term of marketplace is not necessarily monetary, but a place where custom apps are offered and demanded (maybe one can call it “blackmarket” )
But it can be monetary if a user start to ask for a complete custom app and will pay for it
this may not be intended or suggested by anyone. But as mentioned, it is unavoidable if more and more developers find their own solution and offer it as custom apps. Imagine if one also make his version of POS because there is a function can’t be fulfilled by built-in POS or POS Awesome.
How about another custom apps for Chat, Nextcloud, Shopify integration, and so on…
It is not me who against the concept
I said strongly against (by some people) in the ERPNext development path.
No, I don’t complain. This is what I do as well. But since I’m not a programmer I can’t make good and complete custom app to offer to the community nor to support it in the long run.
My contribution is part of codes I answer to questions in the forum that I see solve a problem.
Ok, I think we are saying the same thing. The community is already at this point. They are indeed creating their own solutions and essentially making this entire project a “platform” model even though the foundation of it is not necessarily stable enough to support a platform. (The framework changes just as whimsically as the ERPNext app).
As far as monetary impacts, we are already there as well. I know I pay developers to fix this stuff for me because I am not a developer. I am an implementer.
While I have done my absolute best to avoid using 3rd party apps like POS Awesome, my belief in the monolith structure no longer allows for this. I spent more on trying to change the core POS several years ago than I spent in house payments that year. Some of it made it to the core in v10, but by v12 it was all thrown away for a new POS approach and all that I spent to help the community went to waste. It is now pretty much unusable if you need immediate ledger updates to support your business model like I do.
So here we are. While I have not seen many (or any) apps offered for money, The net result is still the same because someone had to spend money to make them in the first place in support of their own needs. Maybe if there were a community dedicated to making just custom apps for cash, then we could grow the project faster. But to do that we need a stable framework and a commitment from the core developers to avoid making unnecessary breaking changes to the core code.
Respectfully, I think you are misunderstanding what the development team means when they talk about “the monolith.” Apps have been a part of Frappe/ERPNext from the very beginning (or very close to it). Over the past few versions especially, the maintainers have added a tremendous number of hooks to give apps even greater possible scope. In their own official platforms, Frappe Technologies is giving greater and greater prominence to apps, including POS Awesome. If they didn’t believe apps have an important role, they wouldn’t be doing any of that.
New apps for chat, new alternatives to the built-in PoS or PoS Awesome, new integrations with local payment processors, new doctype domains, new experimental approaches to existing functionality…these are all great ways to use the app framework that Frappe has given us. None of them threaten the monolith. The existence of apps – even many apps – is not in conflict with monolith design principles.
Apps provide a pathway for experimentation. They also provide a way for the maintainers to have confidence in community code before incorporating it into core. If we want to experiment with better ways to handle PoS inventory, apps are an ideal way to do it.
Agreed; that is a great outlook on the benefit of custom Apps.
I don’t think my problems with Perpetual Inventory can be solved (safely) with an App. Which is unfortunate. And I’m unlikely to convince the maintainers (whoever they are) that this feature is actually a “bug”. So. I’m just going to modify the ERPNext code directly. Continue maintaining forks. And keep moving forward.
But for new features and additions, or stand-in replacements? I definitely think a custom App is the way to go.
That’s what I’m curious about. You’ve got vastly more experience with the stock ledger than I do, but on quick review it seems to me that a relatively clean solution might already be available.
Earlier in this thread, you suggested that the slowdown was being caused by the check_if_stock_and_account_balance_synced function in accounts/utils.py. I suspect you’re correct about that, as it’s a very intensive bit of logic. In the context of sales invoice creation, it appears to be getting called here:
What’s interesting here is that the validation call gets skipped if an item valuation repost is already pending. If you were to pre-schedule a valuation repost with the before_submit hook, likewise, it should kick everything over to an asynchronous process, which would be much more performant. Would that not work? (It’s similar to what I believe POS Awesome does enqueuing invoice submissions.)
It appears to be a fairly safe fix, though not as semantically transparent as it perhaps should be. Longer term, a simple hook could be placed here, which would allow for more complex logic to be provided by an app. That would indeed require a PR, though a very short and simple one, which is going to be vastly easier for the maintainers to evaluate than a lot of new functionality.
Sorry for the super delayed comments on this. There are some points which needs correction.
Stock update by the inbuilt POS is not immediate .
So yes it is possible to sell more than what is in stock .
It is a serious issue @olamide_shodunke
The ERPNext POS works online, hence very much capable of validating stock availability before submission of stock. Incase stock is not available, POS invoice submission is restricted.
When the POS sync to inventory, it will leave the stocks by:
100 USD valuation rate?
120 USD valuation rate?
In any of the 2 cases there’s a system contradiction, due the timing of the operations.
If it leaves the stock by 100, it means I’ll stay with 0 Items in stock with 20 USD in the stock account associated with this item, that I never will be able to correct! @max_morais_dmm
This will be eventually corrected in the Sales Invoice (which is made from POS Invoice) and stock valuation will be updated for the item.
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. @brian_pond
We very much understand the cost of reposting. This was the very motivation for immutable ledger, but eventually for converted to reposting-via-background-job. @nabinhait@rohit_w perhaps we can give this a fresh though. If you are open for periodic entry, then we can make reposting. This will also be concent of the user on the sales and profitability report based on stock valuation available at the time of posting.
But can you clarify the point above? Will the validation check take into cognizance the items already sold but not yet consolidated because the cashier is yet to close? Or is it validating the on hand qty as at the time the cashier opened her till.
Last time I checked it does not take into consideration the items yet to be consolidated and that is the issue.
It will take into account the qty which is already sold by another cashier for whom closing is not yet posted. In short, stock balance tracking in POS is real-time. The example I shared above. I got this validation without shift closing entry was created.
With v13 beta I created a demo production system with 2 POS users and a single warehouse. Both users were listed as primary in the same POS Profile. In the warehouse I placed 10 unique items each with a qty of only 1 in inventory.
I used 2 terminals and logged in as the 2 POS users.
I sold 3 of the items in the warehouse to a cash customer from POS user #1
10 minutes later I sold one of the same 3 items to another cash customer from POS user #2
This means that I sold one of the items twice and the sale processed as expected.
I closed out POS user 2 first and the transaction was submitted successfully.
When I closed out POS user 1 the transaction created demand for the item sold by POS user 2 (I had negative stock enabled by accident).
This was a failure on 2 levels. First the sale that actually occurred first was the sale by POS user 1. This means that it should have been assigned the available inventory, but the available inventory was given to the user that closed out first which is the second failure here.
I also ran other experiments where one of the POS users would log out of the system (as if to go to lunch) without closing out their drawer. Then they log in again 30 minutes later and a sale that happened before lunch did not show up in the end of day closing.
My trust of the system at that point was destroyed.
Is that justified since it was in Beta version during my testing in Feb of 2021? Maybe not, but it was literally only 5 days after this testing that the 13.0.0 production version was released. So I doubt any of this was actually fixed by then.
Is it possible these things are fixed now? Possible, yes. Does it really work now? I am doubtful since so many other things have been broken and patched and broken again in the past 5 months since my testing and the system still feels like Beta actually.
Conclusion:
I am in the midst of a significant effort to upgrade a v10 client and I do not have time now to do the testing that I used to do for fun in the past. I have far too much on my plate right now to go back and verify if the new POS actually works as @umair describes.
Maybe someone with a little time can setup the same experiments now and tell us it this is actually fixed.
This discussion on Perpetual Inventory -Vs- POS is quite interesting and very educating, especially for some of us who are implementers without a programming background. I have followed the post from the onset through all the comments from all of you great minds.
Yeah, I am the person that observed the Real-world example that @Muzzy mentioned above and it’s quite shocking when you have a demo to a client with the knowledge from previous versions that this or that is very much obtainable, only for you to use an upgraded version (which by my little understanding of the word Upgrade) is meant to improve on something but rather you find yourself scrambling to explain a good process that was abruptly stopped by the same upgrade that was meant to improve it.
I like a comment made by someone above A new version is not necessarily a better version I am just learning it the hard way now.
I love the kind of end-to-end test run by @bkm on the POS transaction as narrated above. Those are the kind of things I love doing. I have also done some already.
I have a very good accounting background but feel like in the current world we are in today, my no knowledge of coding is seriously limiting my potentials as an implementer. I said this because many times I know how to solve my problem but have no technical ability to do it. I can see clearly what’s not right but (Just like I noticed from previous versions that deduct loan from payslip even without passing a disbursement entry, which is very wrong in the real sense) most time it’s difficult to pass some of these minor corrective info to a programmer you work with that has no much knowledge of accounting or inventory.
I am not in any way discrediting the tireless effort that has been made by the maintainers to keep the solution running. I have enjoyed most of my implementation on ERPNEXT but a lot still needs to be done, especially in the part of tearing down or deviating from a process that’s already working fine.
I have not been quite regular in this forum, except when I encountered challenges in the cause of my work, but with the kind of knowledge I acquired just reading through comments on this POS post, I feel it’s time I also become part of the problem solver.
I can do some coding, so if you have good idea to implement new feature or would like to fix some broken feature, please create new post or github issue, let’s see what we can do together to improve.
)
. 