Preventing BOM usage UOM to differ from a Parts Default UOM

[sdrzewiczewski]

We are in the process of integrating Windchill with our ERP system. Our ERP system does not allow BOM Units of Measure to be different that the Parts UOM. I found out that I can make it read only by chaning the file below and the entry below. Do you see any reasons that would cause functionality to break?

<windchill home=">\codebase\netmarkets\jsp\part\tabular_input.jsp

From:

<comp:describecolumn id="ti_unit" mode="&lt;strong">EDIT" label="${unitsLabel}" need="quantity.unit" sortable="false" />

To:

<comp:describecolumn id="ti_unit" mode="&lt;strong">VIEW" label="${unitsLabel}" need="quantity.unit" sortable="false" />

Also while I'm at it, our ERP system also doesn't allow editing of UOM once it's been passed in. So I can prevent the change of UOM by editing

<windchill home=">\codebase\netmarkets\jsp\part\editPartCommonAttrsWizardStep.jsp and putting the mode="VIEW" next to the default unit property.

This may be too strict, would it be possible to review the release history of a part, if there is none, allow editing of the attribute. But once there is a successful release to ERP, prevent editing?

thx,

Steve D.

[ptc-568593]

Dear Stephen,

These minor changes to the UI are typically safe to implement, as for looking at the release history of the part (I am guessing you mean lifecycle history) then it is easily possible with a small code insert in the JSP. You should be very careful with these changes for upgrades, they should be clear marked and documented, you should check on each code upgrade if the ootb pages have changed.

You should note that there are many ways to skin a cat, the UI has many different ways to allow users to change data so the only really safe way is to do this is to implement a listener on the WTPartUsageLink, if you are lucky you can throw a WTException in the listener and this will appear as an error in the UI.

Best Regards,
Simon

[rwelch]

Steve,

As Simon has indicated, the JSP method should work fine. But
a potentially more upgrade friendly and also more flexible
approach might be to write a data validation delegate (aka a
validator). If you did that, you could put business logic
to check for successful ReleaseActivities for a part into
the validator and disallow changing the UOM if there are
any. Centralizing the business logic into a validator would
also lessen the problem of finding all the various places
in the UI where the attribute might potentially be changed.
Just my two cents...

Ron