How does Windchill identify pending change and resulting change in ESI transactions?
Checked the XML of the ESI transaction but there's no CRs or CNs in it.
How else can we stop MRP/ERP buying or manufacturing low revisions?
The triangles are indicating there are changes underway which will impact those parts, yet when Windchill published those parts to downstream systems like MRP and ERP there is no mention of the changes.
The problem is low revision parts will get made or bought.
There's a preference for whether ESI will create a CN for publishing when you manually publish from the actions menu, if you enable it to automatically create the CN to pass to ERP the effectivity defaults to "today".
If you're testing manually and not seeing CN data, that's probably turned off.
That said, as I understand it, ESI itself doesn't really contribute to an impact analysis process.
CR's and affected objects don't enter into the publishing. And how could they? There's no set disposition.
If the part(s) or BOM(s) are published as a resulting object of a change notice, that Change Number will be part of the response and carried over to ERP as part of the response file, including effectivities. This, of course, assumes you're using change management in your ERP to set effectivities.
However, any business process to look at impact analysis, i.e. when to cutover for Mfg. or sourcing, impact to open PO's, etc., either needs to be part of your WC change process, where future effectivities can be specified in the change, or happen in ERP after the new data is published.
Another piece that fits in here is the active filter on the distribution target. For example, you can set a saved filter that only publishes "released" parts. So if a child part in a BOM is actively being changed (in-work state), it would publish the previously released version when the parent publishes versus the potentially incomplete in-work version.
Conceptually, you could publish parts after revision but before any work starts, and let the "in-work" state in WC translate to a status in ERP that generates some kind of warning for procurement/MRP activity that the part is being revised. However, this would be a lot of "churn" and the impact analysis would still need to happen for the warning to be meaningful.