RLessor
Member
Our company is getting ready to go live with OneWorld Xe accounts payable shortly but I have found a issue that bugs me not only as a IT Manager but as a previous accountant and developer. The process in question is accounts payable check writing whereby I can not understand the J.D. Edwards/PeopleSoft thought process. Hopefully one of you has encountered the same problem and possibly a solution.
We use OPTIO check writing solutions and it works exceptionally well. The problem I have is we have a main office staff of accounting clerks and over fifty remote sites with the ability to process accounts payable checks all through a web client (no fat clients). When actually processing the a/p check process, one UBE (R04571) has interconnects to other reports (R04572 and R04573) which causes me to have security concerns. The IT Department goal is to have the PDF check file report print immediate to the appropriate queue at the main office with the balance of the reports to print immediately elsewhere regardless of the user or their location. What we have found is all reports can be printed to one queue unless one decides to create a lot of custom code.
My desire is to have the checks hit the check writing queue OPTIO_PZAP with the accounts payable attachments to print on the printer next to the check printer. PeopleSoft has stated that is not possible without much customization hence the need to have users manually move the check PDF to the correct printer from a “work with submitted job” screen. Because the process starts with the R04571 UBE we are told everything else must follow the interconnected report structures as well.
I get blown away thinking this is not an issue for others. While I could print generic reports to the MICR printer, this is a waste of money. The second option of having users manually print the report to the proper queue is a major design flaw. Think for one minute a user could select one payment to oneself but not actually print the check until later. One could then reset the check writing process and have the check written by others through the manual process. One could then send the original check to the check printer thereby paying one twice. Banks would cash both checks without any problem and it would fall back to the company as a control problem.
While this is somewhat true, having the ability to print directly would eliminate the issue altogether. The PeopleSoft support group has not been very helpful and thought we should request a SAR but like that is going to happen with the life of Xe. Has anyone out there found a solution to this major problem? I hope I have given enough information to the group.
Randy K. Lessor
Manager of Information Technology
World Software/OneWorld Xe Coexistence
OneWorld SP23
Enterprise Server – iSeries/400 (V5R2)
Application Server – Windows 2000 Web Server
We use OPTIO check writing solutions and it works exceptionally well. The problem I have is we have a main office staff of accounting clerks and over fifty remote sites with the ability to process accounts payable checks all through a web client (no fat clients). When actually processing the a/p check process, one UBE (R04571) has interconnects to other reports (R04572 and R04573) which causes me to have security concerns. The IT Department goal is to have the PDF check file report print immediate to the appropriate queue at the main office with the balance of the reports to print immediately elsewhere regardless of the user or their location. What we have found is all reports can be printed to one queue unless one decides to create a lot of custom code.
My desire is to have the checks hit the check writing queue OPTIO_PZAP with the accounts payable attachments to print on the printer next to the check printer. PeopleSoft has stated that is not possible without much customization hence the need to have users manually move the check PDF to the correct printer from a “work with submitted job” screen. Because the process starts with the R04571 UBE we are told everything else must follow the interconnected report structures as well.
I get blown away thinking this is not an issue for others. While I could print generic reports to the MICR printer, this is a waste of money. The second option of having users manually print the report to the proper queue is a major design flaw. Think for one minute a user could select one payment to oneself but not actually print the check until later. One could then reset the check writing process and have the check written by others through the manual process. One could then send the original check to the check printer thereby paying one twice. Banks would cash both checks without any problem and it would fall back to the company as a control problem.
While this is somewhat true, having the ability to print directly would eliminate the issue altogether. The PeopleSoft support group has not been very helpful and thought we should request a SAR but like that is going to happen with the life of Xe. Has anyone out there found a solution to this major problem? I hope I have given enough information to the group.
Randy K. Lessor
Manager of Information Technology
World Software/OneWorld Xe Coexistence
OneWorld SP23
Enterprise Server – iSeries/400 (V5R2)
Application Server – Windows 2000 Web Server