Re: [BPCS-L] Post Ship Billing 3.1 mishap

[Alister Wm Macintyre <macwheel99@xxxxxxxxxxx>]

I hope these clues are helpful.
It has been a long while since we had this particular mishap, but I 
remember the basics.
We used to have it happen all the time.

We are currently BPCS version 405 CD Release 2 with a mountain of Y2K fixes.
Our billing program steps are a bit different from your version.

See if you can get to menu SYS (You may need to be BPCS security officer to 
do this)
and see if Menu SYS has option 23 to another menu
and see if there is a program SYS993C
which we have copied to our own FXS menu for those options we have to use 
all the time

Here's what the first screen of that program looks like to us.

Select WorkStation for Data Area 
Reset                       Last


Select BPCS Function for data area 
reset                     Last

                                          1=Regular Billing 
(BIL500)
                                          2=Post Ship Billing 
(BIL600)
                                          3=Regular Shop Order Release 
(SFC500)
                                          4=Labor Ticket Posting 
(SFC600)
                                          5=Mass Shop Order Release 
(MRP540)
                                          6=Customer Order Picking 
(ORD550)
                                          7=Final Assembly Release 
(FAS500)


Thus, if you have this program in version 3.1
you would key in the identity of the work station side that was trying to 
do the post ship billing and option 2 below, then press enter.

You then get a list of the states of being that post ship billing steps can 
theoretically be at
and also you can reset where it thinks it is ... you not want that work 
station to be anywhere but at a menu when you futzing with this.

There is no harm done if you peek into what values currently exist for 
various combinations of work station and program listed here, then F12 or 
F3 exit without changing anything.

I figured out where BPCS stores this data area stuff, and created a program 
to dump all the contents and do RPG control breaks when one is the same 
kind of prefix but different content.
This is because when people session connections break, the people involved 
do not contact IT if it SEEMS to them that All is well.  But sometimes a 
crash means that there is garbage in the work flow that will cause another 
crash the next time someone tries to run that job from that work station.

Another nuance is that BPCS supplies a member of some file with the data 
that is to be processed by these various steps.  So if you have some crash, 
then try to recover, there is the risk that the population is still out 
there for that work member that has not been processed, then if someone 
rekeys what is to be done, or uses the SYS993C deal to get it "working" 
again, a later run will grab that earlier population and process it a 
second time.  This can complicate the mess.

You want to try to locate that work member, and see what population, if any 
is there.
It has been over a year since we had this particular mishap, so my memory 
is a bit foggy on details.

Now we have shipping get disconnected in middle of picking all orders on 
one customer, all the time.  So we tell everyone to get the heck off of 
BPCS customer orders, check GO CMDLCK to verify they done so, then run a 
program that forces 100% orders to not be in use.  I have a mirror program 
to do RMAs.

I found it useful to DSPFD dump BPCS file statistics to an *OUTFILE work 
file, then list those files which have multiple members, then go looking to 
see what they are called.

Basically there is some Billing Work File out there that has one member 
named after each work station that can do billing, or has ever done billing 
... a topic we have discussed in BPCS_L before with respect to cleaning up 
unwanted ones, from old work station names no longer connected.

This is all documented in the BPCSDOC file member SSALOG00 which I access 
via PDM.

> We are currently on BPCS version 3.1.  We recently had an occurrance
> whereby one of our sales persons had two sessions open in Mochasoft while
> attempting to do a post-ship. Somewhere during the process (I think
> BIL610) the connection to the host was lost.   Since then, we have been
> unable to print the invoice via BIL620.  When we do this, we get a msg
> that BIL620 has already ben submitted from this work station.  When we try
> to run BIL630 for the post ship register, we get an error to first print
> the invoice and then run invoice register.
>
> The spool file BIL522A is still out there, but there isn't an invoice#
> assigned, and it hasn't hit accounting.  Any suggestions would be very
> appreciated.  Thanks!
>
>  Jenny Carr
> PH:  417-532-7121 (main)
> jgcarr@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx