Thank you Al!
I will need to study your message further and dig deeper into this with
our users here to see exactly how all this matches up.
Don
-----Original Message-----
From: bpcs-l-bounces+dcavaiani=amerequip.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+dcavaiani=amerequip.com@xxxxxxxxxxxx] On Behalf
Of Al Mac Wheel
Sent: Thursday, January 17, 2008 11:03 AM
To: BPCS ERP System
Subject: Re: [BPCS-L] Anyone ever experience a "decimal" problem?
We also have CD405.
We also have some "situations" that "some users" can "characterize" as a
"decimal problem" in their understanding of the logic.
We use yield, various BOM units of measure, where the "rounding" does
not recognize reality. Suppose we are consuming discrete units, but
allowing for 3% scrap. The rounding for the scrap might not be able to
make the distinction between FEET or INCHES valid any fraction, while
discrete UNITS or EACHES some fraction not make any sense.
When reporting scrap, BPCS assumes logic which may be contrary to how we
run our factories.
Suppose we have an order to make 1,000. We make 990 and have to scrap
10. The way we run our factory, we immediately make another 10, so we
have 1,000 to go to the next operation. We tell BPCS that we made 1000
and scrapped 10. But consider the timing of the labor reporting and
backflushing. If one labor ticket says we made 990 and scrapped 10,
then another later ticket says we made 10 more, BPCS might not accept
the 10 ticket because when the 990 and 10 went in, BPCS thought we had
reached the 1,000 goal, and that coded the shop order to be completed
and ready to purge.
When a part has several operations, with material consumed in operations
100 200 300 etc. and labor says we worked on a particular operation, or
scrapped at a particular operation, you want the backflush to consume
based on where the materials actually get used in the process. It is
very easy in engineering to make a mistake, and not specify in the BOM
which operation the material is consumed at.
So in comes labor saying we made some quantity at operation 200.
Backflushing looks up BOM to see what is consumed at operation 200.
Thus, if BOM for some part says stuff consumed, but operation not
specified, then you report all operations & none of them consume the
stuff that did not have operation specified in the BOM.
We have same items in different facilities with different cost
structures.
Manufacturing facility = manufactures the part ... it has labor,
material, raw material components from lower levels Distribution
facility = buy & sell the part ... its cost is material at this level If
you transfer a part from one facility to another, the cost structure
travels with the transfer.
So we have situation where we need to ship to a customer what we have,
which includes some from each facility. Someone transfers from one to
other, then ships lump sum, but now one of the facilities has costs
combined, all the different kinds, so the cost is doubled up, which
messes up the General Ledger cost of goods sold.
There can be errors in our BOM. I created various reports to list items
where the apparent cost of the parts meant we losing money ... cost to
make the part greater than sales price, or the profit margin extremely
slim. Management checked the parts out & concluded "no problem",
there's an error in the BOM ... it says we consume this expensive
component, when in reality this part is not consuming that expensive
component. They did not understand that the BOM needed to be fixed,
because BPCS was consuming the part in error, then MRP says we need to
reorder more of it. So come next physical inventory, we find we have $
XX,XXX excess inventory of the part that was in the BOM in error. Some
errors in engineering and reporting can lead to other kinds of hassles.
Some BPCS software does a good job in handling float, where transactions
processed in sequence other than what happened in reality, so fields go
negative temporarily. Other BPCS software does not handle this so
gracefully.
Some BPCS software does a good job in handling values with various
decimal places, others not do such a good job.
We originally found the problem, described below, in billing, where the
rounding was sometimes off by a penny. I tracked the bug to how it was
handling sales unit of measure conversion. Even though we did not have
any sales unit of measure other than same as stocking unit of measure,
"extreme values" were killing us thanks to BPCS making no provision for
work areas.
There are bugs that come with BPCS. Rounding in CST600 and CST900 has
systemic problems because of heavy use of fields like
XXX,XXX,XXX,XXX,XXX.XXXXXXXXX with no provision for work areas. The IBM
programming manual warns of unpredictable results when "extreme values"
(like one or zero) are mathed through this ... the result can be that
one plus one equals 2.00001 or minus 0.00001 and once when we should
have got a result of something like 1.00000 we got a result of negative
999,999,999,999,998. I don't remember the decimal places.
Consequently we are constantly getting cost buckets that do not add up
with precision, and costs added with wrong facility ... costs do not add
up right for some programs when items have both facility and missing
facility costs.
We had an outside consultant develop some modifications for us, where
they brought in some people who did not know BPCS. These people thought
item number, customer number, delivery ticket number, etc. meant
numerical field, so their software treated those fields like numbers.
Well we can have alphabetical characters in item number, shipping ticket
number, warehouse location number, etc. so when those characters got
copied to the consultant software fields then run the programs, we get
decimal data error, meaning alpha data in a field supposed to be numbers
only.
Don Cavaiani wrote:
My users here tell me that for years now there has been "some kind of a
decimal problem" in the BPCS logic (CD405 vers). In one of the
programs - parts issued or in backflushing of parts issued, certain
part numbers come out with an odd decimal qty. used which is incorrect
and must always be adjusted.
Any clue what they are referring to?
TIA
Don
Don F. Cavaiani
IT Manager
Amerequip Corp.
920-894-7063
"It's amazing what you can accomplish if you don't care who gets the
credit." Harry S. Truman
--
This is the BPCS ERP System (BPCS-L) mailing list To post a message
email: BPCS-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list
options,
visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/bpcs-l.
Delivered-To: macwheel99@xxxxxxxxxx
--
This is the BPCS ERP System (BPCS-L) mailing list To post a message
email: BPCS-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list
options,
visit:
http://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/bpcs-l.
Delivered-To: dcavaiani@xxxxxxxxxxxxx
midrange.com
