Product Master Data in EDGEBIC: Planning Attributes Explained

Product master data in scheduling software is the file that tells the engine what you make, how you count it, what it costs, and how it should be planned. In EDGEBIC by User Solutions, every routing step, every manufacturing order, every quote line, and every inventory movement points back at a product record. Get the product record right and the schedule, the quote, and the replenishment suggestion all inherit that accuracy. Get it wrong and the errors surface three screens away, where nobody thinks to look.

This post is the capability overview: what the product record holds, why each group of fields exists, and when you actually need them. For the field-by-field setup sequence see how to set up products in EDGEBIC, and for the build-policy mechanics see make-to-stock vs make-to-order.

What a product record actually is

A product is the master record for anything the system knows how to make, buy, or consume. That covers three roles at once:

• Finished goods you sell, such as Widget-A.
• Sub-assemblies consumed by other routings, such as Frame-S.
• Raw materials that appear inside routings but never get a routing of their own, such as Steel-Plate-4mm.

Nothing on the form switches between those roles. A product's role follows from how you use it. A product with a Bill of Routing is something you make. A product referenced as a material inside another routing is a component. A product flagged Procured is bought rather than made. Category and the Procured flag are how you keep the catalog organized along raw-material, work-in-process, and finished-good lines.

That design choice matters when you migrate from an ERP that forces an item type. You do not need to reclassify anything. You import the catalog, build routings for the things you make, and the roles resolve themselves.

The identity fields, and which one people read

Two names live on the record and they do different jobs.

The rule that saves the most confusion later: keep Product Id short and stable, because a planner reads it on the Gantt and a kiosk operator reads it on the shop floor. Formal part numbers belong in Product Name. If you rename a product that routings or scheduled jobs already use, the system asks whether to update related references, and answering yes propagates the new name to the routing, the Gantt, and the work center detail views.

Unit of measure carries one piece of scheduling relevance. Each unit definition has a scheduling behavior of hours, pieces, or both, which signals whether resources using that unit should be capacity-planned by time or by throughput. That signal is consumed at the work center level, where the capacity type is set. Keep the two consistent and nobody gets confused about why a paint booth measured in square metres schedules the way it does.

Routing readiness, visible from the catalog

The product list carries a BOR column, and it is the fastest data-quality check in the application. It has exactly three values:

Because the column is a stable categorical value rather than free text, you can sort, filter, and group on it. One click buckets a 400-part catalog into schedulable, not-yet-schedulable, and needs-cleanup. The inline check or circle marker beside the product name carries the same information in a glyph.

The legacy multi-routing condition deserves a word. Current practice is one routing per product, and the whole scheduling and quoting chain assumes it. A product that resolves to several routings makes it ambiguous which one drives the schedule, so every red row is a data-cleanup task rather than a configuration option. Getting your catalog clean here is part of the greenfield setup sequence.

Cost, price, and where they land

Two money fields sit on the product and both feed quoting rather than scheduling:

• Rollup Cost is the per-unit cost used when estimating a quote's cost and margin.
• Sale Price is the revenue side of the same calculation.

New quote simulations use the current values. Existing quotes keep the figures they were created with, because a quote is a historical document and rewriting its numbers retroactively would break the audit trail. That is the right behavior, and it also means a stale rollup cost quietly understates cost on every new quote until someone fixes it. If you quote a product, keep its cost current. See quoting against real capacity for how those numbers turn into a promise date and a margin.

Quantity on hand is deliberately not editable on the product form. Stock changes go through inventory transactions so the audit trail stays intact, and on installations that do not use inventory the field is simply unused.

Lead time: the field that does two jobs

Lead time is stored once, in calendar days, and it behaves differently depending on the product's role.

On a purchased or component item, lead time back-schedules a planned order's release date: release equals due date minus lead time.

On a finished good, lead time is the end-item tail: the window between the last work center operation and the moment the item is genuinely ready to ship. Packing, curing, paint drying, shipping prep. The schedule surfaces it as two columns:

Item Start = end of the last work center operation
Job End    = Item Start + LeadTime calendar days

The tail consumes no machine capacity. It is time, not work. Job View and the scheduler Gantt draw it as a slate band after the job's last operation, the schedule grids show Item Start and Job End as separate columns, and the dashboard judges lateness against the delivery-ready end rather than the bare last operation.

Worked example. Widget-A carries a lead time of 2. A job's last operation on Assembly-1 finishes Thursday at 14:00. Item Start is Thursday 14:00 and Job End is Saturday 14:00. If the due date is Friday, that job is late even though the machines finished a day early, because two days of packing push delivery-readiness past the promise. Scheduled backward instead, the engine would have aimed the last operation at Wednesday so the tail lands on the due date. That behavior is covered in the backward scheduling material and in the platform's own direction rules.

Setting lead time to 0 collapses Item Start and Job End, so shops that do not need a tail never see one.

The planning attribute set

Beyond identity, cost, and lead time, the product record carries the attributes that decide how an item is replenished. These are the inputs to inventory projection and master production scheduling, and EDGEBIC describes them as a connected planning capability rather than a bolt-on:

Two of these repay attention immediately.

Yield inflates the suggested start quantity so that scrap does not become a shortage. If a replenishment calculation lands on 150 good units needed and yield is 0.90, the suggestion becomes the ceiling of 150 divided by 0.90, which is 167 units to start. Enter yield as a fraction, always: 0.92 for 92 percent, 1.0 for no scrap.

Setup Family links the product to a changeover group so the sequence-dependent setup matrix can be maintained at family level instead of product-by-product. Ten products in two families need a 2-by-2 matrix instead of a 10-by-10 one. A product left unassigned acts as its own family, which means only product-level matrix entries apply to it and everything else falls back to the flat step setup time. See what a setup family is for the concept and the paint-shop math.

When you need which attributes

You do not need the full set on day one. A useful order:

1. Always: Product Id, unit of measure, category. Enough to build routings and orders.
2. Before you quote: rollup cost and sale price on anything a customer sees.
3. Before you promise dates on finished goods: lead time, if there is real post-production time.
4. When you carry stock: build method, stocked flag, reorder method, and levels.
5. When changeovers hurt: setup family, then the matrix.

Everything past step 1 is additive. Nothing breaks because it is unset, and the planning layer guide covers how the stock and forecast attributes feed the projection and MPS grids once you are ready for them.

What the product record does not do

Saving a product never reschedules anything. Dropdowns update immediately, the lead-time tail redraws on Job View at once, and quote figures change for new simulations. Machine bookings move only on the next scheduling run. That separation is deliberate: master data edits should not silently rearrange the shop floor.

The counterpart is deletion, which does cascade. Deleting a product removes its routing and flushes the production schedule rows tied to it, with no undo. Old products left in place cost nothing, so retire rather than delete.

For the setup sequence, continue to how to set up products in EDGEBIC. For the failure modes and their symptoms, see product setup mistakes. And for the full platform picture, the complete EDGEBIC guide and the product hub tie the modules together.