Epicor 9 Units of Measure

Yahoo Archive
1
Hi Chris,

> It appears to me the conversion routine is flawed as it doesn't show
> the factor.

The factor is built into the UOM table and is not displayed. For each UOM
type (count, length, volume, weight, and area) you must pick one UOM as your
base. Every other UOM has to have a conversion factor to that base. We have
bottles, cans, reams, etc. but most are for non-inventory items and we chose
a conversion factor of 1. 1 box = 1 EA because we don't break down these
items any further.

> And since versions 3 to 8 have been free-form, there could exist
> obviously invalid units of measure.

Yes - absolutely. The UOM conversion program scans a bunch of tables and
lists all of the UOMs found. The conversion program lets you reassign an
old/bad UOM during conversion. For example, we had a UOM of 'E' but it's
really EA. In the conversion program, we picked "EA" for our Version 9 UOM
whenever "E" is found. The "E" will be gone in Epicor 9 - so the conversion
factor really doesn't matter in that case.

> If the units of measure are
> different, either IUM/PUM or IUM/SUM (for example: Ft/In) than the
> factor shouldn't be 1. Conversely, if they're the same, the factor
> should be 1. We have both cases... most of them the first type of
> error: different units but factor is 1.

Right. If the base is IN then the conversion factor will always be 12 when
FT is the UOM whether it's an IUM or PUM.

Where this becomes a bit of a PITA is with UOMs like rolls. I may buy things
in 100FT rolls or 120IN rolls. I cannot have a single RL UOM because the
conversion factor to the base UOM (FT) is different.

Another gotcha I forgot to mention was serialization. If a part is
serialized, its UOM cannot allow fractions of a unit, i.e. no 0.5 EA. If you
find that you need a fraction of a unit for a particular part, change it's
UOM to PC or something else NOW. Then allow that UOM to have fractional
units. The conversion program will set any UOM used on a serialized part to
not allow fractional units.

Once a UOM is used, you can't change it, so don't take this task too
lightly.

Mark W.
2
Any words of wisdom from those who've converted from 8 to 9 regarding
Units of Measure?

Patch 8.03.406 and 407 provide Conversion Routine 9800:
Analyze/Prepare/Apply 8.03 UOM to 9.0. I would think most would be
simple, like inches, feet, yards etc. But what about a package of 6 or
8 or 100 etc? Can you override at the PO or must everything be
predefined in the Units of Measure table?
3
Chris, I don't have first hand knowledge, but we had a consultant here with us all last week. He's helping with some v. 8 issues, but when he talked about 9, we asked him this same question.
He was telling us that the UoM choices must exist in the table before choosing at PO, but that you can add anything you want to the UoM table. just not on the fly, however.
Hope this helps.




________________________________
From: Chris Robisch <bluewine@...>
To: vantage@yahoogroups.com
Sent: Monday, December 22, 2008 3:55:45 PM
Subject: [Vantage] Epicor 9 Units of Measure


Any words of wisdom from those who've converted from 8 to 9 regarding
Units of Measure?

Patch 8.03.406 and 407 provide Conversion Routine 9800:
Analyze/Prepare/ Apply 8.03 UOM to 9.0. I would think most would be
simple, like inches, feet, yards etc. But what about a package of 6 or
8 or 100 etc? Can you override at the PO or must everything be
predefined in the Units of Measure table?






[Non-text portions of this message have been removed]
4
Hi Chris,

> Any words of wisdom from those who've converted from 8 to 9 regarding
> Units of Measure?
>
> Patch 8.03.406 and 407 provide Conversion Routine 9800:
> Analyze/Prepare/Apply 8.03 UOM to 9.0. I would think most would be
> simple, like inches, feet, yards etc.

As you know, UOM will no longer be a free-form field but it's more than
that. There are UOM Types too. Each UOM *must* belong to one UOM type and
only one. The types are user-definable but the standard ones are Counting,
Area, Length, Volume, and Weight. So, consider the lowly ounce. You'll need
to have one UOM for fluid ounces (FZ, FLOZ, FL, ...) and another for weight
(OZ).

For each type, you define the base and default UOM. The base UOM determines
the conversion factor for all of the other UOMs in that type. So if inches
are your base, then a foot is 12 of the base (inches) UOM. The default is
the one that appears once you choose a type. A part has a stocking,
purchasing, and sales UOMs.

Each UOM also has a flag that indicates whether one can have a fractional
(decimal) quantity or if quantities must be in whole numbers. If you do
serialization, you must use a UOM that does not allow decimals. There is
also a way to set the decimal precision and rounding rules.

As for the conversion routine, this has been in flux throughout the beta. It
used to be one of the mandatory conversions and it runs a long time. The
process is two-fold. First it identifies every UOM used in every table. It
then builds a database for you to work with. For each UOM found, you tell
the conversion program what the 9.0 code will be and which type it will
belong to. We had a lot of garbage UOMs (especially in JobMtl), so this
program gives you the chance to map these to a correct UOM. Once the
database is built, it is used during the conversion process and it runs for
quite some time - it does after all have to touch each PartTran and JobMtl
files (among the others) to update UOMs.

> But what about a package of 6 or
> 8 or 100 etc? Can you override at the PO or must everything be
> predefined in the Units of Measure table?

Unfortunately, the latest version we are on is preventing me from getting
into Purchase Order Entry (we're not live yet...) but I'll let you know
about that as soon as that is fixed. All UOMs must exist before you can use
them - period. In order to do six, you might have to use 0.5 DZ (dozen).
IIRC, the UOM field is six characters so you'll have room to make up other
UOMs as needed.

Mark W.
5
Good info - Thanks :o)

--- In vantage@yahoogroups.com, "Mark Wonsil" <mark_wonsil@...> wrote:
>
> Hi Chris,
>
> > Any words of wisdom from those who've converted from 8 to 9
regarding
> > Units of Measure?
> >
> > Patch 8.03.406 and 407 provide Conversion Routine 9800:
> > Analyze/Prepare/Apply 8.03 UOM to 9.0. I would think most would be
> > simple, like inches, feet, yards etc.
>
> As you know, UOM will no longer be a free-form field but it's more
than
> that. There are UOM Types too. Each UOM *must* belong to one UOM
type and
> only one. The types are user-definable but the standard ones are
Counting,
> Area, Length, Volume, and Weight. So, consider the lowly ounce.
You'll need
> to have one UOM for fluid ounces (FZ, FLOZ, FL, ...) and another
for weight
> (OZ).
>
> For each type, you define the base and default UOM. The base UOM
determines
> the conversion factor for all of the other UOMs in that type. So if
inches
> are your base, then a foot is 12 of the base (inches) UOM. The
default is
> the one that appears once you choose a type. A part has a stocking,
> purchasing, and sales UOMs.
>
> Each UOM also has a flag that indicates whether one can have a
fractional
> (decimal) quantity or if quantities must be in whole numbers. If
you do
> serialization, you must use a UOM that does not allow decimals.
There is
> also a way to set the decimal precision and rounding rules.
>
> As for the conversion routine, this has been in flux throughout the
beta. It
> used to be one of the mandatory conversions and it runs a long
time. The
> process is two-fold. First it identifies every UOM used in every
table. It
> then builds a database for you to work with. For each UOM found,
you tell
> the conversion program what the 9.0 code will be and which type it
will
> belong to. We had a lot of garbage UOMs (especially in JobMtl), so
this
> program gives you the chance to map these to a correct UOM. Once the
> database is built, it is used during the conversion process and it
runs for
> quite some time - it does after all have to touch each PartTran and
JobMtl
> files (among the others) to update UOMs.
>
> > But what about a package of 6 or
> > 8 or 100 etc? Can you override at the PO or must everything be
> > predefined in the Units of Measure table?
>
> Unfortunately, the latest version we are on is preventing me from
getting
> into Purchase Order Entry (we're not live yet...) but I'll let you
know
> about that as soon as that is fixed. All UOMs must exist before you
can use
> them - period. In order to do six, you might have to use 0.5 DZ
(dozen).
> IIRC, the UOM field is six characters so you'll have room to make
up other
> UOMs as needed.
>
> Mark W.
>
6
It appears to me the conversion routine is flawed as it doesn't show
the factor.

And since versions 3 to 8 have been free-form, there could exist
obviously invalid units of measure. If the units of measure are
different, either IUM/PUM or IUM/SUM (for example: Ft/In) than the
factor shouldn't be 1. Conversely, if they're the same, the factor
should be 1. We have both cases... most of them the first type of
error: different units but factor is 1.

--- In vantage@yahoogroups.com, "Mark Wonsil" <mark_wonsil@...> wrote:
>
> Hi Chris,
>
> > Any words of wisdom from those who've converted from 8 to 9
regarding
> > Units of Measure?
> >
> > Patch 8.03.406 and 407 provide Conversion Routine 9800:
> > Analyze/Prepare/Apply 8.03 UOM to 9.0. I would think most would be
> > simple, like inches, feet, yards etc.
>
> As you know, UOM will no longer be a free-form field but it's more
than
> that. There are UOM Types too. Each UOM *must* belong to one UOM
type and
> only one. The types are user-definable but the standard ones are
Counting,
> Area, Length, Volume, and Weight. So, consider the lowly ounce.
You'll need
> to have one UOM for fluid ounces (FZ, FLOZ, FL, ...) and another
for weight
> (OZ).
>
> For each type, you define the base and default UOM. The base UOM
determines
> the conversion factor for all of the other UOMs in that type. So if
inches
> are your base, then a foot is 12 of the base (inches) UOM. The
default is
> the one that appears once you choose a type. A part has a stocking,
> purchasing, and sales UOMs.
>
> Each UOM also has a flag that indicates whether one can have a
fractional
> (decimal) quantity or if quantities must be in whole numbers. If
you do
> serialization, you must use a UOM that does not allow decimals.
There is
> also a way to set the decimal precision and rounding rules.
>
> As for the conversion routine, this has been in flux throughout the
beta. It
> used to be one of the mandatory conversions and it runs a long
time. The
> process is two-fold. First it identifies every UOM used in every
table. It
> then builds a database for you to work with. For each UOM found,
you tell
> the conversion program what the 9.0 code will be and which type it
will
> belong to. We had a lot of garbage UOMs (especially in JobMtl), so
this
> program gives you the chance to map these to a correct UOM. Once the
> database is built, it is used during the conversion process and it
runs for
> quite some time - it does after all have to touch each PartTran and
JobMtl
> files (among the others) to update UOMs.
>
> > But what about a package of 6 or
> > 8 or 100 etc? Can you override at the PO or must everything be
> > predefined in the Units of Measure table?
>
> Unfortunately, the latest version we are on is preventing me from
getting
> into Purchase Order Entry (we're not live yet...) but I'll let you
know
> about that as soon as that is fixed. All UOMs must exist before you
can use
> them - period. In order to do six, you might have to use 0.5 DZ
(dozen).
> IIRC, the UOM field is six characters so you'll have room to make
up other
> UOMs as needed.
>
> Mark W.
>
7
Chris,

As Mark mentioned, the UOM conversion has been changing throughout
the
beta process, and there will be more changes in 503 (I am told).
We are currently Live on Epicor9
You are correct, we had Many Many bad units of measure, mostly on
Sales Orders
in our database. We did the following to minimize the conversion
garbage in
Epicor9:
1) I recorded all existing non-standard conversions (LBS to Inches etc)
By standard conversions I mean INCH to FOOT to YARD etc.
2) I forced All parts to have the same UOM Class for IUM,PUM & SUM
3) We did the conversion. We resolved most of the strange UOM's
to EA (but your business & errors may be different)
Note: any non-standard conversions will be lost when the database is
converted. They have to be manually entered later.
Currently, the non-standard conversions are entered on the Part
Maintenance
program, but THEY CAN NOT BE CHANGED ONCE USED. Be very
careful with the direction of the conversion.
Hopefully in 503, we will be able to enter conversions into one of the
Supplier
files for conversions that may change (for example, weight of a
part to be
heat treated, which could vary by how much extra material we
leave to be
ground flat when we are done)

Rick

Richard Sirow, President
Independent Components Corp.
516-481-5100 x106 FAX=516-481-5550

On Dec 29, 2008, at 4:01 PM, Chris Robisch wrote:

> It appears to me the conversion routine is flawed as it doesn't show
> the factor.
>
> And since versions 3 to 8 have been free-form, there could exist
> obviously invalid units of measure. If the units of measure are
> different, either IUM/PUM or IUM/SUM (for example: Ft/In) than the
> factor shouldn't be 1. Conversely, if they're the same, the factor
> should be 1. We have both cases... most of them the first type of
> error: different units but factor is 1.
>
> --- In vantage@yahoogroups.com, "Mark Wonsil" <mark_wonsil@...> wrote:
> >
> > Hi Chris,
> >
> > > Any words of wisdom from those who've converted from 8 to 9
> regarding
> > > Units of Measure?
> > >
> > > Patch 8.03.406 and 407 provide Conversion Routine 9800:
> > > Analyze/Prepare/Apply 8.03 UOM to 9.0. I would think most would be
> > > simple, like inches, feet, yards etc.
> >
> > As you know, UOM will no longer be a free-form field but it's more
> than
> > that. There are UOM Types too. Each UOM *must* belong to one UOM
> type and
> > only one. The types are user-definable but the standard ones are
> Counting,
> > Area, Length, Volume, and Weight. So, consider the lowly ounce.
> You'll need
> > to have one UOM for fluid ounces (FZ, FLOZ, FL, ...) and another
> for weight
> > (OZ).
> >
> > For each type, you define the base and default UOM. The base UOM
> determines
> > the conversion factor for all of the other UOMs in that type. So if
> inches
> > are your base, then a foot is 12 of the base (inches) UOM. The
> default is
> > the one that appears once you choose a type. A part has a stocking,
> > purchasing, and sales UOMs.
> >
> > Each UOM also has a flag that indicates whether one can have a
> fractional
> > (decimal) quantity or if quantities must be in whole numbers. If
> you do
> > serialization, you must use a UOM that does not allow decimals.
> There is
> > also a way to set the decimal precision and rounding rules.
> >
> > As for the conversion routine, this has been in flux throughout the
> beta. It
> > used to be one of the mandatory conversions and it runs a long
> time. The
> > process is two-fold. First it identifies every UOM used in every
> table. It
> > then builds a database for you to work with. For each UOM found,
> you tell
> > the conversion program what the 9.0 code will be and which type it
> will
> > belong to. We had a lot of garbage UOMs (especially in JobMtl), so
> this
> > program gives you the chance to map these to a correct UOM. Once the
> > database is built, it is used during the conversion process and it
> runs for
> > quite some time - it does after all have to touch each PartTran and
> JobMtl
> > files (among the others) to update UOMs.
> >
> > > But what about a package of 6 or
> > > 8 or 100 etc? Can you override at the PO or must everything be
> > > predefined in the Units of Measure table?
> >
> > Unfortunately, the latest version we are on is preventing me from
> getting
> > into Purchase Order Entry (we're not live yet...) but I'll let you
> know
> > about that as soon as that is fixed. All UOMs must exist before you
> can use
> > them - period. In order to do six, you might have to use 0.5 DZ
> (dozen).
> > IIRC, the UOM field is six characters so you'll have room to make
> up other
> > UOMs as needed.
> >
> > Mark W.
> >
>
>
>



[Non-text portions of this message have been removed]