Odoo · ERP · Perú
Errores comunes en la localización de Odoo para Perú
Los errores de localización rara vez se ven el primer día. Aparecen en el primer cierre, en la primera nota de crédito o cuando SUNAT observa un documento.
Última actualización: septiembre de 2026
Emisión por semana
Por tipo de documento
1. Asumir que "ya viene localizado"
El estándar aporta plan contable, impuestos y tipos de documento. Series, tipos de operación, detracciones, retenciones, percepciones y registros requieren decisiones. Esa brecha es la que produce la mayoría de los reprocesos.
2. Series definidas sin ver la operación
Numeración creada sin considerar establecimientos, puntos de emisión ni tipos de documento. Corregirlo después de emitir es caro porque la numeración ya está en poder de SUNAT y de los clientes.
3. Impuestos duplicados
Dos configuraciones para el mismo tributo, creadas en momentos distintos. El resultado son reportes con bases diferentes y un cierre que nadie puede explicar.
4. Detracción como pago suelto
Registrada sin cuenta específica ni enlace con la constancia. Se detecta cuando la conciliación bancaria deja partidas abiertas que nadie sabe cerrar.
5. Tipo de cambio con varias fuentes
Compras usa una, ventas otra y contabilidad una tercera. Las diferencias se acumulan y aparecen como ajustes al cierre.
6. Cuentas de existencias y costo genéricas
Si las categorías de producto no tienen cuentas correctas, el almacén y el mayor dejan de coincidir y la valorización se vuelve una discusión mensual.
7. Fechas registradas con criterios distintos
Usar fecha de registro donde corresponde fecha de emisión afecta los registros de ventas y compras, y por lo tanto la comparación con las propuestas del SIRE.
8. Documentos en borrador olvidados
Comprobantes que existen para SUNAT pero no están validados en el ERP: la propuesta del SIRE los muestra y el libro no.
9. Notas de crédito sin motivo definido
Cada motivo tiene un efecto contable distinto. Si se usa uno genérico, las devoluciones y anulaciones distorsionan ingresos e impuestos.
10. No probar hasta el asiento
Probar que el documento se emite no es probar que contabiliza bien. El caso solo está validado cuando se revisó el asiento resultante.
antes del go-live, recorre cinco casos reales —venta con anticipo, compra con detracción, devolución, operación en dólares y cierre de un periodo de prueba— y revisa el asiento de cada uno.
Preguntas frecuentes
¿Se pueden corregir después de operar?
Sí, con reproceso. Cuanto más tiempo pase, más asientos hay que revisar, así que conviene auditar la configuración antes del primer cierre.
¿Quién debería revisar esto?
El contador de la empresa junto al implementador. Los errores de localización casi siempre surgen cuando una de las dos partes decide sin la otra.
¿Es más frecuente en Community?
Ocurre en ambas ediciones, pero en Community suele haber más desarrollos que suplen funcionalidad contable, y cada desarrollo añade una posibilidad de error.