Diario de una adaptación: llevar un ERP heredado a la factura electrónica B2B
Resumen:
- Rara vez hay que cambiar de ERP: se añade un módulo de emisión conforme y se conecta.
- La parte lenta no es el desarrollo, es normalizar los datos maestros de clientes.
- Emitir en paralelo unas semanas elimina el riesgo de descubrir fallos sin vuelta atrás.
- El proyecto lo debe liderar administración, no informática: las decisiones son de negocio.
Una empresa de distribución de material eléctrico, cuarenta empleados, un ERP construido a medida en 2011 y ampliado por cuatro desarrolladores distintos desde entonces. Ninguno seguía en contacto. La documentación consistía en un archivo de texto con instrucciones de instalación.
El encargo era claro: llegar a la factura electrónica B2B obligatoria sin parar la operación. Estas son las decisiones, en orden.
Semana uno: decidir qué no tocar
La primera tentación con un sistema así es reescribirlo. Es casi siempre la decisión equivocada cuando hay una fecha límite legal de por medio, porque convierte un problema acotado en un proyecto de un año.
Trazamos una frontera: todo lo que no fuera la emisión de facturas quedaba intacto. Almacén, pedidos, tarifas, informes. El ERP seguiría funcionando exactamente igual y solo cambiaría el momento en que se genera el documento fiscal.
Eso redujo el alcance de «un ERP entero» a «un módulo y sus conexiones».
Semana dos: encontrar dónde se emiten las facturas
Sonaba trivial y no lo fue. En catorce años, la emisión de facturas se había implementado tres veces en sitios distintos: la pantalla principal, un proceso nocturno de facturación periódica y un botón en el módulo de albaranes que alguien añadió en 2017.
Las tres escribían en la misma tabla con lógicas ligeramente distintas. Una de ellas no calculaba igual los descuentos por volumen, un defecto que llevaba años produciendo diferencias pequeñas que administración corregía a mano sin saber de dónde venían.
Encontrar eso fue, para el cliente, más valioso que el propio cumplimiento normativo.
Semanas tres a siete: el módulo de emisión
Se construyó un único punto de emisión al que los tres orígenes llaman. Ese módulo genera el documento en el formato exigido, lo registra de forma encadenada e inalterable, y devuelve el resultado al ERP.
| Componente | Decisión |
|---|---|
| Formato del documento | Generación conforme al estándar exigido, con validación contra el esquema antes de dar por emitida la factura. Si no valida, no se emite. |
| Registro | Tabla nueva, solo de inserción, con huella encadenada. Sin operaciones de actualización ni borrado disponibles desde ninguna parte del código. |
| Envío | Cola con reintentos. Un fallo de red no puede dejar la factura en un estado ambiguo ni provocar un envío duplicado. |
| Estados | Cada factura tiene un estado explícito y visible para administración. El «no sé si se envió» es el peor escenario operativo. |
Semanas cuatro a doce: los datos, en paralelo
Aquí estuvo el verdadero cuello de botella. El formato exigido requiere datos del receptor que el ERP guardaba de forma laxa: identificación fiscal, dirección completa, forma jurídica.
La base tenía cerca de tres mil clientes activos. Al validarlos:
- Un número relevante tenía identificación fiscal con formato incorrecto, muchas veces por espacios o guiones.
- Había duplicados: el mismo cliente con dos o tres fichas creadas en años distintos.
- Algunas direcciones eran texto libre imposible de descomponer en campos estructurados.
Ninguno de esos problemas se resuelve programando. Se resuelven con una persona de administración decidiendo caso por caso. Reservamos dos tardes semanales durante ocho semanas y aun así fue lo último en terminarse.
Preguntas frecuentes
¿Hay que cambiar de ERP para cumplir?
Casi nunca. Lo habitual es añadir un módulo de emisión conforme y conectarlo al ERP existente, dejando intacto todo lo demás. Cambiar de sistema entero por una obligación normativa suele ser una decisión desproporcionada, salvo que el ERP ya estuviera al final de su vida útil por otros motivos.
¿Qué pasa con las facturas antiguas?
No hay que convertirlas. La obligación aplica a la emisión desde la fecha de entrada en vigor. Lo que sí conviene es asegurar que el histórico se conserva accesible y legible durante el plazo legal, porque una migración descuidada puede dejarlo inservible.
¿Cuánto tiempo hay que reservar para la limpieza de datos?
Más del que nadie calcula. En los proyectos que hemos hecho, la normalización de clientes y proveedores consumió entre un tercio y la mitad del calendario. No es trabajo técnico: es alguien de administración revisando fichas una por una.
¿Se puede emitir en paralelo durante la transición?
Sí, y es lo recomendable. Se emite por el sistema nuevo y se sigue registrando en el antiguo durante unas semanas, hasta que los números cuadran. Duplica trabajo temporalmente y elimina el riesgo de descubrir un fallo cuando ya no hay vuelta atrás.
¿Quién debe liderar el proyecto desde la empresa?
Alguien de administración con autoridad para decidir sobre los datos, no de informática. Las decisiones difíciles de estos proyectos son de negocio: qué cliente es el bueno cuando hay tres fichas duplicadas, qué se hace con las que no tienen identificación fiscal válida.
Lo que quedó después
La empresa cumple. Pero lo que valoran hoy, un año después, no es eso: es que por primera vez tienen un único sitio donde se emiten las facturas, un padrón de clientes limpio y la certeza de que los descuentos se calculan igual en todos los caminos.
La normativa fue la excusa que financió una limpieza que llevaba años pendiente. Es un patrón que se repite: las obligaciones legales suelen ser el único momento en que una empresa acepta mirar dentro de su sistema.
Lo que haríamos distinto la próxima vez
Dos cosas.
La primera: empezar la limpieza de datos antes que el desarrollo, no en paralelo. Arrancamos las dos líneas a la vez porque parecía eficiente, y el resultado fue que el módulo estuvo listo semanas antes de que hubiera datos válidos con los que probarlo de verdad. Si la validación de clientes hubiera empezado el primer día, el calendario total habría sido más corto.
La segunda: pedir desde el inicio una persona de administración con dedicación asignada, no «cuando pueda». Las decisiones sobre datos maestros no las puede tomar nadie de fuera, y cada consulta que espera tres días se convierte en tres días de retraso.
Señales de que tu ERP está en la misma situación
- Nadie sabe con certeza en cuántos sitios del programa se puede emitir una factura.
- Administración corrige a mano diferencias pequeñas de forma habitual, sin saber de dónde vienen.
- La documentación técnica es un archivo de instrucciones de instalación, o no existe.
- El desarrollador original no está localizable y nadie ha abierto el código en años.
Si reconoces tres de las cuatro, la obligación normativa no es tu problema principal. Es el aviso.