Limiting Who Can Receive a PO

Moving to procurement forum.

You would need to use Lawson 9 security, and write rules against the PO30 form.
However, I would argue that this is exactly the wrong way to do things in an organization for two reasons. Typically, it's the buyer who creates and (sometimes) releases the PO, but it's a different receiving department that does the receipt. More importantly, I'd argue that as a separation of duties, I would not want the same person to create and release the PO and receive the goods.

Thanks for your response on this issue. I will try and reason with the user who wants this to happen.

I received this back from the user, is this different than the question that I asked?

Currently, anyone in the authority can receive on a purchase order which does not make sense.

The requester is not the same one who creates the purchase order. These are two different individuals. After the requester has entered a Requisition it goes thru the approval levels, sometimes one sometimes up to as many as four. After the Requisition has been approved, it is reviewed and converted into a Purchase Order by purchasing not the requester.

It sounds like you just need to limit via security who can access PO30.

John: I agree and disagree. Here's why: If you are talking strictly about doing the receipt in PO30, I agree. If you are talking about using the Receiving link from RQC, I disagree. When you initially click the link from RQC, it pulls up EVERY PO that is eligible to be received. -- Big deal, maybe yes, maybe no. When you pick the PO that you are going to receive by clicking the 'Receive' link you need access to PO30... but really only for the PO Lines that belong to you. So, you'll likely have to do some rule-writing against POLINE/POLINESRC tables. See my latest post in the Security forum.

I got it working!! Here's how:
On the POLINE table I've written a conditional rule on the LINE-NBR field
trim(getDBField('POLINESRC','REQUESTER',table.COMPANY,table.PO_CODE,table.PO_NUMBER,table.PO_RELEASE,table.LINE_NBR))==trim(user.getRequesterId())

Also, on PO30.1 I've written a conditional rule against the actual form PO30.1:
trim(getDBField('POLINESRC','REQUESTER',form.POR_COMPANY,form.POR_PO_CODE,form.POR_PO_NUMBER,form.POR_PO_RELEASE,form.PT_LINE_NBR))==trim(user.getRequesterId())

I've tested (very limited) with a PO with multiple requesters on it --- Since our system is set to combine items if they are the same vendor and ship-to location -- and going through RQC's receiving module, I only see the lines that belong to the specific requester.

Nice Greg.

Turns out- I had to allow full access to PO30.1 -- or you'll get a security violation when there are more than 1 requester per PO. The POLINE restriction though takes care of the RQC issue, as it only lets you see the PO's and the lines that are applicable to your requester.

In nearly all cases, a seperation of duties isolating the receiving function is recomended (if not required) by auditors. The receiving function for RQC may be convenient for some receiving to occur at off-site facilities, but the majority of receiving activity should occur as a dedicated function. LSF9 security rules are needed to restrict the receiving task in RQC and/or PO30 and to enforce a strict schema of who perform the receiving function and the circumstances/conditions which are permitted.

Keep in mind the accuracy and timeliness of the receiving function impacts several downstream processes in Lawson. If your company utilizes inventory tracking, then receiving updates the Stock on Hand quantities in the IC subsystem so that re-order points are accurately reflected. With non-stock purchases, the receiving function updates the RNI account used to generate the end-of-period accruals. Finally, receiving is a primary input to the 3-way Matching component used by AP. With a dedicated receiving function, the accuracy and timeliness of Inventory, RNI and Matching (and subsequently payment to vendors) are always more efficient. Without a dedicated receiving function, Accounting and MM staff will have to track down receipt status via individual requesters throughout the enterprise which could become a daunting task for the people in those departments.

Greg,
Are these rules written for LSF9 security?

Yes, LSF9 security, but just for the RQC role. We only allow people with the RQC role to see RQC, so therefore no search box, no other menus, etc, so that they can't really get to PO30.1... just in the functionality of their RQC ordering.

That is how we have the RQC role security set up as well.

We are now looking into implementing Receiving Self Service in some of our off site areas instead of using the PO30 form.  Thank you Greg for sharing your security conditionals!   This will be a big help for us to move forward quicker. 

I know this is an older post, but it is similar to what we are looking for.

We are needing the ability to limit what PO's a user can see when they go into receive a PO. We want them to only view PO Lines that pertain to them. Similar to setting up a requester and limiting them to only requesting for certain Accounting Units. We want to be able to setup "receivers" and limit them to certain Accounting Units.

I have always thought this was a major limitation in Lawson. You don't have a screen to setup a "receiver" like you do a "requester."

Greg, to verify....were you just able to secure by constructing a security rule on POLINE --> LINE-NBR to retrieve the requester ID from polinesrc?  This secures the RQC --> Receiving Self Service bookmark page?