Erpnext: [Feature Request] Possibility of skipped invoice numbers

[danielcb]

We're currently evaluating erpnext as a ERP (mainly for invoicing at the moment) and I noticed a small issue regarding invoice numbers / naming schemes:

We are using the following naming scheme for invoices: INV.YYYY.MM.#####. Assuming I've two booked invoices and two in a draft state:
Booked: INV20170500001
Booked: INV20170500002
Draft1: INV20170500003
Draft2: INV20170500004

If someone books/confirms Draft 2 the system creates INV20170500004. After that someone finds an issue in Draft1 and deletes it there will be an invoice number missing (INV20170500003).

At least in Germany this can be an issue. My understanding is that while it's not wrong/illegal (the requirement is mainly a unique numbering scheme) it certainly will be a red flag for an accountant/auditor. Other systems only create a number if an invoice gets confirmed/booked. This also guarantees invoice numbers in a "correct" order.

[nick9822]

@danielcb
Instead of deleting you can cancel and amend invoice, so it will get revised.
Hope that helps.

You can post this on community forum at discuss.erpnext.com to get better insights.

[danielcb]

@nick9822 thanks for the quick follow up.

Yes, I've seen this, but its nonetheless possible to create "incomplete" invoice records this way. If the number would be assigned on confirmation this problem could be avoided completely. I've added it here since I thought it might end up in a backlog as enhancement somewhere. If the current solution is the preferred one, feel free to close this issue.

[tundebabzy]

Hi. I believe if there's any concern about maintaining the order of invoice numbers, the first thing to avoid is deleting invoices. Deleting invoices is also frowned at by auditors.

A work flow that avoids the need to delete invoices is to make use of sales orders. Once the details of the transaction have been confirmed, an invoice can be created from the finalized sales order.

I'm summary, ERPNext is flexible enough that with relevant controls in place, the issue can be avoided.

[GSLabIt]

Can we discuss this again?

[danielcb]

just my two cents:
Yes, deleting invoices is not a good idea, but imho, as long as they're not booked/confirmed, it doesn't matter.

The proposed workaround indeed avoids the problem in most cases, but the problem is still there. I think invoice numbers (or any document IDs for that matter) should be added at the confirmation/booking stage and not after saving the document.

[alex-g-s]

My two cents:

• In order to avoid "holes" in the numbering of invoices, I use Sales orders when I am not sure when and if I will post the invoice. For Sales orders noone has a requirement for such a numbering, but you have all the data which you need in invoice later.
  So put the sales data in Sales order, revise it as much as you need. You can post even deliveries and when everything is final - then adjust the sales order , submit it and then as follow up document Make an Invoice when ready and sure.

[Nofal-Mami]

current sales invoice naming is considered as an ID of the invoice and new field should be added for the official sales invoice number which is gapless sequence and get generated at confirmation/submit action.
just create a sales invoice in draft should have an id for later review and validation, but as mentioned above the same can be deleted ignored or abandoned for any reason.

Another concept called invoice chain, where is similar to blockchain concept where sales invoice never get deleted how to implement the same in ERPNext?

[rmehta]

This has been fixed with Immutable Ledger https://github.com/frappe/erpnext/pull/18740

[theopen-institute]

This has been fixed with Immutable Ledger #18740

Is that true? I just tested on latest develop, and the capacity to delete drafts still appears to leave holes in the invoice sequence.

[rmehta]

Draft is not a submitted invoice. Once it is posted, it can't be changed.

Deletion can be controlled via permissions. Those who have access to the database (self hosted) can do whatever they want.

Most countries have systems to generate invoice numbers via government API. 3rd party validation is the only way this is fool proof. Rest is notional.

On 01-Jul-2020, at 1:15 PM, theopen-institute [e-mail] wrote:

This has been fixed with Immutable Ledger #18740 https://github.com/frappe/erpnext/pull/18740
Is that true? I just tested on latest develop, and the capacity to delete drafts still appears to leave holes in the invoice sequence.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/frappe/erpnext/issues/8765#issuecomment-652252334, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABCGLHESRNOQDZGJG6BOCLRZLSQ7ANCNFSM4DK3KKIA.

[theopen-institute]

Draft is not a submitted invoice. Once it is posted, it can't be changed. Deletion can be controlled via permissions. Those who have access to the database (self hosted) can do whatever they want. Most countries have systems to generate invoice numbers via government API. 3rd party validation is the only way this is fool proof. Rest is notional.
…

Indeed, drafts are not submitted invoices, but they are nevertheless being given Invoice numbers.

We all understand that everything is mutable if you have access to the hardware, but this is more of a workflow issue. Notional or not, many of us are bound by accounting standards that insist on strictly sequential documentation. If we create a draft and then decide not to submit it, what is the correct way to move forward?

[aakvatech]

Leaving holes in invoice numbers is an issue in Tanzania as well.

All invoices and journals should have a stage like "Archived Draft" that can only be ammended to to be Submitted. This will create a clear distinction between those Drafts that are current and actually draft, and mark "Archived Draft" for items that are equivalent to "Cancelled and not issued" (generally marked with 2 diagonal lines and written cancelled in physical invoice/journal books for auditors to be satisfied that the document was indeed not issued and would NOT be issued as is.

Moreover, this seems to be more like a doctstatus = 3 "Archived Draft" feature for frappe rather than ERPNext.

[theopen-institute]

Moreover, this seems to be more like a doctstatus = 3 "Archived Draft" feature for frappe rather than ERPNext.

Interesting thoughts. Is there a use-case where this approach is better than just holding off on assigning an invoice number until submission? Are there, for example, audit contexts where it's important to track draft documents that have never been issued and never will be issued?

The approach you're describing might be a lot simpler for the dev team to implement at this point, but I'm not sure I see how it's better than just waiting for submission to assign a serial number.

[barredterra]

@theopen-institute

I think an additional docstatus would be a lot easier to implement. Because the invoice number is currently also the unique invoice ID (in database terms) and generated by a naming series (which is only available for name/id), it would be difficult to move it to an optional field that is only set on submit.

[jalajc]

Shouldn’t the sequence number generate when Invoice is submitted?

In our scenario where we keep draft invoice ready for internal verification 3-4 days prior to delivery. Many a times the sequence which has higher number is sent before the lower sequence. Which is not very desirable and complicates taxation.
This scenario is also particularly prominent at the transition of the month. When say draft generated on 31-Dec is (Submitted and) dispatched later than the draft generated on 01-Jan.

From Architectural point of view and taking cues best practices of other CRM/ERPs, I think each table should have unique id column which then can be used to define parent-child records (such as Sales Invoice -> Sales Invoice Items) but are internal to system.
However, Series Number which becomes basis of external reference documents should generate at the time of Submission.

[barredterra]

@jalajc I completely agree, I also proposed this in several discussions. But there will be a major refactor involved that nobody is willing to make at the moment.