Item Ledger would be an awesome option indeed.
For posting purposes we may have Transaction Batches’ Structure which will lead to more security and flexible user matrix along with posting rights, approvals & reviews.
Just my two cents: most accounting packages I have used have immutable ledgers. Corrections done after the fact are created and posted after the fact. While I definitely understand that some folks get used to having the “Flexibility” to go back in the ledger, if ERPNext wants to become a larger player in the field and attract larger clients, then immutable ledgers are a must. But like everything it’s give and take… As for me I do not see the immutable ledger as an impediment but as a security feature and a good accounting practices.
6 Likes
I totally agree with the comments stating that this feature will only give additional credibility to ERPNext in the accounting field. It’s a must have if we want to be able to be IFRS compliant soon.
I personally don’t see it as a problem for people who don’t want to loose flexibility: it doesn’t prevent you from creating entries after the fact, it just helps preventing you from cooking your books.
In a world oriented more and more towards fraud prevention, I don’t think ERPNext can afford the luxury to be insecure from that point of view.
14 Likes
I believe flexibility is required where in this can be a setting at the admin level. I personally know that this change would cause a serious adoption issue at least for a large number of SMEs in India. I second Jayrams and Sathisha’s comments.
3 Likes
Thanks everyone for your comments!
There is a major misconception that back dated entries will not be allowed. They will be allowed, but just on the current timestamp.
Please read this statement, and let me know if this works for most cases:
Period closing (TB/BS/PL) reports will be based on “Transaction Date” which can be back-dated. But balance (account, stock, valuation, profit) on a particular date will be based on “Posting Date” which will not change.
Requesting @nabinhait to list down a few scenarios and compare how they will be handled in the current system v/s the proposed system.
9 Likes
This might be a great idea to put in “immutability” but in the end this ERP is meant for small business that go from excel to an accounting package that can also do some great stuff like CRM, Inventory etc.
Closing periods, Revaluation … Seems so complex that this proposed change will exclude small business owners out of any simple accounting conversation. [can’t follow anymore] and will become an accounting package for fortune 500 type of companies.
Most of us are not F500 type of companies. Can’t afford a full time accountant.
Again, ERPNext is a great productivity tool with decent accounting. Not a compliance tool. Although it’s current record level user permission allows some very fine grain control of what users can do.
Imagine a small business doing monthly close, quarterly close and yearly close… It will be a nightmare.
There are tools like HFM, EPM… that can provide consolidated reporting for compliance.
Alternatively
-
some how if we could have 2 set of books : statutory and transaction. One for super duper compliance and one for simple people.
-
make it optional / system level or company code level.
3 Likes
Not sure if ERPnext is looking to get Fortune 500 signed up to use the accounting package.
It is meant to be Simple.
For people wanting to go from Excel (what Compliance?) to something that gives productivity.
If anyone uses it to run a 500 people company in this, that is an exception not the average size of business (5-10 users, 50 employees) that adopts ERPnext.
Nitty gritty complexities a few people want will make things complex for 90% of us.
2 Likes
Great discussion with lot of insights. I will certainly wait for @nabinhait usecases, but I am sure the proposed method won’t work for us. To take a step back, I can clearly see the reasoning shifting from performance to statutory compliance/financial integrity. So we have two orthogonal usecases to support
- Immutable ledgers for big customers who care about compliancy
- Current approach for small customers who want the flexibility currently offered
It would be ideal if we can support both usecases with minimal changes. So wondering whether it is completely off the table from implementation perspective. All that we need to support (1) is make ‘edit posting date’ impossible. Can we still get the certification by keeping it not editable by default, but allowing it via some high level Account setting like ‘perpetual/periodic inventory’ or through a custom app?
2 Likes
In this post, I will try to explain what we are currently doing, the drawback and advantages of that method. At the same time, what changes we are proposing and implication of that.
Let’s take following entries to explain our scenario.
Stock Valuation Method: FIFO
Fiscal Year Records:
Stock Ledger Entry
Accounting GL Entries
Now, let’s say, we do a back-dated incoming entry on 15-02-2016 for the same item with 4 qty at $1100.
Currently, based on the back-dated entries, system reposts FIFO Queue and recalculate balance qty and Valuation Rate for all the future entries. In this process, as valuation rate rate changes, it also affects existing accounting entries. So, we delete existing GL Entries and reposts Gl Entries where necessary.
So, after reposting it will look like this:
Updated Stock Ledger Entries (SLE)
Updated GL Entries (GLE)
So, you can see system reposted both SLE and GLE for all the future stock transactions. The same kind of reposting happens if we simply cancel/amend any back dated entries.
But currently, what system does not handle correctly is the “Stock Transfer” Entry on 01-03-2017. It was transfer of 2 qty between from WH1 to WH2. And here, before back-dated entry, system takes incoming rate as 1200 which was based on FIFO Queue on WH1. But if you look closely, after back dated entry, while reposting system did not reset the incoming rate of item on WH2, as per new FIFO Queue. As per current FIFO Queue rate should be 1100. But system did not correct it and hence valuation rate of WH2 remained incorrect. This bug is still there inside the system.
The problem to fix the bug is, if we change the incoming rate of WH2, we have to repost all the future stock transactions of WH2 as well. And in that process, we can find more transfer entries, and hence more reposting. We can also find transfer from WH2 to WH1, which needs reposting of WH1 again. So, there is no end of reposting.
Also, you may also already noticed that, we have changed SLE and GLE of last financial year. It is currently possible even if there are Period Closing Voucher has been entered for the last year.
We also deletes GL entries on cancellation of any accounting transaction, which should be done as per IFRS.
Apart from deleting GLE, we also update some values on GLE while doing payment reconciliation or advance adjustment on invoices, which is not desirable.
New Proposal (Immutable Ledger):
As per the new proposal, there will be 2 date fields in all transactions.
Posting Date: SLE / GLE Date (will always be posted on current date)
Transaction Date: When actual transaction takes place and can be back-dated.
These dates will also be part of every SLE and GLE.
So, in case of the above example of back-dated entry,
Posting date will be 01-12-2017 and Transaction Date will be 15-02-2016
And after the post SLE and GLE will look like following.
Stock Ledger Entries
GL Entries
So, here you can see, as the posting date is on current date, there will be no reposting of earlier stock transactions which has been made after 15-02-2016.
Similarly, if we cancel any back-dated entry, system will not delete existing SLE / GLE of that transactions (as it currently does). Instead, it will post reverse entries on current date (posting date), transaction date will be past date for the reverse entry.
We will be able to see all the accounting / stock reports based on both Transaction and Posting Date.
Note: I don’t have all the answers about the implementation, this is still in active discussion/design phase.
25 Likes
That is perhaps not at all scary as I have thought originally.
I think this is key to the end user. Could you please answer this specific usecase? I forgot to add a purchase invoice dated 01-11-2017. I came to know about that today(01-12-2017) while adding the production entry for a transaction dated 28-11-2017(which was delayed by 3 days). So went ahead and added the missing purchase invoice for 01-11-2017. Now, would the system allow me to create the stock entry for 28-11-2017 as the missing invoice was adding today with transaction date of 01-11-2017? If it allows, I don’t really see any difference as an end user. What was posting date earlier simply becomes transaction date with new implementation. Posting date never changes, so I don’t really need to see that in any form.
1 Like
This is a great explanation.
Indeed not as scary as it originally seemed (like spoojary said) 
I am assuming, here you are facing insufficient stock while making the stock entry.
As the posting date of the purchase invoice (incoming stock transaction) is 01-12-2017, the updated stock will be available on this date only. Hence, I guess you have to post the production stock entry as on 01-12-2017 (with transaction date 28-11-2017).
Thanks @nabinhait. You are right. The production entry failed due to insufficient stock. The new approach will allow entering the missed out invoice with a old transaction date. However for the stock purpose it still uses the posting date, not transaction date. That is completely wrong from stock balance perspective. I will be allowed to create the production entry because it does the same mistake twice!
I understand existing implementation has a flaw wrt how it handles back dated entries. However the proposed mechanism is also going to be faulty one as it uses posting date for calculating the stock/account balance. We are doing more work to replace one defect with another. Is it really worth the effort? I am not really sure.
As per the new design, I think reports of stock balance would be available both by transaction date & posting date, I think that would serve the purpose of your requirement.
What we need is core logic using the transaction date instead of posting date, like production entry checking the stock balance at a particular transaction date, rather than posting date. Posting date doesn’t really mean much for account/stock balances.
I believe every transaction already has a ‘creation’ timestamp. We could simply rename ‘posting_date’ as ‘transaction_date’ and consider ‘creation’ date as posting_date. With that approach, if we simply disable editing transaction date, we get ‘immutable Ledger’, don’t we?
As Nabin has explained in his post and as I understand things with my limited knowledge of ERP, immutability would not allow deletion of past entries or tampering them. It is not just a question of making a field read only.
1 Like
Sorry, I wasn’t right. Immutable ledger and the flexibility of back dated entries doesn’t seem go very well together. However, some of the common usecases like the one I gave above is likely to work, though for wrong reasons. That certainly makes me less paranoid with this change. Before doing this work, it might be good to ask people to list out the usecases that might break with this change. That usecase list will perhaps help make a data driven decision about the implications of this change.
I have started with my useacse at Immutable Ledger - implications - Google Sheets. I would suggest building this list, so that @nabinhait can asses the impact of this change before implementing it.
Hi all,
Great topic!!
Reading all the comments here I think many have different views as what ‘immutable’ is, but correct me if im wrong - the reason we are discussing this is because of the costing issue and back dating transactions – FIFO, No?
If so, why not look at a costing model that is more flexible, accurate and less expensive from a computational point of view.
I would love to open this discussion and if not as soon as im more proficient with the inner working of ERPNext I will be contributing it to the core.
Few things I agree with when it comes to immutable ledgers – having a closing option will help greatly in minimising errors and audits are easier to perform.
I don’t think having a posting date and transaction date as different dates is a good idea - they should always be the same in my opinion. My understanding of posting date is that it’s the date the financial transaction is recording in your ledger which is the truth of your business. All documents should be able to confirm this truth and during audits the auditors will check this. Having different dates will raise questions.
I did not want to make this post long with going into more details into the costing model so if the community wants we can expand on the ‘LOT’ costing model that we use at our business that uses an Enterprise version of and ERP system. Using this system for over 12 years I think it can be improved on from our learnings and make it even better for ERPNext.
Would love to share more but in the past my posts have not got much interest cause maybe I think it was not seen as a need or solving any problem…but I think under this topic it will have great merit.
Will wait for your interests.
Regards
Hemant
2 Likes
I would like to point out that none of this stuff is ERPNext specific or created in a vacuum. Inventory costing can be done either FIFO, LIFO(not implemented here) and weighted average… So what constitutes a “More Flexible Costing option” @hpema108? These are well known and accepted accounting practices
With that being said, I do agree @hpema108 that we have to be careful about transaction date and posting date. All Accounting reports should always look at the posting date as the effective date of the transaction. Think about it this way, pretend you did you accounting and inventory in those old fashioned paper books and you made a mistake 3 months a ago… what do you do? Stuff an entry at the beginning of the journal and modify every subsequent entries after that up to current? Or you enter a correcting entry at the end of the journal? it’s the same principle. If I make a mistake 3 month ago, and I then fix it with an adjustment, if I run the report as of 3 month ago the mistake will show and if I run the same report as of now if will be fixed…
Unless I am missing something I think recalculating the Inventory Costing is very very dangerous, so is reporting on Transaction date vs posting date. ERPNext is really good at what it does and I think we need to embrace standard accounting practices and implement in flexible and user friendly way. At the end of the day I want to trust my books and I want to do my taxes without having to second guess myself
4 Likes