No todo cambio es una multa nueva: eventos de alta, corrección y retiro
Una diferencia entre consultas puede ser un alta, una corrección, un cambio de estado o un retiro. Modelarlas igual genera alertas y cobranzas duplicadas.
Por Marco Ferreiro ·
Una integración consulta hoy y encuentra una infracción. Mañana cambia el monto; después aparece otra descripción y más tarde el registro desaparece. Si cada diferencia se procesa como “multa nueva”, el sistema puede duplicar alertas, tareas y cobranzas.
La solución es separar el objeto observado de los eventos que describen su evolución.
Identidad y versión cumplen funciones distintas
La identidad intenta responder si dos observaciones corresponden al mismo hecho. La versión representa cómo se veía ese hecho en un momento. Un cambio de estado o texto genera otra versión, no necesariamente otra identidad.
Cuando la fuente ofrece un identificador estable, se conserva como dato principal. Si no, la correlación usa varios campos y debe expresar su nivel de confianza.
Cuatro tipos de evento iniciales
Un vocabulario mínimo puede incluir:
infraction.observed: primera observación;infraction.corrected: cambio de campos descriptivos o técnicos;infraction.status_changed: transición de estado;infraction.withdrawn: la fuente deja de presentarla o indica retiro.
El negocio puede sumar pago informado, vencimiento o reapertura, pero conviene empezar con tipos que tengan efectos distintos y comprobables.
Alta no significa fecha del hecho
La primera observación en una API ocurre cuando el sistema la detecta. Puede ser días después de la fecha de infracción o carga administrativa. Mezclar esas fechas produce métricas falsas.
El evento debe tener observedAt, mientras el objeto conserva occurredAt o la fecha textual de la fuente. Si alguna falta, se omite; no se copia la otra para completar el campo.
Corrección conserva el antes y el después
Una autoridad puede corregir ubicación, monto o descripción. El evento incluye campos modificados y referencia a la versión anterior. No hace falta duplicar todo el payload si existe un almacenamiento de versiones, pero el consumidor debe poder auditar el cambio.
Una corrección de patente o número de acta puede afectar la identidad. En ese caso se requiere una regla especial y revisión, no un update silencioso.
Cambio de estado no recrea la tarea
Pasar de pendiente a pagada, en revisión o resuelta debería actualizar la tarea existente. Crear otra tarea de cobro por el mismo hecho contradice el propósito del estado.
El consumidor define una tabla de transiciones y efectos. Un evento informativo puede notificar; uno terminal puede cerrar. Esa decisión pertenece al contrato de la integración, no al texto variable de cada fuente.
Retiro no explica la causa
W3C PROV modela la invalidación como el momento desde el cual una entidad deja de estar disponible para uso. Es una idea útil para trazabilidad, pero una desaparición en un portal no demuestra anulación legal.
El evento withdrawn debe decir qué se observó: ausencia confirmada, estado retirado o respuesta incompleta. Si la consulta tuvo timeout, no corresponde emitir retiro.
CloudEvents como envoltorio
CloudEvents define atributos requeridos como id, source, specversion y type. La combinación de origen e identificador permite reconocer reenvíos del mismo evento.
La especificación no define qué es una infracción ni obliga a las jurisdicciones a usarla. Sirve como envoltorio interoperable para que productor y consumidor compartan contexto.
Una secuencia sintética
Supongamos esta historia:
- el 1 de agosto se observa el acta X;
- el 3 cambia la descripción, sin alterar identidad;
- el 8 pasa a estado pagado;
- el 10 deja de aparecer en una consulta completa.
El consumidor recibe cuatro eventos y mantiene una sola entidad. Si el tercero se reintenta, su ID evita aplicar dos veces el cierre. El cuarto conserva la última versión y marca la ausencia, no borra el historial.
Idempotencia en el consumidor
Antes de ejecutar efectos, el consumidor registra source + id en una operación atómica. Si ya existe, confirma recepción sin repetir acciones. El payload también puede llevar una versión para rechazar eventos atrasados.
Los reintentos son normales en sistemas distribuidos. Diseñarlos como excepción garantiza duplicados cuando haya una falla real.
Privacidad y minimización
Un webhook empresarial no necesita enviar DNI, domicilio, imagen completa o datos de contacto para comunicar un cambio. Debe limitarse al identificador contractual, tipo, tiempos y campos autorizados.
Los logs omiten payloads sensibles. Para depuración se usan IDs de correlación y hashes, con retención definida.
Qué medir
Las métricas útiles separan altas, correcciones, estados y retiros. También cuentan reintentos, duplicados descartados y eventos atrasados. “Multas nuevas” deja de inflarse con cada ajuste de una fuente.
Antes de publicar estadísticas, la organización documenta cobertura, ventana y reglas de correlación. Una secuencia sintética valida el contrato sin exponer datos de producción.
Qué aporta multas.ar
La API de multas.ar puede comunicar resultados y procedencia para integraciones de flota. El ejemplo de eventos es un patrón de diseño, no una afirmación sobre telemetría ya disponible en cada portal.
Al separar identidad, versión y evento, la empresa reacciona a cambios reales sin perder historia. Una corrección deja de parecer una deuda nueva y un retiro deja de borrar la evidencia que explica el recorrido.
Metodología
- Alcance
- Integraciones empresariales que comparan consultas periódicas de infracciones.
- Unidad de análisis
- Evento inmutable aplicado a una identidad estable y una versión observada.
- Cobertura
- Se usa una secuencia sintética; no se afirma que las fuentes oficiales emitan CloudEvents.
Limitaciones
- Algunas fuentes no explican por qué un registro desaparece.
- La identidad puede ser probabilística cuando faltan claves estables.
Fuentes
- CloudEvents specification — Cloud Native Computing Foundation (consultada el )
- CloudEvents primer — Cloud Native Computing Foundation (consultada el )
- PROV-O — The PROV Ontology — World Wide Web Consortium (consultada el )
- JSON Data Interchange Format — RFC 8259 — RFC Editor (consultada el )
Preguntas frecuentes
¿Un acta que cambia de monto es una multa nueva?
No necesariamente. Si la identidad del hecho se conserva, puede ser una corrección o actualización. Debe registrarse el antes y el después.
¿Retiro significa anulación jurídica?
No por sí solo. Significa que la fuente dejó de devolver el objeto o lo marcó retirado; la causa debe conservarse si está disponible.
¿Por qué cada evento necesita un ID?
Para que un reintento no aplique dos veces el mismo cambio. En CloudEvents, la combinación de source e id identifica el evento.
Notas relacionadas
Cómo versionar una respuesta cuando cada jurisdicción cambia
Una respuesta agregada necesita distinguir versión de contrato, revisión de datos y estado de cada fuente. Así un cambio municipal no obliga a reinterpretar silenciosamente todo el resultado.
Webhooks de nuevas multas: idempotencia, reintentos y trazabilidad
Un webhook confiable puede llegar más de una vez, demorarse o fallar después de ser procesado. El diseño debe deduplicar eventos, reintentar con límites y conservar evidencia de punta a punta.
Cancelar una consulta de multas en curso
Cancelar detiene trabajo futuro; no deshace lo que ya terminó ni borra lo que una fuente contestó antes del pedido. Conviene declarar qué estados lo admiten y qué pasa con la cuota.