Infor Lawson for Mingle – How do I migrate Custom Design Studio forms to my current LSF version?

, ,

Issue: I possess Design Studio forms from the previous version of Lawson System Foundation (LSF) and Infor Lawson for Ming.le. How can I ensure their compatibility with my current LSF and Infor Lawson for Ming.le environment?

 

Solution: A Migrate Tool has been provided, starting from specific LSF versions and patches onwards:

 

– LSF 10.0.4, JT-651295, PORTAL.DIR/utility/upgradeCustomContent.htm version 10.0.4.0.747 minimum

– LSF 10.0.5, JT-651295, PORTAL.DIR/utility/upgradeCustomContent.htm version 10.0.5.0.746 minimum

– LSF 10.0.6, JT-651295, PORTAL.DIR/utility/upgradeCustomContent.htm version 10.0.6.0.745 minimum

– Included in the base release for LSF 10.0.7 and newer versions

 

Steps to follow in LSF 10.0.4, 10.0.5, and 10.0.6 with the specified patches, as well as in the delivered release of LSF 10.0.7 and above:

 

To review the existing Design Studio forms:

  1. Log in to Infor Lawson for Ming.le with a Portal Administrator account.
  2. Navigate to Custom Content Tools.
  3. Select Migrate Custom Content.
  4. Choose Analyze | Custom Forms.

 

To update the existing Design Studio forms:

  1. Log in to Infor Lawson for Ming.le with a Portal Administrator account.
  2. Navigate to Custom Content Tools.
  3. Select Migrate Custom Content.
  4. Choose Migrate | Custom Forms.

 

Please note:

This process won’t alter the “XMLGenBy=”xscrgen 10.0.7.0.1240 2016-03-09 08:32:37″” listed in the XML of the Design Studio form. Instead, it will append this tag to the first line: dateupgrade=”1443633109897″. To ascertain the date of the upgrade, visit https://currentmillis.com/ and input the associated value.

 

To review the current Design Studio forms with custom JavaScript:

  1. Log in to Infor Lawson for Ming.le with a Portal Administrator account.
  2. Navigate to Custom Content Tools.
  3. Select Migrate Custom Content.
  4. Choose Analyze | Custom Script.

 

Please note:

There isn’t a migration process for Custom Script. This requires manual handling based on the information from the Analyze step.

Batch Status Descriptions

, ,

Below is a cheat sheet for batch status numbers & their descriptions:

There are several use cases for querying the QUEUEDJOB table in GEN in order to get batch job details, such as status and run times.  The status is stored as a numeric value, not the actual status that is seen in the GUI. It can also be useful to be able to map it to the description.  Here are the batch job status numbers with their descriptions:

# 0 – Running
# 30 – Waiting
# 31 – Waiting Step
# 32 – Waiting On Time
# 33 – Waiting Recovery
# 34 – Needs Recovery
# 35 – Invalid Parameters
# 36 – Queue Inactive
# 37 – On Hold
# 60 – Recurring Skipped
# 61 – Recovery Deleted
# 62 – Cancelled
# 63 – Normal Completion

 

AP195 Issue Cannot close period

, ,

Jobs is in needs recovery with error

tsStoreDBRec error is Record was modified or deleted since your retrieval (131). Additional information is 100. Additional Text is: ModifySqlRec

There are 3 bad invoices in APINVOICE and APPAYMENT with no distribution records in APDISTRIB.

The 3 bad records are as follows

 

Resolution:

In SQL Manger, query the APINVOICE and APPAYMENT files for any invoices with bad name format as below:

Verify these records do not have any distributions records in APDISTRIB. If not, Delete these bad invoices.

APPAYMENT

APINVOICE

Run commit to commit the changes

Go into lawson and recover the job

Keywords:

 

 

LID Access max number error

, ,

PROBLEM:

 

I continue to receive the following error message  when attempting to log into LID:

That indicates a license issue.

so I ran licsta -r  and found the license file is corrupt because it reverted to client 9999.

 

> licsta -r

 

Active License Status For Client 9999

 

License Code/  Active  Licensed  Highest

Application    Users    Users      Use    Expiration Date

———–    ——  ——–  ——-  —————

default                  2         7    Thu Aug 31 13:25:17 2023

PR           2                       Not Licensed

LP           1                       Not Licensed

HR           1                       Not Licensed

un              4       10       13    Sun Sep 17 10:39:42 2023

 

Run licsta -f and verified the file is corrupt.

> licsta -f

File [E:\lawson\law\system\license] not copied to E:\lawson\law\system\tmplicense] – Error [33]

Unable to Read License File Header – File May Be Corrupted

 

You will need to request a new software license key and re-install the license file.

 

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.

 

PR160 In Recovery due to incorrect ACH file path workaround

, ,

If you have a PR160 job that goes into recovery because your ACH path is not correct:

You can modify the exact PR160 job that is in recovering by dumping the job with jobdump command in Lawson Interface Desktop (LID).

Example of command: jobdump -d -o Job -v UserName joesmoe jobdump.dmp

What to change: jobdump -d -o Job -v UserName <your_jobs_username> <enter_the_jobname>.dmp

Edit the dumped job file and change the ACH path ONLY and recover the job to see if it is resolved.

Load the job in report mode (to check for errors): jobload -o Job jobdump.dmp

Load the job in commit mode if it looks good: jobload -c -o Job jobdump.dmp

How to switch LSF domain controller

, ,

Problem:           

If your controller is failing and you need to move the LSF LDAP to another controller

Resolution:

Edit the ldapbind information in the SSOP service and reload it.

  1. Create a dump of the SSOP service:
  • ssoconfig -c
  • Option 5 Manage Lawson services
  • Option 6 Export service and identity info
  • Option 2 for not all services
  • Enter SSOP in upper case
  • Enter NONE in upper case
  • Give a filename (it will write out the file to the directory you are in when you run the ssoconfig -c command.) Example: ssop_prod.xml
  • Exit the ssoconfig menu.
  1. Make a copy of the .xml file that you just created. This is your backup of the SSOP service in its original state.
  2. Then edit the first .xml file and change the following lines:

<BATCH_LOAD FORMAT=”” OVERRIDE=”false”>

to

<BATCH_LOAD FORMAT=”” OVERRIDE=”true”>

 

and this line to the new machine name and port:

<PROVIDER>ldap://dc1.lawson.com:3268</PROVIDER>

to

<PROVIDER>ldap://dc2.lawson.com:3268</PROVIDER>

  1. Save the file.
  2. Do one of the following to load the modified SSOP service file:

ssoconfig -l ssoconfig_password filename.xml

Exit.

  1. A stop and start of the Lawson environment and WebSphere application server is required in order for this to take affect.

 

Suppressing Receiving Delivery and Putaway Delivery Tickets

, ,

To suppress Receiving Delivery and Putaway (PO134) delivery tickets when MSCM Delivery Documents are all that is needed is to disable the Back-Office PO Receiving (PO30) Receiving Delivery and Putaway (PO134) delivery ticket by removing the printer from PO Receiving (PO30) or create a dummy printer to stop the back-office delivery ticket from printing.

Removing the printer from PO Receiving (PO30) only works if the user does not have a default printer assigned to them. After being removed, the default printer will simply populate back in the field upon clicking change.

Additionally, an enhancement to PO Company Setup (PO01) was added which provides a flag called “Delivery and Putaway Ticket Print” which allows disabling the delivery ticket printing at the company level.