I would like to share with you something I think is a bug on invoices module. Allow me to explain:
1.- At least in Spain is mandatory to keep consecutive serial numbers so it is not posible to have 1, 2, 3, 4 and then jump to 6,7, 8 …
2.- If you go ACCOUNTING / SALES INVOICES and you create a new invoice then the next invoice on serie is taken EVEN IF YOU SAVE AS DRAFT
So think now on following scenario:
1.- Last invoice number is C-INVOICE-09
2.- Now you add a new invoice through ACCOUNTING / SALES INVOICE, and C-INVOICE-10 is taken. BUT you save that invoice as DRAFT
3.- You create another new invoice through ACCOUNTING / SALES INVOICE, and C-INVOICE-11 is taken
4.- You delete the invoice C-INVOICE-10 because was only a draft and you don’t need it finally
Then you have a jump from C-INVOICE-09 to C-INVOICE-11 and C-INVOICE-10 does not exists.
Summary: On my opinion an invoice number shouldn’t be assigned till user submit the invoice. But now sure if the current procedure is as it based on some special requirement.
Anyone else think it would be interesting to fix this problem ???
In the UK the same requirement exists and I suspect it is the same throughout the EU as it is a VAT requirement. Given that I agree that Sales Invoices should only be assigned their invoice number when confirmed.
In reality I think if that is a regular problem then there may something in your process flow of how you deal with orders that needs tightening up. Normally the business document flow is: Sales Quotation → Sales Order → Picking Note → Despatch/Delivery Note → Sales Invoice so unless you have dispatched the goods then no invoice should exist. If they do then you should think about using Sales Orders to manage those instances.
The reason I still support this because everyone can make mistakes and hit the Sales Invoice button by mistake which generates an Invoice Number which if you press the back key or any other method of getting out of it without saving it the number is still allocated in the background unless you log completely out of the system and back in again in which case it will generate that same number again. Chances are that isn’t going to happen and someone else will come along and create an invoice and that point you have a gap.
It’s a much less likely scenario however when you have the force of law stating no gaps then less isn’t good enough.
At the minute all you can do is to remove the delete option by customisation (assuming it can be customised) and force the invoice to be credited instead. It’s messy but at least legally compliant.