Re: Shop Order BOM Problem

["Al" <macwheel99@xxxxxxxxxx>]

I am on an earlier version of BPCS, so my speculations might not hold water.
Look at the date of release of the shop order, since at time of release the
FMA is copied from BOM.
Is it possible that the shop orders were being released by one person
simultaneously with another doing the BOM updates?

Could rounding be going on?  We found a bug in Unit of Measure conversion,
where wrong results occur when there are what the IBM RPG manual calls
EXTREME values, like zero or one.  The bug is when BPCS has ordinary values
in a field of size like XXXXXXXX.XXXXXXX I can't remember how many places,
but the field is in essence maximum size numeric for RPG.  If you are doing
math with multiple fields defined like this, then there is a risk that the
math can have digits "fall off" the edge of what is defined, unless a work
field is defined.

-
Al Mac

-----Original Message-----
From: bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx] On Behalf Of
Bailey, Dick
Sent: Tuesday, April 21, 2009 6:39 PM
To: bpcs-l@xxxxxxxxxxxx
Subject: [BPCS-L] Shop Order BOM Problem

          We are on BPCS 8.0, using vanilla shop order creation and release
programs.

           What would cause a shop order to be released with a BOM (FMA)
that contains, for one part number, a qty req'd field value of zero, but a
quantity required of 1. (Both should be 1)?

           It happens that the item type of this part number was recently
changed from A (purchased) to 0 (phantom) and we are still in a use-up mode,
because we have a quantity ot it on hand.  I doubt that this has any bearing
on the problem, however, because there are several other part numbers for
which all the above is true, but the quantity required is correct.

           What should I look at - a data problem in the BOM, or what?

            Thank you.

           Dick Bailey
            MCFA,Inc.