RE: Failed GLUPDATE Job (originally subject was erroneously "RPG Question")

Richard,

We eventually worked with Carl @ GEAC who worked with us (almost all day) to 
resolve this.  Your solution was almost exactly what we did.  The exception was 
that we first posted a reversal of the 4 lines (of the 37,000 possible) that 
had posted, and in OEP65 all we had to do was blank out GLUP65.  We didn't have 
to set the print flag.  We also had to flag the original GL session (the failed 
one) as cancelled.  We print about 3000 invoices a day and they are being 
printed on demand, so we knew that within seconds of our updating the GLUP65 
flag, an invoice would be printed. We then, also, had to do an invoice post and 
then run the AFI, and restart the GLUPDATE background job.  Doing all this has 
seemed to fix the problem and get us back to where we were.

Carl was terrific, by the way, he stayed with us throughout the day as we 
checked and double checked each step as we proceeded.  Great support from GEAC 
in this case.

==Kevin Brunk (for Donna!)

 

-----Original Message-----

From: system21-bounces@xxxxxxxxxxxx [mailto:system21-bounces@xxxxxxxxxxxx] On 
Behalf Of Richard_Caldicott@xxxxxxxxxxxxxxx

Sent: Wednesday, September 08, 2004 10:46 AM

To: System 21 Users

Subject: RE: [SYSTEM21] RPG question

 

What concerns me here is the error that was creating the error report. My guess 
is that it is the same one repeated multiple times. Do you know what the error 
is and what is the status of UPDNOG on FLP007? You may also wish to consider 
consolidating your AFI postings to create fewer FLP008 records per run. The 
other issue here is that your invoices have been posted to A/R - rerunning the 
AFI portion will mean that you could loose the link between A/R and OE, if you 
use it.

If you check everything out and decide to correct the data I would suggest 
SQLing the company code on both FLP007 & FLP008 to 'XX' (providing that isn't a 
valid company for you) - you can remove these at a later date. You should be 
able to access the FLP007 records by session but the FLP008 records probably 
need to be accessed with a range of DOCREFs and UPDNOG = 0.

After verifying that the G/L error you got before isn't a problem (or you fix 
the issue) and having corrected your AFI rules you can set the print flag on 
OEP65 records to 'S' and the GLUP65 to blank. If you then process a dummy 
invoice for $1, you should pull through the new extract. This will of course 
generate new invoice copies too which you will probably want to discard.

I haven't had chance to double check all these notes so you will want to RUN A 
TEST before trying this in live just in case I missed a setting.

Oh, and I'm still concerned about the G/L error....................

Richard Caldicott

Director of Implementations

& Efficiencies

Tandy Brands Accessories

817-548-0090 extn 146

 

"Thomas, Donna" 

<DThomas@wabutler. To: "System 21 Users" <system21@xxxxxxxxxxxx> 

com> cc: 

Sent by: Subject: RE: [SYSTEM21] RPG question 

system21-bounces@m 

idrange.com 

09/08/2004 09:02 

AM 

Please respond to 

System 21 Users 

 

 

 

I'm wondering if anyone has ever had to recover a failed GLUPDATE job?

We update our invoices in GL using AFI, which is driven by posting rules in 
FIP45. On 9/7/04, the AFIGLUPDAT job produced a 13,000 page EXCEPTIONS - 
DEFAULT ACCOUNT POSTINGS report (FI551PT3). The error message was ' Rule not 
found'. We have since determined that the AFI posting rule in our FIP45 records 
is no longer on the system because a new newly numbered rule has been made 
effective. The FLP008 records were created with the actual account as the GL 
account number, but when background job GLUPDATE tried to process those FLP008 
records, the program GL161, looped and produced a spool file so large, it 
caused a critical storage warning on our system. There are approximately 130,000

FLP008 records that have this problem that haven't been processed by GLUPDATE.

The UPDNOG (Update Number General Ledger) is still 0 for the FLP008 records in 
the session, which leads me to believe general ledger accounts have not been 
updated with this information. Is that correct?

I'm trying to determine how to recover from this. I am thinking of deleting the 
FLP008 and associated FLP007 records for this session and then updating the 
FIP45 records to use the correct AFI posting rule, re-running the AFIGLUPDAT 
and seeing if the new FLP007 and FLP008 records would process through the 
GLUPDATE job. Will this recovery work?

If not, how do I recover this?

We are using version 3.5.0b of System 21, if that matters.

== Donna Thomas

The Butler Company.

==Kevin Brunk
The Butler Company
5600 Blazer Parkway
Dublin, OH 43017-7545
TEL: 614-659-1666
FAX: 614-659-1667
 


**********************************************************************
CONFIDENTIALITY NOTICE:  The information transmitted in this message is 
intended only for the person or entity to which it is addressed and may contain 
confidential and/or privileged material.  Any review, retransmission, 
dissemination or other use of this information by persons or entities other 
than the intended recipient is prohibited.  If you received this in error, 
please contact the sender and destroy all copies of this document.  Thank you.  
The Butler Company
**********************************************************************