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.
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.