Leave Request: Approval iView - Hours in the USED column are doubled

[Former Member]

I have a tough one for you experts out there....

We are implementing the ESS leave request iview com.sap.pct.erp.ess.leaverequestapprover in an EP7.0 system without enhancement packs. The backend system is ECC6.0. We are NOT using the UWL. The approver is using the "worklist" in the iView com.sap.pct.erp.ess.leaverequestapprover as their list to approver/reject.

Here is the scenario:

1) Leave Request Approver logs into ESS for the 1st time for the day

2) The approver opens the Leave Request: Approval iView (com.sap.pct.erp.ess.leaverequestapprover)

3) The approver is presented the "worklist" on the Leave Request: Approval iView

4) The approver sees the requests waiting for his approval

5) The hours in the USED column of the worklist are DOUBLE what they should be

6) The approver logs off and logs back into the ESS system

7) The approver opens the Leave Request: Approval iView again

😎 The hours in the USED column of the worklist are now NORMAL

9) They can repeat this process multiple times during the day and the hours will be normal until the next day

I have sent an OSS message to SAP but they have not been helpful with this issue.

Has anyone seen this behavior before? Any ideas about what the root cause might be?

Some of the analysis I have done leads me to the class CA_PT_ARQ_DEDUCTION in method GET_PERSISTENT_FOR_REQUESTID. It looks like this method may be doubling the amounts due to some "persistence" data, which I am not sure how this actually works.

Any help would be appreciated,

Brian Snyder

[siddharthrajora · Accepted solution]

create a OSS for SAP with the same example, I was just checking whether you can reproduce it all the time!

Cause we couldnt

[Former Member · Accepted solution]

Siddharth,

We can reproduce this error in our production system and one of our test systems.

What I have found is that in method CA_PT_ARQ_DEDUCTION=>GET_PERSISTENT_FOR_REQUESTID if the variable current_object_iref is initial (line 37) then the code does not work correctly and doubles up the number of deduction records in the ex_result_tab.

If the current_object_iref variable is initial then the program executes the following code:

• * internal Undo

APPEND internal_next_undo_info TO internal_transaction_stack.

internal_current_transaction = sy-tabix.

TRY.

CALL METHOD pm_load_and_set_attributes

EXPORTING

i_business_key = business_key.

CLEANUP.

CALL METHOD os_internal_undo.

CALL METHOD os_clear_current.

CLEAR current_special_object_info.

ENDTRY.

result ?= current_object_iref.

APPEND result TO ex_result_tab.

TRY.

CALL METHOD os_pm_loaded_persistent.

CLEANUP.

CALL METHOD os_internal_undo.

CALL METHOD os_clear_current.

CLEAR current_special_object_info.

ENDTRY.

• * Clean-up internal Undo

DELETE internal_transaction_stack

INDEX internal_current_transaction.

ADD -1 TO internal_current_transaction.

IF ( internal_transaction_stack IS INITIAL ).

CLEAR internal_undo_info.

internal_next_undo_info = 1.

ENDIF. "( INTERNAL_TRANSACTION_STACK is initial? )

In the above code a record in table special_bkey_tab is deleted and a new record is added while it is still within the loop of this table special_bkey_tab. This causes the program to do an extra loop through this table and add the extract record to the ex_result_tab table.

The pre-requisite for this error to occur is that the call to method os_load_and_validate_current does not finds the required object and the variable current_object_iref remains initial after the call. In our development system the call to method os_load_and_validate_current always finds the required object and then this error never occurs, but in the systems where the error can be reproduced, method os_load_and_validate_current nevers finds the required object and the deduction records are always duplicated.

Hope this helps in duplicating the problem. We are going to add and OSS message and send to SAP.

[former_member656938 · Accepted solution]

Hello Robin

We are experiencing the exact same problem with the hours doubled in the used column in the Approval iView. Did SAP give you a solution after you posted the OSS messages and if so, can you provide the details on what you did to fix the problem in your system? Any assistance you can offer would be greatly appreciated.

Thank you,

Jon

[former_member656938 · Accepted solution]

I sent an OSS message to SAP as well and after exchanging many, many postings back and forth with an SAP support consultant, the OSS message was forwarded to the SAP Development team. Then a developer logged into our system to recreate the issue and debug the code. After debugging the SAP developer responded to the OSS message and asked me to apply snote 1528666. We applied this snote to our sandbox and dev ECC systems and the issue is resolved.

It appears the developer created this snote specifically for this issue and I believe they used much of the code analysis in this thread provided by Robin Hain to make the coding changes. Thanks Robin!

Jon

[siddharthrajora]

check here

CL_PT_ARQ_REQS_LIST=> GET_DEDUCTION.

ensure the note 1495889 is implemented

[Former Member]

Siddharth,

I have verified that note 1495889 has already been implemented in our system. It is not clear what you are expecting me to find in the method CL_PT_ARQ_REQS_LIST=> GET_DEDUCTION. Do you believe this is a defect in the system or something specific to our system? Could this be due to the way HCM is configured or a Portal Setting?

I set a breakpoint in class CL_PT_ARQ_REQS_LIST in method GET_DEDUCTION at line 195. I compared the results of the structure CH_REQLIST_ENTRY-DEDUCTION each time the method was called. The first time the user logs in for the day then displays their worklist the records in this structure are repeated. The next time the user logs in for the same day the records in this structure are not repeated.

Thanks,

Brian

Edited by: Brian Snyder on Oct 19, 2010 7:47 PM

[siddharthrajora]

the reason of this case maybe the cache refresh, You are right we have seen this issue earlier and a couple of notes were

released however the issue persists? were you able tp debug? You ll see when you debug it solves the issue!

We are still missing what exactly occurin, in want of reproduicble example it becomes tricky

[Former Member]

Siddharth,

Do you recall which notes resolved this issue? I would be interested in seeing if we are current enough to already have these in our system. Also, I am working on debugging this so I can provide an example of what I am seeing.

Can you please explain in more detail what you mean by "cache refresh"? Is that controlled by a setting in portal or ESS configuration?

Brian

Edited by: Brian Snyder on Oct 15, 2010 2:30 AM

[former_member182426]

Hi,

First raise a Leave request. Then in back end run the FM PT_ARQ_REQLIST_GET in T-code SE37.

you specify the values for the following two input parameters as and the rest of parameters keep it same and execute.

IM_PERNR <pernr>

IM_MODU R

In output check the table EX_REQUEST_LIST.

Regards,

Shankar Reddy Ch.

[Former Member]

Shankar,

When I run the function do I use the IM_PERNR of the requestor or the approver? What should I be looking for in EX_REQUEST_LIST to help me find a root cause?

Thanks again,

Brian