May 21 2008
Message Type ,Partner Profiles
Data exchanged by an IDoc and EDI is known as messages. Message of
the same kind belong to the same message type.The message type defines the semantic context of an IDoc.The message type tells the receiver, how the message has to be interpreted.
The term message is commonly used in communication, be it
EDI or telecommunication. Any stream of data sent to a
receiver with a well-defined information in it, is known as a
message. EDIFACT, ANSI/X.12, XML and others use message
the same way.
Unfortunately, the term message is used in many contexts
other than EDI as well. Even R/3 uses the word message for
the internal communication between applications. While this
is totally OK from the abstract point of view of data
modelling, it may sometimes cause confusion, if it is unclear
whether we talk about IDoc messages or internal messages.
The specification of the message type along with the sent
IDoc package is especially important, when the physical
IDoc type (the data structure of the IDoc file) is used for
different purposes.
A classical ambiguity arises in communication with customs
via EDI. The usually set up a universal file format for any kind
of declarations, e.g. Intrastat, Extrastat, Export declarations,
monthly reports etc. Depending on the message type, only
applicable fields are field with valid data. The message type
tells the receiver, which fields are of interest at all.
Different partners may speak different languages. While the information
remains the same, different receivers may require completely different file
formats and communication protocols. This information is stored in a partner
profile.In a partner profile you will specify the names of the partners which
are allowed to exchange IDocs to your system. For each partner
you have to list the message types which the partner may send.
For any such message type, the profile tells the IDoc type, the
partner expects for that kind of message.
For outbound processing, the partner profile also sets the media to
transport the data to its receiver, e.g.
• an operating system file
• automated FTP
• XML or EDIFACT transmission via a broker/converter
• internet
• direct remote function call
The mean of transport depends on the receiving partner, the IDoc
type and message type (context).
So you may determine to send the same data as a file to your
vendor and via FTP to your remote plant.
Also you may decide to exchange purchase data with a vendor
via FTP but send payment notes to the same vendor in a file.
For inbound processing, the partner profile customizing will also
determine a processing code, which can handle the received
data.
Leave a Reply
You must be logged in to post a comment.
Not A Member? Register for Free!





