Hello Quentin,
I'm actually replying in English and forwarding the mail to the
accounting expert list (and Brazilian list too) as I think it's
interesting to let the community participate to the debate and see
OpenERP S.A. commitment in integrating community contributions which
is great (else people tend to just miss your leadership). Renato Lima
and me are at customer site today, but you can eventually contact me
on Skype (raphael.valyi).
In general, I advise you look at the commit messages of our branch for
details.
I replied inline:
2010/9/10 Quentin <qdp@xxxxxxxxxxx <mailto:qdp@xxxxxxxxxxx>>
Bonjour Raphaël,
je suis actuellement en train d'analyser la branche d'akretion
relative au rapport intrastat:
https://code.launchpad.net/~akretion-team/openobject-addons/openobject-addons_5.0_report_intrastat
<https://code.launchpad.net/%7Eakretion-team/openobject-addons/openobject-addons_5.0_report_intrastat>
Note: it has been funded by Anevia (via Alexis de Lattre in copy), our
largest customer in production so far. They have been using it
successfully in production for 6 months now.
It basically follows the French legislation for intrastat report more
carefully, but in a way that we believe will be useful to any European
country (not just France).
I attach a first Anevia specification (2 docs) here of from them here
(in French and please consider it evolved since them, true spec is the
code/commits).
J'aurais besoin de plus d'infos concernant certains points afin
d'isoler la partie générique des développements:
1) je crois comprendre qu'au Brésil, vous devez aussi ajouter dans
vos rapports intrastat, les transactions de marchandises qui se
font entre états.
Correct, actually, federal states like Brazil (but may be the US too,
not sure) often need to track good exchange between states like just
between European countries.
Still, because report_intrastat was not generic enough, we were not
able to reuse those concepts in Brazil and had unfortunately to "redo"
them for the Brazilian localization.
So inside the l10n_br module here:
https://code.launchpad.net/~openerp-brazil-team/openerp.pt-br-localiz/trunk
<https://code.launchpad.net/%7Eopenerp-brazil-team/openerp.pt-br-localiz/trunk> ,
you'll see that we have re-deveolpped the concept of state exchanges,
intrastat document type and extended invoice workflow (see next point).
Of course, this was because report_intrastat wasn't generic enough.
This doesn't scale at all. Currently it's impossible (or very very
challenging) to use the same OpenERP for a company working both in
Brazil (l10n_br) and in europe (report_intrastat), because both need
to extend the invoice workflow and that would be incompatible etc...
Ideally those concepts of good echange would be refactored in a common
base_good_exchange module (or any better name) that will make no
assumption on the exact reporting format and upon which both
report_intrastat and l10n_br (and possibly other localizations) would
depend in OpenERP V6.
Pourquoi dans ce cas ne pas avoir rajouté un booléen sur
res.country.state (comme pour les pays)?
Well, might be an idea yes. However, inside a federal state (so inside
a localization) you basically will track exchange between all federal
states of that country, having a flag on it wouldn't make a huge
difference (it's not the main issue) but it might help yes.
2) vous avez modifié le workflow des factures, ajouté un état
'legal_intrastat'. Pourquoi? Dans quels cas devez-vous intégrer
dans vos rapports intrastat des transactions qui ne sont pas liées
à de vraies factures?
The simplest case you could think happens both in France or Brazil: if
you send a product you repaired under the the guarantee terms to an
other (federal) state, then:
* you have no financial moves for that expedition as the customer
would pay nothing (guaranteed repair), so it means no "real invoice"
* you still need to produce the exact "intrastat" document for
customs, as if it where a regular sale (the document is very
similar)
* that document will only differ from a regular sale by some
"operation codes". Both Brazil or France have this concept. See
our report_intrastat and l10n_br modules for details of the
possible codes. In report_intrastat we defined "intrastat_type",
which is the rough equivalent of "fical_operation_id" in l10n_br
from Brazil. A code (easy to select) will actually define one or
more codes (usually two, in Brazil it will for instance select
the proper "CFOP" cfop_id among other codes).
Of course, there are lot's of other cases, not just guaranteed repair.
In a typical Brazilian industry, we would have something like
Quel que soit le besoin, je suis plutôt d'avis que votre solution
n'est pas idéale vu qu'à priori vous allez fausser les stats sur
les factures, mais surtout il me semble que vous mélangez 2
concepts assez distincts...
* Well, indeed, we would need to make sure, stats upon invoices
only take into account the classical states like draft, done so
that our new state will not spoil any stat. Generally speaking,
I think open object is a bit limited regarding to custom
states/workflow. IMHO, states would better have something like a
category/type (like category of draft states, category of valid
states) so modules could had extra states (it's just a rough
idea though). Then reports would be based rather on the state
categories than hardcoding the state names they use which
doesn't scale to customization very well as you remark.
* You could imagine other ideas, but:
o those intrastat documents need all the characteristics of
an invoice
o we could have used inherits, but by the time in v5 it was
not reliable and even report_intrastat didn't use it
o in any case we should really pay attention to the life
cycle of those objects:
+ what for instance if you generate the intrastat
document from an invoice if that a guaranteed repair
(so no financial moves; how you make sure there
won't be?)
+ what if you delete/cancel an invoice, what happen to
the intrastat document?
* I mean, overall it seems that any alternative we could think
about had way more pitfalls (synch'ing the life cycles of
different object types, thinking about all the combinations,
duplicating code...) than what we did. Please, avoid a solution
such like trying to deal with 10 common life cycle synch use
cases whatever effort it takes as that would turn into dozens of
brittle synch lines of code that will easily break in the time,
in corner cases and support no customization. Now, having
Openobject more robust toward workflow customization would
definitely help.
* Any other robust proposal we didn't think about?
Donc je retiens 2 concepts de votre branche:
-lister dans le rapport intrastat des opérations entre états (et
pas forcément entre pays)
-lister des opérations qui ne sont pas liées à des "vraies" factures
In Europe, invoices and intrastat documents are distinct documents
But in Brazil at least, those "intrastat documents" are called "nota
fiscal" (or electronic invoice; you could Google translate
http://pt.wikipedia.org/wiki/Nota_fiscal ). We can't think it should
differ in anything from a regular invoice object, even more than this
"nota fiscal" concept totally replace the "invoice" concept. OpenERP
Invoices just don't exist in Brazil, only "nota fiscal" exists, that's
one more reason I see to use the regular invoice object + extended
workflow. I think it's not worst than the "proforma" workflow branch.
Y aurait-il autre chose qui m'a échappé?
You are still missing:
* intrastat_type m2o that will determine some fiscal codes (it's
nice if localizations can extend that table of codes), need in
France and also Brazil and probably a lot more countries.
* a lot of date/price details that are explicited in the branch
commits
Sinon pour le reste, je crois que les nouveautés introduites par
la v6 sont plus intéressantes.
I don't know what you are talking about here. We have seen no benefit
of v6 regarding this issue. Of course, extracting a common basis
properly from report_intrastat would help.
Merci à toi,
Well thank you too for looking after that. We proposed that code
nearly one year ago already, but that's nice to see OpenERP is finally
taking localization more seriously into account.
At minimum, I think OpenERP S.A. should merge/clean our
report_intrastat in v6 as it's already way more useful than the
current POC.
Ideally, a base module reusable in localizations would be extracted
from it.
Again, don't hesitate to contact us for further discussion about the
feature.
Raphaël Valyi
Founder and ERP Consultant
+55 21 3010 9965
http://www.akretion.com <http://www.akretion.com/>
<http://www.akretion.com.br/>
