SmartProject connects parts, BOMs, product structures and engineering documents with purchase requisitions, ERP procurement and controlled supplier transmittals—preserving the engineering definition through to supply. It integrates with enterprise ERP systems, including SAP, Oracle, Vantage, and others, enabling seamless information exchange between engineering and procurement teams.
A connected lifecycle that begins with the engineering definition of a part and continues through BOM, product structure, purchase requisition, ERP purchase order visibility and supplier document delivery. The engineering layer stays in Wrench; enterprise procurement stays in ERP; and the thread between them is preserved by API integration and controlled transmittals.
What was engineered, what was purchased, who is supplying it, and the technical information issued — connected.
Define and release parts, connect BOMs to purchase requisitions, exchange procurement data with ERP, and control technical information issued to suppliers.
Consolidation brings parts, BOMs, product structures and documents into one engineering environment. ERP integration eliminates duplicate manual entry. Controlled workflows govern approvals and releases. Transmittals link technical documents to purchased parts. The combined effect is a connected lifecycle that supports coordination between engineering, buyers, project management and document control.
Engineering definition flows to BOM, to product structure, to PR, to ERP PO, to supplier transmittal — one connected lifecycle instead of application-to-application handoffs with manual bridges in between.
API integration transmits released parts to ERP for material master creation, and PRs to ERP for buying. The engineering information doesn't need to be re-keyed into the enterprise system by procurement coordinators.
Configurable workflows govern part status, revision, supporting documents, approval history and release — with structural audit trails. The engineering governance that was lost in email bridges is restored.
After PO release, engineering, PM and document-control teams see PO number, supplier, part, quantity and delivery date in Wrench — no need for full ERP seats or chasing procurement for status updates.
Engineers capture the gap between design count and execution reality as a structural field on the PR — defects, damage, wastage, project contingencies — not as a scribbled note on an email the buyer may miss.
The supplier receives the commercial PO from ERP and the technical documents from Wrench — controlled, versioned, acknowledged — not a PO from procurement and a stream of email drawings from engineering.
Quick answers on parts, BOMs, ERP integration and supplier documentation.
No. Wrench provides the engineering information layer; ERP remains the enterprise transaction layer. The two systems operate in parallel, connected by API integration. Wrench holds parts, BOMs, product structures, engineering documents and purchase requisitions. ERP holds material masters, commercial procurement, purchase orders and financials. The customer who implemented this model kept ERP for enterprise procurement throughout — Wrench added the engineering layer that was previously spread across PLM, Documentum and manual bridges.
Two primary integration paths:
Buyers continue to perform commercial procurement in ERP — supplier selection, negotiation, PO issuance — while engineering and document-control teams see the resulting PO information in Wrench.
Engineers include contingency quantities on the PR to account for anticipated material defects, damage, wastage or project execution needs. The contingency is a structural field on the PR alongside the engineering quantity — not a note in an attachment or a verbal instruction to procurement. In the typical example, an engineering requirement of 100 units with a contingency of 5 units produces a procurement requirement of 105 units. ERP buys the full 105, the engineering design remains the authoritative 100, and the gap is captured and visible — not lost in translation. This replaces the common pattern where contingency gets added informally and procurement, engineering and project control teams end up with three different numbers for the same part.
A part record is the single engineering reference point for an item, with configurable attributes across:
Each part also acts as the reference point for its supporting documents — drawings, specifications, technical datasheets, supplier documentation, quality documents, certificates, MSDS/SDS, inspection and compliance records. The part definition and all its supporting information live together as one controlled engineering record.
Each part moves through a configurable workflow that routes it through engineering review, approval and release. The workflow governs part status, revision, supporting documents, approval history, release status and authorized use. Only the approved and released engineering definition moves downstream — meaning only a controlled, formally governed version is used for ERP material master creation and for procurement. This is the structural control that prevents in-progress or unreleased engineering from accidentally flowing into enterprise systems or supplier packages.
Suppliers receive two inputs that work as one coherent delivery: the commercial Purchase Order from ERP, and the controlled technical documents from Wrench. Document controllers in Wrench assemble the technical information associated with the ordered part — drawings, specifications, datasheets, MSDS/SDS, quality certificates, inspection & compliance records — and issue them to the supplier through controlled transmittals with acknowledgement tracking. ERP handles the commercial transaction; Wrench handles the technical content; the supplier doesn't have to assemble the real picture from fragments across email and attachments.
Yes. The reference implementation described here uses ERP, but Wrench's API integration pattern is ERP-agnostic. The same model — released parts flowing to material master, PRs flowing for commercial procurement, PO information returning for engineering visibility — can integrate with Oracle, Microsoft Dynamics, Infor, or other enterprise ERP systems. The core principle holds whichever ERP is in place: Wrench provides the engineering information layer; the ERP provides the enterprise transaction layer; the API preserves the thread.
BOM revisions and part revisions each move through their own controlled workflow, with the audit trail preserving the change history, approval chain and release status. Because the part is the reference point for its documents, any revised drawing or specification is linked back to the part revision that triggered it. When a BOM revision affects already-purchased parts, the PO visibility in Wrench and the transmittal history provide the context required for decisions on supplier re-issue, change notification or impact assessment — rather than a scramble to reconstruct what was issued, to whom, and based on which revision.
Stop relying on emails and spreadsheets for critical document transmissions.