It is possible for the Date of the Cancelled Document and the Cancellation Date (set Today) to belong to different periods.
You should really reread Nabinâs explanation of the posting date/transaction date distinction. It clarifies all these issues.
1 Like
One outcome is that we will fix is cancellation so it is on the original date. I think @Deepesh_Garg will make a fix next week.
Only thing we are stopping from backdating is stock transactions because of its compounding effect on subsequent transactions. Overwriting timelines is bad from a software design perspective too.
Request people to make shorter posts so the discussion is more participative!
Any other âblockingâ problem?
1 Like
Is backdating also disallowed for periodic inventory?
Clarification - again - I thought we could backdate transaction dates but posting date will be entry date. So NO backdated (transaction date) delivery notes? Also document immutability requires that invoice cannot be cancelled - it must be credited. Are we permitting cancellation?
What is on the table for discussion? Are we open to revamping ERPNext (example posting to journal entry as suggested) or this discussion is limited to immutability within the current ERPNext setup? Just seeking clarification on the scopeâŚ
As part of an organization using ERPNext (hosted on erpnext.com), we donât really have an option when it comes to this (immutable stock ledgers) as it would be done as part of an upgrade. But, I would like to add my opinion:
- Not having to create backdated (backdated beyond an old transaction of same item/RM) is definitely an ideal situation. We would expect all operations to reflect physical movement (and that is definitely immutable sequence). So, theorectically, the immutableness of stock ledger sounds logical.
- But, practically there are some situations where backdated entries need to be done. For example, during the COVID time, as there was severe staff shortage, we had to complete some deliveries without proper entries (Purchase Receipt => Manufacturing => Delivery cycle). Now, in case Delivery date is locked (export/tax regulations), our stock In (Purchase Receipt) and Out (Delivery) too has to be date locked (read, backdated).
If we sincerely analyze all our operational situations, in 90% of the cases the onus lies on timely entries. If I donât make excuses of being small organization with limited staff, I think I can safely say that immutable stock ledgers would be not a big issue. But, that is again ideal world.
But, a toggle would definitely put it there with âbest-of-both-worlds-categoryâ. Or, maybe restricting the backdate to be within a financial quarter (based on financial year definition). That might limit a lot of impact.
I realize that this has been in discussion for multiple years. And team would have invested sweat to get this to a stage to be broadcasted as being part of v13. And, a software always has some limitations - we have to learn to live with that.
So, basically a torn-in-both-direction opinion from me.
1 Like
I have at least 5 years of navision and 4 years of adempiere / idempiere. Am implementing erpnext for current company operations. This immutable will be disaster based on my experience. Anyway software is yours. If it risks my career or job I will have to find other solution.
Good luck.
1 Like
ERPNext has very powerful code. I like the simplicity and power of ERPNext as it stands on solid Frappe. ERPNext has a core team who controls the commits, manages the timelines, and documents the software with Online Manuals and Youtube Videos, and Webinars. It also has a respectful and helpful forum. ERPNext community is on a journey.
In practical terms, what would the negative impact of an immutable ledger be for you in this context? Even if your deliveries have posting dates in August, they can still have transaction dates back in July.
Isnât posting date the transaction date?
No, thatâs the whole point. Like I said before, you should really reread Nabinâs explanation of the posting date/transaction date distinction. It clarifies all these issues.
Thereâre many scenarios that require backdated stock entries⌠We have to look from end users business perspective, not from tech stuffs which is the users donât care too much
This immutable forces the users to always bring forward all cancellations/adjustments onlyâŚin other wordsâŚthey should have final audited stock balances ( or letâs assume 80-90% valid) before using erpnext.
Thereâre many other casesâŚthey do adjustment for many reasons like taxes, internal purpose etcâŚsystem should not lock down it⌠bringing adjustment forward only is not acceptable. They are the users and the data are theirs. Let the users themselves decide in flexible way whether theyâre capable enough to use this feature. And based on real experienceâŚeven not many enterprises can adopt this properly⌠backdated is required. tracking/versioning is already there for user admin for audit purpose
It doesnât make sense even for enterprisesâŚthey do adjustment/correction here and there most of the time for many internal reasons.
Iâm in the opinionâŚWe cannot force user to go with erp align with current date in every situation. System should be flexible enough and put them (end-users) in control.
Thanks
User-perspective means transaction dates, and backdated transaction dates are allowed. Can you be specific about a scenario where a user needs backdated posting dates too?
what if the scenario e.g. tax purpose report per last year requires user to backdated adjust stock balance value? is it possible? The adjustment is posted forward per current posting date, right? Immutable doesnât allow to adjust posting date of backdated value/qtyâŚ
the reason behind may vary e.g. previously the value is incorrect but adjustment comes todayâŚsome users cannot accept the adjustment is brought forward only.
Why not using Stock Reconciliation for stock adjutment made on back date?
Maybe making new purpose in the list as âStock Adjustmentâ that can similarly do like Stock Reconciliation. The difference is this adjustment can be done anytime while the reconciliation only at year end.
Yes, a stock adjustment for last year can have a backdated transaction date, as can any journal entry that might be needed to help recalculate valuation. I know I keep posting this, but I think it clears up a lot of misconceptions about what an immutable ledger actually means:
@peterg
The situation here became something like this. Let me assume a product P being sold, made of R1, R2 Raw Material:
- In May month, we had to manufacture a certain quantity of P. For that, we had received R1 and R2 in April - which we couldnât enter into stock because of some government restriction (lack of staff). Then, by end of may the Product P was shipped out of our warehouse. All the while, the in-house staff did all physical movement - minus ERPNext movement.
- In June, more R1/R2 arrived - they were ordered in March. At that time, the staff made PR on those. But, the PR of previously received R1/R2 (in may) was never entered until end of June.
We cannot simply shift the delivery date of P (or, actually, SI) because of taxation laws.
So, in effect, sitting in June, we had to make old entries on R1/R2/P into our stocks - all the while there were already entries of R1 and R2 in month of June.
In the hindsight, the solution is simple - donât enter new entries until old are entered. But, practically that means âwait fairly long to assure date orderingâ - which is quite a big constraints for small organization which run on staff doubling their responsibilities of data entry and actual work.
Hi Shreyansh,
Right, so a Purchase Request was missed. It should have been entered on May 10th, but only on June 20th was it realized to be missing. Maybe even the Purchase Order/Invoice were missing, too. So, in June, you make a backdated stock entry with the format:
Posting date (no backdating allowed): June 20
Transaction date (backdating fine): May 10
Your stock levels, though wrong for more than a month, will be correct going forward, and your reports will include the event on May 10th. If you use perpetual inventory, the system will create a GL Entry on the same dates, as well. In other words, thereâs nothing stopping you from posting Mayâs entries in June (even after delivery). The only thing youâre prevented from doing is pretending that they actually were posted in May.
Would that workflow present you with trouble?
(There is one actually messy part here, related to how FIFO valuation queues get calculated on backdating, but thatâs a somewhat different issue.)
1 Like
Your point is valid - if there were a way to differentiate between posting and transaction dates - that might not have created a problem for me in this scenario (or even other similar situations).
Even though the link that you had added above did talk about such an distinction, the original post (here) talks about restricting transaction (here I assume transaction dates) prior to last transaction (in my sample case, June).
Back dated entries that affect the Stock Ledger will be allowed only after the last stock transactionâs posting time which means there will be no need of any reposting of future transactions.
Am I mistaken or reading wrong?
The computational expensive part being described is related to valuation queues, and in @nabinhait âs explanation those valuation queues are tied specifically to posting date. Likewise, I interpret the post youâve linked to be referring to posting rather than transaction date. In a few other places, as well, the devs have said that the limits on backdating will apply to posting dates and not transaction dates.
The language is inherently a bit confusing, though, so some clarification about current technical plans would definitely be valuable.