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

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