Erpnext: [Proposal] Immutable Ledger

[rmehta]

Discussion

In most accounting systems, the ledger is immutable. If a cancellation or adjustment has to be made, it has to be as a new entry that reverses or changes the impact of a previous entry.

Here are some problems related to this:

• Forward posting is computationally expensive.
• In stock, where valuation is based on First-in-first-out (FIFO), the entire sequence gets regenerated, upsetting valuations and profits for all subsequent transactions.
• Taxes calculated and paid for a period may also get changed.
• Making changes back in time can lead to unexpected consequences

In ERPNext we have allowed back dated entries that forward updates balances and resets FIFO stacks and this is a bad practice. We should fix this so that forward dated ledgers are allowed.

Design

• All transactions will be sequenced as per the creation timestamp
• Posting date will be the "period" in which the ledger will be posted.

Changes

• [ ] In financial statements, show balances as per posting date
• [ ] Change all sequencing queries from (posting_date, posting_time) to creation in stock and general ledger.
• [ ] Don't change FIFO stack of queries already posted.
  
  
  
  • [ ] Remove future re-posting
  
  
• [ ] In financial statements, calculate balances based on posting_date
  
  
  
  • [ ] Trial Balance
  
  
  • [ ] Profit and Loss
  
  
  • [ ] Balance Sheet
  
  
  • [ ] Cash Flow Statement
  
  

[ghost]

I am learning/using ERPNext to capture a legacy/old system into a new system.
The ability to back date items as I catch up old data, while also using current data, is a major draw card. Would this still be possible in the proposed system?
(I do realise that it is temporary, and that once the legacy data is in, there will be no need for this, but for users that are moving over to ERPNext from other systems, I think it would be much more difficult without this ability).

[addymuliady]

Transaction Date and Posting Date, what will be the difference?

[MaxMorais]

@addymuliady Transaction Date, is the phisical date of the transaction, while "Posting Date" is the date when the transaction entered on your records.

For Sample:

On Supplier, issue on Invoice for you into 10-jan-2018 - This is the transaction date
Due some reason you receive the invoice and goods on 20-jan-2018 - This is the posting date, because is when you have knowledgment about the goods, and register this into your books.

[chdecultot]

Hi @rmehta,

My apologies for tagging you on this issue but is it possible to know what is the decision taken regarding this particular enhancement ? Have you decided to drop it or is it just postponed to a future date ?
(My personal view is that it is a very important enhancement for ERPNext)

[rmehta]

Already on @nabinhait's list once we are through v-11! Help us with code reviews and bug fixes in v-11 so we can come to this faster 😉

[chdecultot]

Thank you very much for your answer. It is a great news !
Sure I'm testing v11 everyday and pushing correction PRs whenever I find a bug.

[racitup]

@rmehta In my opinion this is a no-brainer. I didn't even conceive that any accounting system would/could/should rewrite history. General Ledgers are there to echo the days when everything was written in a real ledger book, and you wouldn't go back through the book rewriting all the lines when you found a mistake.
Which version is this now planned for? I notice the version-12 label has been removed.

[nabinhait]

This is a breaking change, it will go into version 13

[nabinhait]

https://github.com/frappe/erpnext/pull/18740

[raveslave]

Please consider making all of ERPNext use an immutable journal. It's fast, offers full history for any type of document / user-action. Even if data is deleted from a ledger, the change history (when needed) can still be accessed. This type of database is obviously also easier to scale/distribute.

Accounting and Stock is of course where it makes the most sense, but also consider the sales flow, orders, payments, banking records, assets.