[Feature] Repair orders

[SchrodingersGat]

Discussed in #7694

I run a repair service. From what I can see, Inventree is not able to create a repair order, and to track parts and a description of repair work done to a customer's unit. Is this a feature that would be likely implemented?

Concept Requirements

• Determine scope of feature
• Required DB models
• Required UI elements
• Require API flows

[adityakrmishra]

@SchrodingersGat @matmair I can pick this up. Since this requires core schema additions, I want to sync on the architecture before cutting a PR.

TL;DR: I'm visualizing this as a hybrid between a SalesOrder (customer-facing) and a BuildOrder (consuming internal stock).
Proposed DB Models (Django)
Integrated into the order app (or a new repair app):
RepairOrder: reference (auto-seq), customer (FK to Company), customer_reference, item_description, symptoms, status (integer choices: Pending, In Progress, Completed, etc.). Inherits from standard Attachment/Notes mixins.
RepairOrderLineItem & RepairOrderAllocation: To map and consume StockItems used during the repair.

API Routing
Standard DRF ModelViewSet CRUD for the models (e.g., /api/order/repair/).
Custom actions like /api/order/repair//issue/ to execute the permanent stock deduction once parts are installed.

UI (Mantine)
New RepairOrderTable index.
Detail view with panels for: Customer Details/Symptoms, Parts Allocation (similar to BO UI), and Markdown Notes for the tech's repair log.

Let me know if this scope aligns with what you had in mind. If this architecture LGTM, I'll start scaffolding the backend models and API as a v1

[SchrodingersGat]

@adityakrmishra that sounds pretty thorough, if you would like to take this on that's great!

Starting Points

• https://docs.inventree.org/en/stable/develop/
• https://docs.inventree.org/en/stable/develop/architecture/
• https://docs.inventree.org/en/stable/develop/devcontainer/
• https://docs.inventree.org/en/stable/develop/react-frontend/

And feel free to reach out with any questions!

Best thing to do would be to start a new PR so that we can provide any direct assistance there 👍

[matmair]

there are a few important things missing here: business context on the function, what kind of actions might be required and the lifecycle of orders in this new concept.
The tech is the easy part that any llm can do

[matmair]

@cameleonnzl @VMT-Solutions @ataylor-rp can you give insights on how you imagine this function / what you intended workflow and possible actions are for handling a order?

[ataylor-rp]

@matmair For my company, we're looking for an easy way to track parts used for a maintenance cycle on our fleet of equipment. I briefly considered creating a new assembly record for each maintenance order and building the BOM as we went through triage and repair, and then issuing a build order after the fact for record keeping, but the shop floor didn't like the number of steps involved. So for us, our ideal case is to be able to open a work order against a specific fixed asset that we're repairing, and allocate parts to a list as we go. I'll put some thought into specific steps and elaborate further later today.

[bountyhub-bot]

🚀 Bounty Alert!

💰 A bounty of $15.00 has been created by matmair on BountyHub for this issue.

🔗 Claim this bounty by submitting a pull request that solves this issue!

You can also increase the amount of the bounty if you think the issue is worth more.

Good luck, and happy coding! 💻

[adityakrmishra]

@matmair @ataylor-rp That makes complete sense. I completely agree that the business lifecycle needs to dictate the architecture.

To keep things moving without stepping on the design process, I have restricted PR #12072 strictly to the baseline backend scaffolding (DB models and API endpoints based on the initial Sales/Build order hybrid concept). The CI is currently green and passing all strict schema checks.

I also have the baseline Mantine UI built locally, but I will hold off on pushing that into a Phase 2 PR until we nail down this exact workflow.

@ataylor-rp, linking the Repair Order directly to a specific "fixed asset" (perhaps a specific serialized StockItem?) rather than just a customer makes a lot of sense for fleet maintenance. Looking forward to seeing your elaborated steps so I can adjust the models and UI to match!

[ataylor-rp]

@matmair @adityakrmishra Apologies for the delay.

We have three types of maintenance tasks we deal with: Regular scheduled maintenance, emergency repairs, and system upgrades. So in general terms we'd like to be able to define task types or categories, similar to the categories used for parts.

Work flow for us would be something like this:

Create a work order, with fields for affected item (We use the unit name, but could be a serial number), expected start date, expected completion date, attachments (work instructions, descriptions of damage, change notices, etc.), repair classification (as mentioned above), and priority (high, medium, low, or something similar). (I don't know if @cameleonnzl or @VMT-Solutions are following this thread, but I imagine they'd like to see fields for Customer and Returned Goods Authorization, as well.)

When the unit comes in, triage the damage and pull parts as needed from inventory, recording them against the work order.

At completion of maintenance, attach the completed maintenance check list and any test results to the work order.

Maintenance manager signs off on work order and it's marked complete, consuming the allocated inventory.

We have some sub-assemblies that we refurbish regularly and track under a separate part number from new units. For those I've created a BOM where all the parts are optional, and the technician can just allocate to a build order what they use as they do the rebuild, but that is a little unwieldy when we get past 10-12parts in a BOM. So the key change we'd be looking for is being able to add line items to a build/work order BOM after the order has been issued.