We are proposing a major change in the cancellation workflow. Currently, when a document is cancelled, its amendment is a new document (with a suffix -1). The major issue with this is that to cancel the document, we need to cancel all dependent documents.
What we are proposing is as follows:
When you cancel, the document goes back to Draft state. In case of GL Entry, new reverse entries will be created.
When the document is re-submitted, it will be the same document, but with new data.
The history can be found in the “Version” of that document. In case of accounting transactions, it will be found in the GL Entry table.
The “Cancelled” state in Frappe Framework will be deprecated.
We are proposing this change in Version 12.
The benefits are:
No need to cancel downstream documents
Number will not change (it is a legal requirement in certain regions).
We would love to know if you have any major problems with this new workflow, and how we can resolve them.
But what if the objective is to cancel the document with no intention of resubmitting it? It should not be proper to keep it in a permanent state of draft.
And if the option is to delete the draft, it takes the document totally out of the list view, this might not be desirable for control purposes.
Can we not have a direct ammend option that takes the state from submitted to draft while still keeping the cancel option for documents that require outright cancellation ?
Wooahh…this is a big statement…I am still not out of shock from yesterday’s news and you hit the community with this proposal…what I can see a lot of issues in migration and a lot of bugs especially when it comes to OLD DATA, especially with those using the erpnext and frappe framework since a long time.
So I have a major objection to this since downstream is a very good thing in one sense let me give you a scenario:
Sales Person books an order for a customer
Then after submission the production department makes a Production Order linked to that Sales Order
After a day or 2 there is a call from customer to the Sales Person to make some amendments to the Sales Orders.
The sales person logs into the system and tries to cancel the Sales Order but since its already linked to the Production Order it cannot be cancelled and hence no amendment can be made.
The above step is basically a check so that the person making the changes knows that the item is already in production and hence he first calls the production department to stop production or check if the item is not manufactured, if the item is not manufactured then he can get the PRD Order cancelled.
After cancelling the DOWNSTREAM documents he can happily make the changes to the Sales Orders.
This is the first use case that came to my mind after seeing your post in the very 1st minute apart from the shock feeling. I think if we allow cancellation without downstream check and put the SO directly in DRAFT mode then it is quite possible to bypass the production team and then we could have DIFFERENT specs in SO and manufactured item could be of different specs.
I hope the community would have many more issues like these, this is just one of them.
This is a very good change to remove the complexity… but I think the revised number is necessary… especially for Quality Management System requirements.
I agree with the proposal point 1-3, but have one suggestion for point 4.
Question: If the DocType is linked with other DocTypes other than GL Entry (Custom DocTypes for example) will it still be allowed to cancel and edit the new draft or not? If yes, than please see my below opinion.
Example case:
When a Sales Invoice is created and the data has been submitted, for customization service for some customers we tend to create custom DocTypes and fetch the invoices for further usage. If we cancel and the system only reverses the GL Entry and goes back to Draft, we will have a problem with the data already fetched in other custom DocTypes which will be different from the edited Sales Invoice and the user has to go and find out in the “Version” what has changed, which in my opinion will cause issues.
Proposed Solution:
If you take a look at Account Setting there is a function to Check if we want to unlink payment on cancellation of the Sales Invoice (see below image reference)
If can have such feature in the “Customize Form” or “Role Permission Manager” to be able to choose whether to Allow “Cancel and go to Draft” or “Cancel Only” maybe through a revised role permission that would be helpful for the user to choose which DocTypes are allow to edit and which ones not.
in my opinion this is not compliant with e.g. CFR regulation. The difference between version and revision (version beeing changes in a document before beeing released or submitted, and revision a subsequent edition of a previously valid document) should be very clear. Also, think of accounting in general: once a sales invoice is set valid, it must not be changed. Should it be changed, it has to be immediately clear from the document (i.e. print format), that it is a changed revision. In Europe, no company following common standards such as ISO 9001, EN 13485 or others will be able to use it (and this is the majority).
I understand the request for “simpler workflows”, but this should not be the standard. Having it as on option “disable revision control” in the global settings might be an option that satisfies this.
I really hate having to disagree again after the desktop discussion. Not trying to be antagonistic. But this change will directly conflict with ISO9001 requirements for Sales & Purchase orders. I have to look deeper, but this could be a major problem, as ISO 9001 is used around the world.
This problem is also present in the ‘Update Items’ field in V11. I’m going to have to find a way to disable that in our ERP when we update.
Edit: @lasalesi has it exactly right in his reply.
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.
