[6.0] Invoices use the "Journal Sequence" instead of the "Invoice In/Out" sequences

[Borja López Soilán (NeoPolus)]

The invoices, on addons 6.0 (revid <email address hidden>) use the Journal Sequence by default instead of the "Invoice In/Out/Refund In/Refund Out" sequences, and it is not possible to setup the sequence to use (the "invoice_sequence_id" field has been removed from the view).

That is completely invalid, as the invoices will have holes in their numbering!, so this bug should be considered critical.

HOW TO REPRODUCE:

  - On a fresh database with the accounting installed and no invoices nor journal entries yet:
  - Create an invoice and confirm it. The invoice will receive number "1" (the same as the journal entry for the invoice).
  - Pay the invoice (voucher), the voucher journal entry will receive number "2".
  - Create a new invoice and confirm it. The invoice will receive number "3" (instead of "2").

NOTES:

On some countries like Spain, we should have a single sequence for all the journal entries (as if we had a single journal), but we may have several invoice sequences.
Also, at least on Spain, we are not allowed to renumber the invoices (after handing it to a customer) under any circumstance, but its common to renumber the accounting entries (they only have to be numbered sequentially by date on the fiscal year closing).
And finally, on Spain, we don't need to restart the invoices sequence each year, but we must do so with the journal entries sequence.

[Olivier Dony (Odoo) (odo-openerp)]

@Borja:
Can you provide more detailed steps to reproduce? (exact list of modules installed - demo data or not, etc.)
Since the invoice number is a fields.related to its journal.entry's number, normally they cannot be different...

@Raphael:
Same question, you might have different conditions to reproduce it?

[Antony Lesuisse (OpenERP) (al-openerp)]

I tried to reproduce folowing the scenario both the entry and the invoice get the Number: SAJ/2010/001.

account/invoice.py line 234:

'number': fields.related('move_id','name', type='char', readonly=True, size=64, relation='account.move', store=True, string='Number'),

So i doubt it's possible unless there is a bug with the store=True.

[Olivier Dony (Odoo) (odo-openerp)]

BTW, this is the desired behavior in v6 and normally guarantees that invoices and their journal entries will always have the same numbers, greatly easing various accounting operations that used to require matching invoices numbers and entries numbers. (e.g. matching with reports, etc.)

[Borja López Soilán (NeoPolus) (borjals)]

Ok, I changed the bug description, I misunderstood the symptoms: It's not that the invoice and account entries were using the same sequence, but the invoice showing the number of the entry (related field). This is not valid on some countries (like Spain), that different numbers for invoices, so if this is the desired behavior for 6.0, we will need to provide the feature on an external addon.

[Fabien (Open ERP) (fp-tinyerp)]

Borja, it's a totally normal behaviour.

Note that you can have different numbering between invoices and payments by selecting different sequences on the different journals.

I you really want to have two different numbers on a journal entry (account.move), you can use the name and the ref fields for this. But clearly having 4 different numbers on a journal item was too much and lead to lots of confusion in v5: (name, ref on account.move, name, ref on account.move.line). -> just imaging financial report, which reference do you print ?

Now, you only have 3 numbers on Journal Entries which is better: "name" the reference of the Entry (payment or invoice number), "ref" the external reference of the entry (ref of your supplier) and "Name" on the journal item (entry line) which is a reference for each line.

I close the bug. I think if you need another behaviour, it's better to do it as a separate module and not to change existing ones.

[Borja López Soilán (NeoPolus) (borjals)]

Fabien, I'll explain a bit more (as it seems there are more differences between Belgium accounting and Spanish accounting than I though):

We have these two main "user histories":

  A - "I'm an accountant of an Spanish company, after closing a fiscal year I need to print my Journal (for that year) with all the entries numbered in sequential order by date without gaps, so I can handle it to the Mercantile Register"

  B - "I'm an accountant of an Spanish company, after closing a period I need to print the list of the invoices (for that period) grouped by sequence and numbered in sequential order by date without gaps, so I can handle it to the Mercantile Register"

Now notice that:

  - In user history A, I say "Journal": for a Spanish company there is a single "Journal"; we don't use different sequences on different "journals" as (outside OpenERP) we simple don't have "journals" but just one big "Journal" for everything (1*).

  - In user history B, I talk about "grouping invoices by sequence": we are allowed to have different invoice sequences (2*), even more, we are forced to have different sequences for invoices and refunds.

In addition, we 'must' not do changes in the invoices, and we 'should' not do changes in the accounting entries: it is pretty usual on Spain to renumber the account numbers when closing the fiscal year (every Spanish accounting software has that feature), but renumbering the (customer) invoices is not legal (or even feasible, as they may be printed & sent already).

If you are interested these are the legal orders that force us to work like that:

*1 "Código de Comercio de 1885" ("Comercial Code of 1885"), point 28.2:
"2. El libro Diario registrará día a día todas las operaciones relativas a la actividad de la empresa." (http://www.gabilos.com/leyes/ccom.l1t3.html#a28)
Badly translated: "The Journal book would register day by day every operation related to the company activities." (notice that "every", and that it says "book" not "books").

*2 Order "RD 1496/2003", point 6 "Contenido de la factura." ("Invoice contents"):
"Número y, en su caso, serie. La numeración de las facturas dentro de cada serie será correlativa.
Se podrán expedir facturas mediante series separadas cuando existan razones que lo justifiquen y, entre otros supuestos, cuando el obligado a su expedición cuente con varios establecimientos desde los que efectúe sus operaciones y cuando el obligado a su expedición realice operaciones de distinta naturaleza." (http://www.gabilos.com/leyes/rd1496-2003.t1.html#a2)
Badly translated: "(Invoices content: ...) Number, and if needed, sequence. Invoices numbering inside each sequence will be correlative.
Invoices can be emited using different series when there are reasons to justify it and, among other reasons, when the emisor does its operations from several places and when the operations have different nature"

CONCLUSION: we are need to use several sequences for invoices, but we must use a single sequence for all the account moves! That's why the new 6.0 behavior isn't valid for us, but 5.0 behavior was alright!

I hope now we understand better each other :)

[Fabien (Open ERP) (fp-tinyerp)]

Hello,

Seems quite easy to use the second field (ref) to store the global uniq ID for journal entries. I think it's better to store this in the l10n_es. Does anyone have the same issue with this for others countries ?

[Nhomar - Vauxoo (nhomar)]

Hello fabien.

Yes, all Latinamerica work's as V5 was doing the work, separate sequence for separate process.

accounting - administrative tasks are tottally separated refund in and out, invoice in and out, payments, etc.

I think make this in a separate l10n_XX module is not the correct solution.

BTW, an official module that separe the sequences should be IMHO a more ellegant solution.

Regards ;-)

[Ignacio E. Parszyk (Thymbra) (ignaciop)]

Hello,

In Argentina we have the same problem.
We need a sequence for each document (out_invoice, in_invoice, out_refund, in_refund, etc), and like in spain, we are not allowed to renumber the invoices, but in the fiscal year closing, the entries are usually renumbered by date.

Regards,

[Cristian Salamea (ovnicraft)]

@Fabien in Ecuador has the same issue, i agree with Nhomar, get another module to solve.

Regards,

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

To sum it up so far (from the accounting expert mailing list thread):

Countries OK with the new V6 system:
----------------------------------------------
Belgium - Fabien (@fpopenerp)
France (dixit @fpopenerp)

Countries not OK with the new system and that would like a specific sequence for invoices as in V5:
----------------------------------------------
Spain - Borja (@NeoPolus)
Venezuela - Nhomar (@nhomar)
Italy - Davide (@davidecorio)
Austria - Ferdinand.
Switzerland - Joël (@jgrandguillaume)
Ecuador - Cristian (@ovnicraft)
Argentina - Ignacio (@ignacioparszyk)
Brazil (@rvalyi @renatonlima)
UK (@sharoonthomas)
India (@sharoonthomas)
Morocco (@hproust)
Cameroon (@hproust)

Feel free to complete the list.

[Nhomar - Vauxoo (nhomar)]

Countries OK with the new V6 system:
----------------------------------------------
Belgium - Fabien (@fpopenerp)
France (dixit @fpopenerp)

Countries not OK with the new system and that would like a specific sequence for invoices as in V5:
----------------------------------------------
Spain - Borja (@NeoPolus)
Venezuela - Nhomar (@nhomar)
Colombia - Nhomar (@nhomar)
Bolivia - Nhomar (@nhomar)
Italy - Davide (@davidecorio)
Austria - Ferdinand.
Switzerland - Joël (@jgrandguillaume)
Ecuador - Cristian (@ovnicraft)
Argentina - Ignacio (@ignacioparszyk)
Brazil (@rvalyi @renatonlima)
UK (@sharoonthomas)
India (@sharoonthomas)
Morocco (@hproust)
Cameroon (@hproust)

[filsys (office-filsystem)]

Countries OK with the new V6 system:
----------------------------------------------
Belgium - Fabien (@fpopenerp)
France (dixit @fpopenerp)

Countries not OK with the new system and that would like a specific sequence for invoices as in V5:
----------------------------------------------
Spain - Borja (@NeoPolus)
Venezuela - Nhomar (@nhomar)
Italy - Davide (@davidecorio)
Austria - Ferdinand.
Switzerland - Joël (@jgrandguillaume)
Ecuador - Cristian (@ovnicraft)
Argentina - Ignacio (@ignacioparszyk)
Brazil (@rvalyi @renatonlima)
UK (@sharoonthomas)
India (@sharoonthomas)
Morocco (@hproust)
Cameroon (@hproust)
Romania (@filsys)

On 25.10.2010 16:50, Raphaël Valyi - http://www.akretion.com wrote:
> To sum it up so far (from the accounting expert mailing list thread):
>
> Countries OK with the new V6 system:
> ----------------------------------------------
> Belgium - Fabien (@fpopenerp)
> France (dixit @fpopenerp)
>
>
> Countries not OK with the new system and that would like a specific sequence for invoices as in V5:
> ----------------------------------------------
> Spain - Borja (@NeoPolus)
> Venezuela - Nhomar (@nhomar)
> Italy - Davide (@davidecorio)
> Austria - Ferdinand.
> Switzerland - Joël (@jgrandguillaume)
> Ecuador - Cristian (@ovnicraft)
> Argentina - Ignacio (@ignacioparszyk)
> Brazil (@rvalyi @renatonlima)
> UK (@sharoonthomas)
> India (@sharoonthomas)
> Morocco (@hproust)
> Cameroon (@hproust)
>
> Feel free to complete the list.
>

[Cristian Salamea (ovnicraft)]

Hello we are working in Peru and its necessary here too:

Countries OK with the new V6 system:
----------------------------------------------
Belgium - Fabien (@fpopenerp)
France (dixit @fpopenerp)

Countries not OK with the new system and that would like a specific sequence for invoices as in V5:
----------------------------------------------
Spain - Borja (@NeoPolus)
Venezuela - Nhomar (@nhomar)
Italy - Davide (@davidecorio)
Austria - Ferdinand.
Switzerland - Joël (@jgrandguillaume)
Ecuador - Cristian (@ovnicraft)
Peru - Cristian (@ovnicraft)
Argentina - Ignacio (@ignacioparszyk)
Brazil (@rvalyi @renatonlima)
UK (@sharoonthomas)
India (@sharoonthomas)
Morocco (@hproust)
Cameroon (@hproust)
Romania (@filsys)

[Borja López Soilán (NeoPolus) (borjals)]

Just an update to the bug: As stated by Fabien and Quentin on the accounting-experts mailing list, this bug will be fixed soon by adding a new module that can then be loaded by localizations needing separated invoice/entry sequences:

"First of all, let me remind you that we will release with the version 6 a module that will have the following behaviour:
*add a new field 'internal sequence number' on the accounting entries (type=char, on account.move object)
*add a new field 'internal sequence' on the account journals (type=many2one(ir.sequence), on account.journal object)
*with this module, a new sequence will be created as data and put as default value on every journal
*when posting an entry (when the state goes from 'draft' to 'posted), it will fill the new field 'internal sequence number' of the accounting entries with the next number accordingly to the sequence selected on the related journal." (qdp)

[Olivier Dony (Odoo) (odo-openerp)]

Housekeeping: proper assignation for implementation by Accounting team.

Note: for bug qualification guidelines please refer to http://doc.openerp.com/contribute/15_guidelines/contribution_guidelines.html#classifying-bugs (we will publish an updated one soon to explain our new process/policy)

[Fabien (Open ERP) (fp-tinyerp)]

TODO: https://bugs.launchpad.net/openobject-addons/+bug/662821/comments/15

NOTE: for the qualification team, when you have bugs with a lot of discussion like this one, please reffer to the comment to implement like above.

[Mustufa Rangwala (Open ERP) (mra-tinyerp)]

Hello All,

We have added account_sequence module on Addons3 branch as per qdp description on comment #15 . It will be visible on trunk addons soon.

Thank you,
Mustufa (mra)

[Cristian Salamea (ovnicraft)]

I am testing the account_sequence module, and understanding what it does, i get this:

Configure my journal with :
 * 2 different sequence ( sequence_id and internal_sequence_id fields)
 * Sale type

Make and Validate one Invoice -> the account move create get name and internal_sequence_number set the values with sequences from journal.
Create manually a move in the same journal and again and both fields are set name and internal_sequence_number.
Results:
Move from invoice: name: 2010/01 internal_sequence_number: 2010/01
Manual move: name: 2010/02 internal_sequence_number: 2010/02

As you see *both* sequence are called, the account_sequence must consider in the code if the move does not comes from Invoice document just use internal_sequence_id from Journal adn write the value in name and internal_sequence_number fields, this keeps the sequence_id ( aka. Invoice sequence).

This[1] is the code in post method redefined in account_sequence.py file from account_move i think the post method must redefined completely and dont use super call, so in parent post method the name field is wrote with Entry Sequence (sequence_id field from journal).

Waiting your feedback, regards,

[1] http://paste.pocoo.org/show/307565/

PS: i'll post a patch

[Cristian Salamea (ovnicraft)]

I did some changes in post method from account_sequence module, check please : http://paste.pocoo.org/show/307900/

Regards,

[Borja López Soilán (NeoPolus) (borjals)]

Anybody still interested on this bug, should take a look at this new thread on the accounting experts, explaining the behavior of the OpenERP proposed solution for this problem, and an alternative solution that may be more interesting on some countries: https://lists.launchpad.net/openerp-expert-accounting/msg01108.html