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 actúa como clave central para el análisis de Process Mining y vincula todos los eventos relacionados con una única solicitud de pago. En los sistemas de ACI Worldwide, como MTS o UPP, corresponde al número de referencia único asignado a una transacción al registrarla. 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 Case ID fundamental necesario para agrupar eventos independientes en instancias de proceso. Dónde obtenerlo Consulte las tablas de cabecera de transacciones, que suelen incluir los campos 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 | La fecha y hora exactas en las que se produjo la actividad. | ||
| Descripción Este atributo registra el momento exacto en que tuvo lugar un evento dentro del entorno ACI. Se utiliza para calcular todas las métricas basadas en el tiempo, incluidos los tiempos de ciclo, las duraciones de aprobación y las tasas de rendimiento. Se recomienda una alta precisión, en milisegundos, para ordenar correctamente los pasos automatizados que se ejecutan con rapidez. Por qué es importante Esencial para ordenar los eventos y calcular las duraciones de rendimiento. Dónde obtenerlo Consulte las columnas «Created Date» o «Update Date» 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 | El paso específico o el cambio de estado que se produjo durante el ciclo de vida del pago. | ||
| Descripción Este atributo define el nodo de evento en el mapa de procesos, como «Payment Request Created» o «Funds Transferred». 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 Workflow. Asignar correctamente estos estados técnicos a actividades empresariales comprensibles es esencial para lograr una visualización útil. 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=Created y 200=Validated, o de las columnas de acción del registro de auditoría. Ejemplos Solicitud de pago creadaPago autorizadoPago liquidadoPago fallido | |||
| Canal de procesamiento ProcessingChannel | El canal a través del cual se inició el pago. | ||
| Descripción Indica el punto de entrada del pago, como Mobile, Web Portal, API o File Upload. Ayuda en el análisis de variantes del proceso de pagos para comprobar si determinados canales son más propensos a errores o retrasos que otros. Por qué es importante Segmenta el rendimiento según el método de entrada. Dónde obtenerlo Cabecera de la transacción, normalmente en columnas denominadas CHANNEL, SOURCE_TYPE o INPUT_METHOD. Ejemplos SWIFTBanca por InternetAplicación móvilCarga de archivo | |||
| Código de error ErrorCode | El código que se genera cuando un pago falla o requiere reparación. | ||
| Descripción Registra el motivo específico de un evento «Payment Failed» o «Payment Error Identified». Agrupar por este atributo en el panel de análisis de fallos y retrabajos de pagos permite identificar las causas raíz más frecuentes de los fallos, como «Insufficient Funds» o «Invalid Account». 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 de motivo del estado, normalmente REASON_CODE o RETURN_CODE. Ejemplos R01AM04BE05TECH_ERR_001 | |||
| Departamento Department | El 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 asignación de la jerarquía organizativa. Ejemplos OperacionesComplianceTesoreríaSoporte de TI | |||
| Es retrabajo IsRework | Indicador que señala si el pago pasó por actividades repetitivas. | ||
| Descripción Indicador booleano calculado durante el procesamiento de datos. Se establece en true si actividades como «Payment Details Validated» se producen más de una vez o si se detecta un ciclo de error. Este indicador alimenta el KPI de tasa de retrabajo de pagos. Por qué es importante Identifica rápidamente los casos ineficientes sin necesidad de consultas de proceso complejas. Dónde obtenerlo Se calcula en la canalización de datos comprobando si hay actividades duplicadas por caso. Ejemplos truefalse | |||
| Fecha de vencimiento del pago PaymentDueDate | La fecha límite en la que debe liquidarse el pago para considerarse puntual. | ||
| Descripción Almacena la fecha de ejecución contractual o solicitada. Esta fecha se compara con la fecha real de liquidación para calcular el KPI de tasa de pagos puntuales y respaldar el panel de cumplimiento de la fecha de vencimiento del pago. Por qué es importante El punto de referencia para medir el cumplimiento del SLA y el rendimiento puntual. Dónde obtenerlo Instrucciones de la transacción, normalmente VALUE_DATE, EXECUTION_DATE o DUE_DATE. Ejemplos 2023-11-012023-11-05 | |||
| Importe del pago PaymentAmount | El valor monetario de la transacción de pago. | ||
| Descripción Indica el valor financiero transferido. Es un campo de contexto fundamental para analizar el rendimiento de los pagos y priorizar los cuellos de botella. Los pagos de importe elevado suelen seguir rutas de aprobación más rigurosas, mediante el análisis de variantes, que los flujos automatizados de importe reducido. Por qué es importante Permite segmentar por valor 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 | El código de moneda ISO correspondiente al importe del pago. | ||
| Descripción Especifica la divisa en la que está denominado 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 | La clasificación del instrumento de pago. | ||
| Descripción Clasifica el pago, por ejemplo, Wire, 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 panel del tiempo de ciclo de pago de extremo a extremo. Por qué es importante Esencial para distinguir entre flujos de pago de alta velocidad y flujos por lotes. Dónde obtenerlo Cabecera de la transacción, con campos como PMT_TYPE, INSTRUMENT_TYPE o SERVICE_ID. Ejemplos Transferencia nacionalTransferencia internacionalCrédito ACHPago instantáneo | |||
| Usuario del evento EventUser | El ID de usuario o agente del sistema responsable de la actividad. | ||
| Descripción Registra quién realizó la acción, ya fuera una persona usuaria, por ejemplo, para las aprobaciones, o una cuenta del sistema, por ejemplo, para la liquidación automatizada. Este atributo es esencial para el análisis de cuellos de botella, ya que permite identificar si determinadas personas usuarias o colas están sobrecargadas. 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á retrasado 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 Calculado: SettlementDate > PaymentDueDate. Ejemplos truefalse | |||
| ID de conciliación ReconciliationId | Identificador que vincula el pago con el libro mayor o con el registro de conciliación. | ||
| Descripción Este ID se completa cuando se produce la actividad «Payment Reconciled». Garantiza que el pago del motor de procesamiento coincida con el asiento del sistema contable. La ausencia de este ID en pagos liquidados indica fallos de conciliación. Por qué es importante Esencial para el panel de 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 | El nombre de la entidad que recibe el pago. | ||
| Descripción Identifica a la contraparte de la transacción. Analizar este campo puede ayudar a identificar proveedores o clientes concretos asociados con altas tasas de retrabajo o retrasos, y respaldar el análisis de fallos y retrabajos de pagos. Por qué es importante Identifica el destinatario del pago y resulta útil para el análisis centrado en clientes. 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 | La región geográfica en la que se originó la solicitud de pago. | ||
| Descripción Indica la ubicación física o lógica de quien solicita el pago. Resulta útil para el análisis de variantes del proceso de pagos, ya que permite comprobar si determinadas regiones siguen rutas no estándar o presentan tasas de rechazo más elevadas. Por qué es importante Proporciona contexto geográfico sobre el rendimiento del proceso. Dónde obtenerlo Cabecera de la transacción, normalmente derivada del código de sucursal o del código de país. Ejemplos NorteaméricaEMEAAPAC | |||
| Sistema de origen SourceSystem | El 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, como ACI MTS o ACI UPF, o de los sistemas externos que participan en el flujo. Es especialmente importante al combinar datos de varios libros mayores o cuando el pago pasa por cámaras de compensación externas. Por qué es importante Proporciona contexto sobre el origen de los datos extraídos y resulta útil para depurar su trazabilidad. Dónde obtenerlo Se codifica durante la extracción o se deriva de una columna SystemID cuando existen varias instancias. Ejemplos ACI MTSACI UPPSAP GLSwift Gateway | |||
| Tiempo de ciclo de aprobación ApprovalCycleTime | Tiempo empleado en la fase de aprobación. | ||
| Descripción Calcula el tiempo transcurrido entre «Payment Sent For Approval» y «Payment Approved» o «Rejected». Esta métrica específica alimenta el panel de análisis del tiempo de ciclo de aprobación de pagos y pone de relieve los retrasos en las etapas que dependen de decisiones humanas. Por qué es importante Aísla la parte del proceso que depende de las personas. Dónde obtenerlo Calculado: Timestamp(Payment Approved) - Timestamp(Payment Sent For Approval). Ejemplos 4 horas15 minutos | |||
| Última actualización de datos LastDataUpdate | La marca de tiempo de la última extracción o actualización del registro en el modelo de datos. | ||
| Descripción Permite hacer un seguimiento de la actualidad de los datos utilizados en el análisis. No representa la hora de un evento del proceso, sino el momento técnico de la ingesta de datos. Así, los analistas pueden saber si consultan datos en tiempo real o instantáneas históricas. Por qué es importante Garantiza que los datos estén actualizados y ayuda a identificar 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. Normalmente, este evento se registra explícitamente con un código de error asociado. | ||
| Por qué es importante Esta actividad es el punto de partida para todos los análisis de retrabajo y gestión de excepciones. Es esencial para los Dashboards «Payment Failure and Rework Analysis» y «Error Resolution Cycle Time». Dónde obtenerlo Busque entradas explícitas en una tabla de registros de errores o un cambio de estado a «Error» o «Requires Correction» en la tabla de transacciones. Estos eventos deben estar vinculados al Payment Transaction ID. Recopilar Se registra un evento explícito cuando el motor de validación o procesamiento del sistema marca un error. Tipo de evento explicit | |||
| Fondos transferidos | Indica que la red de pagos ha confirmado que los fondos se debitaron correctamente de la cuenta del pagador. Normalmente, se registra a partir de un mensaje de estado entrante de la red. | ||
| Por qué es importante Confirma la ejecución correcta del pago por parte de la red externa. Marca el inicio del periodo de liquidación y es un dato clave para el KPI «Average Payment Settlement Time». Dónde obtenerlo Es un evento explícito activado por un mensaje entrante de actualización de estado, por ejemplo, un MT103 de SWIFT o una confirmación de ACH, que actualiza el registro del pago. Recopilar Se registra al recibir un mensaje de confirmación externo de la red de compensación. Tipo de evento explicit | |||
| Pago aprobado | Es un hito clave en el que un usuario autorizado aprueba el pago, lo que permite continuar con su ejecución. Normalmente, se registra como un evento explícito cuando la persona aprobadora realiza la acción en la interfaz de usuario del sistema. | ||
| Por qué es importante Esta actividad es un punto de control importante y suele constituir un cuello de botella significativo. Analizar los tiempos de espera previos a este paso y la duración del ciclo de aprobación ayuda a identificar oportunidades para acelerar los pagos. Dónde obtenerlo Busque un evento explícito en una tabla de registros de aprobación o un cambio de estado a «Approved» en la tabla principal de transacciones, vinculado a una acción y una marca de tiempo específicas del usuario. Recopilar Se registra cuando un usuario autorizado completa la acción de aprobación en el sistema. Tipo de evento explicit | |||
| Pago autorizado | Representa la autorización del pago a nivel del sistema después de la aprobación humana, incluida la verificación de fondos o la comprobación de las reglas antifraude. Puede ser una entrada explícita del registro 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 ordenar la transferencia de fondos. Los retrasos en esta etapa pueden indicar problemas de rendimiento del sistema o dificultades en los subsistemas de cumplimiento y comprobación de fraude. Dónde obtenerlo Busque un registro explícito en un registro de procesamiento del sistema o de seguridad. También puede inferirse a partir de una actualización de estado de «Approved» a «Authorized for Payment». Recopilar El motor de pagos del sistema lo registra después de superar 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, con lo que termina la transacción. Es un evento crítico que representa el final satisfactorio del ciclo de vida del pago. | ||
| Por qué es importante Este es el evento de fin principal de éxito del proceso. Se utiliza para calcular el tiempo de ciclo general y el rendimiento, y es esencial para casi todos los Dashboards de rendimiento de extremo a extremo. Dónde obtenerlo Normalmente, es un evento explícito que se registra cuando se recibe de la red un mensaje de confirmación de liquidación final o cuando el libro mayor interno se actualiza para reflejar la finalización de la transacción. Recopilar Se registra al recibir un archivo o mensaje de liquidación final, que actualiza el estado a «Settled». 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. Normalmente, corresponde a un evento explícito que se registra cuando un usuario o un sistema ascendente 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 pagos. Analizar el tiempo transcurrido desde esta actividad hasta la finalización proporciona el tiempo de ciclo de extremo a extremo, esencial para medir la eficiencia general del proceso. Dónde obtenerlo Probablemente 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 Payment Transaction ID. Recopilar Se identifica mediante el registro de creación o un evento explícito «Create» en el registro de transacciones. Tipo de evento explicit | |||
| Datos del pago validados | Representa la finalización de las comprobaciones automáticas o manuales que garantizan 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 «New» a «Validated» o «Pending Approval». | ||
| Por qué es importante Permite realizar un seguimiento de la eficiencia de los pasos iniciales de validación de datos. Los retrasos en esta etapa pueden crear cuellos de botella anteriores y aumentar la probabilidad de errores de pago más adelante en el proceso. 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 entre el estado «Created» y un estado posterior «Validated» o similar. Recopilar Se infiere a partir de un cambio en el campo de estado del pago, por ejemplo, de «Entered» a «Validated». Tipo de evento inferred | |||
| Error de pago resuelto | Marca el punto en el que un usuario ha corregido un error identificado previamente y el pago se vuelve a enviar para su procesamiento. Esto suele inferirse cuando el estado de un pago cambia de un estado de error a un estado normal de procesamiento. | ||
| Por qué es importante Esta actividad cierra el ciclo de excepción. El tiempo transcurrido entre «Payment Error Identified» y este evento es el 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 «Pending Approval» o «Validated». También puede corresponder a un registro explícito de una acción del usuario. Recopilar Se infiere a partir de un cambio desde un estado de error, lo que indica que se ha realizado una corrección. Tipo de evento inferred | |||
| Instrucción de pago enviada | Marca el momento en que la instrucción de pago se compila 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 Este es el «punto de no retorno» para muchos tipos de pago. Hacer un seguimiento de este momento ayuda a medir el tiempo de procesamiento interno antes de que intervengan dependencias externas. Dónde obtenerlo Casi siempre se trata de un evento explícito registrado en los registros de transacciones o mensajería de ACI, que suele incluir un número de referencia específico de la red. Recopilar Se crea una entrada de registro explícita cuando el mensaje de pago se envía 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 tratarse de 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 a la precisión de los informes financieros y ocultar problemas de pagos pendientes de liquidación. 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 capturaría mediante una actualización del estado a «Reconciled» en el registro del pago. Recopilar Se infiere a partir de una actualización final del estado a «Reconciled» o de datos de conciliación asociados mediante Payment ID. Tipo de evento inferred | |||
| Pago confirmado | Representa el reconocimiento interno de que el pago se procesó correctamente y se recibió una confirmación. A menudo actúa como punto de activación para notificar 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 Normalmente, se infiere a partir de un cambio de estado en la tabla de transacciones de pago a «Confirmed» o «Completed» después de recibir la confirmación de la red externa. Recopilar Se infiere a partir de un cambio de estado a «Confirmed» o «Processed». Tipo de evento inferred | |||
| Pago enviado para aprobación | Indica que el pago superó la validación inicial y se envió para la aprobación administrativa o financiera necesaria. Normalmente, esto se registra mediante un cambio de estado dentro del flujo de trabajo de pagos. | ||
| Por qué es importante Marca el inicio del subproceso de aprobación. Medir el tiempo desde este punto hasta «Payment Approved» es fundamental para el Dashboard «Payment Approval Cycle Time Analysis». Dónde obtenerlo Se deriva de un cambio en el campo de estado del pago dentro de los datos de la transacción, como el paso al estado «Pending Approval». Recopilar Se infiere a partir de un cambio de estado a «Pending Approval» o similar, junto con la marca de tiempo correspondiente. Tipo de evento inferred | |||
| Pago fallido | Es un estado terminal que indica que el pago no pudo completarse debido a un problema irrecuperable. Se diferencia de un error que puede resolverse y representa un estado final de fallo definitivo. | ||
| Por qué es importante Hacer un seguimiento de este evento final 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 y terminal como «Failed», «Cancelled» o «Rejected by Bank» en los datos de la transacción, que no cambia posteriormente. Recopilar Se infiere a partir de un estado terminal de fallo en el registro del pago. Tipo de evento inferred | |||
| Pago rechazado | Ocurre cuando una persona aprobadora rechaza la solicitud de pago, lo que suele requerir una corrección y un nuevo envío. Es un evento explícito que detiene el avance del pago e inicia un ciclo de retrabajo. | ||
| Por qué es importante Identifica el retrabajo y las ineficiencias del proceso. Hacer un seguimiento de la frecuencia de los rechazos ayuda a diagnosticar problemas de calidad de los datos iniciales 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 mediante un cambio de estado a «Rejected» en la tabla de transacciones. El evento puede incluir un código que indique el motivo del rechazo. Recopilar Se registra cuando la persona aprobadora 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 utiliza otra clave única, comosystem_trace_audit_nrcombinada contransmission_date_time, ajuste la selección de la consulta según corresponda.Configure los parámetros de filtro: Abra la consulta proporcionada a continuación. Localice las variables
@StartDatey@EndDateen la parte superior del script. Establézcalas según el periodo 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, como 0200 y 0210, y los códigos de respuesta a las 14 actividades necesarias de Process Mining. Revise las instrucciones
CASEpara asegurarse de que coincidan con las configuraciones específicas de su interfaz de 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 la salida como archivo CSV, por ejemplo,
ACI_Payments_EventLog.csv.Prepare el formato para ProcessMind: Abra el CSV y compruebe que
EventTimestamputilice un formato estándar (YYYY-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 Case ID, Activity y Timestamp, respectivamente.
Configuración
- Date Range: Las tablas
post_trande ACI crecen muy rápidamente. Se recomienda limitar la extracción a un periodo móvil de 3 meses o utilizar el cambio de particiones, si está disponible. - Response Codes: La consulta supone que
rsp_code = '00'indica éxito. Si su institución utiliza códigos diferentes para aprobación o éxito, como '08' o '10', actualice los filtros. - Message Types (ISO 8583): El script se basa en tipos de mensaje estándar, 0100/0200 para solicitudes y 0210 para respuestas. Los tipos de mensaje personalizados definidos en su configuración de
source_node_namepueden requerir ajustes. - System Performance: Esta consulta utiliza sugerencias
NOLOCKpara evitar bloqueos del procesamiento de transacciones en vivo. No elimine estas sugerencias en un entorno de producción. - Currencies: Los importes se extraen como cifras sin procesar. Asegúrese de utilizar
tran_currency_codesi necesita normalizar varias monedas durante el análisis.
a 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;¿Está listo para comenzar?
Utilice este Template como guía para comenzar a extraer sus datos de procesamiento de pagos. Obtenga información valiosa e impulse hoy mismo la eficiencia de sus flujos de trabajo financieros.
Agilice el procesamiento de pagos: inicie ahora su prueba gratuita
Elimine las excepciones de pago y alcance un procesamiento directo del 98 %.
No necesita tarjeta de crédito; configuración en minutos