nuevo módulo de liquidación de sueldos para Chile: l10n_cl_payroll

[Daniel Blanco]

Estimados:

Les paso un nuevo módulo que está liberado en Odoo Apps y en Odoo Chile: l10n_cl_payroll.

La mayoría de los aportes del módulo son de Nelson Ramirez, quien se vinculó a nosotros hace poco. Yo porté el módulo a la API de Odoo 8, y pude certificar el desarrollo mediante TravisCI. Es decir el módulo cumple con los test delineados por la OCA (Odoo Community Association) en cuanto a la calidad del código.

Permite la liquidación de Sueldos, y otras características.

Lo pueden descargar desde Odoo Apps o desde Github.

Este post de nuestro blog, explica cómo funciona (más de 1 hora). También es una conversación coloquial con Nelson y yo, intercambiando opiniones, de funcionamiento, formas de mejorarlo, etc. 

http://blancomartin.cl/blog/novedades-odoo-1/post/liquidacion-de-sueldos-para-odoo-chile-13

Esperamos incorporar en breve, nuevas características, como la toma de datos automática desde Previred y el envío del archivo también a Previred.

Espero tener feedback de Uds.... prueben y me avisan. Preferentemente los invito a publicar los issues y consultas en www.odoochile.org.

Saludos.

Daniel Blanco

Blanco Martín & Asociados

[Pedro Ortiz Escandor]

Estimado Daniel si el módulo funciona impeke me comprometo a ayudar para liberar la localización para Chile del Open en forma definitiva....soy Contador General y Analista Tributario con más de 20 años de experticie...y me ha tocado localizar varios ERP....te aviso...Saludos

El 22/10/15 a las 02:05, Daniel Blanco escribió:

--
Has recibido este mensaje porque estás suscrito al grupo "openerp-chile" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a openerp-chil...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

-- 
Pedro Ortiz Escandor
Consultor Senior ERP
Open Source
BaaN,SAP
MicroStrategy

[Pedro Arroyo]

Arreglen por favor los tipos de cuenta que solo dan dolor de cabeza.

En recursos humanos no cache como integrar el análisis de asistencia con la nomina. tuve que hacer una localizacion de rrhh para open 7 e integre los descuentos de la caja, compras internas en cuotas y bonos por cumplimiento de venta con la nomina, pero la asistencia me jodio. no me quedo muy claro como maneja los turnos. Asiq ahi hay un buen tema tambien.

Saludos cordiales,
Pedro Arroyo M.

[Daniel Blanco]

Pedro, gracias por los comentarios..Sería bueno si quieres crear un hilo en www.odoochile.org para ir viendo los temas, y poder entender mejor tu observación.

[Daniel Blanco]

Está todo en github. en dos repositorios, por si acaso quieres colaborar:

github.com/odoo-chile es una organización en donde están todos los módulos separados, de manera que eventualmente se puede colaborar, con código o con issues ( ojalá ambas cosas ). Los lineamientos que mejor vimos para colaborar son los de costumbre (issue+solución en github, y los aportes en una rama propia, consultas que cualquiera puede responder, en www.odoochile.org).

En esta organización de github, están los módulos propios y forks de módulos que vimos que eran útiles a la lozalización sin que necesariamente los hayamos desarrollado nosotros.

y en este otro repo:  github.com/bmya/odoo-bmya-cl  están solo los módulos nuestros.

Ya que tocas el tema contable, hemos estado viendo además que el plan de cuentas actual no es suficiente por varios motivos, por lo cual estamos pensando una alternativa al modelo actual. Quizá esto sea para otro post diferente, pero gustaría saber sus opiniones y sugerencias también.

[Pedro Ortiz Escandor]

Daniel respecto al PGC el tema es claro, puedes usar el que tú quieras..ahora si me piden un base podría estar para las mipyme el que tiene el SII y para otras más grandes el de la SVS...pero aún así yo puedo tener las cuentas que quiera mientras me ajuste a estas disposiciones....respecto al RUT siempre he dicho que el desarrollo de CUBIC es malo....a mi no me interesa un sistema que me hace digitar demas como contable (agregar el CL)....no tiene sentido ...los sistemas en chile nativos es mientras menos digite mejor....sigo mirando los repósitorios...

El 29/10/15 a las 16:07, Daniel Blanco escribió:

[Pedro Arroyo]

el problema del plan de cuentas actual son los códigos de los tipos de cuentas (BG_ACC_10,BG_ACC_20,BG_ACC_30, etc...) cada vez que lo instalo tengo que reasignar los códigos de los tipos de cuenta (bank, asset, payable, receivable, etc...) para que los reportes por defecto los incluyan.

con respecto a la validación del rut, con el modulo vatnumber basta y sobra. No es necesario hacer mas desarrollos implementando el modulo 11 de nuevo. Si tanto problema es poner el prefijo CL entonces dejemos obligatorio el campo nacionalidad y que ingrese el rut solito para que por debajo se concatene el prefijo para la validación. Un desarrollo interesante seria la validación del rut con el SII, ya que el base_vat valida con el VIES de la UE. Acá se podría validar el RUT con la pagina para consultar información tributaria de tercero y aprovechar de rescatar el giro. Eso si estaría bueno.

Ideas q se me ocurren.

Saludos.

[Daniel Blanco]

Pedro, 

El tema de validación del RUT, que estás diciendo, por lo que veo en los usuarios, hace mucho ruido tener el rut con el CL delante. Por eso ya está resuelto mediante el conjunto l10n_cl_base_rut, el cual depende del l10n_cl_vat de CubicERP, para formatear el RUT. A Su vez, este módulo es usado por l10n_cl_invoice que es el módulo nuevo, el que permite en un único diario tener todos los documentos tributarios de ventas. Este módulo aún no está maduro, pero se le están haciendo modificaciones todo el tiempo, al menos por ahora. 

La propuesta de este módulo, es que internamente, utiliza los códigos de documentos tributarios del SII. La idea, es poder tener un esquema así, aparte de otros diarios:

- Un diario de ventas manual (documentos que no son DTE)

- Un diario de ventas electrónico (documentos que son DTE)

- Quizá otro diario de ventas con otros tipos de documentos tributarios (zona franca por ejemplo).

Si la empresa tiene casa matriz y sucursales, un conjunto de diarios de ventas de este tipo, para cada casa. Aunque podría no ser así, sino tener todos los dt de venta en un sólo diario.. según lo que el cliente quiera manejar.

A éste módulo lo considero una pieza clave para lo que se viene (dte).

El tema de tomar el RUT desde el SII, lo estuve analizando un rato, pero desconozco la existencia de un webservice para eso. Consulté a alguien del SII y no me supo responder. Por lo pronto los giros, los cubre el l10n_cl_partner_activities, con los códigos de actividad del SII también.

Lo que dices de los códigos de cuenta, los vamos a revisar para ver de qué se trata.

Gracias!

[ivan masias]

Hola desarrolle una version mejorada del l10n_cl_partner_activities, solo son unos pekeños cambios, sobre le toponymous lo mejore y agregue artas cosas eso tb lo puedo liberar y pueden hacerme sus comentarios. Sobre el tema de los rut tb hize unos pekeños cambios y desarrollos. Así que si los necesitan avisemen y los agrego al github comunitario. Saludos