Re: A/P Check Payment SNAFU

***** Warning ***** Long post here.

I recognize it, but may not have a good solution, because of a myriad of
complications that I try to illuminate in this post. Especially since it
has been several years since last time we encountered this particular kind
of mishap.

It may be helpful for you, if I was to send you a copy of my FIX OOPS
document off-line. FIX OOPS is an SEU PDM member I added to BPCSDOC, that
lists everything that possibly could go wrong, that we have encountered, and
figured out what to do about it. The scenarios are sequenced by a brief
statement title of nature of perceived problem, or program name where messup
happened. Solution write-ups assume the person trying to fix might have
minimal know-how associated with the techniques needed.

I looked in there, did not find much to help this scenario.

Cut & paste from there:

41900 1. Person-A is on the ACP600 screen where check ranges selected.
03/02/01
42000 2. Oops, Someone killed that job or ended it abnormally.
03/02/01
42100 3. Try to get back in & get the error message
03/02/01
42200 "Company currently being processed" (where Person-A WAS)
03/02/01
42300 4. Solution
03/02/01
42400 CHGDTAARA DTAARA(*LIBL/SSAACP) VALUE('')
03/02/01
42500
03/02/01
42600 DSPDTAARA DTAARA(SSAACP) shows a LONG data area
03/02/01
42700 Y in position 1 means company 1 is being processed
03/02/01
42800 Y in position 2 means company 2 is being processed etc.

In 405 CD, there are work areas named using a combination of the first 6-8
characters of work station id and a handful of letters in front that
designate what application or program is running.

Some work areas end up as members of key files, with same layout as the
files, but containing the data that the work station user intends to post,
and can modify the contents before conclusion. Thus, if a job gets
interrupted, then user returns to it, we have the phenomena of messed up
prior input intermingled with new input.

I suggest using *OUTFILE from List BPCS files to identify which files have a
count of more than one member, and vintage of those named other than same as
the file itself, with other than zero records.

There's also a data area, which keeps track of which step the user is at, in
a series of steps. SYS993C is the program in 405CD to reset this to a
particular check point. Note that A/P is not on the list for 405 CD. Not
all programs have this particular repair made easy by BPCS.

You may want to list these data areas, to see which are susceptible to
manual repairs outside of SYS993C focus.

OBJTYPE(*DTAARA) and DETAIL(*BASIC) within DSPOBJ of wherever your BPCS
files etc. located. I wrote an RPG to compare each to the next to highlight
major differences in contents.

Some of the info, associated with some program, might be stored in
parameters, or local data area, whose contents will be lost if the work
session is killed then restarted.

There's also the phenomena of something "in use", where a cluster of
programs might need to access something, and keep other programs and users
out of that customer order item facility whatever until the task has
completed. If the task gets disrupted, then we miss the end of task step to
reset the "in use" flag(s).

If the user remembers details from immediately before the crash, and if you
are familiar with the files, then DFU can quickly fix this. Otherwise you
may need QUERY to list everything that is in-use, and some mass fix.

I have a cheat sheet on "in use" scenarios ... cut paste from there (I can
e-mail it to you off-list), for example:

. HPH is the header physical file that contains the "in use" flag for
purchase orders. The value "1" means the order is currently "in use".
Change this to blank or zero to say that it is not "in use".
. HPHL02 is a logical access to HPH file that works great when fixing
"in use" via DFU.

Most users today are via PCs, which can be subject to dropping connection
with the 400-I in the middle of a BPCS program, or various other mishaps.

Everyone who works the company should remain aware of what factors
contribute to such disconnections, such as bad weather, time of day, numbers
of concurrent users in particular programs, other uses of corporate
telecommunications. This to avoid running certain types of programs during
times of high risk, avoid having fragile software building large batches,
without good "saves".

There also should be check lists in place, how to recover from the different
kinds of mishaps, to minimize incomplete recoveries, and people at
cross-purposes.

At the instant of failure, an interactive program could be trying to update
a bunch of files, in sync with each other, so now we have partial updates,
where the files are not in sync with each other, with respect to whatever
the user was doing.

A common problem is for the 400 to believe the session is still active,
while the PC thinks the session is broke, so when the user tries to sign on
again, they are told, that session side is in use, with a total lack of
meaningful error message scenario. Ideally, we want the 400 to remember the
lost session long enough for the user to get back there, then immediately
take their work session to a menu, which will reset flags and save totals.

For most programs, it is Ok to kill the job, restart from scratch. This
won't work for a lot of accounting, labor ticket input, shop order launch,
shipping. IT should be familiar with which applications need more recovery
effort, and which menu options to use for the different kinds of resettings.
In some cases, modifications may have been needed to support this. On our
system, I have copied all such reset options to a consolidated menu FXS.

-
Al Mac
-----Original Message-----
From: bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx] On Behalf Of Don
Cavaiani
Sent: Wednesday, May 12, 2010 1:30 PM
To: bpcs-l@xxxxxxxxxxxx
Subject: [BPCS-L] A/P Check Payment SNAFU

Below is the description I asked our Payables Supervisor to phase - in hopes
that someone on the list would recognize this issue:

What happened yesterday is when I got the invoices ready for payment and
everything matched up I go into ACP650 to make payments: The bank 001 has
the correct $ amount to use and agrees with my report. I fill in Bank 001
and hit enter it goes to ACP650-03 at this screen it should say 170 numbered
produced and the amount of payment should be $467033.31.

But when I entered my series of check numbers into the number range area my
computer lost connection. I explained to you that I could not get out of
that screen because I may lose everything. So I then tried to call it back
to re-enter it and it was locked (IT next changed the data area to unlock
it).

So I went out there again and when I call up the ACP650 and the first screen
is correct, but when I enter to the next screen it comes up with different
amount of checks. One time I did it came up to 165 checks, and I re did it
and it came up with 168, and I tried again and it came back with 165 and
the dollar amount also changes from $20,506.68 off at the 165 checks, and
$3817.53 off at the 168 checks.

I have not allocated any checks yet so the check run is not allocated at
all. It would not let me allocate if I wanted to because the amount of
checks I have is at 170 and the screen only shows 165 or 168, so the it
would not zero out. And if it did let me for some reason the check numbers
would be off from what the checks were given to the invoices. I hope this
helps!!!



Don F. Cavaiani

Amerequip Corp.
920-894-7063

"Only one who devotes himself to a cause with his whole strength and soul
can be a true master. For this reason mastery demands all of a person."
Albert Einstein