we're on version 6.04 but i'm nowhere near the 99% level. we seem to have a 
problem after we run CST900. it purges orders but then there is always a 
complaint that mfg can longer post transactions to the order after it has been 
purged.  this implies to be that there is no logic within the purge programs to 
insure that all transactions have been posted. and then again, how could it 
know if all transaction have been posted?

chick doe
barton instrument systems

>>> MacWheel99@aol.com 04/13/01 10:04AM >>>
One of our factory managers asked me the other day

"Al, can you 100% positively assure me that BPCS will not close shop orders 
for purge until all of the neccessary inventory transactions have been 
posted?"

Perhaps someone here can pass on some information that will improve my reply.

My reply was 

1. I am 99% certain that if an order has not had all of its sub-components 
consumed that are needed to make the order, that it will not get closed for 
purge by BPCS 405 CD, 
which is vastly superior to BPCS/36 in this respect, 
even if a human being has posted labor saying all operations are done, 
but I will have to do some research to be 100% sure of this. 

2. A strong argument in favor of this notiion - 
you may remember a couple years ago when we shortened the retention of ITH 
inventory transactions to like 90 days, 
then we discovered that shop orders that had been open for over 90 days would 
not close, 
because CST900 shop order purge uses the ITH data to calculate if all of the 
inventory has been posted, 
but we had gotten rid of some of the ITH data that the older orders needed. 

If they would not purge because they lacked the ancient inventory history, 
then it only stands to reason that current orders will not purge if they lack 
inventory history that has not been posted yet.

3. However, we all know that we have been having intermittent mispostings due 
to some mishaps in resolving JIT620 colliding with other inventory updates, 
and also some use of improperly configured PCs that were not noticed fast 
enough to avert bad data going in, which sometimes results in doubled up 
inventory postings.  Obviously if an unfinished shop order has excess 
inventory posted against it, then that order might close prematurely.

But the way to solve that problem is to eliminate the intermittent problems & 
I have been working on that & it is going too slowly for my tastes, but we 
are making progress.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)


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

This thread ...


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

This mailing list archive is Copyright 1997-2020 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].