EDI - Delivery Instructions, Despatch Advice and other messages

[lars_wuerfel]

One of our customers would be willing to switch to Tryton, when sending EDI Despatch Advices in VDA4913 format (and printing the corresponding labels and shipment documents) would be possible.

While I can fulfill this special requirement for this single customer on my own (by help of third party software, converters and some config files), I would rather like to have EDI features integrated in Tryton.

This thread is to ask if others are also interested in having Tryton EDI modules.

In that case I would create a detailed blueprint.

Here is my rough (simplified) idea:

We have one “basic” module per EDI “sector”, for example

• Delivery Instructions (DELINS)
• Despatch Advice (DESADV), aka Advance Shipping Notice (ASN)
• Invoice / Credit
• …

These basic modules hold the “Tryton view” of the EDI document, including

• references to Tryton objects (Sale, Shipment, …)
• possibly specific EDI information which is not in the referenced objects
• customer / supplier specific configuration with default values and special mappings
• the state (“draft, validated, sent, cancelled”; or “received, validated, done, cancelled”)

For each of these “basic” modules, converters can be implemented for the required formats, for example

• UN/EDIFACT
• VDA
• ANSI X.12
• TRADACOMS
• XML
• other formats (standard or not) as needed

Each converter module has three functionalities:

• receive an EDI document from the basic module, validate it, and give back the content as a defined data structure (or a detailed error report)
• receive content from the basic module, validate it and give back a converted EDI document
• give a human readable, exact representation of an EDI document → kind of “viewer” for the document

Documentation must exist about which parts of the standard are implemented in Tryton, the basic module and each converter, and which are not.
It is no problem to start with partial support of the standard, because most customers don’t use every possible feature of the standard anyway.
And it is no problem to start with partial functionality (for example send only, no receive).
But it must be documented what exactly is supported and what is not.

Back to the “basic” modules:

For incoming EDI messages, the module converts the message and does whatever is to be done on behalf of the message (create a Sale, create a Supplier’s Invoice, etc).
The action is performed when the state is changed to “done”.

For outgoing messages, the module converts the message to the receiving Party’s desired format and gives it to the transport application.

The transport application is not part of Tryton. The transport method is agreed on between customer, supplier and other parties.
There may be multiple transport applications for one Tryton system.

Here is a simplified sketch of my idea for ASN / DESADV, to visualize my thoughts:

And here for DELFOR:

My idea of module naminng scheme is

• edocument_desadv (Despatch Advice basic module)
• edocument_desadv_vda4913 (converter)
• edocument_desadv_vda4987 (converter)
• …
• edocument_delins (Delivery Instructions basic module)
• edocument_delins_vda4905 (converter)
• edocument_delins_vda4984 (converter)
• …

There are a lot of open questions: packaging, empties, packing instructions, interface to transport applications, interface between basic module and converter, and so on, to be discussed in detail.

I would start with two blueprints:

1. General EDI integration
   • naming
   • interface: basic module ↔ converter
   • configuration
   • menu system integration
   • …
2. DESADV / Advance Shipping Notice
   • general description
   • first step: outgoing DESADV
   • first step: VDA4913 converter

So, is there some interest from the community to have a standard EDI integration similar to what I described?

[udono]

@lars_wuerfel

This thread is to ask if others are also interested in having Tryton EDI modules.

my knowledge in this topic is limited, but IMHO it would be great, when we have some additional EDI integrations in Tryton. EDI interfaces for shipment, sale and purchase would be a good complement of the existing edocument modules in Tryton.
At least EDI is a recurring topic over the years.

---

In your proposal of the naming scheme and in the conception for base modules and extension modules I miss a positioning of the already implemented Tryton project modules:

• edocument_unce: Adding many UNCE codes
• edocument_uncefact: XML export of invoice
• account_fr_chorus: CHORUS invoice automation workflow

From the perspective of a software publisher it is nearly unacceptable to change already public module names. It breaks automated migration and makes people unhappy.

So instead of a new naming scheme, why not enhance the existing modules.
Following the usual Tryton naming pattern build up from general to specific functionality, account_fr_chorus is quite good for me I read it as a module which enhances the account[ing] in France with chorus. IMHO the fr is overspecific and not necessary.

edocument_uncefact is also following the usual Tryton naming pattern and reads as a module which enhances the edocument functionality with uncefact.
This module could hold all input and output converters for uncefact conversion, as it already does for invoice output. It would also save a lot of tiny converter modules and re-use common uncefact patterns. New uncefact converter dependencies could be integrated via extras depends. The same pattern can be followed with the other formats, e.g. edocument_vda, edocument_ansi_x.12, edocument_tradacoms, edocument_xml…

The business automation modules of your proposal could be also named following the usual Tryton pattern: sale_desadv or sale_edi_desadv, purchase_desadv or purchase_edi_desadv.

A most general edocument module could implement the very basics of all converter and all automation modules… WDYT?

[ced (Cédric Krier)]

I do not think it is the Tryton ways to build a big generic hub for EDI.
For me the EDI should not be treated as a separate/external engine that does some kind of interconnexions.
Indeed each EDI document/message should have an exact correspondance in the existing business model of Tryton.
Then there should be no need for a “Tryton view” of the EDI document.

A Tryton document could be rendered in different format using the pattern of the edocument modules.

The transmission of the messages should be integrated in the existing document workflow similarly as how account_fr_chorus does by having a dedicated queue for the document and the protocol.

The reception of the message should be design in two steps.
The first is like the import of the account statement. So having an wizard to input and process the message manually.
And the second is to provide a route per protocol to automate the process (a little bit like the webhook of account_payment_stripe).

Now in order to succeed such massive development, I think it should be done gradually by implementing one message/document at a time and probably starting with the kind of message that have already an corresponding model in standard Tryton.

[pokoli (Sergi Almacellas Abellana)]

@ced

The reception of the message should be design in two steps.
The first is like the import of the account statement. So having an wizard to input and process the message manually.

Won’t be that the goal of document_incoming modules?

[ced (Cédric Krier)]

Not for most of the EDI document because they will be unambiguous. But maybe few documents may be extra supported by this mechanism.

[lars_wuerfel]

Thank you all for your valuable comments.

@udono

So instead of a new naming scheme, why not enhance the existing modules.

You’re right of course, thank you for the detailed explanation of module naming.
It has not been my intention to introduce a new naming scheme.

edocument_uncefact

From your comment I understand that edocument_uncefact only works with account_fr_chorus, which I did not install and did not look at.
Now I will have a look at this module.

@ced

A Tryton document could be rendered in different format using the pattern of the edocument modules.

Yes, I learned it, and I fully agree.

@ced

Indeed each EDI document/message should have an exact correspondance in the existing business model of Tryton.
Then there should be no need for a “Tryton view” of the EDI document.

Maybe I’ve been thinking too complicated, and “Tryton view” was for sure a poor wording.

@ced

The reception of the message should be design in two steps.
The first is like the import of the account statement. So having an wizard to input and process the message manually.

Indeed I have been inspired by the account_statement module. My idea was to have such a module per message type, and that it handles both incoming and outgoing messages.

I will rethink my idea based on your comments.

And I will (re-)read the standards, with focus on which message type corresponds to which Tryton model (or has no corresponding Tryton model at the moment) and what actions have to be carried out per message type, incoming and outgoing. Just to have the “big picture”.

This will take me some time, so please don’t await a quick answer. Meanwhile any hint or comment on the topic is most welcome.

[SISalp (Dominique Chabord)]

@ced

I do not think it is the Tryton ways to build a big generic hub for EDI.

+1
My opinion is that Tryton should become “EDI native”, not “EDI compatible”