El 04/03/14 16:48, Farès Hantous escribió: > > 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 >
Hi Very interesting module, I don't know if you see the blueprint of payroll module [1], you based on that? regards [1] http://code.google.com/p/tryton/wiki/PayrollModule -- Lic. Pablo A. Vannini gcoop - Cooperativa de Software Libre Velasco 508 Depto A www.gcoop.coop 005411-4855-4390 Buenos Aires - Argentina
