Philosophy, Ethics, Real Time Inventory and Immutable Ledgers

1

[Disclaimer: I am not a fan of long posts, but to quote Mark Twain, if I had more time I would have written a shorter one]

There has been a lot of discussion around immutable ledgers, and how they specifically stop users post back dated entries. These entries potentially change the FIFO queue and can completely change the timelines, accounts and balances. In v13, we took the decision to stop editing stock value so that we don’t disturb the timeline.

Problems with Mutable Timelines and Ledgers

If I were a manager, I would not want my team to post back dated entries because:

  1. Increase in chances of fraud and malpractice.
  2. Lack of incentive to post entries in real time.
  3. Lack of real time inventory leads to:
    1. Bad purchasing decisions
    2. Surprising stock-outs
    3. Excess inventory
  4. Poor quality of MIS.

From an software POV

  1. Back dated entries are computationally expensive
  2. Hard to investigate because previous queues are “overwritten” when a back dated entry is made.

Learn from Mistakes

A system that make it hard to make back dated decisions forces the user to do it correctly the next time. There is a concept in education where you don’t give an “eraser” to the learner, so the learner

  1. Learns to accept mistakes
  2. Understands the true cost of mistakes
  3. Expensive mistakes lead to faster behavioral correction
  4. Learns that mistakes can’t be hidden

This is the decision in front of us. The goal of an ERP (or any) software is to make the life better of the user. Back-dated entries are a bad thing, and they have to be hard.

Ethics

The counter view is of course, you let the user decide. Who are you to judge on a good practice? If the user wants to make back dated entries, it is their problem.

Great products make the life of users better. I strongly feel that not having real time inventory data leads to poor decision making and wastage. ERPNext should not encourage users to follow such bad practices.

Correct data and Real time inventory is 90% of the value of using a perpetual inventory system in the first place. If you want to just count, then use periodic inventory!

Users (some?) may initially complain but learn to work around the system by making temporary inwards (a conscious decision to acknowledge a missing entry) and then move on in the forward direction. It is not impossible but a bit hard. This will ensure that the real time inventory is captured for better decision making. It will make companies much better. Isn’t this why you use software in the first place?

As software designers, what are the ethics around making such decisions?

I am strongly in favor of a system that allows real time inventory only. What are your thoughts?

Edit: The current implementation in v13 allows the following

  1. Accounting entries can be posted in any period on any date
  2. Stock entries can be cancelled, but the reversal will be in the forward direction.

This should ensure that from an accounting POV, there is no real impact other than ledgers not being deleted.

3 Likes
2

20 years of working. 80% including big companies always encounter the needs to do back dated xxx. From my view point, system is perfect but human are not. And system must allow human to correct their mistake. The reality part is few ten thousands penalties fine are not issue for big companies but few hundreds dollars fine is really hurt for small company and not fair for employer just because of mistakes from employees.

1 Like
3

IMHO post dated re calculation must be there. I have saw cases including good old navision erp.

Joke: if your employer is north Korea president and v13 is not able to back date re calculation…

1 Like
4

I believe it would be great if, under some set of permissions, some admin level could be able to “Approve” back dated entries.

It can guide any sort of company to use it in the best-case scenario and also allow the process of changing without break some process or information.

Is like loose weight… day by day!

1 Like
5

Good thoughts @rmehta. Firstly - its good to hear from you and the rest of the design team on the philosophy / direction of ERPNext. Currently - it seems next-gen features and direction / reasoning are known only to a handful - I think this is wonderful step in right direction. Hopefully many more…

  • The main issue for us with immutable ledgers is when we have to do year end closing for tax returns. If we cannot back date entries - the system will be stuck with an incorrect number on Dec 31(say) and the system numbers will never tie up with the auditors numbers - which are also confirmed later. The whole purpose of an electronic system is so that we can rely on it instead of referring to paper trail - and having ERP represent the real status (whether updated real time or a few days later) is the prime reason to use it.

The concern for us is not as much fraud - as there are other ways to detect them - the sales ledger, the purchase ledger, etc - all can highlight missing inventory. For invoices it is ok to NOT allow cancellation and deletion of invoices - issue credit notes instead.

Lastly for a small business like ours - our server is under utilized and the extra cost of computation (if any) is negligible compared to the cost of hiring staff to update ERP in real time…

I would strongly urge you to revisit the philosophy of forcing all users to use immutable ledgers. I think one size shoe cannot fit all businesses and if it is easy to implement a check mark type optionality - we should seriously consider it…

Thank you again for taking the time to share your thoughts.

2 Likes
6

First, thank you so much for Frappe and ERPNext. Amazing.

There are some business cases backdating may be necessary. For example, travelling salesmen or collectors to go out and return and submit their Sales Invoices for data entry. The second salesman’s invoices may not be accepted because his set of invoices contain dates before the first Salesman

I see business cases where this is a regular monthly thing. Like once or twice a month, a professional accountant comes in and reviews everything before the report is submitted to government authorities. He or she cancels and amends the entries if necessary. He may also insert some backdated accrual reversals that may be missed by the staff.

2 Likes
7

@rmehta @Joseph_Marie_Alba1

  • Immutablity - as in once posted cannot be deleted is different than ability to back date transactions.
  • Perpetual inventory is different than REAL TIME inventory.

Back dating should be allowed (with a check mark setting) until a period closing voucher is entered. Immutability of documents is not excluded in doing so…

1 Like
9

Despite being a small company we support immutability for stock entries. Notice did not say immutable ledger. Some things in that implementation which would seem logical to us and would make its incorporation to our business possible despite extra work in edge cases/errors:

  • clearly separate transactions that should affect stock amounts from those that should affect stock value amounts.
  • allow stock transactions that do not affect stock value amount at any date
  • allow stock transactions that do affect stock value amount retroactive to date and time immediately after the last transaction for that item that affects value
  • never allow cancellation of submitted transactions that affect value, make user create their own reversal entries subject to time and date limitations above as best meets each case

As an example:

  • Jan 1 receive from supplier shipment with quantities of item A and item B. This purchase receipt affects qty AND value.
  • Multiple stock transfers of Item A and B in Jan and Feb. These do NOT affect value
  • Delivery Note for some of Item A Feb 15. This affects quantity AND value
  • Delivery Note for some of Item B Mar 15. This affects quantity AND value

On April 15:

  • can enter transactions do not affect value like stock transfers for ANY date before or after April 15.
  • can enter transactions that DO affect value like delivery notes from Feb 16 for item A and from Mar 16 for Item B
  • if negative quantity not allowed and if inventory is FIFO can enter new Purchase Receipts for item A and B with ANY date including before Jan 1.

Thus there is flexibility in back dating up to the time and date that would require recalculation of already posted transactions. If using batches or serial number in effect have specific ID and all above applies to each specific ID allowing more flexibility without any risk of recalculation, fraud, etc.

We are definitely NOT real time in inventory so have to be able to back date transactions a few days to match reality. Common case is wrong receipt of items noticed on first dispatch. Ideally we could cancel that receipt as the items have had no subsequent transactions, but at worst we should be able to do new transaction reversing and new transaction correctly receiving on the date of original mistaken receipt even if in past.

Agree 100% with:
Immutablity - as in once posted cannot be deleted (OR CANCELED) is different than ability to NOT back date transactions.

Thank you for great program and maintaining an active community

2 Likes
10

Continuing with your train of thought - a ledger can be rendered immutable manually after a PCV or automatedly (with a checkmark) at end of specified time period - daily, weekly, monthly, etc…This would allow large companies the option of real time immutability of ledgers and small companies options to do so manually until a PCV is made…

Document level immutability (cannot delete or cancel - but can replace with another of same posting date) can be standard (until PCV). This discussion is a question of impact of posting date on ledger.

1 Like
14

@rmehta - philosophically this seems a serious enough issue for a lot of companies that would leave us struggling with decision to permanently stay on V12 or find other software that allows us to run business the way it should be. I am sure that everyone loves erpnext but for sure we cannot live with a ledger that is not in agreement with the reality on closing date. I am afraid that we could lose community members (think customers) due to the way this is being implemented. Is it difficult to implement an optional immutable ledger (for example with daily automated PCV )? Philosophically shouldnt accounting software adapt to business and not vice versa??.. why risk it then???

2 Likes
15

without breaking Accounting principles (which do not require real time inventory valuation or immutable ledger, or date sequential data entry)

1 Like
16

Probably, a better way is to simply stop recomputing the future stock values and allow the backdated FIFO costing to be naturally picked up by the next transaction.

1 Like
17

Thanks everyone for sharing your views. Unfortunately there is still some confusion on how this is implemented.

  1. Please note that you can still post accounting entries in previous periods, so there is nothing to stop you or the auditors from from making adjustments. So from an accounting / legal perspective there is no change. Except that ledgers will not be overwritten.
  2. Only the stock ledger cannot be posted beyond the last transaction.
  3. Cancellations for stock entries will work but the impact of cancellation happens in the forward direction only.

Can someone very briefly share a use case where you would want to rewrite the stock balances and a simple accounting adjustment will not work?

18

in make_reverse_gl_entries:

line 320-322:
        entry['remarks'] = "On cancellation of " + entry['voucher_no']
	entry['is_cancelled'] = 1
	entry['posting_date'] = today()    <----

def check_freezing_date(posting_date, adv_adj=False):
	"""
		Nobody can do GL Entries where posting date is before freezing date
		except authorized person
	"""
19

Hi @rmehta

I have been using V13 in a real life environment for the last 6 Weeks. This is a deliberate decision and we assumed the risks inherent in using a beta version.

Companies need to be able to post backdated stock transactions, especially the SME segment which has been your avowed target segment.

The reality is that there are too many scenarios where this will be necessary either as a deliberate action by the business or as a result of errors.

Do not go ahead with this implementation of immutable ledgers. Your market will kick against it strongly.

Olamide

5 Likes
20

Is it stock ledger or stock voucher / stock journal entry?

Stock entry means stock JE?

21

I would like to add to this discussion what I learned from another thread on what immutability means - as there could be confusion - as was the case for me… Very nice and timely summation / clarification posted by @peterg can be found at

The changes will be much less dramatic than people have sometimes thought. As I understand it (based on discussions here and the partial implementation in v13 beta):

  • The cancellation workflow is unchanged. You can still cancel if you wish, and you can still reverse an invoice with a credit note if you wish, your choice. The only thing you can’t do on an immutable ledger is delete cancelled documents.
  • The transaction date/posting date distinction will be made more consistent on the backend. Transaction date will represent when the business event happened, and posting date will represent when it was input to the system.
  • Backdated transaction dates will be allowed, but backdated posting dates will not. The only real implication here, as I understand it, is how this impacts stock valuation. This is, I believe, the sticking point.
  • Closing vouchers will serve to lock transaction date periods, same as now.

In other words, though a lot changes on the backend with (positive) implications for audit, the only real user-facing impact is in how stock valuation gets calculated on backdated transactions.

So it seems a lot of the fears around inability to back date transactions were misplaced - frankly including mine.

1 Like
22

Yes…
And I think we need to start separating between immutable and capability to backdate posting :slight_smile:

1 Like
23

Key for us is the definition of backdating. If backdating means no posting dates before today, that is a deal breaker. If backdating means no posting dates, before the last posting date for this item, that we would support.

Also,

I fail to see the difference between a cancellation and a deletion of something that occurred in the past with transactions dated after it. Both will change balances for subsequent dates that are in the past. If deletion is not allowed, cancellation should not be either

24

It seems the latter: you can backdate posting times as far as the last posting time for the item.

Cancelled documents still represent ledger entries…two sets, in fact: one creating the document and one cancelling it. It is informationally equivalent to a invoice → credit note workflow. If the cancelled document were deleted, the ledger entries would be orphaned.