Looking for reduction of your item master by identifying duplicate items? Here are some tips to consider when consolidating two item masters.

  1. Different ERP systems can have multiple ways of identifying an item. Many items are manufactured by different companies and they really are the same inventory item as they are interchangeable in your warehouse.
  2. Use the main manufacturer information on your item master – or the manufacturer information that your main supplier uses for the item.
  3. If different vendors provide different manufacturers items for the same item, then using a vendor item cross reference can assist with keeping track of that. Lawson does that on PO13.
  4. If there are multiple manufacturers or vendors for the item, then having a way to compare those is also important. Lawson does provide the ability to store manufacturer information in multiple ways – on the item master, on the item location record if a particular item for a location was being purchased from a different Vendor , and on the Vendor Item record. That means there are potentially multiple ways to store and find the manufacturer information for a particular item.
  5. POs are another place where manufacturer information for an item is stored so even if you are not storing the manufacturer information on the item master, you might still be able to create a cross reference by looking at your PO line data as well.
  6. Once all the options for manufacturer information are exhausted, then the remaining items will need to be matched item by item by description. This can be very time consuming especially since Lawson has a small description field which often requires considerable abbreviation of words in the description.
  7. Some additional considerations are to use the any of the other ways items might be classified This includes: generic name, Inventory classes, GL Categories, commodity codes and possibly SKUs if any of these are being stored.

 

This article will walk you through the process of deleting endpoints in Lawson.  You may need to do this if you decommission an external server and need to add a new server as an endpoint, or if there is an issue with your endpoint and you need to redo it.  First, you will unassign the endpoint from all its services, then you will delete it.

 

From LID or a command line window (with the environment variables set), type ssoconfig -c.  Log into ssoconfig with the appropriate password.

 

First, unassign the endpoint from all the services to which it is attached.  (You can see which services it’s attached to in ssoconfig Manage Lawson HTTP Endpoints > Export HTTP Endpoints and HTTP Endpoint assignment to Service).

 

Go to Manage Lawson HTTP Endpoints > Unassign HTTP Endpoint from Service

Enter the FQDN of your endpoint, the HTTP port, and the HTTPS port.  These are identifying values, and must be entered exactly as they are stored.  Enter the service name that you are unassigning (this will typically be either SSOP or the service you use for the thick client login).

Repeat this process with all the services that this endpoint is attached to.  Some examples are IOS, BPM, and LSADMIN.  Again, you can find out for sure by exporting the endpoint/services configuration.

Next, select “Delete existing HTTP Endpoint”

Enter the FQDN of your endpoint, the HTTP port, and the HTTPS port.  These are identifying values, and must be entered exactly as they are stored.

You must recycle Lawson after making these changes, as these types of security configurations are stored in the security caches.

 

It’s official, you have finalized the project to move to Cloudsuite and are ready to begin your journey to the cloud. But wait! What will you do with all your Lawson legacy data? By now you probably know that you can’t take it all with you to the cloud without a massive undertaking. Even then, your data retention policies may not allow you to turn off your Lawson 10x (or 9.0.1) servers just yet. Looks like you have more work to do.

Keeping those servers around for another 7 years is not an option. You’re likely running several Windows 2012 servers, or worst yet, Windows 2008, AIX or AS400 iSeries. Not to mention the database servers, file servers, co-location, Disaster Recovery servers and more. It’s enough to keep the most seasoned IT manager awake at night. What if the hardware fails? What if the old OS has a vulnerability we can’t patch? What if our server admin who knows how to maintain Lawson leaves? All these what-ifs are just the tip of the data retention iceberg.
One option is to park the data in a data lake and bury it under a rug for the time being. But unless your users are data analysts with some sophisticated BI tools and skills, then the data lake might as well be a Crater laker.
What if there was a way to completely remove the Lawson footprint from your data center but still provide fast, secure, and intuitive access to all the data to your users in a way that didn’t require any servers or maintenance? The APIX Serverless Framework is just that solution. Based on the AWS serverless stack, APIX has opened up incredible possibilities for inquiry only applications never before possible without a substantial investment in infrastructure. Clients can now provision a web based, lightweight, data archive solution and migrate all their data within days rather than months and at a fraction of the cost of the other solutions with none of the risk. Find out how the APIX serverless framework can help you meet all your Lawson data archive needs and eliminate the legacy servers for good.

Endpoints allow for external web servers to host Lawson Portal and authenticate against the chose authentication method for the main LSF application.

 

To create an endpoint,

 

Log into ssoconfig -c

Choose option “Manage SSO Domains” > “Add new SSO Domain”

Name the domain INTERNAL

Select the primary service that you will be using for authentication (might be SSOP or your thick client service)

Give the domain a meaningful description

Go back to the main menu and select “Manage Lawson HTTP Endpoints” > “Add new HTTP Endpoint”

Enter the fully qualified domain name for your endpoint

Enter the HTTP port (if you are using SSL, enter -1)

Enter the HTTPS port (if you are not using SSL, enter -1)

Enter the domain you created above

 

Select “Assign HTTP Endpoint to Service”

Assign the endpoint to the chosen authentication service

Enter the ports used to create the endpoint

Enter the name of the authentication service this endpoint should use for authentication (usually SSOP or your thick client service)

Repeat these steps to assign the endpoint to the IOS service, BPM service, and LSADMIN service.

 

Go back to the main menu.
Go to “Manage Lawson HTTP Endpoint Groups” > “Add new HTTP Endpoint Group”

Add a group for your external service with a meaningful name

Go back to “Manage Lawson HTTP Endpoint Groups” > “Add HTTP Endpoint to Group”

Enter the group name you just created above

Enter the endpoint name

Enter the points that were configured for the endpoint

Restart Lawson

Important step!!  The endpoint values are stored in the security cache, so a full recycle is required.

Smoke test

Go to https://server.domain.com/ssoconfig/SSOCfgInfoServlet

The loginurl and httpurl should match your endpoint URL.  If they don’t, you’ll need to unassign and delete the endpoint, then try adding it again.

 

You want to work with an IT partner that has functional knowledge in addition to the technological ability to extract and re-map the data.  This allows a true partnership that looks at the process from a high level and keeps an eye on the details at the same time.

You need to look for a partner that has experience extracting data from Lawson and mapping to the format needed to upload set up and transactional data to any system and taking extracted data from another system and formatting it into what Lawson needs and uploading the data.  A partner who uses a repeatable process that allows for tweaking the process if needed through testing cycles and then having the final version ready when you are ready to go-live.

When considering a Merger or acquisition there are many considerations. Some of these are:

  • Will there be a one-time conversion and at the end everyone will be using the same system?
  • Or will there be an on-going interface between the systems for GL data only or other systems as well?
  • Do you need a full training plan?
  • How will the users be trained on the new system or processes?
  • Make sure to start with a BRD – Business Requirement Document – so you have a road map of what is expected throughout the process.  This helps both you and your partner know what is expected from both parties.

With the right partner, you can have a smooth and successful transition.

It’s official, you have finalized the project to move to Workday and are ready to begin your journey to the cloud. But wait! What will you do with all your Lawson legacy data? By now you probably know that you can’t take it all to Workday. Your data retention policies may not allow you to turn off your Lawson 10x (or 9.0.1) servers just yet. Looks like you have more work to do.

Keeping those servers around for another 7 years is not an option. You’re likely running several Windows 2012 servers, or worst yet, Windows 2008, AIX or AS400 iSeries. Not to mention the database servers, file servers, co-location, Disaster Recovery servers and more. It’s enough to keep the most seasoned IT manager awake at night. What if the hardware fails? What if the old OS has a vulnerability we can’t patch? What if our server admin who knows how to maintain Lawson leaves? All these what-ifs are just the tip of the data retention iceberg.

One option is to park the data in a data lake and bury it under a rug for the time being. But unless your users are data analysts with some sophisticated BI tools and skills, then the data lake might as well be a Crater lake.

What if there was a way to completely remove the Lawson footprint from your data center but still provide fast, secure, and intuitive access to all the data to your users in a way that didn’t require any servers or maintenance? The APIX Serverless Framework is just that solution. Based on the AWS serverless stack, APIX has opened up incredible possibilities for inquiry only applications never before possible without a substantial investment in infrastructure. Clients can now provision a web based, lightweight, data archive solution and migrate all their data within days rather than months and at a fraction of the cost of the other solutions with none of the risk. Find out how the APIX serverless framework can help you meet all your Lawson data archive needs and eliminate the legacy servers for good.

Once you convert Lawson to authenticate with AD FS, you may find that your users would really prefer to log in with their normal ID (as opposed to [email protected] format).  You can accomplish this by updating the login method on the AD FS home page.

 

To make these changes, begin by opening PowerShell as administrator on the AD FS server, then follow these steps.

 

Create a new theme based on the default theme:

new-adfswebtheme -name <custom theme name> -sourcename default

 

Download the new theme to a local path:

export-adfswebtheme -name <custom theme name> -DirectoryPath “<local path>”

 

Navigate to the onload.js file in the theme that you just downloaded.  Add the following code to the onload.js file.  The highlighted portion is what you will update with your company’s domain.

 

// Company customization

// accept sAMAccountName

// pass userprincipalName ([email protected])

if (typeof Login != ‘undefined’){

    Login.submitLoginRequest = function () {

    var u = new InputUtil();

    var e = new LoginErrors();

    var userName = document.getElementById(Login.userNameInput);

    var password = document.getElementById(Login.passwordInput);

    if (userName.value && !userName.value.match(‘[@\\\\]’))

    {

        var userNameValue = ‘company.com\\’ + userName.value;

        document.forms[‘loginForm’].UserName.value = userNameValue;

    }

 

    if (!userName.value) {

       u.setError(userName, e.userNameFormatError);

       return false;

    }

 

    if (!password.value)

    {

        u.setError(password, e.passwordEmpty);

        return false;

    }

    document.forms[‘loginForm’].submit();

    return false;

};

}

 

In PowerShell, upload the new onload.js file:

Set-AdfsWebTheme -TargetName TriCity -OnLoadScriptPath “c:\admin\TriCityTheme\script\onload.js”

 

Activate the custom theme:

Set-AdfsWebConfig -ActiveThemeName TriCity

 

Now, when users type in their regular username, it will be appended with “your domain\” when they click the login button.  If users type in the domain themselves (“[email protected]”), the login page will accept that value and log in the user with the userPrincipalName they provided.