EDI/Edifact Plugin - Versionsgeschichte

Cg: /* Getting a Schema Definition */

2020-10-23T12:56:18Z

Getting a Schema Definition

← Nächstältere Version		Version vom 23. Oktober 2020, 12:56 Uhr
Zeile 427:		Zeile 427:

	However, you can also import schemas manually via the schema parsers. These parsers read specifications in various formats and		However, you can also import schemas manually via the schema parsers. These parsers read specifications in various formats and
	return an instance of EdifactMessageSet. This holds the definitions of segments and messages.		return an instance of <COD>EdifactMessageSet</CODE>. This holds the definitions of segments and messages.
	Because schema parsing may be a relatively expensive operation (depending on the format), these schema definitions are		Because schema parsing may be a relatively expensive operation (depending on the format), these schema definitions are
	cached both in memory and as an option also in external files (schema cache folder).		cached both in memory and as an option also in external files (schema cache folder).
Zeile 443:		Zeile 443:

	For standard definitions, a more convenient automatic parsing is possible,		For standard definitions, a more convenient automatic parsing is possible,
	by asking the utility class "EdifactVersion" for a particular schema.		by asking the utility class "<CODE>EdifactVersion</CODE>" for a particular schema.
	Give it the controlling agency, version and release, as in:		Give it the controlling agency, version and release, as in:

	messageSet := EdifactVersion controllingAgency:'UN' version:'03A' release:'D'.		messageSet := EdifactVersion controllingAgency:'UN' version:'03A' release:'D'.

	Notice that this is also the proper way to get an incoming message's schema definition and done by the "EdifactMessage >> messageSchema method. This will automatically extract the correct schema definition (from the message identifier) and load it via an appropriate parser as required.		Notice that this is also the proper way to get an incoming message's schema definition and done by the "<CODE>EdifactMessage >> messageSchema</CODE>" method. This will automatically extract the correct schema definition (from the message identifier) and load it via an appropriate parser as required.
	This is also the mechanism used when a schema definition is needed by the XPath accessors or when asking for the segment group structure.		This is also the mechanism used when a schema definition is needed by the XPath accessors or when asking for the segment group structure.

Cg: /* Getting a Schema Definition */

2020-10-23T12:55:04Z

Getting a Schema Definition

← Nächstältere Version		Version vom 23. Oktober 2020, 12:55 Uhr
Zeile 431:		Zeile 431:
	cached both in memory and as an option also in external files (schema cache folder).		cached both in memory and as an option also in external files (schema cache folder).

	Assuming, a schema definition is present in SEF format in the file "~expecco/definitions/un/d10a/sef/INVOIC.SEF",		Assuming, a schema definition is present in SEF format in the file "<CODE>~expecco/definitions/un/d10a/sef/INVOIC.SEF</CODE>",
	read it with:		read it with:

Cg: /* Encoding a Message */

2020-10-23T12:52:29Z

Encoding a Message

← Nächstältere Version		Version vom 23. Oktober 2020, 12:52 Uhr
Zeile 132:		Zeile 132:
	for the opposite direction, a number of EdifactCoder classes exist, which take a decoded or constructed EDIFACT message and generate an external representation from it:		for the opposite direction, a number of EdifactCoder classes exist, which take a decoded or constructed EDIFACT message and generate an external representation from it:

	<CODE><PRE>
	EdifactCoder encode: document		EdifactCoder encode: document

	</PRE></CODE>
	generates a standard EDIFACT representation (the above).		generates a standard EDIFACT representation (the above).

	For XML output, various different formats are supported, which use different tags for the elements.		For XML output, various different formats are supported, which use different tags for the elements.
	For example,		<br>For example,

	<CODE><PRE>
	EdifactXMLCoder encode: document		EdifactXMLCoder encode: document

	</PRE></CODE>
	generates the following XML representation:		generates the following XML representation:

Zeile 188:		Zeile 187:
	</edifact>		</edifact>

	whereas		whereas:
	<CODE><PRE>
	EdifactXMLEdifactCoder encode: document		EdifactXMLEdifactCoder encode: document
	</PRE></CODE>
	would generate:		would generate:

Cg: /* Decoding a Message */

2020-10-23T12:51:10Z

Decoding a Message

@@ Zeile 109: / Zeile 109: @@
 given the following EDIFACT message in wire data form:
-UNS+S'
+ CNT+2:1'
-CNT+2:1'
+ UNT+9+1'
 assuming, the above message (as String) is held in the "msg" variable,
 it can be decoded with:
     document := EdifactDecoder decode:msg.
 This returns a structured (hierarchical) message object in "document", which consists of segments and data fields.

Cg: /* Message Subsets */

2020-10-23T12:48:35Z

Message Subsets

← Nächstältere Version		Version vom 23. Oktober 2020, 12:48 Uhr
Zeile 32:		Zeile 32:
	Many segments are specified as optional and not supported/expected by many concrete users.		Many segments are specified as optional and not supported/expected by many concrete users.

	For this typical B2B transaction systems expect and handle only subsets of the ~~over all~~ message set and subsets of the possible segment set within those messages.		For this, typical B2B transaction systems expect and handle only subsets of the overall message set and subsets of the possible segment set within those messages.

	=== Meta Descriptions ===		=== Meta Descriptions ===

Cg: /* EDIFACT Messages */

2020-10-23T12:47:37Z

EDIFACT Messages

← Nächstältere Version		Version vom 23. Oktober 2020, 12:47 Uhr
Zeile 18:		Zeile 18:
	UN/EDIFACT defines the overall format and layout of EDIFACT messages. Standard specifications are typically published twice a year.		UN/EDIFACT defines the overall format and layout of EDIFACT messages. Standard specifications are typically published twice a year.
	New revisions typically add additional data elements, additional segment types and messages.		New revisions typically add additional data elements, additional segment types and messages.
	New revisions are typically backward compatible. That is previous definitions are seldom (if ever) obsoleted.		New revisions are typically backward compatible. That means that previous definitions are seldom (if ever) obsoleted.

	All messages and segments contain a tag (or message type) field, which allows for the type of message/segment to be identified.		All messages and segments contain a tag (or message type) field, which allows for the type of message/segment to be identified.

Cg: /* Message Extraction */

2020-10-23T12:44:08Z

Message Extraction

← Nächstältere Version		Version vom 23. Oktober 2020, 12:44 Uhr
Zeile 605:		Zeile 605:

	* Encode to XML/Edifact V2<br>takes a structured edifact document object and generates a textual XML representation (XML/Edifact version 2 format).		* Encode to XML/Edifact V2<br>takes a structured edifact document object and generates a textual XML representation (XML/Edifact version 2 format).

			===== Document Extraction =====

			* Get AdviceSegment<br>extracts the advice segment from a document object.

			* Get HeaderSegment<br>extracts the header segment from a document object.

			* Get TrailerSegment<br>extracts the trailer segment from a document object.

			* Extract Messages<br>extracts all messages from a document object.

			* Extract Single Message<br>extracts a single message from a document object.

			* Get Header Fields<br>extracts specific fields from a document object.

			===== Document Construction =====

			* Create<br>create a new empty document object.

			* Set Header and Trailer Segments<br>adds segments to a document object.

			* Create from Messages<br>create a new document object.

			* Create from Single Messages<br>create a new document object.

	===== Message Extraction =====		===== Message Extraction =====

Cg: /* Misc */

2020-10-23T12:37:32Z

Misc

← Nächstältere Version		Version vom 23. Oktober 2020, 12:37 Uhr
Zeile 649:		Zeile 649:

	===== Misc =====		===== Misc =====

			* DTM Strings to DateTime<br>convert date and time.

			* DateTime to DTM Strings<br>convert date and time.

	----		----

Cg: /* Message Insertion */

2020-10-23T12:36:29Z

Message Insertion

← Nächstältere Version		Version vom 23. Oktober 2020, 12:36 Uhr
Zeile 648:		Zeile 648:
	===== Message Insertion =====		===== Message Insertion =====

			===== Misc =====

	----		----

Cg: /* Field Modification */

2020-10-23T12:36:04Z

Field Modification

← Nächstältere Version		Version vom 23. Oktober 2020, 12:36 Uhr
Zeile 641:		Zeile 641:

	===== Field Modification =====		===== Field Modification =====

			* Set by XPath<br>change a data element given an XPath locator in an edifact object.

	===== Segment Insertion =====		===== Segment Insertion =====