Hi Stephen — thanks for sharing the issue you’re experiencing with repair locations in IBM Maximo 7.6.1.3. I spent a little time reviewing your situation and I’d like to share a structured response (with some caveats) based on my experience in asset/equipment-/maintenance systems, which may help your decision-making.
What is clear
From your post:
-
The locations in question were originally set up in the “OPERATING” type instead of “REPAIR”, and the “Is a Repair Facility?” checkbox was not checked.
-
Because of that setup, users often forget to check “Charge to Store” on new repair work orders, leading to inventory cost misallocations.
-
You’ve identified two possible remediation paths:
-
Remove the problematic locations from the Location System hierarchy, relabel them as “REPAIR” type via the UI.
-
Update the database via SQL to change the type to REPAIR and mark the “Is a Repair Facility?” flag — but keep them in the Location System hierarchy (which you believe violates the “only OPERATING types in hierarchy” rule).
Key considerations & risks
-
Hierarchy Integrity: If the system logic or your reporting logic assumes that only “OPERATING” typed locations are allowed under the Location System hierarchy, option 2 (changing type to REPAIR but leaving them in the hierarchy) may break downstream processes, reports, integrations or system-validations.
-
In-flight transactions: As the reply from Craig Kokay notes, if there are open work orders, inventory transactions or other linked data pointing to those locations, changing the type/hierarchy may have unintended impacts.
-
Audit/traceability: Direct SQL updates bypass UI validations, audit trails, business logic and may make it harder to track who/when changed what.
-
Change-management & testing: Because this is a production environment, any change must be carefully tested in a sandbox or test instance, with full rollback plan in place.
-
Data consistency: Inventory cost corrections and legacy work orders that missed “Charge to Store” need to be addressed, which means you may have both structural (location setup) and transactional (work order, inventory) corrections to make.
Recommended approach
Here’s a recommended phased path based on best practices for asset/maintenance systems:
Phase 1 – Analysis
-
Query all locations currently typed “OPERATING” but marked (manually or logically) as being used for repair activities.
-
Identify all open/closed work orders, inventory transactions, cost allocations tied to those locations.
-
Map out all reports/integrations (financial, inventory, performance KPIs) that reference the Location System hierarchy or use “repair facility” logic.
Phase 2 – Test change in non-production
-
In a copy/test instance of Maximo, pick a subset of the “problem” locations and perform both options:
-
Option A: Remove from hierarchy, change type to REPAIR.
-
Option B: Change type to REPAIR + enable “Is a Repair Facility?” but leave in hierarchy (maybe temporarily).
-
Run all key scenarios: creating new repair work orders, inventory issue/receipts, reports, cost allocations.
-
Evaluate for breakage or unexpected behavior.
Phase 3 – Choose the structural change and execute
-
Based on the test results, determine which approach is safe and sustainable. My intuitive expectation: Option A (removing from the hierarchy + proper type) is the “cleaner” solution, though it may involve more upfront work (updating hierarchy membership, reports, etc.).
-
Develop a script or batch process to effect the change for all affected locations, including validations before and after.
Phase 4 – Address transactional cleanup
-
For those repair-work orders where “Charge to Store” was missed: extract list of closed or open work orders, filter by location(s), filter by cost allocations, then decide whether you’ll reopen and adjust or make journal entries/adjustment transactions.
-
Document and get finance/asset/accounting approval for cost corrections and an audit trail.
Phase 5 – Prevent recurrence
-
Update your location creation/maintenance governance: ensure new repair facilities are created with correct type “REPAIR”, “Is a Repair Facility?” enabled, and not placed in the Location System hierarchy (unless your business rules allow).
-
Add validation logic or automation (if possible) so when a location gets flagged as “Is a Repair Facility?” that automatically restricts placement in certain hierarchies or creates a warning.
-
Train users on “Charge to Store” importance when creating repair work orders, and update your SOPs/maintenance governance accordingly.
🔧 My answer to your specific question
Between your two methods, I’d lean strongly toward option 1 (remove from hierarchy and convert the type via UI) provided the testing confirms that doing this doesn’t break your key reports or integrations. The reasoning:
-
It aligns with the “system rule” you referenced that only OPERATING types should appear in the Location System hierarchy.
-
It keeps your location taxonomy aligned with design intent and helps ensure future clarity (repair vs operating).
-
It avoids direct SQL edits that bypass UI logic and risk data integrity.
However — if your testing shows significant broken dependency (e.g., a large number of key reports that assume a certain hierarchy and you cannot remediate easily) then option 2 might be a practical interim fix — but with a plan to transition to the “cleaner” model later.