Tips about Error EA299 'Could not write IDoc to file' for RFFOEDI1

[Jigang_Zhang张吉刚]

There is one standard IDOC type DIRDEB with Basic type PEXR2003 used to generate EDI payment documents. It worked fine all the time until last week when one user complained one file was missing in the desired AL11 directory even with multiple re-runs.

It's not a trick issue, here just record this RFFOEDI1 analysis procedure for reference. Please jump to the bottom conclusion part if not interested in those details.

 

1. EDI payment file generation processing with DIRDEB

I got this payment file generation processing from the user and actually, it is quite simple:

• Report RFFOEDI1 to generate IDOC file;


• Report RSEOUT00 (transaction WE14)  to process the IDOC.

2. IDOC DIRDEB-related setting

It's pure standard after checking the outbound setting for DIRDEB through WE20.

But the file directory is customized for sure and can be found at Port parameters through WE21.

• #1. The AL11 file directory to save the EDI file generated by RFFOEDI1


• #2. The Function module for file name customized. Here we pass the company code through ABAP memory at user-exit. (Please find details below.)

3. Customizing part for File name

• The main program is SAPLIEDP (EDI - Payment/Payment Advice Processing);


• Include program is LIEDPF01(EDI-REMADV/PAYEXT, Outgoing Subprograms);


• User-exit include program is LIEDPF0J;


• Exit no. is customized, this case is '903'. The example code is:

*----------------------------------------------------------------------*

*   INCLUDE ZXF08U07                                                   *

*----------------------------------------------------------------------*



* To dynamically create the EDI output file based on payment run

* company code



DATA: W_BUKRS LIKE REGUH_DATA-ZBUKR,

      WA LIKE INDX.



WA-AEDAT = SY-DATUM.

WA-USERA = SY-UNAME.

WA-PGMID = SY-REPID.



W_BUKRS = REGUH_DATA-ZBUKR.



EXPORT W_BUKRS = W_BUKRS TO DATABASE INDX(ZZ)

               CLIENT SY-MANDT ID 'EDI_PAYEXT_PEXR2001_BUKRS'

               FROM WA.

• Function module for creating dynamic file name

FUNCTION Z_EDI_PATH_CREATE_T_CTRY_DT_TM .

*"----------------------------------------------------------------------

*"*"Local interface:

*"  IMPORTING

*"     VALUE(DATATYPE) LIKE  EDIPO-ACTRIG

*"     VALUE(DIRECTORY) LIKE  EDIPO-OUTPUTDIR

*"     VALUE(FILENAME) LIKE  EDIPO-OUTPUTFILE

*"     VALUE(CONTROL) LIKE  EDIDC STRUCTURE  EDIDC

*"  EXPORTING

*"     VALUE(PATHNAME) LIKE  EDI_PATH-PTHNAM

*"----------------------------------------------------------------------



* This FM enables us to create dynamic EDI filenames based on the

* payment run company code



* Get the Company Code which gets set from EXIT_SAPLIEDP_903

  DATA: w_bukrs LIKE reguh-zbukr.

  DATA: wa LIKE indx.

  IMPORT w_bukrs = w_bukrs FROM DATABASE indx(zz)

                 CLIENT sy-mandt ID 'EDI_PAYEXT_PEXR2001_BUKRS'

                 TO wa.

  file2-field2 = w_bukrs.





  CASE datatype.

    WHEN 'I'.

      MOVE 'I_' TO file2-field1.

    WHEN 'O'.

      MOVE 'O_' TO file2-field1.

    WHEN 'S'.

      MOVE 'S_' TO file2-field1.

  ENDCASE.

  DO.

    IF file2-field2 CA space.

      REPLACE ' ' WITH '_' INTO file2-field2.

    ELSE.

      EXIT.

    ENDIF.

  ENDDO.

  GET TIME.

  MOVE sy-datum  TO file2-field3.

  MOVE sy-uzeit  TO file2-field4.

  MOVE directory TO path-directory.

  MOVE file2     TO path-filename.

  CONDENSE path NO-GAPS.

  MOVE path TO pathname.

ENDFUNCTION.

4. The root of the file missing issue

For this missing file issue, there's no need to check the above user exit as it's not related to file generation. The quickest approach is to find any DIRDEB Idoc document through WE05. Check the status records below which point out the wrong segment part clearly with sequence number.

Then go to the IDoc segment 25 and check if any special character exists. In my case, there is one abnormal double quotation which is very likely copied from somewhere in the local language. This special character leads to this failure when writing IDOC to file in the AL11 directory.

After finishing the analysis I found one SAP note: 2368096 describes the same symptom and gives the solution~

Another lesson learned...I should check SAP notes before checking anything by myself!~

 

Conclusion:

1, Find out the Message type through user inputs;

2, Get any IDOC number with a red traffic light through Message type;

3, Check status records '02' and get the sequence number that leads to the issue;

4, Goto Idoc segment accordingly and check if any characters are there;

5, Remove the special character and re-processing this Idoc through WE19;

6, Go to the AL11 directory and check whether the file has been generated correctly, if the issue is still there then go back to step 4.

 

Added Nov-22-2023

The reason why I've had no updates for the last few months: I've been facing an SAP logon issue with the logon page being stuck all the times~No idea how to fix this...

VM123:21 Refused to load the script 'https://munchkin.marketo.net/munchkin.js' because it violates the following Content Security Policy directive: "script-src https://*.zscalertwo.net 'self' 'unsafe-inline' 'unsafe-eval' https://*.gigya.com https://*.gigya-api.cn https://*.account.sap.com https://assets.adobedtm.com https://*.trustarc.com https://*.mtcaptcha.com". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.

(anonymous) @ VM123:21
socialize.gigya.com/js/gigya.js?apiKey=3_8nyT5U5bgmcYd76h25LbEmWhqOWeM39-36YxT90-TFTHoCC5AWQbqzABxbwJMaxU:1 Failed to load resource: net::ERR_CONNECTION_RESET

I tried some plugins to disable the Content Security Policy and build my own Content-Security-Policy for SAP webpages. Now it works temporarily but the website behavior is strange which could cause me to re-logon and stuck forever.