Community
ABAP Forum
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
Read only

Error Function code not defined for flow EWM RF Custom Application

rogert
Newcomer

a week ago

190

Hello all,

I am creating a custom RF application in SAP S/4HANA and I’m running into an issue where the screen is not rendering properly. I found a YouTube video suggesting this may happen when the PBO and PAI function modules have not been implemented yet, and in my case, that is true.

Could someone please explain the correct way to build the PBO and PAI function modules for a custom RF screen? I’m especially looking for guidance on:

  • How to structure the INIT/PBO and user input/PAI modules.

  • How to pass data to the RF screen correctly.

  • Which RF customizing entries must be maintained so the screen renders and the flow continues properly.

From what I’ve learned, SAP EWM RF screens require PBO and PAI function modules for each screen step, and the corresponding FM must be assigned in the RF step flow and screen mapping. I would appreciate any sample logic or a step-by-step explanation for a basic custom RF transaction.

rogert_1-1780989871666.png

rogert_2-1780989959954.png

rogert_3-1780990005676.png

rogert_4-1780990022558.png

 

 

 

 

 

1 REPLY 1
Read only

TMNielsen
Contributor

Wednesday - last edited Wednesday

115

I can't directly help, but I know that the answer will depend on your knowledge about making dynpros (screens) in general?
The PAI/PBO of a RF dynpro is probably the same as in a normal dynpro. Many years ago there was some special requirments because old Telnet RF terminals needed to use F-keys F1 and F4 in a different way than standard SAPgui, but today I think it it most common that the word "RF-terminal" is simply a rugged android device with a build in scanner and maybe with a pistol grip. Basically a mobile phone. These devices will run normal SAPGUI transactions via ITS Mobile ( or they will run Fiori apps or they will run RAP Apps or they will run CAP Apps or ... but that is probably not relevant with the RF Framework).

So it may depend on your setup and your hardware,  but I guess your apps must be with normal dynpros and normal PAI and PBO. 

If you don't know how to create aps with dynpros it will be difficult. When I leaned it I started with a 5 days course. I think it was around 1997. The course was called BC-410 and today it seems that someone has moved it to Youtube:

TMNielsen_0-1781082930999.png

I don't have any real experience with with EWM in S/4 HANA, but I have made many RF transactions in SAP ECC and earlier versions.

In SAP ECC there are also a kind of a customizable RF framework like in EWM. These frameworks are very flexible to be able to handle all kind of requirements from customers around the world running many different RF devices with many different capabilities. This flexibility also makes it very very complicated. 

The flexibility is necessary for SAP to support all the relevant scenarios, but my experience from multiple customers is that each customer installation always decide for one scenario with one (or very few) types of RF devices and with one specific path thru alle the customizing.
In that case we have always chosen not to use the RF framework, but simple make normal transactions with dynpros and PAI and PBO - with all what is normally part of a SAPGUI tranaction. For the dynpros are then generated HTML templates. Finally the transactions are made available as web transactions via a ITS Based gui service in SICF (ITS Mobile).

I know that this may be a controversial approach and probably someone would want to raise a discussion about clean core. As I said I don't know EWM in S4/HANA, but I'm almost sure my approach will also work in a clean core EWM.

I f you want to stay with the framework and make your own apps, I suggest that you take a look on of the SAP standard transactions/programs/function modules in the solution and then make a Z program with same complexity to make the program work with the framework.