IBM Maximo Integration Framework

Maximo Integration Framework

Predefined integration content: functional description and implementation scope.
Table of Contents

Introduction................................................................................................................. 4
Master Data................................................................................................................ 4
Assets..................................................................................................................... 5
Chart of Accounts.................................................................................................... 6
Crafts....................................................................................................................... 7
GL Components...................................................................................................... 8
Labor....................................................................................................................... 9
Operating Locations.............................................................................................. 10
Person................................................................................................................... 11
Person/User.......................................................................................................... 12
Projects................................................................................................................. 13
Storeroom Locations............................................................................................. 14
Vendors................................................................................................................. 15
Vendor Master....................................................................................................... 16
Classifications....................................................................................................... 17
Item/Inventory........................................................................................................... 18
Items..................................................................................................................... 18
Service Items........................................................................................................ 19
Tool Items............................................................................................................. 20
Inventory................................................................................................................ 21
Inventory Balance.................................................................................................. 22
Inventory Vendor................................................................................................... 23
Inventory Reservations.......................................................................................... 24
Inventory Issues.................................................................................................... 25
Documents................................................................................................................ 26
Purchase Contracts............................................................................................... 28
Purchase Requisition............................................................................................ 29
Purchase Order..................................................................................................... 30
Invoice................................................................................................................... 31
Work Order Detail....................................................................................... 36
Work Order Hierarchy................................................................................ 37
CCMDB/SRM............................................................................................................ 38
Authorized Configuration Items (CI)...................................................................... 38
CI Collection.......................................................................................................... 39
Collection Authorization......................................................................................... 39
Service Requests (SR).......................................................................................... 40
Incidents................................................................................................................ 41
Problems............................................................................................................... 41
Transaction Interfaces.............................................................................................. 42
Receipts (Materials and Services)......................................................................... 42
Receipts (Materials and Rotating Items)............................................................... 46
GL Transactions.................................................................................................... 47
Labor Time Reporting........................................................................................... 53
Meter Reading Data.............................................................................................. 54
System...................................................................................................................... 56
2
 Object Structures.................................................................................................. 56
Enterprise Service................................................................................................. 57
Publish Channel.................................................................................................... 58
End Point............................................................................................................... 59
External System.................................................................................................... 60
Integration Controls............................................................................................... 61
Invocation Channel............................................................................................... 62
Integration Queues................................................................................................ 63
Message Definition................................................................................................ 64
MBO Configuration................................................................................................ 65
Domains................................................................................................................ 66
Communication Template..................................................................................... 67
Actions.................................................................................................................. 68
System Properties................................................................................................. 69
Integration Modules............................................................................................... 70
Logical Management Operations (LMO)............................................................... 71
Operational Management Products...................................................................... 72
Launch in Context................................................................................................. 73

Any product data contained herein has been reviewed for accuracy as of the date of initial publication.
Product data, including product enhancements and release dates, is subject to change without notice. Any
statements regarding IBM’s future direction and intent are subject to change or withdrawal without
notice, and represent goals and objectives only.

THE INFORMATION PROVIDED IN THIS DOCUMENT IS DISTRIBUTED “AS IS” WITHOUT ANY
WARRANTY, EITHER EXPRESS OR IMPLIED. IBM EXPRESSLY DISCLAIMS ANY WARRANTIES IF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NONINFRINGEMENT

3
Introduction
This document provides details about the predefined integration content present in the
Integration Framework (I-F). The integration content includes Object Structures, Publish
Channels and Enterprise Services that support importing and exporting data into and out of
Maximo. In some cases only the object structure is provided without a related publish
channel or enterprise service. The Integration Framework, by design, provides support for
inserting, updating, deleting and querying of data according the business rules defined in the
business objects within the object structure. It does not provide all the functionality that is
available through the applications, including those that are available from the Select Action
feature. For some object structures, there is support for some actions such as Change Status;
these supported actions are identified in the following sections.

This document is divided into the following sections:

Master Data
Item/Inventory
Documents
CCMDB/SRM
Transactions
System

Master Data
This section describes the following I-F content:

Asset
Chart of Accounts
Craft
General Ledger Components
Labor
Operating Locations
Person
Person/User
Financial Projects
Storeroom Locations
Vendor
Vendor Master
Classifications

4
Assets
Object Structure MXASSET
Detail Description Asset Object Structure (OS)
This OS allows for bidirectional synchronization of asset
information, including meters.

This OS synchronizes individual assets, but not the asset

hierarchy as a whole. It supports the addition and update of
meters tied to an asset, but not the update of meter reading
values.
Inbound processing of ASSETMETER is restricted to attributes
that define the meter (not meter reading values or other
information pertaining to meter readings).
Comments Prerequisite: Synchronize applicable operating locations,
storerooms, meters, and items before loading Assets.
The MBO relationship used to retrieve the ASSETMETER MBO
is different from the one used in the Assets application.
Therefore, the ‘changed’ attribute in the Maximo XML is not set
for any values from this MBO.
This object structure does not support Status Changes or Asset
Movement.
There is a provided Standard Service for Assets that supports
moving Assets that reside in Operating locations. The standard
service, Asset, provides an Operation, assetmoveSingleAsset, to
support this functionality.
OUTBOUND
Object Structure MoutAssetProcess – Populates the Hierarchypath field if a
Definition Class Classification is associated to the Asset.
Functionality
Publish Channel MXASSETInterface
Processing Rules None
Integration Controls None
INBOUND
Object Structure MaxAssetProcess – If the Hierarchypath is provided, the
Processing Class processing class will populate the corresponding classstructureid
Functionality field of the Asset, which creates the association of the
classification to the Asset.
Enterprise Service MXASSETInterface
Processing Rules None
Integration Controls None

5
Chart of Accounts
Object Structure MXCOA
Detail Description Chart of Account Object Structure (OS)
This object structure allows for inbound synchronization of chart of
accounts data
Comments Prerequisite: Load GL Components before loading Chart of Accounts.

There is no predefined Publish Channel for this object structure.

OUTBOUND
Object Structure None
Definition Class
Functionality
Publish Channel None
Processing Rules None
Integration Controls None
INBOUND
Object Structure MaxCOAProcess - Processes accounts that are specified in the
Processing Class following ways:
Functionality 1) As a combination of delimited segments
Example:
<GLACCOUNT>
<VALUE>6400-2-10</VALUE>
</GLACCOUNT>
The object structure validates each segment, then creates the COA
record in Maximo with:
GLACCOUNT=6400-2-10
GLCOMP01-6400
GLCOMP02=2
GLCOMP03=10
This option is available for XML and interface tables. You can specify
GL Account this way in all object structures.
2) As individual components that are part of the GLACCOUNT
datatype definition
Example:
<GLACCOUNT>
<GLCOMP glorder="0">6400</GLCOMP>
<GLCOMP glorder="1">2</GLCOMP>
<GLCOMP glorder="2">10</GLCOMP>
</GLACCOUNT>
The object structure validates the components and creates the account,
using the delimiter defined in the GLCONFIGURE table for each
segment.
This option is available for XML only.
Enterprise Service MXCOAInterface
Processing Rules None
Integration Controls None

6
Crafts
Object Structure MXCRAFT
Detail Description Craft Object Structure (OS)

This OS allows for bidirectional synchronization of Craft information.

Craft information includes Crafts, Craft skills and Craft rates.

Comments Prerequisite: If the craft references a skill or contracts, that information

must exist prior to loading Crafts.

A craft can have a standard rate; a rate for each skill-level for the craft;
or different rates for each contract that provides the craft, with an
optional skill-level rate for each contract.
The CRAFT and CRAFTSKILL records have a STANDARDRATE
field for the hourly rate for each craft or skill associated with the craft.
The CRAFTRATE record specifies rates for vendors that supply the
craft (and, optionally, different rates for each skill-craft-vendor
combination).
OUTBOUND
Object Structure None
Definition Class
Functionality
Publish Channel MXCRAFTInterface
Processing Rules None
Integration Controls None
INBOUND
Object Structure None
Processing Class
Functionality
Enterprise Service MXCRAFTInterface
Processing Rules None
Integration Controls None

7
GL Components
Object Structure MXGLCOMP
Detail Description GL Component Object Structure (OS)
This OS allows for inbound synchronization of GL Components.

Comments

OUTBOUND
Object Structure None
Definition Class
Functionality
Publish Channel None
Processing Rules None
Integration Controls None
INBOUND
Object Structure None
Processing Class
Functionality
Enterprise Service MXGLCOMPInterface
Processing Rules None
Integration Controls None

8
Labor
Object Structure MXLABOR
Detail Description Labor Object Structure (OS)

This object structure allows for bidirectional synchronization of labor

information, including Person and Labor Craft Rates.

Comments Prerequisite: Synchronize any associated craft, work location, or

storeroom location before loading labor. There can be only one Person
record for a Labor record.
OUTBOUND
Object Structure MoutLaborProcess – Processing Logic disabled.
Definition Class
Functionality
Publish Channel MXLABORInterface
Processing Rules None
Integration Controls None
INBOUND
Object Structure MaxLaborProcess – Supports Status Change. Setting ORGID for
Processing Class LaborCraftRate MBO from parent MBO. Sets the PERSONID on the
Functionality PERSON record, based on the PERSONID in the LABOR record
Enterprise Service MXLABORInterface
Processing Rules None
Integration Controls None

9
Operating Locations
Object Structure MXOPERLOC
Detail Description Operating Locations Object Structure (OS)

This OS allows for bidirectional synchronization of Operating

Location information, including location specs and meters.

Comments This OS supports synchronizing individual operating locations, but not

the location hierarchy as a whole. It supports the addition and update
of meters tied to an operating location, but not the update of meter
reading values.
Object structure supports Status Change.
OUTBOUND
Object Structure MoutOperLocProcess - Skips all outbound LOCATION records that
Definition Class are not of type OPERATING or its synonyms; Populates the
Functionality HIERARCHYPATH field based on classstructureid.
Publish Channel MXOPERLOCInterface
Processing Rules None
Integration Controls None
INBOUND
Object Structure MaxOperLocProcess - If no LOCTYPE is specified, sets value as
Processing Class default value of the OPERATING domain. Supports using the
Functionality HIERARCHYPATH to find the classstructureid.
Supports Status Change.
Enterprise Service MXOPERLOCInterface
Processing Rules None
Integration Controls None

10
Person
Object Structure MXPERSON
Detail Description Person Object Structure (OS)

This OS allows for bi-directional synchronization of Person

information, including phone, email and SMS data.

Comments This OS supports synchronizing individual Person data. It does not

support updating of a Person’s availability information.

Object structure supports Status Change.

OUTBOUND
Object Structure None
Definition Class
Functionality
Publish Channel MXPERSONInterface
Processing Rules None
Integration Controls None
INBOUND
Object Structure MaxPersonProcess – This Service requires that data for all child
Processing Class objects (PHONE, EMAIL, SMS) must be provided with every person
Functionality update. Due to a lack of a unique key on these objects, the logic
always does a complete replace of the child objects (delete all and then
add). If a Person has 3 emails in the system and a Person message is
received with 2 emails records, the email record not included in the
Person message will be deleted. There is support for Status Change.
Enterprise Service MXPERSONInterface
Processing Rules None
Integration Controls None

11
Person/User
Object Structure MXPERUSER
Detail Description Person/User Object Structure (OS)

This OS allows for bi-directional synchronization of Person/User

information.

Comments Supports Status Change

OUTBOUND
Object Structure None
Definition Class
Functionality
Publish Channel MXPERUSERInterface
Processing Rules None
Integration Controls None
INBOUND
Object Structure MaxPersonUserProcess – Processing is required to save the Person
Processing Class data prior to saving of the User date. There is support for Status
Functionality Change.
Enterprise Service MXPERSUSERnterface
Processing Rules None
Integration Controls None

12
Projects
Object Structure MXPROJ
Detail Description Financial Project Object Structure (OS)

This OS allows for bi-directional synchronization of Financial Project

information.

Comments This object structure synchronizes individual tasks and projects as

separate messages. It does not synchronize a project and all its child
tasks in a single message
OUTBOUND
Object Structure Definition None
Class Functionality
Publish Channel MXPROJInterface
Processing Rules None
Integration Controls None
INBOUND
Object Structure None
Processing Class
Functionality
Enterprise Service MXPROJInterface
Processing Rules None
Integration Controls None

13
Storeroom Locations
Object Structure MXSTORELOC
Detail Description Storeroom Location Object Structure (OS)

This OS allows for bi-directional synchronization of storeroom, labor,

and courier locations
Comments
OUTBOUND
Object Structure MoutLocProcess – Provides filtering to only send Storeroom, Courier
Definition Class or Labor Locations.
Functionality
Publish Channel MXSTORELOCInterface
Processing Rules None
Integration Controls None
INBOUND
Object Structure MaxLocProcess – Provides filtering to only accept Storeroom,
Processing Class Courier or Labor Locations
Functionality
Enterprise Service MXSTORELOCInterface
Processing Rules None
Integration Controls None

14
Vendors
Object Structure MXVENDOR
Detail Description Vendor (Companies) Object Structure (OS)

This object structure allows for bidirectional synchronization of

organization-level vendor data including Contacts.
Comments Prerequisite: To enable this object structure to create the company
master record, select the Automatically Add Companies to Company
Master flag for the set associated with the organization where the
vendor record is being added.

Object structure supports Status Change.

OUTBOUND
Object Structure None
Definition Class
Functionality
Publish Channel MXVENDORInterface
Processing Rules None
Integration Controls None
INBOUND
Object Structure MaxComProcess – Logic to support creating the company master
Processing Class record.
Functionality
Enterprise Service MXVENDORInterface
Processing Rules None
Integration Controls None

15
Vendor Master
Object Structure MXVENDORMSTR
Detail Description Vendor (Companies) Master Object Structure (OS)

This object structure allows for bidirectional synchronization of

vendor master data.
Comments

OUTBOUND
Object Structure None
Definition Class
Functionality
Publish Channel MXVENDORMSTRInterface
Processing Rules None
Integration Controls None
INBOUND
Object Structure None
Processing Class
Functionality
Enterprise Service MXVENDORMSTRInterface
Processing Rules None
Integration Controls None

16
Classifications
Object Structure MXCLASSIFICATION
Detail Description Classification Item Object Structure (OS)

This object structure allows for bidirectional synchronization of

Classifications, including class Use With, Class Specs and Class Spec
Use With.
Comments

OUTBOUND
Object Structure None
Definition Class
Functionality
Publish Channel MXCLASSInterface
Processing Rules None
Integration Controls None
INBOUND
Object Structure MaxClassificationProcess – Processing logic to find Classification and
Processing Class parent using Hierarchypath. Since Maximo allows duplicate
Functionality classifications (hierarchypaths), an exception is generated when
attempting to ‘update’ a classification if there are duplicate
occurrences.
Enterprise Service MXCLASSInterface
Processing Rules None
Integration Controls None

17
Item/Inventory
This section describes the following I-F content:

Item
Service item
Tool item
Inventory
Inventory balance
Item vendor
Inventory reservations
Issues

Items

Object Structure MXITEM

Detail Description Item Object Structure (OS)

This object structure allows for bidirectional synchronization of Item

data, including Conversions, Item Specs and Conditions.
Comments Supports Status Change

OUTBOUND
Object Structure Definition MoutItemProcess – Filter to not set Tool or Service Items. Supports
Class Functionality retrieve the Hierarchypath for the Items Classstructureid.
Publish Channel MXITEMInterface
Processing Rules None
Integration Controls None
INBOUND
Object Structure MaxItemProcess - If the inbound transaction is an item update and the
Processing Class capitalized flag of the item has changed, calls a Maximo method to
Functionality change the capitalized status of the item. If the item type is not ITEM
or a valid synonym. Supports Status Change
Enterprise Service MXITEMInterface
Processing Rules None
Integration Controls None

18
Service Items
Object Structure MXSERVICEITEM
Detail Description Service Item Object Structure (OS)

This object structure allows for bidirectional synchronization of

Service Item data.
Comments The main object, SERVICEITEMS, of the OS is a non-persistent
object.
OUTBOUND
Object Structure None
Definition Class
Functionality
Publish Channel MXSERVITEMInterface
Processing Rules None
Integration Controls None
INBOUND
Object Structure None
Processing Class
Functionality
Enterprise Service MXSERVITEMInterface
Processing Rules None
Integration Controls None

19
Tool Items
Object Structure MXTOOLITEM
Detail Description Tool Item Object Structure (OS)

This object structure allows for bidirectional synchronization of Tool

Item data, including Tool Item Specs.
Comments

OUTBOUND
Object Structure MoutToolItemProcess – Supports retrieve the Hierarchypath for the
Definition Class Items Classstructureid.
Functionality
Publish Channel MXTOOLITEMInterface
Processing Rules None
Integration Controls None
INBOUND
Object Structure MaxToolItemProcess - If the inbound transaction is an item update and
Processing Class the capitalized flag of the item has changed, calls a Maximo method to
Functionality change the capitalized status of the item.
Enterprise Service MXTOOLITEMInterface
Processing Rules None
Integration Controls None

20
Inventory
Object Structure MXINVENTORY
Detail Description Inventory Object Structure (OS)

This object structure allows for bidirectional synchronization of

Inventory (Item-Storeroom) data, including Inventory Costs.
Comments

OUTBOUND
Object Structure MoutInvProcess – Sets the value of the ITEMTYPE field from the
Definition Class ITEM object.
Functionality
Publish Channel MXINVENTORYInterface
Processing Rules SKIPINVENTORY - Skips the record if its ITEMTYPE is in the
SKIPITEMTYPE integration control.
Integration Controls SKIPITEMTYPE
INBOUND
Object Structure MaxInvProcess - Supports Status Change
Processing Class
Functionality
Enterprise Service MXINVENTORYInterface
Processing Rules None
Integration Controls None

21
Inventory Balance
Object Structure MXINVBAL
Detail Description Inventory Balance Object Structure (OS)

This object structure allows for bidirectional synchronization of

Inventory Balance data.
Comments The balance change information in this object structure is for the
lowest level (BIN or LOT) within the application.
OUTBOUND
Object Structure MoutInvBalancesProcess – Sets the value of the ITEMTYPE field
Definition Class from the ITEM object.
Functionality
Publish Channel MXINVBALInterface
Processing Rules SKIPINVBALITM - Skips the record if its ITEMTYPE is in the
SKIPITEMTYPE integration control.
Integration Controls SKIPITEMTYPE
INBOUND
Object Structure MaxInvBalancesProcess - The inbound inventory balance object
Processing Class structure internally calls the current balance adjustment method, and
Functionality this creates a CURBALADJ financial transaction in INVTRANS.
Enterprise Service MXINVBALInterface

MXINVBALQInterface – A second enterprise service that is

configured for Operation Query.
Processing Rules None
Integration Controls None

22
Inventory Vendor
Object Structure MXINVVENDOR
Detail Description Item Vendor Object Structure (OS)

This object structure allows for bidirectional synchronization of

Vendor-Item data.
Comments

OUTBOUND
Object Structure MoutInvVendorProcess – Sets the value of the ITEMTYPE field from
Definition Class the ITEM object and set the value of the CURRENCYCODE from the
Functionality Vendor (Companies) object.
Publish Channel MXINVVENDORInterface
Processing Rules INVVITEMTYPE - Skips the record if its ITEMTYPE is in the
ITEMTYPEFORINV integration control.
Integration Controls ITEMTYPEFORINV
INBOUND
Object Structure MaxInvVendorProcess - If the inbound message contains a currency
Processing Class code and that code differs from the vendor’s currency code, reports an
Functionality error.
Enterprise Service MXINVENDORInterface
Processing Rules None
Integration Controls None

23
Inventory Reservations
Object Structure MXINVRES
Detail Description Inventory Reservations Object Structure (OS)

This object structure provides for the bidirectional synchronization of

inventory (storeroom) reservations.

Comments This object structure does not process direct issue reservation records
created by Maximo.
OUTBOUND
Object Structure MoutRSVProcess – Skips reservations that are for Direct Issues.
Definition Class
Functionality
Publish Channel MXINVRESInterface
Processing Rules
Integration Controls
INBOUND
Object Structure None
Processing Class
Functionality
Enterprise Service MXINVRESInterface
Processing Rules None
Integration Controls None

24
Inventory Issues
Object Structure MXINVISSUE
Detail Description Inventory Issues Object Structure (OS)

This object structure provides for the bidirectional synchronization of

inventory (storeroom) issues and returns.

Comments

OUTBOUND
Object Structure MoutISUProcess – Skips reservations that are for Direct Issues.
Definition Class
Functionality
Publish Channel MXINVISSUEInterface - Filters out direct issues from
MATUSETRANS (PONUM is not null and ISSUETYPE is ISSUE or
RETURN) because they are handled by the receipts
(MXRECEIPTInterface) object structure. Filters out variance
transactions that are written to MATUSETRANS by the invoice
approval process.
Processing Rules
Integration Controls
INBOUND
Object Structure MaxISUProcess – If an Action is provided that is not Add, then an
Processing Class exception is generated. Validates ISSUETYPE to ensure that it is
Functionality ISSUE, RETURN, or null. If it is any other value, reports an error. If it
is null, defaults the value to ISSUE.
Enterprise Service MXINVISSUEInterface
Processing Rules None
Integration Controls None

25
Documents
This section describes the following I-F content:

Purchase contract (PC)

Purchase Requisition (PR)
Purchase order (PO)
Invoice
Work order (WO)
Work order detail
Work order Hierarchy

The STATUSIFACE Field

All purchasing and work order documents have a status, so it is necessary to identify whether
related transactions contain new or updated records, or status changes only. The
STATUSIFACE field provides this information.

In general, this field applies to all object structure sub-records that are created from stateful
MBOs, which are MBOs that have a STATUS field and support status change actions

The STATUSIFACE field has been added as a non-persistent field to those objects where
integration supports a status change.

The STATUSIFACE Field and Outbound Processing

While processing an object structure sub-record that has been created from a stateful MBO,
the I-F outbound integration processing looks for a STATUS field in the MBO and a
STATUSIFACE field in the corresponding object structure sub-record. If both fields exist,
the processing sets the value of the STATUSIFACE field to the value of the changed attribute
for the corresponding STATUS field (0 indicates not changed; 1 indicates changed).

This processing applies only to event-generated outbound messages, not to messages

exported via the Data Export feature or through a programmatic invocation.

The STATUSIFACE Field and Inbound Processing

When processing an object structure where the primary (top) MBO is stateful, the inbound
processing looks for a STATUSIFACE field on the corresponding object structure sub-record
to determine if the inbound message is to be processed as both a document update and a
status change, or as a status change only. Processes as follows:
26
 Value of Document exists in Maximo Document does not exist in Maximo
STATUSIFACE
Updates the document in Maximo Adds the document to Maximo
Not provided

0
If the status of the inbound document is Sets the status in Maximo to the status of
different from the status in Maximo, the inbound message
updates the status in Maximo

1 Updates the status in Maximo Error

Note: The processing described in the preceding table applies only to inbound processing
using object structures with a stateful primary(top) MBO. It does not apply to any stateful
MBO that is included as a child object in an object structure.

27
Purchase Contracts
Object Structure MXPC
Detail Description Purchase Contracts Object Structure (OS)

This object structure allows for bidirectional synchronization of

purchase contract information

Comments Note: This object structure currently supports purchase contracts types
of Blanket and Price only.
OUTBOUND
Object Structure MoutPCProcess – Skips reservations that are for Direct Issues.
Definition Class
Functionality
Publish Channel MXPCInterface – Using Processing Rules, Complete PC document is
sent only on Status Change.

Processing Rules 1. SKIPPC – Skips the sending of the document if both of the
following conditions are true:
h The document has not been sent out before.
h The new status is not listed in the PCSEND control.

2. SKIPPCUPDATE – Skips the sending of the document when

updated but no status change

3. SETSTATUSIFACE – Sets the value of the STATUSIFACE field to

0 (false) for all status values except those listed in the PCSEND
control.

4. CHECKSTATUS – Sends only the PC Header data if status changes

and the new status is not in the PCSEND control. (In this case the full
document was previously sent and this is sending only the status
change notification).
Integration Controls PCSEND
INBOUND
Object Structure MaxPCProcess – Supports Status Change. Creates a new revision
Processing Class when Purchase Contract already exists and revision does not. Supports
Functionality only Contract Types of Blanket and/or Price.
Enterprise Service MXPCInterface
Processing Rules None
Integration Controls None

28
Purchase Requisition
Object Structure MXPR
Detail Description Purchase Requisitions Object Structure (OS)

This object structure allows for bidirectional synchronization of

purchase requisition information

Comments Supports Status Change

OUTBOUND
Object Structure None
Definition Class
Functionality
Publish Channel MXPRInterface – Using Processing Rules, Complete PR document is
sent only on Status Change.

Processing Rules 1. SKIPPR – Skips the sending of the document if both of the
following conditions are true:
h The document has not been sent out before.
h The new status is not listed in the PRSEND control.

2. SKIPPRUPDATE – Skips the sending of the document when

updated but no status change

3. SETSTATUSIFACE – Sets the value of the STATUSIFACE field

to 0 (false) for all status values except those listed in the PRSEND
control.

4. CHECKSTATUS – Sends only the PR Header data if status

changes and the new status is not in the PRSEND control. (In this
case the full document was previously sent and this is sending only
the status change notification).
Integration Controls PRSEND
INBOUND
Object Structure MaxPRProcess – Supports Status Change.
Processing Class
Functionality If the current status of the PR is APPR, to support updates the
processing class will change the status back to WAPPR, perform
updates and then status to what is identified in the XML message.
Enterprise Service MXPRInterface
Processing Rules None
Integration Controls None

29
Purchase Order
Object Structure MXPO
Detail Description Purchase Order Object Structure (OS)

This object structure allows for bidirectional synchronization of

purchase order information

Comments Supports Status Change

OUTBOUND
Object Structure None
Definition Class
Functionality
Publish Channel MXPOInterface – Using Processing Rules, Complete PO document is
sent only on Status Change.

Processing Rules 1. SKIPPO – Skips the sending of the document if both of the
following conditions are true:
h The document has not been sent out before.
h The new status is not listed in the POSEND control.

2. SKIPPOUPDATE – Skips the sending of the document when

updated but no status change

3. SETSTATUSIFACE – Sets the value of the STATUSIFACE field to

0 (false) for all status values except those listed in the POSEND
control.

4. CHECKSTATUS – Sends only the PO Header data if status changes

and the new status is not in the POSEND control. (In this case the full
document was previously sent and this is sending only the status
change notification).
Integration Controls POSEND
INBOUND
Object Structure MaxPOProcess – Supports Status Change.
Processing Class
Functionality If the current status of the PO is APPR, to support updates the
processing class will change the status back to WAPPR, perform
updates and then status to what is identified in the XML message.

If the inbound PO is a release PO that needs to be added in Maximo,

then the PO inbound processing identifies the contract revision details
from the PO and attempts to create a release for that PO.
Enterprise Service MXPOInterface
Processing Rules None
Integration Controls None

30
Invoice
Object Structure MXINVOICE
Detail Description Invoice Object Structure (OS)

This object structure allows for bidirectional synchronization of Invoice

information

Comments Supports Status Change

OUTBOUND
Object Structure None
Definition Class
Functionality
Publish Channel MXINVOICEInterface – Using Processing Rules, Complete Invoice
document is sent only on Status Change.

Processing Rules 1. SKIPINVOICE – Skips the sending of the document if both of the
following conditions are true:
h The document has not been sent out before.
h The new status is not listed in the IVSEND control.

2. SKIPINVIOCEUPDATE – Skips the sending of the document when

updated but no status change

3. SETSTATUSIFACE – Sets the value of the STATUSIFACE field to 0

(false) for all status values except those listed in the IVSEND control.

4. CHECKSTATUS – Sends only the Invoice Header data if status changes

and the new status is not in the IVSEND control. (In this case the full
document was previously sent and this is sending only the status change
notification).
Integration Controls IVSEND
INBOUND
Object Structure
Processing Class MaxAPPRocess
Functionality
The inbound processing creates and updates INVOICECOST lines only if
one of the following conditions is met:

The invoice line does not reference a PO line.

The corresponding PO line does not have a distribution.
The PO line does not reference a storeroom.

In all other cases, the inbound processing ignores INVOICECOST

information when creating or updating the invoice.

If the inbound message provides INVOICETERMS, the inbound processing

31
 deletes the old terms and adds the new ones.

Users can optionally specify a price variance in the PRICEVAR field on each
invoice line, if invoice matching is done in the external system and price
variances determined in the external system are sent to Maximo to create
variance transactions to update work orders and storerooms. In order for
Maximo to process these variances, a value must exist for OWNERSYSID in
the inbound invoice, and it cannot be the same as the value of
MAXVARS.MXSYSID.

The IVMATCH collaboration switch lets Maximo create and approve an

invoice without identifying the matched receipt lines for the invoice line and
determining the variances for each line. This switch lets the external system
provide the variances at line level so Maximo can take those variances and
create the corresponding variance transactions in the INVOICETRANS,
MATRECTRANS, or SERVRECTRANS table.

The IVMATCH collaboration switch requires the following values:

OWNER1SYSID value is always “THISMX”.
OWNER2SYSID value is the value of INVOICE.OWNERSYSID.

If the evaluation is false, Maximo ignores the line level invoice variances in
the invoice processing.

If the evaluation is true, Maximo does not carry out any invoice matching
and any variance information provided at the line level is used to create the
corresponding variance transactions in INVOICETRANS/
MATRECTRANS/ SERVRECTRANS as applicable.

Typical scenarios for using the invoice interface are as follows:

Invoice Matching in Maximo (AP Outbound): Invoices received from third

parties—either electronically or manually—are processed by Maximo; that
is, they are matched against receipts, if applicable, and then approved.
Alternately, payment schedules created in Maximo will result in approved
invoices being created based on the schedule. These approved invoices result
in a payment advice being sent to an external AP system. The process of
matching also results in accounting entries being posted to the general
ledger.

Invoice Matching in external system (Variances Inbound): Maximo does not

do the invoicing, but accepts matched invoices from external systems and
applies any variances back to the respective work orders, storerooms, and so
on. The accounting entries related to the accounts payable and/or variances
must be recorded in the external system; they will not be sent out by
Maximo.

The primary intent of this interface is to provide Maximo with any variance
information necessary for updating the work order costs

The table following this one lists possible INVOICE.OWNERSYSID values,

32
 the evaluation that Maximo generates, and the default result of the
evaluation.

IVMATCH Collaboration Switch Evaluation

Value of Evaluation Result
INVOICE.OWNERSYS (Default)
ID

Null OWNER1SYSID=”THISMX” False

and
OWNER2SYSID=”THISMX”
OWNER1SYSID=”THISMX”
MXSYSID and False
OWNER2SYSID=”THISMX”
OWNER1SYSID=”THISMX”
EXTSYSID and OWNER2SYSID=”EXT” True
OWNER1SYSID=”THISMX”
Any other value and OWNER2SYSID=”EXT” True
Enterprise Service
MXINVOICEInterface
Processing Rules
None
Integration Controls
None

33
Outbound Processing Rules for Work Order Interfaces
This section describes the following types of interfaces:

Work order
Work order detail

Unlike the purchasing document interfaces, the work order document interfaces do not have a
STATUSIFACE field or status change notification functionality. They are first sent out when
the work order reaches the status of the WOSTART control and on every update thereafter,
regardless of the status of the work order.

Users can configure the start value in the WOSTART control. Any status that you specify in
the control is the value, not the MAXVALUE. If multiple synonym values exist for a status,
list all applicable synonyms.

Work Order

Object Structure MXWO

Detail Description Work Order Object Structure (OS)

This object structure allows for bidirectional synchronization of work

order information

Comments Supports Status Change - Maximo first sends out a work order when it
reaches the status in the WOSTART control, then on all updates
thereafter. The entire WO document is always sent.

The work order interface contains all the information defined by

Maximo on the work order, but it does not provide additional
information about projects/financial control data, equipment, and
locations that is not part of the standard work order in Maximo. If
necessary, you can add the additional information via user fields.

Maximo treats work order tasks as work orders. Both have similar
properties and they are stored in the same table. If a user creates a
work order, adds tasks/child work orders to the work order, and then
approves the work order, the Inherit Status Changes flag on the work
order indicates whether approval of the work order also results in
approval of all the tasks/child work orders of that particular work
order. The default is Y, so when a work order is approved, any child
tasks or work orders that inherit the parent’s approval based on this
flag are also approved.

The outbound event listener on the work order MBO receives

multiple independent events— one for each work order—and they are
processed and sent out independently. Therefore, a work order with
three tasks and two child work orders will result in six independent
34
 outbound work orders.

OUTBOUND
Object Structure Definition
Class Functionality
Publish Channel
None
MXWOInterface – Using Processing Rules, Complete WO document
is sent only on Status Change.

Processing Rules 1. SKIPWO – Skips the sending of the document if both of the
following conditions are true:
h The document has not been sent out before.
h The new status is not listed in the WOSTART control.

Integration Controls WOSTART

INBOUND
Object Structure StatefulMicSetIn – Generic class that supports status change.
Processing Class
Functionality
Enterprise Service MXWOInterface
Processing Rules None
Integration Controls None

35
Work Order Detail
Object Structure MXWODETAIL
Detail Description Work Order Detail Object Structure (OS)

This object structure allows for bidirectional synchronization of

work order information including planned Material, Labor,
Service and Tools.

Comments Maximo first sends out a work order when it reaches the status in
the WOSTART control, then on all updates thereafter. The entire
WO document is always sent.

The MBO relationship used to retrieve the Reservation MBO

(INVRESERVE) is different from the one used in the Work
Order Tracking application. Therefore, the changed attribute in
the Maximo XML is not set for any values from this MBO
OUTBOUND
Object Structure MoutWORsvProcess – Code required to update sendersysid
Definition Class column on the invreserve MBO
Functionality
Publish Channel MXWODETAILInterface – Using Processing Rules, Complete
WO document with Plan information is sent only on Status
Change.

Processing Rules 1. SKIPWO – Skips the sending of the document if both of the
following conditions are true:
h The document has not been sent out before.
h The new status is not listed in the WOSTART control.

Integration Controls WOSTART

INBOUND
Object Structure N/A
Processing Class
Functionality
Enterprise Service N/A
Processing Rules N/A
Integration Controls N/A

36
Work Order Hierarchy
Object Structure MXWOHIER
Detail Description Work Order Detail Object Structure (OS)

This object structure allows for bidirectional synchronization of

work order information including children Work Orders.

Comments Supports Status Change - Maximo first sends out a work order
when it reaches the status in the WOSTART control, then on all
updates thereafter. The entire WO document is always sent.

OUTBOUND
Object Structure
Definition Class
Functionality
Publish Channel MXWOHierInterface – Contains an Event Filter class,
WOHierarchyEventFilter, that prevents the child MBOs from
being sent out when they are being sent out via a parent MBO
(where both parent and child MBOs are initiated by the same
event action).
Processing Rules 1. SKIPWO – Skips the sending of the document if both of the
following conditions are true:
h The document has not been sent out before.
h The new status is not listed in the WOSTART control.

Integration Controls WOSTART

INBOUND
Object Structure MaxWOHierarchyProcess – supports status changes and commit
Processing Class processing to support loading multiple related WOs in a single
Functionality message.

Enterprise Service MXWOHierInterface

Processing Rules N/A
Integration Controls N/A

37
CCMDB/SRM
This section describes the following I-F content:

Authorized Configuration Items (CI)

CI Collections
Collection Authorization
Service Requests
Incidents
Problems

Authorized Configuration Items (CI)

Object Structure MXAUTHCI

Detail Description Authorized CI Object Structure (OS)
This OS allows for bidirectional synchronization of CI information,
including CI Relationships and Specifications.

Comments

OUTBOUND
Object Structure None
Definition Class
Functionality
Publish Channel MXAUTHCIInterface
Processing Rules None
Integration Controls None
INBOUND
Object Structure MaxCIProcess
Processing Class
Functionality
Enterprise Service MXAUTHCIInterface
Processing Rules None
Integration Controls None

38
CI Collection

Object Structure MXCOLLECTION

Detail Description CI Collection Object Structure (OS)
This OS allows for bi-directional synchronization of Collection
information, including Collection Detail, CIs and Actual CIs.

Comments Built for the TADDM Adapter

OUTBOUND
Object Structure None
Definition Class
Functionality
Publish Channel COLLECTIONPC - contains the processing class, AuthSyncColExit,
to support interaction w/ TADDM.
Processing Rules None
Integration Controls None
INBOUND
Object Structure MaxCollectProcess
Processing Class
Functionality
Enterprise Service None
Processing Rules None
Integration Controls None

Collection Authorization

Object Structure MXCOLLECTIONAUTH

Detail Description Collection Authorization Object Structure (OS)
This OS allows for bi-directional synchronization of Collection
Authorization information

Comments Built for the TADDM Adapter

OUTBOUND
Object Structure None
Definition Class
Functionality
Publish Channel COLLECTIONAUTHPC - contains the processing class,
AuthSyncColAuthExit, to support interaction w/ TADDM.

Processing Rules None

Integration Controls None

39
 INBOUND
Object Structure MaxCollectAuthProcess
Processing Class
Functionality
Enterprise Service None
Processing Rules None
Integration Controls None

Service Requests (SR)

Object Structure MXSR

Detail Description Service Request Object Structure (OS)
This OS allows for bidirectional synchronization of SR information

Comments Supports Status Change

OUTBOUND
Object Structure Definition
Class Functionality
Publish Channel MXSRInterface
Processing Rules SKIPSR – Skip the sending of the SR if the SR status is not in the list
of statuses within the SRSEND Control.
Integration Controls SRSEND
INBOUND
Object Structure StatefulMicSetIn – generic class to support status change
Processing Class
Functionality
Enterprise Service MXSRInterface
Processing Rules None
Integration Controls None

40
Incidents

Object Structure MXINCIDENT

Detail Description Incident Object Structure (OS)
This OS allows for bidirectional synchronization of Incident
information

Comments Supports Status Change

OUTBOUND
Object Structure
Definition Class
Functionality
Publish Channel MXINCIDENTInterface
Processing Rules SKIPIC – Skip the sending of the Incident if the Incident status is not
in the list of statuses within the ICSEND Control.
Integration Controls ICSEND
INBOUND
Object Structure StatefulMicSetIn – generic class to support status change
Processing Class
Functionality
Enterprise Service MXINCIDENTInterface
Processing Rules None
Integration Controls None

Problems

Object Structure MXPROBLEM

Detail Description Problem Object Structure (OS)
This OS allows for bidirectional synchronization of Problem
information

Comments Supports Status Change

OUTBOUND
Object Structure
Definition Class
Functionality
Publish Channel MXPROBLEMInterface
Processing Rules SKIPPB – Skip the sending of the Problem if the Problem status is not
in the list of statuses within the PBSEND Control.

41
 Integration Controls PBSEND
INBOUND
Object Structure StatefulMicSetIn – generic class to support status change
Processing Class
Functionality
Enterprise Service MXPROBLEMInterface
Processing Rules None
Integration Controls None

Transaction Interfaces
This section describes the following types of interfaces:

Receipts (Material & Service)

Receipts (Material & Rotating Items)
General ledger transactions
Labor time reporting
Meter Readings

Receipts (Materials and Services)

Object Structure MXRECEIPT

Detail Description Receipts Structure (OS)
This OS allows for bidirectional synchronization of PO Receipt
information for Material and Service Receipts.

Comments Supports Status Change. Uses a Non-Persistent object to support both

Material (MATRECTRANS) and Service (SERVRECTRANS)
receipts.

In the outbound direction, this OS processes purchase order receipts,

transfers (movements against receipts or receipts against internal POs),
and returns (returns to vendors after receipt inspection, or returns to
vendor after acceptance and goods movement from the inspection
holding location).

For receipts that require inspection, the user-defined field

INSPECTED indicates if the receipt line was inspected in the external
system. The interface does not process TRANSFERs independently;
each transfer is associated with a receipt.

42
 You do not have to specify whether an inbound receipt is a material
receipt or a service receipt. The integration processing determines this
from the POLINE.

All quantities, including return quantities, must be positive.

You can distinguish between the two types of transfer records by the
value in the RECEIPTREFID field, as follows:

Null: a receipt against an internal PO

Not null: movement against a receipt
Do not specify a RECEIPTFREF value for returns. Returns are
processed independently of the corresponding receipt.

OUTBOUND
Object Structure MoutProcess - Processes receipts with issue type of RECEIPT or
Definition Class RETURN. If no issue type is specified, it is treated as RECEIPT.
Functionality
Processing for RECEIPT issue type and Inspection Required = N:
Material and service receipts:
h Uses inbound RECEIPTQUANTITY (for material receipts) or
QTYTORECEIVE (for service receipts) to create the Maximo receipt.
h Maps inbound REJECTEDQTY to the REJECTEDQTY field in the
Maximo receipt.
h Ignores any other quantities.
h Does not look at the inbound INSPECTED field.

Material receipts (MATRECTRANS records):

Sends out only RECEIPT and RETURN type records and TRANSFER
type records containing a PONUM (not a storeroom transfer). Sends
out new receipts only, not updates to existing receipts.

Service receipts (SERVRECTRANS records):

Sends out RECEIPT and RETURN type records. Sends out new
receipts and updates to existing receipts
Publish Channel MXRECEIPTInterface
Processing Rules
Service receipts:

Sends out records when the status is equal to a value in the

SERVRECSTAT control (default COMP). This occurs under the
following conditions:

A record that does not require inspection is inserted.

An existing record is updated in Maximo and the status field is changed
to COMP

43
 Integration Controls SERVRECSTAT control identifies all statuses at which Maximo will
send out service receipt transactions. It can have multiple values. By
default, its value is COMP.
INBOUND
Object Structure
Processing Class MaxRCVProcess -
Functionality
Processing for RECEIPT issue type and Inspection Required = Y:

Material receipts:

INSPECTED = N:

Uses only the inbound RECEIPTQUANTITY field to create the Maximo

receipt; ignores accepted and rejected quantity values.

Creates Maximo receipt with STATUS = WINSP (waiting inspection)

and quantity derived from RECEIPTQUANTITY.

INSPECTED = Y:

Uses the inbound RECEIPTQUANTITY, ACCEPTEDQTY, and

REJECTEDQTY fields to create the Maximo receipt.

Does not allow partial inspections or acceptances. RECEIPTQUANTITY

must equal ACCEPTEDQTY + REJECTEDQTY.

Creates Maximo receipt with STATUS = WASSET (if rotating item) or

COMP (all other items).

Depending on quantities specified, can create up to three transactions—

one RECEIPT, one TRANSFER, and one RETURN.

Service receipts:

INSPECTED = N:

Uses the inbound AMTTORECEIVE (if POLINE order quantity is null)

or QTYTORECEIVE (in other cases) to create Maximo receipt; ignores
all other quantity values.

Creates Maximo receipt with STATUS = WINSP (waiting inspection)

and quantity derived from QTYTORECEIVE.

INSPECTED = Y:

Uses the inbound QTYTORECEIVE, ACCEPTEDQTY, and

REJECTEDQTY fields to create Maximo receipt.

Does not allow partial inspections or acceptances. QTYTORECEIVE

must equal ACCEPTEDQTY + REJECTEDQTY.

44
 Creates a single transaction of type RECEIPT, with
STATUS = COMP.

Processing for RETURN issue type:

Material and service receipts:

Accepts return transactions for a POLINE only if there was an earlier

receipt for the same line; if Inspection Required = Y for the POLINE, the
receipt must have been approved. Otherwise, reports an error.

Uses only the inbound RECEIPTQUANTITY (for material receipts) or

QTYTORECEIVE (for service receipts) field to create the Maximo
receipt; ignores all other quantity values.

Creates a single transaction with issue type RETURN and the credit GL
account as the RBNI account.
Enterprise Service MXRECEIPTInterface
Processing Rules None
Integration Controls None

45
Receipts (Materials and Rotating Items)

Object Structure MXRCVROTITM

Detail Description Material and Rotating Item Receipt Object Structure (OS)
This OS allows for inbound synchronization of Receipt Information for
Items including rotating items.

Comments Supports inbound processing only.

This interface does not let you specify a status for the receipt; the
status is always assumed to be COMP.

This interface differs from the MXRECEIPTInterface in that it

processes material receipts exclusively and lets you identify serialized
rotating assets to be created in the case of rotating item receipts.

You can receive rotating items with or without asset numbers. If you
receive them without asset numbers, you must manually specify the
asset numbers via the Receive Rotating Items dialog box in the
Purchasing Receiving application.

For rotating items, the number of inbound transactions is one more

than the number of rotating items. There is one transaction for the total
receipt quantity, and one transaction for each rotating item associated
with the receipt. For example, for a receipt of ten rotating items, there
will be eleven transactions.

OUTBOUND
Object Structure None
Definition Class
Functionality
Publish Channel None
Processing Rules None
Integration Controls None
INBOUND
Object Structure MaxRcvRotItmMProcess –
Processing Class
Functionality
Reports an error if the PO line being processed has
LINETYPE = SERVICE or STDSERVICE.

Processing is the same as the Inbound Integration Point Processing

Class Functionality for material receipts using the
MXRECEIPTInterface, with the following additional processing:

Receipts: If the line item is a rotating item and Inspection

Required = N, or INSPECTED = Y, checks for asset information
corresponding to the item provided in the interface. If the information
is available, validates the number of asset records to ensure it equals

46
 the RECEIPTQTY or ACCETPTEDQTY (whichever applies). If it
does, invokes the Maximo receiving functionality and creates asset as
required.

Returns: If the item being returned is a rotating item, ignores any asset
information.

In Maximo, return of a rotating type item does not affect the assets
created by the original receipt. The asset records remain unchanged;
only the item balances are updated (if applicable).

Enterprise Service MXRCVROTITMInterface

Processing Rules None
Integration Controls None

GL Transactions
Object Structure MXGLTXN
Detail Description GL Structure (OS)
This OS allows for outbound synchronization of GL transactions

This interface allows for the posting of site-level transactions

generated in Maximo to an external general ledger application for
accounting reconciliation.

This interface uses a non-persistent MBO with data from the following

sub-records:

SERVRECTRANS
MATRECTRANS
INVTRANS
INVOICETRANS
MATUSETRANS
LABTRANS
TOOLSTRANS

The event Filter class, GLEventFilter, is used to set the events to the
applicable persistent objects listed above.

Comments
The SOURECEMBO field identifies the table in which the transaction
originated. Its value is derived from the GLSOURCEMBO synonym
domain.
OUTBOUND

47
Object Structure MoutGLProcess -
Definition Class
Functionality Service Receipts

Service receipts include the following:

Accounting entries for non-distributed service receipts created by the

Receiving application for services ordered on POs
(ISSUETYPE = RECEIPT, COSTINFO=1)

Accounting entries for distributed service receipts created by the

Receiving application for services ordered on POs (ISSUETYPE =
POCOST)

Accounting entries for PO services with Receipt Required = N that are

directly invoiced instead of being received (ISSUETYPE = INVOICE)

Accounting entries for services that are not against POs and are invoiced
directly (ISSUETYPE = INVOICE)

Invoice variance transactions recorded against service receipts

(ISSUETYPE = INVOICE)

Service receipts (SERVRECTRANS) processing:

Sets SOURCEMBO to SERVRECTRANS and ISSUETYPE to value

listed above.

INVOICE type transactions: sends out on insert.

POCOST and RECEIPT type transactions: if Inspection

Required = N for the corresponding POLINE, sends out on insert. If
inspection required = Y, sends out when status is changed to COMP.

Material receipts:

Material receipts include the following:

Accounting entries for non-distributed material receipts created by the

Receiving application for items/ tools ordered on POs (ISSUETYPE =
RECEIPT, COSTINFO = 1)

Accounting entries for distributed material receipts created by the

Receiving application for items/ tools ordered on POs
(ISSUETYPE = POCOST)

Accounting Entries for Item transfers between storerooms (ISSUETYPE

= TRANSFER and PONUM=NULL)

48
Accounting entries for receipt inspection transfers of items between the
receipt inspection storeroom and the PO line storeroom (ISSUETYPE =
TRANSFER and RECEIPTREF!=NULL and PONUM!=NULL)

Accounting entries for receipts against internal POs (ISSUETYPE =

TRANSFER and RECEIPTREF=NULL and PONUM!=NULL)

Accounting entries for receipt inspection goods return of items and

materials (ISSUETYPE = RETURN)

Accounting entries for return to vendor from a storeroom or direct issue

PO lines (ISSUETYPE = RETURN)

Invoice variance transactions recorded against material receipts

(ISSUETYPE = INVOICE)

Accounting transaction for increasing the kit item’s INVENTORY

control account value when kits are made (ISSUETYPE = KITMAKE).

Accounting transactions for increasing the INVENTORY control account

for each constituent item of a kit when a kit is
disassembled (ISSUETYPE = KITBREAK)

Material receipts (MATRECTRANS) processing:

Sets SOURCEMBO to MATRECTRANS and ISSUETYPE to value

listed above.

Sends out INVOICE, RECEIPT, TRANSFER, RETURN, KITMAKE

and KITBREAK type transactions on insert.

For POCOST type transactions on insert if status is COMP (that is, on

insert if Inspection Required = N, and when status changed to COMP
if Inspection Required = Y).

Inventory Adjustments

Inventory adjustment transactions include the following:

Inventory current balance adjustments

(ITTYPE = CURBALADJ)

Inventory standard/ average cost adjustments

(ITTYPE = STDCOSTADJ/ AVGCOSTADJ)

Cost difference when a kit is disassembled and there is a difference

between the value of the kit and the sum of the kit component values

49
(ITTTYPE = KITCOSTVAR)

Physical count reconciliation (ITTYPE = RECBALADJ)

Capitalized cost adjustment (ITTYPE = CAPCSTADJ)

Standard cost receipt adjustment (ITTYPE = STDRECADJ)

Inventory adjustment (INVTRANS) processing:

Sets SOURCEMBO to INVTRANS and ITTYPE to value listed above.

Does not send out transactions with ITTTYPE = INSERTITEM,

CREATEASSET and PHYSCNT, as they are considered audit records
rather than accounting transactions.

Sends out all other transactions on insert.

Invoice Transactions

Invoice transactions include the following transactions created by

invoice approval:

Invoice TOTAL transaction (amount payable to invoice vendor,

TRANSTYPE = TOTAL)

Invoice line tax transactions (tax accounting for each TAX code for an
invoice line, TRANSTYPE = TAX1:TAX5)

Invoice currency variance transaction

(TRANSTYPE = CURVAR)

Invoice price variance transactions

(TRANSTYPE = INVCEVAR)

Invoice transaction (INVTRANS) processing:

Sets SOURCEMBO to INVOICETRANS and TRANSTYPE to the

value listed above.

Sends out all transactions when they are created.

Material Issues and Returns

Material issue and return transactions include the following:

Accounting entries for items issued from a storeroom in Maximo

(ISSUETYPE = ISSUE)

Accounting entries for items returned to a storeroom (ISSUETYPE =

RETURN)

50
 Material issue and return (MATUSETRANS) processing:

Sets SOURCEMBO to MATUSETRANS and ISSUETYPE to value

listed above.

Does not send out direct issue transactions that are created by PO
receiving/ invoice variances in MATUSETRANS, as they are
accounted for in MATRECTRANS. Identifies such transactions by
their PONUM, so all MATUSETRANS transactions that have a PO
reference are not sent out by this interface.

Sends out all other transaction at time of creation.

Labor Transaction (LABRTRANS) processing

Sets SOURCEMBO to LABTRANS.

If approval not required, send out labor actuals against work orders on
insert.

If approval required, sends out transaction after it is approved

(when GENAPPSERVRECEIPT is Y).

Tool Transaction (TOOLTRANS) processing:

Sets SOURCEMBO to TOOLTRANS.

Sends out usage of tools on work orders on creation of TOOLTRANS

Publish Channel MXGLTXNInterface

Processing Rules SKIPGL – Skip the sending of the GL transaction based on the value in
SOURCEMBO existing in the GLSOURCE Control.
Integration Controls GLSOURCE
INBOUND
Object Structure N/A
Processing Class
Functionality
Enterprise Service N/A
Processing Rules N/A
Integration Controls N/A

51
Labor Time Reporting
Object Structure MXEMPACT
Detail Description Labor Time Reporting Object Structure (OS)

This interface allows for posting site-level actual time reported in

Maximo to external applications.

Maximo sends out approved labor actuals and accepts all inbound
labor actuals regardless of status.

Note: Maximo does not update the status of existing records

when processing inbound transactions
Comments
OUTBOUND
Object Structure None
Definition Class
Functionality
Publish Channel MXEMPACTInterface
Processing Rules SKIPEMPACT – Skip the sending of the Labor Pay
(LABTRANS) if the transaction is not approved
(GENAPPRSERVRECEIPT = 0).
Integration Controls
INBOUND
Object Structure MaxEmpactProcess – Allows action of Add only – Null action
Processing Class will process as Add. LABTRANSID is not allowed to passed
Functionality with a value – will be program generated during Add.
Enterprise Service MXEMPACTInterface
Processing Rules None
Integration Controls None

52
Meter Reading Data
Object Structure MXMETERDATA
Detail Description Meter Reading Object Structure (OS)

This interface allows inbound synchronization of Meter Reading

data.
Comments Supports inbound processing only

This interface does NOT support processing of meter readings

against work order-task.
OUTBOUND
Object Structure None
Definition Class
Functionality
Publish Channel None
Processing Rules None
Integration Controls None
INBOUND
Object Structure MaxMeterDataProcess -
Processing Class
Functionality The processing class will verify that the following attributes are
provided
h -Site ID
h -Asset or Location
h -Meter ID or Condition Monitoring Point
h -Meter Reading Value, Reading Date Time, Inspector

When a work order is specified and if a measurement point is

specified, the processing class identifies the asset or location
meter corresponding to the site – measurement point, creating a
meter reading for that asset/ location meter.
h
If a meter is specified, then either asset or location must be
specified. If both are specified, the processing class assumes the
meter belongs to the asset, and will be processed accordingly. If
only asset or location is specified then the meter on the
corresponding entity will be updated.
If no work order is specified,
h If a measurement point is specified, reading is recorded for the
measurement point.

h If a meter is specified, then either asset or location must be

specified. If both are specified, the processing class assumes the
meter belongs to the asset, and will be processed accordingly. If

53
 only asset or location is specified then the meter on the
corresponding entity will be updated.

Enterprise Service MXMETERInterface

Processing Rules None
Integration Controls None

54
System
Some of the content related to integration is specific to MBOs are considered system objects
in Maximo. These MBOs are generally used for application or metadata configuration, and
updating data through these MBOs may require specific post processing activities in Maximo
(for example, reconfiguring the database)..

The following restrictions apply to the use of Enterprise Services, Publish Channels and
Object Structures:

You cannot enable listeners for Publish Channels.

You cannot process system interfaces via interface tables or flat files.
You must specify an action code on inbound system interfaces.

Object Structures
Object Structure MXINTOBJECT

Detail Description Object Structures object structure (OS)

This OS allows for inbound synchronization of the definition of

Object Structures, including column aliases.

Comments
System validations that apply to users adding, deleting and
modifying predefined Object Structures apply to the modification
of Object Structures via the Object Structure object structure
service.
OUTBOUND
Object Structure Definition N/A
Class Functionality
Publish Channel N/A
Processing Rules None
Integration Controls None
INBOUND
Object Structure Processing N/A
Class Functionality
Enterprise Service N/A
Processing Rules None
Integration Controls None

55
Enterprise Service
Object Structure MXENTSRV

Detail Description Enterprise Service object structure (OS)

This OS allows for inbound synchronization of the definition of

Enterprise Services and their corresponding processing rules and
control values.

Comments Before Enterprise Service creation, make sure all controls used by
the Enterprise Service exist in Maximo.
OUTBOUND
Object Structure Definition N/A
Class Functionality
Publish Channel N/A
Processing Rules None
Integration Controls None
INBOUND
Object Structure Processing N/A
Class Functionality
Enterprise Service N/A
Processing Rules None
Integration Controls None

56
Publish Channel
Object Structure MXIFACEOUT

Detail Description Publish Channel object structure (OS)

This OS allows for inbound synchronization of the definition of

Publish Channels their corresponding processing rules and control
values.

Comments Before Publish Channel creation, make sure all controls used by the
Publish Channel exist in Maximo.
OUTBOUND
Object Structure Definition N/A
Class Functionality
Publish Channel N/A
Processing Rules None
Integration Controls None
INBOUND
Object Structure Processing N/A
Class Functionality
Enterprise Service N/A
Processing Rules None
Integration Controls None

57
End Point
Object Structure MXENDPOINT

Detail Description End Point object structure (OS)

This OS allows for inbound synchronization of the definition of

End Points.

Comments Before End Point creation, make sure handlers used by End Points
exist in Maximo.
OUTBOUND
Object Structure Definition N/A
Class Functionality
Publish Channel N/A
Processing Rules None
Integration Controls None
INBOUND
Object Structure Processing N/A
Class Functionality
Enterprise Service N/A
Processing Rules None
Integration Controls None

58
External System

Object Structure MXEXTSYS

Detail Description External System object structure (OS)

This OS allows for inbound synchronization of the definition of an

external system, the Enterprise Services and Publish Channels used
by the external system, and their corresponding control values.

Comments Before External System creation, make sure all Enterprise Services,
Publish Channels, end points, and controls used by the external
system exist in Maximo.
OUTBOUND
Object Structure Definition N/A
Class Functionality
Publish Channel N/A
Processing Rules None
Integration Controls None
INBOUND
Object Structure Processing N/A
Class Functionality
Enterprise Service N/A
Processing Rules None
Integration Controls None

59
Integration Controls
Object Structure MXIFACECONTROL

Detail Description Integration Control Object Structure (OS)

This OS allows for inbound synchronization of Integration Controls

and their system level default values.

Comments
OUTBOUND
Object Structure Definition N/A
Class Functionality
Publish Channel N/A
Processing Rules None
Integration Controls None
INBOUND
Object Structure Processing N/A
Class Functionality
Enterprise Service N/A
Processing Rules None
Integration Controls None

60
Invocation Channel
Object Structure MXIFACEINVOKE

Detail Description Invocation Channel Object Structure (OS)

This OS allows for inbound synchronization of an Invocation

Channel definition.

Comments
OUTBOUND
Object Structure Definition N/A
Class Functionality
Publish Channel N/A
Processing Rules None
Integration Controls None
INBOUND
Object Structure Processing N/A
Class Functionality
Enterprise Service N/A
Processing Rules None
Integration Controls None

61
Integration Queues
Object Structure MXQUEUE

Detail Description Integration Queue Object Structure (OS)

This OS allows for inbound synchronization of Integration Queue

definitions.

Comments
OUTBOUND
Object Structure Definition N/A
Class Functionality
Publish Channel N/A
Processing Rules None
Integration Controls None
INBOUND
Object Structure Processing N/A
Class Functionality
Enterprise Service N/A
Processing Rules None
Integration Controls None

62
Message Definition
Object Structure MXMESSAGE

Detail Description Message Definition object structure (OS)

This OS allows for inbound synchronization of system error and

warning messages.

Comments In addition to the new messages added via this object structure, the
messages.xml file must be updated with the corresponding message
text.

OUTBOUND
Object Structure Definition N/A
Class Functionality
Publish Channel N/A
Processing Rules None
Integration Controls None
INBOUND
Object Structure Processing N/A
Class Functionality
Enterprise Service N/A
Processing Rules None
Integration Controls None

63
MBO Configuration
Object Structure
Detail Description
Comments
OUTBOUND
Object Structure Definition
Class Functionality
Publish Channel
Processing Rules
Integration Controls
INBOUND
Object Structure Processing
Class Functionality
Enterprise Service
MXOBJECTCFG
MBO Configuration object structure (OS)
This OS allows for inbound synchronization of MBO definition
information.
Use this object structure with caution.
Use only Add, AddChange, or Change action codes when
synchronizing inbound data through this object structure. Do not
use the Replace action unless you completely replace the
MAXOBJECTCFG and MAXATTRIBUTECFG data.
The delete action presents the risk of deleting predefined records in
the database tables associated with MAXOBJECTCFG and
MAXATTRIBUTECFG MBOs.
There is an inbound setting restriction on CHANGED,
EAUDITENABLED, EAUDITFILTER, EAUDITTBNAME,
IMPORTED, STORAGEPARTITION, MAXOBJECTID column,
so the XML value is not set to the MBO.
After synchronizing inbound data with this interface, for your
changes to take effect, use Maximo’s Database Configuration
application and select the Apply Configuration Changes action.
N/A
N/A
None
None
psdi.iface.app.configure.MaxObjcfgProcess –
If the event that MAXOBJECTCFG is creating a view
(MAXOBJECTCFG.VIEW=1), the processing class will skip any
MAXATTRIBUTECFG mbos associated with the referred
MAXOBJECTCFG.
This class also delays the SAVE validation on MAXOBJECTCFG
until all its associated attributes are successfully added into
Maximo
N/A
64
Processing Rules None
Integration Controls None

Domains
Object Structure MXDOMAIN

Detail Description Communication Template object structure (OS)

This OS allows for inbound synchronization of domain

information.

Some fields in the Maximo are associated with select value lists.
These lists of defined values are known as domains (sometimes
referred to as value lists).

This OS synchronizes ALN, Numeric, Numeric Range, Table, and

Crossover domains definitions.
Comments Prerequisite: Update and Delete operations require External
Systems to provide valid DOMAINID values.

OUTBOUND
Object Structure Definition N/A
Class Functionality
Publish Channel N/A
Processing Rules None
Integration Controls None
INBOUND
Object Structure Processing N/A
Class Functionality
Enterprise Service N/A
Processing Rules None
Integration Controls None

65
Communication Template

Object Structure MXCTEMPLATE

Detail Description Communication Template object structure (OS)

This OS allows for bidirectional synchronization of communication

templates that users can leverage to standardize frequently used e-
mail communications (also known as notifications).

A communication template is a definition of a mail message with

subject, message, and recipient information that is processed when
certain nodes become current, or along specified workflow routing
paths between nodes.

This OS synchronizes Application, Change Status, Custom Class,

command Line, and Set Value actions, but not Action Group.
Comments Prerequisite: Update and Delete operations requires External
Systems to provide a valid ACTIONID value.
This object structure does not support the creation of Action
Groups.
OUTBOUND
Object Structure Definition N/A
Class Functionality
Publish Channel MXCTEMPLATEInterface
Processing Rules None
Integration Controls None
INBOUND
Object Structure Processing N/A
Class Functionality
Enterprise Service N/A
Processing Rules None
Integration Controls None

Actions
Object Structure MXACTION

66
Detail Description Action Definition Object Structure (OS)

This OS allows for inbound synchronization of workflow action

definitions that can be used with escalation, service level agreement
(SLA), and workflow processes.

An action is an event that you want the system to trigger when it

encounters records that meet the conditions defined by an
escalation point, service level agreement, or Workflow process.

This OS synchronizes Application, Change Status, Custom Class,

Command Line, and Set Value actions, but not Action Group.
Comments Prerequisite: Update and Delete operations require that External
Systems provide a valid ACTIONID value.

This object structure does not support the creation of Action

Groups.
OUTBOUND
Object Structure Definition N/A
Class Functionality
Publish Channel N/A
Processing Rules None
Integration Controls None
INBOUND
Object Structure Processing N/A
Class Functionality
Enterprise Service N/A
Processing Rules None
Integration Controls None

67
System Properties
Object Structure MXPROP

Detail Description System Properties Object Structure (OS)

This OS allows for inbound synchronization of System Properties

and values.

Comments
OUTBOUND
Object Structure Definition N/A
Class Functionality
Publish Channel N/A
Processing Rules None
Integration Controls None
INBOUND
Object Structure Processing N/A
Class Functionality
Enterprise Service N/A
Processing Rules None
Integration Controls None

68
Integration Modules
Object Structure MXIM

Detail Description Integration Module Object Structure (OS)

This OS allows for inbound synchronization of an Integration

Module definition including properties and LMO relationships.

Comments
OUTBOUND
Object Structure Definition N/A
Class Functionality
Publish Channel N/A
Processing Rules None
Integration Controls None
INBOUND
Object Structure Processing N/A
Class Functionality
Enterprise Service N/A
Processing Rules None
Integration Controls None

69
Logical Management Operations (LMO)
Object Structure MXLMO2

Detail Description Logical Management Operations Object Structure (OS)

This OS allows for inbound synchronization of LMOs including

attributes.

Comments
OUTBOUND
Object Structure Definition N/A
Class Functionality
Publish Channel N/A
Processing Rules None
Integration Controls None
INBOUND
Object Structure Processing N/A
Class Functionality
Enterprise Service N/A
Processing Rules None
Integration Controls None

70
Operational Management Products
Object Structure MXOMP

Detail Description Operational Management Product Object Structure (OS)

This OS allows for inbound synchronization of OMPs, including

relationships to CIs and configurations with IM and LMOs.

Comments
OUTBOUND
Object Structure Definition N/A
Class Functionality
Publish Channel N/A
Processing Rules None
Integration Controls None
INBOUND
Object Structure Processing N/A
Class Functionality
Enterprise Service N/A
Processing Rules None
Integration Controls None

71
Launch in Context
Object Structure MXLAUNCH

Detail Description Launch Entry Object Structure (OS)

This OS allows for inbound synchronization of Launch Entries and

context information.

Comments
OUTBOUND
Object Structure Definition N/A
Class Functionality
Publish Channel N/A
Processing Rules None
Integration Controls None
INBOUND
Object Structure Processing N/A
Class Functionality
Enterprise Service N/A
Processing Rules None
Integration Controls None

72