There are several common expressions and methods that you need to know, when dealing with IDoc.The message type defines the semantic context of an IDoc. The message type tells the processing routines, how the message has to be interpreted.The same IDoc data can be sent with different message types. E.g. The same IDoc structure which is used for a purchase order can also be used for transmitting a sales order. Imagine the situation that you receive a sales order from your clients and in addition you receive copies of sales orders sent by an subsidiary of your company.
An IDoc type defines the syntax of the IDoc data. It tells which segments are found in an Idoc and what fields the segments are made of.The processing code is a logical name that determines the processing routine. This points usually to a function module, but the processing routine can also be a
workflow or an event.The use of a logical processing code makes it easy to modify the processing routine for a series of partner profiles at once.
Every sender-receiver relationship needs a profile defined. This one determines
• the processing code
• the processing times and conditions
• and in the case of outbound IDocs
• the media port used to send the IDoc and
• the triggers used to send the IDoc
The IDoc partners are classified in logical groups. Up to release 4.5 there were the following standard partner types defined: LS, KU, LI.The logical system is meant to be a different computer and was primarily introduced for use with the ALE functionality. You would use a partner type of LS, when linking with a different computer system, e.g. a legacy or subsystem.The partner type customer is used in classical EDI transmission to designate a partner, that requires a service from your company or is in the role of a debtor with respect to your company, e.g. the payer, sold-to-party, ship-to-party.
The partner type supplier is used in classical EDI transmission to designate a partner, that delivers a service to your company. This is typically the supplier in a purchase order. In SD orders you also find LI type partners, e.g. the shipping agent.
Message Type – How to Know What the Data Means
Data exchanged by an IDoc via EDI is known as message. Messages 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 well-defined information in itis 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 are referring to 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. They usually set up a universal file format for an arbitrary kind of declaration, e.g. Intrastat, Extrastat, Export declarations, monthly reports etc. Depending on the message type, only applicable fields are filled with valid data. The message type tells the receiver which fields are of interest at all.
Partner Profiles – How to Know the Format of the Partner
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 that the partner may send.
For any such message type, the profile tells the IDoc type, which 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 means of transport depends on the receiving partner, the IDoc type and message type (context).Therefore, you may choose 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 customizsng will also determine a processing code, which can handle the received data.
IDoc Type – The Structure of the IDoc File
The IDoc type is the name of the data structure used to describe the file format of a specific IDoc.An IDoc is a segmented data file. It has typically several segments. The segments are usually structured into fields; however, different segments use different fields.The Idoc type is defined with transaction WE30, the respective segments are defined with transaction WE31.
Processing Codes
The processing code is a pointer to an algorithm to process an IDoc. It is used to allow more flexibility in assigning the processing function to an IDoc message.The processing code is a logical name for the algorithm used to process the IDoc. The processing code points itself to a method or function, which is capable of processing the IDoc data.
A processing code can point to an SAP predefined or a self-written business object or function module as long as they comply with certain interface standards.The processing codes allow you to easily change the processing algorithm. Because the process code can be used for more than one partner profile, the algorithm can be easily changed for every concerned IDoc.The IDoc engine will call a function module or a business object which is expected to perform the application processing for the received IDoc data. The function module must provide exactly the interface parameters which are needed to call it from the IDoc engine.
In addition to the writing of the processing function modules, IDoc development requires the definition of the segment structures and a series of customising settings to control the flow of the IDoc engine.
Segments define the structure of the records in an IDoc. They are defined with transaction WE31.Check first, whether the client you are working with already has a logical system name assigned.The logical system name is stored in table T000 as T000-LOGSYS. This is the table of installed clients.If there is no name defined, you need to create a logical system name . This means
simply adding a line to table TBDLS. You can edit the table directly or access the table from transaction SALE.
The recommended naming convention is
sysid + "CLNT" + client
If your system is DEV and client is 100, then the logical system name should be:
DEVCLNT100.
System PRO with client 123 would be PROCLNT123 etc.The logical system also needs to be defined as a target within the R/3 network. Those definitions are done with transaction SM59 and are usually part of the work of the R/3 basis team.
RELATED POSTS
No comments :
Post a Comment