Epicor Kinetic: Job Will Not Release in Job Entry
Epicor Job Entry cannot release job not engineered
Also searched as
- Epicor job will not release
- Epicor Kinetic job engineered checkbox greyed out
- Epicor job released but not showing in MES or Job Tracker
- Epicor unengineered job cannot be released
Short answer
A job in Epicor Kinetic will not release when it is not Engineered, when a material or operation fails validation, or when the part revision on the job is not approved. Open Job Entry, confirm the Engineered flag first, fix any part, revision or method errors shown in the exception panel, then tick Released.
Applies to: Epicor Kinetic 2021.x to current, Epicor ERP 10.x (same Job Entry logic); Make-to-Order and Make-to-Stock jobs
How to get a job released
- 1Open Production Management > Job Management > Job Entry (Kinetic menu path may be under Job Management > General Operations) and load the job number.
- 2On the Job tab, check the status flags in order: Engineered, then Firm, then Released. Epicor expects Engineered to be on before a job can be released.
- 3If Engineered will not stay on, open the Assemblies, Materials and Operations tabs and look for rows with a validation error: missing part, missing resource group, or an operation with no operation master.
- 4Check the part revision on the job head. If the revision is not Approved in Part Maintenance > Revision, the job cannot be engineered from it. Approve the revision or pick the approved one.
- 5If the job came from a quote or sales order, confirm the method of manufacturing is not still flagged for engineering review, and that any required Engineering Workbench approval has been completed.
- 6Tick Released and save. If a dialog appears about unapproved materials or a locked part, resolve that item and save again.
- 7Open Job Tracker or Job Status and confirm Job Released shows true and the job now appears for scheduling and in MES.
- 8If it still fails, check the Tracker for a BPM message. A site Method Directive on JobEntry.Update can block release with its own text.
What Engineered, Firm and Released actually mean
Job Entry carries three separate flags on the job head, stored in Erp.JobHead as JobEngineered, JobFirm and JobReleased. They are meant to be a progression. Engineered says the method is complete and trusted. Firm says the job is a real commitment rather than a planned suggestion from MRP. Released says the shop floor is allowed to issue materials and report labor against it.
A job created by MRP arrives as an unfirm, unreleased suggestion that Epicor calls an unfirm job. A planner firms it, an engineer reviews and engineers it, and then it is released. In shops that skip engineering, the job is often engineered automatically at creation from the part method, but that depends on the part setting and on whether the part revision is approved.
When someone says the job will not release, the error is almost never about the release itself. It is a failed prerequisite that the release step re-validates: materials, operations, revision approval, or a custom rule.
The usual causes, ranked by how often they bite
First, the part revision is unapproved. Epicor's method of manufacturing lives on a revision of the part. If the revision on the job head was copied from a revision that has since been unapproved, or never approved, the job inherits a method it is not allowed to run. Approve it in Part Maintenance or Engineering Workbench, or reassign the job to the approved revision.
Second, an operation or material row is broken. Typical cases are an operation that references a resource group which was disabled, a material line whose part was marked inactive, or a subcontract operation with no vendor. The Operations and Materials grids highlight the offending row, and the exception message names the sequence.
Third, the job is a child of a parent that is itself not engineered. In multi-level jobs, a sub-assembly cannot be released if the parent assembly structure is still being edited. Work top down.
Fourth, a Method Directive in Business Process Management is blocking the update. That produces a message that does not look like standard Epicor wording and that is the clue.
Checking the state in the database
When you need to confirm what a bulk set of jobs looks like, query the job head and the child tables read-only. Run these against a reporting copy or a read-only login, never against production with a writing account.
The first query lists jobs that are firm but not engineered, which is the typical stuck population after a large MRP run. The second looks for materials pointing at inactive parts.
Do not fix state by updating JobHead directly. The flags interact with scheduling, MRP pegging and costing. Use Job Entry or the JobEntry business object so BPM, audit and scheduling run.
SELECT TOP 100 Company, JobNum, PartNum, RevisionNum, JobEngineered, JobFirm, JobReleased FROM Erp.JobHead WHERE JobFirm = 1 AND JobEngineered = 0 AND JobClosed = 0 ORDER BY JobNum;
SELECT m.JobNum, m.AssemblySeq, m.MtlSeq, m.PartNum FROM Erp.JobMtl m JOIN Erp.Part p ON p.Company = m.Company AND p.PartNum = m.PartNum WHERE p.InActive = 1 AND m.IssuedComplete = 0;
Releasing many jobs without clicking each one
For bulk work use the Job Release function in Production Management rather than opening each job. It lets a planner select a range of firm jobs and release them together, and it applies the same validation per job, so failures come back as a list rather than a stop at the first one.
If you drive this from code, call the JobEntry service through the REST v2 API, set JobReleased on the JobHead row, and submit through Update. Because it goes through the business object, Method Directives and security fire exactly as they do for a user. Expect the same validation errors as the UI and handle them per job.
Common pitfalls
- !Editing Erp.JobHead flags directly in SQL. It skips BPM, scheduling and the pegging updates, and leaves MRP out of sync with the job.
- !Approving a revision for one job and forgetting the next revision created from an engineering change, so the next job fails the same way.
- !Releasing a parent job before its sub-assembly jobs are engineered, which produces confusing material availability and scheduling output.
- !Assuming the error is a bug when a site Method Directive is blocking JobEntry updates. Check Business Process Management first.
- !Unfirming a job to make an error go away and losing the MRP link, so the next MRP run proposes a duplicate.
How an ERP-grounded AI assistant handles this
A grounded assistant such as ERPray, running read-only against Epicor, can list the firm-but-unengineered jobs, check each for unapproved revisions or inactive parts, and tell a planner which row is blocking which job and why, showing the query it ran. It does not change flags itself. Any release is done by a person in Job Entry, or proposed as an approved write-back through the business object.
Frequently asked questions
Why is the Engineered checkbox greyed out in Epicor Job Entry?
Usually the job is already released, closed or complete, which locks the flag, or the user lacks the security to change engineering status. Unrelease the job if policy allows, or ask a security administrator to grant the right. Check Job Tracker to see which status flag has locked the field before changing anything.
Can I release an Epicor job without engineering it?
Some shops auto-engineer jobs at creation from the part method, so no manual step exists. If your jobs are created unengineered, Epicor expects engineering first. Do not bypass it with SQL, because release checks the method that engineering validates, and bypassing creates costing and scheduling problems later.
What is the difference between firm and released in Epicor?
Firm means the job is a committed job and no longer an MRP suggestion that the next regeneration could replace. Released means the shop floor may issue materials and report labor. A job can be firm without being released, which is the normal holding state before a start date.
Why does a released job not show up in MES?
The job must be released, the operation must be scheduled to a resource group the MES user can see, and the operation must not be complete. Check the MES user's resource group or work center assignment and the operation status. A released job with no scheduled start can also be missing from default views.
Related
Epicor MRP Runs but Generates No Suggestions
When Epicor's MRP process completes without a job or purchase suggestion for a part you expect one for, the cause is almost always the part's own configuration (Part Class Type, Make Direct, Non-MRP flag, planning Time Fence) or the demand not being linked in a way MRP recognizes, not a defect in the MRP engine. Work through the part's Planning tab, its safety stock and lead time setup, and the demand source (sales order line status, job material requirement) before assuming the run itself failed.
Error fixFixing Epicor BusinessObjectException: BPM Directive Errors
A BusinessObjectException that says "A Business Process Management (BPM) directive has raised the following error" means a directive on that business object stopped the transaction, either deliberately via a Raise Exception widget or accidentally via an unhandled .NET error in Custom Code. Expand the InnerException on the error dialog to see the real message and the directive name, then open BPM Designer for that object and method to find the widget that fired.
How-toHow to close job costing and the accounting period in Epicor
Before closing an accounting period in Epicor, run Capture Costs (or confirm background costing is current) to post all labor, material, subcontract, and burden to jobs, review the WIP report for jobs that should be closed or investigated, close completed jobs so their costs relieve WIP, and only then close the GL period, since GL close blocks further transaction posting into it.
How-toHow to Create a BPM Method Directive in Epicor Kinetic
In Epicor Kinetic, open Business Process Management > Method Directive Maintenance (the BPM Workbench), pick the business object and method, choose Pre-Processing, Base Processing or Post-Processing, then add a condition and actions such as Show Message or Set Field. Enable it and test in a pilot company before production.
How-toFixing a Slow Epicor BAQ (Business Activity Query)
A slow BAQ in Epicor is usually caused by unindexed join columns, a subquery or calculated field forcing a table scan, or the BAQ pulling far more rows than the dashboard actually displays before filtering client-side. Fix it by reading the SQL Server execution plan Epicor generates, moving filters into the BAQ criteria instead of the dashboard filter panel, and replacing subqueries with joins where possible.
Error fixFixing Epicor REST v2 API 401 Unauthorized Errors
A 401 Unauthorized calling Epicor's REST v2 (api/v2/odata) endpoint almost always comes down to one of three things: a missing or wrong x-api-key header, valid credentials but an API key scoped to a different company than the one in the URL, or REST services simply not enabled for that endpoint. Confirm the API key exists and is active in Application Studio (or the classic REST API help page), matches the company segment in the URL, and that the account used for Basic auth or OAuth has the right security group.
AI for ERPAI for Epicor Kinetic, Beyond What Prism Covers
Add AI to Epicor Kinetic beyond Prism: private LLM over BAQs, BPM data, and REST v2, on-prem or private cloud, with honest guidance on when Prism already covers you.
AI for ERPPrivate AI for Epicor Kinetic Cloud, Outside the Multi-Tenant Boundary
Ground a private LLM on Epicor Kinetic Cloud via BAQs, REST v2, and Data Fabric so sensitive manufacturing data never enters a multi-tenant AI feature.
Stuck on Epicor Kinetic?
Talk to engineers who work inside Epicor Kinetic every week, and who build private AI that answers these questions from your own ERP data.