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
midrange.com
