Skip to end of metadata
Go to start of metadata


Outbound IDoc´s do not reach the target system


ALE, IDoc, outbound, status 30, status 02, IDOCS_OUTPUT_TO_R3, SM58, transfer IDoc immediately, MASTER_IDOC_DISTRIBUTE, COMMIT WORK, Error passing data to port


Outbound IDoc´s do not reach the target system (using tRFC).


Most recent issues in ALE messages

Outbound IDoc´s do not reach the target system (using tRFC)

The status of these IDoc´s is 30 ‘IDoc ready for dispatch (ALE service)‘ (check the status in the transaction WE02):
IDoc´s remain in status 30 and are not sent to the recipient despite of the setting ‘Transfer IDoc  immed.’ in the Partner Profiles (transaction WE20). This status is a success status, no filtering is used in this case:
‘Receiver exists , No filters , No conversion , No version change’

- Does the system have enough ressources for an immediate processing of the IDoc´s?
Concerning necessary ressources check note no. 74141 ‘Resource Management for tRFC and aRFC', where following information can be read:
'The rule should ensure that the number of dialog processes is greater than the number of NON dialog processes (BTC,SPO,UPD,UP2) ...'
Is this rule ensured in your system?

- Go to the transaction SM58 and check, if there are any entries with the destination 'NONE', function module 'IDOCS_OUTPUT_TO_R3' in the status 'Transaction recorded'. If this is the case, start the transaction SMQS and check, whether the destination 'NONE' has been registered there! If yes, is this destination registered with the flag 'W/o tRFC'?
Is in the Partner Profiles (transaction WE20) the setting 'Transfer IDoc immed.' maintained, the function module IDOCS_OUTPUT_TO_R3 is used for triggering the sending of these IDoc´s through the destination 'NONE'.
Read note no. 1813159 'Hanging LUW´s in SM58 with the function module IDOCS_OUTPUT_TO_R3'! and register the destination 'NONE' with the flag 'W/o tRFC' and check then, if the issue still persists! Concerning the number of connections needed, also read note no. 1403974 ‘Determining the maximum connections in transaction SMQS’!

- There are no entries in SM58.
In this case, start the transaction SM12 and check the locks on the table EDIDC. If locks are released only late, or not at all, a sending of the IDoc´s is not possible. Check, who has set the locks on the table EDIDC and correct – if necessary – the coding.
The processing with release 7.00 has been changed. Immediate sending will only be started, if the application is processing a "COMMIT WORK" statement. When using tRFC, IDoc´s have become the status 03 in previous releases and despite of this new status the sending has not been executed. This was an error, which has been corrected with 7.00. If the application processes a "COMMIT WORK", it will lead to the fact, that for all arts of communication a tRFC call for the immediate sending will be saved and processed. This problem and a possible solution for the issue can be found in note no. 150202 'ALE: IDoc outbound - IDocs remain in status 30’
First of all check, whether the processing mode can be changed to collecting IDoc´s and sending them then out by using scheduled runs of the report RSEOUT00. In case the processing mode can not be changed, check, if  following coding (only if the fm MASTER_IDOC_DISTRIBUTE is used) can be applied:

1. Call the function 'DB_COMMIT'
2. All created IDoc´s must be "dequeue"-d:
   call either the function DEQUEUE_ALL, or the function
   EDI_DOCUMENT_DEQUEUE_LATER for all created IDoc´s
3. Finish them with COMMIT WORK.

The coding should look like:

Z# Programm to send IDOCs...#.
 *End of Z Programm

Instead of DEQUEUE_ALL also EDI_DOCUMENT_DEQUEUE_LATER can be used, especially if also a workflow is started.

The status of the IDoc´s is 03 (check the status in the transaction WE02):
03 is a success status from ALE point of view, with the meaning ‘Data passed to port OK’. If the IDoc´s despite of this success status do not reach the target system, check first in the transaction SM58, if there are any hanging LUW´s there! To find the right entry for the IDoc´s, use the transaction ID (TID) field for the search. The TID of the given IDoc can be found in the IDoc throught the transaction WE02 à select the IDoc number à Status records à 03 à Sts details à 1st parameter.
Are there any LUW´s, try to execute them manually! Is there a connection problem, go to the transaction SM59 and check the destination used! Is there the correct user completely maintained? Is the right logon language maintained, if the target system is not a Unicode system? Execute a connection test to the target system! Are there any further connection issues, they should be checked by the component BC-MID-RFC.

The status of these IDoc´s is 02 (check the status in the transaction WE02):

Status 02 has the meaning ‘Error passing data to port’
This error can have several reasons. One of the most frequent reason is the error message ‘Could not find code page  for receiving system’ for this status. Depending on the systems connected (Unicode, or non-Unicode), different settings need to be maintained in the transaction SM59 for the destination used.
Very detailed informations on these settings can be found in notes no. 784381 'IDoc: Status 02, code page cannot be determined' and in 613389 'ALE SAP system group with Unicode systems':
'The logon language is used on the sending system to specify the target  code page. You must set the logon language on the "Logon/Security" tab page. For this language to be used, you must in turn set the "RFC bit options" on the "Special Options" tab page. If no other options are used, enter the value "00000200" (hexadecimal display) here or select the "Use determined code page" code page. If the logon language is not maintained, no IDoc-transfer is possible. Special measures are not required for the reverse direction.'
On the other hand, by setting the flag 'Use Last Code page Found' (note no. 784381) in transaction OYEA can temporary connection issues be resolved. In this case the language from the table EDIPOACODPAG will be used.
Try to determine the codepage by testing the function module ‘NLS_GET_LANGU_CP_TAB’! Can the right code page be determined, the IDoc´s can be resent by running the report RBDAGAIN (this is also the case, if the flag in OYEA has been set).
Is the connection to the target system not working, further checks from BC-MID-RFC, or BC-CST-GW are needed.

  • No labels