Receipt Transaction in Process Error

Chris Kelleher

Administrator
Staff member
We have been seeing an increase in receipt in process error messages. We
know that this is due to records stranded in the lotw_wkfl table but are
boggled as to why these records are getting stranded. A call into support
when we first started seeing this led us to a patch to the PO receipt
programs which has been applied but we are still seeing this error and in
fact have seen the numbers of it increase.

The actual message received when trying to change the inventory detail of
the lot is "receipt transaction in process".

any one have any ideas?

thanks

barry


Barry Kling
Lead Systems Analyst
Genzyme Corporation
(508) 270-2154
barry.kling@genzyme.com www.genzyme.com
 

Chris Kelleher

Administrator
Staff member
Unfortunately, lotw_wkfl records (and sr_wkfl) get stranded all of the time
(depending on your version of Mfg/Pro). Typically, it happens when
(1) the user uses END-ERROR (F4/ESC) to back out of a process from the line-entry level
(2) the user presses CTRL-C while entering lines.
But in a few cases, it can just be the normal result of using a program. Of course, even END-ERROR should clean up the data. QAD had tried to track these all down, but any given release might still have some of these bugs. In v85E we even had a problem where shipping entry would pick up serial numbers previously stranded by some other process and ship them!

My recommendation is that you write a wrapper for gpwinrun.p that checks for stranded workfile records both before and after gpwinrun.p is executed, and logs any strays that it finds. The wrapper can also capture CTRL-C and clean up workfile records then.
(gpwinrun.p is called by the menu to launch all processes)

David Takle
Software Consultant
Find First Consultant, Inc.
 

Chris Kelleher

Administrator
Staff member
Note that gpwinrun is used in GUI MFG/PRO, and gprun is used in character
MFG/PRO...

Scott
===============================================================
Scott M. Dulecki /* 1998061901 */ +1 616 975 6322
Product Manager scott_dulecki@qad.com
QAD, Inc. http://www.qad.com
1188 East Paris SE Grand Rapids, MI 49546 USA

Next Michigan Progress Users Group: 19 January 2000

All opinions are my own, and don't necessarily reflect those of
any other living being.
===============================================================
 

Chris Kelleher

Administrator
Staff member
Actually, gpwinrun.p is also used in character mode.
It is called from mfmenu.p (via gprun.i),
and it in turn calls the item selected in the menu.

David Takle
Software Consultant
Find First Consultant, Inc.
 

Chris Kelleher

Administrator
Staff member
David,

Once again, it seems I look before I leap. Thanks for the refreshing dose
of reality.

Scott
===============================================================
Scott M. Dulecki /* 1998061901 */ +1 616 975 6322
Product Manager scott_dulecki@qad.com
QAD, Inc. http://www.qad.com
1188 East Paris SE Grand Rapids, MI 49546 USA

Next Michigan Progress Users Group: 19 January 2000

All opinions are my own, and don't necessarily reflect those of
any other living being.
===============================================================
 

Chris Kelleher

Administrator
Staff member
THis is interesting but the lotw_wkfl table has no record of which programs
the user was using so it is next to impossible to see what the underlying
cause is (which is really what I am trying to figure out). The best we can
tell is that it is in the work order receipt process since the only parts
impacted seem to be final level finished goods from work orders.

Barry Kling
Lead Systems Analyst
Genzyme Corporation
(508) 270-2154
barry.kling@genzyme.com www.genzyme.com
 

Chris Kelleher

Administrator
Staff member
I would still recommend the wrapper for several reasons:

(1) the log will positively identify what application (menu-level) is leaving the workfile records stranded. Note that even if the specific dot-p that created the record recorded its name in the record, you still wouldn't know why it got stranded, only why it got created (which would be, "the application requires us to keep track of serial numbers and lots").

(2) automatically cleaning up the records will eliminate or greatly reduce the "receipt in process" error messages that you were getting. While this doesn't solve the underlying problem, your users are a lot happier.

(3) you can find out if your users are pressing ctrl-c (it logs as "ERROR" type)

(4) if you monitor the log file, you may be able to get back to the user who orphans the records in a short enough time frame that the user can remember what keystrokes were different than usual (helping you identify the cause).

David Takle
Software Consultant
Find First Consultant, Inc.
 

Chris Kelleher

Administrator
Staff member
My recommendation is that you write a wrapper for gpwinrun.p that checks for stranded workfile records both before and after gpwinrun.p is executed, and logs any strays that it finds. The wrapper can also capture CTRL-C and clean up workfile records then.
(gpwinrun.p is called by the menu to launch all processes)

A word of caution about writing a wrapper for gpwinrun.p.
gpwinrun.p is also called when you press HELP or F6 User-Menu.
So you want to test the originator and *only* cleanup workfiles if called directly
from the menu. Otherwise, you will mess with your main application.
The wrapper looks like this (roughly):

<BLOCKQUOTE><font size="1" face="Arial, Verdana">code:</font><HR><pre>

/* gpwinrun.p (wrapper for original version) */
DEF INPUT PARAMETER run-pgm AS CHAR.
DEF INPUT PARAMETER run-title AS CHAR.
IF INDEX(PROGRAM-NAME(2), "mfmenu") GT 0
THEN RUN Clean-up-work-files ("BEFORE").
run-block:
DO ON ERROR UNDO, RETRY
ON STOP UNDO, RETRY
ON QUIT UNDO, RETRY:
IF RETRY THEN DO:
IF INDEX(PROGRAM-NAME(2), "mfmenu") GT 0
THEN RUN Clean-up-work-files ("ERROR").
LEAVE run-block.
END.
/* run the original gpwinrun.p and pass it the same parameters */
{gprun.i ""gpwinrun-orig.p"" "( run-pgm, run-title )" }
END.
IF INDEX(PROGRAM-NAME(2), "mfmenu") GT 0
THEN RUN Clean-up-work-files ("AFTER").

PROCEDURE Clean-up-work-files:
DEF INPUT PARAMETER pTiming AS CHAR.
[ scan workfiles for records owned by 'mfguser'
if any are found, delete them and append a message to
a flat-file log indicating date/time/global_userid,
the run-pgm variable and the pTiming variable
]
END PROCEDURE.
[/code]

The log can help you identify which programs are mis-managing the workfiles.
If you have source, you can fix them. Otherwise, you can try QAD.
(Also, more research should be done to see if the 'qaddb' alias can be left
assigned to an incorrect database when the user presses CTRL-C)

David Takle
Software Consultant
Find First Consultant, Inc.
 
Top