Módulo de OpenERP para cuotas

Nuestra primera entrada de contenido en el blog ha quedado un poco densa, pero eso es debido al tema tratado y que nuestro objetivo es que quede perfectamente explicado todo el comportamiento del módulo, como si de un manual de usuario se tratara. Buena lectura y, cualquier duda, en los comentarios...

Motivación del módulo

Es frecuente en muchas empresas de servicios tener contratos establecidos en los que se factura una cantidad periódica para sus productos. Es lo que en muchas ocasiones se denomina también como cuotas .

OpenERP no incorpora un mecanismo oficial para cubrir este tipo de casuística, y otras soluciones manuales o bien mediante módulos de la comunidad no cubren al 100% o no lo hacen de forma cómoda. Hagamos un repaso a las posibles soluciones existentes:

  • Manualmente , duplicando un pedido o una factura ya existente (el pedido/factura inicial creado cuando se da de alta el contrato), y estableciendo la nueva fecha. Obviamente este método es proclive al error por olvido de alguna de las cuotas, sobretodo cuando se maneja gran cantidad de ellas.

  • Con el módulo subscription . Con este módulo se puede automatizar la creación de documentos en general con una periodicidad establecida a partir de un documento plantilla. El problema es que hay que tener un documento plantilla para cada posible combinación de productos/servicios, ensuciando y haciendo liosa la pantalla en la que se muestren dichos documentos. Otra pega a este módulo es la de que todos los documentos se generan en estado borrador.

  • Con el módulo sale_subscriptions . Este módulo del que tuvimos conocimiento hace poco creado por & Domsense , facilita algo más la tarea centrándose en la creación de presupuestos (pedidos de venta en borrador), pero tiene los siguientes inconvenientes:

    • No permite incluir descuentos, teniendo que establecer precios personalizados de manera absoluta, haciendo mucho más difícil la lectura de los pedidos.

    • Sólo permite incluir un producto por cada suscripción, impidiendo realizar cuotas complejas como las que suponen los servicios base + complementos que ofrecen muchas empresas.

    • Tampoco define un mecanismo para renovación de las cuotas, por lo que al término del plazo establecido, hay que renovar manualmente la suscripción.

  • Con la colección de módulos account_invoicing_* creados originalmente por Alistek Ltd. , y posteriormente adaptados para la v6.0 y ampliados por Avanzosc . El resumen de estos módulos es fácil: se puede hacer lo que se quiera. El problema es la complejidad que supone la definición de las reglas a crear para cada cuota. Desde luego, cuando la facturación depende de variables (como la tarificación de la luz o del teléfono), esta solución es la única lo suficientemente flexible para dichas tareas.

¿Por qué pedidos de venta?

O dicho de otro modo, ¿por qué no facturas periódicas? La respuesta a esto radica en un factor que en muchas empresas se tiene en cuenta: la previsión de ingresos . Los contratos firmados suponen unos ingresos ya garantizados que normalmente se quieren controlar.

Una posible solución es recurrir a la analítica para anotar esos ingresos, pero este método complica el acceso a la información, limitándolo al “mundo contable” (decimos esto porque, aunque en OpenERP el enfoque de las cuentas analíticas es más de gestión que de contabilidad, el concepto sigue estando muy ligado a la Contabilidad y muchas empresas sencillas rehúsan de este sistema precisamente por evitar complicaciones en su gestión).

El Análisis de venta que se encuentra dentro de Ventas → Informes es una fuente muy jugosa y accesible de información como para ignorarla. Con este informe se puede establecer entonces una regla en la que cuando se consulten datos desde el día de hoy haciendo adelante, todos los datos de pedidos (sean en borrador o confirmados), serán ingresos de venta.

Para quien prefiera la solución con facturas, en la próxima entrada hablaré sobre otro módulo desarrollado que toma este enfoque.

El módulo sale_recurring_orders

Sin más preámbulos (que ya han sido bastantes), presentamos el módulo creado al efecto para gestionar estas cuotas: sale_recurring_orders . El módulo está diseñado para la versión 6.0, aunque no creo que haya demasiados problemas para utilizarlo en la 6.1 (a lo mejor con mínimos cambios). Si alguien puede comprobarlo y dejar en los comentarios si funciona, sería de agradecer.

Se puede obtener desde launchpad utilizando Bazaar con el comando:

bzr branch lp:serviciosbaeza-openerp-addons

O examinar su código en la página:

https://code.launchpad.net/serviciosbaeza-openerp-addons

Los contratos

La definición de las cuotas se realiza mediante el denominado contrato. Para la definición de los mismos hay que acceder desde el módulo de Ventas al apartado Ventas → Pedidos de venta periódicos (Contratos) .

Un contrato incluye los siguientes datos:

  • Nombre : Un nombre que permita identificar a dicho contrato. Es un texto libre que se puede utilizar a discreción del usuario según le dé uso. Por ejemplo, incluir un resumen de los conceptos de la cuota.

  • Nº contrato : Establece un número automático para identificar de manera única a cada contrato. También se puede establecer manualmente si así se desea.

  • Activo : Casilla estándar para activar o desactivar el contrato.

  • Cliente : Cliente para el que se van a generar las cuotas. El comercial asignado en el pedido de venta que se genera será el que tenga el cliente asignado en su ficha.

  • Compañía : Compañía que firma el contrato y para la que se generarán los pedidos (sólo útil en entornos multicompañía).

  • Fecha de inicio : Fecha en la que se comienza el contrato. En esa fecha se generará el pedido inicial, y es la que sirve para calcular los plazos para las siguientes cuotas.

  • Prolongación : Este campo sirve para definir el plazo de duración del contrato, y puede tener tres valores:

    • Plazo ilimitado : La renovación de la cuota se realiza de manera automática hasta que el usuario dé de baja el contrato. Normalmente la mayoría de cuotas llevarán este plazo.

    • Plazo fijo renovable : La renovación de la cuota se debe realizar de manera manual. Este plazo está pensado para aquellos contratos que requieran una revisión antes de su renovación. En este caso, en la pantalla aparece una nueva pestaña llamada Renovaciones , y un botón llamado Renovar contrato , que sirve para realizar manualmente la renovación del contrato.

    • Plazo fijo : Se establece un periodo fijo que no se podrá renovar, por lo que habrá que firmar un nuevo contrato al término de éste. No suele ser un caso muy extendido.

  • Intervalo y Unidad de tiempo : Sólo visibles cuando se escoge plazo ilimitado o plazo fijo renovable en el anterior campo. Establecen el periodo de tiempo para el que se establece el contrato. En el primero se establece la cantidad numérica y el segundo establece la unidad: días, semanas, meses o años. Este periodo de tiempo se define para el contrato, pero no para la periodicidad de los pedidos: por ejemplo, se puede tener un contrato que se renueva anualmente, pero cada mes se factura una cuota.

  • Fecha de finalización : Sólo visible si se ha escogido plazo fijo en el campo Prolongación . Establece la fecha en la que terminaría el contrato.

  • Líneas : Pestaña en la que se pueden definir las líneas del contrato, y que se detallan en el siguiente apartado.

  • Pedidos : En esta pestaña van apareciendo los pedidos generados por el módulo, con información del número de pedido, una casilla que indica si el pedido ha sido confirmado por el módulo, y una flecha verde para poder acceder directamente al pedido.

  • Renovaciones : Es una pestaña sólo visible cuando se ha escogido plazo fijo renovable que muestra una lista con todas las renovaciones manuales realizadas en dicho contrato, con la fecha en la que se hicieron y un campo de comentarios libre introducido en el momento de la renovación.

  • Notas : En esta pestaña se puede introducir cualquier texto libre que se quiera añadir al contrato.

Las líneas del contrato

En cada una de las líneas del contrato, se establece cada uno de los productos que forman parte del contrato, y se pueden mezclar aunque tengan distintas periodicidades (siempre que la fecha de comienzo sea la misma). Por ejemplo: mensualmente se factura una cuota de mantenimiento y anualmente una revisión que hay que realizar obligatoriamente.

Éstos son los campos que apareen dentro de cada línea:

  • Producto : Establece el producto para el que se va a generar una cuota.

  • Activo : Casilla que permite desactivar la generación de las cuotas para ese producto sin tener que borrar la línea.

  • Descripción : Se rellena automáticamente con la descripción del producto, pero permite cambiarla por cualquier otro texto, que será el que conste en el pedido generado.

  • Cantidad del producto : Cantidad que se pondrá en el pedido generado.

  • Precio del producto : Precio al que se pondrá el producto en el pedido generado. IMPORTANTE: Si se deja su valor en 0, se cogerá el PVP del producto, permitiendo con este mecanismo el no tener que modificar todos los contratos cada vez que haya una subida de precio, como por ejemplo por el IPC.

  • Descuento : Descuento personalizado del producto para este contrato.

  • Intervalo de los pedidos y Unidad del intervalo de los pedidos : Con estos dos datos, de igual forma que funcionaba en los contratos, establecemos la cantidad numérica y el periodo para el que vamos a generar los pedidos para este producto.

  • Notas : Campo de texto libre para indicar cualquier otro dato como referencia.

Mecanismo de generación de pedidos

Los pedidos procedentes de los contratos se pueden generar de dos formas:

De manera manual

Cuando se crea el contrato, en la parte inferior aparecen dos botones:

  • General pedido inicial : Este botón permite generar un pedido que incluye todas las líneas del contrato en la fecha de inicio del contrato, y que se genera directamente en estado confirmado. Esta generación es opcional y sólo aparecerá disponible de manera manual mientras no se genere ningún pedido para el año siguiente (sea de forma manual o automática). La razón para este comportamiento es debido a la propia naturaleza de las cuotas: muchos de los contratos comienzan su facturación con la finalización del periodo establecido, no con el inicio.

  • Generar pedidos para el año siguiente : Este botón permite generar todos los pedidos que correspondan dentro del marco temporal de un año a contar desde la fecha en la que se pulsa el botón. El comportamiento de esa generación dependerá del tipo de prolongación definida en el contrato:

    • Si el contrato tiene plazo ilimitado, se generarán todos los pedidos dentro del año siguiente, independientemente de la siguiente fecha teórica de renovación.

    • S i el contrato tiene plazo fijo renovable, se generarán todos los pedidos hasta el año siguiente o hasta la siguiente fecha de renovación (la menor de las dos fechas).

    • Si el contrato tiene plazo fijo, igualmente se generarán todos los pedidos hasta la menor de las dos fechas: el año siguiente o el final del contrato.

De manera automática

Con la instalación del módulo, se crea una tarea que se ejecuta automáticamente todos los días una vez, y que realiza para cada uno de los contratos activos la misma acción que si pulsáramos el botón Generar pedidos para el año siguiente en el mismo.

Confirmación de los pedidos

Todos los pedidos salvo el inicial se generan en estado Presupuesto (borrador), para evitar confundir los pedidos generados con este método con los creados manualmente. Es por eso que también el módulo incluye una tarea programada todos los días que confirma automáticamente los pedidos procedentes de los contratos que tiene fecha del día.

De esa manera, no es necesario preocuparse de cuáles son las cuotas que hay que confirmar, y simplemente una revisión de la pantalla Ventas → Facturación → Líneas a facturar permite controlar en el flujo de gestión diario las cuotas a facturar, ya que en dicha pantalla sólo aparecen los pedidos confirmados.

Futuras ampliaciones

Aunque la base establecida con este módulo es bastante amplia, aún queda mucho lugar a mejoras. La principal es la de establecer un sistema de alertas para los clientes o los usuarios encargados de gestionar los contratos, en la que ya estamos trabajando.

Se admiten de todas formas sugerencias sobre el mecanismo para dichas alertas o para otras posibles mejoras. Utilizad los comentarios de esta entrada para ello.

Comentarios

# Tawa 25-07-2012 17:45
Tried the module on oe6.1 and it bombs out!

2012-07-25 15:42:42,309 21792 ERROR ? openerp.sql_db: Programming error: operator does not exist: integer = boolean
LINE 1: ...WHERE m.model = 'res.partner.ad dress' AND gu.uid = false
^
HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts.
, in query SELECT MAX(CASE WHEN perm_read THEN 1 ELSE 0 END) FROM ir_model_access a JOIN ir_model m ON (m.id = a.model_id) JOIN res_groups_user s_rel gu ON (gu.gid = a.group_id) WHERE m.model = %s AND gu.uid = %s
Responder | Responder con una citación | Citar
# Pedro M. Baeza 25-07-2012 17:49
Hi Tawa:

The module has been developed for 6.0, and I suppossed that there must not be too much problem to work on 6.1, but it isn't.

Next week, I'll try to see if we can adapt it to 6.1.

Regards.
Responder | Responder con una citación | Citar
# Adrian Soto 13-08-2012 07:18
Que tal Pedro:

Haz podido adaptar el modulo para que trabaje en la v6.1 ??

De ser asi me puedes enviar el link parar descargarlo.

Gracias por tu ayuda Pedro.

Saludos.
Responder | Responder con una citación | Citar
# Pedro M. Baeza 13-08-2012 10:57
Buenas, Adrián:

Pues aún no he podido mirar nada con la 6.1. Es que son muy malas fechas, jeje.

De todas formas, según estuve viendo con él, el problema que comentaba Tawa (el del primer comentario), puede no deberse a la versión, sino a problemas con su BD. ¿Has probado tú el módulo?

Un saludo.
Responder | Responder con una citación | Citar
# Pedro M. Baeza 18-09-2012 13:08
Buenas Adrián:

Ya está adaptado el módulo a la versión 6.1. Puedes encontrar los detalles para descargarlo en la nueva entrada del blog.

Un saludo.
Responder | Responder con una citación | Citar
# Adrian 18-09-2012 15:49
Gracias Pedro, voy a probarlo.

Saludos
Responder | Responder con una citación | Citar
# Tawa 26-08-2012 00:22
Peter, Have you had time to test with 6.1 yet? I have tried with fresh DB to no avail.
Responder | Responder con una citación | Citar
# Pedro M. Baeza 18-09-2012 13:06
Dear Tawa:

As you can see in the new blog entry, module has been adapted for 6.1. Try it and comment us if you have any problem.

Regards
Responder | Responder con una citación | Citar
# Canary 25-09-2012 21:37
Hola, he intentado utilizar el modulo pero al intentar generar el primer pedido o pedidos para el siguiente año me arroja el siguiente error (usando la 6.1):
.
.
File "/usr/local/lib /python2.6/dist -packages/opene rp-6.1_1-py2.6. egg/openerp/sql _db.py", line 212, in execute
res = self._obj.execu te(query, params)
ProgrammingError: operator does not exist: integer = boolean
LINE 1: ...HERE m.model = E'res.partner.a ddress' AND gu.uid = false
^
HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts.

Parece que la consulta que se le lanza a la BBDD lleva una funcion y se le estan enviando los parametros de forma incorrecta.

Como se podria solucionar
Responder | Responder con una citación | Citar
# Pedro M. Baeza 26-09-2012 01:56
Estimado Canary:

¿Has utilizado la versión del módulo para OpenERP 6.1?

De todas formas, uno de los errores que observé y también corregí en sendas actualizaciones a ambas versiones es cuando el cliente al que se le hace un contrato no tienen ningún comercial asociado. Revisa también este punto.

Un saludo.
Responder | Responder con una citación | Citar
# Canarycloud 28-09-2012 23:14
Muchas gracias, lo probare
Responder | Responder con una citación | Citar
# Adolfo 23-10-2012 13:55
Que tal Pedro.

Tengo el caso de una empresa cuyas cuotas mensuales deben ser generadas los días 1 de cada mes. Si un cliente se da de alta el día 20 de agosto, por ejemplo, se le cobra el proporcional hasta septiembre, es decir esos 11 días. Entonces,

1) el módulo hace el cálculo de este proporcional, por un lado, y

2) entiendo que se puede elegir la fecha a partir de la cual comienza el contrato.

Muchas gracias y felicitaciones por el trabajo.

Adolfo
Responder | Responder con una citación | Citar
# Pedro M. Baeza 23-10-2012 19:00
Buenas Adolfo:

Me temo que el módulo no está preparado para la casuística que comentas en el caso 1, ya que el cliente para el que lo desarrollamos no tenía esa necesidad.

Sin embargo, puesto que la base establecida realiza la mayoría del trabajo, adaptar el módulo para ese caso no supondría demasiado desarrollo y si estáis dispuestos a financiarlo, saldría muy barato, pero entiende que no podamos hacerlo si no es de esa manera. Contacta conmigo directamente y te doy más detalles.

Con respecto al punto 2, efectivamente la fecha de comienzo del contrato se puede elegir cuando se define el contrato.

Un último comentario que te quería hacer es que la generación de cuotas también está tratada desde el punto de vista de las facturas, que tal vez os pueda resultar más interesante dependiendo de vuestras necesidades. La última entrada del blog habla sobre este otro módulo.

Gracias por el interés.

Un saludo.
Responder | Responder con una citación | Citar
# David Deluria 30-10-2012 14:05
I tried your module and my only problem is that recurring orders I create can't add a tax unlike the standard sales order that allows you to set a tax.
Responder | Responder con una citación | Citar
# Pedro M. Baeza 30-10-2012 14:14
Dear David:

Taxes in the generated sale orders are fetched from product definition and fiscal position of the customer, so there should be no problem with all the posible combinations as long as you properly set both.

If you have the unsual case of having specific taxes for one customer, you can create a product defining that taxes.

Regards.
Responder | Responder con una citación | Citar
# David Deluria 30-10-2012 16:17
Thank you. I was able to get it to work.

Now I'm trying to modify the menu because in english the more proper term is "Continious Service Agreements" instead of "Recurring order agreements". I will probably use the term CSA to make the menu as compact as possible (for tablet users).
Responder | Responder con una citación | Citar
# Percy Mostacero 20-01-2014 22:26
Me interesa contactarme con usted. Pedro me hace llegar un correo o un teléfono

Saludos

Percy Mostacero
Responder | Responder con una citación | Citar
# Pedro M. Baeza 20-01-2014 22:42
Estimado Percy,

Mi correo es .

Un saludo.
Responder | Responder con una citación | Citar
# Ferdinando Ferreras 19-03-2013 20:09
Saludos Sr. Pedro.

Tengo Algunas Interrogantes que me gustaria saber si el modulo la tiene y si no, que sea considerara para un PLUS.

Primera
Tiene este modulo la capacidad de colocarle al contrato los dias de gracias o creditos que tendra cada cuota generada para saber si esta en vencimiento o no ?

Se le puede colocar un porcentaje de penalizacion por mora o falta de pagos para aquellas cuotas que exceden su fecha tope para recibir el pago?


De todos modos los felicito desde Rep. Dominicana
Responder | Responder con una citación | Citar
# Pedro M. Baeza 20-03-2013 00:53
Estimado Ferdinando:

Me temo que estás confundiendo la funcionalidad del módulo: este módulo sólo se encarga de generar los pedidos de venta (también tenemos otro que genera facturas, que está en otro blog), pero el resto de la gestión se delega en el estándar de OpenERP, por lo que la primera funcionalidad se establece con el plazo de pago que se le ponga al cliente, y la segunda es más de la parte contable, pero me temo que no está disponible en el estándar de OpenERP. Habría que buscar algún otro módulo de la comunidad (si lo hubiere) que lo realice.

Un saludo.
Responder | Responder con una citación | Citar
# Andrey Villegas 06-11-2013 16:23
Hola, muy interesantes tus aportes. Te quería hacer una pregunta con respecto a los módulos. Para utilizar el módulo sale_recurring_ orders es necesarío instalar también los otros dos módulos que se encuentran en LP? Es que yo solo instale el "sale" y los pedidos de venta no se me generan, aún colocandolos para generación diaria. Gracias
Responder | Responder con una citación | Citar
# Pedro M. Baeza 06-11-2013 18:13
Hola, Andrey, no es necesario ningún otro módulo de los de LP (si no, estaría puesto como dependencia). El proceso de generación de pedidos se realiza de forma manual pulsando en el botón del contrato, o hay que esperar a que se ejecute una vez al día la tarea que genera esos pedidos de forma automática. Poner la periodicidad como diaria lo único que hará es que en lugar de que se cree un pedido (si es anual) o 12 (si es mensual), se hagan 365.

Un saludo.
Responder | Responder con una citación | Citar
# Andrey Villegas 07-11-2013 00:35
Muchas gracias por la pronta respuesta Pedro M. Ok voy a revisar que estaré haciendo de manera erronea, ya que no veo que se generen más pedidos de manera automática.
Responder | Responder con una citación | Citar
# Jesus Soliva 18-12-2014 20:23
Hola, estaría interesado en probar el módulo. ¿Está adaptado a la versión odoo 8?. Gracias.
Responder | Responder con una citación | Citar
# Pedro M. Baeza 26-12-2014 20:56
Buenas, Jesús,

He migrado el módulo account_periodi cal_invoicing a la v8 aquí: cal_invoicing

Un saludo.
Responder | Responder con una citación | Citar