BAPI_PROCORD_CHECK_MAT_AVAIL affecting screen flow

[alejandro_bindi]

I have a strange problem with this BAPI, which is called in a loop for several orders. The flow goes like this:

1. Program (report type with selection screen) starts, does some processing, and calls dynpro 0100 (which shows an ALV).

START-OF-SELECTION.

...

CALL SCREEN 0100.

2. On a certain PAI action on dynpro 0100, BAPI is called one or several times. Afterwards, dynpro 0200 is called (which shows another ALV).

MODULE user_command_0100.

...

CALL FUNCTION 'BAPI_PROCORD_CHECK_MAT_AVAIL'

...

CALL SCREEN 0200.

...

ENDMODULE.

3. When trying to exit dynpro 0200, LEAVE TO SCREEN 0 does NOT display calling dynpro 0100, but leaves way back to selection screen!

MODULE user_command_0200.

...

LEAVE TO SCREEN 0. "This goes to "CALL SCREEN 0200" point, but afterwards instead of triggering 0100 PBO, leaves screen 0100 also

...

ENDMODULE.

This problems do NOT occur when not calling this BAPI, so I'm 100% sure there's not a problem in the custom program regarding screen flow code.

I have a workaround already, which consists on forcing the next screen immediately after the call screen (with SET SCREEN 0100).

But I'm interested on the CAUSE of this behaviour! I've been unable to find it by debugging the BAPI, neither found any SMP notes on this issue.

Did anyone else experience this or something similar with another BAPI or function?

Thanks!

[alejandro_bindi]

Found it! I came up with the idea of putting a breakpoint precisely on SET SCREEN command, and there lies the problem. Function module CO_ZA_AVAIL_CHK_ORDER_MULTI (which is called indirectly by the BAPI over 12 call levels) does a SET SCREEN 0, which of course affects the next screen of the custom dynpro I'm calling the BAPI from. So, the correct workaround IS actually to use SET SCREEN sy-dynnr after calling the BAPI (the standard function anyway should be corrected to remove that SET SCREEN 0 or do it conditionally).

[wol]

We had exactly the same strange problem with BAPI_PRODORD_CHECK_MAT_AVAIL (which calls the same function as  BAPI_PROCORD_CHECK_MAT_AVAIL) and figured out the same reason and solution.

So I should have read earlier this thread.

Thanks for sharing!

Stefan

[manfred_fettinger3]

Thanks very much!!!