Su Template de datos de procesamiento de pagos
Su Template de datos de procesamiento de pagos
- Atributos recomendados para recopilar
- Actividades clave que debe seguir
- Guía de extracción para ACI Worldwide
Atributos del procesamiento de pagos
| Nombre | Descripción | ||
|---|---|---|---|
| ID de transacción de pago PaymentTransactionId | Identificador único de la instrucción de pago específica en todo el sistema ACI. | ||
| Descripción Este atributo es la clave central del análisis de Process Mining, ya que vincula todos los eventos relacionados con una misma solicitud de pago. En los sistemas de ACI Worldwide, como MTS o UPP, corresponde al número de referencia único que se asigna a una transacción al ingresarla. Permite reconstruir el recorrido completo del pago, desde la solicitud inicial hasta la validación, la aprobación y la liquidación final. Por qué es importante Es el ID del caso fundamental para agrupar eventos individuales en instancias del proceso. Dónde obtenerlo Revise las tablas de encabezado de transacciones, donde suele aparecer como TRN_REF, REFERENCE_NUM o UUID en el registro principal de transacciones. Ejemplos TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981 | |||
| Marca de tiempo del evento EventTimestamp | Fecha y hora exactas en que se produjo la actividad. | ||
| Descripción Este atributo registra el momento exacto en que se produjo un evento en el entorno ACI. Se utiliza para calcular todas las métricas temporales, incluidos los tiempos de ciclo, la duración de las aprobaciones y las tasas de procesamiento. Se recomienda una precisión alta, de milisegundos, para ordenar correctamente los pasos automatizados que ocurren con rapidez. Por qué es importante Esencial para ordenar los eventos y calcular la duración del rendimiento. Dónde obtenerlo Consulte las columnas 'Fecha de creación' o 'Fecha de actualización' del historial de transacciones o de las tablas de auditoría. Ejemplos 2023-10-25T08:30:15.000Z2023-10-25T08:30:22.500Z2023-10-26T14:10:00.000Z | |||
| Nombre de la actividad ActivityName | Paso específico o cambio de estado que se produjo durante el ciclo de vida del pago. | ||
| Descripción Este atributo define el nodo del evento en el mapa del proceso, como 'Solicitud de pago creada' o 'Fondos transferidos'. En los sistemas ACI, suele derivarse de códigos de estado, tipos de operación del registro de auditoría o cambios de estado del flujo de trabajo. Para obtener una visualización útil, es fundamental asignar nombres claros de actividades de negocio a estos estados técnicos. Por qué es importante Define el flujo del proceso y es necesario para visualizar la secuencia de operaciones. Dónde obtenerlo Se deriva de los códigos de estado (por ejemplo, 100=Creado, 200=Validado) o de las columnas de acción del registro de auditoría. Ejemplos Solicitud de pago creadaPago autorizadoPago liquidadoPago fallido | |||
| Canal de procesamiento ProcessingChannel | Canal por el que se inició el pago. | ||
| Descripción Indica el punto de entrada del pago, como la aplicación móvil, el portal web, una API o la carga de archivos. En el 'Análisis de variantes del proceso de pago', permite comprobar si algunos canales presentan más errores o retrasos que otros. Por qué es importante Permite segmentar el rendimiento según el método de entrada. Dónde obtenerlo Encabezado de la transacción, normalmente en columnas llamadas CHANNEL, SOURCE_TYPE o INPUT_METHOD. Ejemplos SWIFTBanca por InternetAplicación móvilCarga de archivos | |||
| Código de error ErrorCode | Código que se genera cuando un pago falla o requiere reparación. | ||
| Descripción Registra el motivo específico de un evento 'Pago fallido' o 'Error de pago identificado'. Agrupar por este atributo en el Dashboard 'Análisis de fallos y retrabajo en pagos' permite identificar las causas raíz más frecuentes de los fallos (por ejemplo, 'Fondos insuficientes' o 'Cuenta no válida'). Por qué es importante Esencial para el análisis de causas raíz de los fallos del proceso. Dónde obtenerlo Registros de errores o columnas con el motivo del estado, normalmente REASON_CODE o RETURN_CODE. Ejemplos R01AM04BE05TECH_ERR_001 | |||
| Departamento Department | Departamento interno responsable de la actividad actual. | ||
| Descripción Asocia Por qué es importante Agrega el rendimiento por función empresarial. Dónde obtenerlo Se deriva de las tablas de usuarios o de la correspondencia con la jerarquía organizativa. Ejemplos OperacionesComplianceTesoreríaSoporte de TI | |||
| Es retrabajo IsRework | Indicador que señala si el pago pasó por actividades repetidas. | ||
| Descripción Indicador booleano calculado durante el procesamiento de datos. Se establece en true si actividades como 'Datos del pago validados' se realizan más de una vez o si se detecta un ciclo de error. Se utiliza para calcular el KPI 'Tasa de retrabajo en pagos'. Por qué es importante Permite identificar rápidamente los casos ineficientes sin consultas complejas del proceso. Dónde obtenerlo Se calcula en el flujo de datos comprobando si hay actividades duplicadas en cada caso. Ejemplos truefalse | |||
| Fecha de vencimiento del pago PaymentDueDate | Fecha límite para liquidar el pago y considerarlo puntual. | ||
| Descripción Almacena la fecha de ejecución contractual o solicitada. Se compara con la fecha real de liquidación para calcular el KPI 'Tasa de pagos puntuales' y alimentar el Dashboard 'Cumplimiento de la fecha de vencimiento del pago'. Por qué es importante Referencia para medir el cumplimiento del SLA y la puntualidad. Dónde obtenerlo Instrucciones de la transacción, normalmente en VALUE_DATE, EXECUTION_DATE o DUE_DATE. Ejemplos 2023-11-012023-11-05 | |||
| Importe del pago PaymentAmount | Valor monetario de la transacción de pago. | ||
| Descripción Indica el valor financiero transferido. Es un dato contextual fundamental para analizar el 'Volumen de pagos procesados' y priorizar los cuellos de botella. Los pagos de importes elevados suelen seguir rutas de aprobación más rigurosas (análisis de variantes) que los flujos automatizados de importes bajos. Por qué es importante Permite segmentar por importe y calcular el volumen total procesado. Dónde obtenerlo Tablas de detalle de transacciones, normalmente con campos como AMT, TRANS_AMOUNT o PRINCIPAL_AMOUNT. Ejemplos 1500.00250000.5050.001000000.00 | |||
| Moneda del pago PaymentCurrency | Código ISO de la moneda del importe del pago. | ||
| Descripción Especifica la moneda en la que está expresado Por qué es importante Es necesario para interpretar correctamente el importe del pago. Dónde obtenerlo Tablas de detalle de transacciones, normalmente con campos como CCY, CURRENCY_CODE o ISO_CODE. Ejemplos USDEURGBPJPY | |||
| Tipo de pago PaymentType | Clasificación del instrumento de pago. | ||
| Descripción Clasifica el pago (por ejemplo, transferencia bancaria, ACH, SEPA o RTGS). Los distintos tipos de pago suelen tener SLA y flujos de proceso muy diferentes. Este atributo es una dimensión principal para filtrar el Dashboard 'Análisis del tiempo de ciclo integral del pago'. Por qué es importante Es fundamental para distinguir entre flujos de pago rápidos y por lotes. Dónde obtenerlo Encabezado de la transacción, con campos como PMT_TYPE, INSTRUMENT_TYPE o SERVICE_ID. Ejemplos Transferencia nacionalTransferencia internacionalAbono ACHPago instantáneo | |||
| Usuario del evento EventUser | ID del usuario o agente del sistema responsable de la actividad. | ||
| Descripción Registra quién realizó la acción, ya sea una persona (por ejemplo, al aprobar) o una cuenta del sistema (por ejemplo, para una liquidación automatizada). Este atributo es fundamental para el 'Análisis de Bottleneck', ya que permite identificar si determinados usuarios o colas tienen una carga excesiva. Por qué es importante Permite analizar los recursos y auditar la segregación de funciones. Dónde obtenerlo Registros de auditoría o columnas 'UpdatedBy' en las tablas de transacciones. Ejemplos SYSTEM_AGENT_01j.doeapprover_group_aBATCH_PROCESS | |||
| El pago está atrasado IsPaymentLate | Indicador que señala si el pago se liquidó después de la fecha de vencimiento. | ||
| Descripción Indicador booleano que compara la fecha real de liquidación con Por qué es importante Simplifica los informes de cumplimiento. Dónde obtenerlo Cálculo: SettlementDate > PaymentDueDate. Ejemplos truefalse | |||
| ID de conciliación ReconciliationId | Identificador que vincula el pago con el libro mayor o el registro de conciliación. | ||
| Descripción Este ID se completa cuando se produce la actividad 'Pago conciliado'. Confirma que el pago registrado en el motor de procesamiento coincide con el asiento del sistema contable. Si un pago liquidado no tiene este ID, puede indicar un fallo de conciliación. Por qué es importante Es fundamental para el Dashboard 'Eficiencia de la conciliación de pagos'. Dónde obtenerlo Tablas de conciliación o campos específicos como RECON_REF o GL_REF. Ejemplos REC-9921GL-Entry-2023-11 | |||
| Nombre del beneficiario BeneficiaryName | Nombre de la entidad que recibe el pago. | ||
| Descripción Identifica a la contraparte de la transacción. Analizar este campo puede ayudar a detectar proveedores o clientes específicos asociados con tasas elevadas de retrabajo o retrasos, y contribuir al 'Análisis de fallos y retrabajo en pagos'. Por qué es importante Identifica al destinatario del pago y resulta útil para el análisis centrado en el cliente. Dónde obtenerlo Líneas de detalle del pago, con campos como CREDITOR_NAME, BENE_NAME o PAYEE. Ejemplos Acme CorpGlobal Supplies LtdJohn Smith | |||
| Región de origen OriginatingRegion | Región geográfica donde se originó la solicitud de pago. | ||
| Descripción Indica la ubicación física o lógica de quien solicitó el pago. En el 'Análisis de variantes del proceso de pago', permite comprobar si algunas regiones siguen rutas no estándar o registran más rechazos. Por qué es importante Aporta contexto geográfico al rendimiento del proceso. Dónde obtenerlo Encabezado de la transacción, normalmente derivado del código de sucursal o del código de país. Ejemplos América del NorteEMEAAPAC | |||
| Sistema de origen SourceSystem | Nombre del sistema del que proceden los datos del evento. | ||
| Descripción Identifica la aplicación o el módulo específico del ecosistema de ACI Worldwide (por ejemplo, ACI MTS, ACI UPF) o los sistemas externos que intervienen en el flujo. Es especialmente importante al combinar datos de varios libros contables o cuando el pago pasa por cámaras de compensación externas. Por qué es importante Indica de dónde se extrajeron los datos, lo que resulta útil para depurar su linaje. Dónde obtenerlo Se establece durante la extracción o se deriva de una columna SystemID si hay varias instancias. Ejemplos ACI MTSACI UPPSAP GLSwift Gateway | |||
| Tiempo del ciclo de aprobación ApprovalCycleTime | Tiempo transcurrido en la fase de aprobación. | ||
| Descripción Calcula el tiempo entre 'Pago enviado para aprobación' y 'Pago aprobado' (o rechazado). Esta métrica alimenta el Dashboard 'Análisis del tiempo del ciclo de aprobación de pagos' y pone de relieve los retrasos en las decisiones que dependen de personas. Por qué es importante Aísla la parte del proceso que depende de las personas. Dónde obtenerlo Cálculo: Marca de tiempo(Pago aprobado) - Marca de tiempo(Pago enviado para aprobación). Ejemplos 4 horas15 minutos | |||
| Última actualización de los datos LastDataUpdate | Marca de tiempo de la última extracción o actualización del registro en el modelo de datos. | ||
| Descripción Permite conocer la actualidad de los datos utilizados en el análisis. No representa la hora de un evento del proceso, sino el momento técnico en que se incorporaron los datos. Así, quienes analizan el proceso pueden saber si consultan datos en tiempo real o una instantánea histórica. Por qué es importante Permite comprobar que los datos estén actualizados y ayuda a detectar datos obsoletos en los Dashboards. Dónde obtenerlo Hora del sistema en el momento de ejecutar el script ETL. Ejemplos 2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z | |||
Actividades del procesamiento de pagos
| Actividad | Descripción | ||
|---|---|---|---|
| Error de pago identificado | Indica que el sistema ha detectado un problema con el pago en alguna etapa, como datos no válidos o una alerta de cumplimiento. Este evento suele registrarse explícitamente junto con un código de error. | ||
| Por qué es importante Esta actividad es el punto de partida para analizar el retrabajo y la gestión de excepciones. Es esencial para los Dashboards 'Análisis de fallos y retrabajo en pagos' y 'Tiempo de resolución de errores'. Dónde obtenerlo Busque registros explícitos en una tabla de registro de errores o un cambio de estado a 'Error' o 'Requiere corrección' en la tabla de transacciones. Estos eventos deben vincularse al ID de transacción de pago. Capturar Se registra un evento explícito cuando el motor de validación o procesamiento del sistema detecta un error. Tipo de evento explicit | |||
| Fondos transferidos | Indica que la red de pagos confirmó que los fondos se debitaron correctamente de la cuenta del pagador. Por lo general, se registra a partir de un mensaje de estado entrante de la red. | ||
| Por qué es importante Confirma que la red externa ejecutó correctamente el pago. Marca el inicio del período de liquidación y es un dato clave para el KPI «Tiempo medio de liquidación de pagos». Dónde obtenerlo Es un evento explícito que se activa cuando llega un mensaje de actualización de estado, por ejemplo, un MT103 de SWIFT o una confirmación de ACH, que actualiza el registro del pago. Capturar Se registra al recibir un mensaje de confirmación externa de la red de compensación. Tipo de evento explicit | |||
| Pago aprobado | Es un hito clave en el que una persona autorizada aprueba el pago y permite que pase a la fase de ejecución. Por lo general, se registra como un evento explícito cuando quien aprueba realiza la acción en la interfaz del sistema. | ||
| Por qué es importante Esta actividad es un punto de control importante y suele convertirse en un cuello de botella considerable. Analizar los tiempos de espera previos y la duración del ciclo de aprobación ayuda a identificar oportunidades para agilizar los pagos. Dónde obtenerlo Busque un evento explícito en una tabla del registro de aprobaciones o un cambio de estado a «Aprobado» en la tabla principal de transacciones, asociado a la acción y la marca de tiempo de una persona específica. Capturar Se registra cuando una persona autorizada completa la acción de aprobación en el sistema. Tipo de evento explicit | |||
| Pago autorizado | Representa la autorización del pago por parte del sistema después de la aprobación humana. En esta etapa se verifican los fondos o se comprueba el cumplimiento de las reglas antifraude. Puede registrarse como una entrada explícita o inferirse a partir de un cambio de estado que indique que el pago está listo para ejecutarse. | ||
| Por qué es importante Es un punto de control crítico antes de dar la instrucción de transferir los fondos. Las demoras en esta etapa pueden indicar problemas de rendimiento del sistema o dificultades en los subsistemas de cumplimiento y detección de fraude. Dónde obtenerlo Busque un registro explícito en el registro de procesamiento del sistema o en el registro de seguridad. También puede inferirse a partir de un cambio de estado de «Aprobado» a «Autorizado para el pago». Capturar El motor de pagos del sistema lo registra después de completar las comprobaciones internas finales. Tipo de evento explicit | |||
| Pago liquidado | Es la confirmación final de que el proceso de pago ha concluido y los fondos se han abonado al beneficiario. Este evento clave marca la finalización satisfactoria del ciclo de vida del pago. | ||
| Por qué es importante Es el evento de fin que indica que el proceso se completó correctamente. Se utiliza para calcular el tiempo de ciclo general y el rendimiento, y es esencial para casi todos los Dashboards de rendimiento integral. Dónde obtenerlo Por lo general, es un evento explícito que se registra cuando se recibe un mensaje de confirmación de liquidación final de la red o cuando se actualiza el libro mayor interno para reflejar que la transacción ha concluido. Capturar Se registra al recibir un archivo o mensaje de liquidación final y actualiza el estado a 'Liquidado'. Tipo de evento explicit | |||
| Solicitud de pago creada | Esta actividad marca el inicio de una nueva transacción de pago en el sistema ACI Worldwide. Suele registrarse como un evento explícito cuando una persona o un sistema anterior envía una solicitud de pago y crea un nuevo registro de transacción con un ID único. | ||
| Por qué es importante Este es el evento de inicio principal del proceso de pago. Analizar el tiempo transcurrido desde esta actividad hasta la finalización permite calcular el tiempo de ciclo integral, una medida esencial para evaluar la eficiencia general del proceso. Dónde obtenerlo Es probable que se trate de un evento explícito registrado en la tabla principal de transacciones o en un Registro de eventos específico de ACI. Busque una marca de tiempo de creación asociada al ID de transacción de pago. Capturar Se identifica mediante el registro de creación o un evento explícito «Crear» en el registro de transacciones. Tipo de evento explicit | |||
| Detalles del pago validados | Representa la finalización de las comprobaciones automáticas o manuales que verifican que los datos del pago, como la información del beneficiario y los códigos bancarios, sean correctos. Esta actividad suele inferirse a partir de un cambio en el estado de la transacción, de «Nuevo» a «Validado» o «Pendiente de aprobación». | ||
| Por qué es importante Permite hacer seguimiento de la eficiencia de los pasos iniciales de validación de datos. Las demoras en esta etapa pueden generar cuellos de botella en fases anteriores y aumentar la probabilidad de errores de pago más adelante. Dónde obtenerlo Se infiere a partir de los campos de cambio de estado de la tabla principal de transacciones de pago. Compare las marcas de tiempo del estado «Creado» con las de un estado posterior, como «Validado». Capturar Se infiere a partir de un cambio en el campo de estado del pago, por ejemplo, de «Ingresado» a «Validado». Tipo de evento inferred | |||
| Error de pago resuelto | Marca el momento en que un usuario corrige un error identificado previamente y se vuelve a enviar el pago para su procesamiento. A menudo se infiere cuando el estado del pago cambia de un estado de error a uno normal de procesamiento. | ||
| Por qué es importante Esta actividad cierra el ciclo de gestión de excepciones. El tiempo transcurrido entre 'Error de pago identificado' y este evento corresponde al tiempo de resolución del error, una medida clave de la eficiencia operativa. Dónde obtenerlo Se infiere a partir de un cambio de estado desde 'Error' a un estado de procesamiento, como 'Pendiente de aprobación' o 'Validado'. También puede registrarse como una acción explícita del usuario. Capturar Se infiere a partir de un cambio desde un estado de error a otro estado, lo que indica que se ha realizado una corrección. Tipo de evento inferred | |||
| Instrucción de pago enviada | Marca el momento en que se prepara la instrucción de pago y se transmite a una red de pagos externa, como SWIFT, ACH o SEPA. Los sistemas de ACI registran explícitamente esta transferencia para fines de auditoría y seguimiento. | ||
| Por qué es importante Para muchos tipos de pago, este es el «punto de no retorno». Hacer un seguimiento de este momento permite medir el tiempo de procesamiento interno antes de que intervengan factores externos. Dónde obtenerlo Casi siempre se trata de un evento explícito registrado en los registros de transacciones o de mensajería de ACI, que suele incluir un número de referencia específico de la red. Capturar Se crea una entrada explícita en el registro cuando se envía el mensaje de pago a la red externa. Tipo de evento explicit | |||
| Pago conciliado | Representa el paso contable final, en el que la transacción de pago registrada en ACI se coteja con los extractos bancarios o los asientos contables. Puede ser un evento explícito de un módulo de conciliación o inferirse a partir de un cambio de estado. | ||
| Por qué es importante Esta actividad mide la eficiencia del proceso de conciliación administrativa. Los retrasos en esta etapa pueden afectar la precisión de los informes financieros y ocultar problemas con pagos aún no liquidados. Dónde obtenerlo Esta información puede proceder de un módulo de conciliación específico de ACI o de un sistema ERP externo. Se registraría mediante una actualización del estado del pago a 'Conciliado'. Capturar Se infiere a partir de una actualización final del estado a 'Conciliado' o de datos de conciliación vinculados mediante el ID de pago. Tipo de evento inferred | |||
| Pago confirmado | Representa la confirmación interna de que el pago se procesó correctamente y se recibió una confirmación. A menudo, este evento activa el envío de una notificación al beneficiario o a otros sistemas internos. | ||
| Por qué es importante Este hito es fundamental para medir el cumplimiento de las fechas de vencimiento y la tasa de pagos puntuales. Proporciona una marca de tiempo clara del momento en que la organización considera que el pago se ejecutó correctamente. Dónde obtenerlo Por lo general, se infiere a partir de un cambio de estado en la tabla de transacciones de pago a «Confirmado» o «Completado», una vez recibida la confirmación de la red externa. Capturar Se infiere a partir de un cambio de estado a «Confirmado» o «Procesado». Tipo de evento inferred | |||
| Pago enviado para aprobación | Indica que el pago superó la validación inicial y se envió para obtener la aprobación financiera o gerencial necesaria. Por lo general, se registra mediante un cambio de estado en el flujo de trabajo de pagos. | ||
| Por qué es importante Este evento marca el inicio del subproceso de aprobación. Medir el tiempo desde este punto hasta «Pago aprobado» es fundamental para el Dashboard «Análisis del tiempo de ciclo de aprobación de pagos». Dónde obtenerlo Se obtiene a partir de un cambio en el campo de estado del pago en los datos de la transacción, por ejemplo, cuando pasa a «Pendiente de aprobación». Capturar Se infiere a partir de un cambio de estado a «Pendiente de aprobación» o similar, junto con la marca de tiempo correspondiente. Tipo de evento inferred | |||
| Pago fallido | Estado terminal que indica que el pago no pudo completarse debido a un problema irrecuperable. Se distingue de un error que puede resolverse y representa un estado final de fallo definitivo. | ||
| Por qué es importante Registrar este evento de fin es fundamental para calcular la tasa general de pagos fallidos. Analizar los motivos del fallo puede ayudar a mejorar la calidad de los datos y las reglas del proceso. Dónde obtenerlo Se infiere a partir de un estado final, como 'Fallido', 'Cancelado' o 'Rechazado por el banco', en los datos de la transacción, que no vuelve a cambiar. Capturar Se infiere a partir de un estado terminal de fallo en el registro del pago. Tipo de evento inferred | |||
| Pago rechazado | Se produce cuando quien aprueba rechaza la solicitud de pago, lo que suele requerir corregirla y volver a enviarla. Este evento explícito detiene el avance del pago e inicia un ciclo de retrabajo. | ||
| Por qué es importante Permite identificar el retrabajo y las ineficiencias del proceso. Hacer seguimiento de la frecuencia de los rechazos ayuda a diagnosticar problemas de calidad inicial de los datos o de las políticas de envío, y facilita el análisis del retrabajo. Dónde obtenerlo Se registra como un evento explícito en el registro de aprobaciones o como un cambio de estado a «Rechazado» en la tabla de transacciones. El evento puede incluir un código con el motivo del rechazo. Capturar Se registra cuando quien aprueba completa la acción de rechazo en el sistema. Tipo de evento explicit | |||
Guías de extracción
Pasos
Acceda al entorno de base de datos: Inicie sesión en la instancia de SQL Server que aloja la base de datos ACI Postilion Realtime mediante SQL Server Management Studio (SSMS) o un cliente compatible.
Identifique las tablas principales: Localice las tablas
post_tran(registro de transacciones) ypost_tran_cust(extensión de datos personalizados). Asegúrese de tener permisosSELECTsobre estos objetos.Determine el identificador del caso: Esta extracción utiliza
retrieval_reference_nrcomoPaymentTransactionId. Si su implementación usa otra clave única (comosystem_trace_audit_nrjunto contransmission_date_time), ajuste la selección de la consulta según corresponda.Configure los parámetros de filtro: Abra la consulta que aparece a continuación. Localice las variables
@StartDatey@EndDateal principio del script. Asígneles el período de extracción deseado (por ejemplo, los últimos 30 a 90 días) para optimizar el rendimiento.Revise la lógica de actividades: La consulta asigna los tipos de mensaje ISO 8583 (por ejemplo, 0200, 0210) y los códigos de respuesta a las 14 actividades de Process Mining requeridas. Revise las instrucciones
CASEpara asegurarse de que se ajusten a la configuración específica de su interfaz ACI.Ejecute la consulta: Ejecute el script completo. La consulta utiliza
UNION ALLpara normalizar los distintos estados de las transacciones en un único formato de Registro de eventos.Verifique los datos de salida: Compruebe que los resultados incluyan las columnas necesarias:
PaymentTransactionId,ActivityNameyEventTimestamp. Asegúrese de que ningún campo crítico contenga valoresNULLinesperados.Exporte los datos: Haga clic con el botón derecho en la cuadrícula de resultados de SSMS y guarde los datos como archivo CSV (por ejemplo,
ACI_Payments_EventLog.csv).Prepare los datos para ProcessMind: Abra el CSV y compruebe que
EventTimestamptenga un formato estándar (AAAA-MM-DD HH:MM:SS) y quePaymentAmountcontenga únicamente valores numéricos.Cargue los datos: Importe el CSV verificado en ProcessMind y asigne las columnas a ID del caso, Actividad y Marca de tiempo, respectivamente.
Configuración
- Intervalo de fechas: Las tablas
post_trande ACI crecen muy rápido. Se recomienda limitar la extracción a un período móvil de 3 meses o usar el cambio de particiones, si está disponible. - Códigos de respuesta: La consulta supone que
rsp_code = '00'indica éxito. Si su institución utiliza otros códigos de aprobación o éxito (por ejemplo, '08' o '10'), actualice los filtros. - Tipos de mensaje (ISO 8583): El script se basa en los tipos de mensaje estándar (0100/0200 para solicitudes y 0210 para respuestas). Es posible que deba ajustar los tipos de mensaje personalizados definidos en la configuración
source_node_name. - Rendimiento del sistema: Esta consulta usa sugerencias
NOLOCKpara evitar bloqueos en el procesamiento de transacciones en vivo. No las elimine en un entorno de producción. - Monedas: Los importes se extraen como cifras sin procesar. Si necesita normalizar varias monedas durante el análisis, asegúrese de usar
tran_currency_code.
Consulta de ejemplo sql
DECLARE @StartDate DATETIME = '2023-01-01 00:00:00';
DECLARE @EndDate DATETIME = '2023-01-31 23:59:59';
/* 1. Payment Request Created: Initial transaction request received */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Request Created' AS ActivityName,
t.datetime_req AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Origination' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0100', '0200') -- Authorization/Financial Request
UNION ALL
/* 2. Payment Details Validated: Inferred after request but before routing */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Details Validated' AS ActivityName,
DATEADD(second, 1, t.datetime_req) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Compliance' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0100', '0200')
AND t.rsp_code = '00' -- Implies validation passed
UNION ALL
/* 3. Payment Sent For Approval: Routing to internal authorization */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Sent For Approval' AS ActivityName,
DATEADD(second, 2, t.datetime_req) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Risk Management' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0100', '0200')
AND t.tran_amount_req > 1000 -- Example threshold for approval logic
UNION ALL
/* 4. Payment Approved: Successful response code logic */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Approved' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'Approver' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Risk Management' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type IN ('0110', '0210')
UNION ALL
/* 5. Payment Rejected: Specific rejection codes */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Rejected' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
t.rsp_code AS ErrorCode,
1 AS IsRework,
NULL AS EndToEndCycleTime,
'Risk Management' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code IN ('51', '05', '61') -- Insufficient funds, Do not honor, etc.
UNION ALL
/* 6. Payment Authorized: Successful authorization completion */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Authorized' AS ActivityName,
DATEADD(millisecond, 500, t.datetime_rsp) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0110' -- Authorization Response
UNION ALL
/* 7. Payment Instruction Sent: Handoff to Sink Node */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Instruction Sent' AS ActivityName,
DATEADD(second, 1, t.datetime_req) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
t.sink_node_name AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Network Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.sink_node_name IS NOT NULL
AND t.message_type IN ('0200', '0100')
UNION ALL
/* 8. Funds Transferred: External network confirmation */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Funds Transferred' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
t.sink_node_name AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Treasury' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0210' -- Financial Response
UNION ALL
/* 9. Payment Confirmed: Final acknowledgment */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Confirmed' AS ActivityName,
DATEADD(second, 5, t.datetime_rsp) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Customer Service' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0210'
UNION ALL
/* 10. Payment Settled: Settlement/Reconciliation message */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Settled' AS ActivityName,
ISNULL(t.settle_date, t.datetime_rsp) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'Settlement Engine' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Accounting' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type = '0500' -- Reconciliation
AND t.rsp_code = '00'
UNION ALL
/* 11. Payment Failed: System Errors */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Failed' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
t.rsp_code AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'IT Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code IN ('91', '96', '06') -- Issuer down, System malfunction
UNION ALL
/* 12. Payment Error Identified: General Error */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Error Identified' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
t.rsp_code AS ErrorCode,
1 AS IsRework,
NULL AS EndToEndCycleTime,
'Compliance' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code NOT IN ('00')
AND t.message_type IN ('0210', '0110')
UNION ALL
/* 13. Payment Error Resolved: Reversal or Correction followed by Success */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Error Resolved' AS ActivityName,
t.datetime_req AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
1 AS IsRework,
NULL AS EndToEndCycleTime,
'Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0400', '0420') -- Reversal/Advice
UNION ALL
/* 14. Payment Reconciled: Batch processing flag from Custom Table */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Reconciled' AS ActivityName,
ISNULL(c.recon_date, DATEADD(hour, 24, t.datetime_req)) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'Recon Module' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Finance' AS Department
FROM post_tran t WITH (NOLOCK)
JOIN post_tran_cust c WITH (NOLOCK) ON t.post_tran_cust_id = c.post_tran_cust_id
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0210'
AND c.recon_date IS NOT NULL; ¿Todo listo para empezar?
Use este Template como guía para empezar a extraer los datos de procesamiento de pagos. Descubra información valiosa y mejore la eficiencia de sus flujos de trabajo financieros desde hoy.
Agilice el procesamiento de pagos: comience hoy su prueba gratuita
Elimine las excepciones de pago y alcance un procesamiento directo del 98 %.
No se requiere tarjeta de crédito. Configuración en minutos.