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



Al,
There may be a couple other reasons for this condition. Dont know if they apply 
to your situation. No mention of DRP but if any items are setup for DRP they 
would not be processed in your scenario. If the policy code is blank they will 
not be planned. If your BOM has any mixture of MRP, MPS, DRP at alternating 
levels you would have to run the planning programs more than once to push the 
result all the way thru the structure. For example, an MPS end item with MRP 
subassemblies and MPS purchase components would require a second iteration of 
MPS to get the purchase items planned and cleared correctly.

Regards
Larry


In a message dated 11/1/2004 11:30:01 AM Eastern Standard Time, Daniel Warthold 
<daniel.warthold@xxxxxxxxx> writes:

>
>
>Suggestion: why not query on ITH for items with no activity since a selected
>date?
>We are not sure how CIC.ICACT gest flagged by other various BPCS
>transactions. I would prefer make my own "activity" flag  using my own
>criterias. You could add to the list of items with no activity from ITH,
>items with no forecast, no open ECL, etc. as per your preferred criterias.
>
>
>Daniel Warthold
>
>
>-----Original Message-----
>From: Alister Wm Macintyre [mailto:macwheel99@xxxxxxxxxxx]
>Sent: Sunday, October 31, 2004 16:01
>To: BPCS_L discussion
>Subject: CIC.ICACT
>
>
>
>Under what circumstances would this field still be "Y" after all facilities 
>have had MRP500 MRP600?
>
>My understanding of the field is that any action to any item in a facility 
>that would impact MRP or CAP, such as change to customer orders, change in 
>inventory, change in BOM or Routings, tha causes this flag to go on, then 
>when MRP full regeneration is completed, the flag is off again.
>
>Right before End Month, I did do MRP500 MRP600.
>Right after End Month, we had 18,000 CIC records with ICACT 'Y' ... I was 
>surprised that End Month jobs would flag MRP needed, so I ran it all 
>again.  I noticed that after MRP500 but before MPR600 on one facility that 
>the count rose to 23,000 telling me that MRP500 probably flags children of 
>relevant master scheduled items as needing attention.
>After 100% facilities had MRP500 MRP600 we had 1,000 records in CIC still 
>with ICACT 'Y'
>
>I recognize some of them as samples and pilots where we have activity 
>before the engineering is completed, but far too many items in the 
>condition of ICACT 'Y'
>I am wondering if some are master scheduled engineering orphans, children 
>of parent items such that there is no way for MRP to get to them, so they 
>get flagged but never reached.  For example, perhaps there was activity 
>right before an engineering change that made a sub-component such that it 
>has no parents any more.  We might have conversion artifacts that became 
>"Y" permanently.  I am just trying to get a handle on all possible reasons 
>... I suspect most of these items are some kinds of data errors we ought to 
>clean up.
>
>The reason I got interested in this field.
>We want to identify whether we have dead inventory ... such as children of 
>customer parts whose orders have dried up.  Perhaps Safety Stock needs a 
>review, but on which items?
>Most reports that list cost variances, items in more than one facility 
>whose costs inconsistent, etc. list all items that have ever been 
>engineered in a facility.
>We have people who only want to be researching items with cost 
>discrepancies when we have on-hand or those items are recently active, so I 
>been looking into fields that define activity, that are relatively easy to 
>combine in query/400.  Since CIC has standard & actual cost by item by 
>facility & also this field, it seemed like a good choice, except I thought 
>it meant only those items active today, since we do MRP500 MRP600 every 
>evening.
>
>-
>Al Macintyre  http://www.ryze.com/go/Al9Mac
>Find BPCS Documentation Suppliers 
>http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html
>BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/
>Replacement company web site (same company, new 
>domain)  http://www.globalwti.com/
>_______________________________________________
>This is the SSA's 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: daniel.warthold@xxxxxxxxx
>_______________________________________________
>This is the SSA's 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: cfgwizard@xxxxxxx
>

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.