Transformación de la sociedad

For ALE and EDI scenarios you always use the same instrument: the data, such as purchase orders, order confirmations or invoices, are sent to the respective recipient in the IDoc format, or are recevied by your system as IDocs and are subsequently transferred to the target applications.

I n t e r n a l U s e S A P P a r t n e r O n l y I n t e r n a l U s e S A P P a r t n e r O n l y

BIT300 Lesson: Message Control and IDoc Generation

Figure 62: EDI: Purchase Order at a Vendor

Up to now, the purchase orders at a vendor in our example company have been processed on paper: the purchasing employees create purchase orders in the system at head office, possibly on the basis of purchase requisitions from other departments, and send them by post to the vendor. However, in the future the vendor should receive the purchase order data electronically in an EDI standard format.

In many cases, the external vendors are not part of the company network. Therefore, the electronic communication with them is often by means of intermediary subsystems, known as EDI converters. SAP provides an open interface to such systems (CA-EDI).

The EDI subsystems assume the responsibility for all EDI-specific tasks, such as data conversion, partner profile management and process monitoring.

I n t e r n a l U s e S A P P a r t n e r O n l y

The SAP application sends an IDoc to the subsystem. In the case of a purchase order, the message type is ORDERS. The subsystem reads the IDoc and converts it into an EDI document. This document is sent to the vendor, whose EDI converter converts the incoming data into a format that can be processed in the vendor's ERP system.

Often an order is automatically created from the data of the purchase order received.

Figure 64: Port Types

Many subsystems are capable of communicating with SAP systems by means of tRFC. However, if your subsystem cannot decrypt RFC protocols, you usually use a port of the “file” type. The directory of the operating system, in which incoming and outgoing data is to be saved, is entered in the detailed settings for this port.

Partner profiles for EDI scenarios must always refer to partners of the partner types LI (vendor) or KU (customer), while the partners in ALE scenarios are always logical systems (partner type LS).

I n t e r n a l U s e S A P P a r t n e r O n l y I n t e r n a l U s e S A P P a r t n e r O n l y

BIT300 Lesson: Message Control and IDoc Generation

Figure 65: Partner Profile: Partner Type LI

Thus, for the EDI scenario represented in the first illustration of the lesson, partner profiles of partner type LI would be required. When creating such partner profiles, you always refer to the vendor master data. Therefore, if the vendor was created using the key T-BIL00, the EDI partner is also called T-BIL00.

I n t e r n a l U s e S A P P a r t n e r O n l y

The “vendor” business partner can have various functions with regard to the company.

During a procurement procedure, a vendor is first the recipient of the purchase order, then the goods supplier, later the invoicing party and finally the payment recipient. A partner does not always carry out all the functions himself. Thus a party other than the purchase order recipient can deliver the goods. For this reason, logistical appliations in SAP R/3 and SAP ECC systems work with partner functions that are assigned in the partner master data and can be changed in the application documents, if necessary.

Figure 67: Partner Profile for EDI

Therefore, when creating partner profiles for EDI partners, in contrast to ALE, you always have to enter the respective function in which a partner is sending or receiving a message.

For EDI scenarios, the distribution model you were introduced to as an important ALE element does not play any role. The application programs determine the recipient of the message from the respective application document. The communication IDoc is then created on the basis of the parameters in the partner profiles and processed further - for example, it is stored as a sequential file on the operating system level.

I n t e r n a l U s e S A P P a r t n e r O n l y I n t e r n a l U s e S A P P a r t n e r O n l y

BIT300 Lesson: Message Control and IDoc Generation

logistics applications. You can also send the information contained in your SAP R/3 or SAP ECC documents as a fax or an e-mail to employees or partners. The format in which the message is output is determined by the transmission medium, which you define in advance or which you can - depending on the default settings - specify in individual cases before the output.

Figure 68: Transmission Medium

Every time you save a new or altered purchasing document (for example, a request for quotation, a purchase order or an outline agreement), the system checks whether a message has to be created for this document, and in which format - that is, by means of which transmission medium - this message is to be output.

The individual message, such as the IDoc with the purchase order data, is always created on the basis of a message type which is defined in the Customizing of the respective application. Message types are keys to which the most important control parameters for determining and subsequently outputting messages are linked. For example, the message type for outputting purchase document data is called NEU (new printing of purchase order).

I n t e r n a l U s e S A P P a r t n e r O n l y

Figure 69: Message Types

Message types are application-specific. Every application that uses the message control is indicated by a two-character key. For example, Purchasing, which is responsible for the purchase order processing, has the key EF. To get an overview of all the applications that use the message control, you use transaction NACE. With this transaction (message types button) you can also call up the list of all the message types defined for an application.