I’ve seen several potential customers (none of them a real project yet) asking for payroll management in Tryton. I will like to know if there is interest on having a generic module for them on Tryton.
The idea is to have a model to store the payroll and print a report to be sent to the employee.
A payroll document should contain at least the following:
The company
The employee
The start and end date of the payroll
A sorted list of concepts with an amount for each (amount can be positive or negative)
Amount to pay: Sum of amounts of all concepts
We should integrate it with other Tryton modules:
Accounting: After posting the payroll the right account moves should be posted on accounting.
Account Payment: It should be possible to generate a SEPA file with all the amount to pays of the payrolls.
Currently most of our customers are generting a single account move for the payroll amount of all emploies of a period (normally monthtly). I’m wondering if we should also support also grouping payrollls on accounting or just create a move for each payroll document.
This should be the starting point with the objective to be able to automatically generate the payroll documents for all the active employees in a period I think the first step should be manual generation.
It will be great if you can share your opinion about this topic, specially if you have some special requirements for each country that may require the adaptation of the base module.
I think we need to define what a “concepts” should model.
Design
In Italy(just so we can find a “common ground”) is customary to find in a payroll:
taxes (like pension, income taxes ecc…) (payed by the employer for the employee)
tax returns
benefits (deduced from pay, like supplementary health insurance, or add tot he pay)
TFR (escrow money that the employee will receive at the end the the contract, usually 10% of the pay)
I think we can model this similar to how we do in the invoice module:
We have lines, to each line we can add one or more taxes.
The line should have a unit, and a base rate.
Each line can be based on a template/type, or stand alone.
This because each unit of work can be billed/taxed differently (Like sick leaves, or traveling) so (IMHO) is require to have multiple line for each “type” of work.
Accounting
We should generate a separate move line for each item in the payroll (IMHO). This to aid budgeting via analytic accounting and can be useful in a matrix management structure (so you can keep track of the cost of each product analytically).
Taxes
This is a bit difficult (and I’m out of my waters here, so I’m piecing together information). The tax rate usually is not fixed, and based on the income of each employee (at least in Italy, in a progressive tax scheme). So don’t know if we should have a system that pre-calculate the taxes based on the party estimated income, and distribute the cost between each payroll. At the end of the year the difference from the actual income, and the one pre-calculated should be reconciled.
TL;DR: Each line have a tax, that is used to calculated the amount at the end of the year, but we make the employee pay for the estimated amount distributed between each payroll.
Reporting
The report should have access to the total taxes payed for the current fiscal year, the estimated amount of taxes owed, and the amount of escrow money the user have.
I think the accounting should be grouped in a single move for confidentiality. Not every accountant will have access to the payroll of every employee. The payroll detail should be restricted to a limited group of user.
For the analysis this can be simply done using the average cost price of the employee. There is no real point to be more precise. The cost price could be updated using the payroll but usually it will include more than that.
I do not think the invoice design will apply here because taxes computation are more complicated and there are needs for detail.
I think it will be more flexible to just store line with an amount computed from a rule system. The rule system should be flexible enough to support most of the cases (and design to be extended easily).
Probably we may have an optional quantity but I imagine that there are some cases from where the quantity is not relevant. That’s why I not included them originally. My idea is that the user just enters the concept and the amount.
A concept should define:
The account used to account this concept
The tax lines that should be created using this concept for the amount.
This will allow a user with a payroll document generated by anyone else to enter it on the system and tryton will take care of creating the proper accounting records depending on the concept used.
We can create just a single move to keep accounting simpler but then split the concepts using analytic accounting. As far as the concept has the right analytic account values set there should be no issue.
I think we should use the current tax and tax code structure like we do for other taxes. This way we do not need to create a separate report but just use the tax code chart that currently exists.
Not sure if this is the case of other countries, but in spain we include in a single tax report the escrows done from payroll but also the ones done from invoices (for self-employeed persons).
Using the existing tax code chart will automatically support this behaviour.
Following this topic, I’ve been thinking if we need to be able to create the a set of “base concepts” from the account chart. Then the update chart of accounts wizard will also create/update those concepts. This will allow to have the common setup for a country into a common configuration.
This should be an optional feature of each chart of accounts.
This is something that I already tought about and it makes sense for me.
This will allow the users to compute the net amount to be received by the employee by just entering the gross amount. So the workflow should be something like:
Enter the gross amounts to be paid to the employee. (can be in various concepts)
Click the compute rules button.
The system will create (or update the amounts if required) for the concepts that can be computed using the rule system.
Then I will also consider allowing the creation of rules from the chart of accounts, like we do for the concepts.
Usually it is based on an amount of time (days) and a rate (from contract). The time depends on the type of contract can be fixed or linked to actual time spend.
That sounds right for me as long as the user may still correct some part after.
I think this idea of “concepts” is often called “Payments and Deductions”, but it might be easier just to call it “Payroll Items”, or on a payroll model “Items”?
In the UK I’m pretty sure these are reported totally separately.
In fact, for payroll, often HMRC needs to be given Real Time Information each time an employer pays an employee.
I like the idea of “Payroll Items (even just items)” for the user interface.
But then on the report probably better to use “Payments and Deductions”. And even sorting them to include payments allways on top and after all the deductions.
As far as you have a hook to generate the proper report like we do for french chorus. you will be able to publish this on real time.
And if needed you will be able to report the total amount on a period using the tax codes.
Yes, actually they are commonly separated into two separate columns on payslips I’ve seen, one called “Payments” and the other called “Deductions”. Also there is commonly another area which contains various totals and other details (often with a space for a note or comment).
From what I know, and can see, the proposal seems to be generic enough to support the things that I think may be required, from my point of view.
Payroll stuff is highly driven from local legislation, and subject to change very frequently (at least yearly, when the assessment limits change).
The effort to maintain this for each country would probably kill the project.
OTOH, having it too generic, it does not really add value.
So a good advise is to give payroll and tax accounting to a specialized agency, and let them deal with the local requirements…at least I kept it that way in my businesses
Indeed my ideas is to allow this worflow also. If they payroll is computed by a specialized agency they will send to the company the payroll documents. This payroll should then encoded to accounting. Instead of creating directly the account moves one may enter the payroll document based on the computation of the agency using the payroll concepts that the accountant has created for the company. Then the account moves will be created automatically on Tryton.
Some benefits:
The user may access directly their payroll documents from the ERP system
The account moves creation is simplified
Ease introduction of payroll account moves
The payment of the payroll documents can be integrated into the other payment workflow.
If we group all the account move the accounting users will not have access to the particular amounts of each employee.
For me we just need to have a button to create the payments directly from payroll but linked to the payable move line. With this we solve two problems:
The payable line is no longer present on the lines to pay view
Only users that can access payments may have the full detail of the information.
I think this is a good compromise (at least when using SEPA payments) because once the user has access to the SEPA message, he may read the processed file with the details.
hello,
thinking about complexity, this is what I can list at least
employee / party partularities
contract family and contract particularities
time off or special time (training, citizen duty, whatever)
expenses (sometimes partly added to wages)
payslip model
legals and fiscal parameters
localization and industry specifics.
There are also few things to care about:
Anytime, a playslip can contain information to compensate something in the past payslips.
For example, il you get a rate from administration in march, valid since january, it means you get a line for march, bust also a correction line for january and a correction line for february.
You can get correction lines after the end of the contract.
You also get cumulated totals for the year : in june, you print totals for january-to-june period.
As a background info, I checked Odoo status.
Odoo payroll is now in the proprietary part. Nevertheless only the Belgium localization is operational.
There is also a community module which seems to be unadapted to most cases.
I think Tryton has several features to help keeping payroll a bit less complex. I see:
historics of legal data and contract modifications
capability to update legal data from official servers
spreadsheet models and relatorio. A model may contain part of localisation and industry specifcs (Am I crazy ?) Could calculation rules be inside the model and not in the database ?
This is information that should be defined on the employee but only required to properly compute the rules to be used on the payroll. Probably depending on the country localization. So for me this should be solved by having a proper rule system based on formulas (like price list) where we can have several parameters like:
Gross amount
Current net amount
Employee
Payroll date
Company
As usuall the formula may be extended with more parameters if needed.
Not sure to fully understand here. Do you think this can be managed by a employee leave management module?
The payslip module shold be a report that can be printed directly from Tryton. So we allow each company to customize the design and whatever required.
To properly integrate expenses on payroll first we need a module to manage expenses.
As far as the expenses are added as an additional concept on the payroll it should not affect the design of the models but just create a new line from the expense module.
Sorry but I do not understand you here. Did you mean that it’s needed to have a report to sumarize the expenses related to payroll?
Indeed database and spreedsheet are very similar. I will prefer to have it on the database and as we allow to update it via CSV import it won’t be hard to manage them from spreadsheet.
Did you think it’s worth having a look at it? If yes, feel free to share a link to it
I disagree. If you don’t manage contracts correctly, I doubt you can make payslips.
Contracts, leave, holidays and legal.
For example; you work on Sunday : 25% more, different fiscal rule, and 1/2 a day off as compensation.
Another one: You get credit for training, you use part of it, and during this training you don’t benefit of lunch tickets. and so on…
yes indeed
This is why I mention it.
Not only (part of) expense. Totals of paid, raw, different total for pensions, fical fees and so on.
Part of expense is in because it may be reincorporated in salary (company car, tele-working expenses etc…)
Importing rules from csv format ?
It may be of interest because it is similar to what you propose.
Of course there are a lot of variables to manage to compute the payrolls.
My idea is to find a proper desing for the paylisp document and by start by allowing the user to just fill them manually supporting the computation by specialized agency.
Once we are have the basis we may create new modules to implement the other required features as you have properly listed.
Thanks, I will have a look at them to garther as much information as possible.
It is not a matter of how many there are, but how they are in relation and how they live to define the correct architecture.
It is the topic of the thread, indeed.
You may design a new ‘payslip-like’ report and create the form to feed it. It will be worth for what it is.
What is you position regarding my proposal for coding rules in the report model, under ods format ?
So my proposal toward the basis is to correctly define what is related to
employee,
contract,
events in the month (time off, worked hours, expenses, and so on…)
regularization of past periods
legal period totals
and legal data update.
When the architecture is correct, there is no need to implement everything if you don’t need to, but new functions can then be added gracefully (I hope).,
I had a look over this thread and having lived in many countries, I have some insights into how payroll differs between countries and how Tryton could support it.
The first insight I would emphasize is to break it down into logical pieces. Moreover, Tryton may not implement all those pieces. They may be developed by different people and at different speeds. These are some of the pieces of the puzzle, the client may use different tools for each step:
employee contract management
time reporting, vacation, sickness, etc
calculation of the gross pay (convert days/hours to gross pay)
calculation of the deductions (use gross pay to lookup tax and social security tables)
booking the net pay and booking the deductions to G/L
paying the deductions to authorities and insurance companies
producing end-of-year reports by employee and by authority
The last three steps (booking to GL, paying bills, producing the annual reports) are fairly easy. You could almost do that using the existing tax code system. For some users who have a fixed salary for every employee and some freelancers, consultants and self-employed people this would be satisfactory. Their accountant will give them a spreadsheet, they photocopy the spreadsheet each month and use it as the payslip.
One important point to note is that when the amounts are booked to the GL, they may correspond to a previous year. E.g. the employee works some overtime on 31 December 2020 and the payment is made on 3 January 2021. For some reports the payment should appear in the 2020 tax return, for other reports the payment should appear in the 2021 tax return. Therefore, it is important to have some field, like the VAT tax point, that may not be the same as the payslip date or the payment date.
The idea of making this work like Invoice and Tax codes is very relevant. A tax code tree for payroll could be an interesting way to view payroll deductions (social security, tax, insurance, pension)
(in Germany)