The above point is where I really require clarification. Is the GL still immutable if you allow back dated entries? What would then be the point of the whole exercise? Under what conditions would you bypass the immutability of the Ledger?
Just in case you’re wondering, I am definitely in support of immutability because I know it is the recommended standard practice in accounting and honestly, it significantly improves the reliability of the system not to talk of the bug (as disclosed by @nabinhait) which leaves our Stock Ledger perpetually inaccurate when using FIFO
Having said all this, I’m however a bit concerned, just like several others, about the impact this would have on the end-users. If I correctly understand the earlier explanations from the ERPNext team, we would still have the reports showing ‘amended’ transactions (similar to what we have now) when we run them using the ‘Transaction Date’. Using the Posting Date however would show a report of entries according to their order of creation
At this point, I think the naming convention requires some clarifications too as it might be causing some confusion. Since Posting Date is generally understood as the date when the transactions impact the Ledgers, I think we should keep it this way instead of using the term Transaction Date. For the date when the entry is made, we can consider keeping this simply as ‘Entry Date’
So for every transaction, we have:
Posting Date: Date when the Ledgers are impacted (Can be amended as required)
Entry Date: Date when the entry is Created (Can not be changed)
Therefore, immutable ledgers (from a user’s perspective) simply means that the Ledgers will now be generated using Entry Date rather than Posting Date in order to avoid frequent recalculations and other compliance issues. Also, Cancelling a document will work just like doing a return. There will however be the ability for us to still view reports according to Posting Date (as we have it currently)
If all the foregoing is correct, then there’s not much impact on the end-user as long as the logic for validating transactions is also based on Posting Date and not Entry Date
@nabinhait could you please confirm the above statement regarding logic for validation of transactions?
EDIT: The more I look at this, the clearer it becomes (I think). Going from the very definition of Posting Date above, I now understand better why the ERPNext team chose their initial naming convention. If the Posting Date is actually agreed as the date when the transaction impacts the ledger then it means Posting Date = Entry Date because that’s when it actually impacts the ledgers under the new proposed system
The Transaction Date would then refer to the date when the actual transaction took place. If I’m getting this correctly then the initial use of Posting Date and Transaction Date by the ERPNext team is actually the correct way to go under the new proposed system!