Hi Experts,
We found you had been struggling with backdating transactions. In V13 you changed to the immutable ledger for solving this issue but we found another issue instead.
We tried to create backdate transaction in v13 and erpnext still recalculate all the stock valuations onwards.
It took a longer time than V12 to do the calculation. We couldn’t have a real-time balance value and accounting ledger.
Based on our experience using SAP B1, we have suggestions for your consideration.
SAP B1 has 2 dates : Posting Date (Transaction Date) and System Date (Creation Date).
.
The calculation stock value is always based on System Date. It doesn’t matter if the transaction is backdated or not, the stock valuation will be always moving forward. There’s no need to recalculate all the previous transactions.
.
As for the other one, the report above is based on the posting date (Transaction Date). It’s more like Erpnext’s stock ledger report. The difference as you can see, the backdated transaction does not affect item cost for other transactions which had been created before the backdated transaction itself. The new cost calculation would take effect as shown in the last row.
It would be best if you can implement this method to solve backdated transactions. Cheers!
4 Likes
How does calculating stock value based on system date make sense though from a valuation perspective? Doesn’t it make the valuation calculations between the system date and the posting date wrong then? (for backdated entries).
It doesn’t make the calculation wrong. Instead, it will make the system easier to calculate backdate transactions since stock value just moves forward. The transaction made in the past (after backdate posting) would not change its value, the system doesn’t have to recalculate all the accounting ledger for all the transactions afterward.
I mean, wouldn’t the other transactions between the backdated entry posting date and the next transaction (after said posting date) be incorrect? In the screenshot shared, I would be referring to line items 12-14:
I suppose if there are only a few transactions in between, this wouldn’t be a huge deal. But what if the backdated entry was several months back, and there were hundreds / thousands of transactions between the backdated entry’s posting date and the next transaction after said posting date?
It’s not a problem. Actually, this is the best method to calculate backdate. You have to see the other report as well. The calculation of the item cost will be based on the system date. Therefore, all transactions which you mention before in lines 12-14 will not be recalculated. They would still have the same item cost. So the system won’t calculate the transactions which already been submitted even if you input thousand of backdated transactions.
This would solve the problem in manufacture as well. What happens now in erpnext, say you create backdated purchase invoice, the system will calculate all the transactions after the posting date and create an additional difference account entry for manufacture transaction. The financial report would be moving and finance would have a hard time tracking down the details.
1 Like
Sounds logical and is a fair approach. If you have some more details such as SAP documentation around this, would be good.
@szufisher what’s your advise on this approach?
This speed issue with backdated entries is why our Erpnext implementation could not go through for a manufacturing concern.
I do hope that some core developers take notice.
1 Like
This is basically the misunderstanding of accounting principles of developers trained in engineering have when they do accounting or business software. They think that all transactions are the same and all have to be valuated at the point in time they are generated.
In accounting, journalization is point-in-time. That means that journal entries must reflect the exact date and time that the financial transaction was created.
However, ledgers (general ledgers, stock ledgers, inventory valuations) are generated on a periodic basis, based on accounting requirements. (Periodic reports can be monthly, and Annual reports are reckoned yearly.)
In SAP, all inventory valuations are considered “estimates”. It only becomes a final value when you POST a final ledger entry valuation. Therefore, all valuations can be reckoned on the PERIOD end and NOT on a per transaction basis.
This misunderstanding is the reason why ERPNext invested (wasted) so much effort on trying to have a perfect up to date inventory valuation on a per transaction basis leading to incorrect solutions like immutable ledger.
Also, auditors review the transaction records. Accounting allows adjusting entries to be made.
This suggestion is actually very correct based on accounting principles. (I already tried to explain the valuation principles several months ago in this forum.)
1 Like
I do think the current back date solution is too perfect, SAP approach like what @Joseph_Marie_Alba1 explained above is more realistic, my advice is at least we need to consider restrict the back date posting to only current and previous period, this way, the transaction volume and possible error will be manageable, also this will somehow enforce user to input data into system as soon as they are available.
Well managed system relies on both adequate system features and enforced business rules(on time and accurate data entry).
1 Like
Yes, I’d like to elaborate more if there are any inquiries. For the moment, I could share the documentation of item valuation in SAPB1. Please check the link below:
https://help.sap.com/doc/18be8e2f8ba447afb2e7694e141c5837/8.82/en-US/882_GL_B1_HTG_882_PerpInvent.pdf
Hello @szufisher , backdate posting is very useful. Restriction in backdate posting will cause more problems for users. I think the best solution for this backdate is following SAP logic, which is you need to separate stock value calculation using creation date (not posting date). Inventory value calculation will only keep forward even there are any backdate transactions. Hopefully, using this logic ERPNext could be still using backdate transactions while not causing any major problems and complex calculations.
@ankush @umair what do you think of this suggestion to take a more looser approach to backdated calcluations?
To clarify further, as long as the period has not been closed, journal entries dated any time within those open periods are allowed. So, you can enter last week’s entries or last month’s entries as long as the general ledgers have not been officially generated.
At the end of the period, you generate general ledgers from the journal entries. Then, you check if you are satisfied with your results. When you are good, you POST the journal entries into the general ledger. However, as long as you have not yet closed the period, you are still able to make new Journal entries within those open periods.
When you are truly sure of your entries, you CLOSE the period. This will be the official figures in the LEDGERS (usually in general ledger), and these are the ledger entries that should be officially immutable.
What ERPNext is doing is when you post a journal entry, the ledger becomes immutable. I would argue that this requirement makes the system virtually unusable to the majority of business enterprises in the real world since it does not conform to correct accounting practices.
Hi Joseph,
SAPB1 is also using immutable ledgers but they haven’t delete function. Any cancelation document will create a reverse journal entry. Journal entries that have been created cannot be recalculated. Thus, they don’t have computational problems like ERPNext.
