cancel
Showing results for 
Search instead for 
Did you mean: 

How to capture user input for customer exit processing?

Former Member
0 Kudos
1,033

I need to calculate the number of working days elapsed in the current fiscal quarter BASED on the USER INPUT on the reporting front. i.e., say the fiscal quarter started on 1 July 2005 and if the user enters 10 July 2005, I should get the value 8 (Assume that Monday through Friday are all workdays). If the user enters 12 July 2005, I should get 10. I have written customer exits and know how to use factory calendar, but <b>THE CHALLENGE</b> is how do I <b>CAPTURE</b> the user input and use it in my exit? During the varible definition, if I select the check box "Ready for input" then the customer exit is not being processed and unless I check that box I can't get a user entry! If I look at the import values in the customer exit, I see i_t_var_range with type rrs0_t_var_range. My strong feeling is that this parameter gets the user input, but I am unable to use it as the customer exit is not being called if I make the user to input the data. Based on the empirical evidence, I felt that user input and customer exit can not co-exist!! Please somebody prove me wrong and let me know how can I use the user input to process my "customer-exit" variable. I would really appreciate any input from the BW community here.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Sameer,

Most likely, I'm missing something, but I think that the answer is very simple.

CASE I_VNAM.

WHEN 'YOUR_CUSTOMER_EXIT_VAR'.

IF I_STEP = 2. “ After selecting of input variable

LOOP AT I_T_VAR_RANGE INTO LOC_VAR_RANGE

WHERE VNAM = 'USER_INPUT_VAR'.

CLEAR L_S_RANGE.

L_S_RANGE-LOW = LOC_VAR_RANGE-LOW(4).

...

APPEND L_S_RANGE TO E_T_RANGE.

ENDLOOP.

ENDIF.

ENDCASE.

In this typical user exit coding you have a user entered value in LOC_VAR_RANGE (originally in I_T_VAR_RANGE) and you construct your user exit variable value in E_T_RANGE.

Best regards,

Eugene

Message was edited by: Eugene Khusainov

Former Member
0 Kudos

Hi Eugene,

Thanks for your reply. Your input certainly helped me think of a different solution. But I think one can't process the same variable in the customer exit from which you are getting the input. Say VAR1 is a variable with processing type "Customer Exit" and "ready for input". If the user enters a value for VAR1 then I can't change VAR1 in the user exit even though its processing type is "Customer Exit". Am I right? I came to this conclusion after empirical evidence. I could get a break-point to stop for my VAR1 only when i_step is 1. Let me know your comments and thanks again for your input.

Former Member
0 Kudos

Hi Sameer,

As Eugene said, here you have to use 2 variables.One for holding the value of user entry.And another variable to be defined as 'user exit' as processing type(and it should not 'ready for input'). You will be populate the value to 2nd variable in user exit with the help of 1st variable.

With rgds,

Anil Kumar Sharma .P

Former Member
0 Kudos

Hi Sameer,

as Anil an Eugene pointed out, this is a possible and feasible solution. We use this on a regular Basis.

The only thing you have to think about is the value the user types in and how to prevent the query from filtering according to this value. Most of the time you do not want this happen.

cheers,

Frank

Former Member
0 Kudos

Exactly Frank, you have rightly pointed out one of the potential problems. As all of you suggested that two variables are definitely required if you want to process a customer exit based on the user input then I will take heart from the fact that empirical evidence was indeed correct.

I use both the user input and customer exit variables in the same place and as the "restrict" values always work on "OR" condition, they work just fine (luckily the user input should be included in the results!!). The only annoying thing is that if one opens the query definition, it is not very clear why there are two restrictions!! I don't think there is any way out of this.

Coming to the problem you pointed out, even if you don't want the user input to be considered, one can use dummy RKFs and hide them from showing up in the query. Let me know if this is how you handle the filtering problem. Thanks.

Answers (0)