[18.0] Advanced Payroll WIP

[dreispt]

Depends on:

• [x] #173
• [x] #177

[nimarosa]

Hello @dreispt, some of this are great additions to payroll.

I suggest you if you want to be merged to separate the modules in different PRs.

Also, regarding the module salary_table, we are currently using the server-tools time conditions module to save such params and can be used in salary rules. Maybe you can take a look to it, the module is still in v14 for payroll. Maybe you find interesting proposing a migration (it should no be difficult)

[dreispt]

@nimarosa Thank you for your comments, and please keep an eye here and continue providing feedback. In particular I worry if some of the names chosen are too context specific, and better ones could be used.

This is a WIP and unstable. More features/modules will be coming. In its final form each commit will have its own PR.

Regarding the salary table, I quickly reviewed the 14.0 implementation, and it seems to only cover the case for global parameters. The features required are more generic. Examples are given in the README. Let me know if this makes sense.

Thanks

[nimarosa]

Hello @dreispt,

Let me review in detail the modules you are proposing and I give you feedback and my opinion, I think some functionalities can be added directly to payroll, but I have to see it in detail.

Thanks for your contributions, I look forward to new changes.

[nimarosa]

@dreispt I like the new modules you are introducing. I have to test them locally. Is this PR ready for testing/merging or it's not finished yet?

[dreispt]

It should be working.

[nimarosa]

@dreispt Hello, i want to introduce some changes to your modules here. More like view changes and improvements. Can i do it in this PR? So then we can move it to open and merge it.

I have similar modules but your implementation seems advanced so maybe we can work in it here in this PR. i have push access to this PR so if you are okay i can add changes here.

[dreispt]

You can. I can extract module sinto individual PR once they are good enough for that.

[usmanfarzandali]

why not we port payroll enterprise into community ?

[nimarosa]

why not we port payroll enterprise into community ?

@usmanfarzandali because payroll from OCA is better and with more functionalities than enterprise.

[dreispt]

why not we port payroll enterprise into community ?

Why would we want to do that?

[dreispt]

Hello, i want to introduce some changes to your modules here. More like view changes and improvements. Can i do it in this PR? So then we can move it to open and merge it.

They are already isolated as one module per commit. I have them in the same branch to conveniently work on them at the same time.

@nimarosa You are welcome to create a new branch, cherry-pick the commit for particular module you want, and then add proposed changes to it.

[nimarosa]

Hello, i want to introduce some changes to your modules here. More like view changes and improvements. Can i do it in this PR? So then we can move it to open and merge it.

They are already isolated as one module per commit.

I have them in the same branch to conveniently work on them at the same time.

@nimarosa You are welcome to create a new branch, cherry-pick the commit for particular module you want, and then add proposed changes to it.

Yes @dreispt, that's what im doing. When im ready i will share them here so we can merge them if you are okay with the new changes.

Im replacing other implementations i have with your modules so i will be adding a lot of new features to them. Hope we can work together in them.

[dreispt]

Great @nimarosa If you create a WIP PR I would be able to follow on your progress and maybe make early comments on the direction taken.

[github-actions[bot]]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.

[hitrosol]

Hi @dreispt,

Since the runboat is not active, I have installed and tested the module locally. This is an interesting approach to ensure that the components within the contract remain dynamic and sustainable. I have a few notes:

1. There are situations where changes in Master data need to be requested by one person and then reviewed and approved by another. For that reason, it would be great if we could enable logging here with draft and confirmed states. In the future, with other modules, this module could also be extended with tier validation.

2. I encountered an error when trying to access the Rule History with the following error message:

UncaughtPromiseError

Uncaught Promise > View types not defined form found in act_window action undefined

Error: View types not defined form found in act_window action undefined at _executeActWindowAction (localhost:8069/web/assets/1/26b6886/web.assets_web.min.js:10103:26) at doAction (localhost:8069/web/assets/1/26b6886/web.assets_web.min.js:10128:8) at async Object.doActionButton (localhost:8069/web/assets/1/26b6886/web.assets_web.min.js:10139:249) at async execute (localhost:8069/web/assets/1/26b6886/web.assets_web.min.js:9741:301) at async executeButtonCallback (localhost:8069/web/assets/1/26b6886/web.assets_web.min.js:9734:34)

3. I am a bit surprised with the fields Type 1, 2, and 3. Typically, Odoo and OCA use a dynamic approach such as Many2One to ensure that potential records can be supported in the future. But in this case, it uses hardcoded values to cover the three existing types. Essentially, I still do not understand the purpose of this table. A bit more information in readme will help user to understand.

4. How do we define parameters that are global in nature? In version 14, we had payroll_rule_time_parameter. Is that module no longer needed in version 18?" I gues it will refer to point 3, the salary tables / periods ?

Thanks for the great modules

[dreispt]

@hitrosol Thanks for the review and feedback.

Since the runboat is not active, I have installed and tested the module locally. This is an interesting approach to ensure that the components within the contract remain dynamic and sustainable. I have a few notes:

I haven't been able to resume work on this recently, but will eventually.

1. There are situations where changes in Master data need to be requested by one person and then reviewed and approved by another. For that reason, it would be great if we could enable logging here with draft and confirmed states. In the future, with other modules, this module could also be extended with tier validation.

Sounds like a good idea. I will look into it.

2. I encountered an error when trying to access the Rule History with the following error message:

Noted.

3. I am a bit surprised with the fields Type 1, 2, and 3. Typically, Odoo and OCA use a dynamic approach such as Many2One to ensure that potential records can be supported in the future. But in this case, it uses hardcoded values to cover the three existing types. Essentially, I still do not understand the purpose of this table. A bit more information in readme will help user to understand.

I will improve the Readme. We want dynamic support for Employee Master Data, with full history. In sectors like Banking and Government you might find things like: Professional Category, Seniority Date or Base Pay. These three examples use different type of values: a Char, a Date or a Float. So each different Master Data item has a configuration for that data type it uses, and only the appropriate field will be made available to the user.

4. How do we define parameters that are global in nature? In version 14, we had payroll_rule_time_parameter. Is that module no longer needed in version 18?" I guess it will refer to point 3, the salary tables / periods ?

Not factored in, but probably that's not hard to do using the same data structures that there. Using the module you mention alongside can be an option, but it is not my personal preference.

Thanks for the great modules

Thank you for the feedback!