Trust you’re doing great and thanks for joining the conversation. The main purpose of the Posting Date is exactly the same as it’s always been… GL Entries! The Posting Date determines the order (and timestamp) of transactions in your Ledgers so it’s more than just a record of when the entry was created. Please also note that in ERPNext, the creation date refers to when the document was Saved on the system and not necessarily when it was Submitted (which is when the ledger postings occur)
Since the Posting Date will now be in chronological order (at the time of submitting the documents), it’s critical to have a field that let’s us know when this transaction actually took place (in case of back dated transactions). For example, If I’m just making a Journal Entry today for a transaction that actually happened yesterday, the Posting Date will be today but then I will enter the ‘Transaction Date’ as yesterday so that in my reports, I can view transactions and their impact in the actual order in which they occured
In all systems I have used, this was how the accounting system works and I think the sentiment is the same in the posts above.
You post all your transactions and then run depreciation, report and discuss results with management and decide if you need to make any changes (such as releasing accruals, overhead or recharging elements to other departments). Once agreed, you close the ledgers and no more back posting.
Stock cannot be back dated, which is why there is always a big push towards the end of the month to ensure all transactions are posted correctly and stock booked/issued correctly.
I think this will cause confusion having different dates for different elements. A consistent approach should be used, i.e. “transaction date” should be used for all reporting, TB/BS/PL/Account/Stock, Valuation, Profit etc…
I’ve read to the end post as of Feb, 2019 and am unsure if this was tackled or not.
If it has not been tackled, I may suggest re-thinking the implementation of the entire system. Switch this from “state” tables, to instead be an immutable list of changes (e.g. Event Sourcing). The system could be backed by EventStore or similar, and you have reliant audit-able data as part of the implementation without additional work. Technically, the storage for a system like this could be done using a WORM drive.
If you don’t really want to lose the ability to define a document type, re-think how you would store/retrieve/render the document. Can the document be a key/value store?
I’m no expert on Python, but am learning this in C# at the moment.
Yes, of course. Material transfer should not affect GL entries and it does not in erpnext as well. But still we need reposting of target warehouse because if valuation rate or FIFO queue has changed in source, it should also reflect valuation/FIFO queue of target warehouse (as we are maintaining separate FIFO queue per warehouse). And it should repost COGS booking in future dates from target warehouse.
Also, if valuation rate changed for raw materials, we should also repost valuation of FG item in case of a manufacturing stock entry. Otherwise, it will not reflect correct COGS booking for FG items when it will be delivered in future.
If we don’t maintain FIFO queue per warehouse, then it will be easier for reposting. Because in that case, we have to repost all future entries for that item irrespective of warehouse. And we need to maintain separate warehouse-wise total qty and overall total qty.
I know we always can ignore reposting valuation of all future entries in case of back-dated entry and can only correct qty on future dates. And at the end of the period, we can fix it based on Stock Reconciliation. But that is always there and it does not give correct data until the end of the period.
And in that case, there is no benefit of using perpetual inventory, it is almost similar to periodical inventory accounting.
The NetSuite and SAP both reposts costing on back dated entries based on background jobs. we are also thinking to do the same.
ERPNext gives provision to create separate accounting ledger for each warehouse. And hence, even if it is a stock transfer entry, still if accounting ledger are different for source and target warehouse, we have to post GL entries (even though it does not affect COGS).
Yes, in fact, this is the only way to assign an Asset Account Code to an Item. Item has default Expense Account provision, Income Account provision, but no Asset Account provision. So, if you want to different Items to different Account ledgers, you have to assign them to a pseudo Warehouse with the proper Account code for the Asset (inventory account).
But it does affect the Inventory valuation. For example, if you like to use a certain Cost Value for a product in a certain warehouse, you can simply transfer the preceding Quantities to another warehouse. So, the FIFO of that warehouse will now fall to the desired value. It becomes like a song FIFO IN/FIFO OUT between warehouses to get desired cost values.
There are a lot of good points on this thread and must specifically second the incorrect handling from a business logic sense of stock transfers. In our multi-currency implementation, stock transfers appear to be causing discrepancies between the account value and the stock value. Need to investigate more, but if true makes no sense what so ever as virtually or physically assigning an asset to a different location does not change its value accounting wise in any way.
Similarly using different exchange rate in Purchase receipt versus purchase invoice creates a stock account entry. If allowed should be an exchange gain/loss not a stock discrepancy.
From the accounting perspective, Transfers within a business should not change Accounting Values, unless it is a Manufacturing Activity where inventory changes its nature (from Raw Materials → Work-in-Progress → Finished Goods, and incurs direct and indicrect manufacturing costs.
@nabinhait - I came across this thread after seeing another post from @rmehta on philosophical decision of immutable ledger.
Scanning through the posts here it seems immutable ledger implementation as discussed in 2017 means something else… It would be useful to repost a summary of what is being implemented:
Document immutability - cannot delete once submitted - can only be replaced with a credit note, etc. Assuming that is being implemented?
It seems this thread is discussing the use of another date - transaction date. To me the posting date is the transaction date and ERP already tracks submission date. So implementation involves calling submission date as posting date and posting date as transaction date?
Impact of back dated transactions? Permitted? If not permitted - then how to update period end reports with actual audited inventory and accountant / auditor required entries? If back dated transaction date permitted - what does immutability mean ? Are period end reports recalculated? Does that affect downstream calculations?
Role of periods / closing vouchers.
I am now confused after reading this as to what immutability means and what has been implemented in V13? I am sure the community will appreciate any clarification… Perhaps this is much ado about nothing…
Nabin posts a good explanation earlier in this thread (hard to find because it’s gotten huge!)
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. That parts messy, though, and it makes me wonder if separating stock valuation from the stock ledger might not be the cleanest way forward.
In that case, why not using Stock Adjustment document/doctype?
Basically, I’m against using different dating for the same purpose. As mentioned by other above, each date has its own purpose. And I think having Creation Date is enough as Posting Date. And a field for Transaction Date to represent the document’s date.
My long, more general, opinion is below:
The flow for money related items should be Document → Transaction → Statements.
The SO, PO, Invoices, Stock Movement, Productiion Order, etc. are all documents (even a JE voucher). These what user should be dealing with when using ERP. Documents are proof of transactions.
Then the money-related fields in the documents (depicting the transactions) should create JE as middleware to accounting. Then these JEs build up the statements (via GL, etc).
Hence, when user Cancel, they cancel the document (not the transaction). But since the document consist of transactions, the system should also grab the related (previous) JE and reverse it.
If not amended, this reversed JE should be posted to balance the corrected JE.
And when user Amend, the amended document is renumbered, and create new JE. Posted (when Submit) as new JE, relates to old JE by the amended document.
If required, Accountant can make change/adjustment directly via JE (not necessary creating new documents). If necessary only role of Accountant or Auditor can do this.
Immutability means what has been recorded (submitted) can’t be changed/deleted. Doesn’t mean locking up the documents.
The immutability of GL should mean user can’t make direct change to GL. It should be made via JE. And JE should be immutable also.
Immutable = permission is create but not delete or update.
This flow will make the Statements has GL as underlaying, GL has JE, JE has documents (or direct entry by Accountant). In-system document can have attached scanned paper document.
Drilling down can be done easily.
Now, in relation to backdated entry, user submit backdated document means the JE will be posted as backdated entry. In any system (manual or auto), it must be recalculated. Just because this will cost heavy power of calculation is not an excuse not to do so, let alone not allowing it.
The illegality of backdated is to post a transaction AS different date, not in posting it IN different date. Means posting a backdated transactions (including stocks) is still legal.
The ERPNext v13 immutability was triggered (primarily) by stock recalculation. In my opinion, this change in stock value can be handled by stock adjustment document.
Still in accord with my explanation above the backdated direct stock document should not be entered and posted as backdated stock. But entered as adjustment to stock.
The stock adjustment will create JE for the adjustment (qty and valuation). Then this adjustment is added or substracted the stock valuation in the respective period to create correct (adjusted) financial statements.
Both perpetual or periodical stock should allow this adjustment.
The same with other stock-related document like SO, PO, WH movement, would create JE for stock adjustment.
The illegality of not-correct stock at time is in not reporting it properly in the correct period. People will learn to record stock at the correct period because they wan to avoid this illegality, not because he can’t record it because the system not allowing him to do so.
In a glance to the explananation from @nabinhait I have feeling (don’t have time to find details) that this can happen. So one can increase the value of stocks by transfering from one Wh to another and again and again.
This is dangerous.
I dont know if related, but maybe this worth investigation
Stock Entry with Manufacture stock entry type may also be affected when backdated Stock entries insist on recalculating future stock transactions (from backdate to present).
At the time when Manufacture entry is submitted, the Raw Materials and Finished Goods are locked in. If recalculated, will the Manufacture values be changed?
It may be better to just place the backdated order on the queue and allow it to be picked up by the next transaction.