× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: NOT Whole Numbers of BPCS Inventory
  • From: "Christopher J. Devous" <cdevous@xxxxxxxxxxx>
  • Date: Thu, 14 Oct 1999 12:36:42 -0700
  • Organization: The Antigua Group

We had a problem with INV500, in our issue transactions, that relates to 
this.

When you create a shop order, the field MBOM in FMA is populated with that 
components' share of the parent quantity.

In our case, the parent item is a logo that we are putting on a shirt, and 
it's quantity is the total number of shirts.  The component line item is 
the shirt itself.

Suppose we are embroidering 4500 shirts.  The parent quantity is 4500.  The 
first component's quantity required is 25.  MBOM will calculate (25 / 4500) 
to .005555 (MBOM is 6 decimal places).

When you create the issue with INV500, it will calculate the issue quantity 
from MBOM: 4500 * .005555.

It will then issue 24.9975 shirts for that component line item.

I would not want to be the poor guy who has to wear .9975 of a shirt. 
 Might get cold.

So I modified INV500 to take MQREQ, regardless of what the MBOM calculation 
comes up with.  Of course, that might not work for you, but I think your 
only other alternative would be to modify FMA to have more decimal 
positions for MBOM to increase the level of accuracy.

Interestingly enough, there is a BMR in one of the FAS or SFC programs that 
references this problem, and proceeds to "fix" it by giving the program's 
work fields more decimal precision.  But the FMA field is never changed....

+-----------------------------------------------------
Christopher J. Devous
Director of Systems Development
The Antigua Group
mailto:cdevous@antigua.com
http://www.antigua.com

Warning:

All e-mail sent to or from this address will be received or otherwise 
recorded by The Antigua Group, Inc.'s corporate e-mail system and is 
subject to archival, monitoring or  review by, and/or disclosure to, 
someone other than the recipient.
+-----------------------------------------------------

On Thursday, October 14, 1999 11:42, MacWheel99@aol.com 
[SMTP:MacWheel99@aol.com] wrote:
> We have had an intermittent problem with materials that should always 
have
> whole numbers quantities, that people tend to discover by accident, when 
we
> really need the item, but due to errors of various kinds, our inventory 
went
> incorrect & we did not know it, and we would like to find & fix this sort 
of
> thing before it gets us in trouble.  I just created a report which 
calculated
> the on-hand for items whose Unit of Measure is EA ("each" should be
> individual units), moved the decimal portion to a field 3.3 decimal only, 
> then print only if that field is not zero & my report found 35 items, 
which
> we are working on auditing & fixing.  This is our latest in a series of
> reports that in aggregate can analyse every field in every file & tell us 
> various things wrong that need to be fixed, but in an ideal world we 
should
> have systems in place so that we would not have the errors in the first 
place.
>
> The older version of BPCS/36 had a deal where at some level like item 
class
> we could say that a category of items needed to figure their on-hand to 5 
> decimal places, or be in whole numbers, or some such rule.  Is there such 
a
> reality for BPCS 405 that perhaps we have overlooked?  If we were using 
such
> a business rule, then it ought to prevent BOM & routings creations that
> result in the kind of error found to have contributed to the first item 
we
> checked out ... we have labor transactions through JIT that are consuming 
> fractions of items that should come in whole numbers.
>
> Al Macintyre
> BPCS 405 CD on AS/436 V4R3
> +---
> | This is the BPCS Users Mailing List!
> | To submit a new message, send your mail to BPCS-L@midrange.com.
> | To subscribe to this list send email to BPCS-L-SUB@midrange.com.
> | To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner: dasmussen@aol.com
> +---
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.