Temporary sales invoice number before submit

I come from Oracle Application (eBusiness Suite) world and I see a missing feature when creating a sales invoice.

To avoid numbering holes Oracle Ebusiness Suite provide a temprorary sequence number as invoice number until this invoice is submitted, then it takes the final invoice number with the right sequence.

I think we can use this workflow :

  • When creating a new sales invoice : set a temporary sequence number which can contain holes
  • When Sales invoice is submitted : replace the temporary invoice number with the right sequence number

With this, when we delete a draft invoice we don’t have any holes in the numbering sequence.

Do you see any issue to implement this workflow ?



What use would this temporary number be?

ErpNext keeps “draft” versions of your documents. If you create a document and don’t save, then you can always revisit this.

Try this.

  • Create a new sales invoice but do not save
  • Navigate to other pages
  • In the search bar, type "New Sales "…
  • You will see your invoice there, You can navigate to the document and complete the document.

NOTE: You will lose the changes if you “Reload” the application from the menu.

Coming back to the sequence. It is normally a mandatory legal requirement that invoice numbers are sequential with no gaps. Creating temporary numbers may cause issues with conforming to that requirement. Alternatively, we need to maintain two sequences for a single document, which may come with it’s own set of problems.

1 Like

You’re right @crafter and i’m doing this now to avoid this issue.

Validated invoice numbers must not contains holes, not draft invoices.
So I don’t see any legal issue.
The real issue is for the renaming if we have link the draft invoice with multiple documents like email, comments, quotation, sales orders

I’m agree with 2 numbering sequencing, one for drafts and one (or many) for submitted.

With multiple users it’s happening like this :

  • user1 create an invoice and save it (because it’s the end of his workday) → invoice_num : 0001
  • user2 create an invoice and save it and submit it → invoice_num : 0002
  • user1 see an error and delete his draft : unvoice_num 0001 is lost, we have created a hole

Draft invoice which can be deleted should not have a final invoice numbering, don’t you think ?


1 Like

There is an option of choosing naming series. Make 2 types of naming series. User can choose draft invoice series to make invoice. And then choose the main series before submitting. You can try it out. Am not sure of the result as it hasn’t been tested.

1 Like

Yes we can choose naming series before save, but we cannot update it after.
The key proposition is to set naming series number after submit and not on creation.

So do you think my proposition is right or not ?

I can code it and I need a feature like this to avoid the holes numbering issue.



in table sales invoice the column name is the primary key, all links to this table are build using this column, accordingly permanent sales invoice number (gapless number) will be added as an information only for the document, used in search, print, but not linking. what is your thoughts?

1 Like

This is a very important feature. In my country, Mauritius, the invoices obligatorily have to be in numerical order. If it’s not the case, the tax office will start investigating.

I really hope this feature gets implemented.

It seems this feature is needed more than I thought.

So the only solution to avoid massive renaming through multiple tables (a very bad idea)
My proposition : create a new column “legal_num” to store the legal numbering and keep the current invoice_num as primary key.
The legal_num should be used by default for printing in countries which need it.

What happens if you need to cancel an invoice in Mauritius ?

an update
Re: [frappe/erpnext] [Feature Request] Possibility of skipped invoice numbers (#8765)

as per Rushab, This has been fixed with Immutable Ledger #18740

1 Like

Merged in develop so only for v13.
It seems to set a good practice to never delete gl entries but reverse it on cancellation.

We cancel the invoice and note it down. We’ll need to show that the refunds were made etc. But having draft invoices take up the numbering scheme will be dubious.

I’ve yet to test the latest commit which is supposed to fix it.

It doesn’t appear to be fixed on the latest develop branch. I just tested by creating Invoice A draft, creating Invoice B and submitting it, then deleting Invoice A draft. You end up with a hole in the invoice sequence.

Please update issue with your comments, it’s important.


Already did :slight_smile:

1 Like

I am very new to ERPNext programming. I have done some work around for this issue and updated it. I am not sure there are better way to work around this. Any comment welcome.


1 Like

I think Dokos which is based on ERPNext did this by setting a temporary naming series for the draft document and only use the desired naming series on submission. The developer is a member of the Forum @chdecultot.

I’m also new to Frappe and ERPNext and I couldn’t find what they changed to get that result.

In the Dokos version, when you create a draft sale invoice it is named (b69c16989c) for example and when you submit it it becomes ACC-SINV-2022-00004.

Oh thanks so much. I really think this is a very big issue that make many people worry about using ERPNext.

I will try to see how it works in Dokos, and will propose a PR to ERPNext.

I use a series called proforma invoice which is different than regular one. When I receive the payment, I would cancel this invoice and amend to change the series and re-submit. This way I am able to run all reports like receivable summary and take followup on payments.

I searched in the commits but I couldn’t figure it out. If you manage to find something please inform us.

I use a series called proforma invoice which is different than regular one. When I receive the payment, I would cancel this invoice and amend to change the series and re-submit. This way I am able to run all reports like receivable summary and take followup on payments.

We are aware of that possibility but Dokos version of ERPNext do it automatically. And that adds a layer of complexity to the end user.