Item Master vs Inventory for item records in Maximo

You may experience a scenario where some of your item records are available in different statuses in Maximo.

For example : The item is in PENDOBS status in Item Master app. But the same item is in ACTIVE in Inventory app.

But would you know why this happens ? Is my system broken ? No !

Have you asked your self about what is the difference between the Item Master and Inventory applications?
Do you understand how and when to use each ?

The reason for that is because the Item Master application is used to define Items that will be procured and stocked in
storerooms. 

You will learn to navigate to the Item Master application and use it to create, modify and manage Item records. 

Item master is for managing new items and items not associated in storerooms while Inventory app is for managing the items that are IN A SPECIFIC storeroom location, one item in Item Master can belong to MANY storeroom locations in Inventory app.

You manage data about an item record, for example vendors and classifications, in the Item
Master application, but you manage item balances in the Inventory application.

We know that there is existing relationship between those two Maximo applications (Item Master and Inventory ) but this does not mean that you can always update the Inventory data from Item Master via the relationship.

Maximo will check if the data can be updated or not based on the business rules. It is not advisable to use this relationship to update inventory data from Item
Master. This is not a one to one relationship. That is, one item in Item Master may have multiple records with same Itemnum in Inventory application.

10 Minute Tip - Scheduled reports sending multiple emails

Today we will discuss a couple of reasons why your users may be receiving multiple emails for a single scheduled report from Maximo. For example, the user has a weekly report sent to them yet, for some unknown reason, they get 2, or more copies of the report in their inbox. The "unknown" reason is usually one of two things.

• It's actually not a duplicate. Since scheduled reports do not indicate anywhere in the email where they came from - which Maximo server - we have seen times when the second email is actually not coming from the Production Maximo server. Perhaps they are testing functionality from a test server, or maybe a Sandbox server is being used and the same user has the same report set up on that server and the extra email(s) they are receiving are, in fact, being sent from this other server.  Double check the other servers - you can use the View Scheduled Reports option from Report Administration to aid in this effort.  One suggestion we have that may help is to put the server name in the email Subject or Comments section when the report is scheduled.

• The other known possible cause is related to the fact that a complex report that takes extra time to process will appear to Birt to be hung and it will restart it. Eventually these newly spawned jobs will all finish  and the emails will all be sent.  By default if the RUN phase of a report (the SQL phase) takes longer than 15 minutes the issue can present itself.  This 15 minute setting can be changed so if you feel this is the issue (and you can verify this usually be checking the report usage log to see how long the report took to complete)  you can change it as follows:

Goto -> System Configuration/Platform Configuration/Cron Task Setup

Select -> REPORTLOCKRELEASE cron task

Change Parameter-> LOCKINTERVALINMINUTES to the desired value - say 30, for example

Save changes

Restart the Maximo Application server to ensure new value is activated

There's generally no repercussions to making this change but bare in mind that it's for all scheduled reports. There is no ability to change it for specific reports.

In most cases the multiple emails are caused by one of the above situations.

That's all for now.

How I can close my requisitions automatically?

If you use the Desktop Requisition application and did a simple search on it, you may have noticed that you have a lot of useless requests there.

Well, requisitions can be closed in the following ways:                     
1) Direct Issue Materials that have a PO created. (line type = "Material" or "Service")                                               
This requisition will be closed when the PO is closed as well.         

2) Requisitions that have WO associated with them (Line type - other than "Material" or "Service")
These requisitions will be closed when the WO is closed as well        

3) You can create a new escalation or workflow to make the status change. You may change the requisition status to CLOSE or CANCEL
Regardless of what you choose to do this (WF or escalation), you must create a status change action for both.

Some Handy Links for Maximo 7.6

Hello again! This is a standalone blog entry, but I will also be adding it to a new blog post that is a compilation of the installation walk-through I posted in December 2014. Coming your way soon.

What to download for Maximo Asset Management

Maximo Upgrade Resources

Platform Configuration Matrix

Maximo Asset Management feature Packs

Version (links to technote)	Fix Central link
Maximo 7.6.0.1 Feature Pack	7.6.0.1-TIV-MAMMT-FP001
Maximo 7.6.0.2 Feature Pack	7.6.0.2-TIV-MAMMT-FP002
Maximo 7.6.0.3 Feature Pack	7.6.0.3-TIV-MAMMT-FP003
Maximo 7.6.0.4 Feature Pack	7.6.0.4-TIV-MAMMT-FP004
Maximo 7.6.0.5 Feature Pack	7.6.0.5-TIV-MAMMT-FP005
Maximo 7.6.0.6 Feature Pack	7.6.0.6-TIV-MAMMT-FP006
Maximo 7.6.0.7 Feature Pack	7.6.0.7-TIV-MAMMT-FP007
Maximo 7.6.0.8 Feature Pack	7.6.0.8-TIV-MAMMT-FP006

Installing a Feature Pack in Maximo 7.6

Installing an Interim Fix in Maximo 7.6

Maximo Best Practices for System Performance 7.6.x

Maximo Asset Management Wiki on developerWorks

Asset Management Forum on developerWorks

Maximo Request for Enhancement (RFE) Community

I will update this post periodically (and especially when new Feature Packs come out), so bookmark it!

Field required on Add to Storeroom screen

When you have an item record in Maximo, you have the option to Add Item to Storeroom, however, not every field is required.

For this example, we will use the IN20 field. If you would like to have the IN20 field in Inventory app to be required at the moment that you are adding the item to storeroom from Item app, here are some steps for you. 

All you have to do is this :

1. Go to Application Designer and search for ITEM app
2. Click on the Edit Dialogs button, on the toolbar
3. Select additemstostoreroom , which corresponds to Add Items to Storeroom
4. The dialog will appear for you to edit
5. Make sure you add a new table column for your required field (you can copy/paste an existing one and edit properties or add from Control Palette)
6. Change the properties of the new field to set :    Input Mode = Required
7. Save changes

Now, when you are in Item Master app and try to add an item to a Storeroom by using the Select Action > Add Items to Storeroom,  then Maximo will now require users to fill a value on that new field, which will be transferred over to Inventory app, preventing records with null values in that field.

See ya...

About grouping PM generation into to generate at a time

We were wondering how we could stagger PM generation within an organization across time zones and how we could further divide up the PM generation within a single large site. We would ideal like to be able to group our PM generation into even groups to generated at a certain hour within their time zone and use multiple Crontask to generate them. We can current only control the PM generation at the site configuration level. We seem to only be able to run all PMs with a single crontask with this configuration.

PMWoGenCronTask executes for all sites that the "user" has access to. When a PM Wogen crontask runs, it executes across all org/site combinations, which have automatic work order generation  for PM enabled and for which the where clause defined for the site returns records.

In that scenario, Maximo currently does not offer a functionality that allows you to do that, and some Maximo documents mention that it is important not to set up multiple instances which may contain the same sites within the users group, since this could cause errors when processing the records for generation. In other words, you cannot just set up multiple cron task instances to all process the same Site, or recordset as defined by the PM where clause.

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/IBM+Maximo+Asset+Management/page/Executing+PM+Wogen+Crontask+by+Site

However, if you still would like something to workaround this, I believe you can do the following :

NOTE :  This is just a try, I'm not sure if it will fully meet your needs, but feel free to try it on a TEST environment. :)

The PMWoGenCronTask could be divided across multiple JVMs by creating individual crontask instances, each assigned to an user restricted to see specific PM records from the same site. These specific users would have access to different PM records on the same site based on Security Restrictions / Object Restrictions defined in Security Groups app.
These users would be set as Run as User for each specific crontask instance for the PMWoGenCronTask.

In other words, you would create multiple administrative users that could run the PMWoGenCronTask, and each crontask instance would use a different value for Run As User.  The important, and implied detail, is that the crontask instances need to be selecting different record sets. 

See ya

BMXAA2256E - Field Signature Option is read-only.

You are trying to hide the following fields in Create Requisition (CREATEDR) application:
- Card Type
- Card#
- Card Verification Value
- Expiration Date

Listed below are the steps being taken in trying to achieve this task: 

1. Open CREATEDR in Application Designer
2. Click Select Action, Choose Add/Modify Signature Options
3. Create J_HIDECREDIT
4. Right-click Card Type Control, choose Properties
5. Click Advanced Tab
6. Select J_HIDECREDIT for Signature Option
7. Receive the following error: BMXAA2256E - Field Signature Option is read-only.
8. You receive the same error when you try to do the same through Configure Conditional Properties
9. You receive the same error when you try to do the same with the other fields   Card#, Card Verification Value, and Expiration Date.

It does appear these specific Control Properties are read-only and you have not found a way to change that.

You cannot modify some property settings in the fields from Charge Information section from CREATEDR app. You are trying to add a Signature Option on that, and getting : 

BMXAA2256E - Field Signature Option is read-only.

This is working as designed. The reason is because the worklog section is being included from the library.xml; the application designer does not support direct editing of those included
sections. You have to export the library.xml and edit it in there, then reimport the library.xml. Once you do that to include sigoption property to the desired controls in library.xml, and reimport library.xml into Application Designer, you will be able to hide the fields, after a Maximo server restart.

See ya