[V 7.0] Validating draft sales invoices does not respect order of invoice dates

[Els Van Vossel (Foxy)]

[V 7.0]

Latest version of server, addons, web

Legal issue: numbering according to invoice date

Database with demo data

Create 3 sales invoices (e.g. one from order, one from delivery, one manual sales invoice).
Change the dates: add invoice date 28/05/2013 to the first invoice created
add invoice date 21/05/2013 to the second invoice created
add invoice date 23/05/2013 to the third invoice created

Select all three invoices and use the wizard Validate draft invoices.

The legal numbering should be: 001 for invoice of 21/05, 002 for 23/05 and 003 for 28/05. This is not the case!

Please make sure the invoices receive a numbering starting from the earliest invoice date.

Regards,

Els Van Vossel

[Graeme Gellatly (gdgellatly)]

sorry but who decides this is a bug. Again this is a feature to please "some" users while wrecking behaviour for others in a non reversible way. If a user wishes their invoices to be validated in a certain way then by all means create own module but please show me any international standard where invoices MUST be validated in the way the bug report requests. It is trivial in an extension module to sort the ID's for workflow, but now we have it baked in wrecking everybody elses use case to satisfy one.

[Xavier ALT (dex-phx)]

Hi Graeme,

First of all, nothing landed on stable now!

Considering this issue, when validating the chosen "draft" invoices, the current behavior is to following standard ordering of invoices (i.e reverse order of creation (id DESC)). If user forced the "invoice_date" of those draft invoices, it make more sense to me to validate them following that order;

Note that the "read()" within ``invoice_confirm`` method will return item ordered following "account.invoice" _order; so in both cases user are not totally in control of the validation order - except by validating invoice by invoice.

Please share you thought on this.

Regards,

[Graeme Gellatly (gdgellatly)]

The default behaviour of nearly all actions that operate on multiple records are to apply that action using the current on screen ordering. e.g. If you sort a list by invoice number ascending and print invoices - that is what you will get, invoices printed in ascending invice number order. Likewise if you sort by date, you will have the actions performed in date order.

While I understand it makes sense to you and for many people, and I am not saying it is a bad feature, however right now the user and also other modules have all the choice in the world to control the order of all of the actions they perform on multiple records.

The merge proposal just replaces one bug with another bug. Instead of

for record in sorted(data_inv, key=lambda x: x['date_invoice'] or today):

why not just

data_inv_dict = {inv['id']: inv for inv in data_inv}
data_inv = [data_inv_dict[ctx_id] for ctx_id in context.get('active_ids', [])]

Then the order has been restored.

One comment I would make though. The reason the read is used in invoice_confirm I think is a little bit lazy or else had an unintended good side effect. I presume it is to in effect reverse the order of the ids as context['active_ids'] will list in id desc by default. With out that read() invoice numbers would not match up nicely on screen and I think that is desirable.

THerefore I would concede that it makes sense to reverse the id order so whatever search order of ids is passed the newest invoice number always ends up on top.

data_inv_dict = {inv['id']: inv for inv in data_inv}
data_inv = [data_inv_dict[ctx_id] for ctx_id in reversed(context.get('active_ids', []))]