How to Link a Sales Order to a Job in EDGEBIC

Linking a sales order to a job in EDGEBIC is about seeing the two together: the customer commitment and the manufacturing work that satisfies it. In EDGEBIC by User Solutions you do this on the schedule orders view by switching on sales order group mode, which regroups the job grid into a tree of orders with their jobs nested beneath. Expand an order and every job it drives is right there, with schedule and hours detail. This guide covers reading that grouped view and spotting jobs that no order accounts for.

For the header entry that creates the order in the first place, see how to enter a sales order. For the broader order workflow, read how to enter and manage sales orders, and for the demand mechanism behind the link, how sales orders drive demand. All of this is documented behavior of EDGEBIC; the full task set is in the how-to hub.

Before You Start

• You need at least one sales order with jobs created for its product lines.
• Open the schedule orders view (the manufacturing order grid).
• Know that the link itself is a property of the job: a manufacturing order either references a sales order or it does not.

Step 1: Open the Schedule Orders View

Open the schedule orders view, the grid that lists your manufacturing orders. In its default state it is a flat list of jobs with no grouping. That flat list is fine for scheduling but poor for answering "what is happening with this customer's order," which is what the grouped view solves.

Step 2: Switch On Sales Order Group View Mode

Click the sales order group view mode toggle on the toolbar. The grid regroups into a tree. Each sales order becomes a parent row, and the jobs tied to it nest underneath. Loading this view deep-reads each order's jobs along with their schedules and daily breakdowns, so the hours columns are populated and current.

Step 3: Expand an Order to Read Its Jobs

Click the expander on a sales order row. Its child jobs appear, and each one shows:

Read across a child row and you have the full state of that piece of the order, from planned to actual, without leaving the tree. A worked example: an order for a machined bracket might show two child jobs, one at status scheduled with a start of the 12th, an end of the 14th, and 16 estimated hours against 9 logged, and a second still unscheduled with no dates and a dash in the actual hours column. From that single expanded row you can tell the customer the first job is running and roughly two-thirds through its planned hours, while the second has not started. That is the whole point of the view: the commitment and the work sit together.

Why the Grouped View Matters

The flat job list is organized for the scheduler, which cares about jobs and work centers, not customers. When a customer calls about an order, the flat list forces you to know every job number for that order and check each one. The grouped view inverts that: you find the order once and read everything beneath it. Because the load deep-reads each order's schedules and daily hour breakdowns, the estimated and actual hours are real aggregates, not placeholders, so the answer you give is grounded in logged shop-floor data rather than a plan on paper. For the demand side that connects an order's lines to these jobs, see how sales orders drive demand.

Step 4: Check the Unassigned Group

Scroll to the bottom of the tree for the Unassigned group. It collects every job with no sales order link. This is where you find work that no customer order explains. Two populations live here by design:

• Stock and plan builds. Jobs created from replenishment suggestions or from firmed MPS buckets carry no order link, because they exist to satisfy stock or a build plan rather than a named line. They belong here.
• Orphan customer jobs. A job that should belong to an order but lost or never had the link. These are the ones worth investigating.

For hunting down the second kind, see how to find orphan jobs with no demand.

What Changes When You Switch the View

Nothing in the data changes. This is a display mode, not an edit. Switching to group mode reorganizes what you see; it does not alter any job's link, schedule, or hours. You can toggle back to the flat list at any time and lose nothing.

How to Check It Worked

Confirm the tree shows sales order parent rows with expandable children, and that expanding a known order reveals the jobs you expect for it. If a job you believe belongs to an order is sitting in the Unassigned group instead, its link is missing, and that is the finding, not a display glitch.

Common Mistakes

• Reading a dash in actual hours as zero. The actual hours column shows a dash, not zero, until a job has at least one schedule with both an actual start and an actual end. A dash means no logged work, which is different from zero hours of a started job.
• Treating Unassigned as an error group. Replenishment and MPS builds live there legitimately. Only genuine customer jobs missing their link are a problem.
• Expecting the view to create links. Group mode displays existing links; it does not make them. The link is set when the job is created for the order.
• Forgetting the deep read is a snapshot. The grouped view reads schedules and hours at load time. If work is logged after you open it, refresh to see the new actual hours.

What Comes Next

The grouped view is where you notice a job that should belong to an order but is sitting under Unassigned instead. Chasing those down is its own task: read how to find orphan jobs with no demand. For the order lifecycle that precedes all of this, revisit how to enter and manage sales orders, and browse the how-to hub for related tasks.