Values Manage Owns: Dates, Spaces, Audit Columns and Keys in Fiedler Data Import

Most of these rules came from round trips. Fiedler Data Export reads records, and Fiedler Data Import plans the file again. Every row should then plan as unchanged. Where a row planned as an update although nobody changed it, the cause was a value that Manage owns. We checked the behaviour on our test system, on the MAS 9.2 series.

Dates with a time, and three time zones

#

A date with a time passes three time zones on its way into Manage:

The importer reads a date and time from the workbook in the job’s time zone. It hands Manage that exact moment and compares it in the same zone. So 2026-11-02 08:00 in the workbook stays 08:00 in Vienna, and the next plan reads the row as unchanged.

Manage’s own screens show a date in the time zone of the user’s profile. A user without one sees the pod’s time. On our test system that is GMT, so the same value shows as 07:00 there. Nothing is wrong with the record. Set the time zone in your Maximo profile, and Manage shows 08:00 too.

Spaces at the start or end

#

Manage trims every text it is given. A value typed into a Manage screen can never start or end with a space. Data loaded past Manage can, for example by SQL: demo data, a migration or an interface that writes tables directly.

A workbook cell holds the same text without those spaces. So Fiedler Data Import treats spaces at the start or end as no change, and a space inside a value still counts. On our test system, a workbook of 50 locations planned 23 updates before this rule. All 23 came from the description alone. With the rule, all 50 rows plan as unchanged.

Four columns Manage fills itself

#

ENTERBY, ENTERDATE, CHANGEBY and CHANGEDATE say who created and who last changed a record. Manage sets them when it saves, so a workbook value has no meaning there. The importer never compares them and never sends them. The result workbook marks such a column >>ignored<<.

This matters more than it looks. Reading an open work order sets CHANGEBY and CHANGEDATE in memory to the reader and the moment of the read. A workbook exported from work orders then planned 30 updates of 50 on our test system, for these two columns alone. Now it plans 50 unchanged.

Fiedler Data Export leaves the four columns out of a generated layout from the start. A box on the Export page brings them back when you want to see them.

A unique id in the key

#

A row without a key column usually ends as an error: the importer cannot find the record. An autokey is the exception, because Manage generates it. The row inserts a new record and gets its number back.

On some objects the unique id is part of the primary key. ACTIONSCFG is keyed by ACTIONSCFGID alone, and LABTRANS by SITEID, LABORCODE and LABTRANSID. Manage generates the unique id as well, so the importer treats a missing unique id column like a missing autokey: the row is an insert. A filled unique id still never inserts, because it names one record of one system.

That makes the Transfer layout of Fiedler Data Export work on these objects. Transfer leaves the unique id out on purpose, for a load into another system. Before this rule, Transfer workbooks of 33 such objects planned every row as an error. Now each row plans as an insert.

Work order tasks as children

#

Manage shows a work order’s tasks, assignments and actual labor through sets of its own, such as SHOWTASKS, SHOWASSIGNMENT and SHOWACTUALLABOR. These sets carry other names than the objects in them. A task row is also no plain WORKORDER: it is a WOACTIVITY, an object based on WORKORDER.

The importer compares a child’s object with the object behind the set, and it accepts an object based on it. So tasks, assignments and labor import as children of their work order. On our test system, a workbook of actual labor planned 171 errors before; afterwards its 721 rows planned as unchanged.

STATUSDATE on the structure path

#

A status change in Manage needs three values together: the new status, the date of the change and a memo. Manage writes them as one step, with a line in the status history.

On the business object path, the importer makes that step with the date from the workbook’s STATUSDATE column. On the object structure path, Manage changes the status at its own time and ignores STATUSDATE. The plan warns on every such row, so you see it before the run. When the date matters, as in a migration, use the business object path.

Which application the job uses

#

Several applications often share one main object. WORKORDER alone has eight on our test system. The application matters, because it can carry a condition that limits the records it finds.

Graphical Scheduling (PMCHGFSCGA) is one of them. Its condition keeps only work orders with schedule dates, and on our test system it left out 10,002 of 67,580 work orders. An import through it could not find those records and planned them as errors.

So the importer proposes the application in this order:

1. The application named like the object, or IBM’s standard one, such as WOTRACK for WORKORDER.
2. Then an application without a condition.
3. Then the first by name.

You can always choose another one. The command line takes the same application when --app names none.

What comes next

#

These rules keep a round trip quiet: what goes out of Manage comes back as unchanged. Plan first, then run shows the verdict each row gets, and the example library holds 37 workbooks to try them on. The Fiedler Data Import page lists the whole series.

Do you migrate data with values like these? Get in touch.

IBM and Maximo are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide.