Friday, 9 November 2018

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








Monday, 27 August 2018

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:
















Tuesday, 6 March 2018

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.