ICR - FB_ICRC105 RFC destination NONE

[Former Member]

Hi,

Has anyone hit the error below? I am selecting vie sequential numbers (isolating the company) as well as customer and vendor number but it seems that the selection job times out (running in background).

The error message from the logs is as follows:

Company 002378/2611: RFC destination NONE: Error in RFC connection: Time limit exceeded.

Message no. FB_ICRC105

Any help will be greatly appreciated.

Thanks

Kris

[bertrand_demany]

Hello,

Using the transaction FBICR3, whan i want to display an original FI document, the system issues an error FB_ICRC 105.

It's seems to be the error described into the note 1142254, but this one deals with the FBICR2 case.

Furthermore, my system includes the relevant support package (the EA-APPL SAPKGPAD13 package for the release 600) that correct this program error.

It seems that the number of the FI document displayed in the transaction is not the real FI number but the content of the FBICRC003A - DOCNR zone.

Anybody could help me ?

Thanks a lot,

Bertrand.

Edited by: Bertrand Demany on Jul 6, 2009 11:34 AM

[former_member572578]

Hello Bertrand,

Please implement all of the existing notes for keyword FB_ICRC_SHOW_FI_DOCUMENT_RFC. If this does not resolve the issue please create a service ticket.

Best regards,

Ralph

[former_member572578]

Hello Kris,

The error indicates that the data selection work process cannot finish within the time limit set in the system parameters. For GL open items, please review note 1261646. For customer & vendor accounts you may want to look into restricting the account numbers if this is possible (e.g. all intercompany customer and vendor accounts use a certain number range). Note 1296851 might also help in this context.

Other than that it would be interesting to know how many open items you have in your scenario and at which point the time_out occurs (which line(s) of which program/function module).

Hope this helps,

Ralph

[Former Member]

Hi Ralph,

The failure happens in process 3 and we are already selecting by a specific customer and vendor number that represent the partner companies. The volume of open items is around 60 000 per partner so 120 000 in the selection.

We are in the process of moving note 1296851 into our productive system so will run again. Our test system did not have enough voulume to replicate the error.

I will let you knew if we have further issues.

Thanks

Kris

[Former Member]

Hi Ralph,

We have implemented the note and executed the selection again. The selection program Timed out again with the following details:

"The program "SAPLFB_ICRC_SERVICES" has exceeded the maximum permitted runtime

without interruption, and has therefore been terminated."

As far as I am aware, our system parameter rdisp/max_wprun_time is set at the maximum 1200.

The ST22 log points to the failure as at:

The termination occurred in the ABAP program "SAPLFB_ICRC_SERVICES" in

"FB_ICRC_BS_DK_SEL_RFC".

The main program was "SAPMSSY1 ".

The termination occurred in line 350 of the source code of the (Include)

program "LFB_ICRC_SERVICESU19" of the source code of program "LFB_ICRC_SERVICESU19" (when calling the editor 3500).

342 * Get fields to be transferred for BSEG

343 READ TABLE lth_tname_ftab

344 ASSIGNING <ls_tname_ftab>

345 WITH TABLE KEY tname = fbicc_tabname-fagl_sitem_details.

346

347 IF sy-subrc = 0

348 AND lth_bseg_read IS NOT INITIAL.

349 * Read additional header information

>>>>> SELECT (<ls_tname_ftab>-t_ftab)

351 FROM bseg

352 INTO CORRESPONDING FIELDS OF TABLE lth_doc_details

353 FOR ALL ENTRIES IN lth_bseg_read

354 WHERE bukrs = lth_bseg_read-bukrs

355 AND belnr = lth_bseg_read-belnr

356 AND gjahr = lth_bseg_read-gjahr

357 AND buzei = lth_bseg_read-buzei.

358 ENDIF.

Not sure if this is something that can be resolved through an OSS note?

Thanks

Kris

[Former Member]

Sorry, looks like my colleagues have lied to me and not moved the OSS note transport into production yet....

Will run again once the note is in.

Thanks

Kris

[Former Member]

Hi,

We have implemented note 1265903 (and associated notes) and executed the selection jobs again. We are still encountering TIME_OUTs in program SAPLFB_ICRC_SERVICES. The termination occurred in line 359 of the source code of the (Include) program "LFB_ICRC_SERVICESU19"

of the source code of program "LFB_ICRC_SERVICESU19".

The failure is happening in the following section of code (line 359):

358 * Read additional header information

>>>>> SELECT (<ls_tname_ftab>-t_ftab)

360 FROM bseg

361 INTO CORRESPONDING FIELDS OF TABLE lth_doc_details

362 FOR ALL ENTRIES IN lth_bseg_read

363 WHERE bukrs = lth_bseg_read-bukrs

364 AND belnr = lth_bseg_read-belnr

365 AND gjahr = lth_bseg_read-gjahr

366 AND buzei = lth_bseg_read-buzei.

367 ENDIF.

368

Ralph, is this something that I need to raise an OSS message for?

Thanks

Kris

[former_member572578]

Hello Kris,

The problem is that it simply takes data selection too long to gather all the necessary information about the open items. There are 2 options:

#1 Decrease the runtime, e.g. by restricting the data to be selected. Are you running data selection for several companies in one program run? You could split up the data selection by setting the flag to use a separate RFC call for individual companies in FBIC032. How many entries are in lth_bseg_read when the error occurs?

#2 Increase the maximum runtime for dialog processes.

There are no known issues with performance of data selection at this point. The process is highly optimized and the long runtime is probably due to the data volume. Therefore you either need to make the packages smaller or define a higher maximum runtime. If this occurs in a test environment the best approach in my opinion would be to extend maximum runtime and simply test how long data selection actually needs to complete without issues.

Obviously you can always create a service ticket if your efforts do not get you the results you are looking for.

Best regards,

Ralph

[Former Member]

Hi Ralph,

Thanks for the reply.

I have executed the job again but still get Time Out errors. I am selecting 2 company codes with additional selection by Vendor number and Customer number (representing the AP/AR sides of the transaction). Separate RFC calls have been configured for each of the company codes. The parameter rdisp/max_wprun_time is set at maximum.

The failure is happening in our Production system and we are dealing with around 70 000 records on each side so approx 140 000 for the selection. I have no way of reducing the packages as already at lowes level selection i.e. for a single Vendor/Customer.

I will execute the job and switch on a trace to try and find out more. Perhaps a service ticket will be required.

Thanks

Kris

[former_member572578]

Hello Kris,

It seems that 70'000 open items per partner are a lot. Is there a reason why the open items have not been cleared yet? How many new open items are posted every month?

Did you apply the following notes yet?

1265903

1296851

Best regards,

Ralph

[Former Member]

Hi Ralph,

We are in the process of applying note 1296851 and will run the jobs again once the note is applied.

Note 1265903 has already been applied but did not resolve the issue.

Our model and design is such that we have massive amounts of intercompany transactions, and the clearing down of the direct debit/edi paymemt advice is not always as efficient as it could be. I will review the timings of payment runs/clearings and try to schedule the selection job to run after that i.e. minimise the open item volume.

I will report back once we have the note in place...fingers crossed.

Thanks for the help.

Kris

[Former Member]

Hi Ralph,

We have applied note 1296851 and executed the selection job, which once again had a TIME_OUT. We then executed again in a test system, with a trace activated, and compared the results to the productive failure. I can send the trace summary (including the record number stats) to you if you are interested?

We are now looking at updating some indexes and maybe creating a server group where the work process time limit is increased. One thing that was highlighted in the trace was the occurrence of several nested loops...I am not an ABAP'er but understand that this could cause performance issues?

Let me know if you want to see the trace document and I will forward to your @sap email.

Thanks

Kris

[former_member572578]

Hello Kris,

Please do send me the trace. What indices are you looking into?

Ralph