Forums / Categories / PeopleSoft / Human Capital Management / Time and Labor Workflow - Approval for Managers

    Time and Labor Workflow - Approval for Managers

    Hello,

    I am hoping someone may be able to help me out.  We are looking at setting up TL workflow for reported time.  We do not have position management in place.  We maintain a our department security tree with our structure (somewhat) and mantain the manager on the department table.  We would like approvals to go the individuals manager.  Using the TLByDeptManager works great, however if the individual entering time is the manager of his department it needs to go to his manager.  This is defined on the department security tree.

    For example:

    Our department security tree looks like the following

    Root

    | - Information Services (Manager X)

    |             | -  PeopleSoft (Manager Y)

    | - Accounting

    | - Marketing

    etc

    1. If an employee in Dept "Peoplesoft" was to enter time then Manager Y gets the approval workflow - This is working and what we expect

    2. If Manager Y, who is also in dept "Peoplesoft" enters time the transaction auto approves because he is the manager - This is not what we want.  It should go to Manager X because he is the manager in the next level of the tree.

    Is this functionality that exist in the workflow options?  I know we can write queries and SQL ID the approver list, and maybe that is where we need to go with this?  This seems like a basic function though and I am wondering if I am missing something?

    Any help would be appreciated.

    Thanks

    Hi Tammy

    I have shared your questions internally with a couple of consultants and I am cutting and pasting some of their responses:

    Assuming all T&L are ok being approved by immediate supervisor and not DeptManager….. The delivered TLBySupervisorID may be better than TLByDeptManager. It depends on how the HR data is structured. Otherwise, write a query and configure the approval workflow.

    To address Self Approve issue there are 4 different ways;

    1. Add step criteria

    <colgroup><col style="width:48pt;" width="64"><col style="width:69pt;" width="92"><col style="width:204pt;" width="272"></colgroup>
    |   | UserList | Criteria |
    | Step 1 | SupervisorID |  If requester is a dept manager

    Return True  |
    | Step 2 | DeptManager | If requester is a dept manager

    Return False |

    2. Add path Criteria - Same step criteria above can be used in the path criteria. Each path will have one step with respective userList

    3. Create SQL object to identify approver and assign it the the userlist in single step.

    4. Alter Delivered DeptManager App class (Customization)

    Also, from the query it is apparent they are using AWE. So it will be interesting to see how their Approval proxy might be working(if they use it at all). As delivered proxy cant approve their own timesheets, which is what the case should be with Department manager approval. if the delivered DeptManager App Class is not catering for, it can be raised with Oracle and get the delivered DeptManager app class looked at and altered for such scenarios. 
    Hope this helps Tammy

    Chamanthi Weerasinghe

    [email protected]

    Thanks, Chamanthi,

    I may have to use supervisor ID as I am not understanding how or even if I can took up the department tree to determine the next level manager.  I have another question for you if you don’t mind.  I am new to AWE so this is likely a very simple question so I apologies for my ignorance.  How would I build criteria to determine if the user is or is not the dept manager as you are suggesting in your email?

    If I click on the criteria for the step, the capabilities for the criteria look very limited.  I am not sure how you would say where the dept manager ID is equal to the current user?

    Tammy Cates, PMP
    Senior Business Systems Analyst, Finance Systems Solutions

    Hi Tammy

    A response from one of our consultants:

    Using SupervisorID definition (TLBySupervisorID) will work as follows:
    With supervisorID definition department tree look up will not be required, it purely works on Job Data supervisor ID.

    Root

    | - Information Services (Manager X)

    |             | -  PeopleSoft (Manager Y)

    | - Accounting

    | - Marketing

    etc

    If an employee in Dept "Peoplesoft" was to enter time then it will go to Manager Y, if Manager Y is identified as Supervisor on employee’s Job Data.

    If Manager Y, who is also in dept "Peoplesoft" enters time the transaction will go to Manager X, If manager X is identified as supervisor on Manager Y’s Job Data.

    **As for Step Criteria; **
    for this scenario user defined criteria cannot be used. You will need to use Application package in criteria type . 
    Application package will have a application class in which we will have a SQL to check if the requester is a Department manager and return True or False. Technical analyst can help with creating these objects with the logic we provide.

    Inline image 1

    Alternatively, You can use different Approval workflow for managers (TLBySupervisorID) and non managers(TLByDeptManagerID) by creating different Workgroups and assigning respective workgroups at the time of enrolling individuals to TL (Time reporter data). This approach will not required any app package or custom SQL on AWE side. Although this is entirely config, it will require new Work Group creation and Time reporter data updates.

    Happy to discuss further if required. There are lot of options to get this to work. Which way we go is guided by project phase we are in, knowing org structure, current TL framework etc.

    Regards

    Chamanthi

    [email protected]

    Thank you for your response.  I think based on our structure we will need to use both the supervisor and the dept manager with application class criteria as you suggest.  That, or better yet dept manager and some sort of userlist that will be able to look up the department security tree.  That latter would be our best option as the first option requires us to maintain the supervisor ID.  Can you tell me, I assume both the application class in the criteria as well as a userlist can use the current user ID as a variable passed to the class logic?

    Tammy

    Hi Tammy

    Apologies for the delay.  Vishal was a little tied up with a client.

    Here are his thoughts:
    Yes both application Class criteria and Userlist can use current user ID. Although, it is bit different how it is used. In Userlist you check 'Include user as Input' check box when your Userlist source is either SQL Defn, Query or App class.

    App Class in Userlist the same configuration option is available. As for Application Class in criteria, user ID as input is not a configuration option, but you can retrieved it in ppl code or SQL with in the app class.

    Just an observation, it is a good idea to maintain reporting hierarchy accurately in the system; supervisor or reports to. It is crucial for MSS, GSS, ecomp, eperformance, delegations other AWE etc. which we may want to use in the future.

    Hope this helps

    Chamanthi Weerasinghe

    [email protected]

     

Looks like your connection to Quest Oracle Community was lost, please wait while we try to reconnect.