openerp-expert-accounting team mailing list archive

[Ovnicraft <ovnicraft@xxxxxxxxx>]

Thanks Borja for this completely explanation and thanks for NaN for the
solution in module.

best regards,


On Thu, Mar 31, 2011 at 11:40 AM, 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"<https://bugs.launchpad.net/openobject-addons/+bug/662821>).
> 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"<http://www.mail-archive.com/openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx/msg00867.html>).
> 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 <https://launchpad.net/openerp-spain>).
>
> 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<http://www.mail-archive.com/openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx/msg01046.html>),
> also some other countries (like Italy, just read Davide Corio<http://www.mail-archive.com/openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx/msg01047.html>:
> "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:
>
>
>
> 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:
>
>
>
>
>
> 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):
>
>
>
> The module mainly adds an extra field called "Internal number" to the
> journal entries and the journal entry views:
>
>
>
> 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!
>
>
> *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<http://bazaar.launchpad.net/%7Eopenerp-commiter/openobject-addons/extra-6.0/files/head:/nan_account_invoice_sequence/>
> ).
>
> 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):
>
>
>
> So, when we create (and confirm) and invoice, we get different and
> unrelated numbers for the invoice number (green) and the journal entry
> (blue):
>
>
>
> 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)
>
>
>
> 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<http://www.mail-archive.com/openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx/msg01045.html>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<http://groups.google.com/group/openerp-spain/browse_thread/thread/b324fe1638fa805a>.
> 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ánhttp://www.kami.eshttp://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
>
>


-- 
Cristian Salamea
@ovnicraft