Le 04/03/2014 20:07, Mark Hayden (local) a écrit :
Payroll can be complex--perhaps that is why it isn't a core Tryton
module (yet) and closed source systems often charge obscene amounts of
money for a license to such a module.
here is a preliminary list of the fields i need to add to employee /
party for payroll:
name, birth_date, gender, marital_status, nationality, national_id,
national_id_date, passport, passport_date, social_security_id
how do you think this should be done?
As far as how you want to do it, it largely depends upon if you want a
general purpose module or one tailored to your case.
it will be a basic and general module. everyone can add localization
extensions for his case.
for example where I live our "national_id" is called a "social
insurance number" or SIN and is like a "social security ID" in any
case. SINs do not expire and the date a SIN is issued is not tracked
(indeed an employer is not allowed to ask that infomation). Thus the
"national_id_date" is an invalid field for me and would always be
blank. Also, employers where I live are not allowed to collect
passport information (unless it is part of sponsoring a foreing worker
perhaps but it is not allowed for citizens).
with national_id, i mean identity card.
any way, with localization modules, the titles can be adapted
Thus only 6 of the 10 fields would be used for the vast majority of
employees. Considering this, if you intend to design a payroll module
that can apply to general cases it would be bad design to design a
data model involving a table with these fields as it would be
inefficient and awkward to deal with all the blank fields.
with localization modules, it is possible to hide fields / make adapted
views, ...
Also be aware that "party" does not mean "person". Parties are very
often corporate entities that have no gender and no "birth" date
(perhaps a founding date, but that is not relevant to most business
activity).
More appropriate would be to extend the "employees"
(party->configuration->employees). Employees records link to parties
and employees are generally "people" so would have birth dates and so
forth.
i considered a person as a party because i think these fields can be
used for other applications
example: in real estate in tunisia, customers are identified with their
id, birthdate, job,...
in tunisia, parties can be physical parties (individuals with or without
vat) or moral parties (companies)
Better yet instead of just extending employees directly you should
have a separate table/model for "employee_payroll". That way if an
employee quits or is fired, but is then re-hired later (or
circumstances change in other ways) multiple records could exist to
maintain history since some of the details can change (marital status,
position, salary, full/part time, contract/inside, etc).
with the current design, one employee can have many contracts with the
same company. so, it is currently possible to keep some of these tracks.
but, i will think deeper about this
the employee_payroll would have to be pretty general to support a
general case and so some info would be best stored in a key/value
table rather than as distinct fields in a table (like national_id_* or
passport fields which in some places are not relevant to payroll).
Because of the nature of payroll it has to be extended based upon
region/market the way chart of accounts is (account_de, account_fr,
etc). so the base payroll module has to be very general and configurable.
Hope this helps give you an appreciation of what payroll module would
involve. It is doable and would be very very welcome by many.
Perhaps we should see how openERP does it and emulate what works and
change what doesn't...
thank you for your answer
i will make a simple version, and i will follow the demands of the community
you can already install the version published in bitbucket to see what i
included in the views. for the moment, there is no workflow, no button,
no reports
