Archive for category: Articles

If you are running GL199 to close the period, you may encounter the below error message in the print file (or in the job scheduler log) “Company being processed in different job”.

This means that Lawson “thinks” there is another GL199 job running that is processing the same company your job is trying to process.  If that is the case, allow the first job to finish before running yours.  However, there may not be any other jobs running, yet you are still encountering the error.

To troubleshoot, first try to trace back to the first time the GL199 ran and failed (it may be in recovery or canceled).  Look at the examine log for that run.  There may be a different error that indicates the root cause of the issue.  If so, resolve that issue and recover or rerun that job.

If there are no issues to resolve, and you are certain that the GL199 hasn’t failed in the middle of updating records, you can get your DBA to update the status flag so that Lawson will no longer think the GL199 is running.  This can be accomplished by creating a paint screen for GLSYSTEM, or by making a direct update in the database.  The field “UPDATING” needs to be set to 0.  Additionally, you should check to see if your failed GL199 job is stuck in GLMONITOR.  If so, you should delete the record for that job.  But make sure you are deleting the record for your job!!!

Lawson provides the ability to query Lawson tables via URL.  These transactions are called “DME” queries, and can be quite useful in IPA processes, or in scripting bulk data calls.

To query data using a DME call, the URL is https://<server name>/servlet/Router/Data/Erp?.  To select specific fields, use the “FIELD” key word.  To filter the results, use the “SELECT” key word.  You will need to have knowledge of the data tables and columns to build these queries.  The dbdef command in LID can be quite useful for this.

GEN

To query GEN data, the syntax would be https://<servername>/servlet/Router/Data/Erp?PROD=GEN

For example, this URL would return the PRODUCTLINE and FILENAME fields for the FILEDEF record with prefix “API”:

https://lawson.company.com/servlet/Router/Data/ERP?PROD=GEN&FILE=FILEDEF&SELECT=PREFIX=API&FIELD=PRODUCTLINE,FILENAME

LOGAN

To query LOGAN data, the syntax would be https://<servername>/servlet/Router/Data/Erp?PROD=LOGAN

For example, this URL would return the VERSION data in the LOGAN data area

https://lawson.company.com/servlet/Router/Data/ERP?PROD=LOGAN&FILE=VERSION

Data Area

To query your desired data area, the syntax would be https://<servername>/servlet/Router/Data/Erp?PROD=<data area>

For example, this URL would return the CUCODE “USD” from the CUCODES table in the TEST data area.

https://lawson.company.com/servlet/Router/Data/ERP?PROD=TEST&FILE=SELECT=CURRENCY-CODE=USD&FIELD=CURRENCY-CODE,DESCRIPTION

Output

The default output type is XML, but you can also output in CSV format.  To do that, in the URL, append the command “&out=csv”.

Infor recently updated handhelds and MSCM for a cloud environment. The test user was able to download the Infor CAB files to the handheld but was unable to download the PlatformDLL file. The error message kept coming back with “Internet Explorer cannot download file”

 

After ensuring all permissions were set for the user and running several tests, rechecking the configuration setup. We finally located the issue from the update and it turns out a port was reset to a default value and we had to change the Service Type to LHC. Below are the steps you can take to resolve this if you’re experiencing a similar issue.

 

1. Login into MSCM with Server Administration group rights.
2. Select MSCM Configuration >> Additional Settings
3. Select Service Type LHC and under Handheld Service Properties, ensure you’re using the correct port. For us we had to update it to 1447

4. We updated both LSF and handheld ports to 1447 and the user was now able to download the file.

Hope this was helpful!

If you have suddenly noticed in Lawson Security Administrator that certain users have different attributes in their addins field other than ALLOW or DENY, don’t worry as this was setup by design back before LSF version 9.

These values were removed in version 9+ because Lawson User Security (LAUA) and Lawson System (LS) security can now secure these actions on specific tables and records.

If you want to convert the old Addins Attributes like to Allow or Deny, simply edit the users RM info and change the Addins field to Allow or Deny.

 

If you prefer to stay on the older attributes, see the table below for in-depth access descriptions:

Attribute ID	Description
Dxxxx	The user does not have access to the Query Wizard, but has full access to the Upload Wizard.
DDxxx	The user does not have access to any Addins functionality.  Same as the current Addins attribute = DENY.
ADxxx	The user has access to full QueryWizard functionality, but is blocked from using any part of the UploadWizard.
AADDD	The user has access to both the QueryWizard and the UploadWizard, but is blocked from adding, changing, and deleting records.
AAADD	The user can use the QueryWizard and UploadWizard to add records only.
AADAD	The user can use the QueryWizard and the UploadWizard to change records only.
AAAAD	The user can use the QueryWizard and the UploadWizard to both add and change records, but is blocked from deleting records.
AADDA	The user can use the QueryWizard and the UploadWizard todelete records only, but is blocked from adding or changing any records.
AAADA	The user can use the QueryWizard and the UploadWizard to add and delete records, but is blocked from changing any records.