Manufacturing PLM and ViBe ERP

What this connector is, and what it is not

It is the reference implementation of the connector framework — the one the other five are built against, and the one where the framework's assumptions were tested before there was a customer to disappoint.

That has a specific practical consequence. In the other connectors, effectivity has to be translated: a unit-number range flattens when the target cannot model it, and the flattening rule lives in configuration. Here there is nothing to flatten, because ViBe models effectivity as ranges across the same three dimensions Manufacturing PLM does. The agreement was made in the schema rather than in a mapping table.

What it is not is a merged system. ViBe ERP and Manufacturing PLM remain two products with two databases and two release cycles, and the boundary between them is enforced by the same matrix that governs a third-party ERP. Being operated by the same company is not a reason to blur a system-of-record line — it is the most common reason people do.

The mechanism: events rather than polling

Where the third-party connectors publish on release and read context on a schedule, this one is event-driven in both directions. A release emits an event ViBe consumes; a cost or inventory change emits an event Manufacturing PLM consumes. There is no nightly window during which the two systems disagree.

Because the two share a suite identity layer, credentials are not a per-tenant API key exchange but a scoped grant — and it is still scoped per tenant, with no shared credential across tenants. Convenience is the usual reason that rule gets broken between systems operated by one company, so it is worth stating that it was not broken here.

Connector runs establish the same tenant context a user request does, so the isolation predicate applies to sync work exactly as it applies to a page load. Background jobs are where isolation usually leaks, and a native connector is where the temptation to skip that is highest.

The failure it prevents

The failure a native connector exists to prevent is not a data error. It is the six-week field-mapping workshop that precedes every ERP integration, where two teams discover that “part number” means three different things and that one system's unit of measure is the other's packaging quantity.

That workshop is unavoidable with a third-party system and the matrix exists to make it productive rather than to skip it. Between Manufacturing PLM and ViBe it was held once, at the schema level, before either product shipped — so identity, units, effectivity semantics and revision meaning were agreed rather than reconciled afterwards.

The result is an integration that can be turned on in an afternoon rather than scoped as a project, which is the practical argument for running both. It is not an argument that the boundary matters less.

How it meets the rest of the product

Everything published is resolved first, the same as every other connector — effectivity, variants, revision policy and plant scope evaluated in one pass. The difference is that the resolved answer arrives with its conditions intact rather than flattened, so ViBe can answer a unit-number question without asking Manufacturing PLM again.

Impact analysis reads live inventory and open demand rather than a cached snapshot, so the operational consequence shown next to an engineering change is current rather than as-of last night. That matters most for exactly the decisions where it is easiest to be wrong.

Agents inherit the matrix here as everywhere. The Cost Agent reads cost from ViBe and will not propose editing it; the Supplier Agent reads supplier records and adds only approval state.

How it meets your ERP

If you already run ViBe ERP, item identity is agreed rather than matched — the two systems share the concept, so there is no manufacturer-part-number tie-break and no queue of unmatched items to work through before go-live.

If you do not, this page is mostly useful as a description of what the other five connectors are approximating. The framework is the same, the matrix is the same, and the conflict behaviour is the same; what differs is how much translation sits between the two schemas.

The reverse direction is still read-only. Cost, on-hand, committed, in-transit and supplier records master in ViBe and render read-only in Manufacturing PLM, labelled with the owning system. Shared ownership would be easy to build here and it is deliberately not built, because a field with two masters is a data-loss incident waiting for a scheduling coincidence.

Where the boundary is

Manufacturing PLM has no ERP functionality and gains none by being adjacent to one. No general ledger, no accounts payable or receivable, no invoices, no sales orders, no purchasing transactions, no inventory movements — the same list as every other connector page, for the same reason.

Nor does ViBe gain PLM functionality. Change control, revision semantics, effectivity resolution and the relationship graph stay here. Two products operated by one company that quietly grow into each other end up as one product nobody can deploy separately.