SSO with multiple requester codes

I switch my requester code all the time (for troubelshooting user issues) and I can tell you this method will not work. It will take time for LDAP to sync and reflect the changes in lawson, sometimes up to 10 minutes or so unless you bounce the server.

We looked at how we could manage the users for multi-company as well. We are LDAP bound, migrated from LAUA to LS over a year ago, use process flow for approvals and what we found was there is no easy way to handle the maintenance of mutliple requestors.

What we did is have one Requestor ID and we opened up the company field on RSS. This allowed the RSS users to default to their main company for ordering but allows access to order for the other company. The only issue we have to monitor, which should be caught in the approval process is that the second company we could not tie down to particular accounting units in that company.

Overall, we are not having too many issues with this process and it keeps us out of the business of maintaining the requestor id's.

Below is the options we looked at and we chose option 2.

Disclaimer: Since some options deviate from the way RSS is designed to work, there is no guarantee that either will work and should therefore be tested and validated.

Option 1:
-User has a single requester ID
-rssconfig is not modified. Company field is display only and will display the company value assigned to the requester on RQ04. NOTE: User could potentially use RQ10 to order for any company (dependent upon security).
-User uses RSS to order for company 1000. RSS will default to company 1000 and will not allow a user to select any other company.
-User uses RQ10 to order for company 6000. User will be able select a company on RQ10 (dependent upon security)

Option 2:
-User has a single requester ID
-Modify rssconfig to allow company field to be a select. Dependent upon security, User will choose the company for requisitions.
-User does not need to go to RQ10 since they can choose the company to request.


Setting Description
"allow_company_select"
value="false"
Indicate whether users can change the company on a requisition before the requisition is assigned a number.
Changing the above to TRUE will allow company select.

Option 3
-User has multiple requester IDs, each tied to a different company. The second requester ID is stored in a custom attribute
-rssconfig is not modified. Company field is display only and will display the company value assigned to the requester on RQ04. NOTE: User could potentially use RQ10 to order for any company (dependent upon security).
-This URL executes RSS with a specific requester (Overrides the default):
http://{Server}/rss/html/index.htm?newreq=true&requester={RQ04 REQUESTER}
The link doesn't let them pick a Requester within RSS or Portal. The link provides a means of building Bookmarks for specific requesters and in that sense allows them to select a Requester.

Example:
By default you are Requester (Default0000) but you need to be able to order for several companies which require different default values on RQ04. You would build a bookmark with child links for each requester I need (Requester1000, Requester2000, etc) and then assign that bookmark to the individual. Instead of clicking "Shopping" they would click the bookmark of their choice when they want to order for someone other then their default. The link will start RSS and use the requester in the link overriding their default.

Note: Have notice that in some cases the system holds onto the old requester when entering RSS through "Shopping" as a rule they should always click the "New" button which is a fix for almost all issues in RSS but in this case it resets based on the values used when starting RSS.

This method requires some setup in Portal Bookmarks and of course the additional RQ04 Requesters and as rule is an exception and not rule. If you have large numbers of users needing this functionality, it could result in a lot of work.
We have been using this method for awhile and it has worked out great. Requisitions are created within the correct company and Purchase Orders/Pick Tickets are created under the correct company. In addition the User only has 1 Login ID.


NOTES
SS uses the Requester ID stored in the requisition service to validate access into RSS.
That requester ID is recorded on every requisition.

The company number on the RQ04 record is a DEFAULT not a limitation for requisitions.
Security limitation is set to allow or not allow access to the other companies, Not the setup in requisitions.
If you use 1 ID on RQ10, you can change the company and location that you want to order for on every requisition. Same is true in RSS IF the company field is a select, not a display only.






In RQ04, you have the option of limiting access within the default company to specific accounting Units. When ordering for multiple companies whose GL is different, this can pose an unexpected limitation. However, you can still apply accounting unit limitations using security instead of using the RQ04 record.
If you remove the accounting units from the Requester ID (RQ04), you might want to look at adding accounting unit limitation on the user record.
That way you can still control the accounting unit access for all companies