Implementing EDI which format?

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
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

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.

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.

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.

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