payroll module and extension of party module

[fares]

Hi,

I started working on a basic payroll module. It will be available here [1].
So, I needed to extend the party module to include some fields relative to individuals such as the birthdate, id number, first and last names,...
That's why I wrote this small module: party_person [2]
I think this feature (party_person) should be discussed and included in the basic party module for these reasons:
    - there are some applications that need this extension and it is better to normalize it
    - this will bring the party module closer to the carddav standard [3]

[1] https://bitbucket.org/fareshantous/payroll
[2] https://bitbucket.org/fareshantous/party_person-3.0
[3] http://en.wikipedia.org/wiki/VCard

[Cédric Krier]

On 04 Mar 07:59, fares wrote:
> Hi,
>
> I started working on a basic payroll module. It will be available here [1].
> So, I needed to extend the party module to include some fields relative to
> individuals such as the birthdate, id number, first and last names,...
> That's why I wrote this small module: party_person [2]
> I think this feature (party_person) should be discussed and included in the
> basic party module for these reasons:
> - there are some applications that need this extension and it is better
> to normalize it
> - this will bring the party module closer to the carddav standard [3]

I'm strongly against such module. It is wrong to consider everyone has a
first name and last name.
By the way, CardDAV is wrong on this topic.
See
http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[Farès Hantous]

Le 04/03/2014 17:11, Cédric Krier a écrit :
>
> I'm strongly against such module. It is wrong to consider everyone has a
> first name and last name.
> By the way, CardDAV is wrong on this topic.
> See
> http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
>

not everyone has a first and last name, but everyone has a name and a
birthdate

if you agree with this:
http://tools.ietf.org/html/rfc6350
there are fields for names, gender, birthdate ... and a field 'ORG' for
the organization name
no field is compulsory

[Cédric Krier]

On 04 Mar 17:53, Farès Hantous wrote:
>
> Le 04/03/2014 17:11, Cédric Krier a écrit :
> >
> >I'm strongly against such module. It is wrong to consider everyone has a
> >first name and last name.
> >By the way, CardDAV is wrong on this topic.
> >See
> >http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
> >
> not everyone has a first and last name, but everyone has a name and
> a birthdate

No, I don't agree about the name by the way we should think about
removing the required on it.
And about birthdate, it is not so simple: companies or other similar
entities like country don't have one or have many.

> if you agree with this:
> http://tools.ietf.org/html/rfc6350
> there are fields for names, gender, birthdate ... and a field 'ORG'
> for the organization name
> no field is compulsory

But none are needed in Tryton. More over, the RFC is not a design for a
relational database.

[Farès Hantous]

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?

[Mark Hayden (local)]

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.

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

[Farès Hantous]

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

[Pablo Vannini]

El 04/03/14 16:48, Farès Hantous escribió:

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

[Farès Hantous]

Le 04/03/2014 21:15, Pablo Vannini a écrit :
> 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

yes, the current design is inspired by that blueprint and by the openerp
module

[Luis Falcon]

Good morning Farès

On 04/03/14 15:59, fares wrote:
> Hi,
>
> I started working on a basic payroll module. It will be available here [1].
> So, I needed to extend the party module to include some fields relative
> to individuals such as the birthdate, id number, first and last names,...
> That's why I wrote this small module: party_person [2]

You might want to look at the GNU Health section on party demographics,
when the party is an individual (physical person). We already include
many indicators that will be shown only if the party is a person.

It's included in the health core module. Hope you find it useful.

Best,

> I think this feature (party_person) should be discussed and included in
> the basic party module for these reasons:
> - there are some applications that need this extension and it is
> better to normalize it
> - this will bring the party module closer to the carddav standard [3]
>
> [1] https://bitbucket.org/fareshantous/payroll
> [2] https://bitbucket.org/fareshantous/party_person-3.0
> [3] http://en.wikipedia.org/wiki/VCard

--
GNU Health : The Free Health and Hospital Information System
http://health.gnu.org
Twitter: @gnuhealth

[Farès Hantous]

Le 05/03/2014 11:28, Luis Falcon a écrit :
> You might want to look at the GNU Health section on party demographics,
> when the party is an individual (physical person). We already include
> many indicators that will be shown only if the party is a person.

yes, that is the kind of fields i am adding in the party_person module.
the question is:
is it useful to make a specific module with only the most used fields
that will be used by payroll, health, ...
or
should every module have its own party extension

[Vincent CARDON]

> yes, that is the kind of fields i am adding in the party_person module.
> the question is:
> is it useful to make a specific module with only the most used fields
> that will be used by payroll, health, ...
> or
> should every module have its own party extension
>

Perhaps this is not a good idea, but why not include in tryton an Active Directory based LDAP system like Samba4 to store employee data.

This can improve the value of tryton by allowing a better integration into existing enterprise systems, and it would provide a solid base for guidance on this issue.

just a thought.

--
Vincent CARDON, ingénieur commercial
TRANQUIL IT SYSTEMS
12 avenue Jules Verne
Bâtiment A (Alliance Libre)
44230 Saint Sébastien sur Loire (FRANCE)
tel: +33(0)240 975 755
site commercial: http://www.tranquil-it-systems.fr
site communautaire: http://dev.tranquil.it

[Farès Hantous]

Hi,

Here are some screenshots of what I am doing.
I used one2many fields to make the module adaptable to a wide range of cases.

For the moment, an administrator must write python code in wage rules.
This is a bad solution (security issue + not easy for the administrator).
So, I will change it when things will become clearer, or when we will
have a python parser.

For emloyee attributes, I will probably use a one 2many field in order
to make it fit all the cases.

Fares

[Cédric Krier]

Please avoid sending attached images on the mailing list.

[Luis Falcon]

On 06/03/14 16:36, Farès Hantous wrote:
> Hi,
>
> Here are some screenshots of what I am doing.
> I used one2many fields to make the module adaptable to a wide range of cases.
>
> For the moment, an administrator must write python code in wage rules.
> This is a bad solution (security issue + not easy for the administrator).
> So, I will change it when things will become clearer, or when we will
> have a python parser.

Thank you for the update on this important functionality !
Payroll is a tough cookie, but a having a general model will definitely
help. Country-based customizations will follow.

Best,

>
> For emloyee attributes, I will probably use a one 2many field in order
> to make it fit all the cases.
>
> Fares
>

[Artem Braga]

Hello. 

Was Payroll module developed and where is it available for review? 

Thank you 

Artem 

вторник, 4 марта 2014 г., 17:59:40 UTC+2 пользователь fares написал: