You are on page 1of 2

The IDOC_OUTPUT* and IDOC_INPUT* programs are linked to the message type and ido c type via process

code. WE82 links message type to idoc type, and WE64 links me ssage type and process code. Message type, idoc type and process code are linked together in the partner profile for a particular inbound / outbound idoc proces s. Now as for the triggering of Idoc, it works differently in inbound and outbound cases. Methods of Outbound Idoc triggering 1. If the IDoc is created automatically through output via transaction (like edi order response, or invoice). Then the triggering program will be EDI_PROCESSING for EDI and ALE_PROCESSING for ALE scenarios. These programs read the NAST entr y (created during output proposal) for the output type and then determine the co rrect outbound parameters from a unique partner profile matching the NAST record and then trigger the outbound process code. 2. We can trigger an outbound IDoc using MASTER_IDOC_DISTRIBUTE. Here we need to create the IDoc data body within the program and pass on receiver, sender, mess age type parameters to MASTER_IDOC_DISTRIBUTE which then creates it. 3. Manually creating a preconfigured IDoc message via transaction WE19 Methods of inbound IDoc triggering Inbound IDocs are triggered by either external systems (edi, wms etc) or can be triggered by inhouse applications in SAP to post a application document. 1. EDI_DATA_INCOMING can create a IDoc from a file on the OS layer. It just need s a IDoc flat file containing control and data records, it will create an Idoc f rom it if the control record successfully matches a inbound partner profile para meters. 2. IDOC_INBOUND_ASYNCHRONOUS can be triggered by external/internal programs to c reae IDoc withing SAP, whereas IDOC_INBOUND_SYNCHRONOUS can be used by inhouse S AP programs to create inbound Idoc. 3. WE19 can create and post an existing inbound Idoc to application It depends on business case: Case 1: A customer wants a order acknowledgment for his order, another wants a i nvoice in EDI formats. In this case you will enable IDoc output through output d etermination in VA01 and VF01 transactions, you will assign ORDERS, INVOIC messa ge types. The triggering function module would be EDI_PROCESSING Case 2: A business wants to distribute its material data from its main ERP syste m where all materials are maintained to non SAP warehouse management systems, pr ice cataloging systems, all of which require some part of material master. For t his you will enable ALE, create distribution model with the other systems as rec eivers, generate partner profiles and activate change pointers, which will trigg er MATMAS idoc type whenever important fields on material master are changed via MM* trxns. Here internally you are using MASTER_IDOC_DISTRIBUTE or externally B D10 transaction. Case 3: You are getting EDI messages from your business partners like payment ad vices, orders etc. You would need to create IDocs and post the documents to resp ective transactions like VA01 etc. You are getting the EDI message in a file and map it to ORDERS idoc file on OS. Now you can use EDI_INCOMING data, and if all

other configurations like partner profile, inbound process code, message and id oc types are setup, you will be able to post the payment advice or create a sale s order Case 4: You have to post a transaction internally within the system, then you wi ll use IDOC_INBOUND_ASYNCHRONOUS or SYNCHRONOUS. Case 5: You want to directly trigger SAP from an external system, posting an inb ound IDoc, you would need to call IDOC_INBOUND_ASYNCHRONOUS via tRFC connection and ALE So it all depends on what the business requirement is.

You might also like