Hello Quentin and all, Thank you taking time to consider those important issues; my inlined answers:
2010/9/22 Quentin <[email protected]> > 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 <[email protected]> > >> 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 > >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-accounting Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-accounting More help : https://help.launchpad.net/ListHelp
