EDGEBIC Manufacturing Orders Explained: The Job the Scheduler Plans

EDGEBIC by User Solutions treats a manufacturing order, a job, as the unit its scheduler plans: a product, a quantity, and a due date, plus the priority and target dates that shape its timing, which the engine turns into scheduled operations on work centers. Everything the scheduling system does ultimately serves the manufacturing order. It is where a production requirement becomes a concrete job, and it is the object whose start and finish dates the whole plant cares about.

A job's schedule is only as good as the routing behind its product and the capacity of the work centers it runs on, so the manufacturing order sits at the intersection of the bill of routing and the work centers. This overview covers what the order carries, which fields drive the plan, and how it moves through its life without losing its history.

Product, Quantity, Due Date

At its core a manufacturing order is three things: what to make, how many, and by when. The product selects the routing, the sequence of operations the scheduler will lay down. The quantity scales the run time of each operation, because making two hundred takes longer than making twenty. The due date is the target the scheduler aims to hit.

From those three, the engine does its work: it reads the product's routing, scales each operation by the quantity, and schedules the operations onto work centers in dependency order, respecting finite capacity. The order goes in as an intention and comes out as a plan with a real start and a real finish.

The Fields That Move the Plan

Not every field on an order changes the schedule, and knowing which do keeps configuration honest. The load-bearing inputs are the product, the quantity, the due date, and the priority. Priority is the tie-breaker: when two jobs want the same capacity, it decides who gets it first, which is how you tell the scheduler which order matters more. For the strategy behind that, see job priority and sequencing strategy.

Two optional inputs give you more control over timing. Target start or end dates let you anchor a job rather than let it float, which is the basis of backward scheduling from a due date. And a per-order utilization setting controls how hard the scheduler loads capacity for that job. The rest of the order's fields describe it; these are the ones that shape the plan.

A Status That Reflects Reality

A manufacturing order moves through a lifecycle, and the important design point is that the status is derived from facts rather than flipped by hand. A job is created when you enter it. It becomes scheduled once the engine has assigned its operations to work centers and time. It becomes in progress once actuals are logged against it. And it becomes complete only when every operation step has an actual end date.

That last rule matters: marking one early step done does not flip the whole job to complete, and the finish date stays open until the last operation truly ends. Because status is read from actual dates and logged work, it always tells the truth about where the job is, which is why the reports can trust it. The actuals pipeline is what supplies those facts.

Demand Versus Production

A manufacturing order is not the same thing as a sales order, and keeping them distinct is deliberate. A sales order is demand: what a customer wants and when. A manufacturing order is the production job that satisfies demand: the thing the scheduler plans onto machines.

In the simplest flow, a sales order for two hundred units by the twenty-eighth is met by a manufacturing order for that product and quantity, which is what actually gets scheduled. You manage commitments on the sales side and production on the manufacturing side, and because they are separate objects you can always see both the promise and the job that keeps it, and notice when they diverge. For the demand side, see how sales orders drive demand.

Surviving a Reschedule

The payoff of treating a job as a first-class object with a real status is what happens when you reschedule. A job that is already partly done does not get rewritten. The scheduler treats operations with actual dates as historical fact and leaves them where they happened, then replans only the remaining operations forward from where the job genuinely is.

A job that finished three of seven steps keeps those three untouched and gets a fresh, realistic plan for the last four. This is why logging actuals is not paperwork: it is what lets a manufacturing order survive rescheduling honestly instead of promising dates that ignore the work already on the floor. For the guardrails, see how to reschedule safely.

Where It Fits

The manufacturing order is the hub the rest of the system turns around: routings and work centers feed it, the scheduler plans it, the kiosk logs against it, and the reports measure it. To run one through the engine, how to run the scheduler is the walkthrough, and for the whole system the order lives inside, the complete EDGEBIC guide is the map.

The Point of a First-Class Job

A schedule is only meaningful if the thing it schedules is a durable object with a real state. Making the manufacturing order that object, driven by a few honest fields and a status read from facts, is what lets EDGEBIC plan it, track it, reschedule it around reality, and report on it, all while keeping its history intact. The three lifecycles that hand off to each other, a quote's, a sales order's, and a job's, are set out in EDGEBIC status lifecycles explained. The job is the noun the whole verb of scheduling acts on.

Want to see your own jobs planned end to end? Bring an export to a demo and we will schedule a batch of them.