> Syntax independent - MCIs - Messages > Details > Representations

SYNTAX INDEPENDENT COMPONENTS

Implementation Related Components


Message Content Inventory Identifier : M9730 - Objet technique, document annexé / Technisch object, bijgevoegd document - (Messages with added documents - Multimedia JPEG, TIF, PDF, PNG) - Approved , and is part of release 201801
Sender : Any
Receiver : Any
Status : 2 - Version : 5
Seq. n° n
u
d
(*)
Data element
Code list
Usage
Mandatory
Conditional
Optional (**)
Condition(s)
TB2 UN/EDIFACT representation
TB2 XML and JSON representation (***)
Indicator
Identifier
Version
10  
Message issuing date and time
No
-
-
Mand.
 
XEH+97+1+9730+++domain++++yyyymmddhhmm+xx' (=X916 and =X918) 
ExchangeUnitIssueDateTime 
20  
Message content inventory identifier
No
-
-
Mand.
 
XEH+97+1+9730+++domain++++yyyymmddhhmm+xx:::M9730' (=X943) 
ExchangeUnitBusinessContentDescription 
30 u 
Message content inventory version
No
-
-
Mand.
 
XEH+97+1+9730+++domain++++yyyymmddhhmm+xx:::M9730:5' (=X944) 
ExchangeUnitBusinessContentDescriptionVersion 
40  
GUID (Globally Unique IDentifier) du message référencé
No
-
-
Mand.
 
RFF+085:x--x' 
ReferencedMessageGuidReference 
50  
Document annexé
No
-
-
Mand.
 
DOC+xxx+x--x:x--x::x--x+status' (especially the X066 -Document name- can be useful) 
Document... DocumentDetail DocumentIdentifier CodeListIdentifier DocumentName StatusCoded 
60  
Document - Indication présence Multimédia
Yes
1
Mand.
 
DOC+xxx - GIS+EW12+x--x 
MultimediaFileIsPresentProcesscode 
70 u 
Document - Document à (faire) signer
Yes
2
Option.
 
DOC+xxx - GIS+EW23+x--x' 
DocumentToBeSignedProcesscode 
80 n 
Document - Signature digitale présente
Yes
2
Option.
 
DOC+xxx - GIS+EW24+x--x' 
DigitalSignaturePresentProcesscode 
90  
Document - Pérennité du URL
No
-
-
Cond.
mandatory if URL present 
DOC+xxx - DTM+161:x--x:001' 
UrlDurabilityDate 
100  
Document - Numéro du document
No
-
-
Option.
especially relevant when multiple similar documents must be referenced 
DOC+xxx - RFF+009:x--x' 
DocumentReference 
110 d 
Document - Signature digitale présente
No
-
-
Option.
 
DOC+xxx - BIN+EW24:x--x' 
DigitalSignaturePresentBinary 
120  
Document - URL du document
No
-
-
Cond.
mandatory if MMD absent 
DOC+xxx - FTX+063+x--x:x--x:x--x:x--x:x--x' 
UrlDocumentText 
130  
Document - MultiMediaData fichier : Composite element : Filetype, Filename, Stringbase, Stringlength, String
No
-
-
Cond.
mandatory if URL absent 
DOC+xxx - MMD+X095+X094:X096:X097:X098 (NEW Composite Data Element) (X096=base64, X098=multimediacontent) 
...Datafile MultimediaDetail MultimediafileName MIMElikeContentTransferEncoding DatastringLength Datastring 
140 u 
Message end
No
-
-
Mand.
 
XET+97 
 

(*) n u d : new / updated / deleted since previous version.

(**) Usage: The indications Mandatory / Conditional / Optional are to be understood in respect of the actual level of the Data element:
  example given; some party data-set as a whole can be optional, while, if present, the party's name within that party data-set can be mandatory.

Remark: in UN/Edifact, "Mandatory / Conditional" are notions used within the standard. And within edi-guides (a refinement of a standard) the "Conditional" can become "Required / Optional / Dependent / Advised / Not used". Ideally we should implement the same ideas.

(***) Remark: In 2020 things evolved into another "approach A" and then yet another "approach B" - It is that "appoach B" which you see here - That "approach B" is the basis of the EDIMERX development.
In TB2-XML "Namespace 2018" (as well as in eEG7-UN/CEFACT), things were/are structurally different.
EDIMERX is supporting the transition from Edifact (messages) to JSON (API's).
The so-called "Business API's" are what comes next / after such transition-phase - and there things will be structurally differrent again.