Re: Drop Ship & Purchase Orders

Al Mac plinking at parts of your problem & hopefully providing SOME info that 
was not already obvious to you.

You have several challenges here.
Identify all that is messed up, and force some fix so you can end fiscal 
month.
From the evidence you found, deduce what if anything else messed up by this & 
fix the consequences of the corrupted data being processed through your 
system.
Back track what caused the original problem so as to prevent it happening 
again.
Document how you fixed it, so if it happens again, you do not forget nuances.

As for how could this have happened, MIS needs to bend over backwards 
diplomatically with the people who do the transactions in hopes of getting at 
truth.

Scenario ... you in the middle of doing some BPCS task & you PC pops out on 
you - how do you recover the BPCS task with assurance no harm done?

Possible answers

It never happens.
We have no idea.
We reboot the *$#* PC & return to the menu option where we started the 
interrupted BPCS task & start over & hope for the best.
We carefully restart the work from a different PC work station session 
address & tell ____ (MIS person) which one is suspect & when they have 
finished checking it out they tell us when it is safe to use it again.
We call _____ (MIS designated power user help desk person) & they do whatever 
"magic" (SYS993 etc.) to clean up BPCS so it is ready for use to start over 
cleanly.
Well normally we do .... but there was a new gal doing it yesterday & 
something went wrong & we have no idea what happened.
We get these error messages & we forget to write them down & then we forget 
what they were.
We have been having this problem, which may be related, .....

DMunro@badgerminingcorp.com writes:

> Or any clue where the negative 29 comes in for the line number?

We have weird stuff happening to some of our data
(e.g. negative previous cost level)
and in another thread someone suggested journalling file(s) that get messed up
then check journal records to document arrival of garbage
nailing down program & circumstances
delete journal records rapidly so as not to eat precious disk space
I have not yet started doing this
This approach might help you find where this mess comes from if it turns out 
not to be isolated incidents
but it does not help with cleaning up messes already created
  
>  Any clue how it can count right & get to 40 

I believe that several programs read the next sequential line # & do not care 
if some are negative ... a small negative number is a larger number than a 
large negative number, so your data is read in correct consistent fashion, 
except for the duplicate zero lines.  However, many programs start at some 
valid anticipated line # ONE & miss the unanticipated.

>  & leave the last 15 po detail records unsequenced?

The fact that a field that I consider to be part of a KEY is in fact ZERO
and has several such records - this tells me several things

a) You may have duplicate keys from perspective of some programs
    which means those programs can only access one of the records

b) Some programs start accessing some file by setting all values 
    except sequence field, then read forwards numerically
    which means they"ll get the minuses, then ONE of the zeros
    then the correct stuff

c) Some programs same as above except start sequence field at ONE
    so they will skip all the minuses & the zero records

MacWheel99@aol.com (Alister William Macintyre) ... "Mac Wheel" is a play on 
my surname ... my job title is also twisted by in-humor
BPCS 405 CD Rel-02 Data Janitor on 400-170 OS4 V4R3 (pre-IBM e-Server 
i-Series 400)  @ http://www.cen-elec.com Central Industries of 
Indiana--->Quality manufacturer of wire harnesses and electrical 
sub-assemblies - fax # 812-424-6838

---

• Subject: Drop Ship & Purchase Orders
• From: Dennis Munro <DMunro@xxxxxxxxxxxxxxxxxxxx>
• Date: Wed, 22 Nov 2000 14:29:21 -0600

AS/400 V4R4M0 - behind one set of ptf's from the current set, groups & cum -
BPCS ver. 6.0.02 plf, full client/server, Mar'98 cum

When entering drop shipments, I have one order whose corresponding HPH/HPO
have invalid field contents & I cannot get to the order to finish the
billing process.  The po was receipted, a few lines here & a few there so
they never noticed the extra lines?????

I am comparing a "good" order & po set to the set "bad" I am having trouble
with.  They both are to the same customer/ship-to/item - just different
dates.

The "good" HPO purchase order detail contain the correct number of lines,
which is 40 & they are numbered 1 through 40.
The "good" HPO field PBUYC has a "7" & field PCLIN has "001".

The "bad" HPO purchase order detail contains an incorrect number of lines,
which is 55 & they are numbered 1 through 55.
The "bad" HPO field PBUYC has a " ".
The "bad" HPO field PCLIN has negative "029-" for order line 1.
The "bad" HPO field PCLIN has negative "028-" for order line 2.
The "bad" HPO field PCLIN has negative "027-" for order line 3.
The "bad" HPO field PCLIN has negative "026-" for order line 4.
The "bad" HPO field PCLIN has negative "025-" for order line 5.
The "bad" HPO field PCLIN has negative "024-" for order line 6.
The "bad" HPO field PCLIN has negative "023-" for order line 7.
The "bad" HPO field PCLIN has negative "022-" for order line 8.
The "bad" HPO field PCLIN has negative "021-" for order line 9.
The "bad" HPO field PCLIN has negative "020-" for order line 10.
The "bad" HPO field PCLIN has negative "019-" for order line 11.
The "bad" HPO field PCLIN has negative "018-" for order line 12.
The "bad" HPO field PCLIN has negative "017-" for order line 13.
The "bad" HPO field PCLIN has negative "016-" for order line 14.
The "bad" HPO field PCLIN has negative "015-" for order line 15.
The "bad" HPO field PCLIN has positive "001" for order line 16.
The "bad" HPO field PCLIN has positive "002" for order line 17.
The "bad" HPO field PCLIN has positive "003" for order line 18.
The "bad" HPO field PCLIN has positive "004" for order line 19.

 and etc. through line 39

The "bad" HPO field PCLIN has positive "025" for order line 40.

For  purchase order detail records 41 through 55, PCLIN has a -0-(zeros) in
the field.

The "bad" ECH field HSTAT is an "E" (have not found a list of valid codes) &
the "good" ECH has a "7".
The "bad" ECL field LSTAT is an "E" & the "good" ECL has an "8".

Any clues as to what I need to do so I can complete the drop ship process?  

Or any clue as to what the operator may have done to give us our mess? 

Or any clue where the negative 29 comes in for the line number?

Any clue how it can count right & get to 40 & leave the last 15 po detail
records unsequenced?

Rather confused this day before Thanksgiving here in the States & I was
trying to end the week without any more problems????

I hope the abover makes sense because I'm not sure what we need to do to
rectify this error before month end.

Dennis Munro

"I love deadlines.  I especially like the whooshing sound they make as they
go flying by."  Dilbert's Words Of Wisdom:

Badger Mining Corporation
www.badgerminingcorp.com
dmunro@badgerminingcorp.com
(920) 361-2388

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

---