Manufacturing PLM and Epicor Kinetic

What this connector is, and what it is not

It publishes released engineering structures into Epicor as part revisions with their material requirements, and reads cost, on-hand and supplier context back.

Epicor's central construct here is the method of manufacture — the combination of what a part is made of and how it is made, held against a specific part revision. That combination is the interesting problem, because a PLM legitimately owns the first half and manufacturing engineering usually owns the second.

The connector does not resolve that ownership question for you. It surfaces it as a row in the matrix, defaults to publishing material lines only, and leaves operations to whoever owns them in your organisation. What it will not do is publish half a method and then behave as though it owned all of it.

The mechanism: revisions with an approval gate

A release creates a new Part Revision carrying the resolved structure's material lines. Prior revisions stay intact, so Epicor retains the record of what each build consumed.

Approval state is respected. Epicor's engineering workbench exists so that a method does not become usable until somebody with manufacturing responsibility says it is. A published revision enters in the state your configuration specifies, and the connector will not mark a method approved on your behalf. A site that discovers its PLM has been auto-approving methods stops trusting the PLM, not the workbench.

Transport is the REST services Epicor exposes for part and revision data, with credentials held per tenant. Writes are idempotent and publication is all-or-nothing per release; a retried run does not create a second revision.

The failure it prevents

The failure specific to a method-of-manufacture model is a structure and a routing that disagree about the same revision. Engineering revises the bill because a component changed; manufacturing revises the operations because the fixture changed; both are correct, and the two edits land against different revisions of the same part.

Nobody notices until a work order is released against the revision that has the new material and the old operations, or the reverse. The parts are right and the process is wrong, or the process is right and the parts are wrong, and either way it is found on the floor.

Declaring per-object ownership up front does not prevent people from making changes — it prevents the two changes from silently landing in different places. Material lines come from engineering with a revision attached; operations come from manufacturing; both attach to the same revision, and a conflict raises a task rather than winning.

How it meets the rest of the product

What publishes is a resolved structure. Effectivity, variants, revision policy and plant scope are evaluated in one pass so Epicor receives a concrete method, not a conditional statement it has no way to evaluate.

Impact analysis reads Epicor context. An engineer scoping a change sees which affected parts have on-hand quantity and open demand behind them, so “this is a cheap change” gets tested against the sixteen weeks of stock that makes it an expensive one.

Cost and supplier fields render read-only in Manufacturing PLM, labelled with Epicor as the owning system, and roll up through the resolved structure for cost analysis without either system writing the other's numbers.

The AVL sits alongside the Epicor supplier record rather than replacing it. Epicor owns the commercial relationship — terms, pricing, the supplier part number a buyer transacts against. Manufacturing PLM owns which manufacturer parts engineering has approved for a given internal part, and which of them are qualified. Those are two different questions that a single supplier field cannot answer.

How it meets your ERP

Item identity matching runs on manufacturer part number first, internal part number second, then a configurable tie-break. Epicor will hold parts Manufacturing PLM never created — purchased hardware set up by buyers, service parts, non-stock items — and those keep their Epicor identity. Unmatched parts are surfaced for a person rather than merged automatically.

Every sync is an attributed audit row naming the connector, the run and the direction, so an auditor asking who changed a method and when gets an answer that names a system. Sync history is queryable and retries are bounded.

If a published revision's material lines are edited in Epicor, the next run raises a reconciliation task naming the part, the revision, the field, both values and the owning system. It does not overwrite — in a shop where manufacturing engineering has legitimate reasons to adjust a method, silently reverting their work is how the integration gets disabled.

Where the boundary is

No job entry, no work orders, no purchase orders, no material transactions, no cost postings. Manufacturing PLM reads context and writes engineering definition; everything transactional stays in Epicor.

Operations, resource groups, work centres and setup times are not published by default. They sit under the tenant-decided row of the matrix and in most deployments they belong to manufacturing engineering inside Epicor, where the people who own them already work.