Un sistema operando en dos países: decisiones de arquitectura
Resumen:
- Un sistema multi-entidad evita la consolidación manual y los catálogos divergentes.
- Todo importe se guarda con moneda y tipo de cambio, nunca convertido a una sola moneda.
- El producto es único; los atributos fiscales son por entidad.
- Los permisos empiezan cerrados por entidad y se abren de forma explícita.
Una empresa de manufactura ligera con planta en Tijuana, almacén y oficina comercial en San Diego, clientes en ambos lados. Operaban con dos sistemas independientes y una hoja de cálculo mensual que alguien armaba para consolidar.
El encargo era unificar. Las decisiones que siguen son las que se toman en las primeras semanas y las que después no se pueden deshacer sin rehacer el sistema.
Uno: multi-entidad desde el primer día
La tentación es construir para la operación principal y «después añadir» la segunda. No funciona. Introducir el concepto de entidad en un sistema que ya tiene datos es una migración dolorosa que toca casi todas las tablas.
Multi-entidad significa que cada registro —cliente, pedido, factura, movimiento de inventario— pertenece a una entidad legal concreta, y que los reportes pueden verse por entidad o consolidados.
Cuesta poco al principio. Cuesta muchísimo después.
Dos: la moneda no se convierte, se acompaña
El error clásico es guardar todos los importes convertidos a una moneda de referencia. Es cómodo para reportar y destruye información.
| Enfoque | Consecuencia |
|---|---|
| Solo moneda de referencia | Imposible reconstruir el importe original. Una factura emitida en dólares aparece en pesos y no coincide con el documento físico. |
| Importe más moneda | Mejor, pero al recalcular con el tipo de cambio actual los históricos cambian solos y nada cuadra. |
| Importe, moneda y tipo aplicado | Correcto. Se conserva la operación tal como ocurrió y se puede reportar en cualquier moneda de forma reproducible. |
La tercera opción implica tres columnas en lugar de una en cada tabla con importes. Es el precio de poder cerrar un mes sin discusiones.
Tres: un producto, atributos por entidad
La misma pieza física tiene identidad distinta a cada lado: clasificación arancelaria, tratamiento fiscal, unidad de medida declarada.
La solución equivocada es duplicar el producto, una vez por país. Produce inventarios que no se pueden sumar y catálogos que divergen en cuanto alguien actualiza uno solo.
La solución correcta es un producto único con un conjunto de atributos por entidad. Existe una sola pieza y tiene dos fichas fiscales.
Cuatro: la numeración de documentos
Cada entidad necesita su propia serie de folios, independiente y correlativa. Compartir numeración entre países produce huecos en ambas series que ninguna autoridad va a considerar aceptables.
Suena obvio y lo hemos visto mal implementado varias veces, normalmente porque el sistema empezó con una sola entidad y la segunda se añadió reutilizando el mismo contador.
Cinco: los permisos empiezan cerrados
Una operación transfronteriza tiene información sensible que no debe cruzar sin decisión: márgenes, costos de transferencia, condiciones de clientes.
El modelo que funciona es que cada usuario ve por defecto solo su entidad y los permisos de visión consolidada se otorgan de forma nominal. Abrir permisos es fácil; cerrarlos después de que alguien se acostumbró a ver algo es una conversación incómoda.
Preguntas frecuentes
¿Conviene un solo sistema o uno por país?
Un solo sistema con soporte multi-entidad, salvo que las operaciones sean independientes de verdad. Dos sistemas separados obligan a consolidar a mano cada mes y a mantener dos catálogos de producto y de cliente que inevitablemente divergen.
¿Cómo se guarda un importe cuando hay dos monedas?
Siempre con tres datos: importe, moneda y tipo de cambio aplicado en ese momento. Guardar solo la conversión a una moneda destruye información y hace imposible reconstruir el importe original de la operación.
¿Se puede usar un mismo catálogo de productos en ambos países?
El producto sí; los atributos fiscales no. La misma pieza tiene una clasificación en un país y otra distinta en el otro. La solución es un producto único con atributos por entidad, no dos productos duplicados.
¿Qué pasa con los reportes para el corporativo?
Necesitan una moneda de consolidación y un criterio de conversión declarado: tipo de cambio de cierre, promedio del periodo o histórico de cada operación. Los tres son válidos y dan cifras distintas, así que hay que elegir y documentarlo.
¿Los usuarios ven todo el sistema o solo su entidad?
Por defecto solo la suya, con permisos explícitos para ver el conjunto. Una operación transfronteriza tiene información que no debe cruzar de un lado al otro sin decisión consciente, y es más fácil abrir permisos que cerrarlos después.
La decisión que más se discutió
El idioma de la interfaz. La planta trabaja en español, la oficina comercial en inglés, y el corporativo pedía reportes en inglés.
Se resolvió con idioma por usuario, no por entidad. Una persona de la planta que reporta a San Diego puede trabajar en español y exportar en inglés. Parece un detalle de comodidad y evitó que el sistema se percibiera como impuesto desde un lado de la frontera.
Lo que dejamos fuera
El corporativo quería nómina unificada. Lo desaconsejamos con firmeza.
La nómina de cada país tiene su propia normativa, sus propios cálculos y su propio calendario. Unificarla en un desarrollo a medida significa asumir el mantenimiento de dos marcos regulatorios que cambian cada año, y es de las peores decisiones de alcance que puede tomar una empresa.
Se quedaron con dos sistemas de nómina locales que entregan al sistema central solo el costo consolidado por centro. Es menos elegante y es sostenible.
Los precios de transferencia entre entidades
Cuando la planta de un país factura a la comercializadora del otro, esa operación es una venta entre partes relacionadas y tiene reglas propias. El sistema tiene que registrarla como lo que es.
En la práctica significa tres cosas. Que las operaciones entre entidades del grupo estén identificadas como tales y no mezcladas con las ventas a terceros. Que el precio aplicado quede documentado con el criterio que lo justifica. Y que los reportes consolidados eliminen esas operaciones internas, porque de lo contrario el grupo aparece vendiéndose a sí mismo.
Esa última parte se olvida con frecuencia y produce reportes de venta consolidada inflados que nadie detecta hasta que alguien compara con la contabilidad.
Qué hacer con el histórico de los dos sistemas
La empresa tenía cuatro años de datos en cada uno de los sistemas anteriores. La tentación de migrarlo todo era fuerte.
Se migró solo lo que tenía uso operativo: clientes activos, productos vigentes, saldos abiertos y el histórico de compra de los últimos veinticuatro meses. El resto se conservó en una copia consultable de los sistemas viejos, sin migrar.
Es una decisión que incomoda al principio y que ahorra semanas. La mayor parte del histórico de un sistema de gestión no se vuelve a consultar nunca; migrarlo cuesta lo mismo que migrar el que sí se usa.