Sequential invoice numbers per distributor

[abdellani]

What? Why?

• Closes [Invoices numbers] Invoices should have sequential numbers by enterprise #11458

Depends on another PR, this one starts at: bd8460d

What should we test?

Some possible scenarios
Scenario 1:

1. Create an order for Distributor 1 (suppose id is 123)
2. Generate an invoice, the invoice number should be: 123-1
3. Update the order (quantity for example)
4. Generate another invoice, the invoice number should be: 123-2

Scenario 2:

1. Create an order O1 for Distributor 1 (suppose id is 123)
2. Generate an invoice for O1, the invoice number should be: 123-1
3. Generate another order O2
4. Generate an invoice for O2, the invoice number should be: 123-2
5. Edit O1 (update quantity for example) and generate another invoice for O1. The invoice number should be 123-3

Release notes

Changelog Category (reviewers may add a label for the release notes):

• User facing changes
• API changes (V0, V1, DFC or Webhook)
• Technical changes only
• Feature toggled

The title of the pull request will be included in the release notes.

Dependencies

• New and unique invoice template #11679

Documentation updates

[abdellani]

This PR is based on #11679

[dacook]

Looks good 👍

I'm assuming the requirement about bulk invoice ordering is already covered in BulkInvoiceJob#sorted_orders.

[rioug]

Looks good !

[sigmundpetersen]

I think we need to get #11679 in first

[sigmundpetersen]

Conflicts need to be resolved.

[dacook]

Rebased on master, ready for testing.

(dunno why GitHub reported conflicts; my local Git was able to rebase without any conflicts)

[RachL]

@abdellani when staging I see it has automatically generated a number for invoices previously created under the feature toggle. And it created a sequential number per order.

So with my release farm on staging Fr I have several times the number 2720-1 for example.

As I'm not able to replicate this once I start doing invoices with the new code, I'm assuming this only occurs for enterprise which had been playing with the new invoice feature before- which won't happened in production. So we are safe with ignoring this case. Am I right?

[abdellani]

As I'm not able to replicate this once I start doing invoices with the new code, I'm assuming this only occurs for enterprise which had been playing with the new invoice feature before- which won't happened in production. So we are safe with ignoring this case. Am I right?

@RachL
This was happening with the existing invoices created before this PR).
The invoice's number uniqueness scope was the order, not the distributor.

I didn't handle the existing invoices, do you want me to do that?

[RachL]

@abdellani no I don't think so as I guess it won't happen in production, that's what I wanted to double check :-)

I think this needs a rebase before we merge: can you have a look? Thanks

[RachL]

hehe @sigmundpetersen you are more courageous than me :D

[sigmundpetersen]

Shall we merge then? 😊

[RachL]

yeaaaah merging without waiting for requirements to be met! #howwild

[RachL]

ah actually we can't do that, we need a review, moving back to code review then!

[sigmundpetersen]

I don't think there has been any actual changes since you tested, only rebasing.
So in my view this doesn't need another review

[RachL]

@sigmundpetersen I'm ok with that, but I don't have the power to merge. Ticking the box doesn't change anything on my side this time.