Hola Jose Manuel, bienvenido a la comunidad!
Por el momento nadie ha avanzado con el desarrollo de estas funcionalidades. De todos modos, seria interesante que nos expliques las necessidades de México para poder comprobar que la propuesta de diseño cumple con vuestros requisitos también.
UN saludo,
Hola Sergi,
Las necesidades en México son desde un registro de asistencia que se puede realizar con una interface de un biométrico, o reloj checador de asistencias, cumplir con un expediente digital, que incluya experiencia laboral, y documentación de identificación oficial.
Con respecto a la nomina, la necesidad se enfoca al calculo de las percepciones y deducciones, en estas ultimas de incluye la retención de impuestos de ISR (impuesto sobre la renta que se calcula en rangos de salario de acuerdo a una tabla), asi como la retención de IMSS (seguridad social).
Hay empresas que tienen hasta 100 ó mas conceptos de nomina (percepciones y deducciones) los cuales hace compleja su operación, por ello se debería tener un modulo en el cual se puedan generar nuevos conceptos junto con su mecánica de calculo de cada uno..
adicional a esto se requiere que también se presente un Recibo de nomina (Liquidación de pago) por cada pago generado que puede ser semanal, quincenal o mensual, esto de acuerdo a las especificaciones de cada empresa. este recibo va timbrado (es un proceso similar a una factura electrónica), a través de un tercero (empresa que certifica un archivo XML) que envía al gobierno y lo regresa con un sello digital.
Estos son requerimientos a grandes rasgos;
Como ejemplo estos son algunos software de paga, con los cuales se ah cubierto la necesidad :
Contpaqi: https://www.contpaqi.com/nominas
Aspel Noi: Sistema de nómina en línea | Siigo Aspel NOI
Meta4: https://www.meta4.com.mx/mx/software-de-nomina-mexico#ventajas
Espero esto ayude y pueda contribuir de mi experiencia en el desarrollo de este modulo..
Un Saludo!!
El registro de asistencia esta ya dispoinble en el modulo attendance
El hecho de hacer pago semanales/quincenales va relacionado con anticipos de nomina o mas vien que se hacen la nomina con esta periodicidad?
Mi pregunta es por si es realmente necessario hacer otro modulo para generar los anticipos o no.
Los pagos se hacer con esta periodicidad, puede ser: semanal, quincenal, catorcenal o mensual,
Pero la periocidad del pago se corresponde con la periodicidad de la nomina o van de forma distinta?
El pago se produce antes o despues del devengo de la nomina?
La periodicidad corresponde al pago de la nomina; y el pago se produce después del devengo de la nomina..
El periodo de nómina se refiere al momento en el que las nóminas laborales deben ser elaboradas.
Las nóminas por tiempo son las que dependen del tiempo en el que se paga el salario. Se dividen en cuatro tipos:
Nómina semanal: Es cuando los trabajadores reciben su salario cada semana.
Nómina catorcenal: Aquí, el salario se paga cada 14 días. Algunos la confunden con la quincenal, pero no son lo mismo.
Nómina quincenal: El salario se paga cada 15 días.
Nómina mensual: Se paga el salario de los trabajadores cada 30 días. Sin embargo, dependiendo del caso, se puede ajustar a 28, 29 o 31 días.
Cuando se habla de nóminas por tiempo, las más comunes son la quincenal y mensual.
Existen también periodos de pago de nomina extraordinarios, como un pago anual por gratificación, también un pago de nomina extraordinario por alguno bono, o por reparto de utilidades de las empresas..
Para esto es importante que en el sistema, cada empresa pueda defina sus periodos de nomina. (un calendario de nomina)
Hi Sergi. I tried to write down how it works here in Switzerland and als wrote down what should be calculated in which way. If you’d like to go on, I’d ask professional staff to help us tryton.cloud: wages module - Google Sheets
Hi all
Is there a way to go on here and producing such a payroll module? I’m interested and could carry a part of the development cost. Wo could spend time and money too? What about a new Sponsoring - Tryton Discussion ?
Hello to All,
It’s been a while since this post started the discussion about a potential payroll module. I would like to know what’s the status with it and how can I contribute with coding or other means. I need to start working on migrating some legacy payroll apps to Tryton, hence the question whether to write my own module or contribute to a existing one.
Anyone has any insights on this matter?
Hi Richard,
No code had been started so far, so if you start it will be great if you can share it somewhere so we can evolve it on the future.
Thanks for the reply. I will put my code in github and later share the link over here.
Dear Richard. Great news. I’d love to support your project. So if you have a version and would like to bring it closer to the features we need (see my description) I could partly finance your work. Just get in contact with me for details. Merry Christmas, Stefan
May I ask you to publish and maintain the code at Tryton Community. This will allow others to find it more easily and fosters collaboration. If this is not an option, I strongly recommend to use a democratic hosting platform, e.g. codeberg.org.
I haven’t finish working on the code. I will consider your suggestions when I am ready to upload. I was busy lately doing the 7.8 migration and cleaning up some other modules. Thanks for the tips.
Hope you will have the time to upload the module, so the community can benefit from it.
Thanks!
I would like to start work inmediatly in a Tryton Payroll management for official Tryton. Which are the official steps to begin a module?, I need to start in my own repository and next share in this post?, Some else have repository already?
Before starting to code this module, I have read your post and each one of your opinions to take into consideration in the design of this module. The next is a purpose for creating the base of a sustainable and scalable payroll module that in the future could be extended to specific rules for each country, for example, “payroll_us,” “payroll_co,” etc… There are many thinks to take in cosideration but is a concept or a serie of modules in the Tryton environment.
MVP (Minimum Viable Product) for a Payroll module in Tryton ERP.
| Attribute | Field Type | Required | Related Model | Notes |
|---|---|---|---|---|
| company | Many2One | Yes | company.company | Employer entity |
| employee | Many2One | Yes | company.employee | Worker |
| contract | Many2One | No | payroll.contract | Active contract |
| period_start | Date | Yes | - | Pay period start |
| period_end | Date | Yes | - | Pay period end |
| working_days | Integer | No | - | Computed |
| gross_amount | Numeric(16,2) | No | - | Sum earning lines |
| deductions_amount | Numeric(16,2) | No | - | Sum deduction lines |
| net_amount | Numeric(16,2) | No | - | Computed |
| amount_to_pay | Numeric(16,2) | Yes | - | Final amount |
| state | Selection | Yes | - | draft/posted |
| lines | One2Many | No | payroll.line | Detail lines |
| journal | Many2One | No | account.journal | Manual select |
| move | Many2One | No | account.move | Created on post |
Buttons: compute_rules, calculate_totals, post, unpost
| Attribute | Field Type | Required | Related Model | |
|---|---|---|---|---|
| payroll | Many2One | Yes | payroll.payroll | |
| concept | Many2One | Yes | payroll.concept | |
| amount | Numeric(16,2) | Yes | - | |
| type | Selection | Yes | - | earning/deduction |
| account | Many2One | No | account.account | |
| analytic_account | Many2One | No | account.analytic_account | |
| quantity | Numeric(10,2) | No | - | |
| rate | Numeric(10,4) | No | - |
| Attribute | Field Type | Required | Related Model | |
|---|---|---|---|---|
| name | Char | Yes | - | |
| code | Char | Yes | - | |
| type | Selection | Yes | - | earning/deduction |
| account | Many2One | No | account.account | |
| rule | Many2One | No | payroll.rule | |
| default_amount | Numeric(16,2) | |||
| is_taxable | Boolean | No |
Standard Concepts: Salary, Overtime, Bonus, Commision, Social Security, Income Tax, Vacation
| Attribute | Field Type | Required | Related Model | |
|---|---|---|---|---|
| employee | Many2One | Yes | company.employee | |
| contract_type | Many2One | No | payroll.contract_type | |
| start_date | Date | Yes | - | |
| end_date | Date | No | - | |
| salary | Numeric(16,2) | No | - | |
| schedule | Selection | No | - | monthly/biweekly/weekly |
| working_hours | Numeric(5,2) | No | - |
| Attribute | Field Type | Required |
|---|---|---|
| name | Char | Yes |
| code | Char | Yes |
| schedule | Selection | No |
| working_hours | Numeric(5,2) | No |
| Attribute | Field Type | Required | Related Model | |
|---|---|---|---|---|
| name | Char | Yes | - | |
| code | Char | Yes | - | |
| formula | Text | Yes | - | PYSON |
| input_variables | One2Many | No | payroll.rule_var | |
| output_field | Selection | Yes | - | amount/quantity/rate |
| active | Boolean | No | - | True |
| Attribute | Field Type | Required | Related Model | |
|---|---|---|---|---|
| rule | Many2One | Yes | payroll.rule | |
| name | Char | Yes | - | |
| source | Selection | Yes | - | fixed/field |
| source_value | Numeric(16,2) | No | - | |
| source_field | Many2One | No | payroll.concept |
I do not understand how the rules are converted into payroll lines.
I’m wondering if a company can have payroll in a different currency than its accounting.
To compute the working days, you need a calendar of holidays and also a definition of the working days (some countries may work on Saturday other not etc.)
I think the coupling with the accounting should be optional. Some companies may only want to calculate the working days, others to calculate the full payroll and finally some will want to do the full accounting.
In case of full accounting, I do not think it is good to make a move per employee because this will leak personal information into the accounting. I think the accounting should be done grouped for all the employees of the same period.
I think the analytic should be separated (and probably only do by the rule engine).
I do not see how the amount, quantity and rate are filled by the rules?
I think there are some lines that are for the company eyes only.
I think a rule must have 2 evaluations: a condition and a calculation.
What is the purpose of this?
I think this is going in the wrong direction. In order to pay an employee you need to record the ‘life’ of the employee in the company. So when the employee started to work for the company, which contract and working hours, days and weeks, how many holidays they have etc.
During the ‘lifetime’ of an employee at the company there are job evaluations and based based on the result a new contract or the current contract is changed because the employee wants to work less hours, or have one day of every two weeks etc.
Also holidays have to be recorded and approved, or getting a day off or going home early. Sick leave etc all these things have to be recorded. Even tracking the time by the employee themselves or by using some electronic system. So an employee can leave one day early, but works the other day longer to compensate or work long hours because work must be done and they get overtime.
Based on those measures the first thing is to improve the invoicing of the worked hours to the customer eventually through the project module.
This means that first HR should be implemented before you can do something with payroll. The very last step IMO would be the financial part for the employee.