Maybe a checkbox in setting can toggle this functionality to allow back dated.
Or a role to allow this functionality.
So for example, the business owner can do daily transactions and maybe make mistakes. At the end period, the ‘rented’ accountant can activate this functionality and correct the mistakes.
In my opinion, especially for SMEs, the tracking of the correction made (and who does it) is more important than not allowing to make mistakes.
It’s a nightmare if backdated not allowed for SMEs as they do backdated most of the time…I would suggest this as an system setting option.
This immutable ledger is more fit for enterprises who willing to comply accounting standards
Let’s clear the misconceptions:
I need clarification as I must explain this to a prospect currently.
What happens during a new implementation where backlogs of stock transactions (for previous months in the financial year) must be captured in the system?
Hi Rushabh,
Is there any automation for this? Doing it manually may present an area of confusion for many users. I think when we try to post a backdated Stock Transaction, there should be a modal that says something like…
“Backdated transactions not allowed for Items xxxx, yyyy, zzzz. Stock movement will be posted on current date and Journal Entry will be auto created to move impact to transaction date. To proceed, click Yes or Cancel to manually adjust Posting Time”
Not sure if Cancellations (as we currently know it) are still allowed in V13 but if so, the Journal Entries will need to be auto deleted if the Stock Transaction is Cancelled. I would however expect that Cancellations in V13 will instead create a reverse entry (keeping in line with the concept of Immutable Ledgers) in which case, there’ll be no need for deletion
I would suggest that you strongly consider this before releasing the feature. It needs to be as ‘painless’ as possible 
Thanks
As per my understanding, we cannot do backdated stock transactions anymore… and I believe it will be painful for SME users…stock is the concern for them not accounting stuffs…
I agree immutable ledger is strongly needed for enterprise compliance…so there should be option for system manager to turn this on/off
Hello,
Our Scenario:
Purchase may not be immediately booked (invoice not received, or material not verified or invoice not verified or busy with another task). We do not have dedicated accountant, so purchases are booked as and when we get free. However, some item from this purchase may be delivered to customer to meet urgency. Happens 20-30% of the times.
It is practical, that there could be delay in booking entries.
With current implementation, we shall not be able to book transaction correctly to reflect our books. Also, if we book transaction on actual date of booking transaction, we may end up filling incorrect returns with tax authorities.
I am not against Immutable ledgers, but I am against implementation.
Proposed Solution:
Where Stock Entry and Journal Entry, both are affected from one doctype (e.g.: Purchase Invoice with Update Stock option), it should book backdated Journal entry as per document date and automatically forward post stock entry with a warning. Currently it is not allowing to book backdated purchase itself.
Edit:
Further, there may be stock reconciliations required for end of fiscal year. This should be one exception I feel were back dated stock entries should be allowed. Else, It would be difficult to disclose actual stock value and stock in books where this reconciliation entry is passed on a later date.
I agree immutable stock ledgers would be disaster for SME like ours. The issue is well pointed out earlier but I would add to it that there are many cases when ZERO valued stock entries are posted since the people doing stock entries are not aware about the stock values and neither are they concerned for this there needs to be Stock Reconciliation which is mainly for valuation purposes and it happens on backdated basis.
The erpnext team cannot expect every stock entry to have the correct valuation rate and what if the error is found after some time and then if we just want to do the stock reconciliation for the stock valuations in the back-dates I guess immutable sle would deny the same. This seems like a DEAL Breaker for most of the users especially those in SME sector since most of the times there are no dedicated person for such things in the organisation.
I’m currently assessing ERPNEXT for my business and think so far , its a great product. I’m in the final stages and really want to implement this product . I believe i would re-consider if the system don’t allow back-dating of stock. It is quit crucial for , i think most businesses to back-date stock transactions and get an actual correct stock valuation based on this.
I would propose the user to have an option in the system to allow proper back-dating of stock transactions , whether reconciliations ,or purchase orders back-logs etc… ,with
quantity and cost. It will just give ERPNEXT an advantage over other systems in the market. ’
To erase a feature that most users find crucial in an ERP system , just don’t add up. Rather give them the option to activate or disable the feature.
Hope this will be considered , as it is crucial to listen to user feedback, for any ERP system be successful and to properly consider the impact of major system changes .
Regards
Just to add to the points where the team has made the system so flexible that even in v13 we have the option for negative stock as shown below:
So my question is how does the people doing accounting on erpnext would manage their stock suppose they have checked allow negative stock and then they plan to make the stock entries for fulfilment later as is the case in most SMEs.
I guess that immutable Stock Ledger would defeat the whole purpose of allowing negative stock since you cannot go to govt authorities with Negative stock ledger values as I think it might even be illegal in some countries to have negative stock balances.
Promblem regarding cancellation:
The new GLE or SLE created by the cancellation entry is dated on the date of cancellation.
But this new entry DOES NOT have any “originating” journal entry or stock entry supporting it.
Also, the first GLE or SLE generated by the journal entry no longer has the originating journal entry to support it is it got cancelled.
This has the effect of “inventing” ghost GLE and SLE (Ledger entries) without any journal entry supporting ledger entries.
To correct way to do this is, in order to cancel Stock Entry (Journal), we MUST NOT cancel the original entry. Instead, we must create a reversing Stock Entry dated today for the stock we want to cancel. This way, ALL supporting journal entries are maintained.
So, with immutable ledgers, we can say NO CANCELLATIONs are allowed with stock entries. All stake holders must be super careful about dates. A single manual error in the dates can mess up the entire Inventory system.
I haven’t looked to closely at the back end of this, but I don’t see any reason that these have to be ghost entries. The originating Entry is the document that was at one time created and then later cancelled. When Entries are cancelled, they don’t disappear. They’re still part of the permanent record in the company’s accounting.
Deepesh_Garg:
On cancellation of any transaction instead of deleting the General Ledger Entry(GLE) or Stock Ledger Entry(SLE) a new GLE or SLE will be posted on the date of cancellation that will reverse the impact of that transaction.
In accounting, we have journal entries to record transactions. When journal entries are posted (in ERPNext - submitted), a set of General Ledger entries are generated for the purpose of generating reports like Trial Balance, Balance Sheet, Income Statement, etc.
Previously, when Journal Entries are cancelled, the corresponding General Ledger Entries are also cancelled. When you amend the Journal Entries, a new set of corresponding General Ledger Entries are generated. So, there is a one-to-one mapping between Journal Entry (in our case Stock Entry) to the General Ledger Entry.
Now, with immutable ledger, when you cancel a Stock Entry, the General (Stock) Ledger entries that were generated when we submitted (posted) the Stock Entry are not cancelled. Instead, a new set of General (Stock) Ledger with TODAY’S date is generated to reverse the previous General Ledger Entries.
So, what we have now is One Cancelled Journal Entry (meaning - no longer valid), and yet we have two sets of existing General Ledger entries with no Journal (Stock) Entry to stand on for support. The original set of General Ledger Entries no longer has the Journal Entry since it has been cancelled, and the New set of General Ledger entries with Today’s date appears out of nowhere without a Journal Entry with the Today’s date.
This is why, if we want to implement Immutable Ledger entries, the present procedure of generating Ledger entries for cancelled entries seems dubious.
It is better to know outright with immutable ledgers, CANCELLED ENTRIES are not possible.
Also, you wlil discover the unpleasant surprise that you cannot Amend the cancelled entry because it pre-dates the General Ledger entries generated for the cancellation. You will get Backdated error.
This is where we interpret things differently. You understand “Cancelled” to mean “No longer valid”. I understand it to mean “Created and subsequently reversed”.
Sorry, you do not get what I mean.
You must consider the RELATIONSHIP between the JOURNAL ENTRY with its GENERAL LEDGER entry (system generated upon posting or submit).
In this implementation, what we have is a Journal Entry MARKED cancelled. And yet you have two sets of GENERAL LEDGER entries.
The auditor will ask you, WHERE did this General Ledger entry come from? (pointing to the first set),.
What do you do? point to a Journal Entry marked cancelled?
Then the auditor will ask you, WHERE did this General Ledger entry come from? (pointing to the second set generated when you cancelled the journal entry).
What do you do? point to the cancelled journal entry again? Then, the auditor will demand… This General Ledger posting DOES NOT even have the same date as the Journal Entry you are pointing at!
So, in this immutable ledger implementation, Users must be warned outright that they cannot cancel any Stock Entry.
Yes, exactly.
No, not in the posting date of the document, but the date of cancellation is marked immutably in the document’s timeline (not to mention the general ledger itself). The information is there.
I understand what you want: you want a 1-to-1 relationship between Entries and Ledgers. That’s not a requirement of my accounting standard, but if it is for yours you can already do it. Just turn off cancel permissions on all relevant documents. Then, if you need to reverse something, you can create a reversal Entry exactly like you’re describing.
Ok thanks.
The one thing is, Once cancelled, you cannot amend the transaction because of the Backdated requirement.
One thing that can be implemented is the Periodic Inventory Closing procedure.
At present, Inventory valuation is finalized, posted and sealed upon every Submit of a stock entry.
With Inventory Closing (Similar to Income / Expense period closing), this is done at the end of a Period (month-end/quarter-end/year-end).
Inventory valuation can be performed as a batch process for all stock entries based on their individual item inventory valuation (moving average, standard cost, Fifo, even Lifo).
The difference between the Posted ledger entries and the Inventory Valuation calculated by the Inventory Closing procedure will be posted as an Inventory Adjustment journal entry.
So, as long as the Inventory period has not been closed, Changes can be done to stock entries of Open inventory periods.
This is lifted from SAP:
You can cancel a delivery document, choosing the Data → Cancel or by choosing the same option in the context menu.
In this case, a new cancellation delivery document is opened, and both the inventory and the accounting transactions are reversed, once you add the cancelation delivery.
Use this option when you make a mistake creating the delivery document. For example, if you choose the wrong customer or item.
Alternatively, if items were delivered and sent back to you, create a return document based on the delivery to reverse all the transactions.
You cannot create an A/R invoice from a delivery that has been closed or canceled nor can you create another sales document with reference to the delivery. You can no longer make changes to the closed delivery either.
Since you can’t change or cancel a goods receipt PO, you can create a goods return document.
This validates my observation that rather than creating on-date general ledger entries, the correct approach is to create another cancel journal document, while also creating general ledger entry.
It can be seen that each cancellation action is SUPPORTED BY a cancel journal document, while the original journal is marked as cancelled.
