Product cost price avco sync

El módulo actúa sobre los productos cuya categoría utiliza el método de coste Average Cost (AVCO). Los productos valorados a precio estándar o FIFO no se modifican.

No es compatible con la valoración de inventario automatizada

Úsalo solo en categorías de producto cuya valoración de inventario sea manual.

Con la valoración automatizada, cada capa de valoración tiene un asiento contable publicado junto con ella. Este módulo reescribe la capa cuando se corrige un error pasado, y no toca ese asiento, que se publicó con las cifras que la capa tenía entonces y bien puede estar en un periodo ya cerrado. La valoración de existencias y la contabilidad se desviarían, en silencio, por el importe de cada corrección.

El objetivo de reexpresar el pasado es llegar a las empresas que publican la valoración de existencias periódicamente, desde el informe de valoración, en lugar de movimiento a movimiento. Las que la publican automáticamente ya tienen cada corrección contabilizada el día en que se hizo, que es lo que hace Odoo por sí solo y lo que espera su contabilidad.

Valoración por número de lote/serie

Ambos modelos son compatibles y pueden coexistir en la misma base de datos, por lo que marcar o desmarcar Valoración por número de lote/serie en un producto no requiere ningún cuidado especial desde el punto de vista de este módulo: las capas que ya tenía siguen reproduciéndose como la cadena que eran, y las nuevas se reproducen por lote.

Ten en cuenta que habilitarlo es una operación propia de Odoo, no de este módulo: vacía las existencias y las vuelve a introducir, dando a cada lote existente el coste medio actual del producto, porque el coste al que realmente se compró cada lote no se registra en ningún sitio antes de ese punto. Además, se niega a ejecutarse mientras algún lote tenga una cantidad negativa en una ubicación valorada.

Costes en destino y diferencias de precio en la factura de proveedor

Ambos añaden valor a una capa de recepción sin tocar su coste, y ambos leen la cantidad restante para saber cuánto queda todavía disponible. Se mantienen sincronizados: corregir el coste o la cantidad de una capa ajusta su valor restante por la diferencia, de modo que lo que un coste en destino o una factura le añadieron sobrevive a la corrección y las correcciones posteriores se valoran correctamente.

La corrección de un precio en la factura de proveedor está cubierta por purchase_stock_price_unit_sync, que la aplica a toda la recepción en lugar de solo a lo que queda disponible, por lo que esa vía acaba siendo equivalente a corregir la recepción o la capa.

Corregir un error

Hay cuatro formas de corregir una compra, y todas acaban en el mismo sitio: la capa se reexpresa como si siempre hubiera tenido las cifras corregidas, los movimientos de salida valorados en el intervalo se recalculan y el coste del producto, o del lote, sigue el mismo camino.

| Qué corriges | Dónde | Qué hace falta | |---|---|---| | El coste de una recepción | El unit_cost de su capa de valoración | Este módulo | | La cantidad de un movimiento realizado, de entrada o de salida | La cantidad de la línea del movimiento | Este módulo | | El precio de un pedido de compra ya recibido | La línea del pedido | purchase_stock_price_unit_sync | | El precio en la factura del proveedor | La línea de la factura | purchase_stock_price_unit_sync |

Corregir el mismo precio dos veces, primero en el pedido y luego en la factura, no lo cuenta dos veces: la segunda encuentra la capa ya con el valor que indica y no hace nada.

Forzarlo a mano

Para las ocasiones en que una corrección no pudo ejecutarse por sí sola, como capas escritas mientras este módulo no estaba instalado, la acción Recompute average cost from here está disponible en el menú Action de la lista de capas de valoración de existencias. Selecciona una o más capas y la cadena se reproduce desde cada una de ellas.

Solo se usa la capa más antigua de cada cadena de la selección, porque la reproducción corrige todo lo que viene después del punto de partida y el resto reharía el mismo trabajo. En un producto valorado por lote, cada lote es una cadena propia, por lo que se conserva la capa más antigua de cada lote.

Reproducir una cadena larga reescribe todas las capas posteriores al punto de partida, en una sola transacción. En un producto con cientos de miles de capas, empieza lo más tarde posible en la cadena según lo permita la corrección.

Qué ocurre con todo lo demás

Estos flujos no necesitan nada de ti y no se ven alterados por una corrección:

• Costes en destino, aplicados antes o después de la corrección, y divididos por lote. Lo que añadieron a la capa no es coste de compra, por lo que sobrevive intacto y la corrección solo mueve el coste de la mercancía.
• El asistente de revalorización de existencias. Lo que añade se reparte entre las unidades disponibles, igual que un coste en destino, por lo que el coste del producto sigue coincidiendo con el valor de sus capas.
• Existencias negativas. Sin unidades restantes con las que promediar, una recepción fija el coste al precio realmente pagado, y el propio vacío de Odoo salda el déficit pendiente con ese mismo precio una vez que llega suficiente stock real. Corregir una recepción a la baja por debajo de lo que ya se había entregado registra el faltante como el déficit que busca el vacío, por lo que esas unidades también se recalculan. Ese faltante se registra en el último movimiento de salida de la cadena, que es donde habría quedado corto en orden cronológico, en lugar de en la entrega que se llevó cada unidad concreta. Reconstruir eso significaría reproducir el consumo hacia atrás, y no cambiaría nada: un coste medio se reparte sobre toda la cantidad, por lo que lo que importa es que el déficit exista y se salde, no a qué entrega esté asociado.
• Los ajustes de inventario y las devoluciones se valoran al coste del momento en lugar de promediarse, y una corrección los recalcula junto con el resto.
• Cambiar un producto a valoración por lote o desde ella, en cualquier momento. Las capas que ya tenía siguen reproduciéndose como la única cadena que eran.

Lo que queda en manos de Odoo

• Los reembolsos de facturas de proveedor, que Odoo compensa contra la factura original con una lógica propia.
• Las capas creadas directamente desde código, fuera de un movimiento de existencias y sin ejecutar el vacío de existencias negativas de Odoo, como podría hacer un módulo de terceros. No activan nada: usa la acción de servidor anterior si alguna vez una cadena lo necesita.
• Los productos que no se valoran a coste medio, y la valoración de inventario automatizada, que no es compatible en absoluto. Consulta las notas de configuración.