← Back to team overview

openerp-expert-accounting team mailing list archive

Re: Pool: Countries with separate Invoice numbers and Journal numbers

 

Hi Quentin.

Some comments:

*create a customer invoice and confirm it: it receives the number SAJ/2010/001
*create the payment that will receive the number CSH/2010/001
*create a second customer invoice and confirm it: it receives the number SAJ/2010/002 (what Borja explained before is True only if you set the same sequence for several journals, which is not the the adviced configuration) *cancel the first invoice (only possible if you install the module account_cancel and set the journal accordingly): the accounting entry is deleted. Set to this invoice back to draft and confirm it again: the invoice still have the number SAJ/2010/001

What you described would be the right behavior for invoice sequences (they may be canceled, so they can be edited/corrected, but the same number should be used when confirmed; and shouldn't exist any gap) :) Invoice numbers are more important than entry numbers in the sense that entry numbers are internal until the periods or fiscal year are closed, but invoice numbers are external (i.e. invoice sent to a customer).

By the way, i don't see any interest in having a internal number that is totally meaningless for the end-user: with a name which is 'SAJ/2010/512' i know easily what is the accounting entry for. Which is not the case if my accounting entry is named as '2010/000436'. I'd like also to emphase that we made something a bit similar for the bank statement, in order to have the 'name' of the accounting entry which is actually the name of the paper document (internal name).

Yep, it is stupid to have such internal number. But it has a small bit of sense:

   * On Spain the accounting entries are usually registered by an
     external accountant. So, that entry number is useful on the
     accountant/company communication ("please review the entry
     4321..."). You can think of it as a "id" of the entry.
   * There are historical reasons: When the accounting was done by
     hand, on paper, we were required to register all the economic
     operations of the company on the so called "Journal" book, but we
     were also required to have separated books to register received
     and sent invoices. Lines on such paper books can't be deleted (the
     book pages are numbered, and the books have to be officially
     certified&signed before using them) and the media (the paper) is
     inherently sequential. Computers changed it all: computer storage
     has no strict order, so we are forced to register the sequence in
     a explicit way. As we had several different books on paper, we
     need several different sequences on computer.


And finally, let me explain the reason we made this 'improvement': in v5, each time you cancelled an invoice and confirmed it again, you introduced a gap in your accounting entries numbering. If you wanted to disallow that, you had to modify the ir.sequence object manually: and that was really not a good idea to let your accountants do that! In v6, it's not the case anymore: there is no gap introduced.

Two points here:

   * On Spain having such gaps is permitted (and done often), but only
     when doing the accounting on a computer! Again this has historical
     reasons: On paper it was hard to make a mistake, and you might use
     "typex" to fix an entry (or a rubber if you used a pencil); on a
     computer mistakes are easier to make, harder to notice (they may
     be automatized), so sooner or latter you might need to remove some
     entries.
   * This will leave gaps on the entries numeration of course, but as
     long as the Journal hasn't been printed it is not a big deal: as
     it is an 'internal' number (that you only use inside your company
     or with your accountant) you can renumber it anytime. That's why
     every Spanish accounting program has some kind of "renumbering"
     wizard that will renumber the entries by date. On OpenERP 5.0 we
     implemented such a wizard too: It's the account_renumber module of
     the extra-addons.

By the way, i don't see any interest in having a internal number that is totally meaningless for the end-user: with a name which is 'SAJ/2010/512' i know easily what is the accounting entry for. Which is not the case if my accounting entry is named as '2010/000436'. I'd like also to emphase that we made something a bit similar for the bank statement, in order to have the 'name' of the accounting entry which is actually the name of the paper document (internal name).

The difference is that we aren't legally required to have a "book" for bank statements: no paper-book, no computer-sequence ;)


The summary is: Just a matter of legal requirements so the computer-assisted accounting remains compatible with hand-made accounting (just legacy).

I hope this helps, thanks for your contribution.

Thanks to you for listening to the community :)

--
Borja López Soilán
http://www.kami.es


References