From Cancelled to Draft by sql is it wrong

Hi Friends
I wonder what can go wrong if i make Sales Invoice or other doctypes docstate change by sql from 2 to 0 ?

Is “Amend” not an option? Do you mean programatically or in the UI?

@tmatteson i mean frappe.db.sql code that hits the docname and change docstatus = 0
amend is not the option since amend will create a different naming series … and i want the same series to be edit

is it going to affect the system integrity … i don’t want to do it then discover it damage the system at any how , we are using 500 thousands of recoreds to each doctype so it will be bad if something go wrong after this implementation to the code

Yes, very much so. So much so that I would advise you not to do it, at least in a vacuum. Can you describe the use case for why this works for your implementation?

@tmatteson my client want to edit a sumbited form ? So he canceled and amend it and the new one with different naming series-1 , we want the same submitted series to be editable!
What bad effects and how does it triggers

hi, I don’t know if it helps, but do you know you can make some field editable after document was submitted? you can change it in Customize Form checked Allow on Submit

there is an alternate you can use, after canceling that entry, you can delete it and import it through excel. with same entry name.

and in your case, i believe changing canceled doc to draft will also work fine. but legally, it’s not recommended.

1 Like

The concerns generally follow three lines:

  1. Downstream effects: if you change the sales order, what does that do the invoices, delivery notes, dependent purchase orders, etc. You have a mismatch in the docflow, that may not have existed before and doesn’t really represent the process as well as cancel and amend
  2. Legal issues: in some countries documents are not deletable because you’re opening yourself to fines at audit. ERPNext enforces this with the Nepal and France localizations and those two won’t be the last.
  3. The third concern is a more general question: if this is going to be a normal workflow, is this client really committed to the data entry requirements of an ERP? Unfortunately @NMyshuk Natalia’s suggestion will look like it works in the UI, but it bypasses some important on_submit methods, including posting to the general ledger. Every ERP is a garbage-in, garbage-out piece of software and you’re at risk of breaking more things by shortcutting your workflow.

Also, if this is more of a historical cleanup issue, then I think you’re fine as long as no records end up going missing. If that’s the case, @adnan’s suggestion is a good one.

1 Like