Validation for invoice number

In most countries rules exist for valid invoice numbers, e.g. usually there must not be duplicate invoice numbers and so on. Some basics are explained in Wikipedia, on top of this lots of national regulations exist. According to my (limited) knowledge of bookkeeping, the "Storm Invoice" module does not properly warrant to generate valid invoice numbers. Since the sole job of the "Storm invoice" module is to generate invcoices, this is a bug. Since unique invoice numbers are a key component of accounting, this is even a major issue.

I'd suggest to either validate the invoice numbers, as the original poster proposed on July 30, 2009, or to allow the user to generate proper invoice numbers by himself, e.g. with tokens. A proper (unique) invoice number could be easily generated, for example with this simple token:

<?php
 return 'Invoice No. ' . '[yyyy]' . '[mm]' . '[dd]' . '-[nid]' 
?>

This takes the node creation date and adds the node ID, which always results in a unique and incrementing invouce number (at least as long as you stick with one Drupal site). However, this would be much better than the current approach which can only result in serious fiscal trouble.

Workaround (requires several node edits):

• Generate the node title with the token above
• Edit the "Storm invoice" node, and replace the invoice number with the node title
• Pray that you don't forget to fix the "Storm invoice" before a tax auditor catches you

Good plan. Would you be able to submit a patch?

(This would need to go into the 2.x branch)

Sorry, just user, not coder.

Moving to Project Management module queue.

'Invoice No. ' . '[yyyy]' . '[mm]' . '[dd]' . '-[nid]'
The above code would generate a unique but hardcoding it may be in-convenient for some.

Possible solutions,

1. Create a CTools plugin for generating invoice number. It could provide widgets based on "token", a simple text field, the above rule, basically if anybody wants a new feature a new widget could be implemented.

2. Provide a simple text field that user can edit which is auto-filled. Provide a validation for uniqueness. And a hook for any other module to alter the auto-fill rule and validation rule.

Two thoughts:
- It has previously been pointed out that in some jurisdictions invoice numbers are required to be consecutive (so nid may not be ideal)
- How would we do this using core fields?

The core field could be simple text field.

Below is just for discussion,

Proposal 1:

The idea was the plugin should calculate the invoice generation logic and letting
others to develop a pluggable invoice number generation logic.

Proposal 2:

PREFIX-NUMBER

1. A variable to store the next invoice number.
2. A variable to store the prefix.
3. Generate an invoice number after the node is saved (keep on incrementing until it finds a unique string ).
4. Corresponding invoice field of node updated accordingly (taking precaution not
to cause a infinite loop here :) ).

Also providing a check-box to allow user to override automatic generation for any invoice number if they may choose to.

But in practice the invoice numbers PREFIX may need to be changed depending upon time,

it may be in the format: {prefix:}{field:FIELD_NAME}{tag:TERM_NAME}{date:YY}{date:MM}{number:}

Also there could be another reset logic where the incrementing number resets when say YEAR changes or Month Changes.

Cons:
The invoice number wont be visible in node add, i.e. "Invoice creation" time.

What's the status of this at the moment?
I would love to see the functionality implemented in Proposal 1 of creating custom invoice id's by using tokens.

I am more than willing to e.g. test patches

We should consider this when converting that field to Field API.

It may be possible to implement this quite easily as the value of a calculated field (for example).

(Status by the way, is not started, anyone can pick this up if they have the time).

Moving to PM Invoice for review of whether this is still relevant.

PM Invoice is only concerned with adding "line items" into the invoice. Everything else would be the contrib. module specific settings which already expose such settings.

Having said that. I am sure we can implement our own logic to override the contrib module invoice number generation. But is it required?