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.
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?
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] <mailto:[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 likeQuel 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" facturesIn Europe, invoices and intrastat documents are distinct documentsBut 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/>
-- 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
<<attachment: qdp.vcf>>
_______________________________________________ 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
