openerp-expert-accounting team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

Hello Quentin and all,

Thank you taking time to consider those important issues; my inlined
answers:

2010/9/22 Quentin <qdp@xxxxxxxxxxx>

>  Hello Raphaël, hello all,
>
> the analysis of your merge proposal of report_intrastat and of the needs,
> brings me to the conclusion that it won't be straightforward to include any
> of the improvements you made. There are good ideas, but unfortunately they
> are done in a way that doesn't convince us. So we are not gonna merge this
> branch for version 6, because it seems there will be too much work (and we
> don't want to delay the release of v6) but we may keep it for a further
> version.
>

Well, I guessed that.


>
> By the way, i found really strange reading that module's code that the
> analysis were made on invoices rather than on stock.pickings. This could
> have fix the problem of uninvoiced transactions that needed to appear in the
> report intrastat, maybe in a more handy way... What's your view on that?
>

We did that because:


   - the original report_intrastat system by OpenERP S.A. was entirely
   invoice based. intrastat document for non invoiced good expedition are
   exactly the same kind of documents, that would have mean duplicated code to
   make pickings look like invoices. Furthermore there would have been issues
   with the prices, what prices should be used in the pickings, what taxes,
   that might have been complex to implement.
   - we always thought about the Brazilian requirement where clearly any
   good move required a "nota fiscal" which is basically an invoice, at least
   it's way closer from an invoice than a stock picking (we like co-production
   at Akretion, doing that European report_intrastat work first was even a way
   to finance the Brazilian localization for us).



In general, we talked about that more deeply with Renato Lima (my associate,
the leader of the Brazilian localization), and Alexis de Lattre (co-director
of Anevia, who made the spec of our improvements). Here is what we conclude,
basically we could generalize what is done in Brazil for European intrastat
documents, that would avoid altering the invoice workflow, but would make
the ERP administration more complex:

Actually in Brazil, the law are very very strict to try to fight financial
crime (there were a lot traditionally) and as a result companies are very
controlled now.
In Brazil, any time you make a product move outside from your
main warehouse, be it a product reception or expedition, you should create
the equivalent of an invoice (nota fiscal, and you should even send it
electronically now), even if you don't actually charge anything to a
customer (like warranty).
Do we need to alter the workflow of those invoices in Brazil as we did in
our report_intrastat branch?
-> No! All those invoice are validated, they generate accounting lines and
the ERP user even register payment of those invoices.
BUT:
- those "intrastat" invoices are made on a special journal and
it switches the accounts properly
- a proper "fiscal position" is automatically selected in the l10n_br module
given the "operation code" you select at the order/picking/invoice level
- the payment is made using a specific journal that will not take the
customer money to pay the good. Instead it will use your money from a
specific account, like "cost with warranty" to make the payment and balance
everything properly.


So, the Brazilian system is actually totally homogeneous here, there is no
such invoices for intrastat that need to have their workflow aborted as we
did for Anevia in our report_intrastat branch.
Alexis from Anevia found that correct and may be possible to apply in France
or other countries that need intrastat declarations.

But, currently in European countries such as France, the law doesn't force
you do create invoices for all your product moves as in Brazil, so it would
be a lot of extra daily ERP work if you force you to do so, that's the issue
and that's why we continue to think our report_intrastat module is one of
the best trade-off you could imagine.

We could also imagine the following: instead of creating special
invoices/payments for all stock moves, European companies that need detailed
intrastat reports could actually only do it for stock moves outside from
their countries. That's probably an acceptable trade-off too, and may be the
one OpenERP S.A. should follow if you don't like the way we did currently
(but please notice that to be usable it would also probably require some
little development, you can look at l10n_br/ask us to get an idea
eventually).

Also notice that in the Brazilian way where all product moves require
invoices, there are some annual stock variations in the company that are
automatically dealt with, whereas in countries such as France, if you send
products under warranty without invoicing them, you will need to do some
annual accounting corrections manually to account for those stock
variations.
So the way it's done in Brazil has also some advantages, but yeah, I doubt
European companies would like to always register any product move with
specific invoices even with those advantages.

That's why my own conclusion is that:

   - when you generalized the "intrastat" system to federal states such as
   Brazil and its "nota fiscal" (I'm curious, is there some equivalent in the
   US?), you understand that "intrastat documents" need to be invoiced based,
   not picking based (remember, we need prices, taxes an payments, we wouldn't
   duplicate all this logic over pickings, that's nonsense when invoices are
   here).
   - in Europe and France especially, companies could use our
   report_intrastat branch (
   https://code.launchpad.net/~akretion-team/openobject-addons/openobject-addons_5.0_report_intrastat)
if they need to deal with complex cases with warranted products for
   instance and if they don't want to do the next point.
   - eventually, European companies, could do the "Brazilian way", by
   creating invoices upon any product movements outside from their country, and
   creating specific journals for invoice/payment and possibly fiscal
   positions. In that case, that would be interesting to see if some more
   development is required to make this user friendly. In this case, the
   original report_intrastat module might be used (no need for a special
   invoice workflow). Unlike in Brazil, companies opting for that method, would
   still need annual manual correction of their stock if they don't do
   invoices/accounting moves for product move inside their country (to
   alleviate their daily ERP work).
   - In all cases, there are improvements we made in report_intrastat that
   are not linked to the invoice workflow modification and I think they should
   be merged in the original report_intrastat anyway because they respect the
   legislation better. This should be investigated, but here are examples of
   such commits:
      -
      http://bazaar.launchpad.net/~akretion-team/openobject-addons/openobject-addons_5.0_report_intrastat/revision/2446
      -
      http://bazaar.launchpad.net/~akretion-team/openobject-addons/openobject-addons_5.0_report_intrastat/revision/2449



For us, the only sad news with v6 is that both report_intrastat and l10n_br
deal with those requirements in their own ways (those modules are probably
incompatibles) whereas we think a common basis could be extracted and would
make them compatible.

What do you guys think?

Raphaël Valyi
Founder and ERP Consultant
+55 21 3010 9965
http://www.akretion.com

<http://www.akretion.com.br/>




>
> Anyway thanks for your comprehension and your contributions
>
> Regards
>
>
> On 10/09/10 15:58, Raphaël Valyi wrote:
>
>  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>
>
>> 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:
>       - those intrastat documents need all the characteristics of an
>       invoice
>       - we could have used inherits, but by the time in v5 it was not
>       reliable and even report_intrastat didn't use it
>       - 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.br/>
>
>
> --
> Quentin De Paoli
>
> OpenERP s.a.
> Chaussée de Namur, 40
> 1367 Grand-Rosière, Belgium
> Tel: +32.81.81.37.00 - Fax: +32.81.73.35.01
>
> Web: http://www.openerp.com
> SaaS: http://www.odoo.com
>
>