AP Invoices only flow to Asset Management when there is an Asset Template associated with the AP invoice distribution line.

The invoices appear on AM15 and can be then added to AM or not depending on the actual need.

AP invoices do not automatically create assets, they need to be reviewed on AM15 and all aspects of the information that appears there is able to be adjusted before the invoice becomes an Asset.

 

 

Recently we ran into the dreaded “Unable to load” error message in Portal, and could not find any indication of why Portal couldn’t load.  The most we could see through a Fiddler trace is that the sso.js file was getting a 500 error.  There was nothing logged anywhere.  Not on the WebSphere node, application server, nothing in ios, security, event viewer.  Nothing!  We figured WebSphere had to be the culprit, because sso.js is wrapped up in an ear file in WAS_HOME, and everything on the Portal side was working until it tried to hit that script.  So, we started digging into WebSphere and figured out that one of the certs was expired on the Node.  For some reason, a custom wildcard cert had been used for the WebSphere install on the node only.  We opted to switch it to use the default self-signed cert, which was not expired, and was the solution that worked best for us.  Another option would, of course, be to upload a new wildcard cert and switch the old one to the new one.

To switch a cert in WebSphere, go to Security > SSL certificate and key management > Key stores and certificates.  Select the NodeDefaultKeyStore of the node you want to change, and under additional properties on the right, select “Personal certificates”.  Click your “old” cert and select “Replace”.  Select the “new” certificate that is replacing the old one.  Check the “Delete old Certificate after replacement” box.

Bounce WebSphere services, or better yet, reboot.  And you should be good to go!

 

 

 

The indexOf() method returns the first index of where a user given element is found in an array or it returns -1. This method has 1 required parameter and 1 optional parameter. The required parameter is the lookup value and the optional one is start index. The lookup value is the element you are trying to find. The start index is where you want to start looking for the lookup value.

 

Below shows some examples of how the indexOf() method works.

 

 

 

With the Chrome 80 update, here is a simple workaround to disable SameSite cookies.

 

To get started open your Chrome Browser.

Type chrome://flags in the URL and press enter:

Search cookies and set SameSite by default cookies and Cookies without SameSite must be secure to disable, then relaunch the browser:

Confirm changes after relaunching and that it!

 

Watch the accompanying video below for a visual guide.

Lawson RQ02 approval strings work hand in hand with Landmark and are setup in different ways per organization. Some use general hierarchal titles and some use individual usernames. Regardless of how you implement it, you want to be able to create a report so you can update them as individuals join/leave/move around the organization

To generate a database dump of all approval strings and their levels using my method, you’ll need read access rights to the LSL database and must be using SQL.

  1. Login to your TEST or PROD database application.
  2. Create a new query window and paste the below SQL code in, one is a screenshot to show syntax highlights and the other is the raw code for your convenience.

  3. Run the query, copy and paste with headers into Excel to filter down the data or edit the query.

I’ve renamed various column names to reflect the different levels and dollar amounts more clearly. Feel free to change the query to your liking. This is only the RQ02 strings, to get the filters for users’ setup in Landmark, check out my article titled: “Generating a simple approval level report from the Landmark database”.

For this tutorial, we will be restricting a table in CU01.1

  1. Login into Lawson Security Administrator
  2. Load up your default security profile typically titled PROD10 or TEST10
  3. Add a new security class

    Ours will be called TestSecClass
  4. Grant token access to CU01.1
  5. Once this is added, we want to restrict a specific table on CU01.1 to find the table name, go to CU01.1 and press CTRL + SHIFT + O when selecting the field
  6. Back in LSA, set CUC-CURRENCY-CODE to Deny Any Access
  7. Add this new class to a role of your choice. Add the role to a user and test CU01.1. To learn more about how Lawson security handles access, check out my other article titled: “Lawson Security – The Theory of Least Privilege Access Explained”

To start at the beginning, check out Part 1 of this series titled: “Creating an LBI Dashboard Series – Getting Started (Part 1)

 

For this part in the series, we will be adding a simple module to our new LBI Dashboard.

  1. First login into LBI environment as an admin user.
  2. Go to your newly created dashboard
  3. Click the + icon on the top left and select “New Module”
  4. On the Main tab, title your module, ours will be called “Payroll”
  5. By Default, the module will inherit access from the Dashboard itself, if you want to further restrict each module to separate users, you would do this again here. The expanded checkbox is great for convenience as the Module will be expanded by default:
  6. Go to Appearance Tab and select a Icon for your module to help distinguish it from others, we will select the money icon for Payroll module:

  7. When done select Save and you should see a blank Module in your dashboard:
  8. To add reports to this module, click the gear wheel icon in the top right of the module and select Add Items and then Search. You can also select a direct URL but this is much easier.
  9. A Searchbox should come up, this is to search all existing LBI reports. Type in the report name you want, check “Search Reporting Services Reports” and click the search icon to see the results.
  10. Once you find your report, select it and click Save:

You’ve created a report module in your dashboard and added your first report!

That’s all for this article, keep an eye out for more in our LBI Dashboard series.

 

LBI dashboards are useful for delegating reports to specific access and is essentially a frontend for all your user reporting needs.

For this part in the series, we will be going over the very basics and how to create a dashboard tab for Finance users and setup access so those users can access the dashboard.

  1. First login into LBI environment as an admin user.
  2. In the top right next to your admins username, you’ll see a gear wheel, click that and select “New Dashboard Tab”
  3. Enter a dashboard title and click OK, ours will be named Finance
  4. You should be redirected to a blank Dasboard, on your new dashboard, click the + sign in the top left and select “EDIT” (note you can select ‘Set Access’ but it’s simpler to go to edit)

  5. A new menu should pop-up with multiple tabs. Go to Sharing and select Edit Viewers for specific access
  6. In this screen you should see a set of users and groups (roles). In LSA, if users have specific groups assigned to their users, adding here will give them access to this dashboard. For our example we will be adding LBI-Payroll group from Lawson:
  7. All users with LBI-Payroll group will now have access to this dashboard. Press okay and Save:

This is the first step in setting up an LBI dashboard for specific users. Please note that LBI comes with a default role that all users must have which is typically called something like LBIUSER. Example below for this article:

Lawson allows for requester users to submit requisition orders for their organization. To make sure the orders are valid, Lawson also supports approvers to verify and approve/reject the orders.

The core of this is done by setting up Requisition Locations (RQ01) and Requisition Strings (RQ02) and having a workflow process everything in between.

Requisition Strings can be used in many different ways, but in our example it is to have individual approvers approve for a particular location. This can also be general titles like Manager, VP, etc. or however your organization wants to set it up.

As you can see below, these are strings for Company 100, Requesting Location RQ210 with Approvers starting at Level4 and stopping at Level6. The lower limit on the left is the amount that the users approve orders for and depending on the IPA flow logic, could notify or skip them.

When users track requsitions in say RQ10 for example, they can drill around and see history log via the strings themselves:

This is only half the setup for this particular organization.

 

Approvers have to be setup on the Landmark side via Rich Client or Process Server Administrator web application. This is done via “Filters” and these have to be named accordingly to what your IPA Requisition flow will coincide with.

Below is an example of how we would mirror the RQ02 strings in Rich Client (custom report).

The Level 4, 5, and 6 are the “auth id” that our custom flow matches up on. It then grabs the user from Landmark and send notifications based on where the requisition is in the flow.

Some organizations simply don’t use RQ02 strings as they may find it easier to process everything on the Landmark side.  Landmark does have a set of its own reporting tools and filters (See my other article titled “Generating a simple approval level report from the Landmark database“ for a custom database report I created).

The benefits of RQ02 strings in my experience is that the frontend functional users could setup the strings for the developers to mirror in the back end (or by an automated process if done right).

 

Hope this was helpful in giving you a brief overview of requisitions and approvers.

Lawson natively supports requisitions and a hierarchy requisition approval system within organizations. Some use both the approval strings found in RQ02 and setup filters within Lawson Rich Client (An application in Lawson Landmark). More info on this can be found in another one of our articles titled: “A Brief Overview into the Lawson Requisition and Approval Process”

 

To generate a database dump of all approvers and their levels using my method, you’ll need read access rights to the LSL, IPA, and GEN databases and must be using SQL.

 

    1. Login to your TEST or PROD database application.
    2. Create a new query window and paste the below SQL code in, one is a screenshot to show syntax highlights and the other is the raw code for your convenience.


      Run the query and your results should show as so:
    3. Copy and paste with headers into Excel to filter down the data or edit the query.

I’ve included an Active Status to show which locations are active or inactive. This can be changed in RQ01 per company and location.

Feel free to optimize the query to your likings if you see any inefficiencies. Remember, this is only for approval levels on the landmark side, not the RQ02 strings themselves.