---
id: KB-IN-020
url: https://app.codecontract.io/ayuda/integraciones/cuando-vuestro-sistema-se-actualiza
idioma: es
categoria: integraciones
audiencia: usuario
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [en]
relacionados: [KB-IN-008, KB-IN-016, KB-IN-018]
citadoPor: [KB-IN-005]
---

# Cuando vuestro sistema se actualiza

_No cambiáis de programa: solo lo actualizan. Y la integración sigue funcionando, que es justo lo que la hace peligrosa._

**Responde a:** han actualizado el erp y la integración falla · actualización de versión y campos que cambian · la integración sigue pero faltan datos · avisar al proveedor antes de actualizar

Vuestra informática o vuestro proveedor actualiza el programa un fin de semana. El lunes todo funciona: la gente entra, los pedidos salen, y la integración sigue enviando datos. Por eso este problema tarda semanas en aparecer, y para entonces ya ha ensuciado el histórico.

## Cómo se rompe una integración sin dejar de funcionar

| Qué cambió | Qué se ve | Qué está pasando de verdad |
| --- | --- | --- |
| Un campo cambió de nombre | Todo sigue igual | Ese dato llega vacío y nadie lo mira |
| Un campo cambió de formato | Los datos entran | Entran mal: fechas o importes distintos |
| Se añadió un campo obligatorio | Empiezan a fallar algunos envíos | Es el caso bueno: se nota |
| Cambió cómo se identifica un registro | Se crean duplicados | Cada envío crea uno nuevo en vez de actualizar |

> [!IMPORTANT]
> Las dos primeras filas son las peligrosas por el mismo motivo: **una integración no avisa de lo que deja de recibir**. Si un campo pasa a llamarse de otra forma, no hay error: hay un hueco, y los expedientes se van creando con ese dato vacío durante semanas. Cuando alguien lo nota, hay que decidir si se rellenan doscientos casos a mano. El fallo ruidoso —el envío que se cae— es en realidad el mejor escenario, porque se descubre el mismo día.

## Qué hacer alrededor de una actualización

1. **Enteraos de cuándo va a ser, aunque no os afecte «a vosotros»** — Es información que casi nunca llega a quien lleva la integración.
2. **Preguntar qué cambia en los datos, no en la interfaz** — Lo que le importa a una integración no sale en las notas de versión.
3. **Comprobar un caso completo al día siguiente** — Uno de verdad, con sus datos, no un ping.
4. **Y mirar los expedientes de esa semana con lupa** — Es donde aparecerán los huecos si los hay.

> [!WARNING]
> El aviso que conviene tener montado antes de que pase: **una comprobación que mire si el dato llega, no si el envío responde**. Que la integración conteste «recibido» no significa nada sobre lo que había dentro. Una revisión sencilla —cuántos de los últimos expedientes tienen ese campo vacío— detecta en un día lo que de otro modo se descubre cuando un cliente pregunta por qué le falta un número.

## Si el que actualiza sois vosotros

**En corto**

- Avisad a quien mantiene cada integración antes, no después.
- Guardad un ejemplo de cómo llegaban los datos antes de actualizar: es con lo que compararéis.
- Y si es posible, actualizad un día en que alguien pueda mirar al día siguiente.

> [!NOTE]
> Este mismo problema aparece cuando el que actualiza es el proveedor de la otra punta y no os avisa. La diferencia es que ahí no lo podéis planificar; solo detectarlo pronto, y para eso sirve la comprobación de arriba.

**¿Puedo probar la actualización antes en algún sitio?**

Preguntad a vuestra informática: si hay entorno de pruebas, es el momento de usarlo.

**¿Y si el hueco lleva semanas?**

Rellenad lo que se pueda por lote y anotad desde cuándo faltaba.

**¿Conviene congelar la integración durante la actualización?**

Pararla un rato es más barato que limpiar duplicados después.

## Ejemplos

**Una empresa actualiza su ERP y tres semanas después descubre expedientes sin número de pedido.**

- Comprueba un caso completo al día siguiente y revisa cuántos llegan con el campo vacío

→ El hueco se detecta en un día en vez de en doscientos expedientes que hay que repasar.

**El ERP se actualiza un fin de semana y el lunes la integración no funciona.**

- Pide el calendario de actualizaciones a informática
- Prueba el flujo en el entorno de pruebas antes del salto

→ La actualización se afronta con la integración ya comprobada.

**Cambia un campo y la integración empieza a fallar en silencio.**

- Configura un aviso si deja de llegar actividad

→ El fallo se detecta en horas.

**Se actualiza y nadie prueba nada.**

- Prueba un caso real justo después

→ El problema se descubre antes que los usuarios.

**La actualización cambia el formato de un dato.**

- Valida el formato antes de escribir

→ El dato malo no se propaga.

**Se acumulan avisos sin procesar durante la ventana.**

- Comprueba lo pendiente al terminar

→ La ventana no deja un agujero.