Payroll Module Development (Page 1 of 2)

One specific question I have is how to integrate the payroll into the current bank transaction (check writing) form, and being able to see all the taxes/deductions itemized.

All ideas coveted.

I've created some simple calculation functions and I've been able to figure the various payroll amounts correctly. I could use some help in posting the values to the GL. It looks like the Bank Account Payment Entry is using a cart to handle entries, but I'm not seeing how they are posted. Any help is appreciated.

Thank you,
-Joshua

I hope it is helpful. So far, you have been the only person to respond.

Joshua

You will need to allow for different groups of employees being paid on different days on different pay cycles.

In general you should avoid data entry columns specific to any type of pay such as salary or commission. Your database structure should support the user definition of pay items similar to inventory items, and have a pay cart built using those pay items.

When defining your database structures avoid including any columns that are specific to any one country.  Instead, you could create attribute tables linked to the core common data tables. The basic calculated payslip items should only need a quantity column, a rate and a calculated cash amount.

Avoid holding any accumulated totals in any tables. Always output totals by accumulating the core calculated payslip items. Using attributes linked to the pay items to define report categories it makes it relatively easy to create reports for different countries requirements.

I hope I have not been too discouraging.

For the attribute table, I meant something similar to the sys_prefs table in FA, but linked to each of the main entities in the payroll. If you have a pay items table similar in purpose to the FA items table, the pay item table itself would not have any columns specific to any one country but have a table linked to it to contain all the values of what would be country specific columns in the pay item table. I don't think you'd include the type and length of each attribute in the attribute table, unlike the FA sys_prefs table, but should probably have a separate attributes index table that defined all the possible attributes, their types and lengths and scope.

The payroll pay item attribute table would then just have the pay item id, the attribute index id, and the value specific to this pay item.

For example, the pay item table would have a code, description, a link to an FA expense account and fields to declare how the pay item is to be calculated. A pay item record for a salary would have a calculation method field that linked the pay item to the salary calculation function, and a separate tax pay item would link the item to the tax calculation function. But there are other attributes linked to a pay item that would have to be associated with specific countries, such as a tax category to indicate how that pay item is to be reported for tax, or perhaps how that pay item might be included in the total from which another pay item is calculated. Those types of attributes should not be columns within the pay item table, but perhaps each value stored as a separate record in a 'pay item attributes' table, linked to the pay item.

It then becomes possible to easily add processing for new countries whilst not upsetting the processing for countries already defined. You'd need attributes tables linked to each of the main entities in the payroll: the company, employees, pay items and payslip (pay check) records.

Adding a new country to the framework then means simply adding the new attributes, calculation functions and country specific reports. Hopefully the core tables would not need changing, but you might need to add country specific reference tables: the UK needs tiered National Insurance rate tables as well as tiered tax tables, and different countries quite often have different fields for each tax tier. For Australia there are two percentage rates involved in the tax calculation. For UK, you have to flag which tier is the basic rate tax, and so on.

I think you do need a separate table for payslips and payslip items, just as FA has sales order and sales order details, and the GL entries are generated from them. The payslip and payslip items tables also need their own attribute tables as some countries require values to be carried forward from pay to pay.

I have followed this design for a PC payroll system that is sold in Australia, New Zealand, United Kingdom, and several Pacific islands. It's worked quite well so far and it's relatively easy for me to extend the software for new countries. I had considered adding a payroll module to FA myself based on the same design, but I am a bit tied up with support and enhancements for that other payroll and don't have much time left.

Hello gents,

i was considering writing a module for payroll, but maybe we can join forces.

As I am living in Romania, I am mostly interested in a payroll module for Romania.

Aside from various country specifics you mentioned, in RO we have a deduction - aka an amount that is subtracted from base amount - for tax income calculation.
The amount itself is calculated based on a table(gross income, # of persons, formula)=>deduction amount.

LE: and of course, I would like to create an user for each employee, so that they can see/check their payslip and submit their vacation requirements (approval/etc).
and to generate MT100 files for bulk bank payment
and (localized and country specific) to be able to generate electronic statements for authorities.

Whether I can help, otherwise than making specs, please say.

Regards,
S

It sounds like most of the stuff in your edit could be handled by generating reports. I haven't done any reports yet, but from what I've read, it should be easier than creating a module. Fa already has the ability to create users with different limited permissions,  so you could generate payslip and bank reports based on who is logged in.
I haven't really done any projects quite like this before, so I don't know how to break this up for distributed development, except for the kind of things you're talking about with the reports and whatnot.

dear sticmann, I have one question:
have you considered this: Anahaw Open Payroll System ? https:/sourceforge.net/projects/openpayroll/

it seems that it is integrated with weberp - the ancestor of FA....
Perhaps it is easier to use and integrate.

sticmann,
it was just an ideea, I did not knew how advanced are you.

If you can share the code, I would jump in

after completion of Fixed asset module we are working on payroll and HR module.

following are list of features.

Payroll Module   
   
S. No    Options
1    Location Setup
2    Department Setup
3    Bank Setup
4    Designation Setup
5    Grade Setup
6    Gazetted Holidays Setup
7    Qualification Setup
8    Employee Information
9    Leave Setup
10    Leave Inquiry and Approved Setup
11    Loan Setup
12    Loan Inquiry and Approved
13    Breakup Salary Inquiry
14    Process Month
15    JV posting
16    Pay Slip  (Report)
17    Bank Draft (Report)
   
   
HR Module   
   
S.No    Options
1    Advertisement
2    Applicant
3    Upload CV
4    Inquiry Applicant Form View/Edit/CV/Approved
5    Interview Inquiry Interview Date/Final Interview
6    Applicant  Appointent Letter
7    Applicant Extended Letter
8    Applicant Termination
9    Applicant  Confirmation
10    Evaluation Form
11    Increment and Promotion Form
12    Increment and Promotion Form Approved
13    Increment and Promotion Letter

Hello,
I have zero development knowledge but I know that when you acquire this component up and also flowing it ought to be well recieved by every one of the people. Has any person from FrontAccounting been assisting you?
Bill

I have developed HR and payroll module,you all can test it from this url below.

http://bahriatravels.com/erp/ie3/

user id= admin
pass word= 123456

please give me suggestions.

Regards,
Farhaj