Re: Duplicate Invoice Number

[Al Mac <macwheel99@xxxxxxxxxxx>]

This can happen on BPCS 450CD with ONE person if they do not know how to 
respond to a crash.

Suppose you connected to the 400 via a PC and there is a power outage while 
you in the middle of some accounting update.  You hypothetical user have no 
idea what the proper recovery process is.  When the power back on again, 
you ignore the fact that you had this disruption, sign on again to a new 
work session and restart the same job, in which prior to the power outage, 
some work was in fact done, and BPCS has a data structure, and work members 
in various files named after your work session, containing evidence of 
partially done work, which you then are doing over again, resulting in some 
work done more than once.

Let's suppose it was not a power outage, just some glitch requiring the PC 
to be rebooted, or arrangement of stuff under the desk so that an 
accidental kick can nudge the power plug.  From the perspective of the end 
user, it appears to them that they are able to abnormally terminate a BPCS 
update job, then restart that same job, and it seems to go to an Ok 
conclusion, but some work got done in duplicate, that is not immediately 
obvious to that user.

Since they not know any problem, they may not make an effort to capture 
extra joblogs of their activity.

There can also be problems, if someone other than the billing person, is in 
midst of update of the files associated with billing, then their connection 
gets broken.  Remember that in this scenario, WKRACTJOB will not show you 
DSC jobs that are entangled.  You need to use WRKSBSJOB QINTER.

So what is the correct response?  Well first, people need to remember what 
BPCS task they were running when they got disconnected, and they need to 
know enough about naming conventions to know which is an inquiry, simple 
report, or an update program, and if update, what are the kinds of problems 
that can result from THAT update program getting disrupted, such as risk of 
duplicate postings, some in use flag, hung batch, and so forth.

We have a query that lists which customer orders currently have their in 
use flag on, and a second that does this for RMAs (member RETURN).  We know 
how to fix onsies with DFU.  However, there is a step in shipping in which 
they select the customer to be shipped, then get list of orders for that 
customer, and then pick which of those to be shipped, and if the shipping 
PC goes down right at the point where they select customer, then 100% of 
the orders on that customer are in use.  We get everyone off of all BPCS 
tasks which can update BPCS, then we run a program that does a mass update 
of all customer orders to not be in use.

SYS993 is needed to reset certain tasks such as BIL500 when the end user 
was in the middle of a series of steps, and they get disrupted, and need to 
restart.  SYS993 is found on the reset menu of SYS which we copied to our 
menu FXS for miscelaneous fixes because we not want many people able to 
mess with other stuff on the SYS menus.  Note that SYS993 needs to be run 
when the victim is at a menu, and we also need to do the in use fix.

SYS993 vanilla is SYS / 23 /21
ours is FIXS / 50
Also of relevance is SYS / 4

In addition, there are flags in BBL related to how far the process got 
before it bombed.  We added a few logicals to simplify the task of making 
repairs to the disrupted work in process.

We use GO CMDLCK when it is an ordinary case of a conflict with another 
user, other than the in use flag, to find out who is updating the same 
file, which we know from error message on bottom of screen, F1 there, or 
check the user's joblog while they still signed on.

GO CMDLCK option 8 ECL
If you get a blank screen, F6 then F5
scroll to locate activity of other than an inquiry (read only) nature
lock column with *SHRUPD means the person is running a program which can 
update the file
To the left of the *SHRUPD you have column showing work station of person 
who is currently running something that is updating customer orders

There can be an in use flag if someone else is updateing a customer order 
at same time as different user trying to bill earlier shipments on that 
order.  BPCS tells the ORD500 person that the order is in the invoicing 
state, which means it got shipped but not yet billed, and there is a way 
for the ORD500 person to take a command to force access to update the order 
anyway, which messes up the billing.

We have a process I call pre-billing, in which we run various reports 
driven by what's in BBL file to review what is about to be invoiced, to 
support any last minute corrections.  We have learned what can be corrected 
at that point, and what can not.

This topic is one of several we have added details about how to resolve in 
our FIXOOPS document added to the BPCSDOC collection, because when there is 
a long time between one instance of a problem and the next instance, there 
is a tendency to forget some of the nuances of what needs fixing.
> Hi Everyone,
>
>
>
> I have a BPCS Version 405 site that somehow manages to get duplicate
> invoice numbers on occasion - there is no relation I can see between the
> invoices ie they are for different customers, different items, different
> quantities etc etc.
>
>
>
> Is it possible that two users have accessed the invoicing process at the
> same time to grab the same invoice number from the data structure?
>
>
>
>
>
> Regards,
>
>
>
>
> Kylea White
> Technical Consultant
> KAZ Technology Services
> Switch: +61 8 6212 0100
> Fax:      +61 8 9225 6748
>
>
>
> Email     kylea.white@xxxxxxxxxxxxx
> Web      www.focalsystems.com.au
>
>
>
> A KAZ Technology Services Company - visit our website at
> http://www.kaz-group.com
>
>
>
>
>
>
>
>
> --
> This is the SSA's BPCS ERP System (BPCS-L) mailing list
> To post a message email: BPCS-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
> or email: BPCS-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/bpcs-l.
>
> Delivered-To: macwheel99@xxxxxxxxxxx

-
Al Macintyre  http://www.ryze.com/go/Al9Mac
BPCS/400 Computer Janitor ... see
http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html