How to Retire a Tool Without Breaking Routings in EDGEBIC
User Solutions TeamTo retire a tool in EDGEBIC by User Solutions, clear the requirement from every routing step that still names it, then untick Active on the tool and save. Deleting a tool that steps still require is blocked with a message counting those steps. Deactivating in the wrong order does not error, and that is worse: the steps keep the requirement and the jobs fail on the next run.
Getting the order right turns a retirement into a bookkeeping change with no schedule effect, which is what it should be.
Before You Start
| Prerequisite | Why |
|---|---|
| You know whether the tool is going for good or is temporarily away | A temporary absence is downtime or a quantity of zero, not a retirement |
| You know which routing steps require it | Those steps decide whether the retirement is quiet or disruptive |
| You have a replacement in mind, if the operations continue | Steps need somewhere to point |
Step 1: Confirm This Is a Retirement
Three situations look similar and have different answers.
| Situation | Correct action |
|---|---|
| Out for calibration or repair, coming back | Record a downtime range |
| All units loaned out, coming back | Set QUANTITY to 0, restore it later |
| Out of service for good | Retire it: clear the steps, then untick Active |
Only the third is this post. The other two are covered in how to record tool downtime.
Step 2: Try the Delete and Read the Count
If you want a quick census of which steps still reference the tool, attempt the delete. It is refused, and the refusal counts the steps that require the tool and tells you to remove the requirement from them or to deactivate the tool instead.
That count is the size of the cleanup job. Nothing is changed by the attempt.
Step 3: Re-Point or Clear Every Step
For each routing step that requires the tool, open it in the BOR grid's Basic Information section or the BOR Designer properties panel and change the requirement:
- To a replacement tool, if the operation still needs one.
- To
(none), if the operation genuinely no longer mounts any tool.
Do this before touching the tool record. This is the whole discipline of the task.
Step 4: Reschedule and Confirm
Run a reschedule and check that the affected jobs still place. If you re-pointed to a replacement, their dates may move, which is correct: they are now booking a different pool with a different quantity and different absences.
Step 5: Deactivate
Select the tool on the Daily Hours tab, Tools inner tab, untick Active, and click 💾 Save Tool. The tool shows in the list flagged as inactive and disappears from the required-tool picker on routing steps.
Because no step names it any more, this changes nothing about any plan.
Why Deactivate Rather Than Delete
Deactivation keeps the record and its downtime history while dropping the tool out of every future scheduling run. That history is what explains old plans: six months from now, a question about why a job slid in July is answerable if the calibration range is still on file, and unanswerable if the record was deleted.
The delete guard exists for the same reason a skill delete is guarded. A step whose tool quietly vanished would schedule unconstrained, and unconstrained is not the same as unconstrained-on-purpose. A refused delete is visible; silent degradation is not.
What Changes When You Deactivate
| Surface | Effect |
|---|---|
| The Tools list | The tool remains, flagged as inactive |
| The required-tool picker | The tool disappears. Active tools only |
| Steps that still name it | Keep the requirement, and fail loudly on the next run |
| The scheduling model | The tool contributes zero capacity from the next run |
| Downtime ranges | Preserved on the record |
The third row is the one to internalize. Deactivation is a scheduling-affecting action, not an archival one. Check the step count before you do it.
How to Check It Worked
The tool shows as inactive in the list. It is gone from the required-tool picker. A reschedule places every job normally with no tooling failure in the run's messages. If a job does fail naming the retired tool, one step was missed: find it, clear or re-point it, and reschedule.
Common Mistakes
- Deactivating first. The steps keep the requirement and fail. Clear them first.
- Treating a temporary absence as a retirement. Use downtime or a quantity of zero for anything with a return date.
- Clearing steps to
(none)when the operation still needs a tool. That silences the message and removes a real constraint from the plan. Point at the replacement instead. - Forcing a delete by clearing steps you did not intend to change. Deactivation is almost always the right end state; a delete buys nothing and loses the history.
- Forgetting to reschedule. Nothing changes until the next run.
Next Steps
If a replacement is coming, create it with the same care as the original and set its quantity from units you own. To point steps at it, see how to require a tool on a routing step. The equivalent housekeeping on the machine side is how to deactivate a work center.
Every task in this library is indexed on the EDGEBIC how-to hub. To see the delete guard and the deactivation path on real data, book a walkthrough of EDGEBIC.
Clear the requirement from every routing step that still names it, then untick Active on the tool and save. In EDGEBIC by User Solutions this order matters: deactivating first leaves the steps still asking for a tool that no longer supplies capacity, so those jobs fail loudly on the next run. Clearing the steps first means the deactivation changes nothing about the plan, which is what a retirement should do.
Because routing steps still reference it. The delete is refused with a message counting the steps that require the tool and telling you to remove the requirement from those steps or deactivate instead. Allowing the delete would leave steps pointing at nothing, and a step whose tool quietly vanished would schedule unconstrained, which is silent degradation rather than a visible problem.
No, and this is the trap. Deactivation removes the tool from the scheduling model and from the routing picker, but every step that already names it keeps the requirement. From the next run those steps fail loudly, naming a tool that is now inactive. Deactivate only after you have re-pointed or cleared the steps.
Both empty the pool and both produce the same loud refusal on any step still requiring the tool, so the schedule behaves the same. The difference is intent and reversibility. A quantity of zero says the units are temporarily unavailable and will be back, and the tool stays in the picker for new steps. Deactivating says the tool is out of service for good, and it drops from the picker while keeping its record and its downtime history.
Expert Q&A: Deep Dive
Q: We deactivated a tool and now a dozen jobs will not schedule. What is the fastest recovery?
A: Reactivate it first, then reschedule, so the dozen jobs come back and you are not planning under pressure. Deactivation is reversible and there is no cost to putting it back for a day. Then do the cleanup in the right order. Find the routing steps that require the tool, change each one's required tool to the replacement, or to the entry labeled none if the operation genuinely no longer needs a tool, and reschedule again to confirm nothing broke. Only once no step names it should you untick Active. At that point the deactivation is a bookkeeping action with no schedule effect at all, which is exactly what you wanted the first time.
Q: We are replacing an old fixture with a new one on the same operations. Do we need to retire the old record at all?
A: Eventually, and it is worth doing rather than leaving both active. Create the new tool with its own name, code, and quantity. Then change each affected step's required tool from the old record to the new one and reschedule; the plan now books the new fixture's pool and the old one's is untouched. With no step naming it, the old record is safe to deactivate. Deactivate rather than delete, because the record and its downtime history explain past plans, and a delete that succeeds only because nothing references it any more still throws away that context. It also keeps the option open if the old fixture comes back as a spare.
Frequently Asked Questions
Ready to Transform Your Production Scheduling?
User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.
User Solutions Team
Manufacturing Software Experts
User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.
Share this article
Related Articles
How to Create a Watched-File Integration in EDGEBIC
Create a watched-file integration in EDGEBIC: point it at the file your ERP drops, pick the target entity and import mask, set the debounce, and let a new file trigger the run.
How to Rehearse an Integration With the EDGEBIC Simulator
Use the built-in Simulator to provision demo data, watch real integration runs happen, and prove the mechanism before you point anything at a live ERP. Includes the tear-down rule.
How to Run an Integration Now and Pause All Schedules in EDGEBIC
Force one integration to run with Run Now, cancel a run in progress, disable a single definition, or tick Pause all schedules to stop every automatic sync for the session.