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. 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). 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. 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. 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). 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...
