Creation of BOR objects, Start and Stop eventsGo to the transaction SWO1. Enter a name for the Object type and click 'CREATE' button for creating the custom BOR Object.Enter the details required for creating the BOR objects... Create the Key fields and events of the BOR object. For creating the Key fields place the cursor on the Key fields and Click on the Create Button Create events for triggering the workflow and stopping the workflow. For creating the event place the cursor on the EVENTS and Click the create button like Key fields. Create two events. Enter the event name description etc and proceed further to create it. Similarly create another event for ending the Workflow in the similar manner like that created earlier. Now, Generate the BOR object through the generate button Release the EVENTS and subsequently release the BOR object.
Create a workflow for the generation of notification whenever an error is reached in the Inbound Idoc.Execute the transaction SWDD. Click on the CREATE button for creating the workflow for error handling. Choose the Step type to be inserted for the notification like here we are using Send Mail option for sending a mail to the user whenever any error occurred. Activate the Workflow and test it whether it is working as per the requirement. After the successful completion it is required to attach the workflow with the event. Go to the Header section (Denoted by CAP).
Enter the details of the event with which the workflow should be linked like the category, BOR object type and the event with which that should be linked. Enter here the BOR object that has been created and give the name of event created for starting the workflow. Click on the Binding Button for generating the binding between the event and the workflow. Generate the binding and click OK button to save the binding. Click on Activate / deactivate button for activating the linkage. After the successful linkage the following sign will appear on the workflow..... This shows that the workflow has been linked to the event and it will be triggered whenever that particular event will be triggered.
generate a function module and attach it to the process codeGo to SE37 transaction and copy a standard process code function module to a custom one. Do no delete any parameters from the function module as the SAP standard program itself is calling this. In that function module do the required validation and whenever the validation fails set a standard parameter 'WORKFLOW_RESULT' to 9999 from within the function module, otherwise normally proceed to set the status to 53. After the creation of function module it is required to attach it to the process code and corresponding attached to the message type at the Partner Profile stage.
The process code is being created through the transaction WE42 Go to the change mode and click the New Entries button for creating new process code.
Enter the Process Code Name, description and choose the processing type as Processing by function module. Click on the extension button of Identification. The details for the of the Process Code after clicking the identification button will be Whenever idoc arrives into the Destination system then the standard SAP triggers the Process code attached to the Message type in the partner profile. The partner profile is being maintained in the transaction WE20. Since, it is and inbound scenario so the message type and the corresponding process code will be maintained for the Inbound Parameters. Click on Create Inbound Parameters button for creating new Inbound Message type and the corresponding message type. Enter the process code for the corresponding message type. Click SAVE button for saving the changes. Whenever the IDOC arrives into the target system, it checks the partner profile and finds the corresponding process code. The process code is being linked with the function module through which the IDOC is required to be processed.
Structural relationship between IDoc and EDI Standard messages for SDSAP R/3 uses IDoc as the intermediate data for transmitting information; whereas most of the business applications use standards like EDIFACT/ ANSI X12 for transmitting business information. On higher level every message has header, detail and trailer section. Header giving identification information, detail being the content of information and trailer giving the summary information. The following diagram shows EDIFACT message ORDERS96A, IDoc ORDERS05 and ANSI X12 850(i.e. Orders) version 3020 for basic Order message.
By observing the above three message structures we can see that for EDIFACT message the Message header starts with UNB segments and includes all segments before LIN segment. For IDoc it starts with EDI_DC40 i.e. control record and includes all the segments before E1EDP01. And for ANSI X12 starts with ISA and includes all the segments before P01. In the header section various identification information is specified. As EDIFACT and ANSI X12 message being delimited messages i.e. delimiters separate fields/segments. This information is provided by EDIFACT-UNA and ANSI X12-ISA segment. Whereas in IDoc every field is positional i.e. starts at fixed position and every segment is of fixed length. Other important identification information required is sender and receiver of the message. It is specified by EDIFACT-UNB segment, IDoc-EDI_DC40 segment and ANSI X12- ISA segment. These segments also contain the date and time information of message transfer. In addition they also identify the type of business information these messages represent for example orders, order response or invoices etc. The EDIFACT-UNH segment in addition contains the EDIFACT message version and release number information like IDoc control header contains the IDoctype and extension information. This segment also used to give messages sequence number; ANSI X12-ST segment serves the same purpose. After identifying the message is of type order in UNH segment; for representing the type and function of the message in more detail EDIFACT-BGM and ANSI X12-BEG segment is used i.e. which type of order it is Purchase order, rush order or cross dock order etc. Various qualifiers used for this purpose. These segment are also used to provide customer message identifying number i.e. purchase order number for inbound order. In IDoc E1EDK01 segment used store SAP document number. This segment of IDoc also stores the currency code information whereas EDIFACT CUX or ANSI X12 CUR segments used for this purpose In EDIFACT and ANSI X12 DTM segment with different qualifiers are used to provide different date time information for example document/message creation date or order date etc. In IDoc E1EDK03 segment plays the same role. Additional free form text information/instruction can be communicated by EDIFACT-FTX or ANSI X12-NTE segment. IDoc uses E1EDKT1 with E1EDKT2 segment pair for this purpose. While transferring the information the references to the vendor and customer document
numbers are important for example offer number, sales order number, purchase order number etc. EDIFACT-RFF segments used for this purpose with different qualifiers. In IDoc E1EDK02 with qualifier 001 gives customer related identification number and E1EDK02 with qualifier 002 gives vendor related identification number of the business document. E1EDK02-DATUM field provides the respective vendor /customer document date. EDIFACT and ANSI X12 uses DTM segment for this purpose with RFF segment. In business information the different parties involved in business are important e.g. supplier party, buyer party or delivery party. This information is provided by EDIFACT-NAD ANSI X12N1..N4 segment with help of qualifier. In Idoc E1EDKA1 segment serves this purpose with qualifier. So on higher level we can see as below for header section.
The detail section of the EDIFACT, ANSI X12 Message or IDoc gives the item or product information. In EDIFACT it start at LIN and ends before UNS; for ANSI X12 it starts from PO1 and ends before CTT. And for IDoc it starts from E1EDP01 and ends before E1EDS01 segment. For every product / item in this business message these segments repeats. IDoc E1EDP01 segment is used to give basic and most frequently used line item detail. EDIFACT-LIN and ANSI X12 PO1 segment serves that purpose. These segments includes information like product identification number, item serial number within series of articles. Information regarding quantity of the product and unit used for measuring quantity is given by EDIFACT-QTY segment. In IDoc it is stored in E1EDP01 segment and for ANSI X12 P01 segment is used. Also price information is given by IDoc E1EDP01 and ANSI X12 P01 segment while EDIFACT uses PRI segment for that purpose. Date/time information related to item/product e.g. requested delivery date or shipment date is provided by IDOC E1EDP03, EDIFACT & ANSI X12 DTM segment. IDoc E1EDP19 segment is used to give additional identification information for the product specified in E1EDP01 segment. EDIFACT PIA segment is used for that purpose. This information is contained in the ANSI X12 PO1 segment additionally with respective qualifier. For giving the more free format text description of the product or item IDoc E1EDPT1/E1EDPT2 segment pair is used. In EDIFACT FTX/IMD segment is used for that purpose. In ANSI X12 PID segment is used. So on higher level we can see following structural relation between detail level segments
The trailer section of the message is important to give summary information like total number of products/item specified in detail section, total quantity or total price. These summary segments serves to check the integrity of the message. IDoc uses E1EDS01 segment with different qualifiers for give summary information. EDIFACT has UNS segment to indicate start of summary section. It contains CNT with different qualifiers for givi