Primary UOM Not The Smallest UOM

[Steve Wells]

This is a copy of a question I sent to JDE. I'm interested in reading any comments that anyone may have on the issue.

####################

I would like to re-visit the unit of measure issue raised in Call 5273415. I need some additional clarification on the issue.

The question I need answered explicitly is whether JDE can support using pricing and purchasing UOMs that are smaller than the primary UOM.

Here is a sample item that illustrates the situation:

The sample item comes packaged in a case that contains two, 2.5 gallon bottles. The smallest UOM in which we will physically buy or sell the product is the 2.5 gallon bottle. Therefore, we would like to make Bottle the primary UOM so we can maintain our inventory in bottles, and default Bottle (the primary UOM) as the transaction UOM on sales orders and purchase orders. (One additional note: On occasion, we take returns of a partial bottle, but we have all quantities set to 4 decimals, so we should be able to handle the return OK.)

The norm in our industry is to cost and price this type of item by the gallon, regardless of the physical container in which the product is packaged. As a result, we would like to make Gallon both the pricing and purchasing UOM for the item. Unfortunately, this approach violates the general directive from JD Edwards that the primary unit of measure must be the smallest unit of measure for the item.

It is important to us to be able to use this approach, but we cannot do so if it will cause problems with processing in JD Edwards.

So, to recap, here is our desired setup for the item:

Item: Sam’s Simple Solvent
Packaging: Comes in a case of two, 2.5 gallon bottles.

Item UOM Conversion:
1 case = 2 bottles
1 bottle = 2.5 gallons

Primary UOM: Bottle
Pricing UOM: Gallon
Purchasing UOM: Gallon


Can JD Edwards support this approach? Please use one of the three following statements as the basis of your answer.

1. JD Edwards can support this approach with no problems in any area of the system.

2. JD Edwards can largely support this approach, but potential problems can occur in the following areas:

3. JD Edwards cannot support this approach at all.

Sincerely,

Steve Wells

 

[fknies]

Good luck Steve,

I'm sure you won't have the response in the form you asked (to precise).
We was told a few years ago that if we violate the rule you rised the "guaranty" will also be rised up :-(

Anyway, please share the response you get (if so), we have almost the same question.
For us it is a matter of "yahourt pot" (we produce them per 4, 6 or 12 but sometimes we have to sell them in pot, no matter if it must be a multiple of 4).

Fred

 

[zorin]

Hello, Steve!
As I know primary UOM should be the smallest UOM in structure. So
your pricing UOM may be out of it.


Regards,
Nikolai N.Zorin
JDE Consultant - logistics,AWM,transportation
OWXE SP16.1, IBM Intel, Oracle 8.0.6
mailto:[email protected]

 

[rekblad]

Had a similar problem with JDE. Seems to me it is math and whether or not it is to a greater or smaller UoM doesn't matter. My argument was that if I converted from pallets to carton (and carton is smaller and not the primary) why don't I have this problem?? Secondly, they can do it with currency...

 

[Mike Dupaix]

Rob,
The issue is not so much with the conversion itself
but with the quantity field. JDE defaults to value
with no decimals. Therefore, if a quantity consumed
or sold is less than the primary value, JDE will round
the value to match the quantity decimals. This can
provide extensive differences in cost and usage.
--- rekblad <[email protected]> wrote:
http://www.jdelist.com/ubb/showthreaded.php?Cat=&Board=Apps&Number=42896


__________________________________________________
Yahoo! - We Remember
9-11: A tribute to the more than 3,000 lives lost
http://dir.remember.yahoo.com/tribute



World, OW B733X and Xe

 

[JBeerens]

Hi Steve,

Our company works with a smaller pricing UoM than our delivery UoM (we deliver outer cartons and we invoice in customer units)

We have a small problem, and it is that on 1 of 10000 invoice lines the calculation is made OC x CU-price instead of CU x CU price.
JD Edwards doesn't do anything about this problem, because our primary UoM is not the smallest.

So, yes it is possible, but it can give problems.

Best regards
Jessica

 

[Steve Wells]

For those who are interested, here is the reply JD Edwards sent reagrding making the primary UOM not the smallest UOM.

####################

J.D. Edwards always recommends that primary is the smallest unit of measure.
Your answer to the following scenario would be
number 3; 3. JD Edwards cannot support this approach at all.

See the following possible issues within the system when primary uom is not
the smallest as well as the following KG documents:

JD Edwards only supports the Primary Unit of Measure being the smallest. If
it is not, we can not support client with the many unpredictable results
they may get throughout the system. Issues they can likely expect to
experience in their system will be related to:
1) Errors with unit of measure conversion. The system may not be able to
convert back to primary uom
2) Issues with calcualting correct unit and extended costs/pricing within
sales order
3) Errors with inventory and on hand quantities using conversion
4) Errors within manufacturing parts lists, work orders, kits, bill of
materials, and configurator.
5) Errors with rounding throughout system will likely increase as a result
of not having the smallest uom as primary. This may lead to various
integrity
issues.

I hope this helps to clarify the issue.

####################

 

[erpgeek]

From my experience, anything JDE says on the help desk should be taken with a grain of salt. I called re: an issue with truncation on math numeric data types without moving the decimal. The JDE consultant told me our items did not have the smallest unit of measure as the primary unit of measure and "all bets are off when the primary unit of measure is not the smallest". This perplexed me because the primary UOM on this item is LF (linear feet) and our pricing UOM is SQ(square or 100 sq feet). In fact, he was not going to help on this issue until I set up an item with UOM1 as SQ and duplicated my issue. I argued with this guy for 1 hour trying to get him to explain how 100 square feet of an item is smaller than 1 foot. He told me (after putting me on hold several times) that having 1 SQ of an item is a smaller unit of measure than having 33.47 LF of an item. Am I missing something here?! In our industry we buy items by the purchasing UOM of LB and the primary UOM is LF. Depending on the gauge and width of an item, 1 LF may be larger than LB or vice versa. I wonder what they propose to do in that scenario?

Incidently, the truncation problem is due to a bug in mishandling decimals when a result is larger in places than the data item can handle. For instance if a result is calc'd to be 1001.000552 and the item is set for 9 places with 2 decimals displayed, the value becomes 100.100055. This could plague any multi-decimal enviroment on XE with a service pack less than 19.

 

[rekblad]

The real issue here is that when going back to the Primary UoM the answer has to be "1" - meaning no decimals.
For example, make PL your primary UoM with 20EA = 1 PL. If you receive 21 EA the system will calculate 1.05 PL. That's what they don't want and can't handle --- even though as a business case it may make sense.