Thank you everyone for your consideration and comments.
Some of the queries were related to audit. We already have a “Version” system to keep track of changes, so that will stay. You can always restrict “Revert” permissions to new users.
Maybe we can keep both models, by adding a new level of permission called “Revert”, which will be like “Cancel” but does not demand downstream cancellations.
The immutable part is the General Ledger. When you cancel, the ledger will will not be deleted, but reverse entries will be added, so that should satisfy accounting audit requirements.
We can maintain a “Revision” property to track the revision number of say a quotation, and we can also show a preview of the previous version.
Again, please just make sure you’re consulting very, very carefully with experts in a variety of different accounting standards. This is important and fragile stuff. When I mention audit, it’s not merely a question of keeping the information in the system (via the GL or versions or anything else). Certain documents, most notably sales invoices, are required by many regulators to be immutable. In order to modify them, we’re required to go through a cancel and reissue cycle. Those cancelled invoices aren’t drafts; they’re a permanent part of our books, and for us to stay compliant they need to stay that way.
I’m all for a system that offers both Reverting/Revising and Cancelling, whether through different permissions or different parameters at the doctype-design level.
My 5 cents…if people want to have the master version without suffixes, why not just reverse the current state, that is, cancelled document gets -1 prefix and master stays without doc. number change.
You have change control and the same number, win win
PS: I also would like to keep versioning it is very important for audit control.
Even though I assume the commitment made in the link Topic to some sort of LTS (as I understand it) may be good news to quite some members of the entire ERPNext ecosystem, I don’t think it automatically means we can can just go on with a change like the one being discussed here unless we accept this may mean the ones who can not live with a Cancellation Workflow as proposed in the initial post of this Topic just to have more time to migrate to a different ERP System (or find a way to adopt to the unwanted change nevertheless).
But from what I read in all comments here thus far there seem to be sufficient ideas on how to create something that may satisfy the members preferring the status quo in cancellation policies. And I think it’s worth to take on the effort of finding such a solution.
@rmehta The dependency on the downstream documents provides a very strong data integrity foundation. From a timeline perspective, all the dependent (downstream) documents have been created based on the original document’s data. If we allow the original document to be edited/reverted, then it renders the dependent documents invalid. In my opinion, allowing a submitted document to be edited or reverted without downstream cancellations will create data-integrity loopholes.
There are lots of examples like @adityaduggal mentioned where data integrity can be compromised if the proposed feature is allowed. Few examples are the integrity between -
And, how about having a flag on each transaction indicating that an (any) upstream document has been “reverted” so that it’s quite visible.
Having Revert is a very good solution from my point of view, it allows to manage the data migration and also have a way to not cancel downstream documents.
There could be in future flags in the company setups / system settings that disable the revert facility altogether.
The only problem is to have an additional code set that need maintenance, which in a way becomes a distinct point when compared with other ERPs.
Downstream documents are those that are created after a document in question.
For example, Stock Entry is a downstream document to a Material Request. Same goes with Purchase Receipt which is a downstream document to Purchase Order.
I think this would be the best approach. Let the system admin have the right to decide which role (if any at all) should have ‘Revert’ rights for which document. This looks like something that could cause significant data integrity issues if not managed properly so I think it’s important to put the decision in the hands of the user
For something like a sales invoice, what’s important about immutability is that cancelled records remain in the system in ways that unambiguously reflect their cancelled status. They need to be distinguishable from drafts, and in most cases they need to retain their unique number.
Having a separate “revert” workflow and a “cancel” workflow would serve that end, because than a sysadmin could just prevent revert entirely (if required) via the permissions system.
As far as I know, SAP has 3 different cancellation process
no cancellation status for master data such as material(item), customer and vendor, on one hand, some master data field can not be changed anymore if it is used by open transactions, for example material master’s valuation class(mapped to general ledger account) can not be changed if the material is used by open PO,Sales order or has on-hand stock. on the other hand, some field can be changed even though there is open transaction, because it has been copied to the transaction when the master data is used/linked when transaction is created, in this case, the update of master data will not auto refresh the open transaction, the user need to manually update the relevant field in the transaction if needed.
No cancellation status for non booking(material and accounting movement) relevant transactions like PO, work order, sales order etc, if there is down stream transactions linked to the relevant item, there is validation check to make sure the changed quantity will be less than the received/delivered/invoice quantity, the price is normally can not be changed anymore, when there is no downstream transaction, both quantity and price can be changed, if price and quantity change crossed the predefined approval threshold, the document status changed back to block status, need to be released again before the down stream transaction can be carried out. for sales order, if saved and order number assigned, the order item can not be deleted anymore, instead there is a rejection reason field, by which user can assign different reason to indicate this item is not needed, it is a kind of soft deletion flag.
booking related transaction which will auto generate the material movement and/or accounting document, such as purchase receipt, sales delivery, vendor invoice, customer invoice, once submitted and relevant booking document(material and accounting document) posted, no change can be make, it is needed to cancel/reverse the transaction which will create the corresponding reversal transaction with negative quantity/amount.
there is special period lock control on material document and accounting document, normally the previous period is locked, so the material and accounting document not in the current active period can not be cancelled anymore. if unlocked the previous period and cancel the document in the previous period, there will be only the reversal document created, no delete and recreate the subsequent documents like ERPNext.
for all changes, there is change history saved on each transaction, this is the most important audit trial.
so SAP is somewhat considered a very strictly controlled system, normally it can be drilled down/ traced back to individual transaction and together with the change history.
Well, you might need to clarify your definition of ‘immutability’. The ERPNext system as it currently stands doesn’t have transaction immutability because we’re still able to make all traces of a transaction disappear by Cancelling and Deleting. Thankfully though we’re expecting real immutability to ship with V12. Pls see thread below for reference:
If your concern however is about the ‘Revert’ option being a threat to immutability when it does come in V12 then there’s no need to worry at all
Immutability is more about the ledger than the doc itself. Reverting creates reverse ledger entries as opposed to deleting the existing ones which is in line with the philosophy of immutability
For ease of reference, the team has suggested an option of adding a ‘Revision’ property to the DocType which will basically serve the same purpose as the current suffix naming system. This means when a document gets Reverted once for example, there’ll be a number 1 in the ‘Revision’ field. If it gets Reverted three times, there’ll be a figure 3 in the ‘Revision’ field
When there’s a figure in the ‘Revision’ field, you should be able to inspect the audit trail by simply clicking on the ‘View => Accounting Ledger’ button. This should bring up all ledger entries for the document including the reversals
…indeed some hot stuff and serous debates lately…
It was long on my wishlist to have and easier and more user friendly way to handle mistakes in a workflow…But reading all comments I do realize the consequences…
Why do people want such feature…Most likely because it is annoying wehen one small typing error results in a lot of upstream or downstream processing.
I believe we should diffentiate between 2 types of corrections: not critical (change in date, mode of payment, name of suplier/customer…etc) and those that involves the item list and have serous repecusions on Gl and Inventory…
If small and stupid mistakes can be repared (thus change after submit) that do not affect the up and downstream I believe many frustrations are already covered…
For the more complex changes…involving Items, Taxes, Inventory, GL, manuafaturing…Well, what can be done by a human can also be done by a machine>>>1) show the user all related tables and ask wether the modification should be passed to all related tables…
And let the software carefully analyse if any serious issues would occur eg in availabitity of materials and the like…
This sollution would not need the change of fundamental changes such as the removal of “Cancel” For audit purposes the original documents would be copied with code-1 as suggested sevral times already…(the opposite of the current,where the origical becomes xxx-1)
This is very true, though we can’t dismiss document immutability entirely. A system that doesn’t allow for documents to exist in a “cancelled” state would be incompatible with at least a few major accounting standards.
Hmmm… good point but I think the suggestion by the team to add ability to see a Preview of the doc in its previous state(s) should take care of this requirement… yes?
The other thing would be to completely remove the outright delete option and probably replace it with some sort of soft delete that transits a doc from ‘Draft’ to ‘Deleted’ status but keeps the record on the system (similar to Cancelling)
Some of the specifics of the proposal are not yet clear to me, but to follow the law I need to be able to print on demand every single invoice that has ever been issued, regardless of whether it’s active or cancelled, numbered sequentially. In other words, having an explicit and visible “canceled” state for invoices is fundamental.
I suggest rather than changing the cancellation flow, let create an option in settings to allow cancellation or not. This way, users who depend on dependence for verification and checking purposes and those who do not can still use the system.
I’m not sure what implications it will be for the entire system when this is implemented to v12… but I think, my approach may have a lesser impact on the upgrade…
I suggest, during the cancellation, instead of adding the -1 , -2 suffix to the newly created document, we don’t do that on the new document, but add the suffix to cancelled document instead? Don’t you think this is would make it more backwards compatible to previous versions?
We’re actually thinking of making such modifications on version 11 and version 10, if this is acceptable, we can contribute the codebase back for v12
We’re actually plagued by the current system where they could alter the doc name and put a -1 on it, this is especially unacceptable when we name documents using their Fully Qualified Business Name, For instance when a company is called “So and So Pvt Ltd” , using this to name the document would turn it into “So and So Pvt Ltd-1” when it is amended, we’d still like to name the document with their full name, without the -1, but like to retain the past revisions… The problem here is, the -1 would not only appear on the document name, it would appear on the link field used to refer back to it as well.
i think, if we reverse this process, it would allow retention of past revisions/audit trail, and the name of the finally submitted document would not have a -1 suffix to it, which is the main issue contributor to propose such changes.
