jimmymac
Reputable Poster
We are on E1 9.0 using an Oracle DB. I have an issue with a new Create Payment group version that is creating two checks when there should be one. Let me explain.
A/P needed to separate certain tax payments in their own check run. Since this data comes from another system, we import the F0411 records through the F0411Z1 and assign a special handling code of M for these. Then we have a new create payment group R04570 that selects on RPCRC = 'M'.
The problem is that instead of one voucher with four lines ending up on one check.(the supplier is set to pay by voucher), the first line kicks out on its own check, and the next three on a second check. There should only be one check.
Through debugging I see in the R04570 that this program actually changes the incoming BC field for the RPCRC based on some logic in the Before Level Break in the Detail section. Its basically corrupting the data as it reads it.
Curious if anyone has run into this. Using the special handling code as we do for this special tax run seems like a reasonable thing to do, but in this case its screwed us a bit. The fix in the short term we found was to move the CRC field in the sequencing to the bottom of the sort sequence in that version. This removes the CRC field from causing a level break and since this version only selects a specific code, that has the effect of correcting the problem.
Any thoughts are appreciated.
A/P needed to separate certain tax payments in their own check run. Since this data comes from another system, we import the F0411 records through the F0411Z1 and assign a special handling code of M for these. Then we have a new create payment group R04570 that selects on RPCRC = 'M'.
The problem is that instead of one voucher with four lines ending up on one check.(the supplier is set to pay by voucher), the first line kicks out on its own check, and the next three on a second check. There should only be one check.
Through debugging I see in the R04570 that this program actually changes the incoming BC field for the RPCRC based on some logic in the Before Level Break in the Detail section. Its basically corrupting the data as it reads it.
Curious if anyone has run into this. Using the special handling code as we do for this special tax run seems like a reasonable thing to do, but in this case its screwed us a bit. The fix in the short term we found was to move the CRC field in the sequencing to the bottom of the sort sequence in that version. This removes the CRC field from causing a level break and since this version only selects a specific code, that has the effect of correcting the problem.
Any thoughts are appreciated.
