That’s exactly what the Item Valuation Repost doctype I just mentioned does.
1 Like
So how do we get that on an implementation track?
BKM
Hi @youssef,
Nice analogy; I agree. Like you, I personally tend to choose option #1.
However, for a moment let’s pretend that you and I have the time (and motivation) to incorporate our changes into the “core” of ERPNext.
Okay. How?
The default, fallback answer is: “please submit a PR”. But in reality, it’s not actually that simple.
We are making important, fundamental changes to how POS and Inventory behave. Probably editing many lines of code. Deleting other code lines, or sometimes deleting entire functions. Rewriting the system to behave how -we feel- it should behave.
Let’s assume our code is amazing. Well-documented. Shiny and clean, and it works perfectly every time. So we submit a PR. We write a few paragraphs about it. We try to explain why Our Way = Better Way.
Will our PR be accepted?
This is not a bug fix. This is refactoring. So why should the maintainers accept our PR? Regardless of how wonderful our PR is, it is very-much based on our opinion. Our belief on how things should work. Certainly you and I strongly believe we are doing the right thing.
However, at some point in history, some other person(s) wrote the current, existing code. They probably thought they were doing the right thing too. And the maintainers agreed. They allowed today’s code into ERPNext. Either explicitly or implicitly, they said: “This is the way.”
So, to get our PR approved, we’re going to have to negotiate. We must (somehow) convince the maintainers that our way is better.
-
First, we must get all relevant parties involved. Who are these maintainers that are responsible for POS and Inventory? What are their names? Can they make this decision alone, or do we need to involve other people too?
-
To convince them, we need more than “back-and-forth” GitHub messages. These are large, complicated issues. If we hope to convince them, we need to communicate effectively. Probably we must meet online (several times) to have discussions and debates.
What I just described sounds like a lot of work and effort, doesn’t it? So much work, that PRs like this are rarely submitted.
If the ERPNext Community had Working Groups, and strong relationships with its Maintainers, these types of PRs might happen more often.
Until then, I suspect most ERPNext developers will continue taking the "path of least resistance". Which is operating in silos, and doing our own things.
4 Likes
Hi @brian_pond
You have just described reality.
To compound this issue, the kind of projects that leads to the quantum of work you described are usually paid for by clients. Clients do not have time to wait for “negotiation”, once the product is tested and it meets their needs with no apparent “side effects” they are good to go.
Very few (if any) client insists that their “refactored” solution must be pulled into the core before they will use it. This removes the motivation for the developer to stay the “negotiation” course.
Merging a major project is a lot of work, time and resources are involved, and some projects just cannot be merged. I guess this is why on frappecloud the Frappe team have showcased some apps that can be installed with one click if the subscriber requires it. I think there are about 7 of them at the moment, POS Awesome, the Telegram app, Nextcloud and four others.
Could this be a midway solution for major projects while bug fixes remain the majority of pull requests by the community ?
I really do not know, but this is a very important conversation to have.
This can definitely be a way forward for major community initiatives. Over the past few versions, there’s been a lot of impressive work on the backend to make Frappe more extensible, too, so apps are more powerful than ever.
Early on, I think the maintainers were nervous about supporting apps because of all the fragmentation in the Odoo ecosystem. But, there are other models too. Drupal has used apps to tremendous effect in exactly the way you’re describing, acting as a staging ground for new ideas before incorporation into core.
The maintainers are (rightly) cautious about incorporating community code into the core, but apps are a great way to battle test new initiatives at scale. POS Awesome is well on its way down that road already.
The last posts from @brian_pond, @olamide_shodunke, and @peterg would create a “marketplace” which is strongly against in the ERPNext development path.
As my post here ERPNext 14... What would you like to see? - #34 by rahy the incorporation of apps should be decided, otherwise it will be confusing. And contribution to the core will be low.
Anyway, I see that this discussion has deviate from the original topic.
“Marketplace” denotes buying and selling. That is not what we mean here .
The apps wil not be for sale.
Like I said something like this already exists in the frappecloud where certain curated apps are available for one click installation by the subscribers.
We are already there by default.
Regards
1 Like
My mention of “marketplace” doesn’t necessary for monetary buying and selling, but rather demand and supply.
I mentioned it because the vision of monolithic development adopted by ERPnext should mean everything is inside or built in the core.
Many (offered and requested) custom apps especially for the core functionality should be avoided.
Don’t get me wrong… I support this custom app way of development. But sometimes the phrase “…please contribute…” should extend to providing these custom apps.
There’s no mention of a marketplace in anything I said. I don’t see it suggested by anyone else either.
1 Like
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.
BKM
2 Likes
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.
This was mentioned in my post here ERPNext 14... What would you like to see? - #34 by rahy
There is monolith way and there is platform way.
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.
Got it! 
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.
BKM
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.
5 Likes
This deserves more than one upvote
Well said
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.
#POSAwesome
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.
4 Likes
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.
Screenshot 2021-07-13 at 1.14.50 PM
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.
Thanks Umair
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.
Regards
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.
That’s great news. Will check ot