Odoo: almacenes, pedidos y reglas de reabastecimiento

Desde principios de año venimos trabajando en implantar un ERP (entreprise resource planning) en un hospital veterinario, el software elegido ha sido Odoo (conocido anteriormente como Open ERP). La ventaja de Odoo es que es una alternativa de código abierto a SAP ERP y Microsoft Dynamics… mi experiencia en este campo era nula y aun así se supone que dirijo el proyecto, supongo que es la ventaja de ser socio, que a ver quien me quita.

La intención era aprender… y qué mejor forma de hacerlo que comiéndote tu propia comida (eating your own dogfood).

En estos dos meses y medio que llevo en el proyecto he pasado por periodos de euforia en los que pensaba que estaba todo chupado e incluso estaba animado a migrar a Odoo también el CRM (SOHOVet) que en su día programamos para el Hospital y otros momentos de bajón en los que todo se nos ponía cuesta arriba y no conseguía ver la luz al final del tunel. Ahora estoy en un punto intermedio…

Por suerte la programación de este proyecto corre a cargo de Juan Ignacio Alonso de Grupo Vermon… que es un auténtico crack: profesor de C en la Universidad, investigador en el campo de la minería de datos (Redes Bayesianas y Grafos Cadena), robótica, análisis estadístico…en fin podéis leer algunas de sus publicaciones si estáis interesados en que os estalle la cabeza.

En definitiva, un tio increible con un talento y paciencia infinita (para soportarme) digno de ser nombrado junto con El Guerrero de la Carretera, El Faro y el Sabio.

Y aun disponiendo de un Genio a tiempo parcial el tema es dificil… incluso cuando piensas que debería ser sencillo (que es lo más desesperante), por ejemplo ahora estamos con la programación de las reglas de re-abastecimiento…

Os cuento de que va la película:

El Hospital Veterinario compra a distintos proveedores  productos, algunos son para auto-consumo (pueden ser comprados pero no vendidos), otros para vender a los clientes (pueden ser comprados y vendidos) y otros que se auto-consumen y además se venden. Hasta ahí todo claro, ¿verdad? Ahora vamos a ver las distintas situaciones que se pueden dar:

A – Saco de pienso de 7.5Kg:

• producto: saco de pienso de 7.5 KG (asi debe aparecer en el ticket)
• se compra: en unidades al proveedor.
• se vende: por unidades al cliente (saco).
• el precio de coste del producto: es el precio al que el proveedor te lo vende
• stock mínima: por ejemplo ponemos que tiene que haber siempre 2 en stock
• el proveedor suministra: en múltipos de 1 unidad

B – Pack de 6 latas de comida para gatos.

• producto: lata de comida para gatos (ticket del cliente)
• se compra: en packs de 6 al proveedor
• se vende: por unidades al cliente (lata)
• el precio de coste de la unidad: es el precio al que el proveedor te vende el pack dividido por el número de unidades que tiene el pack
• stock mínima: puede ser por ejemplo 3 latas.
• el proveedor suministra: en múltiplos de 6 unidades (aunque se puede dar el caso de que te venda medio pack por ejemplo, es decir, que el mismo se encargue de romper los packs antes de enviártelos y cobrarte una fracción del importe total… entonces podrían ser múltiplos de 3)

C – Pack de 4 cajas de antiparasitarios con 4 dosis cada uno y que se venden en dosis sueltas.

• producto: dosis antiparasitario (ticket del cliente)
• se compra: en packs de 4 cajas de 4 unidades, con lo que cuando entra un pack se deben anotar que entran 16 dosis.
• se vende: por unidades al cliente (dosis)
• el precio de coste de cada unidad: es el precio de coste del pack dividido por el número de dosis que contiene en sus 4 cajas.
• stock mínima: puede ser por ejemplo 3 dosis… de manera que cuando sólo queda una caja y está empezada se tienen que hacer un pedido.
• el proveedor suministra: en múltiplos de 16 dosis (4 cajas de 4 dosis)

¿Seguís vivos? ¿os habéis dormido ya? Vale, pues ahora otra vuelta de tuerca…

D – Cajas de pipetas que se compran en packs y se venden en pipetas sueltas… pero también se venden en cajas (a un precio más ventajoso para el cliente).

Para contemplar esa posibilidad hemos tenido que hacer un desarrollo que nos permite comprar «cajas de pipetas» (en unidades o packs) y transformarlos nosotros en «pipetas» a nivel de almacén. Escenifico:

1. Me entra un pack de 4 cajas de pipetas.
2. Vendo 3 cajas a un cliente, me queda una caja.
3. En el ticket al cliente hay que ponerle «3 – Caja de pipetas (100 unidades)»
4. El precio de coste de la caja es pipetas es el precio del pack dividido por el número de cajas que contiene.
5. Otro cliente viene y quiere comprarme 10 pipetas sueltas.
6. Para ello el programa transforma una caja de pipetas en 100 pipetas individuales (que es la representación dentro del programa del acto en el que el veterinario extrae 10 pipetas de una caja nueva… dejándola inservible para ser vendida como caja a otro cliente).
7. El precio de coste de la pipeta es el precio de la caja de pipetas dividido por el número de pipetas que contiene la caja.
8. En el ticket al cliente hay que ponerle «10 – pipeta individual»
9. Ahora tengo 0 cajas de pipetas y 90 pipetas sueltas (que son distintos productos, cada uno con su margen). Con la diferencia de que las pipetas individuales se pueden vender, pero no se pueden comprar al proveedor… se tienen que generar por nosotros a partir de cajas de pipetas enteras.
10. El stock mínimo en este caso se mide en número de cajas de pipetas enteras, si siempre quiero tener al menos una caja para vender y otra para abrir, tendré que poner un stock mínimo de 2 cajas, y en cualquier caso tengo que tener en cuenta que el proveedor me suministra en múltiplos de 4 cajas.

¿Qué os parece? Ahora a esto le tienes que sumar las distintas ubicaciones de los productos, el control de fechas de caducidad, las distintas tarifas de proveedores, los descuentos por compras por volumen, los distintos márgenes, promociones, descuentos especiales a determinados clientes… ¡BOOOM! Una auténtica locura.

Os seguiré contando… a vuestro pesar.