| Thread Previous • Date Previous • Date Next • Thread Next |
Eu acho que a gente tambem nao esta usando esse "*account_sequence *(veja em
baixo)
Talvez Renato pode depois resumir. Mas vamos sim protestar com eles caso é
confirmado que nosso problema é o mesmo.
Atts.
--
Raphaël Valyi
Founder and consultant
+55 21 3010 9965
www.akretion.com
---------- Forwarded message ----------
From: Borja <borjalopezsoilan@xxxxxxxxx>
Date: Thu, Mar 31, 2011 at 1:40 PM
Subject: [Openerp-expert-accounting] Invoice/Journal numbers - followup
(account_sequence vs nan_account_invoice_sequence)
To: openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx
Cc: openerp-spain@xxxxxxxxxxxxxxxx
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
Attachment:
pngtltuV4NbES.png
Description: PNG image
Attachment:
png4aj03hIrdK.png
Description: PNG image
Attachment:
pngwp6u3AAZdF.png
Description: PNG image
Attachment:
pngmP8hReapk7.png
Description: PNG image
Attachment:
pngWvLB6_VA2E.png
Description: PNG image
Attachment:
png03J5dUYo9E.png
Description: PNG image
Attachment:
pngppjC6ZjtkK.png
Description: PNG image
Attachment:
pngT7plRfGLVs.png
Description: PNG image
| Thread Previous • Date Previous • Date Next • Thread Next |
