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