I thought I’d weigh in to this conversation, as we have invoicing functionality in our own customers (CRM) application. This supports the way you want to (or rather, have to) handle invoice numbers. As a bonus, it also supports crediting invoices 🙂
Please note that ‘Deleting an invoice’ is considered fraud by law in most (if not all) countries. Once an invoice is generated, it should be credited in order to be removed instead. This also requires some more administrative work in the accounting, which is why we separate orders from invoice generation.
Here’s how it works. First, we have a data item called Sales order which represents any sales order. In our case these are made on the website, then sent through Zapier, but they can be created in any other way too.
We only use a single data item, which represents sales orders and contains the invoice information:
Note that we use the order date as the invoice date. Should you require a separate invoice date you can always create one. These fields are all empty when the item is created. We only fill them when we want to invoice the sales order or credit it.
Let’s start with the invoice number; this is generated by a flow part called Set sales order invoice number. It’s rather intricate, but you could simplify it for your needs most likely:
This flow part takes a Sales order as input and then first determines whether the invoice has already been invoiced (by checking whether the invoice number is empty). If not, it finds the sales order with the highest invoice number by finding the sales order with a rule that says Invoice number is not empty and then sorts them by invoice number from highest to lowest. It searches for 1 sales order.
The calculation after that just adds 1 to the highest invoice number. The other path simply takes the invoice number from the input sales order. We do this to make sure we can use the result of the calculation Invoice number after the decision. We store this number in the sales order.
The next bit is not very necessary perhaps in your case. We calculate the length of the invoice number and then add leading zeros to it to make it always have length 10. For example, invoice number 9 would become 0000000009 and invoice number 1023154 would become 0001023154. After we do this, we add some more text in the action ‘Final invoice number as text’. In our case we make it look like this:
We do need a little trick here since the invoice number will have some periods and/or commas in it. To remove those we use the following rule:
CUT REMOVE . FROM REMOVE , FROM Invoice number as text FROM 1 FOR 10 CHARACTERS
This rule uses a lot of functions in functions, you could also use separate calculations for this.
Finally, we update the field Invoice number as text of the input sales order.
In a separate flow part called Generate invoice document for sales order we then generate a PDF document that represents the invoice and store it in the property Invoice document:
We separate these 2 flows because we want to be able to re-generate the invoice using the same data. This can be handy when you change something in the layout of your invoice. Please note that this does not change any of the values in the order, it just regenerates the document.
To credit an invoice, we use a single flow part called Credit sales order which takes 3 inputs:
The true/false can be ignored really, it’s just used to regenerate the credit note when the design changes. The sales order is the sales order we want to credit and the user is the user who presses the button to credit it. We store this just in case we get a question about it, so we know who to ask.
The flow is rather simple; it creates a credit number which is just the invoice number with an appended -C, so for example:
This is sufficient according to the Dutch tax law and I believe in most other countries too. They simply require invoices and credit notes to be able to be traced (without going into more detail on this for now).
That’s it, a complete set of data item and flow parts to generate invoices and credit them if necessary!