The proposal to merge lp:~openerp-dev/openobject-addons/trunk-edi-review-hmo into lp:openobject-addons has been updated.
Description changed to: == Reviewed implementation of Electronic Document Interchange (EDI) engine == = Summary = Introduces the EDI framework for exporting and importing specific OpenERP documents between OpenERP instances and 3rd-party systems. Contains a generic framework, and a sample implementation of EDI for the following objects, complete with an automated e-mail notification: - Invoices - Sale Orders - Purchase Orders = Implementation details = The EDI framework consists in the following parts - An edi.document model for storing serialized EDI documents (JSON format) with their unique key, and exposing an API for being able to retrieve an EDI document if the unique key is known (no login/access rights needed), and to import an EDI document (relevant access rights needed). - An EDIMixin class, to be inherited by OpenERP Models that want to offer an EDI API. It contains an extensible generic implementation of the import and export methods (based on a skeleton EDI dict layout), as well as helper methods for generating/processing these documents. - A web module exposing a simple API for viewing, downloading, and importing EDI documents, as well as sample templates for the built-in EDI-enabled models [1]. The relevant modules (account, sale, purchase) have now an (in)direct dependency on the `edi` module, as well as the `email_template` module. Their default workflows now include a call to generate an EDI export upon validation of a document (Customer/Supplier invoices, Sale Orders, Purchase Orders) and to send an email notification to the corresponding Partner. The email notifications are fully customizable email templates. They include an option to pay online (including Paypal if a Paypal account is set on the issuer company details). This automatic notification is designed to be easily disabled: - the "server actions" that bind the EDI export + notification to the workflows can be easily removed, and will not be re-established after an update (declared in "noupdate" XML block) - the notification templates (Email Templates) may be edited or deleted, and will not be reset after an update (declared in "noupdate" XML block) - any Partner can be opted-out of such notification by checking the "Opt-out" option on the partner form In order to be unobtrusive for the user, the EDI generation, report printing, and email notification are done in background after the document validation, introducing no delay for the user. [1] These EDI templates should have been part of their respective modules, but technically they share many common parts, and still belong to modules that have no inter-dependencies (e.g sale vs. purchase). A dummy technical module could have been added to wrap these common parts, but being mostly made of very small QWeb(XML) templates, it was deemed easier to keep them as sample templates in the main edi module. = Tests & Demo = You may test this branch with a demo database including the account, sale or purchase module: 1a. Create a new partner with a valid email address 1b. or modify a demo partner to set a working email address, and uncheck the "Opt-out" flag on the partner form, that is checked by default for all demo partners 2. Make sure you configure a working SMTP via Administration > Configuration > Email > Outgoing Mail Servers (Extended view needed, check your preferences!) 3. Using the web client, create an EDI-enabled document (Invoice/SO/PO), validate it, and wait a few minutes: you should receive an email notification with a link to the EDI preview page. 4. The notification is not sent immediately but queued in the outgoing mail queue. You can manually force the delivery by going to Administration > Configuration > Email > Messages. 5. If you want to test the Paypal payment features, make sure to specify a Paypal account on the issuing Company details before validating the document (this works for Customer Invoices and Sale Orders in "prepay" mode) Here's a sample: - screenshot of the EDI Preview Page for a Customer Invoice: http://i.imgur.com/J0II4.png - corresponding serialized EDI Document: http://pastebin.com/vLSscafT = Tech details about the Merge Prop = This MP has a rather large diff, and its contents is broken down as follows: * + ~2000 lines: new `edi` module, including the framework source, web module with sample templates, JS and CSS, EDI export helpers for partners, * + ~1800 (3*600) lines: new `edi` package in account, sale and purchase modules to implement the EDI import/export behaviors for these modules, the mail notification template, and a related YAML test for EDI. * ~300 lines: small patches to the mail/email_template modules to support minor features needed for EDI (like a new helper in template evaluation context) * ~1200 lines: numerous small fixes to unrelated modules, that used to create their own partners for YAML tests instead of using the demo partners. With EDI installed, any validation of a SO/PO/Invoice would generate an EDI notification, which could cause random issues with the test data. EDI import/export and notifications are tested by the EDI-enabled modules, and can be safely disabled for all other tests. This is done by making sure the related partners have "Opt-out" checked, which is done automatically for all demo partners. We should not normally create partners for YAML tests. For more details, see: https://code.launchpad.net/~openerp-dev/openobject-addons/trunk-edi-review-hmo/+merge/81481 -- https://code.launchpad.net/~openerp-dev/openobject-addons/trunk-edi-review-hmo/+merge/81481 Your team OpenERP R&D Team is subscribed to branch lp:~openerp-dev/openobject-addons/trunk-edi-review-hmo. _______________________________________________ Mailing list: https://launchpad.net/~openerp-dev-gtk Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-dev-gtk More help : https://help.launchpad.net/ListHelp
