Subject: Re: Anyone ever experience a "decimal" problem? From: Al Mac Wheel Date: Thu, 17 Jan 2008 11:02:35 -0600 List-archive: List-help: List-id: BPCS ERP System List-post: List-subscribe: , List-unsubscribe: ,

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

As an Amazon Associate we earn from qualifying purchases.