Volver al blog Operaciones SMS A2P

Validación de archivos de carga masiva SMS A2P: guía operativa

Una guía para diseñar controles por etapas en archivos de SMS A2P, identificar errores corregibles y conservar la trazabilidad sin confundir validación con consentimiento o entrega.

Flujo de validación por etapas para un archivo de carga masiva de SMS A2P

Qué problemas evita validar antes de crear mensajes

Una carga masiva puede reunir datos correctos, registros incompletos y errores que impiden interpretar una fila. Validar antes de crear mensajes permite detectar esos problemas en una etapa controlada y mostrar qué registros requieren revisión, en lugar de descubrirlos después de iniciar el procesamiento.

La validación debe entenderse como un control de datos y reglas previamente definidas. No demuestra que exista consentimiento para contactar, que un remitente esté autorizado en un destino ni que un mensaje vaya a entregarse. Esas comprobaciones pertenecen a procesos distintos y dependen del contexto, las reglas aplicables y las capacidades disponibles.

  • Acordar qué estructura acepta el sistema y qué significa cada campo.
  • Separar errores de lectura de incumplimientos de reglas operativas.
  • Conservar una referencia inequívoca entre cada registro original y su resultado.
Qué problemas evita validar antes de crear mensajes

Definir el contrato de datos

Antes de aceptar archivos, documenta un contrato de datos: formatos admitidos, codificación esperada, encabezados reconocidos, campos obligatorios y tratamiento de valores vacíos. Si se admiten variantes, especifícalas de forma explícita. No dependas de suposiciones como el orden de columnas o la interpretación automática de fechas y números.

Al leer el archivo, comprueba que se puede interpretar con el formato declarado y que las columnas requeridas existen. Distingue entre un archivo que no puede analizarse y uno que sí se lee, pero contiene filas incompletas. La primera situación afecta al archivo entero; la segunda suele poder informarse por registro.

No existe en la evidencia disponible una convención única para la codificación, los encabezados o los campos obligatorios de toda carga masiva A2P. Por eso, estas reglas deben fijarse para cada integración y comunicarse a quienes preparan los archivos.

  • Publica una plantilla y una definición de cada columna, incluidos los formatos y valores permitidos.
  • Indica si se toleran columnas adicionales, campos vacíos o encabezados alternativos.
  • Usa errores distintos para archivo ilegible, encabezado ausente y dato requerido vacío.
Definir el contrato de datos

Validaciones por registro: número, remitente y contenido

Para cada fila, valida que el número destinatario esté presente y pueda interpretarse conforme a las reglas acordadas para la integración. Si se aplica una normalización, define y documenta su comportamiento; no añadas prefijos, elimines caracteres o cambies la interpretación basándote en una suposición. La recomendación E.164 es una referencia de numeración internacional, pero la información disponible aquí no permite detallar sus reglas ni concluir que una cadena que las cumpla sea enrutable.

Comprueba que el remitente y el contenido estén presentes cuando el caso de uso los requiera y que puedan representarse en el formato esperado. La sintaxis válida de un remitente no prueba que esté autorizado para el destino. Del mismo modo, que el texto se pueda leer no confirma que cumpla las reglas de consentimiento, políticas aplicables o restricciones de una ruta.

Mantén separadas las comprobaciones de datos y las decisiones de envío. Una fila puede ser sintácticamente válida y, aun así, requerir una revisión de autorización, política o elegibilidad antes de procesarse.

  • Define los formatos de número admitidos y qué casos se rechazan o requieren revisión.
  • Valida el remitente según las reglas configuradas para el contexto, sin tratar la validación sintáctica como autorización.
  • Comprueba que el contenido sea interpretable y que los campos de personalización requeridos estén disponibles.

Detectar duplicados sin cambiar la intención

Dos filas similares no son necesariamente duplicadas: pueden representar envíos legítimos a la misma persona, por ejemplo, en momentos distintos o para propósitos diferentes. Antes de marcar duplicados, define qué combinación de campos y qué periodo, si corresponde, se utilizarían para detectar coincidencias. No elimines ni combines registros automáticamente sin una regla acordada con el responsable del proceso.

Conviene distinguir entre duplicado exacto del archivo, coincidencia según una regla de negocio y repetición legítima. La decisión puede ser advertir, bloquear o dejar pasar el registro; debe ser explícita, auditable y coherente con la finalidad del envío.

  • Define la clave de comparación y el alcance de la detección antes de implementarla.
  • Conserva los registros originales y comunica qué filas coinciden.
  • No presentes una coincidencia como prueba de error o fraude.

Clasificar errores por etapa

Una clasificación útil separa al menos tres niveles. Los errores de formato impiden leer el archivo o interpretar un campo. Los errores de reglas de negocio indican que un valor no satisface una condición acordada. Las restricciones de envío comprenden decisiones posteriores sobre autorización, políticas o posibilidad de procesar el tráfico. No mezcles estas categorías en un único estado genérico de «inválido».

Un error corregible puede resolverse modificando el archivo o el dato y volviendo a validarlo. Un rechazo definitivo, dentro de las reglas configuradas, indica que el registro no debe avanzar en ese proceso. Evita llamar definitivo a un error si solo significa que falta información o revisión. La clasificación debe reflejar la causa conocida, no una conclusión que el control no puede demostrar.

  • Usa estados distintos para archivo ilegible, dato corregible, regla incumplida y revisión pendiente.
  • Explica qué acción puede tomar la persona que prepara la carga.
  • No conviertas un fallo de validación en una afirmación sobre consentimiento, identidad o entrega.

Resultados accionables y referencia a la fila

Cada resultado de validación debería señalar qué registro se evaluó y cuál fue la causa del aviso o rechazo. Para ello, conserva una referencia estable al registro de origen, como su número de fila dentro del archivo recibido y, si existe, un identificador propio de la carga. La referencia debe mantenerse aunque el sistema transforme o normalice valores para procesarlos.

Describe el campo afectado, la regla aplicada y una acción posible. Evita mensajes ambiguos como «error de número» si puedes indicar que falta el destinatario o que el valor no satisface el formato esperado. La información devuelta debe ser suficiente para corregir, pero no exponer datos personales innecesarios.

  • Incluye identificador de carga, referencia de fila, campo, resultado y motivo legible.
  • Distingue advertencias de rechazos y explica qué hacer a continuación.
  • Protege los datos personales en informes, registros y canales de soporte.

Cargas grandes, lotes y reenvíos

El tamaño máximo de archivo, el número de registros por lote y la estrategia de procesamiento dependen del sistema que recibe la carga. No hay aquí evidencia que permita recomendar límites numéricos universales. Define los límites según las capacidades verificadas de la implementación y publícalos antes de que los equipos preparen sus archivos.

Si se procesa por lotes, conserva el identificador de la carga y la posición de cada fila a través de todas las etapas. Diseña el reenvío para que un fallo parcial no convierta silenciosamente una repetición en nuevos mensajes. La semántica de reintentos y deduplicación debe quedar especificada por la integración; no se puede inferir solo de que el archivo se haya vuelto a enviar.

  • Documenta límites y comportamientos comprobados en la integración concreta.
  • Registra qué parte se validó y procesó, sin ocultar resultados parciales.
  • Define cómo se reconoce una repetición de carga antes de permitir reenvíos.

Trazabilidad y retención proporcional

Mantén una relación verificable entre el archivo recibido, cada fila, el resultado de validación y cualquier mensaje que llegue a crearse. Esa trazabilidad ayuda a investigar errores y a responder preguntas operativas, pero debe limitarse a los datos necesarios para la finalidad definida.

Establece una política de retención para archivos y resultados que incluya quién puede acceder, qué datos se conservan y cuándo se eliminan. La información disponible no determina un plazo adecuado ni sustituye las obligaciones aplicables en cada jurisdicción. Define esos límites con las personas responsables de privacidad, seguridad y cumplimiento, y evita conservar copias completas cuando una referencia mínima sea suficiente.

  • Conserva identificadores de carga y fila que permitan reconstruir el resultado sin duplicar innecesariamente datos.
  • Restringe accesos y evita incluir números o mensajes completos en registros si no son necesarios.
  • Determina los plazos de conservación según la finalidad y las obligaciones aplicables.
FAQ

Preguntas frecuentes

¿Un archivo validado demuestra que los destinatarios dieron su consentimiento?

No. La validación de estructura y datos solo demuestra que se cumplen las comprobaciones configuradas para la carga. El consentimiento y las demás obligaciones de mensajería requieren controles independientes.

¿Un número que supera la validación garantiza que el SMS llegará?

No. Una comprobación de formato no demuestra que el número esté activo, que la ruta esté disponible ni que el mensaje se entregue. No debe presentarse como garantía de entrega.

¿Conviene eliminar automáticamente las filas duplicadas?

No sin una regla acordada. Coincidencias similares pueden corresponder a mensajes legítimos. Define cómo se identifica un duplicado y si se advierte, se bloquea o se permite.

¿Qué información debería incluir un error de validación?

Como mínimo, una referencia a la carga y a la fila, el campo afectado, el motivo y una acción posible. Limita los datos personales expuestos en el informe.

¿Qué tamaño máximo debería tener un archivo?

Depende de las capacidades verificadas del sistema y de la integración. Define y comunica el límite concreto; no hay un valor universal que pueda recomendarse aquí.

Fuentes consultadas

  1. Especificación SMPP v3.4SMPP Developers Forum
  2. Recomendación E.164Unión Internacional de Telecomunicaciones (ITU-T)
  3. Especificaciones 3GPP3GPP
  4. Semántica HTTP (RFC 9110)IETF