--- title: Módulo ABM comercios slug: modulo-abm-comercios docTags: createdAt: 2026-01-24T16:28:22.093Z --- ## Definiciones El módulo **ABM (Alta, Baja y Modificación)** constituye la **capa primaria de ingreso y mantenimiento de datos maestros** dentro de la Plataforma SUGA. Desde este módulo se gestionan las entidades fundamentales del ecosistema (por ejemplo, comercios, subcomercios, adquirentes, medios, configuraciones base, entre otros), y actúa como el **punto de origen de la información** que alimenta al resto de los procesos y subprocesos de la plataforma. En términos conceptuales, ABM representa la **fuente de verdad** sobre la cual se construyen los flujos de onboarding, operación, transacciones, costos, liquidaciones, conciliaciones y reporting. ```mermaid flowchart TD UI[Onboarding Digital
UI SUGA - SaaS] API[ABM via API] FILES[ABM via Archivos] UI --> ABM[Motor ABM
Validacion + Contratos de Datos + Persistencia] API --> ABM FILES --> ABM ABM --> CORE[Plataforma SUGA] CORE --> MODS[Modulos Consumidores
Comercios, Medios de Pago, Costos, Transacciones, Terminales, Liquidaciones, etc.] ``` ## **Qué muestra el diagrama** - Existen **tres canales** de ingreso. - Todos convergen en **un único motor ABM**. - Los módulos downstream consumen la misma fuente de verdad. ## Rol del ABM dentro de la arquitectura de SUGA El ABM implementa el dominio de **gestión de datos maestros**, garantizando que la información estructural de la plataforma: - Sea consistente. - Sea validada. - Sea versionable. - Sea trazable. Todos los módulos que conforman la plataforma(Gestión de Comercios, Medios de Pago, Costos de Servicio, Transacciones, SmartCoupon, Terminales, Liquidaciones, etc.) **consumen datos generados o mantenidos desde ABM**. Como consecuencia, la calidad de la operación de la plataforma está directamente relacionada con la calidad de los datos ingresados en este módulo. ## Componentes — Estándares de Calidad de Datos Los siguientes estándares aplican a todos los canales de ingreso. Su cumplimiento es obligatorio para garantizar el comportamiento predecible de la plataforma. ### Campos Obligatorios Todos los campos definidos como obligatorios en el contrato de datos de cada entidad deben estar completos antes de ser enviados al Motor ABM. No se admite la práctica de ingresar valores temporales o ficticios para saltar validaciones con intención de completar datos posteriormente. ### Tipos de Dato, Longitudes y Formatos Los tipos de dato (texto, numérico, fecha, booleano) deben respetarse en su totalidad. Las longitudes máximas definidas por el layout no deben ser superadas ni truncadas arbitrariamente. Los formatos de fecha deben seguir el estándar ISO 8601 (YYYY-MM-DD) salvo indicación explícita contraria en el layout. Los identificadores fiscales (CUIT, CUIL, RFC, NIF, entre otros) deben validarse contra el formato del país del comercio antes del ingreso. Los códigos de categoría de comercio (MCC) deben corresponder a la clasificación internacional vigente y ser representativos de la actividad real del comercio. ### Unicidad del MID La plataforma SUGA asigna un único MID por comercio, válido tanto para operaciones de tarjeta presente como no presente. Está prohibido intentar generar múltiples MIDs para el mismo comercio como práctica de evasión de controles. El MID se genera automáticamente por la plataforma una vez que el expediente digital del comercio es aprobado. ### Integridad Referencial Los subcomercios deben estar vinculados a un comercio padre existente y activo en la plataforma. Los medios de pago asignados a un comercio deben pertenecer al catálogo habilitado por el adquirente. Los planes de cuotas referenciados deben existir y estar activos en el Módulo de Gestión de Medios de Pago. Las terminales asociadas deben estar registradas y activas en el módulo de gestión de dispositivos. ### Prohibición de Duplicidades No deben existir entidades duplicadas en la plataforma. Antes de crear un nuevo comercio, el operador debe verificar que no exista ya un registro activo o inactivo con el mismo identificador fiscal. La detección de duplicidades debe escalarse y resolverse antes de proceder con el alta. ## Importancia de la calidad de datos en ABM ABM es el principal **input de datos** del sistema. Errores, omisiones o inconsistencias en esta capa se propagan de forma transversal al resto de la plataforma, impactando potencialmente en: - Autorizaciones. - Cálculo de costos. - Aplicación de reglas. - Liquidaciones. - Conciliaciones. - Reportes. Por este motivo, es **crítico** que: - Se respeten las **documentaciones técnicas vigentes**. - Se utilicen correctamente los **layouts definidos**. - Se completen todos los **campos obligatorios**. - Se validen tipos de datos, longitudes y formatos. ## ABM como contrato de datos Dentro de SUGA, cada entidad administrada por ABM posee un **contrato de datos**: - Estructura. - Campos. - Tipos. - Reglas de obligatoriedad. - Relaciones. Este contrato actúa como acuerdo entre: :::BlockQuote Canales de ingreso de datos → Plataforma → Módulos consumidores ::: Respetar este contrato garantiza: - Integridad referencial. - Compatibilidad entre módulos. - Comportamiento predecible de la plataforma. ## Canales de operación del ABM Las operaciones de ABM pueden realizarse típicamente mediante: - Interfaz digital automatizada. - APIs. - Archivos batch con layout definido. Independientemente del canal, las mismas reglas de validación aplican. ## Beneficios del enfoque ABM en SUGA - Centralización de datos maestros. - Reducción de duplicidades. - Menor necesidad de correcciones posteriores. - Mayor confiabilidad operativa. - Base sólida para escalabilidad.