UOM Conversion Business Function problem

[wjhoogduin]

Hi all,

Can somebody help me with the following problem?

I'm building an CSV file which needs to convert a UOM Quantity to another UOM Quantity. Now I found out that I could use the standard BF B4000520 to do this for me.

I filled the following mappings:
F4211.MCU -> BranchPlant
F4211.UOM -> FromUOM
'PL' -> ToUOM
F4211.SOQS -> QuantityToConvert
'1' -> SuppressErrorMessage
F4211.ITM -> ShortItemNumber
SOQS <- ConvertedQuantity

My conversion set-up is as follows:
USTR UOM = UOM
1. 1 PL = 4 LA
2. 1 LA = 21 TU
3. 1 TU = 6 EA
4. 1 EA = 1.5 LT

Now I've got 2 records to be converted.
1. 2016 EA to PL
2. 164 TU to PL

The second line gives no trouble at all, it shows up as 2 PL, which is correct if you do the math.
The first line is the one that gives issue. It shows up as 24 PL, which is not even close. It should give 4 PL as the outcome.
If you still have your calculator, you could probably figure out really easily that 24 devided by 6 gives 4 (the correct answer), which leads to the conclusion that the BF is skipping the conversion from EA to TU. Or better it's only converting TU to LA to PL.
To test if the BF is recognizing the UOM EA, I had it convert the EA to TU. Obvisiously this went awesomely well.
So now I'm stuck with the fact it's not converting an extra level.

Does anyone know how to overcome this or is there anyone who has the knowledge to fix this? I'm not that formilliar with C-debugging, so that would probably not be an option for me. Neverdeless, I'm not even thinking of changing a standard BF!

Please help me!

Thanks in advance.

Willem
The Netherlands

 

[JMast]

Willem,

I am not sure I have seen that function loop through 3 levels of conversion.

The quick solution would be to enter a conversion from EA to PL. It is generally a good idea to have each of the needed conversions in the conversion table.

In addition to preventing issues in JDE, this can be useful for Customer Service or Inventory people who may want to do a quick lookup in the system to see what the conversion is. We work with leather hides which get complicated with eaches, square feet, pounds. We have found that it is easier for people to maintain and understand the conversions when they are kept simple.

Is this something that would work for you or would it be too much maintenance to do? Of course, you don't enter every possible combination, only the ones that will be used in the system or the users would reference.

Jer