Cómo se integran realmente los módulos de un ERP

La palabra integrado esconde tres cosas distintas

Casi todos los folletos de ERP usan la palabra integrado. Debajo hay al menos tres modelos que se comportan de forma muy distinta cuando algo falla en el cierre de mes. El primero es la transferencia de ficheros o por lotes programados: un sistema exporta y otro importa, normalmente por la noche. El segundo es la sincronización mediante API o middleware, en la que dos bases de datos separadas se mantienen al día intercambiando mensajes. El tercero son los datos realmente compartidos, en los que los módulos no son sistemas separados, sino vistas distintas sobre un mismo conjunto de tablas, un único libro mayor y un único conjunto de registros maestros.

Ninguno es correcto en todos los casos. La transferencia por lotes es barata, fácil de entender y sobrevive a una caída de cualquiera de los dos lados, porque el fichero simplemente espera. También está siempre desfasada por diseño, y un proceso fallido puede pasar inadvertido hasta que alguien cuestiona un informe. La sincronización por API ofrece un comportamiento casi en tiempo real y permite conservar sistemas que hay buenas razones para conservar, pero a cambio usted pasa a ser dueño de un sistema distribuido: reintentos, orden de los mensajes, fallos parciales y dos copias de la verdad que pueden no coincidir. Los datos compartidos eliminan el tipo de problema en el que dos bases de datos divergen, porque solo hay una, pero obligan a los módulos a ponerse de acuerdo en un único plan de cuentas, una única definición de artículo y un único ritmo de versiones, lo que es una restricción y no una ventaja gratuita.

La pregunta práctica no es qué nivel es el mejor, sino qué nivel merece cada flujo. Transferir cada noche un extracto bancario está bien. Transferir cada noche los niveles de existencias que hay detrás de un punto de venta en funcionamiento, no. Skyline Nexus se sitúa en el tercer nivel para sus propios módulos: contabilidad, punto de venta e inventario, CRM, mantenimiento, recursos humanos, flota y activos escriben en un único libro mayor y un único conjunto de maestros, y se integran hacia fuera mediante API con sistemas externos cuando un cliente ya tiene un sistema que merece la pena conservar.

La deriva empieza en los datos maestros

De los fallos de integración se suele culpar a las interfaces, pero la primera grieta suele ser un registro maestro que existe dos veces con un contenido ligeramente distinto. En cuanto dos sistemas tienen cada uno su propia lista de clientes, las listas divergen en cuestión de semanas, y todas las cifras que dependen de ellas heredan esa divergencia.

• Cliente: una sola identidad en ventas, facturación, cobros y control de crédito, o la antigüedad de clientes no coincidirá con el informe de ventas.
• Proveedor: compartido entre compras, cuentas a pagar y pagos, incluidos los datos bancarios, que son objetivo de fraude cuando están duplicados.
• Artículo: un código, una unidad de medida, un método de valoración. Dos maestros de artículos significan dos valoraciones de existencias.
• Plan de cuentas: una única estructura. Si un módulo mantiene su propia lista de cuentas y la mapea a la suya, el mapeo es una segunda cosa que mantener y en la que equivocarse.
• Códigos de impuesto: una sola definición de tipo, tratamiento y fechas de vigencia, usada tanto por la transacción como por la declaración.
• Sucursal y ubicación: compartidas, porque tanto las existencias como la contabilidad se dimensionan por ellas.
• Empleado: un único registro detrás de la nómina, la asistencia, las órdenes de trabajo de mantenimiento y la asignación de vehículos.
• Activo: un único registro detrás de la amortización, el historial de mantenimiento y la baja.

Libros auxiliares y la cuenta de control

El libro mayor contiene saldos resumidos. El detalle está en los libros auxiliares, y cada libro auxiliar está vinculado a una cuenta de control del mayor. Cuentas a cobrar contiene una línea por cada factura y cobro de cliente, cuya suma es la cuenta de control de clientes. Cuentas a pagar hace lo mismo con las facturas de proveedores. Los movimientos de inventario se contabilizan en una cuenta de control de existencias, y el coste de las mercancías vendidas se reconoce a medida que salen. La nómina contabiliza el salario bruto, las cotizaciones a cargo de la empresa, las retenciones y los pasivos netos. El inmovilizado contabiliza altas, amortizaciones y bajas contra el coste del activo y la amortización acumulada. El punto de venta contabiliza las ventas, el impuesto repercutido, los medios de pago y, cuando se usa inventario permanente, el lado del coste de cada venta.

La regla que hace que esto sea fiable es sencilla: el libro auxiliar debe conciliar siempre con su cuenta de control, hasta la unidad monetaria. Si la antigüedad de clientes dice una cifra y la cuenta de control de clientes dice otra, una de las dos está mal y no se puede saber cuál sin investigar. Por eso normalmente se bloquean los asientos directos en las cuentas de control. Un asiento manual en clientes crea un saldo que ningún cliente debe, y que no aparecerá en ningún extracto que usted envíe.

La conciliación debe ser un informe que se pueda ejecutar cuando se quiera, no una hoja de cálculo que alguien mantiene. Cuando los módulos comparten un único libro mayor, la conciliación es casi una tautología. Cuando no lo comparten, es el control más importante que se puede automatizar.

Reglas de contabilización y pista de auditoría

Cada línea del libro mayor debe poder rastrearse hasta un documento de origen: un número de factura, una entrada de mercancías, un proceso de nómina, un calendario de amortización, una transacción de punto de venta. Si existe una línea sin origen, alguien se ha saltado el proceso. El identificador del documento debe viajar con la línea del mayor, no estar en una tabla de correspondencias aparte.

Los asientos contabilizados no deben poder modificarse sin dejar rastro. Las correcciones se hacen con asientos de retrocesión o facturas rectificativas, que dejan visibles tanto el original como la corrección, cada uno con su fecha y su usuario. El cierre del periodo debe bloquearlo, en lugar de confiar en que la gente recuerde no registrar con fecha anterior. La prueba es si se puede tomar cualquier saldo, abrirlo y bajar hasta los documentos que lo originaron sin salir del sistema.

Dónde fallan realmente las integraciones

Los modos de fallo son bien conocidos y casi siempre son los mismos.

• Calendario y corte: una venta contabilizada justo antes de la medianoche del último día del periodo llega al otro sistema después del corte, y los dos periodos no coinciden nunca.
• Procesos fallidos que nadie vigila: una transferencia programada deja de ejecutarse y la ausencia de datos parece una semana tranquila.
• Escrituras parciales: se crea la cabecera de la factura, fallan las líneas y un lado tiene ahora un documento que el otro no reconoce.
• Claves duplicadas: un mensaje reenviado crea una segunda copia de la misma factura, o un sistema de numeración colisiona entre sucursales.
• Deriva por divisas y redondeos: dos sistemas que redondean en momentos distintos, o que usan tipos de cambio distintos para el mismo día, generan pequeñas diferencias que se acumulan.
• Impuesto calculado dos veces: el sistema transaccional y el contable calculan cada uno el impuesto, con reglas ligeramente distintas sobre descuentos, precios con impuesto incluido o redondeo por línea frente a por documento. La factura entregada al cliente y la cifra de la declaración dejan entonces de coincidir.

Idempotencia y la prueba de que ambos lados coinciden

Todo lo que puede reintentarse acabará reintentándose, así que cada operación de contabilización necesita una clave estable derivada del documento de origen. Enviar la misma factura dos veces debe dar lugar a una sola contabilización, no a dos. El lado receptor debe registrar qué claves ha procesado ya y devolver el resultado anterior en lugar de crear uno nuevo. Sin esto, el comportamiento normal de la red se convierte en ingresos duplicados.

Además, hace falta que la conciliación sea una funcionalidad de primer nivel: recuentos y totales por periodo y por tipo de documento, comparados en ambos lados, con las diferencias enumeradas y no resumidas. Una marca verde que solo dice que el último proceso terminó bien no prueba que ambos lados coincidan. El informe útil es el que nombra los siete documentos que existen en un lado y no en el otro.

Sucursales y divisas

Operar con varias sucursales significa que cada transacción lleva su ubicación como dimensión desde el momento en que se crea, no asignada después por la lógica de un informe. Existencias, ingresos, costes y personal pertenecen todos a una sucursal, y los traspasos entre sucursales necesitan que se contabilicen ambos lados, o las existencias de las dos sucursales no sumarán la cifra de la empresa. La numeración de documentos debe ser única entre sucursales y a la vez tener sentido dentro de cada una.

La multidivisa necesita que la moneda de la transacción, el tipo de cambio utilizado y el importe en moneda base se guarden todos en la línea. Guardar solo la cifra convertida destruye la evidencia. Así, la actualización de los saldos abiertos y las diferencias de cambio realizadas en la liquidación tienen dónde contabilizarse, y la diferencia de cambio deja de ser un misterio de redondeo.

Nota regional: el modelo de validación previa cambia el calendario

Donde se aplica un régimen de facturación electrónica, el momento de la integración deja de ser una preferencia de diseño. Varias administraciones tributarias exigen ya que las facturas se validen ante la administración o se le comuniquen antes de que lleguen al comprador, o en el mismo momento. El régimen de la ZATCA en Arabia Saudí es un ejemplo vigente: las facturas se generan con una estructura definida, elementos criptográficos e identificadores, y la administración interviene en el ciclo de vida del documento en lugar de recibir un resumen después. Eso convierte la creación de la factura en un problema de integración en tiempo real. Un proceso nocturno por lotes no puede producir un documento que el cliente está esperando en el mostrador.

El panorama es distinto en otros lugares, y conviene ser preciso. Estados Unidos no tiene ningún mandato federal de facturación electrónica, y el impuesto sobre las ventas se gestiona a nivel estatal, con normas y tipos que varían según el estado y a menudo según la jurisdicción local. Canadá aplica el GST y el HST a nivel federal con variaciones provinciales, incluidos impuestos provinciales sobre las ventas en algunas provincias. Los demás mercados de la región MENA están en fases distintas. La lección de diseño es mantener la determinación del impuesto y la emisión del documento en un solo lugar, para que un mercado que pasa de la comunicación a la validación previa cambie de configuración y no de arquitectura. Skyline Nexus gestiona la validación ante la ZATCA desde la misma transacción que escribe el asiento en el libro mayor, de modo que la factura que recibe el cliente y la cifra de la declaración salen de un único cálculo.