Cómo elegir un ERP autoalojado para trabajar con varias monedas: lista práctica de evaluación

Por qué no basta con que «admita varias monedas»

Un selector de moneda no demuestra que una aplicación pueda cubrir tu flujo de trabajo contable. Necesitas saber dónde se aplican las monedas, cómo se convierten los importes, qué queda registrado y cómo aparecen las cifras resultantes en los informes.

Toma las afirmaciones del producto como puntos de partida para hacer pruebas, no como respuestas. Consulta la documentación oficial del proveedor para la versión que planeas usar y luego reproduce tus flujos de trabajo reales en una instancia de prueba. La documentación puede explicar el comportamiento previsto; una prueba permite comprobar si la configuración se ajusta a tu organización.

La [documentación oficial de ERPNext sobre contabilidad multidivisa](https://docs.frappe.io/erpnext/multi-currency-accounting) distingue, entre otros conceptos, la moneda de la empresa, la moneda de la cuenta, la moneda de la transacción y la moneda de la lista de precios. Es un ejemplo de las distinciones que conviene investigar, no una garantía de que otro producto utilice el mismo modelo.

• Anota las monedas que realmente utiliza tu empresa y para qué se usa cada una.
• Indica qué informes y decisiones dependen de importes convertidos.
• Registra cada pregunta sin resolver como un requisito del producto que debe verificarse, no como una suposición.

Identifica dónde se utiliza cada moneda

Sigue una transacción desde el primer importe que ve el cliente hasta su asiento contable final. Una cotización o lista de precios puede utilizar una moneda, mientras que la factura, los libros de la empresa y la cuenta de pago utilizan otras. El proceso de compra puede seguir un recorrido distinto.

Prueba las cotizaciones o listas de precios, las facturas de venta, las facturas de compra y los pagos como flujos de trabajo independientes. No des por sentado que elegir una moneda en un área configura las cuentas contables correspondientes o los valores predeterminados de clientes y proveedores. Por ejemplo, la [documentación de ERPNext sobre monedas](https://docs.frappe.io/erpnext/currency) explica que habilitar una moneda no crea por sí solo una cuenta bancaria o de cuentas por cobrar en esa moneda; la configuración de cuentas y los valores predeterminados para clientes o proveedores pueden requerir pasos separados.

En cada paso, anota qué moneda introduce el usuario, qué moneda conserva el registro y qué moneda aparece en el libro mayor o en el informe. Pregunta qué ocurre cuando la moneda de una cuenta no coincide con la del documento o con la moneda de la empresa.

• Cotización al cliente: ¿Qué moneda aparece en la cotización y en la lista de precios, si la hay?
• Factura de venta: ¿Qué moneda se introduce y qué importe se contabiliza en la moneda de la empresa?
• Factura del proveedor: ¿Se puede registrar la factura del proveedor en su moneda original?
• Pago: ¿Qué monedas están disponibles para la cuenta y el pago, y cómo se asignan?
• Informes: ¿Se pueden identificar tanto el importe original de la transacción como el importe convertido?

Distingue entre la moneda de la empresa, la moneda de la transacción y la moneda de presentación

Pide al proveedor que defina los términos de moneda utilizados por el sistema. La moneda base o de la empresa suele ser la moneda en la que se llevan los libros, pero no tiene por qué coincidir con la moneda de una transacción, la moneda de una cuenta o la moneda de una lista de precios. La moneda de presentación es la que se utiliza para mostrar los resultados en un informe y puede ser distinta de la moneda de los libros. No des por sentado que el producto admite esa conversión en informes ni que la realiza automáticamente.

Utiliza un escenario sencillo para comprobar las diferencias: emite una factura en la moneda del cliente y revisa la factura, el asiento contable, el saldo del cliente y un informe de la empresa. Verifica qué cifras son importes originales, cuáles están convertidas a la moneda de los libros y, si el sistema ofrece esa opción, cuáles se convierten a una moneda de presentación. Pregunta también si los usuarios pueden distinguirlas sin exportar los datos ni hacer cálculos manuales.

Deja constancia del tratamiento esperado en tus notas de evaluación. Si los términos del proveedor no están claros, pide una demostración con tu escenario en lugar de confiar en una afirmación general de que el software es multidivisa.

• Documenta la moneda en la que se llevan los libros y las monedas que se necesitan para los informes.
• Identifica las cuentas que deban mantener saldos en una moneda concreta.
• Confirma si la moneda y el importe originales de una transacción siguen siendo visibles después de contabilizarla.
• Comprueba si la conversión de la moneda de las listas de precios es independiente de la conversión contable y de cualquier conversión para informes.

Comprueba cómo se obtienen, se fechan y se registran los tipos de cambio

Un tipo de cambio solo tiene sentido junto con su fecha, fuente, dirección y finalidad. Averigua si los tipos se introducen manualmente, se importan de un proveedor configurado o se obtienen de ambas formas. Determina quién puede aprobarlos o modificarlos y cómo pueden saber los usuarios qué tipo se aplicó a una transacción.

Prueba una transacción cuya fecha del documento sea distinta de la fecha de registro. Después, introduce otra transacción cuando el tipo haya cambiado. Comprueba si la aplicación selecciona un tipo según la fecha pertinente, permite un tipo manual aprobado y conserva el registro del tipo utilizado. No des por sentado que el valor predeterminado de la aplicación coincide con tus políticas contables.

Las instrucciones de ERPNext para [tipos de cambio](https://docs.frappe.io/erpnext/v13/user/manual/en/accounts/currency-exchange) describen registros con fecha de vigencia, monedas de origen y destino, un tipo de cambio y aplicabilidad a compras o ventas. Consulta la documentación oficial y actual del producto elegido para confirmar sus propios campos y reglas de selección.

• ¿Quién puede añadir, editar o aprobar un tipo de cambio?
• ¿Puede un usuario ver el tipo, la fecha y la fuente aplicados a un documento contabilizado?
• ¿Qué ocurre si no existe un tipo para la fecha de la transacción?
• ¿Puede el sistema utilizar un tipo aprobado manualmente cuando hay disponible un tipo automatizado?
• ¿Modificar un tipo afecta solo a las transacciones nuevas o también puede cambiar registros existentes?

Prueba los redondeos, los pagos parciales, los reembolsos y las notas de crédito

Utiliza importes que reflejen tus facturas y métodos de pago reales. Comprueba tanto la precisión que se muestra a los usuarios como el importe que finalmente se contabiliza. La cantidad de decimales que se muestra no determina por sí sola el comportamiento de redondeo de cada cálculo o asiento contable; la [documentación de ERPNext sobre precisión](https://docs.frappe.io/erpnext/set-precision) trata la precisión monetaria y el método de redondeo como ajustes distintos.

A continuación, registra un pago parcial con un tipo de cambio distinto del utilizado en la factura. Revisa el saldo pendiente, la asignación del pago y cualquier diferencia de cambio realizada. Haz una segunda prueba para liquidar el resto de la factura y verificar la asignación y los saldos finales. La [documentación de ERPNext sobre pagos](https://docs.frappe.io/erpnext/payment-entry) describe pagos parciales y diferencias de cambio realizadas; confirma el comportamiento de la aplicación que evalúas.

Prueba un abono parcial, un reembolso y, si tu proceso lo requiere, el uso del crédito de un cliente para otra factura. Comprueba qué moneda aparece en cada documento y cómo se reflejan los importes correspondientes en las cuentas. La [documentación de ERPNext sobre notas de crédito](https://docs.frappe.io/erpnext/credit-note) describe estas operaciones; confirma el comportamiento específico de la aplicación elegida.

• Crea una factura con un importe fraccionario y revisa los valores que se muestran y los que se contabilizan.
• Paga una parte de la factura con un tipo de cambio distinto al de la factura; revisa el saldo restante y la diferencia realizada.
• Completa el pago y confirma que la factura se cierra como corresponde.
• Emite un abono parcial y prueba el proceso de reembolso o asignación que realmente utilizas.
• Repite los cálculos más importantes con la precisión monetaria y los ajustes de redondeo que usas habitualmente.

Pregunta por la revaluación al cierre del periodo y los informes históricos

Una diferencia de cambio al liquidar una factura no es lo mismo que revaluar un saldo abierto en moneda extranjera al cierre del periodo. La revaluación ajusta el valor en moneda de la empresa de los saldos abiertos que cumplen los requisitos, mientras mantiene sin cambios sus importes en moneda extranjera. Pregunta qué cuentas y saldos pueden revaluarse, qué tipo y fecha se utilizan y cómo se revierte o se arrastra el ajuste según tu proceso.

Prueba un saldo abierto en moneda extranjera en dos fechas de presentación de informes. Después de la revaluación, compara el importe en moneda extranjera, el valor contable en moneda de la empresa y el registro de la transacción original. A continuación, genera informes para ambas fechas. El objetivo es confirmar que una valoración posterior no modifica inadvertidamente la factura original, el pago o el registro histórico del tipo de cambio.

La [documentación de ERPNext sobre revaluación de tipos de cambio](https://docs.frappe.io/erpnext/exchange-rate-revaluation) trata la revaluación por separado de las diferencias realizadas relacionadas con los pagos. También explica el uso de un valor contable posterior y de un tipo de cierre. Tómalo como un ejemplo específico de ese producto y consulta la documentación y los ajustes contables actuales de la aplicación que elijas.

• ¿Puedes identificar los saldos abiertos en moneda extranjera que requieren revaluación?
• ¿Qué fecha del tipo de cambio se utiliza para cada ajuste de cierre del periodo?
• ¿Pueden los usuarios distinguir la revaluación no realizada de las diferencias realizadas al liquidar una operación?
• ¿Los informes históricos conservan las cifras y los tipos que correspondían a sus fechas de presentación?
• ¿Se puede rastrear un ajuste de revaluación hasta el saldo de origen y su asiento contable?

Verifica las importaciones, exportaciones, integraciones y los registros de auditoría

El comportamiento de las monedas debe mantenerse más allá de la introducción manual de datos. Prueba las plantillas de hojas de cálculo, la validación de importaciones y los campos de exportación que esperas utilizar. Incluye códigos de moneda, fechas, tipos de cambio, importes y los campos pertinentes de cuentas o partes. Comprueba cómo gestiona el sistema las monedas ausentes, los códigos no válidos, las filas duplicadas y los importes que requieren más precisión que la del formato mostrado.

Si otra aplicación envía o recibe registros financieros, prueba un intercambio pequeño de principio a fin en lugar de suponer que los nombres de campo coincidentes tienen el mismo significado. Confirma si la integración transfiere el importe original, la moneda, el tipo de cambio, la fecha del tipo y el importe convertido cuando se necesitan.

Revisa el registro de auditoría para ver los cambios en los tipos de cambio, los documentos y las asignaciones. En las importaciones, inspecciona tanto las advertencias y los registros como los datos resultantes. La [documentación de ERPNext sobre importación de datos](https://docs.frappe.io/erpnext/data-import) describe plantillas de hojas de cálculo, advertencias de validación, registros de importación y exportaciones de tablas secundarias; verifica el comportamiento correspondiente en el producto que elijas.

• Importa un archivo pequeño con filas de moneda válidas y otras deliberadamente no válidas.
• Compara los registros importados con el archivo de origen y revisa los mensajes de validación.
• Exporta los mismos registros y comprueba si se incluyen los campos de moneda y tipo de cambio.
• Si corresponde, prueba en ambos sentidos una integración representativa.
• Confirma quién puede hacer cambios y qué registro de esos cambios queda disponible.

Prepara una matriz de pruebas pequeña antes de elegir

Una matriz compacta permite comparar las aplicaciones con más fiabilidad que una lista de funciones. Usa los mismos escenarios, monedas, fechas y resultados esperados en cada aplicación que evalúes. Marca los resultados como aprobados, fallidos o no verificados, y guarda capturas de pantalla o resultados de informes cuando sea útil.

Puedes copiar esta plantilla y completar una fila por prueba:

| Escenario | Resultado esperado | Resultado observado y pruebas | Estado (aprobado, fallido o no verificado) | Pregunta pendiente, responsable y siguiente paso | |---|---|---|---|---| | Factura en moneda extranjera | | | | | | Factura de proveedor | | | | | | Cambio de tipo de cambio | | | | | | Pago parcial y liquidación | | | | | | Abono o reembolso | | | | | | Revaluación al cierre del periodo | | | | | | Importación y exportación | | | | |

Separa la idoneidad del flujo de trabajo de la idoneidad de la implementación. Primero determina si la aplicación cumple tus requisitos de moneda y contabilidad. Después evalúa cómo se operará: quién controla el acceso, los datos, las copias de seguridad, las actualizaciones y la recuperación, y qué responsabilidades de alojamiento seguirá asumiendo tu equipo.

Si la implementación es autoalojada, consulta la configuración de producción y los requisitos operativos de la aplicación concreta. Por ejemplo, la [guía oficial de Docker Compose para producción](https://docs.docker.com/compose/how-tos/production/) aborda configuraciones específicas de ese entorno; es una cuestión aparte de cómo calcula un ERP los importes en distintas monedas. Una implementación gestionada puede encargarse de parte de la infraestructura, pero no elimina tu responsabilidad en las decisiones sobre datos, acceso y gobernanza.

• Usa el mismo conjunto de monedas, fechas y datos de prueba en cada aplicación.
• Registra resultados observados y pruebas, no solo las respuestas del proveedor.
• Deja como «no verificado» cualquier requisito que no hayas podido probar y asigna un siguiente paso.