From: James N. <Jne...@we...> - 2004-10-12 07:37:07
|
Hi all, Not having much experience with payroll systems, I'm not able to add much to the discussions, but from an interface perspective I agree that the interface will be vital to the system. One thing that would definitely make it easy to use is the ability to be able to copy a previous payroll transaction for an employee. For salaried employees whose Gross and Net pay don't change, it would be a simple task to process these transactions. For contract/waged staff where the capturing of time sheets needs to be handled, I suggest that it is a manual process where someone will have to tally the hours, and manually create the deductions, etc. I'm not an accountant, but here in South Africa the requirements seem to be simpler than in the US. We have Tax that is deducted by the employer according to a sliding scale (PAYE), an unemployment fund payment that is paid by both the employer and the employee, also based on a scale and then other deductions such as retirement funds, medical aids, etc We don't have State taxes or Federal taxes. Other items that I've experienced on the payroll system is the ability to pay off money lent to you by the organisation. This is probably outside the scope of a payroll system, but may be nice for those instances where it is required. Our small organisation would be able to function much more easily with the ability to capture the Gross Pay, manually insert the deductions (PAYE, UIF, etc) and then print out a payslip to present to the employee - Currently we do with with a spreadsheet template and we just change the date :) Once one transaction has been saved, we can always copy that payroll slip for the next month and save a ton of time in calculating out TAX debt. I have no experience with a larger organisation (25+), maybe the requirements are very different. Kind Regards, James Jeff Vian wrote: >On Mon, 2004-10-11 at 17:06, Santoken wrote: > > >>Jeff Vian wrote: >> >> >> >>>Just from my limited experience in doing payroll for one company, in the >>>US there are things like medicare, ssa, FUTA, SUTA, state income, >>>federal income, local taxes, and probably others I have missed. >>>There are also withholdings for IRAs, stock purchase plans, >>>garnishments, medical savings plans, insurance plans, etc. >>> >>> >>Yes...so, what you are saying is we start with a big number (gross >>income) and do some deductions (some will be percentages, others static >>numbers, etc.) and then we are left with a smaller number...that's the >>total of the paycheck, right? >> >> >> >>>This will be a very complex issue even if only addressed for one >>>country, and making it multinational will be even more. >>> >>> >>Complex? Hardly. Look, doing payroll (as I and my company have been >>doing for 8+ years now) is nothing more than simple math. You start >>with a big number, subtract some numbers or percentages from it, and the >>total left is the check amount. Granted, there are other things >>happening in the background, but it's hardly more complicated than this. >> >> >> > >The complexity is not in doing the math, but in making the interface >easy to use and easy to update values. Even worse is the need to make >it intuitive on "how to get there from here." Many (probably most) >users don't care about the backend, as long as the interface is friendly >and easy to use and the results are accurate. > >As I see it, the hardest programming part will be in defining what >deductions apply to which employees and when. Then making the interface >and automation handle that correctly with suitable reports and data >entry screens. > >The interface and making it flexible enough to encompass many different >locales will require some basic knowledge of what is needed in each >locale. Once the requirements are known the actual implementation >should be fairly straight forward and similar to what Chris is already >working on. > > > >>>My approach would be to do this for one country at a time and then add >>>additional countries as the need arises and time permits. A separate >>>payroll module for each country, with the processing output being >>>plugged into the GL is likely required in order to make it flexible >>>enough for all environments. >>> >>> >>That type of approach only makes this module look more difficult than it >>really is. >> >> >> > >Not really - divide and conquer. Once it is done for one locale, the >modifications to fit additional areas become simple and in many cases >obvious. > > > >>>A complete knowledge of the requirements for each country/state will be >>>needed and the ability to do updates to the calculations (percentages, >>>etc.) as changes occur will be mandatory. >>> >>> >>Nope. Currently, I use Peachtree for my payroll. I haven't paid for >>their tax tables since I bought the software. I have manually entered >>my deduction tables since then. >> >> >> > >You may the updates to the taxes tables manually, but do you have all >the knowledge of what is required in all situations? And do you know >how to make the software do what peachtree does in the background? If >so, please collaborate and help produce the modules to make this happen. > > > >>Look, payroll is not rocket science. If you think it is, your >>accountant (or your payroll contractor) has kept you in the dark for far >>too long. Payroll is quite simple, as some have indicated by still using >>ledgers, pens, and adding machines. >> >>There is NOTHING (as least here in Ohio) that has to be filed >>electronically. I mean NOTHING. Not on any Federal, State or local. >> >>Kent >> >> >> > >Exactly, but reports will have to be designed to provide the values >needed for you to fill in the periodic reports that do need to be filed >- monthly, quarterly, or whenever. > > > > > >------------------------------------------------------- >This SF.net email is sponsored by: IT Product Guide on ITManagersJournal >Use IT products in your business? Tell us what you think of them. Give us >Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more >http://productguide.itmanagersjournal.com/guidepromo.tmpl >_______________________________________________ >sql-ledger-users mailing list >sql...@sq... >https://lists.sourceforge.net/lists/listinfo/sql-ledger-users > > > |