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
I’m thinking we do pseudo Perpetual Inventory where Perpetual Inventory is turned off, but the Current Assets , are booked once a day through a Batch Job based on the Stock Movement for the day. This should be good enough for most organizations. Organizations that need this batch job to run more frequently (say hourly) should be able to set that in a configuration setting.
Thanks
Jay
can you share more details? thanks.
So during the day your inventory values are “wrong” 
And from midnight to the next day, stock has the correct values.
And once someone moves some stock again it is wrong. So what is the point?
Accuracy is expensive. Accuracy once a day when everyone is sleeping : Is that accuracy?
I am not sure if reservation concept exist in ERPNext or not, but I see a solution on that if implemented.
High level concept:
As far as I know this is a missing feature.
May I share a link to SAP Business One on how they treat perpetual inventory costing. It may give our community some ideas on what we can do to make ERPNext inventory better.
Let’s take this example:
I bought a wonderful Ferrari, and its color is bright yellow, it has a great engine and it is very fast and eye-catching, but for me it has a small flaw which is that the audio system is bad, here I have three solutions:
The first and simplest solution is to replace the audio system with another one that suits me
The second solution is to replace the car with another car that has a better sound system
The third solution is to contact the manufacturer and help make the audio system in all their cars better
For me, I tried the first solution because I love this car, it has a great engine, and I do not have time to communicate with the factory to improve the audio system and go through complicated and long procedures
For you, you can help me improve the new audio system or help the factory…
This logic applies to most cases here, we can always contribute to the core or create additions to avoid these small flaws
Greetings
In the discussions around the immutable ledger problem, many of these same questions came up. There, the solution was to create a new Item Valuation Repost doctype, which represents deferred recalculations of stock value, set to take place at some point in the future.
This approach is an attempt at compromise, running computationally cheap stock level updates in real time and computationally expensive valuation updates asynchronously. The downside is that your COGS isn’t going to be always up-to-date, but at least you can quickly see which item valuations are ‘dirty’ and due for update (and, presumably, run those updates when you need to generate a report.)
Would generalizing that system to all transactions (and not just backdated ones) be a reasonable solution here? I don’t have a lot of hands on experience with the stock module, but to my inexperience eye it seems like a solution might be already near at hand.
The discussion I think involves two different values.
On the POS side, the primary concern is available Qty. Does the location (in ERPNext - Warehouse) have available qty to sell? POS ideally wants Qty to be exact / online all the time. A related question would be, if a qty in the warehouse is not available, is there any other location (warehouse) that the company has with Item Qty?
POS does not really care about cost immediately. Cost can be calculated later.
The problem is, ERPNext perpetual inventory places Qty and Cost in a single calculation mode.
Qty needs to be Transactional (OLTP), but Cost could be analytically computed later (OLAP).
It would be good if ERPNext can place Qty and Cost on different tracks. Compute stock qty immediately with the transactions, but make computation of Cost as a scheduled job which can be recalculated later.
That’s exactly what the Item Valuation Repost doctype I just mentioned does.
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.
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
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.