# How to send a Windchill BOM to your ERP > Source: https://netray.co/erp-help/plm-windchill-to-erp-bom-release-integration > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Release the BOM from Windchill on an approved change, not on demand. Use PTC's Enterprise Systems Integration (ESI) for a managed release to SAP or Oracle-class ERPs, or build the feed on Windchill REST Services (OData) for other targets. Map part, structure, revision and effectivity explicitly, and make the ERP response visible back in Windchill. ## Kind how-to ## System mfg-systems ## Erp PTC Windchill with any ERP ## Module Windchill / BOM and change release to ERP ## Query how to send Windchill BOM to ERP ## Alternate Queries - Windchill ESI BOM release to SAP - Windchill REST Services get part structure - Windchill change notice to ERP integration - Windchill to ERP part number sync ## Applies To PTC Windchill 11.x to 13.x with Windchill ESI or Windchill REST Services; ERPs including SAP, Oracle, Infor, NetSuite and others via middleware. Exact option names vary by release. ## Steps ### Design the Windchill to ERP BOM release **Items:** - Define the trigger: release on a Change Notice reaching Implemented or Released state, so ERP only receives approved data. - Decide the unit of release: parts and their structures affected by the change, with revision and effectivity dates. - Choose the mechanism: ESI with a configured distribution target for a managed release, or Windchill REST Services (OData) read plus your own integration for custom targets. - Document the field mapping: part number, name, unit of measure, make or buy, revision, BOM quantity, reference designators, find number, substitutes and effectivity. - Handle master data ownership: which attributes Windchill sets (description, revision, BOM) and which the ERP owns (costing, planner, lead time, safety stock, MRP type). - Send the data in a defined order: materials or items first, then BOM structures, then change or effectivity records. - Capture the ERP's acknowledgement and write status back to Windchill, or at least to a monitoring view, so engineers see failures. - Test with a part that has a multi-level BOM, a revision change, a phantom assembly, a substitute and a part that fails an ERP rule. ## Sections ### ESI versus REST Services **Body:** Windchill ESI (Enterprise Systems Integration) is the PTC-supplied way to publish parts, BOMs and changes to an enterprise system. It builds a release package from a change object, applies a mapping, delivers it to a target, and records the response. For SAP, PTC has supported connector options; for other ERPs, ESI can emit files or messages that middleware translates. Confirm current supported targets and versions with PTC. Windchill REST Services expose Windchill data over OData, for example the part management domain for parts and their structures. You write the integration yourself: query released parts and structures, transform, and call the ERP's API. This gives more control and fits non-standard ERPs, but you own error handling, retries, and tracking what was already sent. Either way, the trigger should be a workflow event on the change, not a nightly dump of everything. Full dumps hide intent, create large reconciliation problems and can overwrite ERP-owned fields. **Code:** GET /Windchill/servlet/odata/ProdMgmt/Parts?$filter=Number eq '100-2045'&$expand=PartUses # Exact domain, version and entity names depend on your Windchill release and WRS version ### Mapping the things that go wrong **Body:** Revisions: Windchill uses revision and iteration (for example A.3), while many ERPs use a revision level or change number. Decide whether the ERP revision is only the major letter or a combined value, and keep the rule identical across all parts. Effectivity: engineering change often has a date, a serial or a lot effectivity. Many ERPs handle date effectivity natively but serial effectivity differently, or not at all. Choose what the ERP can enforce and document the rest as a manual or MES-controlled step. Units and structure: Windchill allows structures the ERP will not accept, such as the same child twice under a parent with different find numbers or quantities in different units. Validate before sending and return a readable error, not a failed IDoc or API call with a code. Make or buy and phantom: the ERP needs to know whether a part is manufactured, purchased or a phantom assembly that explodes through. This is rarely stored cleanly in PLM, so define a source attribute and enforce it. ### Closing the loop **Body:** The weakest point in most PLM to ERP projects is feedback. Engineers release a change and assume it landed. Capture the ERP response per part and per BOM, store it against the change, and give engineering a list of failed releases with the ERP's message. Reconciliation should be routine. Compare, for released parts, the BOM component list and quantities in the ERP against Windchill at the effective revision. Differences caused by manual ERP edits or failed partial releases show up quickly with a simple scheduled query. Consider what happens with prototypes and in-work changes. Keep these out of the ERP, or into a separate planning status, so production planners do not see unreleased designs. ## Pitfalls - Releasing on demand or nightly dumps instead of on an approved change, which overwrites ERP-owned planning data. - Sending BOMs before the component parts exist in the ERP. - Ignoring effectivity, so the ERP shows a new revision active before the shop is ready. - Letting Windchill overwrite ERP costing, MRP and purchasing attributes. - No acknowledgement path back to engineering, so failures are found by planners. - Treating the integration as a one-time project with no owner after go-live. ## Ai Angle An assistant grounded in the ERP can compare what the ERP holds against an extract of the released Windchill structure and say which BOMs differ, which components are missing, and which open work orders still use a superseded revision. With ERPray it reads the live ERP read-only, shows its query and respects roles. It does not release changes; engineering approval and the release workflow remain in Windchill. ## Faq ### Should I use Windchill ESI or build on REST Services? **Answer:** Use ESI when your target is a supported ERP and you want a managed release with responses. Use REST Services when the ERP is not supported or you need custom transformation. REST gives flexibility but you build the retry, tracking and error feedback yourself. ### Which system should own the part number? **Answer:** Usually the PLM generates and owns the engineering part number, and the ERP receives it. The ERP can still own plant-level attributes. Avoid creating numbers in both systems, which causes duplicates and manual matching. ### How do I stop PLM from overwriting ERP planning fields? **Answer:** Define attribute ownership in the mapping and send only the PLM-owned fields on update. In the ERP interface, protect planner, lead time, safety stock and costing fields from update by the integration user. Test an update to prove it. ### Do I need to send every part revision? **Answer:** Not necessarily. Many plants send only revisions that change form, fit or function and that affect production. Decide with engineering and quality, document the rule, and make sure a revision that changes a BOM or routing always reaches the ERP. ## Search terms Windchill to ERP integration, Windchill BOM release, Windchill ESI, Windchill REST Services OData, PTC Windchill SAP integration, Windchill change notice ERP, PLM to ERP BOM sync, Windchill part structure API, send BOM from PLM to ERP --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json