Este módulo proporciona funcionalidades de contabilidad de existencias específicas para Rumanía que se ajustan a las normas y regulaciones contables rumanas. A continuación se presentan las opciones de configuración disponibles.
Descripción general
El módulo amplía la contabilidad de existencias estándar de Odoo para cumplir con los requisitos contables rumanos, proporcionando:
- Configuraciones contables específicas por ubicación
- Cuentas de valoración de existencias específicas para Rumanía
- Personalización de cuentas de existencias por categoría de producto
- Gestión de la posición fiscal del almacén
- Cuentas especializadas para operaciones de existencias
- Valoración FIFO por ubicación (frente al FIFO por empresa predeterminado de Odoo)
- Compensación automática de existencias negativas para productos FIFO
- Asientos de valoración de existencias para entregas dropship, simétricos con las entregas regulares
FIFO por ubicación
Para productos con cost_method=fifo, el módulo valora los movimientos de salida contra la pila FIFO de la ubicación de origen en lugar de la pila a nivel de empresa. Cada movimiento de salida se divide automáticamente en un stock.move por capa FIFO (por ejemplo, una salida de 4 unidades desde una ubicación con IN 2@10 + IN 3@8 produce un movimiento 2x10 + un movimiento 2x8).
Las transferencias internas (internal → internal o vía tránsito) se tratan como is_in e is_out en el mismo movimiento:
- consumen de la pila FIFO de la ubicación de origen,
- entran en la pila FIFO de la ubicación de destino con el valor extraído del origen,
- generan un asiento contable a través de la cuenta de valoración de la ubicación (o la cuenta de transferencia a nivel de empresa si las ubicaciones comparten una cuenta).
Controlado por res.company.fifo_per_location (por defecto True para empresas rumanas, calculado a partir de country_id, editable por empresa).
Compensación de existencias negativas
Cuando un movimiento de salida FIFO ocurre antes del movimiento de entrada correspondiente (es decir, la pila FIFO de la ubicación está vacía), el valor de salida recurre al standard_price del producto. La cantidad pendiente se rastrea en el movimiento de salida mediante fifo_neg_pending_qty / fifo_neg_origin_value.
Cuando se registra el siguiente movimiento de entrada correspondiente, el módulo:
- asigna el nuevo valor de entrada entre los movimientos de salida pendientes (FIFO);
- actualiza stock.move.value en los movimientos de salida para reflejar el precio de compra real;
- emite una corrección de account.move que debita la cuenta de variación/COGS y acredita la cuenta de valoración de existencias por el delta;
- vincula esa corrección de vuelta al movimiento IN de origen mediante account.move.fifo_neg_origin_move_id para trazabilidad.
La compensación es idempotente — si se vuelve a invocar _set_value en el mismo movimiento IN (por ejemplo, cuando se registra la factura del proveedor), la compensación existente se detecta y no se duplica.
Controlado por res.company.fifo_location_negative_compensation (por defecto True para empresas rumanas, editable por empresa).
Valoración de dropship
Un movimiento dropship (ubicación del proveedor directamente a una ubicación del cliente, las mercancías nunca entran en el stock propio de la empresa) ahora se valora y contabiliza de la misma manera que una entrega regular: la factura del proveedor sigue debitando la cuenta de valoración de existencias al recibirse, y el módulo ahora acredita esa misma cuenta y debita la cuenta de gastos cuando las mercancías salen hacia el cliente, sin dejar saldo residual. Sin esto, la cuenta de valoración de existencias acumulaba un saldo que ya no correspondía a ninguna mercancía en existencia, y el coste de las mercancías enviadas por dropship nunca se reconocía como gasto.
Esto se aplica a los movimientos dropship validados después de instalarse la corrección; los movimientos dropship históricos conservan sus asientos contables originales (faltantes) y requieren una regularización separada y deliberada si es necesario liquidar ese saldo.
Asientos contables de dropship
La empresa nunca posee físicamente las mercancías enviadas por dropship (el proveedor envía directamente al cliente), pero según las normas contables rumanas las existencias se reconocen en la transferencia de riesgos y beneficios (OMFP 1802/2014, pt. 283 párr. 1), no en la posesión física — el mismo principio subyacente a las cuentas 327 "Mercancías en tránsito" y 357 "Mercancías en poder de terceros" para existencias que la empresa posee sin tenerlas. Encaminar una compra dropship a través de la cuenta de valoración de existencias en lugar de gastarla directamente en la factura del proveedor también evita que un desfase temporal entre factura de compra y factura de venta (por ejemplo, factura del proveedor en diciembre, factura del cliente en enero) distorsione el resultado del período, según el principio de devengo (pt. 53).
Movimiento forward (las mercancías salen hacia el cliente):
| Cuenta | Debe | Haber | |---|---|---| | Gasto (607) | valor | | | Valoración de existencias (371) | | valor |
Movimiento de devolución (dropshipped_return), convención storno — mismas cuentas que el movimiento forward, importe en rojo, no un intercambio debe/haber:
| Cuenta | Debe | Haber | |---|---|---| | Gasto (607) | −valor | | | Valoración de existencias (371) | | −valor |
408 "Proveedores - facturas no recibidas" nunca aplica a un movimiento dropship: esa cuenta es un pivote para mercancías recibidas físicamente en un almacén antes de que llegue la factura del proveedor, y un movimiento dropship nunca tiene esa pata de recepción física. Si la factura del proveedor falta en el momento de la venta al cliente, la contrapartida correcta es 327 (una cuenta de existencias en tránsito), no 408.
Para que el asiento anterior siga siendo correcto en la práctica: el haber a 371 debe ocurrir en el mismo período contable que el debe de la factura del proveedor y por el mismo importe, de modo que la cuenta se salde a cero para el tráfico dropship al cierre del período; y las cantidades dropship deben fluir a través de una ubicación distinta para que nunca se mezclen en el recuento de inventario físico de un almacén real.
El dropshipping de un producto no afecta al valor del stock real de ese mismo producto mantenido en otro lugar, con ninguno de los dos métodos de coste (FIFO o coste medio). El propio motor de coste medio de Odoo integra los movimientos dropship en el mismo fondo de media móvil que las compras reales por diseño, lo que de otro modo revalorizaría retroactivamente existencias no relacionadas en mano solo porque el mismo producto también se envió por dropship; este módulo desvía los movimientos dropship de ese recálculo por completo para las empresas con contabilidad rumana.
Notas de rendimiento
- Un índice compuesto parcial en stock_move(product_id, location_dest_id, date DESC, id DESC) WHERE state='done' AND is_in=true potencia la búsqueda de la pila FIFO con escaneos solo de índice en historiales grandes.
- Un índice parcial en stock_move(...) WHERE fifo_neg_pending_qty > 0 mantiene la búsqueda de compensación en tiempo constante incluso con millones de movimientos históricos.
- Una caché con alcance de petición (context['fifo_stack_cache']) reutiliza el mismo resultado de _run_fifo_get_stack entre búsquedas por lotes en product._compute_value y stock.quant._compute_value — los informes grandes de Inventory Valuation bajan de O(N) consultas a O(consultas distintas (product, location)).
Traducción automática al español (DeepSeek) de la descripción original de OCA, que está en inglés.
auto_awesome Qué hace este módulo
Generado por IA a partir del código · Odoo 20.0Añade reglas rumanas de contabilidad de existencias: valoración FIFO por ubicación de almacenamiento en lugar de por compañía, corrección automática de los valores FIFO de existencias negativas y cuentas de existencias específicas de Rumanía en ubicaciones, productos y almacenes.
Este módulo adapta la valoración de inventario de Odoo a la práctica contable rumana. Está pensado para empresas rumanas y aparece como campos y opciones adicionales en las pantallas existentes en lugar de como un menú nuevo.
Qué pueden configurar los usuarios: - En el formulario de la compañía, dos interruptores: FIFO per Location y FIFO Negative Stock Compensation. - En las ubicaciones de existencias, una cuenta de valoración de existencias rumana más cuentas de ingresos y gastos, que pueden propagarse a las ubicaciones hijas. - En las categorías de producto, una opción para permitir que la cuenta de existencias se cambie desde las ubicaciones, y en los productos una cuenta de valoración de existencias rumana. - En las cuentas, una Consume Account y una Reception in Progress Account. - En los almacenes, una posición fiscal.
Qué ocurre automáticamente: - Para los productos FIFO, las salidas de mercancías se valoran a partir de las capas de existencias de la ubicación de origen, no de toda la compañía. Un movimiento de salida puede dividirse en varias líneas para que cada parte tome el coste de la capa que consume. - Si las mercancías salen de una ubicación que no tiene existencias, el movimiento se valora al coste estándar y se marca como pendiente; el siguiente movimiento de entrada para el mismo producto y ubicación lo revaloriza y registra un asiento de corrección en el diario de existencias. - Los movimientos de existencias obtienen un tipo de movimiento rumano y cuentas de valoración y transferencia rumanas, y los asientos contables relacionados las utilizan. - En las facturas rumanas, no se añaden las líneas habituales de coste de las mercancías vendidas y diferencia de precio, y las diferencias de tipo de cambio en mercancías recibidas pero aún no facturadas se registran automáticamente al publicar la factura. - Las recepciones en curso y las recepciones de aviso utilizan cuentas dedicadas en las facturas de compra, y las entregas de aviso utilizan una cuenta dedicada en las facturas de venta.
Un botón en las transferencias abre los asientos contables relacionados.
Depende de
Lo necesitan otros módulos
Modelos y campos (13)
- stock.move · modelo nuevol10n_ro_move_type (Romanian - Move Type), l10n_ro_account_id (Romania - Valuation Account), fifo_neg_pending_qty (Negative Stock Pending Qty), fifo_neg_origin_value (Negative Stock Initial Value), l10n_ro_transfer_account_id (Romania - Transfer Valuation Account), fifo_neg_compensation_move_ids (Negative Stock Compensation Entries), l10n_ro_extra_account_move_ids (Romania - Extra Account Moves)
- res.company · amplía un modelo existentefifo_per_location (FIFO per Location), fifo_location_negative_compensation (FIFO Negative Stock Compensation)
- stock.quant · modelo nuevo
- account.move · modelo nuevofifo_neg_origin_move_id (Source IN move for negative stock compensation), l10n_ro_extra_stock_move_id (Romania - Extra Stock Move)
- stock.picking · modelo nuevol10n_ro_notice, l10n_ro_reception_in_progress
- stock.location · amplía un modelo existentel10n_ro_property_account_income_location_id (Income Account), l10n_ro_property_stock_valuation_account_id (Stock Valuation Account Romania), l10n_ro_property_account_expense_location_id (Expense Account)
- account.account · modelo nuevol10n_ro_stock_consume_account_id (Consume Account), l10n_ro_reception_in_progress_account_id (Romania - Reception in Progress Account)
- product.product · modelo nuevo
- stock.warehouse · modelo nuevol10n_ro_fiscal_position_id (Fiscal Position)
- product.category · modelo nuevol10n_ro_stock_account_change (Allow stock account change from locations)
- product.template · modelo nuevol10n_ro_property_stock_valuation_account_id (Stock Valuation Account)
- account.move.line · modelo nuevo
- l10n.ro.stock.scenario.loader · modelo nuevo
Texto generado por IA (DeepSeek) al leer el código de la versión 20.0 en GitHub; puede contener errores, así que verifícalo en el código antes de decidir. El módulo es muy grande y solo se ha leído una parte del código. Ver el código en GitHub
Disponibilidad por versión
Revisado: 2026-11-03Estado de confirmación: 8 confirmadas, 1 sin información de 9 versiones.
Fuentes · Odoo 19.0
Confirmado el 2026-11-03 en la rama 19.0 de OCA/l10n-romania.
terminal Instalación y uso
Sin información verificadaLas instrucciones de instalación, el paquete de distribución, las dependencias y los pasos de configuración no se muestran porque todavía no se han verificado en la documentación del módulo para ninguna versión.
Datos importados de GitHub: esta ficha refleja la última revisión del catálogo, no una consulta en directo. Verifica siempre en la documentación del módulo y en staging antes de instalar en producción.