What Is Sales Order Reference Grouping in an Import?

Sales order reference grouping is the import behavior that gathers every file row sharing one order reference under a single sales order and auto-numbers their jobs from that reference plus a line number. It is how a multi-line customer purchase order arrives in the plant as one commercial document with several jobs beneath it, rather than as a handful of unrelated work orders that happen to share a due date. In EDGEBIC by User Solutions the reference column is optional, and its presence or absence per row decides which of the two shapes you get.

How it works

A demand import loads jobs, and each file row becomes work the plant may perform. Three columns are mandatory: the product being ordered, the quantity, and the job date. Everything else is optional, and one of those optional columns is the order reference.

The grouping is decided per row, not per file, so a single import can carry three genuine purchase orders and a dozen loose internal builds without any special handling. That is the right default because real demand files are usually mixed.

Around those columns sit the optional ones that make an imported order useful downstream: the customer name, a due date, an order date, a priority, a unit price and free-text notes. Two mask options are worth knowing about. Products and customers named in the file that do not yet exist are created on the fly by default, which is what allows a portal export to be imported without preparing master data first. And a pair of options controls how the job date and due date relate when the file carries only one of them, so a file that gives you promised dates and nothing else still produces sensible jobs.

Priority deserves a note because it is easy to misread. Priority is a plain positive number where lower comes first, so a job at priority 1 is ahead of a job at priority 5. A file that leaves the column out simply produces jobs at whatever default applies.

The relationship the reference creates is not decoration. It is what lets someone later ask what happened to a customer's purchase order and get a single answer covering all its lines, rather than reconstructing the set from dates and part numbers. The order and line vocabulary, including the states an order moves through, is defined in what is a sales order line.

A concrete example

Acme Industries sends purchase order ACME-PO-4471 covering three parts. The file the planner receives has three rows, each with the product, the quantity, the date, and the same reference value in the reference column.

After the run, the plant has one sales order for ACME-PO-4471 and three jobs beneath it, numbered from the reference with a line suffix: line one, line two, line three. Anyone looking at any one of those jobs can see the order it belongs to, and anyone looking at the order sees all three jobs.

Now take the same three rows with the reference column left blank. The import creates three standalone jobs with no parent order. Nothing is broken and the work is identical, but the commercial grouping is gone, and reconciling against the customer's paperwork later becomes a manual exercise.

The scale version of this shows why the import path exists at all. At eight in the morning the planner imports forty sales orders for Acme. At one minute past eight, the scheduling tab shows forty new jobs and the timeline shows none of them, because imports never schedule. At five past eight the planner runs the scheduler in new-jobs-only mode: the forty jobs are planned around everything already committed on the floor, and only then do they appear on the plan. Forty orders keyed by hand would have taken the morning; this took five minutes, and the review step in the middle is where a planner catches the row that arrived with the wrong quantity.

How EDGEBIC uses it

Demand loads run through the same mask mechanism as every other data type: pick the entity type, map your file's columns onto the target fields once, save the recipe, and every later run is two clicks. The eight importable types and their mandatory columns are listed in what is an import entity type.

Three habits make a demand routine dependable:

• Carry the customer's real reference, or nothing. A genuine purchase order number is worth preserving; an invented placeholder creates orders that correspond to no document.
• Check what was auto-created after the first run of a new file. Products and customers are created on the fly by default, and a misspelled part number creates a new product rather than failing, so the first run of a new feed deserves a look at the product grid.
• Read the results, then schedule. Row outcomes are created, updated, reused or failed, as described in what is an import row status, and the per-run log names the row behind any failure. Scheduling is a separate deliberate step afterwards.

One boundary is worth stating plainly. An imported order is created, not planned. Its dates on the file are demand information; the dates the plant will actually work to come from a scheduling run against real capacity. That is the same rule that applies to an order created by hand or converted from a quote, described in what is a manufacturing order.

The takeaway

Sales order reference grouping is a one-column decision that preserves a real commercial relationship through a bulk load: fill the reference to keep a multi-line purchase order together with numbered jobs, leave it blank for genuinely unrelated demand. Combined with the mandatory product, quantity and date columns, it turns a customer's spreadsheet into schedulable work in minutes without losing the paper trail. To see demand imports and the jobs they produce in a working plan, explore EDGEBIC, and if you are arriving from the older Resource Manager lineage, the move from RMDB to EDGEBIC maps the equivalents. For neighboring terms, read what is an upsert in data import and what is an import run log.