A client sells the same item to most customers in pounds but to a few customers in kilograms.

They have set up the stocking unit of measure as pounds. They would like to create an alternate unit of measure, but Adagio restricts it to whole number factors.

How do others deal with this?

Hi Steve,

You cannot create alternate unit of measure factors with decimals unless you enable 'Fractional Quantities' in the IC company profile. Once this is enabled, you can enter 0.454 for converting pounds to kilograms (or 2.2 for the other direction).

Makes sense?

This is a feature we would like to use. When I test it I find that "units sold year-to-date" is updated in the grid but "quantity on hand" is not updated when using the alternate unit of measure. It is updated if using the standard "stocking unit" in OE 8.1C and Inventory 8.1C. What could cause this?

Regards,

Rick McLeod

Hi Rick

Quantity on hand, by definition, is always measured in terms of the "stocking unit".

If you want to know the quanitity on hand based on an alternative unit of measure, you will have to create a custom report, using GridView, Crystal Reports for Adagio, or some similar tool.

The alternative units of measure are used for purchasing, selling, and physical inventory counts, but for on-hand and inquiry purposes, everything is translated back to stock unit.

I don't see a problem with this. If you do, can you explain further.

Steve

Hello Steve,

In this test, we sell an item by the yard & defined the alternate unit of measure as a foot (0.3333 of the stocking unit). If I invoice 4 ft. then the "units sold to date" increases by 1.32 but the "quantity on hand" does not decrease at all. However, if I invoice 1 yd (using the standard stocking unit) of course it goes down by 1. Do you have any explanation?

Regards,

Rick McLeod

Hi Rick,

Using the Current versions of OE and IC, I could not replicate the situation where shipping 4 Feet of an item, where the stocking unit is in Yards and the Alternate unit of measure conversion is 0.3333 Yards per Foot, and the Qty on hand is not reduced by the correct amount of 1.33. The Sales History 'Units sold' also increased by 1.33 units. This is using either OE invoices or IC Shipments.

Can you indicate where you are looking to determine that the quantity on hand is not decreasing after 4 feet of an item is sold? Have you run Day End if using Order Entry?

Hello,

Unfortunately, my results are not consistent & repeatable. The part # that resulted in the error in the initial test had a high quantity on hand (1183) and when I did the transactions with another part with only 29 on hand, the results did not repeat and everything worked as expected.

Then I restored the data to the original starting point & there was a different incorrect result for both part numbers. If 2 ft. was invoiced 2 times for each part, the "units sold to date" increased by 1.32 for each part number and if sold as 4' per part 1 time each, "units sold to date" increased by 1.33. However, the "quantity on hand" dropped by 1.00 by one method & by 0.00 by the other method instead of 1.33 each time. DIC in IC showed no errors but DIC in OE produced the following identical errors for the 2 part numbers used in OE for the tests.

Orders/Invoice headers ... Checked OK
Item UK51P ShipNotCosted at loc 1 is -1.65 calc 0.00
Item UK51S ShipNotCosted at loc 1 is -1.65 calc 0.00

The rebuild function in OE DIC did change the "quantity on hand" down by 1.65 on each part # in IC to match the increase in "units sold to date".

This is not causing any problems and it appears that OE DIC rebuild will fix any errors. This was only a test on the procedure and everything on our live data is working perfectly (but without fractional quantities).

Thanks for your help. I would like to use this feature in the future.

Rick

Today I ran "end of day" and retrieved the batches into AR (not done in prior trials) before trying again and everything worked properly this time with no DIC errors. The "quantity on hand" and the "units sold to date" quantities were correct. I will let you know if the problem shows up again.

Rick