Merge lp:~synerpgy/openobject-addons/hr_payroll_french_localization into lp:openobject-addons

Proposed by YannickB (YOLO consulting)
Status: Superseded
Proposed branch: lp:~synerpgy/openobject-addons/hr_payroll_french_localization
Merge into: lp:openobject-addons
Diff against target: 96 lines (+25/-2)
2 files modified
hr_payroll/hr_payroll.py (+16/-2)
hr_payroll/hr_payroll_view.xml (+9/-0)
To merge this branch: bzr merge lp:~synerpgy/openobject-addons/hr_payroll_french_localization
Reviewer Review Type Date Requested Status
YannickB (YOLO consulting) (community) Disapprove
Fabien (Open ERP) Disapprove
Review via email: mp+82573@code.launchpad.net

This proposal has been superseded by a proposal from 2011-11-30.

Description of the change

Hi,

I would like to propose some improvements in the payroll. I'm currently trying to implement the payroll for the french localization but unfortunately some tools are currently missing in the module.

In particular, the employer contributions management are completely not implemented. This is a big problem and I can't develop the localization without it.

Here I propose some little changes for implementing it. I try as much as possible to make little changes but which will next add big features to the payroll management.

Tell me what you think about it, this is my first merge proposition. I hope you will process it fast so than I can begin to work on the localization in itself as soon as possible.

Regards,
Yannick Buron, SYNERPGY.

To post a comment you must log in.
Revision history for this message
Fabien (Open ERP) (fp-tinyerp) wrote :

IMHO, This can be implemented by a simple rule, I don't think we need to develop specific code for this. The current rule engine is able to handle this.

The employer contribution should just be a rule that is not part of the deductions.

If it's not clear, can you describe what you intend to do exactly ?

review: Disapprove
Revision history for this message
YannickB (YOLO consulting) (yannick-buron) wrote :

Hi Fabien,

I knew you would say something like that. You proclaim on twitter some weeks ago that hr_payroll could handle any localization and I was very optimistic when I finally found the time to try it.

For me, the best news was the release of l10n_be_hr_payroll. I think we really needed an example of what it was possible to do with hr_payroll and l10n_be_hr_payroll provide it perfectly.

Thanks to that, I now perfectly understand the power of the Python code field. You did a really nice job by allowing to use contract, payslip, worked_days, input and categories objects directly into the computation of the amount. Thanks to that, I am quite confident in the fact I can even configure the extremely complicated payroll we use in France.
One example : 3% employee contribution for basic 0-2000€n then 7,7% for the 2000€+ part of the salary, I am sure I could manage it with the powerful basic management you implement in hr_payroll.

But still, something is missing. For one contribution you have generally two amount, employee deduction and employer deduction. You suggest to make two lines in the payslip but I say that in my payslip report I need to show these two amount in only one line.
For this we need a link between the employee and the employer deductions. Here with the code I propose we can make it very simply, by making good use of the payroll framework you developed.

Let me also remark that you didn't declare the employer deductions in l10n_be_hr_payroll, and yet some Google research show me that you have theses in Belgium.

If after that you're still confident with your module, just respond to this question :

Let's assume I am currently developing the module l10n_fr_hr_payroll. What I want to do in this module is just :
       -Declare the contributions of course, and the rest of the configuration needed.
       -Create a new payslip report (sorry the actually is terrible, but no problem I think this report is the work of the localization)
       -Eventually create some gross total / net total function field in the payslip for using them in the report. Since I plan to hard-link them to the corresponding rule, I prefer create them in the localization module.

Let's also assume the goal of all this is to create EXACTLY this report : http://www.logiciel-gestion.org/images/ciel-paye-tepa-4-4-bulletin.jpg .

How the hell I can do to display the employer contribution like in this report with the actual module? Also I need that the user can easily modify the employer contribution from the payslip, and the most ergonomic way for that is to display the field in the same line that the employee contribution.

If you can find a way, and also a truly ergonomic way for the users to implement my need, then I'll just do it. If not, please consider implementing this feature which is probably the only last thing so we can managing payroll in OpenERP.

Of course I can also develop this feature in the localization module, but I think the employer contribution management is a general need and so I propose to merge it.

Regards,
Yannick.

review: Needs Resubmitting
Revision history for this message
Fabien (Open ERP) (fp-tinyerp) wrote :
Download full text (3.2 KiB)

Hello Yannick,

Having a first POC of a l10n_fr_hr_payroll would be very good. We need localizations that can serve as an example for others countries. It also allows us to validate (or not) the payroll engine we developed.

> But still, something is missing. For one contribution you have generally two amount, employee
> deduction and employer deduction. You suggest to make two lines in the payslip but I say that in
> my payslip report I need to show these two amount in only one line.
> For this we need a link between the employee and the employer deductions. Here with the code I
> propose we can make it very simply, by making good use of the payroll framework you developed.

Why not using the hyerarchy in the rules for this ?

Have a look at the meal voucher rule in the l10n_be_hr_payroll, this may solve your issue. For a meal voucher of 6.00 EUR in Belgium, there is 1.09 paid by the employee (deduced from it's gross salary) and 4.81 paid by the company (to Accor for example). To manage this we do:
  - one rule (Meal Voucher)
       - Children 1: company contribution
       - Children 2: employee contribution

If the report requires to print both rule in one line, I think it's better to implement this at the report level, rather than changing.

Sorry if I look strict on this, but IMHO if something can be computed by the current payroll engine, it's better not to develop specific rules for specific cases. Payrolls are so complex that we could potentially add lots of fields and logic if we don't rely on a strong computation engine.

> Let me also remark that you didn't declare the employer deductions in l10n_be_hr_payroll, and yet
> some Google research show me that you have theses in Belgium.

What's the french translation of employer deduction ? (Charges patronales ? sociales?)

> Let's assume I am currently developing the module l10n_fr_hr_payroll.

Yes, that would be great.

> What I want to do in this module is just :
> -Declare the contributions of course, and the rest of the configuration needed.

> -Create a new payslip report

If you create a better, and generic, report I think it's better to merge it directly in the hr_payroll module in replacement to the Payslip Details report. All countries will need it. The example you took from ciel seems to be generic, we just need to identify some salary rule categories code that have a special meaning, like NET.

The whole structure in the columns of your document seems generic (salaire de base, salaire brut, total retenues, ...). If I am not wrong, the left column Mt. Sal contains all rules having "Appears on Payslip" checked whereas the right column Mt.PAT is all not having 'Appears on payslip" checked. Is some rule belong to the same parent, they should be on the same line.
    --> this makes me wonder if "Appears on Payslip" is the right label?

> Of course I can also develop this feature in the localization module, but I think the employer
> contribution management is a general need and so I propose to merge it.

No, we need a payroll engine that implements most scenario without having to develop (too much) in country specific modules. I prefer that we try improving the current engine t...

Read more...

Revision history for this message
Fabien (Open ERP) (fp-tinyerp) wrote :

IT may look strange to use "Appears on PAyslip" to differenciate between Mt. Pat / Mt. Sal but it was or intention with this field as in Belgium, Mt. Pat stuff do not appear on the payslip.

Revision history for this message
YannickB (YOLO consulting) (yannick-buron) wrote :
Download full text (4.1 KiB)

Thanks a lot for these explanations. I think I start to be agree with you.

> Why not using the hierarchy in the rules for this ?

> Have a look at the meal voucher rule in the l10n_be_hr_payroll, this may solve your issue. For a
> meal voucher of 6.00 EUR in Belgium, there is 1.09 paid by the employee (deduced from it's gross
> salary) and 4.81 paid by the company (to Accor for example). To manage this we do:
> - one rule (Meal Voucher)
> - Children 1: company contribution
> - Children 2: employee contribution

I suppose this happen but I feel a bit ashamed here... How I could missed that, you're totally right the rules hierarchy could totally handle the link. I still don't know if it'll be ergonomic enough for the users who will modify the employer contributions in the payslip but at least it worth a try.

> If the report requires to print both rule in one line, I think it's better to implement this at
> the report level, rather than changing.

> Sorry if I look strict on this, but IMHO if something can be computed by the current payroll
> engine, it's better not to develop specific rules for specific cases. Payrolls are so complex
> that we could potentially add lots of fields and logic if we don't rely on a strong computation
> engine.

Don't worry, I think this is the good way to do it, no change unless necessary. Even me was careful with the merge here to not make big changes.

> What's the french translation of employer deduction ? (Charges patronales ? sociales?)

The term is "Cotisations Patronales" but "Charges Patronales" is ok too. We have also "Cotisations Salariales" for the employee contribution.
The translation of theses terms is difficult, some research make me think that "employer contribution" and "employee contribution" is a good translation, rather than deduction, but well I'm not a linguist.

> If you create a better, and generic, report I think it's better to merge it directly in the
> hr_payroll module in replacement to the Payslip Details report. All countries will need it. The
> example you took from ciel seems to be generic, we just need to identify some salary rule
> categories code that have a special meaning, like NET.

Good news we are agree on this point. You can account on me to do it, but now I will before begin the l10n_fr_hr_payroll module for having some data test asap.

Just one point : I'm still unsure I'll not have to redefine the report in l10n_fr_hr_payroll because some France specific data appear (Like URSSAF, SIRET, "Plafond de sécurité sociale" etc...)

> The whole structure in the columns of your document seems generic (salaire de base, salaire brut,
> total retenues, ...). If I am not wrong, the left column Mt. Sal contains all rules having
> "Appears on Payslip" checked whereas the right column Mt.PAT is all not having 'Appears on
> payslip" checked. Is some rule belong to the same parent, they should be on the same line.
> --> this makes me wonder if "Appears on Payslip" is the right label?

Don't worry, I think the "Appears on Payslip is good and don't need to be change. We'll probably need that some lines which are not employer contribution doesn't appear ...

Read more...

review: Disapprove
Revision history for this message
Fabien (Open ERP) (fp-tinyerp) wrote :

> If you create a better, and generic, report I think it's better to merge it directly in the
> hr_payroll module in replacement to the Payslip Details report. All countries will need it. The
> example you took from ciel seems to be generic, we just need to identify some salary rule
> categories code that have a special meaning, like NET.

> Just one point : I'm still unsure I'll not have to redefine the report in l10n_fr_hr_payroll because
> some France specific data appear (Like URSSAF, SIRET, "Plafond de sécurité sociale" etc...)

Yes, you may need this. But can you work in two steps: all generic stuff for hr_payroll, then a slight change on this report for l10n_fr specific fields.

> I suppose this happen but I feel a bit ashamed here... How I could missed that, you're totally right
> the rules hierarchy could totally handle the link. I still don't know if it'll be ergonomic
> enough for the users who will modify the employer contributions in the payslip but at least it
> worth a try.

Why would you change the employer contribution manually ? Isn't it computed by legal rules ?

If you need to change it from time to time, you can change directly in the tab "Salary Computation". But if you need to change the value at each payslip, the best is to add an "Input Data" that is defined and used by this rule (you can say if the input data is provided, I use it, otherwise not)

   -> you can test the 1% sales commission rule for this.

> I think a check-box "Employer contribution?" will be useful for identifying the child line which
> will be used as employer contribution.

Yes, seems good.

Revision history for this message
YannickB (YOLO consulting) (yannick-buron) wrote :

> Yes, you may need this. But can you work in two steps: all generic stuff for hr_payroll, then a slight change on this report for l10n_fr specific fields.

I though there was no inheritance in the report feature, and I needed to completely redefine it if I want to make some changes?

> Why would you change the employer contribution manually ? Isn't it computed by legal rules ?

> If you need to change it from time to time, you can change directly in the tab "Salary
> Computation". But if you need to change the value at each payslip, the best is to add an "Input
> Data" that is defined and used by this rule (you can say if the input data is provided, I use it,
> otherwise not)

> -> you can test the 1% sales commission rule for this.

My point was I wanted the users can easily review the payslip created, without having to dig too much for finding the employer contributions. Again I'm not sure if the current hr_payroll is ergonomic enough, we'll see.

The work move forward, I hope I will make a first publication on my branch during the weekend (probably without the report through, I expect some work about it).

Revision history for this message
qdp (OpenERP) (qdp) wrote :

Hello Yanick,

it's great to see you involved on the testing and enhancement of this new feature! If even more cool to see that you're confident and optimistic about it ^^

One comment about what you plan to do:
       -A checkbox "Employer contribution" in child rules for identifying the employer contribution rule.
=> i don't think it would be really generic having this because, i guess that, in some countries/cases we could have several rules computing the employer part (or the employer part would be divided into several contribution registers). So i feel like this checkbox would be a limitation more than a real improvement. Maybe this have to stay at the localization level...

       -Some many2one field "Basic" "Gross" "Net" in the configuration somewhere (company configuration?) which lead to Hr Salary Category object. Then I should be able to call the value of theses category on the report without make hard-link in the report itself.
=> mmh would it be a problem to search for the category having code=='BASIC'? Yes, it's a kind of hardcoded link but in the other hand, if someone change the code or delete this category the whole payroll engine will probably get down! And if it's on a function, localization modules can also override the function if they want to use something else.

       -Creation of a better payslip report. Although I still think I'll need to redefine it in l10n_fr_hr_payroll
=> this would be indeed a real nice improvement

Looking forward to see your proposal,
Quentin

Revision history for this message
Fabien (Open ERP) (fp-tinyerp) wrote :

> -A checkbox "Employer contribution" in child rules for identifying the employer contribution rule.

Why not adding a "Report Section" selection field ?
It could be used by others reports later.

> -Some many2one field "Basic" "Gross" "Net" in the configuration somewhere
I agree with QDP on this, using keywords is simple.

Also having the computer NET field in the payslip would be interesting for the useability, may be a function field that search for the NET rule.

Revision history for this message
YannickB (YOLO consulting) (yannick-buron) wrote :

Hi everyone, I have good news : I just made the first commit of l10n_fr_hr_payroll, you can find it on my branch.
A large part of the work is already done, all the rules are created (~60 rules) and I can already say that hr_payroll is really able to support french payroll.

Now there is still a lot of work :
    -Create the report
    -Make the accounting configuration, so the payslip can generate the good account move
    -The actual amounts are still false, but I want to work on the report before correcting it.
I only worked on the contributions, the really important point here, other rules like deductions or allowances will be done after a first release.

Some comments :

-We really need that the basic and the percentage are visible on the payslip lines. It is mandatory here so that hr manager can see right away if an amount is wrong, and I also need theses fields in the report. I'll modify hr_payroll for that when I'll develop the report.

-Some fields like SIRET or URSSAF number should be declare in l10n_fr module, I'll also modify it for the report.

-If you say to me that hr_payroll already use keywords, then I guess you're right. Let's go for hardlinking.

-About the "Employer contribution" checkbox... well I really don't know. The only things I'm pretty sure is that employer contributions appear everywhere in the world, but I'll let you the choice to use it on hr_payroll or not.
Until that, I'll create it on the localization module.

Stay tune, the report will be done as soon as possible.

Revision history for this message
Fabien (Open ERP) (fp-tinyerp) wrote :

Hello,

Seems good, a few comments

> About the "Employer contribution" checkbox... well I really don't know.

Can you add, in hr_payroll module, a field called "Report Section" which is a selection box ['employee contribution', 'employer contribution', False]. You can use this field for improving the report.

> The only things I'm pretty sure is that employer contributions appear everywhere in the world

Yes, probably. But, for example, in Belgium in does not appear on the payslip because the employer contribution, called "Charges Patronales", does not appear on the payslip because it's directly paid by the company to the ONSS "Office National de la Sécurité Sociale" --> so for belgians, we manage this with a contribtion register "ONSS" and the checkbox "does not appear in the payslip".

> -Some fields like SIRET or URSSAF number should be declare in l10n_fr module

Yes, of course.

> Now there is still a lot of work: Make the accounting configuration, so the payslip can generate
> the good account move

This is the reason why we splitted hr_payroll and hr_payroll_account. You can do hr_payroll without implementing the accounting yet. In this case, your module must depend on hr_payroll and not hr_payroll_account.

Revision history for this message
YannickB (YOLO consulting) (yannick-buron) wrote :

Well I'm afraid the work on the report take more time than planned... My skills is more on the functional part and I can't achieve to make the report working.
If you want to, maybe a little help could be useful. I already made a sxw (you can find it on l10n_fr_hr_payroll/report/fiche_paye_save.sxw), we just have to make it working.

If I have no other choice, I could certainly ask to my old developer to help me but not before the weekend.

As I can't anything else, I'll return working on the contributions declarations where I am way more efficient.

I also add a "type" field on hr.payroll.rule, which should work as your "Report Section"suggested. It can have as value : "normal", "employer" and "total"
     -A "normal" rule will work just like now. If it has a child rule with "employer" type, this child rule will be use for the employer part on the line of the report .
     -A "employer" rule, without being a child of an another rule, will only display his rate and amount field on the employer part on the report. The employee part will be leaved empty in that case.
     -A "Total" rule will be use in case we need to display a total line on the report. This kind of line should not have any impact on the total computed for the category, not like now. This is important as if I currently use total line the total computed for the category are all wrong.

Revision history for this message
YannickB (YOLO consulting) (yannick-buron) wrote :

Hi everyone,

After some time, I finally manage to make the report working as I want.

Now I still have to :
   -Make some corrections, having sure that all result computed are correct.
   -Implement working day support, as l10n_be_hr_payroll.

Once this will be done, I think I'll try a first merge request.

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'hr_payroll/hr_payroll.py'
2--- hr_payroll/hr_payroll.py 2011-11-15 14:07:23 +0000
3+++ hr_payroll/hr_payroll.py 2011-11-17 17:49:25 +0000
4@@ -577,7 +577,7 @@
5 #check if the rule can be applied
6 if obj_rule.satisfy_condition(cr, uid, rule.id, localdict, context=context) and rule.id not in blacklist:
7 #compute the amount of the rule
8- amount, qty = obj_rule.compute_rule(cr, uid, rule.id, localdict, context=context)
9+ amount, qty, employer_amount, employer_rate = obj_rule.compute_rule(cr, uid, rule.id, localdict, context=context)
10 #check if there is already a rule computed with that code
11 previous_amount = rule.code in localdict and localdict[rule.code] or 0.0
12 #set/overwrite the amount computed for this rule in the localdict
13@@ -608,6 +608,8 @@
14 'amount': amount,
15 'employee_id': contract.employee_id.id,
16 'quantity': qty,
17+ 'employer_rate':employer_rate,
18+ 'employer_amount':employer_amount
19 }
20 else:
21 #blacklist this rule and its children
22@@ -769,8 +771,10 @@
23 'amount_select':fields.selection([
24 ('percentage','Percentage (%)'),
25 ('fix','Fixed Amount'),
26+ ('employe_employer_contribution','Employe/Employer Contribution'),
27 ('code','Python Code'),
28 ],'Amount Type', select=True, required=True, help="The computation method for the rule amount."),
29+ 'employer_contribution_rule':fields.many2one('hr.salary.rule', 'Employer Contribution Rule', help="Indicate here the employer rule"),
30 'amount_fix': fields.float('Fixed Amount', digits_compute=dp.get_precision('Payroll'),),
31 'amount_percentage': fields.float('Percentage (%)', digits_compute=dp.get_precision('Payroll'), help='For example, enter 50.0 to apply a percentage of 50%'),
32 'amount_python_compute':fields.text('Python Code'),
33@@ -851,9 +855,17 @@
34 elif rule.amount_select == 'percentage':
35 try:
36 amount = rule.amount_percentage * eval(rule.amount_percentage_base, localdict) / 100
37- return amount, eval(rule.quantity, localdict)
38+ rate = rule.amount_percentage
39+ return amount, eval(rule.quantity, localdict), rate
40 except:
41 raise osv.except_osv(_('Error'), _('Wrong percentage base or quantity defined for salary rule %s (%s)')% (rule.name, rule.code))
42+ elif rule.amount_select == 'employe_employer_contribution':
43+ try:
44+ amount = rule.amount_percentage * eval(rule.amount_percentage_base, localdict) / 100
45+ employer_amount, employer_qty, employer_rate = rule.employer_contribution_rule.compute_rule(cr, uid, rule.id, localdict, context=context)
46+ return amount, eval(rule.quantity, localdict), employer_amount, employer_rate
47+ except:
48+ raise osv.except_osv(_('Error'), _('Wrong percentage base or quantity defined for salary rule %s (%s)')% (rule.name, rule.code))
49 else:
50 try:
51 eval(rule.amount_python_compute, localdict, mode='exec', nocopy=True)
52@@ -925,6 +937,8 @@
53 'contract_id':fields.many2one('hr.contract', 'Contract', required=True),
54 'amount': fields.float('Amount', digits_compute=dp.get_precision('Payroll')),
55 'quantity': fields.float('Quantity', digits_compute=dp.get_precision('Payroll')),
56+ 'employer_rate':fields.float('Employer Rate', digits_compute=dp.get_precision('Payroll')),
57+ 'employer_amount':fields.float('Employer Amount', digits_compute=dp.get_precision('Payroll')),
58 'total': fields.function(_calculate_total, method=True, type='float', string='Total', digits_compute=dp.get_precision('Payroll'),store=True ),
59 }
60
61
62=== modified file 'hr_payroll/hr_payroll_view.xml'
63--- hr_payroll/hr_payroll_view.xml 2011-11-09 18:12:56 +0000
64+++ hr_payroll/hr_payroll_view.xml 2011-11-17 17:49:25 +0000
65@@ -320,7 +320,11 @@
66 <field name="category_id"/>
67 <field name="sequence" invisible="1"/>
68 <field name="quantity" string="Quantity/Rate"/>
69+ <field name="amount_percentage_base"/>
70+ <field name="amount_percentage"/>
71 <field name="amount"/>
72+ <field name="employer_rate"/>
73+ <field name="employer_amount"/>
74 <field name="total"/>
75 </tree>
76 <form string="Payslip Line">
77@@ -330,7 +334,11 @@
78 <field name="category_id"/>
79 <field name="sequence" groups="base.group_extended"/>
80 <field name="quantity" string="Quantity/Rate"/>
81+ <field name="amount_percentage_base"/>
82+ <field name="amount_percentage"/>
83 <field name="amount"/>
84+ <field name="employer_rate"/>
85+ <field name="employer_amount"/>
86 <field name="total"/>
87 <field name="salary_rule_id" groups="base.group_extended"/>
88 </group>
89@@ -607,6 +615,7 @@
90 <field name="condition_range_max" colspan="2" attrs="{'invisible':[('condition_select','&lt;&gt;','range')], 'required':[('condition_select','=','range')]}"/><newline/>
91 <separator colspan="4" string="Computation"/>
92 <field name="amount_select"/><newline/>
93+ <field name="employer_rule" attrs="{'invisible':[('condition_select','&lt;&gt;','employe_employer_contribution')], 'required': [('condition_select','=','employe_employer_contribution')]}" />
94 <field name="amount_percentage_base" attrs="{'invisible':[('amount_select','&lt;&gt;','percentage')], 'required': [('amount_select','=','percentage')]}"/><newline/>
95 <field name="quantity" attrs="{'invisible':[('amount_select','=','code')], 'required':[('amount_select','!=','code')]}"/><newline/>
96 <field name="amount_fix" attrs="{'invisible':[('amount_select','&lt;&gt;','fix')], 'required':[('amount_select','=','fix')]}"/><newline/>

Subscribers

People subscribed via source and target branches

to all changes: