Billing Shipping 405 CD Klutz Compounded -- BPCS-L

From Al Macintyre

We have stumbled into some serious mixtures of messes, and I attribute the 
root causes to people need vacations & sometimes their replacement personnel 
are trained pretty much only in how to do the job when nothing goes wrong & 
are not able to cope effectively in various error recovery possibilities, and 
sometimes we have sudden surprise employee turn over in knowledge worker 
tasks where entirely too much corporate memory resides exclusively in the 
mind of the worker who is no longer with us.

My feeble attempt at stating short specific questions:

1. When someone picks an order line for partial shipping, then ships, then 
before the shipment has been billed they pick the same line for another 
future partial shipment, which prevents the first billing from concluding, 
can they in fact back out the second picking & not mess up anything else 
until the billing gets finished?

2. Does BBL & the ES files get populated from each pick then ship, so that if 
the same order line got shipped twice in the same day, or in two consecutive 
days, the billing would reflect the dual shipments, once the line no longer 
in picked status?

3. Picking Shipping Invoicing in concert updates customer Orders to reflect 
requirements satisfied and updates Inventory to reflect production has gone 
away, and posts to the Receivables.  If some output from a facility is in a 
condition between two of those steps (Picking Shipping Invoicing) for several 
days while we are trying to do klutz repair, can we be assured that the 
requirements & inventory were updated in sync so that we are not lying to the 
MRP Production Planning requirements for what is needed to get the next 
shipment of repetitive business on schedule?

4.  When we do an RAR RCM reorg off the reorg menu, does it in fact recompute 
what RCM totals from RAR records?   Or more importantly, what is not 
recomputed?

5.  When we have a billing crash & manage to repair the damage but forget to 
reset the work station involved & run more billing from the crashed work 
station, can we be reasonably sure that the only place containing corrupted 
data is the duplicated invoice generation in to the RAR file, which 
fortunately are easy to find because the invoice numbers are negative 
numbers?  In other words we have stopped GL post until we have this cleaned 
up & want to review which files we need to unmess with other than RAR data, 
then re-run reorg RAR & RCM to get the totals   I realize that the sales 
totals & shipping history will be off, but at the moment my main concern is 
with getting clean billing records to our customers, then minimizing any 
corruption of populating data going to GL.

6. Bogus invoicing creates ITH inventory history records just like valid 
invoicing.  Do I presume correctly that in wiping out the bogus invoices & 
making sure inventory and customer requirements are correct, any history 
showing on INV300 will only reflect running balance incorrectly beyond the 
point of this going kaput?  I am tempted to post a comment in the history on 
each of the shipped items involved to remind folks that here was where the 
inventory history was corrupted by the Summer Shipping Snafus.

7. We have thankfully found only a few invoices in which data from totally 
different shipments orders customers managed to get combined, which I think 
is due to the workstations not being reset & far too many people do not 
understand "Please stay out of Customer Orders until we tell you it is safe 
to get back in again"  I want to make a query to look at invoice data to see 
if there are any more like these that we may have overlooked.  Would SIL be 
the closest file BPCS 405 CD has to an image of all the data in lines that 
show up on our invoices?

8. There is an option to correct shipment documents then reprint them in 
corrected form, which we have not been using, except for a klutz scenario in 
which someone was using the reprint capability to create previously 
non-existant shipments & we only found out that they were not following the 
documented steps when they asked for a modification to simplify all the extra 
unneccessary work they were doing.

Can this alter past shipment & reprint story be run after the billing has 
been done on a shipment?  My thinking is that this might be the solution to 
the invoices that managed to merge multiple shipments ... kill those invoices 
& the associated BBL remnants, then regenerate the stuff off of the shipment 
redo option, or does it get some of its input from BBL & SIL both of which we 
have totally corrupted?

9. When we have corrupted data known to have been messed up by things that 
happened outside the normal flow of BPCS processing, such as using a work 
station corrupted from an earlier crash without it being reset, or someone 
turning off an in use flag when the order really was in use, are we better 
off deleting the unwanted records outside of BPCS?

When we know the data is wrong because of actions totally within the bounds 
of BPCS such as second picking after shipping before first billing, or 
shippers & biller communications that shipping will stop updating customer 
orders until billing reruns yesterday's remnants, then a shipping person 
ignores the agreement & slips in some more shipping anyway, are we better off 
fixing the results totally within the BPCS process?

This is assuming we are able to connect the dots between all the things that 
went wrong and the various causes of the messes.

10.  When there are aborted jobs & no one else is told that this happens, 
because the end user involved does not realize such notification is 
advisable, short of checking every possible combination of work station 
reset, is there some reasonably easy way to dump the work station status 
information so as to see which work stations are messed up for which tasks?

11. I believe that DISPLAY ACTIVE BPCS JOBS from 
http://www.precosis.com.au/piu1.htm
would be a life saver in coping with this kind of scenario, but I have not 
been able to convince the powers that be of this ... perhaps the way to fly 
would be to arrange a trial in which the trial starts when one of these 
messes start, then take it away from them ... this is also something so 
inexpensive that myself or a group of co-workers could chip in & buy it as a 
gift to all other co-workers.

What I really felt we needed this time around, even more than DSPBPSACT was 
DSPWHORDUS = Display Who is responsible for a specific Order supposedly being 
in Use.  

The reason for this notion is that we have some very knowlegeable users but 
not smart enough to understand all which jobs legitimately update customer 
orders & a lot of users with only the vaguest comprehension of what connects 
to what so that when a message goes to *ALL users asking who is updating what 
customer orders right now, some of the people updating customer orders ignore 
the message because they do not think this applies to them, and also some 
people in middle of some customer order & been called away from their work 
station on other important business, so they oblivious to latest crisis.

The data in ECH only says yes/no in restricted use, not what or who is 
actually connected to them.
The data in OS/400 LCK commands list all the people in the ORD applications, 
but not which orders they are updating.
I suspect that if I was to do a join of all the work station members of all 
the programs that update ORD files & access that data in read only format, I 
might be able to get a picture listing who all is messing with which orders 
right now, and put it in order number sequence so we could see which "in use" 
flags are valid & which are bogus, without being a disruptive influence on 
the people doing valid order update work.
Does that sound practical?

12. What combinations of fields contain identification of order lines that 
are in some combination of picking shipping invoicing DRP?

I know about the ECH ECL order status code ... what I do not know is how that 
interacts with wherever the DRP invoicing state information is stored.

We have managed to get a DRP order into invoicing state without it being 
shipped & I suspect it is part of the dual picking idiocy.

13. Have I overlooked any other nuance implied by the above tales?  This is 
one scenario where I really could have used the DSlick BPCS Reference Manual.

Al Macintyre  ���
MIS Manager Programmer & Computer Janitor of BPCS 405 CD Rel-02 running on 
AS/400 V4R3 http://www.cen-elec.com Central Industries of Indiana--->Quality 
manufacturer of wire harnesses and electrical sub-assemblies
+---
| 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
+---