Q
Problem solve Get help with specific problems with your technologies, process and projects.

Why are IDocs not passed automatically to the application and remain in status 64?

We are a nSAP site currently on version 4.5b (soon to upgrade to 4.6b.) Last year we successfully implemented EDI invoice processing via the IDoc interface into MM. We're having problems processing the INVOIC real-time and therefore had to schedule BD20 to run daily. Could you advise us of possible reasons why the process linked to our PARTNER is not invoked automatically after the IDOC has been created successfully with status 64?

The radio button on WE20 is currently set to trigger by background program rather than trigger immediately but this was done because we had to schedule BD20.

Background: We are receiving the supplier invoice into our EDI subsystem where the INVOIC EDIFACT message is mapped to the INVOIC02 IDoc. The function module EDI_DATA_INCOMING is then trigged via a Remote function call from the EDI subsystem. The IDoc is created in SAP with status 64 but subsequent processing is not triggered. We are therefore not able to process incoming invoices real-time but scheduled only as mentioned above.


The ultimate answer to your questions lies already within your question itself: you have to set the "Trigger immediately" option in the partner profile. This can be done individually for every combination of partner/message code/message function/message type. If you send the IDocs from two different locations that have to be processed differently, make use of the message code and message function to further discriminate the messages (fields MESCOD and MESFCT in the IDoc header EDIDC.)

Explanations:
If an IDocs remains in status 64, it means that the processing within the IDoc engines did not reach its end, where the new status could be set. There are two principal reasons:

1. In the matching partner profile the processing is not set to "Trigger immediately"

2. The application that processes the IDoc abnormally ends with a fatal error (crashes). If this happened you will see a trace in the system log (ST22). In this case have the satellite system write the file to disk but you trigger the EDI_DATA_INCOMING. Then start EDI_DATA_INCOMING from SE37 manually and debug yourself through the individual steps. A good start would be to set a break-point in the application handling function (in your case: IDOC_INPUT_INVOIC_MM or IDOC_INPUT_INVOIC_FI).

One more note: I noticed that you say the EDI_DATA_INCOMING is triggered via RFC. Can you consider calling the standard RFC-Gateway for IDoc, which is calling IDOC_INBOUND_ASYNCHRONOUS or IDOC_INBOUND_SYNCHRONOUS via RFC and passing the data directly? EDI_DATA_INCOMING has in fact been delivered for batch processing EDI data files, that are dumped behind the scenes in some incoming directory, not for RFC calls.


This was last published in March 2003

Dig Deeper on SAP Basis

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchERP

SearchOracle

SearchDataManagement

SearchAWS

SearchBusinessAnalytics

SearchContentManagement

SearchHRSoftware

Close