Multiple inbound idoc

Hi,
My scenaroi is Proxy-Soap(Request)-Soap(Response)---IDOC(Multiple IDOC).
I am able to do this with one inbound idoc but i am unable to configure multiple inbound idoc with the scenario.
My proxy is sending data to soap to intialise request and get the response and send that resopnse data to idoc based on certain condition where i have three idoc at inbound side .
So in One response message i have to send data to three idoc at the same time.
Please suggest.
Regards
V Santhosh

r u using BPM?
receive-->Traformation-->send->trasformation(SOAP RespIDoc's)>Send(depend on number of IDoc's).
Map SOAP response to Multiple IDoc;s using muti mapping or you can develop individual mappings.
but exeucte Traformation step(Operation Mapping)out side BPM,i mean call Operation mapping in Interface Determination.
Regards,
Raj

Similar Messages

Config inbound Idoc

Good morning.
Please help me.
I must set up multiple inbound IDOCS, one of them is:
Type base : orders05.
message type : orders.
The process is : data is received xi / pi, and IDOCs must be created to fill the data transaction VA01 and VA02.
I have read many tutorials but I have not been clear what to do if we use a standard IDOC type base as ORDERS05.
what should I set in r / 3?
Thanks!!!

Detailed ALE configuration as follows... This might be helpful to check both your PI and ECC or R/3.
1. First - Maintain the Sender R/3 System:
SM59 : Create a RFC destination to XI
WE21 : Create a TRFC Port ->Specify the RFC Destination Created
BD54 : Create a Logical System for the Idoc Receiver
WE20 : Create Partner Profile ->Maintain Outbound and the Inbound Parameters
2. Second - Log on to XI System:
SM59 : RFC Destination for Sender System
IDX1 : Create the port to get Idoc Metadata from Sender System ( The Port Name must match the port name in the idoc header - Usually in format SAP<System ID>. eg. SAPID1 Optional Step. Not mandatory
IDX2 : Maintain the Idoc Metadata. This is needed only by XI, and not by other SAP systems. IDX2 is needed because XI needs to construct IDoc-XML from the IDoc. No other SAP system needs to do that.
3. To Enable Acknowledgement:
SXMB_ADM ->Integration Engine Configuration ->Specific Configuration ->Add New entry -> Select parameters as:
Category: RUNTIME
Parameters: ACK_SYSTEM_FAILURE
Current Value: 1
4. GO TO SLD:
Create Technical System: Choose WEB AS ABAP if the system is R/3 -> Define SAP SID, Installation Number and Database Host Name a Maintain message Server Details according to Sender System -> Maintain Client Details of Sender System ->Select a Installed Product for Sender System
Create Business System: Choose WEB AS ABAP if the system is R/3 -> Choose the Technical System and the client Created Before -> Choose the Installed Product -> Set:
Business System Role: Application System
Related Integration Server: Integration Server
5. IDOC Tunneling in XI
To prevent performance consuming XMLization and de-XMLization IDOCs are tunneled through SAP XI IDOC adapter meaning no XMLiziation is executed before the IDOC is passed onto the pipeline. Note the message is converted to UTF-8 codepage.
6. Start transaction SXMB_ADM on SAP XI.
Select option Configuration->Integration Engine Configuration and add two parameters EXTERNAL_MAPPER in the category IDOC.
Configure the parameter according to the conditions below:
If Message Code and Message Function are specified in the partner profile:
<Snd.Syst.Id>.<Snd.Syst.Client>.ReceiverPort.<Mess.Type>.<Mess.Code>.<Mess.Function>
If only the Message Code is specified in the partner profile:
<Snd. System Id>.<Snd. System Client>.ReceiverPort.<Mess. Type>.<Mess. Code>
If only Message Function is specified in the partner profile:
<Snd.Syst.Id>.<Snd.Syst.Client>.ReceiverPort.<Mess.Type>..<Mess.Function>
7. Integration Builder  Integration Directory:
Add Business System: Adapter Specific Identifiers -> 'Logical System' identical to the 'Logical System Name' in the SLD Business System
IDoc Receiver Communication Channel: port the same as XI System IDX1

Help required in posting inbound idocs

Hi,
We are facing a problem during integration testing to post inbound idocs.
The scenario is :
A custom FM is written to process the inbound idocs, which does the following processes in sequence.
1. BAPI used to create Goods Receipt
2. BDC used to create Delivery using VL01N
3. BDC used to create Handling Unit using VL02N
4. BDC used to create Post Goods Issue using VL02N
The VL01N creates a deivery, and using that delivery BDC calls VL02N to create HU.
In unit testing the idocs are success, but when multiple idocs are used in integration testing, all fails either during delivery creation or HU creation.
The error message we often get when HU is failed is : "Runtime error RAISE_EXCEPTION has occured ".
We have also incorporated a commit work and wait of 5 seconds after each BDC to avoid locking problem if any.
The partner profile is set to ' trigger by background program'.
Standard program RBDAPP01 is scheduled to collect the IDocs in status 64 and then to be processed.
The package size used is 1, inorder to process idocs one by one to avoid locking.
Should any object type be given in RBDAPP01 ?
If so, is it required to maintain any record for that object type in table TBD55 to process idocs serially in RBDAPP01 ?
Any help in this regard is appreciated.
Thanks in advance
Regards
Meena George

Hi,
We are facing a problem during integration testing to post inbound idocs.
The scenario is :
A custom FM is written to process the inbound idocs, which does the following processes in sequence.
1. BAPI used to create Goods Receipt
2. BDC used to create Delivery using VL01N
3. BDC used to create Handling Unit using VL02N
4. BDC used to create Post Goods Issue using VL02N
The VL01N creates a deivery, and using that delivery BDC calls VL02N to create HU.
In unit testing the idocs are success, but when multiple idocs are used in integration testing, all fails either during delivery creation or HU creation.
The error message we often get when HU is failed is : "Runtime error RAISE_EXCEPTION has occured ".
We have also incorporated a commit work and wait of 5 seconds after each BDC to avoid locking problem if any.
The partner profile is set to ' trigger by background program'.
Standard program RBDAPP01 is scheduled to collect the IDocs in status 64 and then to be processed.
The package size used is 1, inorder to process idocs one by one to avoid locking.
Should any object type be given in RBDAPP01 ?
If so, is it required to maintain any record for that object type in table TBD55 to process idocs serially in RBDAPP01 ?
Any help in this regard is appreciated.
Thanks in advance
Regards
Meena George

Inbound IDOC Mass processing - No status message

Hi Friends,
I am updating a database table using inbound IDOC. But in batch job when XI passes multiple IDOCS,
for some IDOCs there is no status message even though i coded for status message.
If i rerun IDOC in BD87 then it work fine.
please help.
regards,
madan

Hi Madan,
Since you are loading multiple idoc to the system due to high load in the production system data is not commiting properly. So use external commit work statement in you code. this will reduce the performance but logic will work.
COMMIT WORK [AND WAIT].
Effect
The statement COMMIT WORK completes the current SAP LUW and opens a new one, storing all change requests for the current SAP LUW in the process. In this case, COMMIT WORK performs the following actions:
It executes all subroutines registered using PERFORM ON COMMIT.
The sequence is based on the order of registration or according to the priority specified using the LEVEL addition. Execution of the following statements is not permitted in a subroutine of this type:
PERFORM ... ON COMMIT|ROLLBACK
COMMIT WORK
ROLLBACK WORK
The statement CALL FUNCTION ... IN UPDATE TASK can be executed.
Triggering an internal event for the Persistence Service of the Object Services.
If event handlers are registered by the Persistence Service, these collect the changes to the objects managed by the Persistence Service and transfer them via CALL FUNCTION ... IN UPDATE TASK to a specific update function module that is registered as the last update module.
This executes all high-priority (VB1) update function modules in the order of their registration and in a common database LUW. If you do not specify the addition AND WAIT, the program does not wait until the update work process has executed it (asynchronous updating), but instead is resumed immediately after COMMIT WORK. However, if the addition AND WAIT is specified, program processing after COMMIT WORK will not continue until the update work process has executed the high-priority update function modules (synchronous updating).
When all high-priority update function modules are completed successfully, the statement executes the low-priority (VB2) update function modules in the order of registration together in a common database LUW.
After the execution of high-priority update function modules, the individual function modules registered using CALL FUNCTION ...IN BACKGROUND TASK|UNIT are executed in a separate database LUW for each destination.
Within an update function module started using COMMIT WORK, the execution of statements that lead to a database commit is not permitted. In particular, the following are forbidden:
Thanks,
Raghav

Workitem is not generating for an Inbound Idoc

Hi All,
The problem I am facing, when inbound idoc is processing in SAP, if there are any errors occurred, it would generate a work item and that will be sent to user Inbox (SBWP) as per the workflow. Here it is not generating a work item for an inbound idoc where is there is an error. So user is not receiving work item mail to inbox, to check about the idoc error. This idoc has been processed through the function module.
Could you please let us know your input on this issue.

Hi Hitu,
The problem could be at multiple places.
To debug check the workflow which sends the workitem to the user when an error occurs.
Check if this workflow is getting triggered when the error occurs. If yes, then check the step whre this workflow fails.
Else, check the event linkage of this workflow and check if the associated event is getting triggered or not. If yes, check if the event linakge is active for the workflow.
There could be other places as well to diagnose the error.
Check if these inputs gives you some direction.
Regards,
Saumya

Break in inbound iDoc Processing.

Hi All.
Am using CRM 5.0 and have integrated the same with 3rd party delivery system via. EAI Webmethods. Following is the scenario:
Scenario: We recieve multiple inbound update iDocs which update the sales order at header level and item level with delivery specific information.
Issue: the issue is that the time difference between the frequency of the inbound iDocs is very low. Hence when the first iDoc is updating the document several other Idocs comes in the system and display with yellow status (64- IDoc ready to be transferred to application). and remains in the system with the same status. We can schedule the background job with program RBDAPP01 but that doesnot solve the issue as the document must be updated at the time idoc comes into the system.
Can someone please suggest wht should we do for resolving this issue. I'm not a middleware consultant hence comprehensive help will be appriciated.
Cheers
Avi

Hi Vijay,
The IDoc is a Delivery IDoc. The OSS Note that you have sent is for a similar error but is related to APO systems and hence I don't think it is related.
Has anyone encountered this error before...?
It says 'Conversion of dimensionless units is not possible'....
Regards,
SP.

Help in inbound idoc posting using bdc

Hi,
We are facing a problem during integration testing to post inbound idocs.
The scenario is :
A custom FM is written to process the inbound idocs, which does the following processes in sequence.
1. BAPI used to create Goods Receipt
2. BDC used to create Delivery using VL01N
3. BDC used to create Handling Unit using VL02N
4. BDC used to create Post Goods Issue using VL02N
The VL01N creates a deivery, and using that delivery BDC calls VL02N to create HU.
In unit testing the idocs are success, but when multiple idocs are used in integration testing, all fails either during delivery creation or HU creation.
The error message we often get when HU is failed is : "Runtime error RAISE_EXCEPTION has occured ".
We have also incorporated a commit work and wait of 5 seconds after each BDC to avoid locking problem if any.
The partner profile is set to ' trigger by background program'.
Standard program RBDAPP01 is scheduled to collect the IDocs in status 64 and then to be processed.
The package size used is 1, inorder to process idocs one by one to avoid locking.
Should any object type be given in RBDAPP01 ?
If so, is it required to maintain any record for that object type in table TBD55 to process idocs serially in RBDAPP01 ?
Any help in this regard is appreciated.
Thanks in advance
Regards
Meena George

Refer these links and see if they are useful:
http://help.sap.com/saphelp_nw04/helpdata/en/0b/2a66c9507d11d18ee90000e8366fc2/content.htm
Regards,
Ravi

Multi Mappng - different inbound idocs

Hi,
I have a requirement to map a single outbound message into inbound different idocs.
Source: Src_mesg1,
Target: Idoc1 and idoc2.
I am able to create Operation mapping with different inbound idocs.
But not able to create message mapping with different target idocs.
Please suggest .
Thanks
sneha

Hi,
>Cant i acheive the same through simple message mapping ? Single source message and multiple target idocs : Idoc1 and idoc2.
Not if that are different IDoc types, in that case you need BPM
Regards,
Udo

Inbound Idoc customer number conversion

I am new to EDI and have a question to ask you both about inbound IDOC's. We have customers sending remittance advices through EDI. The customer numbers in them are their own customer numbers. In SAP, we maintain different customer numbers. Where do the mapping of the customer numbers take place -- In the EDI subsytem itself or in SAP? If in SAP, can you let me know the procedure to do this.
Any help will be appreciated and points awarded.
Thanks,
Nile.

Hey Fren,
1. Data Mapping
Within the framework of SAP EDI, the conversion of a business document in IDoc format to an EDI standard format (and vice versa) is the most important task performed by a subsystem. This process is resource intensive and, hence, is better done at the subsystem level than within SAP. The following conversions and translations are carried out by the subsystem.
Creating a control record for each inbound IDoc.
An inbound IDoc must have a control record. The EDI subsystem builds the control record using the information stored in its local repository or from the SAP repository.
Removing the control record during the outbound process.
The control record in the IDoc file is used by the subsystem for housekeeping functions, such as locating the trading partner profile. The data on the control record is not needed for translating the content of the EDI documents.
Translating data from IDoc format to EDI format.
For an outbound transaction, the EDI subsystem converts data in the IDoc format to a suitable EDI format.
Translating data from EDI format to IDoc format.
For an inbound transaction, the EDI subsystem converts data in the standard EDI format to IDoc format.
Bundling and unbundling IDocs.
If several IDocs are passed to the EDI subsystem in one file, the subsystem separates them into individual documents. Similarly, on the inbound process the subsystem can bundle multiple IDocs into a single file to improve performance.
2 Maintaining the Partner Profile
A partner is defined as the business partner with whom you conduct business and exchange EDI documents. These partners are not necessarily the same as the partners in the partner profile of SAP. However, the concept is quite similar. In SAP, the partner profile maintains parameters specific to the IDoc process, and in the subsystem the partner profile maintains parameters specific to the EDI process. Some typical attributes in a partner profile are
· A unique partner number
· The partner type (Customer, Vendor)
· The standard used (EDIFACT, ANSI X12, and so on)
· The version of the EDI standard
· The EDI message exchanged (850, 860, ORDERS, ORDCHG)
· A functional acknowledgment flag
3 Triggering the Inbound Process
After receiving an inbound EDI transmission and creating an IDoc file, the subsystem is often responsible for triggering the inbound process. SAP provides a program named startrfc to start any RFC−enabled function module from the operating system level. For the EDI process, the subsystem uses the startrfc program to
trigger the function module EDI_DATA_INCOMING. Chapter 6, "Configuring Basic EDI Components," provides the complete details and parameters of the startrfc progam.
4 Reporting Process Status to SAP
In an outbound process, after an IDoc has been transferred from SAP to the subsystem, SAP loses control over the process. However, SAP maintains visibility into the process by requiring the subsystem to report on the status of the process. SAP provides a file interface for the subsystem to send a status report at every milestone.
I hope you got some idea from this process.....
<REMOVED BY MODERATOR>
Warm Regards,
Abhi...
Edited by: Alvaro Tejada Galindo on Apr 25, 2008 4:36 PM

Inbound IDOC File Testing

Hello friends,
Could any one guide me in preparing the Test file for testing Inbound IDOC (message type: ACC_DOCUMENT) and (basic type: Acc_Document01).
Only these are the 4 segments I am going to use.
E1BPACHE09
E1BPACGL09
E1BPACAR09
E1BPACCR09
Basically I would like to know how to create a template to upload multiple documents during testing and the procedure to upload.
I am able to test post one document at a time thru WE19.
Thanks for ur help.
Sam.

Did you find the answer for you question?
I am trying to do the same to run a LSMW that load data through FB50 but I don't find how to fill the structures.
Thanks.

Inbound Idoc Testing File Template

Hello friends,
Could any one guide me in preparing the Test file for testing Inbound IDOC (message type: ACC_DOCUMENT) and (basic type: Acc_Document01).
Only these are the 4 segments I am going to use.
E1BPACHE09
E1BPACGL09
E1BPACAR09
E1BPACCR09
Basically I would like to know how to create a template to upload multiple documents during testing and the procedure to upload.
I am able to test post one document at a time thru WE19.
Thanks for ur help.
Sam.

Hi Sam,
Try this, to my knowledge this is only to test if idoc is posted properly or not (to check the configuration), we can only post one Idoc at a time i think...but try this...
am not sure but try this...
Go to WE19-> acc_docume*>control on the data segment and copy it->insert(next to copy in menu bar) the segment at the same level> fill the data and post it ...to see..just try this...
Thanks
Ajay

Multiple Inbound delivery PGR

Hi All,
I am using IDOC_INPUT_DELVRY for Post Goods Receipt of an inbound delivery. My requirement is I have to Finalize multiple Inbound deliveries at same time. I copied the E1EDL20 segment and pasted it at the same level 4 times. I am passing 4 Inbound deliveries in the idoc for PGR. But the last inbound delivery which is the bottom most segment of the idoc only gets PGRed.
The other inbound deliveries, the batchs are getting created. But the IDOC_INPUT_DELVRY has the standard code for performing the PGR, then it should do the PGR for multiple E1EDL20 segments. But it is not happening.
Do I need to do something additional when I am passing multiple Inbound deliveries for processing.
Regards,
Joseph M

Hi...
First create inbound delivery and do GR against inbound delivery by using t code MB0A
Once GR is completed create TO with reference to Material document .
Config - For inbound delivery document type remove putaway relevancy .
Spro - Logistics execution - shipping - deliveries - define item category for deliveries
here for relevant item category remove putaway relavancy .
Hope it helps
Jinoy

Step-by step procedure for INBOUND IDOC (VENDOR CREATE / CHANGE)

Hi ,
Can any body provide me the step-by-step procedure for Inbound IDOCS.
As i'm new to this i need the the clarification between Inbound & outbound idocs.
How can we differentiate both?
where to define outbound & where to define Inbound?
( If possible Please explain me the procedure for Vendor Create through INBOUND IDOCS )
Thanks in advance..

Hi,
Ale Technology is SAPu2019s technology to support distributed yet integrated processes across several SAP systems.
Outbound Process:
ALE Outbound Process in SAP sends data to one or more SAP Systems. It involves four steps.
1. Identify the need of IDoc: This step starts upon creating a application document, can relate to a change to a master data object.
2. Generate the Master IDoc: The document or master data to be sent is read from the database and formatted into an IDoc format. This IDoc is called as a Master IDoc.
3. Generate the Communication IDoc: The ALE Service layer generates a separate IDoc from the Master IDoc for each recipient who is interested in the data. Separate IDocs are generated because each recipient might demand a different version or a subset of the Master IDoc. These recipient-specific IDocs are called Communication IDocs and are stored in the database.
4. Deliver the Communication IDoc: The IDoc is delivered to the recipients using an asynchronous communication method. This allows the sending system to continue its processing without having to wait for the destination system to receiver or process the IDoc.
Inbound Process:
The inbound process receives an IDoc and creates a document in the system.
1. Store the IDoc in the database: The IDoc is received from the sending system and stored in the database. Then the IDoc goes through a basic integrity check and syntax check.
2. Invoke the Posting Module: The control information in the IDoc and configuration tables are read to determine the posting program. The IDoc is then transferred to its posting program.
3. Create the Document: The posting program reads the IDoc data and then creates a document in the system. The results are logged in the IDoc.
Over view of IDocs:
IDoc is a container that is used to exchange data between any two processes. The document represented in an IDoc is independent of the complex structure SAP uses to store application data. This type of flexibility enables SAP to rearrange its internal structure without affecting the existing interface.
IDoc interface represents an IDoc Type or IDoc data. IDoc Type represents IDocu2019s definition and IDoc Data is an instance of the IDoc Type.
IDoc Types:
IDoc type structure can consist of several segments, and each segment can consist of several data fields. The IDoc structure defines the syntax of the data by specifying a list of permitted segments and arrangement of the segments. Segments define a set of fields and their format.
An IDoc is an instance of an IDoc Type and consists of three types of records.
i. One Control record: each IDoc has only one control record. The control record contains all the control information about an IDoc, including the IDoc number, the sender and recipient information, and information such as the message type it represents and IDoc type. The control record structure is same for all IDocs.
ii. One or Many Data records: An IDoc can have multiple data records, as defined by the IDoc structure. Segments translate into data records, which store application data, such as purchase order header information and purchase order detail lines.
iii. One or Many Status records: An IDoc can have multiple status records. Status record helps to determine whether an IDoc has any error.
Message in IDoc Type:
A Message represents a specific type of document transmitted between two partners.
Outbound Process in IDocs:
Outbound process used the following components to generate an IDoc. A customer model, and IDoc structure, selection programs, filter objects, conversion rules, a port definition, an RFC destination, a partner profile, service programs, and configuration tables.
The Customer Model:
A customer model is used to model a distribution scenario. In a customer model, you identify the systems involved in a distribution scenario and the message exchanged between the systems.
Message control:
Message control is a cross application technology used in pricing, account determination, material determination, and output determination. The output determination technique of Message control triggers the ALE for a business document. Message control separates the logic of generating IDocs from the application logic.
Change Pointers:
The change pointers technique is based on the change document technique, which tracks changes made to key documents in SAP, such as the material master, customer master and sales order.
Changes made to a document are recorded in the change document header table CDHDR, and additional change pointers are written in the BDCP table for the changes relevant to ALE.
IDoc Structure:
A message is defined for data that is exchanged between two systems. The message type is based on one or more IDoc structures.
Selection Program:
Is typically implemented as function modules, are designed to extract application data and create a master IDoc. A selection program exists for each message type. A selection programu2019s design depends on the triggering mechanism used in the process.
Filter Objects;
Filter Objects remove unwanted data for each recipient of the data basing on the recipients requirement.
Port Definition:
A port is used in an outbound process to define the medium in which documents are transferred to the destination system. ALE used a Transactional RFC port, which transfers data in memory buffers.
RFC Destination:
The RFC destination is a logical name used to define the characteristics of a communication link to a remote system on which a function needs to be executed.
Partner Profile:
A partner profile specifies the components used in an outbound process(logical name of the remote SAP system, IDoc Type, message type, TRFC port), an IDocu2019s packet size, the mode in which the process sends an IDoc (batch versus immediate), and the person to be notified in case of error.
Service Programs and Configuration Tables:
The outbound process, being asynchronous, is essentially a sequence of several processes that work together. SAP provides service programs and configuration tables to link these programs and provide customizing options for an outbound process.
Process flow for Distributing Transactional Data:
Transactional data is distributed using two techniques: with Message control and without message control.
Process flow for Distributing Master Data:
Master data between SAP systems is distributed using two techniques: Stand alone Programs and Change Pointers.
Triggering the Outbound Process via Stand-Alone Programs:
Stand-Alone programs are started explicitly by a user to transmit data from one SAP system to another. Standard Programs for several master data objects exist in SAP. Ex. The material master data can be transferred using the RBDSEMAT program or transaction BD10.
The stand-alone programs provide a selection screen to specify the objects to be transferred and the receiving system. After the stand-alone program is executed, it calls the IDoc selection program with the specified parameters.
Triggering the Outbound Process via Change Pointers:
The change pointer technique is used to initiate the outbound process automatically when master data is created or changed.
A standard program, RBDMIDOC, is scheduled to run on a periodic basis to evaluate the change pointers for a message type and start the ALE process for distributing the master data to the appropriate destination. The RBDMIDOC program reads the table TBDME to determine the IDoc selection program for a message type.
Processing in the Application Layer:
The customer distribution model is consulted to make sure that a receiver has been defined for the message to be transmitted. If not, processing ends. If at least one receiver exists, the IDoc selection program reads the master data object from the database and creates a master IDoc from it. The master IDoc is stored in memory. The program then calls the ALE service layer by using the function module MASTER_IDOC_DISTRIBUTE, passing the master IDoc and the receiver information.
Processing in the ALE Interface Layer:
Processing in the ALE Layer consists of the following steps:
u2022 Receiver Determination: The determination of the receiver is done through Customer Distribution Model.
u2022 IDoc Filtering: if an IDoc filter is specified in the distribution model for a receiver, values in the filter are compared against the values in the IDoc data records. If a data record does not meet the filter criteria, it is dropped.
u2022 Segment Filtering: For each sender and receiver combination, a set of segments that are not required can be filtered out.
u2022 Field conversion: Field values in data records are converted by using the conversion rules specified for the segment.
u2022 Version change for segments: Segments are version-controlled. A new version of a segment always contains fields from the preceding version and fields added for the new version. Release in IDoc type field of the partner profile to determine the version of the segment to be generated.
u2022 Version change for IDocs: IDocs are also version controlled. The version is determined from the Basic Type field of the partner profile.
u2022 Communication IDocs generated: The final IDoc generated for a receiver after all the conversions and filtering operations is the communication IDoc. One master IDoc can have multiple communication IDocs depending on the number of receivers identified and the filter operations performed. IDoc gets the status record with a status code of 01 (IDoc Created).
u2022 Syntax check performed: IDoc goes through a syntax check and data integrity validation. If errors found the IDoc get the status of 26 (error during syntax check of IDoc u2013 Outbound). If no errors found the IDoc gets the status 30 (IDoc ready for dispatch u2013 ALE Service).
u2022 IDoc dispatched to the communication Layer: In the ALE process, IDocs are dispatched using the asynchronous RFC method, which means that the sending system does not await for data to be received or processed on the destination system. After IDocs have been transferred to the communication layer, they get a status code 01 (Data Passed to Port OK).
Processing in the Communication Layer:
To dispatch an IDoc to a destination system, the system reads the port definition specified in the partner profile to determine the destination system, which is then used to read the RFC destination. The RFC destination contains communication settings to log o to the remote SAP system. The sending system calls the INBOUND_IDOC_PROCESS function module asynchronously on the destination system and passes the IDoc data via the memory buffers.
Inbound Process in IDocs:
An inbound process used IDoc structure, posting programs, filter objects, conversion rules, a partner profile, service programs, and configuration tables to post an application document from an IDoc.
Posting Program:
Posting programs, which are implemented as function modules, read data from an IDoc and create an application document from it. A posting program exists for each message. Each posting program is assigned a process code. A process code can point to a function module or a work flow. In the standard program process codes always point to a function module.
Ex. The posting program for message type MATMAS is IDOC_INPUT_MATMAS which has a process code MATM.
Workflow:
A workflow represents a sequence of customized steps to be carried out for a process. The workflow management system is used to model the sequence, identify information required to carry out the steps and identify the person responsible for the dialog steps.
Partner Profile;
A partner profile specifies the components used in an inbound process (partner number, message type, and process code), the mode in which IDocs are processed (batch versus immediate), and the person to be notified in case of errors.
Process flow for the Inbound process via a Function Module:
In this process, IDocs are received from another system and passed to the posting function module directly.
1. Processing in the communication Layer:
The IDOC_INBOUND_ASYCHRONOUS program, triggered as a result of an RFC from the sending system, acts as the entry point for all inbound ALE processes. The IDoc to be processed is passed as an input parameter. Control is transferred to the ALE/EDI layer.
2. Processing in the ALE/EDI Interface Layer:
u2022 Basic integrity check: A basic integrity check is performed on the control record.
u2022 Segment Filtering and conversion: Filtering out unwanted segments and carry out any required conversion of field values.
u2022 Creation of Application IDoc: The application IDoc is created and stored in the database and a syntax check is performed. If there are errors it gets status code of 60 (Error during Syntax check of IDoc u2013 Inbound). At this point a tangible IDoc, which can be monitored via one of the monitoring transactions, is created and the IDoc gets status code 50 (IDoc Added).
u2022 IDoc Marked ready for Dispatch: IDoc gets the status code 64 (IDoc ready to be passed to application).
u2022 IDoc is passed to the posting program: The partner profile table is read. If the value of the Processing field is set to Process Immediately, the IDoc is passed to the posting program immediately using the program RBDAPP01.
3. Processing in the Posting Module:
The process code in the partner profile points to a posting module for the specific message in the IDoc. The posting program implemented as a function module either calls a standard SAP transaction by using the Call Transaction command for posting the document or invokes a direct input function module.
The results of execution are passed back via the function moduleu2019s output parameters. If the posting is successful IDoc gets the status code 53 (Application Document Posted) or it gets status code 51 (Error: Application Document Not Posted).

Creation of Sales Order and Service Contract from Inbound IDOC

Hi Experts,
My requirement is to create a Sales Order as well as a Service Contract from one Inbound IDOC. I am getting the Inbound IDOC from a third Party. The message type is ORDERS and Basic Type is ORDERS02. How ever i am using an extension type IDOC which carries all the required data for Sales Order and Service Contract. My requirement is like, to create a Sales Order first.
I have created a Z FM which is attached to the Process Code and subsequently to the message type. Inside the FM i an calling FM 'IDOC_INPUT_ORDERS' for creation of Sales Order. After that i am changing the IDOC data for the Document Type. I am changing the document type which is responsible for Contract Creation.
Then I am again calling the FM 'IDOC_INPUT_ORDERS' for creation of Contract with the help of IDOC data. But here the Contract is not getting created. It's getting failed during the Batch input session.
I need to solve this problem as soon as possible. Please help me. If there are any other options also please share.
Thanks in Advance.
Regards,
Priyabrata

Actually there is problem with BDCDATA. Inside the FM it's calling transaction with help of BDCDATA. If i am creating a Sales order or contract alone its creating successfully. But when i am trying to create both, it's retuning sy-subrc '1001' after calling the transaction on the second attempt. Is there any problem with BDCDATA like we can't handle with less time gap? Please help and give your inputs.
Regards,
Priyabrata

Creation of Service Contract from Inbound IDOC

Hi Experts,
I am using Inbound IDOC type ORDERS02 with message type ORDERS for creation of Sales Order. Now my requirement is like to create a Service Contract from that Inbound IDOC. The IDOC type contains all the data require to create a Service Contract. The scenario is like, after creation of Sales Order it will check for the corresponding Service Contract exits or not by querying on a Z table which contains all those entries.
So my idea is to create a Z Program, in which it will check for the Service Contract and will create the same by reprocessing the same IDOC or by calling some Function Module. Please suggest how shall i proceed to create a Service Contract.
Is there any way to reprocess the IDOC or to collect the Data from the IDOC segments pass them to a FM which is responsible for creation of Inbound IDOC. Please suggest if this is feasible.
Thanks in Advance.
Regards,
Priyabrata.

Actually there is problem with BDCDATA. Inside the FM it's calling transaction with help of BDCDATA. If i am creating a Sales order or contract alone its creating successfully. But when i am trying to create both, it's retuning sy-subrc '1001' after calling the transaction on the second attempt. Is there any problem with BDCDATA like we can't handle with less time gap? Please help and give your inputs.
Regards,
Priyabrata

Multiple inbound idoc

Similar Messages

Maybe you are looking for