Hello Ferdinand, Thanks for this effort. Just a general remark about edifact (and I copy it to the framework list as some might be interested there too):
Emitting edifact messages from OpenERP as you did isn't that hard indeed, it's like reports or screen templating, it's just a stupid and boring job, and you have to be rigorous (means expensive). Now receiving edifact messages into OpenERP (might be required sometimes, we often see such requirements) is very hard to achieve. You can spend a lot of effort parsing some specific formats but in general it's a PITA. When I worked in an GDS provider for airlines, those guys used to spend literally hundreds of thousands euros per year to maintain only their edifact communication layer, it makes a half dozen guys busy all day long while if it were XML based they could do that for free using standard open source tools. But legacy is legacy and we might need to to cope with it too with OpenERP, specially for larger companies. Now, there seems to be actually one viable open source tool that deal with Edifact: the Talend ETL: http://mimishandshuna.com/jhuki/edifact/how-to-convert-an-edifact-document-to-xml-part-1/ At the same time, we at Akretion developed a very powerful OpenERP plugin for the Kettle ETL (Pentaho), TerminatOOOR http://github.com/rvalyi/terminatooor/ , based on the OOOR Technology on JRuby, that is, running in the Java world. Kettle and Talend are the two mainstream open source ETL's, both are Java based and benefit from large legacy investments there (SOAP, M$ Office, XML, feeds, JDBC, Ldap, SAP and Salesforces connectors...) and from the Java performance. Both are large commercial success and are backed with millions and decent engineers now (even if some early design mistakes will be hard to remove). The reason we went for Kettle over Talend was: it seemed simpler and I already knew it a bit. I was also thinking that Kettle had a better overall designed while very very very badly implemented I should say (but it just work and Java makes ugly code safer that say Python at some point). Kettle was also a much smaller download while Talend seemed a monster, an important feature in Brazil where we fight for bandwidth. But adapting my work for TerminatOOOR to build a similar tool for Talend wouldn't be that hard. Other possibilities exist: porting the EDI tool from Talend to Kettle (but I would not do it myself, I hope Pentaho would come with such feature in the future). But if you need it now, the easiest would be to make the two ETL's talk together, that should be fairly easy though a bit boring to install. Again we are here talking about infrastructure for large companies, certainly larger than 50 people and probably than 200, so it's okay. At the end, I would emphasis that for large organizations, it seems quite easy to have Edifact flows both ways with OpenERP along with a robust and reliable Edifact infrastructure. At Akretion, we use more and more that TerminatOOOR Kettle plugin for accounting: we do bank reconciliations with it, emit payments orders, and are also very close to create the "legal Brazilian Electronic Invoices" with it. We have now an OpenERP plugin where you can execute the Kettle transfo by just clicking a button or register it as an OpenERP cron task in a snap. Once the infrastructure is on (and it's easy to set up), it just a matter of having a Kettle transformation market place for every case: reconciliation with bank X, Y, importing initial data etc... We will demo all that soon and make all available, but it's just that currently, like everybody here we should balance those community efforts and struggle to make our OpenERP projects profitable and our customer happy. Thoughts? Raphaël Valyi Founder and ERP Consultant +55 21 3010 9965 http://www.akretion.com <http://www.akretion.com.br/> On Fri, Aug 6, 2010 at 1:29 PM, Ferdinand Gassauer <[email protected]>wrote: > Hello > we develop a very simple EDIFACT module based on account_payment. > > > Generates an UN/EDIFACT file for each payment order to be sent to a bank. > > The generation is triggered by a "Confirm Payments" or via wizard "Generate > EDIFACT". > > This works for payment within the country as well as for payments to a > foreign > country. > EDIFACT is specified by > http://www.unece.org/trade/untdid/d01a/trmd/paymul_c.htm > > The banking accounts should preferably be specified by IBAN/BIC. > > For the own company IBAN/BIC must be specified. > > Financial charges allocation is configured to (EDIFACT: "FCA+14"): > > - inland expenses are charged to ordering customer > - foreign expenses are charged to benefit recipient > > The EDIFACT business function code is hardcoded to "royalties" > (EDIFACT: "BUS+1:ROY"; see > http://www.unece.org/trade/untdid/d01a/tred/tred4025.htm) > as OpenERP does not provide this kind of information. > *** YET to be fixed *** > > The banking information must be specified for each payment line (sic!). > > The bank transfer currency must be the same as the company currency. > > Partner addresses are determined according to the function-sequence > "invoice"- > >"default"->"None". > > Transfer text is composed of invoice-number, invoice-date and invoice- > description. > > There is a default path for the EDIFACT-file. > *** Yet to be fixed *** > > -- > Best Regards > > ChriCar Beteiligungs- und Beratungs- GmbH > http://www.chricar.at/ChriCar/index.html > Dr. Ferdinand Gassauer > Official Tiny Partner > > _______________________________________________ > 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 >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
