Para cubrir esa necesidad, hemos creado el módulo dx_sale_line_delivered, que mejora el módulo base y añade los siguientes campos a la linea del pedido:

• Enviado, cantidad enviada, obtenida de los albaranes asociados y validados, hasta que no se valida un albarán no lo tiene en cuenta.
• Stock real, el stock que hay en los almacenes.
• Stock disponible, es el stock de los almacenes restando el reservado y añadiendo el pendiente de recibir.

Con esto no sólo conoceremos el estado de envío de cada linea de pedido, sino que tendremos accesible también la información del stock real y disponible para poder estimar cuando podremos servir los productos restantes.

El módulo esta liberado bajo AGPL y está disponible en launchpad https://code.launchpad.net/~domatix/dx/6.1 y en http://apps.openerp.com/addon/7655

En primer lugar, enhorabuena al equipo de Avanzosc por la organización. No es una tarea fácil, y una vez más, el equipo de organizadores realizaron un trabajo excelente para facilitarnos a todos los presentes y conferenciantes nuestra asistencia. Recomiendo también la lectura del artículo-resumen «oficial» colgado en la página de las Jornadas.

Sobre el programa, un año más las presentaciones han sido expuestas por distribuidores/partners de OpenERP y por tanto mayoritariamente las preocupaciones y exposiciones son de carácter técnico y funcional, orientadas hacia la comunidad de desarrolladores. Aunque se habló de la posibilidad «censar» a los usuarios finales que se han «auto-implantado» OpenERP (algo imposible de realizar en la práctica, el censo, no la auto-implantación) y de que necesitan un lugar para exponer sus necesidades, carencias y problemática. Si bien lo cierto es que no hay una comunidad ni representación activa de los mismos, y orientar parte del tiempo o esfuerzos hacia éstos creo que no sería tan productivo como dedicar energías a tratar de atraer nuevos implantadores para potenciar la comunidad y que a su vez promuevan OpenERP para seducir a nuevos clientes potenciales y aumentar el número de implantaciones. En definitiva, la «comunidad» de OpenERP está formada por empresas que distribuimos OpenERP, y escuchamos las necesidades nuestros clientes, trabajando de una manera u otra para resolver dichas necesidades. Para soporte adicional, siempre se puede contar con OpenERP s.a.

Sobre las charlas, de varios tipos (nota: no es mi intención describirlas todas, esa tarea ya está realizada en la web oficial de las Jornadas):

Soluciones verticales, como siempre un trabajo excelente de las empresas desarrolladoras, con charlas más completas en gestión de granjas (de dos tipos, cría de animales y huevos), gestión de proyectos según Project Management Institute (excelente trabajo de Eficent), módulo para LOPD (que bien pudiera servir para la localización, ya que es aplicable a todas las empresas),  gestión de recursos para actividades lúdicas de Abartia, nuestra vertical de transportes, éstas dos últimas no se pudieron ver en directo debido a una caida de la conexión a internet.

Charlas ténicas: a destacar KafkaDB, propuesta para migración de módulos y datos entre versiones de OpenERP, MongoDB, una excelente alternativa para almacén de datos alternativo y complementario y BABI, un «embrión» de Business Intelligence para OpenERP.

Módulos para la comunidad: entre otros, el l10n_es_gestion_comercial, para la gestión de efectos comerciales (cobros y pagos), para el que estamos prestando nuestro apoyo y ayudaremos a dar un empujón y mejorarlo/terminarlo en breve. También a destacar la presentación de Omar Castiñeira, de Pexego para la gestión de la documentación de expedientes.

También vimos la presentación del nuevo proyecto de Carlos Liébana, Factor Libre, al que deseamos mucha suerte desde aquí, aunque no la necesite, excelente comienzo y previsiones aún mejores.

Para dar una nota de color, se presentó el «competidor comunitario» de OpenERP, Tryton. Nosotros mismos sugerimos la charla en la lista de correo, aunque finalmente fue realizada por el equipo de Nan-tic, elección acertada, pues ellos están involucrados muy activamente en la localización española y difusión del proyecto.

Una de las…

Después de testear varias alternativas para gestión de comisiones de agentes comerciales nos decidimos por trabajar con el módulo sale_commision. Este módulo permite la gestión de comisiones a agentes comerciales, pudiendo ser un agente comercial tanto un empleado como un autónomo u otra empresa. En cada venta se puede indicar si se desea asociar uno o varios agentes comerciales, y periódicamente se pueden liquidar las comisiones correspondientes a cada agente comercial según lo pactado sobre lo facturado.

En el módulo sale_commission se pueden configurar comisiones fijas o por tramos. Si se utilizan comisiones fijas se indica que comisión en tanto por ciento de lo facturado se va a pagar al agente comercial. Si se configura la comisión por tramos se podrá indicar que tanto por ciento se le va a pagar al agente comercial en función del total vendido.

Como ampliación de este módulo hemos definido otro tipo de comisiones, comisiones por descuento. Con este nuevo tipo de comisiones podemos configurar el sistema para que la comisión dependa del descuento que se aplica en la venta.

A parte de esta ampliación se ha modificado el campo de comisión en las lineas de factura para poder editarlo. De esta forma en una venta puntual se podría indicar manualmente la comisión que se paga al agente comercial.

Una posible próxima ampliación para el futuro es añadir poder pagar las comisiones no en función de lo facturado como funciona actualmente, sino en función de lo cobrado finalmente.