openerp-expert-framework team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

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 <office@xxxxxxxxxx>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     : openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-accounting
> More help   : https://help.launchpad.net/ListHelp
>