Un mismo sistema funcionando en dos países: España y Portugal

El encargo sonaba simple: un cliente que ya usaba una funcionalidad de suplidos en España la necesitaba también para su operación portuguesa. Misma empresa, mismo sistema, mismo flujo de trabajo. Lo suficientemente parecido como para pensar que sería cuestión de copiar la pantalla, cambiar cuatro etiquetas y listo.

No lo fue. Un suplido no es un concepto universal: es un concepto fiscal, y cada país lo trata a su manera. Qué se considera suplido, cómo se refleja en la factura, qué justificación hay que conservar. La lógica de negocio (adelantar un gasto por cuenta de un tercero y repercutirlo después) es la misma en los dos países. Las reglas que determinan si eso se puede facturar así, y cómo, no lo son.

Ese desajuste entre “el proceso es el mismo” y “la regla no lo es” es, en nuestra experiencia, el punto exacto donde se decide si un proyecto de este tipo sale bien o se convierte en un problema permanente.

Lo que cambia no es el proceso, es la regla

Cuando una empresa opera en dos países, hay una tentación razonable: tratar cada país como un desarrollo aparte. Al fin y al cabo, hay diferencias reales entre operar en España y en Portugal. La forma de facturar cambia, el idioma en el que se presentan los documentos cambia, los criterios fiscales que aplican a cada tipo de gasto cambian, y los plazos y trámites asociados también son distintos en cada administración.

La tentación es fácil de entender: si todo es distinto, ¿por qué no hacer dos sistemas? Pero eso confunde dos cosas que conviene separar desde el principio: el proceso de negocio (cómo trabaja el equipo, qué pasos sigue, qué decisiones toma) y la regla local que ese proceso tiene que respetar en cada país. El proceso de gestionar un suplido es el mismo aquí y allí. La regla que dice si algo cuenta como suplido, y cómo debe quedar reflejado, no lo es.

Duplicar o parametrizar: la decisión que de verdad importa

Ante ese desajuste hay dos caminos.

Duplicar es rápido. Se copia la funcionalidad, se ajusta al país nuevo y en poco tiempo está funcionando. El coste no se ve al principio: aparece con el tiempo, cuando las dos versiones han empezado a separarse. Cada cambio hay que hacerlo dos veces, y tarde o temprano alguien lo hace solo en una. Con el tiempo, lo que era “el mismo sistema en dos países” se convierte en dos sistemas que se parecen cada vez menos.

Parametrizar cuesta más al principio. Hay que separar con cuidado qué parte del código es proceso (igual en cualquier país) y qué parte es regla local, y convertir el país en una variable real del sistema, no en un comentario o una excepción puntual en el código. Es más trabajo de diseño antes de escribir la primera pantalla. Pero el resultado es un sistema, no dos: los cambios de proceso se hacen una vez y se aplican en ambos países, y los cambios de regla local se aíslan donde corresponde sin tocar el resto.

En este proyecto elegimos parametrizar. Más trabajo hoy, menos deuda dentro de un año. Es una decisión que hemos tomado ya varias veces en distintos proyectos, y casi siempre que hemos optado por la alternativa (duplicar para salir del paso) nos hemos arrepentido más adelante.

Lo que encontramos al abrirlo

Lo que convirtió esta decisión en algo urgente fue lo que apareció al revisar cómo facturaba cada país. La facturación portuguesa se había construido en su momento como un flujo aparte, y con los años se había quedado atrás respecto a la española sin que nadie lo notara:

• En España, la factura se partía en dos según hubiera o no retención, y se añadían automáticamente las líneas de honorarios de la agencia. El flujo portugués no hacía ninguna de las dos cosas.
• Los dos países compartían la marca de “ya facturado”. Facturar algo en un país lo daba también por facturado en el otro, y al revés.

Ninguna de las dos cosas era un error de nadie en concreto. Eran la consecuencia natural de haber duplicado en lugar de parametrizar: dos versiones que nacieron iguales y que cada cambio fue separando un poco más. Así que antes de añadir los suplidos, la decisión fue que Portugal hiciera exactamente lo mismo que España, con la misma lógica, y que lo que de verdad cambia entre los dos países quedara como regla de cada uno.

Qué hace falta para que sea una decisión real y no solo una intención

Decir “vamos a parametrizar” no basta si no se traduce en decisiones concretas de diseño. En la práctica implica cosas como:

• Que el país sea un dato del sistema, no una condición dispersa por el código allí donde hace falta.
• Que las reglas específicas de cada país vivan en un solo sitio, no repartidas entre pantallas, guiones y capas distintas.
• Que añadir un tercer país, si algún día hiciera falta, sea una cuestión de definir sus reglas, no de construir de nuevo la lógica de negocio desde cero.

Esto último es, para nosotros, la prueba de que la parametrización está bien hecha: si el sistema estuviera preparado solo para dos países concretos y no para el concepto de “país” en general, seguiría siendo una duplicación disfrazada, solo que con una única base de código en vez de dos.

El coste no desaparece, se traslada

Conviene ser honestos con esto: parametrizar no elimina el trabajo de entender las diferencias entre países, lo traslada. En lugar de que ese trabajo lo asuma cada copia del sistema por separado (con el riesgo de que una de las dos quede desactualizada sin que nadie se dé cuenta), lo asume el diseño, una sola vez, al principio del proyecto. Es más análisis por adelantado: hay que preguntar, para cada pieza de lógica, si es un proceso o si es una regla que cambia según dónde se aplique. Esa pregunta hay que hacérsela con calma, no sobre la marcha, porque una respuesta equivocada en ese punto es la que después obliga a deshacer trabajo.

Es, en el fondo, la misma lógica que aplicamos a cualquier decisión de arquitectura: el esfuerzo que no se hace al principio no desaparece, reaparece más adelante, y casi siempre más caro.

Lo que nos llevamos

La parte difícil de llevar un mismo sistema a dos países no es la técnica, es resistir la tentación de resolver rápido lo que en realidad es una decisión de arquitectura. Separar el proceso de la regla local cuesta más al principio y ahorra mucho después. Es el mismo criterio que aplicamos en cualquier aplicación FileMaker que tiene que crecer sin multiplicar el trabajo de mantenerla, y es uno de los tipos de proyecto que puedes ver reflejados en nuestros casos.