We had a problem like that an inbound EDI document came into SAP and remained in status 62 or 64. Status 62 means ‘IDOC passed to application‘ and status 64 means ‘IDOC ready to be transferred to application‘. When you check IDOCs with WE02, you just see yellow light. So IDOC didn’t go to application, so document wasn’t created… All inbound IDOCs were in that situation, it showed us we had a general problem! But what would it be?
Let’s go to SDN and let’s google.
Here what I found from SDN (its new name is SAP Community Network, maybe we might call SCN):
- [SND Forums] IDOC status change issue
- [SAP Note Number: 160670] Idocs remain in inbound with status 62
- [SAP Note Number: 836022] ALE: Link to application log in status 62
- [SAP Note Number: 92552] IDocs-Status 62 cannot be processed
- [SAP Note Number: 631039] IDoc: Problems with inbound processing using workflow
- [SAP Note Number: 194640] IDoc: Workflow is not started in RSEINB00
- [SAP Note Number: 181729] ALE: IDocs remain in status 64 / 3.X inbound
- [SAP Note Number: 168276] IDocs remain in status 64
Not too much info from googling…
- [TechTarget Expert Answer Center] Why are IDocs not passed automatically to the application and remain in 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.
Yeah the first thing to check is partner profile. If you process and inbound IDOC immediately, related message type of partner should be set as ‘Trigger immediately‘ on Inbound options tab. Yes I checked it was as we wanted ‘Trigger immediately‘.
Axel Angeli who is EAI Developer Mentor and SAP Project Manager, Logos answers this questions like that:
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.)
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:
- In the matching partner profile the processing is not set to “Trigger immediately”
- 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.
So let’s get a try.
- Prepare an EDI document for example for DESADV (Delivery: Shipping notification).
- Use WE16 to push EDI document to SAP.
- Debug EDI_DATA_INCOMING function module.
Everything seems normal. As status 62 tells us that ‘IDOC passed to application‘. The next step is IDOC processing function module should IDOC_INPUT_DESADV1 should process the IDOC. The other thing came to my mind is maybe processing function module IDOC_INPUT_DESADV1 gets short dump and stops processing and IDOC remains in status 62. I checked short dumps with ST22, but there was nothing.
So the problem would be at triggering point from EDI_DATA_INCOMING function module. For a long search and work ‘[SAP Note Number: 168276] IDocs remain in status 64‘ helped me to solve the problem.
The event receiver linkage may be performed using transaction OYEB.
Afterwards, check the workflow Customizing in transaction SWU3.You can display information on the individual steps of transaction SWU3 by selecting the small ‘I’ button on the right margin.
I went to SWU3 (Verify Workflow Customizing). Here third step Workflow RFC destination was saying “User is Locked“. There was a user name and it’s locked! Transaction SWUB (Configure Workflow RFC Destination), Customizing step (Basis Components / Basic Settings (System, SAP Business Workflow) / Create Logical destination for tRFC). So I changed the user, it fixed the problem. I tried to push another EDI document with WE16 and it worked…
T H E E N D … HappYYYY EnD 😛