Update LDAP Bind Connection

, ,

Sometime you may have a need to update your LDAP bind connection, such as when the domain controller you are bound to is decommissioned.

To update the LDAP bind connection,

First figure out which service is using ldap bind.  To do that, go to http(s)://<server>:<port>/ssoconfig/SSOCfgInfoServlet.  Make a note of the service name displayed on the page.

Next, log into ssoconfig and export that service:

Now, open the file you just exported.  Update the OVERRIDE attribute to “true”.  Update the “PROVIDER” element to the new server and port.

Next, upload your updated file into ssoconfig.  The syntax is ssoconfig -l <password> <full file path>

For example:

Ssoconfig data is stored in the security cache, so you will need to recycle your system for this change to take effect.

NOTE: If you need to change the credentials for the domain controller, this will be an extra process.  You will need to update the service associated with your LDAP bind.  This is most likely your SSOP_BIND service.  You can look under privileged identities in Lawson Security, check for a “DEFAULT” key associated with your ldap bind user.  That is your LDAP bind service.

To update the credentials for this service, log into ssoconfig and select Manage privileged access to services > Change existing identity.  Enter the service that you noted above.  Enter the correct user DN.  Enter the password.

Recycle Lawson.

 

Finding Duplicate Items in your Item Master

, ,

If you find duplicate items in your item master and want to reduce clutter, here are some tips:

  1. Items can have multiple ways of being identified. 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 on PO13- Vendor Item, indicate the vendor and their item number and their manufacturer information there. This information will default onto a PO when ordering from one vendor vs. a different vendor.  This allows you to have a single item that could be manufactured or supplied by multiple vendors and manufacturers.
  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.

 

What to consider when converting to a new ERP for Open POs

, ,

Many people are moving from one enterprise resource planning (ERP) platform to another.  There are many pieces to an Open PO that need to be considered when converting to a new ERP.

  1. How much history do you need to bring over to your new system? How often do you clean up your open POs in your current system?  Do you need all of your open POs or only certain ones – for example, only those for active vendors?
  2. Cleaning up your old POs – closing out old POs that probably will never be finished at this point is a great idea before starting the conversion process.
  3. Locations – how will you deal with locations in your current ERP that will not be in your new ERP? Is there a default location that can be used to process the conversion? A memo or user field can be used to store the original information.
  4. What about inactive requesters – how will you address these? Providing a default or generic requester when the old ones won’t be in the new system is a good way to handle this.  A memo or user field can be used to store the original information.
  5. Vendors – what about open POs for vendors who are inactive in your current system. Are you going to be converting those?  The vendor will need to be added to your new system if the answer is yes.
  6. Make sure to have the most current chart of accounts and cost center mapping.

 

Consolidating Two Item Masters

, ,

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.

 

Delete Lawson HTTP Endpoints

, ,

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.

 

Moving to CloudSuite Financials? How will you archive your Lawson data?

, ,

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.

BSI Tax Factory 11 SAAS Update and what you need to know

,

At some point this month (May 2021) BSI turned off their cloud version of TF10 in favor of their TF11 offering. Even though notifications were sent out to customers in advance, many clients did not make the move in time and were therefore left with an non-functional payroll system when their Lawson payroll could not connect with TF10. Fortunately this only affected the cloud customers. Unfortunately, BSI does not offer an extension of the TF10 product for their SAAS customers and therefore the only option is to move to version 11. The catch is if the client did not have a full backup of their TF10 environment, they may be out of luck with figuring out any custom payments, calculations or tax codes. This was the case with a few of the clients we worked with this week to get them back on track. If you’re dealing with this very issue, keep reading because although there is no easy fix, there is a light at the end of the tunnel. Here are the steps we recommend you follow

  • Contact BSI to let them know you’re dealing with this issue and make sure they are aware of the problem.
  • Update your local Lawson environment to the minimum requirements for BSI TF11. There is a specific patch for BSI TF11 that varies depending on your environment version (JT-1219557). This will require down time.
  • Update your local Lawson application to the minimum requirements for BSI TF11 (JT-1179406). This will likely require a database reorg.
  • Download the TFDSFILE.exe utility from your BSI portal
  • Use the executable to generate a new TF11 xml file
  • Add the following environment variables TF11_DATASET and TF11_DATABASE
  • Download the new server side drivers for the new TF11 version that corresponds to you cloud instance
  • Change the message maintenance for PRTF to reflect the new version
  • Recompile PRTF and test
  • Setup the default mappings within your BSI version
  • If you’re using custom calcs, codes, and payments you will need to set those up again unless you have a backup of them. There are ways you can discover what they may have been but that can take additional resources and time.
The above steps should get you operational but make sure to test thoroughly before running your next payroll or you will have a hard time later making corrections. As always, if you need help with any of the above steps, feel free to reach out to us via the contact us link on our site.