Bugs in 1099 program P04515

Diana_Apple

Well Known Member
Has anyone noticed that pgm P04515 will print erroneous data on the 1099s if you have multiple EIN's? What happens is that the program reads F04514, compares the fields from that records with control level fields. If they differ, then it "EXSR" S0L2T, S0L3T, etc; depending upon what fields have changed. (It also executes S0l2D & S0L3D, etc- but these are okay). The purpose for S0L2T & S0l3T is to print totals for 1099 report and/or form. However the fields used in these subroutines are the new detail fields just read, instead of the "previous" fields that belong in this subroutine. (The S0L3T subroutine is fine.)

For example, if the G1EIN is not equal to $SEIN, subroutine S0L2T is executed, but instead of processing $SEIN and printing that tax id on the form, it is processing G1EIN, which definitely does not belong with that 1099! Am I making any sense?

Has anyone else encountered this problem and is there a SAR out there? I've placed a called to Oracle/Peoplesoft and am waiting for a call back.

We ran the 1099's, before our deadline, but didn't discover the problem until today. So now it's correction time.
 
Sorry didn't notice this one but we don't have multiple EIN's so I think we are safe. I did post a message on the board awhile back about a bug in P04515 and gave the SAR # for it. Look in the World posts "1099 Changes to be aware of..."

Diana_Apple <[email protected]> wrote:Has anyone noticed that pgm P04515 will print erroneous data on the 1099s if you have multiple EIN's? What happens is that the program reads F04514, compares the fields from that records with control level fields. If they differ, then it "EXSR" S0L2T, S0L3T, etc; depending upon what fields have changed. (It also executes S0l2D & S0L3D, etc- but these are okay). The purpose for S0L2T & S0l3T is to print totals for 1099 report and/or form. However the fields used in these subroutines are the new detail fields just read, instead of the "previous" fields that belong in this subroutine.

For example, if the G1EIN is not equal to $SEIN, subroutine S0L3T is executed, but instead of processing $SEIN and printing that tax id on the form, it is processing G1EIN, which definitely does not belong with that 1099! Am I making any sense?

Has anyone else encountered this problem and is there a SAR out there? I've placed a called to Oracle/Peopleso! ft and am waiting for a call back.

We ran the 1099's, before our deadline, but didn't discover the problem until today. So now it's correction time.
Diana Apple
Quikrete
AS/400 JDE A7.3 cum 6
 
Back
Top