Alternative procedure to migrate Maximo configurations - using MXDIFF,runscriptfile and MXAPPLY

Purpose: The purpose of this article is to explain the use of MXDIFF and MXAPPLY in Maximo.  These tools are very handy and you can migrate only the changes i.e. delta to other environments.

Example: You have a requirement to add a field “Require Permit” to work order object and include the field in Work Order application (WOTRACK.xml). And then apply the same to all environments.

Procedure:
Apply the configuration changes to dev

1.    In dev, initially, export wotrack.xml and save it to any folder for ex. C:\temp

2.    Add the field MC_PERMITREQ to WORKORDER object

3.    Add the field “Permit Required” to WOTRACK through application designer (or modify the wotrack.xml directly)

Prepare the migration package

1.    Export the modified version and rename as WOTRACK_MODIFED.xml. Save the modified file to C:\temp

2.    Now, we will create a transactions file which contains only the difference of the xmls.

3.    Open the CMD as administrator

CD to D:\IBM\SMP\maximo\tools\maximo\screen-upgrade

4.    Execute

mxdiff.bat –b”C:\temp\wotrack.xml" -m”C:\temp\wotrack.xml" -t"C:\temp\CHG1024_plusgwo.mxs"

-b : Original file

-m: modified file

-t: Transaction file which will contain the difference

5.    Next, we will create a dbc file to add, modify or delete attributes. Prepare a .dbc as explained in the link https://drive.google.com/file/d/1kIHrIv4wxY4MsVK7mpAiRtIvXAFLSFzR/view?usp=sharing

Apply the package

1.    In the destination environment, Copy the CHG1024.dbc to tools\maximo\en\script

2.    In the above path, MC is a custom folder to copy the customer’s .dbc files

3.    Open CMD as administrator and CD to <maximo_root>\tools\maximo\internal

4.    Execute runscriptfile.bat -f<script> [-c<subdirectory]

runscriptfile.bat –fCHG1024

runscriptfile.bat –fCHG1024_plusgwo_xml

5.    The attributes will be added to the object and wotrack.xml

6.    Turn admin mode on & off for the changes to be effective

Alternatively, use MXAPPLY to apply the xml differences (.mxs)

1.    Open the CMD as administrator

CD to D:\IBM\SMP\maximo\tools\maximo\screen-upgrade

2.    Execute

mxapply.bat -t\\dc2ap871\server1\dmnd0004124_plusgwo.mxs -pmaximo.properties

BMXAA1185E - The debit or credit general Ledger account is not specified

Issue: Works Administrator was reporting Actual Labor transactions in Work Order and for one technician Maximo was displaying the error "BMXAA1185E - The debit or credit general Ledger account is not specified".

Eventually Works Administrator couldn't proceed to report the technician's working hours.


Solution: I had a look at the issue and initially thought the GL account combination was invalid, reading the error message again, I noticed that the GL Account was not setting in either the LATRANS.GLDEBIT/LABTRANS.GLCREDIT. 

Looked at the Location's Internal Labor Account and noticed internal labor account wasn't mentioned. The internal labor cannot be blank as Maximo uses the internal labor control account as the credit account for any internal labor transaction. It is the accrual account for the value of internal labor "issued" to work orders or other activities. Maximo credits this account when you report internal labor use on a work order.

You can define the internal labor account for all the internal labor either in one of the below applications:

Location: 

Charts Of Accounts: This will be the default internal labor account for all GL transactions.

Labor:

Reorder Vendor and Cost logic

Question

How does reorder determine Vendor and Cost?

Answer

How does reorder determine Vendor and Cost?
After determining the quantity of items that will satisfy reorder requirements, the next step for Maximo is to determine the vendor and cost that will be used when PRs (and optionally POs) are created.

Considering Purchase Contracts
In finding a vendor and cost for the reordered item, Maximo must first evaluate the “Consider Contracts” option.



This flag indicates whether the reorder process should seek out Purchase type contracts for determining the pricing and vendor when purchasing the item(s). (Only contracts in APPR status will be considered.)

NOTE: Primary Vendor is considered to be a storeroom’s preferred vendor when running reorder. If the Primary Vendor for an inventory item is flagged as an internal supplier (ie: another storeroom),
Maximo will NOT consider contracts from external vendors, and will always generate PRs against the supplying storeroom. The unit cost will be determined as the issue unit cost of the supplying storeroom.

1. If this flag is checked, then Maximo will first look to see if any purchase contracts exist for the item with the primary vendor.

• If a contract is found, Maximo will convert the order quantity to the contract. Order Unit as necessary, and use this, quantity, the contract order unit, and the contract cost when creating PRs. The contract and revision number

will also be referenced on the PR. [If more then one contract is found in this scenario, Maximo will use the one with the lowest unit cost]

• If no contract is found Maximo will proceed to step 2 below.

2. If no contract is found, Maximo will look for any purchase contracts for the item, regardless of vendor.

• If a contract is found, Maximo will convert the order quantity to the contract痴 Order Unit as necessary, and use the contract vendor, the converted quantity, the contract order unit, and the contract cost when creating PRs.

The contract and revision number will also be referenced on the PR. [If more then one contract is found in this scenario, Maximo will use the one with the lowest unit cost]

• If still no contract is found, Maximo will use 'standard' rules for finding a vendor and cost which are documented under the next heading 'Finding a non-contract Vendor and Cost'.

Finding a non-contract Vendor and Cost
If a contract cannot be found, or if the user has chosen to not reorder using contract information, Maximo will then attempt to find a vendor and cost based on the following rules:

Organizations and Sites

All 'non-contract' vendor/cost information is stored in the INVVENDOR table. This is viewed in the application as the Vendors table window on the reorder details tab of the Inventory application, or as the Vendors tab in the Item Master application.

INVVENDOR is a catalog of items and vendors, with corresponding manufacturers, model numbers, vendor catalog codes, pricing, and last order details.

The INVVENDOR table permits the SITE field to be optional. This allows users to have 'site-level’ pricing for a given item vendor combination. Additionally, the user can leave the site empty and the item/vendor/cost combination is considered to be at
'organization-level'. For this reason, Maximo processes the cost-finding rules below FIRST based on the site of the storeroom, and if no vendor/cost combination is found, SECOND based on the organization of the storeroom with a null site.

NOTE:

• The rules below include references to the BidPrice column in the INVVENDOR table. This column was used in earlier versions of Maximo prior to the addition of true contracts functionality. The column remains in the table,

and is not shown on the screen by default. This column will be dropped in a future release.

• Unless otherwise noted, the fields below are referencing the vendors table window (INVVENDOR table).
• The rules below make reference to the REORDERPAD table. This table is used to store the data that has been processed by reorder but has not yet been processed into a PR (or PO). It is a ‘staging area’ that allows the

reorder functionality to complete its processing and then turn the finished data into a consolidated set of PRs and POs.


1. Find a Unit Cost based on Primary Vendor
For a given item/storeroom/site combination, if primary vendor is specified in INVENTORY, Maximo will sort the INVVENDOR table based on the item, primary vendor, and site of the storeroom order by last date in descending order,
use the first record where the last date is non-null. (If no record is found, re-process rule #1 based on the organization of the storeroom. If still no record found move to rule # 2 below)
a. If BidPrice is non-null and > then zero, use BidPrice
b. Otherwise use Last Cost.

When writing records to ‘Reorderpad’:
a. Set the cost from INVVENDOR. (Either BidPrice or Last Cost based on above).
b. Set the order unit from INVVENDOR. If null, set the order unit from INVENTORY.
c. Convert the reorder quantity into the order unit from INVVENDOR. If a conversion between the units does not exist, an error will be written against this item, and it will not be reordered.
d. Set the vendor, manufacturer, model number and catalog code based on the values in the Inventory application, reorder details tab, primary vendor section.

2. Find a Unit Cost based on ANY vendor (with Primary Vendor Specified)
For a given item/storeroom/site combination, IF primary vendor is specified in INVENTORY, Maximo will sort the INVVENDOR table based on the item and site of the storeroom order by last date in descending order,
use the first record where the last date is non-null. (If no record is found, re-process rule #2 based on the organization of the storeroom. If still no record found move to rule # 3 below)
a. If BidPrice is non-null and > then zero, use BidPrice
b. Otherwise use Last Cost.

When writing records to 'Reorderpad':
a. Set the cost from INVVENDOR. (either BidPrice or Last Cost based on above)
b. Set the order unit from INVVENDOR. If null, set the order unit from INVENTORY.
c. Convert the reorder quantity into the order unit from INVVENDOR. If no conversion
exists, error out this item.
d. Set the vendor, manufacturer, model number and catalog code based on the values in
the Inventory application, reorder details tab, primary vendor section.

3. Find a Unit Cost and Vendor based on the 'Default Vendor'
NOTE: The ‘Default Vendor’ is an organization-level default catalog row that is used to source items for direct issue scenarios. The ‘ISDEFAULT’ flag is used to indicate this record is the default vendor for the item in the organization. The
organization can have only one default vendor. In the case of reorder, Maximo will consider the default vendor when it determines price, ONLY if a cost cannot be determined for the primary vendor.

For a given item/storeroom/site combination, if the primary vendor is NULL in INVENTORY, Maximo will perform a select based on the ISDEFAULT flag. Maximo will take the ISDEFAULT record. (If no record is found move to rule # 4 below)
a. If BidPrice is non-null and > then zero, use BidPrice
b. Otherwise use Last Cost.

When writing records to ‘Reorderpad’:
a. Set the cost from INVVENDOR. (Either BidPrice or Last Cost based on above)
b. Set the order unit from INVVENDOR. If null, set the order unit from INVENTORY.
c. Convert the reorder quantity into the order unit from INVVENDOR. If no conversion
exists, error out this item.
d. Set the manufacturer, model number and catalog code based on the values in the
Inventory application, reorder details tab, primary vendor section.

4. Find a Unit Cost based on ANY vendor (Without Primary Vendor Specified)
For a given item/storeroom/site combination, Maximo will sort the INVVENDOR table based on the item and site of the storeroom, order by last date in descending order, use the first record where the last date is non-null. (if no
record found, re-process rule #4 based on the organization of the storeroom. if still no record found, Maximo will write a PR with a null vendor and a unit cost of zero)
a. If BidPrice is non-null and > then zero, use BidPrice
b. Otherwise use Last Cost.

When writing records to ‘Reorderpad’:
a. Set the cost from INVVENDOR. (Either BidPrice or Last Cost based on above)
b. Set the order unit from INVVENDOR. If null, set the order unit from INVENTORY.
c. Convert the reorder quantity into the order unit from INVVENDOR. If no conversion
exists, error out this item.
d. Set the vendor, manufacturer, model number and catalog code based on the values
from INVVENDOR.

PM with route does not generate parent work order

Issue: PM does not generate Parent work orders, but generate child work orders

Solution: Most of the PMs have a route associated with it and has multiple job plans associated with each PM. We noticed the Parent work orders were not created, but the child work orders were created. The Child work order has the parent WO number tagged with it, but if you navigate to the parent wo, the record doesn't exist in the system.

I verified the parent work order from workorder, workview, wostatus objects, but the record doesn't exist in any object.

After enabling logging I noticed the parent work order was created, but the system  is deleting the record from all relevant objects.

So I picked up the PM (The PM has a route with multiple job plans) which was having a problem and tried to generate work orders manually. I noticed that after successfully generating work orders, the system is trying to save the PM and while saving the PM an error is displayed "Record has been updated by another user" and as the PM wasn't successfully saved, the system is trying to delete the work order generated. But to my surprise, system is deleting only the parent PM work order, but not child work order and other relevant activities - This could be a Maximo bug.

Now coming to reason why the PM was not successfully saved: the system is trying to update JPSEQINUSE to 1 (the current value is 0) as there are multiple job plans associated with the PM. We identified the PMs were loaded through MIF and the JPSEQINUSE was set to 0 irrespective of the multiple job plans associated with the PM.

Maximo doesn't display start center after successful log in

Issue: End Users are able to successfully log in into Maximo, but after log in - a white page is displayed.

Solution: Initially I thought  it  was due to insufficient hard disk space, but my assumption was incorrect.

Then one of my colleagues advised to me to try navigating directly to work order application by typing in app=wotrack in the address bar - it opened up the work order application!. From there, I navigate to start center and the start center displayed.

On the start center, my name wasn't displaying and displays as "Welcome,{null}". So I navigate to person application to check if my name was overwritten. To my surprise my personid doesn't exist anymore in the system, whereas my user id still exist in the system. Due to this reason, I was able to log in into Maximo, but couldn't access my start center as the personid doesn't exist.

So I created my personid and since then I have been able to successfully acess start center and navigate to other applications using the Go To menu.

Later we identified the person records were deleted from the system due to the replication configuration.

Increase ASSETNUM, PRNUM field length on Screen

Issue: 1. ASSETNUM, PRNUM, PONUM key identifiers are part of muti-part textbox and unable to increase the length on screen.
2. Bold & Underline the label


Solution: Apply the below to increase the length of key identifiers.

Edit C:\ibm\SMP\maximo\applications\maximo\maximouiweb\webmodule\webclient\css\maximo.css OR
C:\ibm\WebSphere\AppServer\profiles\ctgAppSrv01\installedApps\ctgCell01\MAXIMO.ear\maximouiweb.war\webclient\css\maximo.css

add your code as follow:
.gwpart1width { width:150px; font-family: arial, sans serif, verdana; font-size: 11px; }
.gwpart2width { width:400px; font-family: arial, sans serif, verdana; font-size: 11px; }
.gwunderline { text-decoration:underline;}

how to use (modify at Application Designer):
1. set properties first part of multiparttextbox using 'textcss', and second part of multiparttextbox using 'desctextcss'
ex: <multiparttextbox applink="asset" dataattribute="assetnum" descdataattribute="description" id="main_grid8_1" desctextcss="gwpart2width " textcss="gwpart1width "/>
2. set properties labelcss
ex: <multilinetextbox columns="33" dataattribute="GW_ACTUALCAUSE" id="1337075607498" rows="5" labelcss="txtbold gwunderline"/>

Reports aren't executing properly in Clustered environment

Issue: All Reports were executing properly, but after migrating to a new environment i.e copied database from Prod to dev few reports are executing and few reports gives weird errors. The same issue can happen after Maximo upgrade

Version: Maximo 7.1 or higher

Solution: In a clustered environment, initially, you must generate the request page xml for each individual instance or all JVMs have to be restarted after generation of request pages in one JVM.