FITV_POWL_ASSISTANT can't get expense claim tab visible

[Lukas_Weigelt]

Hi folks,

System Information:

NW AS 7.03 ABAP Stack 731 Level 11, ECC 606 (EHP 6) with SAP_HR 604 Level 73 and EA_HR 607 (HR-Renewal 1) Level 24

Background / Business Process:

In our business process, there are two groups of "power users" that are allowed to create trips on behalf of other persons. These are a) our outer offices, which are allowed to create travel requests and expense claims on behalf of other users in draft mode and b) our internal Travel Service Team, which is allowed to create Travel Requests and Travel Plans in whatever status on behalf of other users.

As a means of technical basis, we decided to use the application FITV_POWL_ASSISTANT.

Problem:

I've tried to configure the POWL Customizing Tables accordingly, however for one single Tab/Query it doesn't work, meaning the tab for the query does not appear in the POWL. For two other tabs, it works out.

Outer Office can only see the Travel Request tab but should be able to additionally see the expense claim tab as well.

Travel Service Team can see Travel Request tab and Travel Plan tab. (all is good here).

What I've tried / researched so far:

• I quadruple-checked all POWL Tables that need to be consistent and in my opinion, everything is just fine. I'll append Screenshots for the respective tables to the thread nevertheless in case I am routine-blinded by now.
• I've cleared the cache via POWL_D01 after changing the queries/views
• there are no implicit personalizations in the application whatsoever, not on user scope, not on admin scope and not on configuration scope
• I did not enhance the standard component configuration
• there are no modifications anywhere whatsoever
• there are no relevant enhancements in the underlying WDA Components
• The Feeder Class is untouched
• did a light debug analysis on POWL_UI_COMP but didn't find out where the table is actually assembled
• the field 14 in V_T702N_A for "other settlements" is set to 0, so requests, plans and settlements are globally activated

I have not yet searched for fresh FI-TV POWL notes because I assume, something which works well for one query (Plans) and does not work for another one (expense claims) can't arise from a general technical fault (fearless assumption -.-).

I don't know what to check next and I'm close to rebuilding everything from scratch. If you got any idea what I could still check, please share it with me. Or, even better, if you know where the table strips are built programatically and where I could debug in the generic POWL components, that'd be awesome as well.

With respect to the following wikis/blogs/helps:

POWL Reports - Web Dynpro ABAP - SCN Wiki

Configuring visibility of Buttons and tab strips in All my trips and POWL - ERP Human Capital Manage...

Cheers, Lukas

P.S. God damn you, POWL 😞

Screens:

TA POWL_TYPE

TA POWL_TYPER

TA POWL_QUERY

TA POWL_QUERYR

[Former Member · Accepted solution]

Hello Lukas,

It looks strange and it must be very specific but I will try to help

What I would do at this point, if I was in your shoes :

1/ Check if you have any implementation of BADI BADI_TYPE_CUST, extension point POWL_RUNTIME_TYPE_MODIFICATION.

2/ If not, debug :

- POWL tabs are built in POWL_UI_COMP as you stated, in view MASTER_TAB. The building is done here based on values contains in POWL class. So debugging the class is more relevant than debugging the web dynpro.

Most important class are CL_POWL_UI_HELPER and CL_POWL_MODEL. I think the class you should debug is CL_POWL_MODEL which contains the queries to be displayed (using instance attribute mr_model in cl_powl_ui_helper).

Start debugging method GET_VISIBLE_TYPES of CL_POWL_MODEL here you have the selections in powl tables.

Check that your 2 types are selected and returned. If so tell me and we will see

Regards

Mathieu

[Lukas_Weigelt · Accepted solution]

Hi Mathieu,

thanks for your reply it already helped me a lot. The hint to start at GET_VISIBLE_TYPES of CL_POWL_MODEL was just perfect. However, now I start to think my system is infected with the undead, let me elaborate on that:

EDIT: In before, my use case has now all roles so he should be able to see all three tabs (for better debugging purposes).

In Line 126 of Method GET_VISIBLE_QUERIES in CL_POWL_QUERY_ACCESSOR is the following coding:

* step 2: actual user queries
   SELECT q~query q~type q~masterquery q~admin q~creator q~sync q~default_q_change

          a~applid a~username a~result_count a~refresh_date a~refresh_type
          a~refresh_time
          a~refresh_tzone a~esttime a~category a~cat_sequence
          a~cat_query_seq
          a~tabs_query_seq a~layout a~active a~result_cache_id a~status

          t~description t~spras
   FROM
     (
       (
         powl_query AS q LEFT OUTER JOIN powl_act_query AS a
         ON q~query  = a~query )
       JOIN powl_query_t AS t
         ON q~query = t~query
      )
   INTO CORRESPONDING FIELDS OF TABLE e_visible_queries
   FOR ALL ENTRIES IN i_vistypes
     WHERE q~type    = i_vistypes-type
       AND q~creator = i_username
.

I've debugged this part right after a complete deletion of ALL cached queries via POWL_D01 so the table powl_act_query is empty. Here's a screen of the debugger after the select statement:

Now, what makes the fact that there's an entry selected completely unintelligible, is the fact that the joined Select is restricted to the field CREATOR for my current user RSS_WEIGELT. There is no such entry in any of the three joined tables whatsoever, yet one entry is selected. This entry that is selected in runtime does not exist.

Table POWL_QUERY ( "q" in the join statement ).

Table POWL_ACT_QUERY ( "a" in the join statement ) has no entries, hence no screenshot.

Table POWL_QUERY_T ("t" in the join statement ).

The fact that this fiendish zombie-entry is selected as user-derived query from nowhere causes the subsequent coding to ignore the respective admin query, setting it inactive and deleting it, hence only the Travel Request tab and the Travel Plan tab remain.

What IS going on here? How do I exorcise this user-derived query?

Cheers, Lukas

[Former Member · Accepted solution]

Ok, I think you have an entry in POWL_QUERY where you are the creator (derived one with GUID as query ID). You should see it if you remove your filter on "FIT*ASS".

Where does it comes from? I dont know, maybe from some personnalization. One thing is for sure it hasnt been cleaned by POWL_D01 because the select in POWL_D01 is slighty different. The LEFT OUTER JOIN isnt done in the same order.

Coding in form SELECT_QUERIES of POWL_D01

FROM
          (
            (
              powl_act_query AS q LEFT OUTER JOIN powl_query AS a
              ON q~query  = a~query )
            JOIN powl_query_t AS t
              ON q~query = t~query
           )
        INTO CORRESPONDING FIELDS OF TABLE lt_act_queries
          WHERE q~username IN user AND
                q~applid IN applid.

Coding in GET_VISIBLE_QUERIES of CL_POWL_QUERY_ACCESSOR

FROM
     (
       (
         powl_query AS q LEFT OUTER JOIN powl_act_query AS a
         ON q~query  = a~query )
       JOIN powl_query_t AS t
         ON q~query = t~query
      )
   INTO CORRESPONDING FIELDS OF TABLE e_visible_queries
   FOR ALL ENTRIES IN i_vistypes
     WHERE q~type    = i_vistypes-type
       AND q~creator = i_usern

Now we should :

1- Try to understand how is created the entry in POWL_QUERY with your username as creator. I will also investiguate on my system.

2- Write an OSS message to SAP, with these technical elements. For me there is a very high chance that the problem is on their side

Mathieu

[Lukas_Weigelt · Accepted solution]

Well I'll be damned. It's exactly as you said. There were several Queries with some hexadecimal stuff as "ID" instead of a readable Query Name. I did a hard database delete on these and now everything works out as intended.

Do you think it's to be considered a program error that these two select statements differ from each others, i.e. the select statement for selection differs from the one for deletion? I'm asking this because I'm unsure how to formulate the OSS message, since I don't know as of yet how these strange entries came into existance in the first place. I'll keep an eye on it in any case.

Thanks a ton, Mathieu! Many Kudos and ponits to you 😉

In case you should find out where these entries originate from before me, please let me know!

Cheers, Lukas

[Former Member · Accepted solution]

Lukas Weigelt wrote:

Do you think it's to be considered a program error that these two select statements differ from each others, i.e. the select statement for selection differs from the one for deletion? I'm asking this because I'm unsure how to formulate the OSS message, since I don't know as of yet how these strange entries came into existance in the first place. I'll keep an eye on it in any case.

Yes I m not sure either that this is the cause... and as we dont know how these entries appeared... Maybe it only happens for developers and not for end users ? maybe only in development system ? An OSS message wouldnt hurt but it would be better to understand the cause before

I will let you know if I find something on my side

Have a good day

Mathieu

[Lukas_Weigelt · Accepted solution]

The damn pseudo-user-queries (which are flagged as admin queries too) apparently are auto-generated from the admin-queries upon initial refresh of the POWL. Once this happens, the user queries are used in the further process flow. What's even worse about this, is the fact that these pseudo-user-queries do not adapt my layout variants from the admin-queries, so the layout gets reset to standard.

I'm gonna open a message now...

Cheers, Lukas

[Lukas_Weigelt · Accepted solution]

Solved by means of the following notes:

0001900317

0001907411

0001945143

0001971927

0001973063

0001975395

0002002786

0002015291

0002025604

0002033656

0002046662

The table design hasn't changed and the process I can see in Debugging hasn't changed its behaviour either but everything works out as intended now.

I'll just stop trying to understand POWL

Cheers, Lukas

[Former Member · Accepted solution]

ahahah