Logical Requester vs Individual Requester

Sort:
You are not authorized to post a reply.
Author
Messages
Sarah
New Member
Posts: 4
New Member
    I am curious what the pro's and con's are for definine requesters from a long term maintenance perspective. We are looking to restrict the ability to order by authorized requesting location.

    ex: Sarah the user and Sarah the requester (Individual) or
    Sarah the user and MyDepartment the requester.

    I see the benefit of assigning individuals to logical requesters as an ease in maintenance on the RQ04 ( for the authorized requesting locations). However, will we still be able to email the individual if the request is denied (via their S3 security email address)? or does it default to the RQ04? Is it still easy to drill around by who requested? or is the drill around based on the requester? ( sarah vs. MyDepartment)

    How have others solved this problem? How much maintenance do you experience at the individual level vs logical groups?

    Thanks in advance!
    Rob Conrad
    Veteran Member
    Posts: 73
    Veteran Member
      Hi Sarah -

      The answer really depends on what type of Requesting you will be doing - automated or manual.

      Most organizations are setup with Requester matching an individual Lawson RM ID and this has a number of advantages. You can restrict individual Requester activity using the RQ04 form, and Requester email notifications in your Req Approval Process Flow can be driven by the RM Email Address. RSS/RQC heavily rely on the Requester ID for Requisition Status Reporting and the REQCOOKIE for access, so having an individual Requester makes things a lot cleaner and reporting more detailed/useful. Additionally, when an Employee TERMS or CHANGES jobs in the Hospital, you can deactivate their Requester ID using PFI to make sure they do not make any purchases (after the approved PA52) and this will not have any affect on the rest of the department (as in having to now manage a password or access for someone who might still be an employee, but just not in that department anymore).

      On the other hand - a generic Requester ID should be used for automation or interfaces; in fact replenishment programs like IC142 require a Requester to be setup specifically for that job, so I would recommend an individual Requester for staff members who must order items and a generic department/location Requester for your interfaces and automated replenishment jobs/pars etc.

      Are you using MSCM and/or PFI?

      RC

      JonA
      Veteran Member
      Posts: 1162
      Veteran Member
        What will happen in PFP/PFI if you tie multiple end users to one Requester is that the system will loop through every user id alphabetically that has that Requester named in their Resource Manager setup in Lawson Security and choose the last one to send any email notifications. We have several generic Requesters set up (OR, Pharmacy, Imaging) so they can easily see what others in their department has ordered to decrease duplication of orders. But for the most part each invidual has their own. I also require that anyone that orders supplies has a unix account so I can see who actually created the req.
        Jon Athey - Sr. Supply Chain Analyst - Materials Management - MyMichigan Health
        JonA
        Veteran Member
        Posts: 1162
        Veteran Member
          Correction, it's the Indentities area in security that holds the Requester not RM.
          Jon Athey - Sr. Supply Chain Analyst - Materials Management - MyMichigan Health
          Rob Conrad
          Veteran Member
          Posts: 73
          Veteran Member
            Hi Sarah -

            Per Jon's note - you can handle multiple RM_IDs with a single generic Requester using PFI. Depending on how your code is written, you can capture ALL the Email Addresses associated with the generic Requester inside the RM loop, or choose the last Address by putting the variable node outside the loop. An assign and message builder node inside the RM Node would allow you to capture every single distinct email address linked to the Generic Requester record in RM as the RM node loops. You can then populate that string of email addresses captured in the Message Builder node by referencing the Message Builder variable in your Email Node "To Address" etc.

            Anyway, just thought I would clarify that a bit from my previous post.

            Most clients tend to be 1:1 with Requester to RM record though.

            RC
            Sarah
            New Member
            Posts: 4
            New Member
              Thanks everyone... we are going the 1:1 route! 
              You are not authorized to post a reply.