gemlog wrote:
We should may be provide an optionnal module that does this (adding 2
fields for first/last name, replacing the existing name by a function
computed on these 2 files). It's only a few lines of code.
So a normal 'Name' field and two others for first/last where IF
> first/last had content THEN they'd be concat together for the normal
> name field. Use or don't use. That would work for all I think.
> Thank you.
Also, I don't think I can just add a page(s) to the current HR view
> without effecting the original distro code with an include, correct?
No, you can do everything without modifying the original code, in a
separate module. See the modules product_expiry for info, or
account_tax_include.
In a few word:
Make your object that _inherit or _inherits from the object you plan to
change.
Make your view that inherit from the view you plan to extend. To add a
page its something like:
<model record="ir.ui.view" id="myid">
...
<inheritd_id eval="hr.id_of_the_view_to_extend_in_hr_module"/>
<arch type="xml">
<notebook position="inside">
<page string="My Page">
<field name="myfield"/>
</page>
</notebook>
</arch>
</model>
> I do not ever want to change distro code, because that only creates a
> maintenance nightmare. I thought to implement by inheriting both table
> and views into a 'replacement' HR module and control it by only
> displaying the replacement to users. This 'feels' like the correct
> way with how terp is laid out.
It's not a replacement hr_module, it's an extra "hr_payroll_base" module
that will extend through inheritancy the existing hr module and add (or
modify) some fields.
Then, others countries will inherit from the hr_payroll_base module and
add their specificities. So I think it could be very helpfull if you can
design in 2 modules:
* hr_payroll_base
* hr_payroll_ca (depends on hr_payroll_base but with canadian
specificities, default data, demo data...)
If you replace the hr module, others modules depending on it will not
work anymore: hr_timesheet, hr_skill_management, hr_expenses, ...
Is there any merit at all to the notion of generic dr/cr as discussed
> above? If not, all payroll writers will pretty much start from scratch
> each time I think.
I suppose it has if you said that :) ...because I have no idea on what's a
dr/cr rule.
As far as I know, it seems to exist 2 different ways of computing
payroll in the world (+variants or exceptions for all countries):
1. A system of rules that apply debit/credit depending on criterions,
2. A grid that does the relation between gross/net
In belgium, we use the system 1.
Thanks,
--
Fabien
Control your software source code and you control your business.
Tiny ERP: Own the source for free. What are you waiting for?
-- Marty Tennison, 2006
_______________________________________________
Tinyerp-users mailing list
http://tiny.be/mailman/listinfo/tinyerp-users
