I have functional Supply chain background and I was SME to design an opensource ERP for GOV org. Cancellation was complex subject I agree.
But my learned lesson cancellation process impact is more business decision.
Also it’s case per case we cannot do something generic applicable every where.
For example cancel a PO can take many form, is it submitted to vendor, is it received totally or partially, is there any invoice matched and so on. Also what we want to achieve by initiating a cancellation is the main target to achieve according to me.
system should not allow breaking integration, reason of why an ERP is used, but it should protect this coherence of data.
another case, how you will cancel an inventory transaction, only we do a reverse transaction and it’s not doable if onhand already moved out of stock.
what I suggest, we can work on a list of doctype and assign ressources for each doctype to give a study on cancellation workflow.
I’ve emailed this thread to the Quality Assurance Manager at my company. Her reply:
Without reading every line of the guide, these are the areas that just jumped into my head to check…
Straight from the ISO 9001 text, section 7.5.3.2c:
“For the control of documented information, the organization shall address the following activities, as applicable:
…c) control of changes (e.g. version control);
Documented information retained as evidence of conformity shall be protected from unintended alterations.”
And 8.2.4:
“The organization shall ensure that relevant documented information is amended, and that relevant persons are made aware of the hanged requirements, when the requirements for products and services are changed.”
And 8.3.6:
“The organization shall identify, review and control changes made during, or subsequent to, the design and development of products and services, to the extent necessary to ensure that there is no adverse impact on conformity requirements.
The organization shall retain documented information on:
a) design and development changes;
b) results of reviews;
c) authorization of changes;
d) actions taken to prevent adverse impacts.”
And 8.5.6:
“The organization shall retain documented information describing the results of the review of changes, the person(s) authorizing the change, and any necessary action arising from the review.”
Cutting the amendment process would/could cut out these sections of document traceability
If the delete option for the document sent back-to-draft is not allowed, then we have a good history track and we can always refer to those changes.
Currently once a draft document is deleted, then all traces of it are gone. That won’t be good for a submitted document to loose trace while having the dependent objects still existing.
The change is otherwise expected to bring in lot more flexibility in the system, specially when I see the Salary Structure → Salary Assignment → Payroll Entry → Salary Slip like dependency and you want to now change Salary Structure.
My company is audited in both Nepal and the United States, and this change would make ERPNext unusable in both countries. Keeping a record of cancelled vouchers is a basic tenet of every accounting standard I have ever encountered. Before you implement this change, make sure you’ve consulted with a wide range of audit experts. The effects will be massive.
(That said, I do understand the motivations for this change, but I suspect there are other, more compliant ways to achieve it. Why not just roll cancel+amend into a single step, such that linked documents don’t have to be canceled too but merely rolled over to the newly amended version?)
Welcome to the Implementation world. Looks like you are grappling with the conflicting requirements of control and flexibility that Indian customers seem to clamour for. You talk control - they want flexibility. You provide flexibility and they demand control.
Having to cancel all downstream documents is an excellent control. However some documents need a hard control. Like between a PO and a PREC or a Sales Order and a Delivery Note. Then there are other documents like making a payment, where it is not catastrophic to have such flexibility.
So, maybe we can come up with a Control Matrix of documents and decide where it can be allowed and where it can’t. And keep the current schema for documents that need a hard link. But allow the new schema where documents need soft links. But then implementing it may become too tedious.
But if I (on behalf of my installed base) have to choose between the existing configuration and the proposed configuration, I’d pick the existing configuration meaning No, please don’t.
However, if we can build a toggle in an appropriate settings page and the organizations can chose to have the existing configuration or move to the proposed configuration, it would be perfect.
Getting a document back to the same number is a hack that I’ve published a couple of years ago and here’s the link:
I would echo most of the comments here especially @JayRam.
Certain doctypes may be ok with removing revisions, but others would be a big no no.
For example: we use the Quotations and if the customer requests a change in the Quote then we amend and work with version -1 if the quote which is then sent to the customer. If revisions are removed, then there is no way to discriminate one quote and an earlier version. This would cause many, many problems. Certain doctypes may not experience a problem with revisions but some such as Quotations will certainly do.
I have always argued that the ability to edit a document, a PO, or a SO, and others, was possible. So I really like the idea of doing it this simple way.
I think audit trails need to exist to support this change. Thus, all changes (always allowed via User Permissions) would be saved (perhaps one way to improve this is to create audit reports per item if they do not already exist), and the editing process, regardless of when it is before or after would be facilitated.
Cancel, in my opinion, should have some changes. Before Submitting, it could stay as it is. After Submission, some approval should be required, and still, keeping all the data, recording them into some canceled document report, with all necessary audit tracking.
This would please companies and countries that have quality audit, accounting, financial, and other requirements, by keeping all the data and users that interacted with the document, and users and managers, who would have a simpler and more flexible process, without lose control.
To extend the concept, we should probably have an attribute on DocType definitions called “immutable”. If checked, then a submitted instance of this DocType cannot be cancelled but must implement a method that updates the document in the desired way. For example, a journal entry wouldn’t be able to be cancelled but might have a reverse button that, when clicked, would post a new document containing the a journal with reversed entries and then update the original journal with a reference to the reversal journal and an indicator that indicates it’s been reversed.
If the immutable field is not checked, then cancellation behaves in the manner you’ve described and didn’t rename the document when saved again.
You could cancel the original quote at which point it would go into draft status, then duplicate it and then delete it. Although I guess the link between the two would be lost.
If there are downstream objects them is the responsibility of the developer to make sure the cancellation is prevented until downstream documents are cancelled.
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.
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)
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 -
