openerp-expert-accounting team mailing list archive

[David Rinnan <david@xxxxxxxxxx>]

thank you for the explanation. and thank you for highlighting that this sequence module exists. I dont remember from the top of my head if separated sequences are required by law or not. but the nan module is the way to go in sweden and acts inline with what users are used to from other systems. 

thanks 

david rinnan
aspirix ab

Sent from my iPad

On 31 mar 2011, at 18:40, Borja <borjalopezsoilan@xxxxxxxxx> wrote:

> Hi accounting experts!
> 
> I'm bringing back this 'old' topic for a little follow-up.
> 
> Maybe you remember that, after OpenERP 6.0 RC1 was released, some of us complained about the (half-backed) change in the way invoices where numbered on 6.0 (bug #662821 "Invoices use the "Journal Sequence" instead of the "Invoice In/Out" sequences"). At that time, a pool was made to study what countries needed separate sequences for invoices and journals ("Pool: Countries with separate Invoice numbers and Journal numbers"). And, based on the pool, given that a lot of countries needed such feature, OpenERP acted in consequence and promised to create a module to solve the problem for those countries: the account_sequence module that was available on the final 6.0 release. 
> 
> Well, on this email I'll try to explain why I think account_sequence is not the right solution we were expecting, and what alternative solution we have (and is likely to be used, at least, by the OpenERP Spanish Localization Project).
> 
> This may look a Spanish accounting localization issue, but I think it's worth sharing here: We've seen some people from other countries having doubts about whether account_sequence does fit their needs (for example Cristian Salamea, aka Ovnicraft, stated he needed to change it), also some other countries (like Italy, just read Davide Corio: "i know account_sequence, but it doesn't solve the problem") may benefit from the alternative described here.
> 
> 
> 
> 
> Ok, here we go: I'll give you a simple example how OpenERP 6.0 works by default, how it works with the solution given by OpenERP, and finally how does it work with the solution proposed by NaN (one of the main Spanish OpenERP partners).
> 
> 
> OpenERP default behaviour (journal sequence only)
> 
> This is the default OpenERP 6.0 behavior, valid at least for Belgium and France, where the invoice number is just a 'reference' (a copy) of the journal entry number.
> 
> So, if you create (and confirm) an invoice you'll end with something like this:
> 
> <mime-attachment.png>
> 
> That is the way to go for some countries but - I just like complaining ;-) -  for me it looks redundant: Not just the same numeration is used for the invoice and journal entry numbers (which seems the right thing for Belgium and France), but it is also somehow displayed twice on the invoice form and on the journal entry you have the number and also the reference (same as the invoice number with the "/" removed).
> 
> And, what about reports? Well, you have again a bit of redundancy for these journal entries generated from invoices:
> 
> <mime-attachment.png>
> 
> 
> 
> PROS:
> Works better for some countries.
> CONS:
> Does not work for several countries.
> Redundancy.
> 
> OpenERP behaviour with account_sequence (journal sequence + internal journal sequence)
> 
> On countries like Spain, Venezuela, Italy, Austria, Switzerland, Ecuador, Argentina and Brazil (did I miss any?), somehow it is required to have a specific numeration for the Journal (or journals) entries, different from the invoices. OpenERP 6.0 tried to solve this with the account_sequence module.
> 
> The module creates a new sequence used to generate the "internal" sequence number for the Journal entries ('internal', meaning of not available to customers/providers, and even, on some countries, editable until the fiscal year is closed):
> 
> <mime-attachment.png>
> 
> The module mainly adds an extra field called "Internal number" to the journal entries and the journal entry views: 
> 
> <mime-attachment.png>
> 
> But, wait... that's everything? 
> 
> Yep, it does not change the reports to display the internal number! It is not used anywhere else! (truly "internal" number, huh?) 
> If you want to output this 'internal' entry number (like is required on some countries), you'll have to edit the reports yourself!
> 
> <mime-attachment.png>
> The "Ref" and "Move" columns displayed on the general ledger are just (redundant) references to the invoice number, and we still miss
> 
> 
> PROS:
> We have different numerations for the invoices (the journal sequence) and the account moves (the internal number sequence), "as required" on several countries.
> CONS:
> We don't have (and miss, compared to OpenERP 5.0) a way to display that internal field on the official reports (what was the meaning of the field in first place?).
> We may need to adapt some modules coming from the 5.0 version (like account_renumber) to work with this new field.
> Still redundant.
> 
> OpenERP behaviour with nan_account_invoice_sequence (journal sequence + invoice sequence)
> 
> Given the problems of the account_sequence, NaN (one of the main OpenERP partners in Spain) decided to go ahead and write their own module to solve the problem: The nan_account_invoice_sequence module was born (you'll find it on the extra-addons for 6.0).
> 
> This module, instead of creating a new extra field, just makes OpenERP work like it used on 5.0: The invoice number is freed (unlinked) from the entry number, and separated invoice/entry     sequences are configurable per journal again.
> 
> So, with this module installed, you may reuse the old () "Account Invoice In/Out/Refund In/Refund Out" sequences for the invoices and, either just reuse the old "Account Journal" as a single sequence for all your accounting (5.0 behavior with single journal sequence), or use separated sequences for the accounting entries of each journal (5.0 behavior with multiple journal sequences):
> 
> <mime-attachment.png>
> 
> So, when we create (and confirm) and invoice, we get different and unrelated numbers for the invoice number (green) and the journal entry (blue): 
> 
> <mime-attachment.png>
> 
> Do you see? We haven't lost any info in the process: you still have the invoice reference (green) on your accounting entries!  
> 
> And, of course, your reports will display both the invoice reference and the accounting move number (no more redundancy)
> 
> <mime-attachment.png>
> 
> Finally, as no extra fields are used, the 5.0 modules are easier to port or just work right-out-of-the-box (for example account_renumber).
> 
> 
> 
> PROS:
> We have different numerations for the invoices (the invoice sequences) and the account moves (the journal sequences), as required on several countries.
> The accounting move number is displayed on standard reports.
> We give some good use to those old still-present-though-not-needed-on-6.0 sequences :)
> Modules are easier to port from 5.0.
> More familiar for final users: Same behavior as the 5.0 version.
> CONS:
> Not the best option for some countries (Belgium, France).
> 
> 
> Summary
> 
> On the 6.0, the way invoices were numbered was changed to make it simpler and more appropriate for some countries... but it turned out to be wrong to assume the same behavior was valid for every country. So, a decision was made by OpenERP: the simple behavior would be the default for 6.0, but a module would be provided to fix-the-gap and make it compatible with the rest countries. Unfortunately the module, supposed to fix the problem for the localizations of those countries -in my opinion- is not enough, not what we where expecting.
> 
> Since January, a debate around this topic has been ongoing on the OpenERP-Spain mailing list. And someone, NaN in this case, took the initiative and built a new module to solve the problem. 
> I think it is an interesting alternative, that should be taken into consideration by other countries localization drivers.
> 
> Just as a last comment, several official Spanish OpenERP partners (NaN, Zikzakmedia, Pexego...) have already tested this module, and voted to make it a requirement for the Spanish localization :)
> -- 
> Borja López Soilán
> http://www.kami.es
> http://twitter.com/NeoPolus
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-accounting
> Post to     : openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-accounting
> More help   : https://help.launchpad.net/ListHelp