mockerm
Member
Looking for suggestions or examples of how someone has approached a similar
direct deposit issue.
First off we are currently on 7332 and getting ready to go to XE. We have
about 10,000 employees scattered around 40 or so plants, and a corporate
center. Each plant executes their own payrolls in JDE - each using a
unique Payroll ID for hourly employees (i.e., Plant #2 Payroll ID =
002HRLY). Right now we only offer direct deposit to our salaried employees,
but in June, we are expanding it to hourly employees as well.
Currently, direct deposit is fairly straghtforward, as all salaried
employees fall under a single Payroll ID, and processed at corporate. The
direct deposit file is then sent to the bank from corporate using a direct
dial-up. When we go live with direct deposit for hourly employees, we now
have an issue of how best to get the direct deposit data from each plant to
the bank.
In both 7332, and XE, the program that creates the direct deposit file is
supposed to run locally, and the file is written to the workstation(B7
directory). The program's processing options only allow one Payroll ID. If
we continued with that design, each plant would be responsible for getting
their data to the bank.
First off, I don't think the bank is willing to accept 40 separate
transmissions from a single company. And secondly, even though our payroll
process is decentralized, this process cries out for centralization. It's
too high risk to ensure every submission is making it across the lines OK.
We would like to "bundle-up" the multiple Payroll IDs, and send the direct
deposit data from corporate in one transmission. As stated, JDE's current
design for the direct deposit process is not condusive to this.
From the outset, we didn't care for the idea of having the payroll direct
deposit data going to a workstation, and modified the process to not run
locally, but off the server, with the output file going to our UNIX box.
This also eliminated the need for an additional fat client(s).
OK, sorry for the novella, but I had to get our situation described. Has
anybody attempted anything similar? Any ideas? Thanks.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
direct deposit issue.
First off we are currently on 7332 and getting ready to go to XE. We have
about 10,000 employees scattered around 40 or so plants, and a corporate
center. Each plant executes their own payrolls in JDE - each using a
unique Payroll ID for hourly employees (i.e., Plant #2 Payroll ID =
002HRLY). Right now we only offer direct deposit to our salaried employees,
but in June, we are expanding it to hourly employees as well.
Currently, direct deposit is fairly straghtforward, as all salaried
employees fall under a single Payroll ID, and processed at corporate. The
direct deposit file is then sent to the bank from corporate using a direct
dial-up. When we go live with direct deposit for hourly employees, we now
have an issue of how best to get the direct deposit data from each plant to
the bank.
In both 7332, and XE, the program that creates the direct deposit file is
supposed to run locally, and the file is written to the workstation(B7
directory). The program's processing options only allow one Payroll ID. If
we continued with that design, each plant would be responsible for getting
their data to the bank.
First off, I don't think the bank is willing to accept 40 separate
transmissions from a single company. And secondly, even though our payroll
process is decentralized, this process cries out for centralization. It's
too high risk to ensure every submission is making it across the lines OK.
We would like to "bundle-up" the multiple Payroll IDs, and send the direct
deposit data from corporate in one transmission. As stated, JDE's current
design for the direct deposit process is not condusive to this.
From the outset, we didn't care for the idea of having the payroll direct
deposit data going to a workstation, and modified the process to not run
locally, but off the server, with the output file going to our UNIX box.
This also eliminated the need for an additional fat client(s).
OK, sorry for the novella, but I had to get our situation described. Has
anybody attempted anything similar? Any ideas? Thanks.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
