The problem is that the width and height values are only committed to the database once you press update. That is why the FMS does not get triggered when you change width or height.
Please try the following, and let us know if it works for you:
Use the query I suggested in your other question, or use the one Edy Simon suggested, and attach it to your FMS.
Set the FMS to Auto refresh when field changes:Volume - Sales unit and Refresh regularly.
Make a change to the width or the height, and press Update
Refresh the Item master data window. The value of the Area UDF should now have been updated.
The query is taking the screen value for the calculation.
Example,
If the width value on the screen is 100m, the $[$-54.0.1] will return you '100m', hence you will need the replace($[$-54.0.1],'m','') to just return the 100.
Based on the above, I think you should now figured out how to modify the query .
That is not the problem, and Edy's solution is incorrect. Simply because that solution would mean that 100cm x 10m = 1.000 ?² when in reality it should be 100.000 cm²
The correct way to solve this problem, is by policy. In you company you need to agree on a single unit of measurement for length and width. So always use m or always cm or always mm, but never mixed.
If your database already contains mixed values, use the DTW to update all values to one and the same unit of measurement of your choice.
When importing new items, make sure that any measurements in a different unit, are first converted.
Regards,
Johan
P.S. @Tony: most people on SCN do not get payed to help out on this forum. One of the few incentives is collecting points. You, as the person who asked the question, can award these points by marking an answer as helpful or the solution. Marking your own answer as the solution, when it is not, and not even marking other answers as helpful, will make people less inclined to help you in future.
B1 allows mixed UOM, simply because SAP never deemed it necessary to enforce a single UOM policy. Using a single UOM policy, is more of a best-practices kind of thing. I can easily think up several scenarios that would benefit from a single UOM policy, and not a single one, that necessitates a multiple UOM policy. Also a multiple UOM policy makes automating processes that use measurements, unnecessarily complicated.
You are right though, that the solution can be implemented with a query with string functions and/or case statements. However that only proves my point. A simple agreement to only use m as UOM, or a complicated query, each time you have a new requirement ? In other words, always use the K.I.S.S. method.
Regards,
Johan
P.S. The UOM for each measurement is maintained in a separate own column. So for Height (SHeight1) the UOM can be found in SHght1Unit
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.