Re: JIT transactions -- BPCS-L

First thing you do is look at ITE transactions that you have ... there is
an INV inquiry into Transaction Effects ... do you have an INV500
transaction in which you enter the parent item # and it automatically
generates CI transactions on all the children of that parent?  Make sure
your people know how to do that in the negative.

Perhaps we want to take this discussion off-line because we 405 CD users
are tiny minority on this list, but I think I given enough clues here for
someone to deal with this topic.

I have not actually done this, but considered it.

Reason being ... when something goes haywire, they want to fix it TODAY ...
no way am I going to figure out this program that fast ... and how often
does this mess happen?

Where I focused my programming attention was what causes JIT to go bonkers,
and as a result, we now have an incident perhaps once every 3 months, and
it used to be several every month.

Now that is a thread to explore some time, perhaps off-line, what all
causes a particular program to go bonkers, and what can we do about it in
practical terms.

If you check the layout of the ITH transactions and the layout of the FLT
transactions there are a couple fields that allegedly contain labor ticket
#, but in BPCS 405 CD only one of them is valid for us.  We do have some
queries in which we link the labor and inventory activity on the same
transaction.

When something goes bonkers, usually what happened for us was one update
run of JIT620 for one user, the update run got hung, there was an error
message with a choice of BAD IDEA, VERY BAD, or EXTREMELY BAD, and the end
user thinks Duh? and presses enter key, and it takes the default option
which is INCREDIBLY BAD IDEA.  This causes a string of programs to run
again, in which some types of transactions are duplicate posted, and some
just got posted once, then it gets to the same stick point (can't update
something because some record locked by some user screen in which the user
had to get up and go to the bathroom and is not back yet), so guess
what?  We had one incident where 1,000 transactions were extra misposted 3
times before user went to IT to ask for help.  Well one software
modification priority was to intercept that stuff before end user even saw it.

From the audit trails, you should know the first and last ticket number of
that batch.

Couple of caveats ... if you have people in two different facilities
entering JIT transactions, the ticket numbers will overlap, so if you want
to select all ticket numbers in some range to use them for some fix, you
also want to restrict based on facility the tickets were for.

Other caveat is that we are using more audit trails than BPCS supplies.
BPCS audit trails assume person doing JIT600 is an expert on production
control.
In real world we have a clerk doing it who is not such a person.
We added query/400 over WORK member of FLT file, and a few other
constraints to list contents of JIT600 batch with fields laid out just the
same way they are on JIT600 screen, so data entry person can rapidly scan
their input to see if anything obviously transcribed wrong before
finalizing the batch.

In the process we now know first and last ticket # of batch.  That info is
written on post it note attached to front of physical batch of tickets, so
that if some question later comes up about some input, we are able to
navigate to where the transactions are on the computer.

So, in theory, someone could write a program to simulate what JIT620 does
in reverse, in which the "input batch" consisted of FLT records in a
selected range of ticket#s.  I have not done this.

What we do instead is we run Query to identify what transactions need to be
reversed.
We do NOT use the CI transaction, instead we do a negative M I think it is
in which you put in the parent item being made, and it does the
transactions for all the components on that item, and we are doing it in
the negative.

With SFC600 you can do the labor side in the negative.

But you have to know what went wrong, so that you fix it correctly - you
can have 1/2 a batch that got posted, you can have labor and inventory
input out of sync.

Hello,

Does anybody have a way of backing out JIT transactions besides manually
reversing the 'PR' and 'CI' transactions. We are running on BPCS 4.05CD.
Any help would be most appreciated.


Thanks,
Glen Langston

-
Al Macintyre (macwheel99@sigecom.net via Eudora)
Al's diary http://radio.weblogs.com/0107846/