Fwd: Finishing 405 CD Shop Orders

Chick

I have also heard that grievance, but I consider it to be part & parcel of a 
different misconception.

Do you always produce exactly the same quantity as the shop order calls for 
or is there sometimes overage or underage & scrap?

Let's suppose the order is for 500 & they produce 550 but not all at one time.
As soon as 500 has been reported against the order, it is coded as ready for 
purge.
As soon as you run a purge the order is gone.
You cannot post the last 50 against the gone order.

This is why we sometimes need to do shop order maintenance to increase size 
of shop order to actual needed, but production management not always know in 
a timely manner that this situation exists & needs repairs.

Let's suppose the order is for 500 & the JT600 reports 500 made & 5 scrap.
JIT620 can put that reporting on a DIFFERENT shop order for the same item & 
warehouse than we reported, because BPCS recognizes that we only needed 500 
reported to the order not 505, so it tries to spread the reporting around to 
other shop orders & in my opinion that part of the software is not real 
smart.  We have had cases where we end up with twice as much reported to one 
order than ought to be there & nothing reported on the original order.

Plus of course the users do not know this is going on.

They wanted to have it get posted to the order on the labor ticket.
They did not want it posted to that other order, for whatever reasons.
So now that other order is ready for purge & the one they reported on is 
still waiting for labor reporting.

I have a modification requiest in my pile to take the scrap out of the math 
that is used for this, because 95% of the time when the users not like the 
results, it is when scrap has pushed the quantity over the precipice.

I think it would have been a whole lot smarter for SSA to offer this as a 
SYS800 Yes/No option do we want this to be going on.

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

---

• Subject: Re: Finishing 405 CD Shop Orders
• From: "Chick Doe" <Cdoe@xxxxxxxxxxxxxxxxxxxxxx>
• Date: Fri, 13 Apr 2001 10:48:24 -0700

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

---