There’s a deleted documents list. If we could get the deleted document as we view a regular one but with a deleted flag visible then it would be fine. Today we just see a JSON.
Deleted documents can be deleted …after which …they are gone
Yeah. We need a soft delete mechanism (using a deleted flag) and then remove the ability to delete.
The changes are piling on now but probably interesting to have a field in the doctype definition that indicates of a doctype should soft-delete (update a flag) or hard-delete (completely removed from the table row)
How about if the deleted document audit trail is left behind, will it be sufficient for audit purposes.
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.
As a general comment, not everyone needs to move to the latest and greatest: A general comment on versions, design and architecture changes
3 Likes
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.
5 Likes
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.
1 Like
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.
5 Likes
@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 -
- Purchase Order (PO) and Purchase Receipt (PR)
- PO, PR and Purchase Invoice
- Material Request & Stock Entry
- Sales Order and Work Order
- Sales Order and Sales Invoice
- Invoice and Payment entry
Kirthi
4 Likes
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.
I feel the term “downstream” being used quite a lot in this Topic. Can someone explain what it exactly means in this context?
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.
1 Like
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
Kind regards,
Won’t having both the options make the records not immutable?
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.
6 Likes
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
Hope this helps clarify things
Cheers
1 Like
…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)
see also Allow on Submit
rgds
2 Likes
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.