From bill of materials to product cost, with nothing in between

It differs in where the foundations sit. Dimensional posting starts at the first line, so profitability by order, plant, product and customer leaves the same general ledger that produces the trial balance — rather than a bolt-on field and a spreadsheet beside it. Rules are versioned, so an order still carries the BOM version it was opened under a year later. Documents have state machines with permitted transitions, and the same workflow kernel handles approval against limits in purchasing and on the floor. A real WMS lives in the core — bin locations, directed picking, waves — so semi-finished goods do not live in a different system from finished goods. A module attached from the side has to reconstruct all of that across an interface, and reconstruction produces the numbers nobody ends up trusting.

No. NG Operations is a separate Konis product for shop-floor operations and it stays that way — NG One orchestrates the ecosystem rather than swallowing it. The point of contact is concrete: the planning UX in NG One (grid, planner cockpit, what-if) is taken from NG Operations because it is proven on a real shop floor rather than designed for a demo. Data exchange rests on the API-first layer with REST and OpenAPI over every entity, plus MCP access for agents. The scope of exchange is defined per project, because no two plants draw the line between floor operations and the wider chain in the same place — and we say that before a signature rather than after one.

The calculation comes from lines, not averages: material at actual consumption and actual purchase cost including landed costs, labour from shop-floor reporting, subcontracting at the service charged, overhead by a key that is effective-dated configuration — so a past calculation does not change when the key changes. Variance against the standard estimate stays attached to the order where it arose and is broken down by cause: material, time, scrap, subcontracting. Postings carry dimensions, so profitability by product, order, plant or customer leaves the same general ledger as the trial balance and always agrees with it. A backdated report triggers a recalculation instead of leaving a wrong product cost standing.

Nothing happens to the open order — and that is the point. The BOM is a versioned record and the order references the version it was opened under, so a revised norm applies to orders created from then on. When someone later asks why consumption deviated, the version is read from the order instead of reconstructed from emails. If the change must also apply to an open order, that is a decision taken deliberately, it leaves a trace and it appears in the order history — rather than a silent change that retroactively alters the meaning of consumption already reported.

Both. APS produces a finite schedule against capacity, tooling, people and calendars, and gives every order an explanation of why it landed on that slot — a schedule that cannot be explained is one the planner cannot defend on the floor anyway. Underneath it sit sales and production planning, MRP, the Production Grid and what-if scenarios in a copy of the plan, so a change is tried out before it touches the published schedule. PLM runs the product lifecycle and engineering change through ECO: who requested the change, who approved it, and the date it takes effect on the BOM. One note without embellishment: scheduling is only as accurate as your times per operation, and those times come from reporting on the shop-floor terminals — which is why APS and reporting sit in the same core rather than in two systems that sync overnight.

In the order in which the data depends on itself. Engineering first: items with UoM conversions, BOMs with versions and validity dates, routings and norms — the part that takes the most work from you, because today it is usually scattered across spreadsheets and people's heads. Then dimensions and the effective-dated overhead key are set, so the standard estimate has a reference from the first order. Then plan and MRP, then the floor and reporting, then quality and maintenance. You go to go-live with one line or one product family, not the whole plant at once. Configuration is versioned and separated from the core (clean-core), so what you set during implementation survives an upgrade instead of landing back on the table with every new release.