Implementing EDI which format?

[mwl (Matt Longfield)]

As I start the process of formulating a plan/presentation for a EDI module, what is the consensus on the documents that are most useful and should be planned for?

I understand the danger of ‘to a hammer everything looks like a nail’, BUT
My specific background is ANSI-X12 with UN/EDIFACT mixed in occasionally. I’m familiar with the similarities between dialects and can easily convert between the two concept-wise. Both are multi-hierarchical delimited flatfiles and to a large degree I can picture the whole supply-chain interaction in my mind when using this model.

The way I conceptualize ‘order flow’ uses these documents as a general minimum
X12/EDIFACT
850/ORDERS Inbound SO / Outbound PO
855/ORDRSP SO/PO Acknowledgement
856/DESADV Shipping Advice
810/INVOIC Invoice

These are the ‘old school’ transactions that haven’t changed much over time.

OASIS(UBL) & UN/CEFACT added ‘new’ XML dialects that are compelling, but in my experience the ‘old school’ dialects still prevail in the industry.
In the instances where I’ve seen XML dialects used, transformation was always done and ultimately the end parties received the ‘classic’ format.

Does it make most sense to write the API using UN/CEFACT or UBL as a common dialect? - some work has already been done and the CII (Common Industry Invoice) already implemented - with the understanding that some degree of transformation will be required? Or write individual modules for each document type (X12/EDIFACT/UBL)?
In this last case the common format between the different dialect modules are the intermediate models/tables themselves for the SO, INV, ASN, etc transactions

[ced (Cédric Krier)]

@mwl

Does it make most sense to write the API using UN/CEFACT or UBL as a common dialect?

I think so. For me having an XML based format is better than a custom flat format because with XML you have schema that can validate. So it is simpler to write test and detect mistakes.

@mwl

some work has already been done and the CII (Common Industry Invoice)

This was mainly to work with Chorus Pro and for future use in Factur-X but it should give an example on how to implement.

@mwl

Or write individual modules for each document type (X12/EDIFACT/UBL)?

Indeed it is the general usage for Tryton. We do not want to restrict to one format/protocol. But you have to pick one to start. For me, it should be EDIFACT or UBL but we have already an initial EDIFACT.

@mwl

In this last case the common format between the different dialect modules are the intermediate models/tables themselves for the SO, INV, ASN, etc transactions

Of course, the orders should always be the source of data to generate the data.

[mwl (Matt Longfield)]

After an extended break, I’m back and looking for something to do, to move forward on this idea. What suggestions does the community have for me to take as a starting point? Should I be looking at UBL, maybe starting with the Order?
Any help to get back on track would be appreciated - even if it’s just to start the discussion again so I can formulate a clear path in my mind about the next best steps with the ultimate goal of developing a generic interface for EDI processing (hopefully including X12 at some point)