Varad
Before delving into the Using IDoc / Output Type special processing options. We had a particular necessity for making Deals Request from Buy Requests inside a similar SAP framework. This was to occur in situations where we had a between organization Buy Request – a Plant in say Country X raises a PO for a Material which can be delivered by one more Plant in Nation Y. Presently the two plants have a place with a similar Organization however will have different Organization Codes.
Ordinarily for a PO we have an ordinary outbound EDI 850 (IDoc Type: ORDERS05) going to an outside framework (say EDI) utilizing a middleware like SAP PI.
Then, at that point, we likewise have the inbound EDI 850 (same IDoc Type) which makes a deals request (Exchange VA01) in SAP ECC.
Using IDoc/Output Type special processing options. For this situation for Buy Request (Application ‘EF’), rather than setting off the typical EDI 850 outbound to XI (Medium – ‘6’ for EDI) for our exceptionally yield type, we can utilize medium ‘8’ (Unique Capability). Then we want to determine a program and subroutine name. The subroutine ought to be this way:
SET EXTENDED CHECK OFF.
INCLUDE rvadtabl. "Messages
INCLUDE rv56acom. "I/O-Structure
SET EXTENDED CHECK ON.
FORM sub_trigger_code_for_po USING returncode TYPE sy-subrc
us_screen TYPE c.
* Code Logic
ENDFORM. " sub_trigger_code_for_po
The worldwide construction nast is accessible in this subroutine. Here you can get the article key (objky) which will contain the PO number for this situation.
The custom rationale can be composed according to our prerequisite. The setting off of the result conditions can be characterized by the entrance successions and schedules related with it. Just when the given circumstances are fulfilled, then, at that point, the result condition is set off which then, at that point, calls the custom rationale carried out in the subroutine.
For our situation, in this construction we can get the PO information from concerned tables utilizing the PO number accessible in nast.
This information can be populated into the IDoc structures and Inbound IDoc made utilizing capability module IDOC_INBOUND_WRITE_TO_DB. Assuming you maintain that this IDoc should be posted, you can do a similar utilizing IDOC_START_INBOUND.
A decent methodology for doing this is do the IDoc populace and setting off rationale in foundation or a different undertaking.
One more very valuable stunt for populating standard outbound IDocs for express PO’s in any custom program is by calling the standard SAP capability module related with that result type/outbound cycle code. Like model for PO to populate the standard ORDERS05 outbound IDoc in your custom program, you can do the equivalent by simply calling IDOC_OUTPUT_ORDERS.
* Call the Function Module to Generate EDIDD Structure CALL FUNCTION 'IDOC_OUTPUT_ORDERS' EXPORTING object = wa_nast control_record_in = wa_edidc TABLES int_edidd = i_edidd EXCEPTIONS error_message_received = 1 data_not_relevant_for_sending = 2 OTHERS = 3.
Note that for this situation we would have to send the control information in wa_edidc and a sham (yet legitimate) PO number and different subtleties in wa_nast. The client exits related with this EDI/IDoc will likewise get set off for this case. Any further customization during populace should be possible there.
The populated IDoc can then effectively be made and sent utilizing MASTER_IDOC_DISTRIBUTE.
YOU MAY BE INTERESTED IN
What is EDI,ALE & IDOC ? How does it work?
SAP Launches Partner Innovation Program to Deliver Microvertical Capabilities with SAP S/4HANA Cloud
