Su Plantilla de Datos de Procesamiento de Pagos
Su Plantilla de Datos de Procesamiento de Pagos
- Atributos recomendados para recopilar
- Actividades clave para el seguimiento
- Guía de extracción para ACI Worldwide
Atributos de Procesamiento de Pagos
| Nombre | Descripción | ||
|---|---|---|---|
| ID de Transacción de Pago PaymentTransactionId | El identificador único para la instrucción de pago específica en el sistema ACI. | ||
| Descripción Este atributo sirve como la clave central para el análisis de Process Mining, vinculando todos los eventos relacionados con una única solicitud de pago. En los sistemas de ACI Worldwide (como MTS o UPP), esto corresponde al número de referencia único asignado a una transacción al entrar. Permite la reconstrucción del recorrido de pago de principio a fin, desde la solicitud inicial hasta la validación, aprobación y liquidación final. Por qué es importante Es el ID de Caso fundamental requerido para agrupar eventos discretos en instancias de proceso. Dónde obtener Consulte las tablas de encabezado de transacciones, a menudo etiquetadas como TRN_REF, REFERENCE_NUM o UUID en el registro principal de transacciones. Ejemplos TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981 | |||
| Nombre de la Actividad ActivityName | El paso específico o cambio de estado que ocurrió en el ciclo de vida del pago. | ||
| Descripción Este atributo define el nodo de evento en el mapa de proceso, como 'Solicitud de Pago Creada' o 'Fondos Transferidos'. En los sistemas ACI, esto a menudo se deriva de códigos de estado, tipos de operación de registro de auditoría o cambios de estado del workflow. Un mapeo preciso de estos estados técnicos a actividades de negocio legibles es crucial para una visualización significativa. Por qué es importante Define el flujo del proceso y es necesario para visualizar la secuencia de operaciones. Dónde obtener Derivado de Códigos de Estado (por ejemplo, 100=Creado, 200=Validado) o columnas de Acción del Registro de Auditoría. Ejemplos Solicitud de Pago CreadaPago autorizadoPago LiquidadoPago Fallido | |||
| Timestamp del Evento EventTimestamp | La fecha y hora específicas en que ocurrió la actividad. | ||
| Descripción Este atributo registra el momento exacto en que ocurrió un evento dentro del entorno ACI. Se utiliza para calcular todas las métricas basadas en el tiempo, incluyendo los tiempos de ciclo, las duraciones de aprobación y las tasas de rendimiento. Se prefiere una alta precisión (milisegundos) para secuenciar con exactitud los pasos automatizados rápidos. Por qué es importante Esencial para ordenar eventos y calcular duraciones de rendimiento. Dónde obtener Consulte las columnas 'Fecha de Creación' o 'Fecha de Actualización' en el historial de transacciones o las tablas de auditoría. Ejemplos 2023-10-25T08:30:15.000Z2023-10-25T08:30:22.500Z2023-10-26T14:10:00.000Z | |||
| ¿Es Retrabajo? IsRework | Indicador que señala si el pago pasó por actividades repetitivas. | ||
| Descripción Un indicador booleano calculado durante el procesamiento de datos. Se establece en verdadero si actividades como 'Detalles de Pago Validados' ocurren más de una vez o si se detecta un bucle de error. Esto impulsa el KPI de 'Tasa de Reprocesamiento de Pagos'. Por qué es importante Identifica rápidamente casos ineficientes sin necesidad de consultas de procesos complejas. Dónde obtener Calculado en el pipeline de datos al verificar actividades duplicadas por caso. Ejemplos truefalse | |||
| 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 Móvil, Portal Web, API o Carga de Archivo. Esto ayuda en el 'Análisis de Variantes del Proceso de Pago' para ver si ciertos canales son más propensos a errores o retrasos que otros. Por qué es importante Segmenta el rendimiento por método de entrada. Dónde obtener Encabezado de la transacción, a menudo en columnas llamadas CHANNEL, SOURCE_TYPE o INPUT_METHOD. Ejemplos SWIFTBanca por InternetApp móvilCarga de Archivo | |||
| Código de Error ErrorCode | El código generado cuando un pago falla o requiere reparación. | ||
| Descripción Captura el motivo específico de un evento de 'Pago Fallido' o 'Error de Pago Identificado'. La agrupación por este atributo en el panel de 'Análisis de Fallos y Reprocesamiento de Pagos' permite a la empresa identificar las causas raíz más comunes de fallos (por ejemplo, 'Fondos Insuficientes', 'Cuenta Inválida'). Por qué es importante Esencial para el Análisis de Causa Raíz de fallos de procesos. Dónde obtener Registros de errores o columnas de motivo de estado, a menudo REASON_CODE o RETURN_CODE. Ejemplos R01AM04BE05TECH_ERR_001 | |||
| Departamento Department | El departamento interno responsable de la actividad actual. | ||
| Descripción Mapea el Por qué es importante Agrega el rendimiento por función de negocio. Dónde obtener Derivado de tablas de Usuarios o mapeo de Jerarquía Organizacional. Ejemplos OperacionesComplianceTesoreríaSoporte de TI | |||
| Fecha de Vencimiento de Pago PaymentDueDate | La fecha en la que el pago debe liquidarse para ser considerado a tiempo. | ||
| 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 'Tasa de Pago a Tiempo' y apoyar el dashboard 'Cumplimiento de la Fecha de Vencimiento de Pago'. Por qué es importante El punto de referencia para medir el cumplimiento del SLA y el rendimiento a tiempo. Dónde obtener Instrucciones de la transacción, usualmente VALUE_DATE, EXECUTION_DATE o DUE_DATE. Ejemplos 2023-11-012023-11-05 | |||
| Moneda de pago PaymentCurrency | El código de divisa ISO para el importe del pago. | ||
| Descripción Especifica la moneda en la que se denomina el Por qué es importante Necesario para interpretar correctamente el Monto del Pago. Dónde obtener Tablas de detalles de la transacción, típicamente campos como CCY, CURRENCY_CODE o ISO_CODE. Ejemplos USDEURGBPJPY | |||
| Monto del Pago PaymentAmount | El valor monetario de la transacción de pago. | ||
| Descripción Indica el valor financiero que se transfiere. Este es un campo de contexto crítico para analizar el 'Rendimiento de Pagos' y priorizar los cuellos de botella. Los pagos de alto valor a menudo pasan por rutas de aprobación más rigurosas (análisis de variantes) en comparación con los flujos automatizados de bajo valor. Por qué es importante Permite la segmentación por valor y el cálculo del volumen total procesado. Dónde obtener Tablas de detalles de la transacción, típicamente campos como AMT, TRANS_AMOUNT o PRINCIPAL_AMOUNT. Ejemplos 1500.00250000.5050.001000000.00 | |||
| Tiempo de Ciclo de Extremo a Extremo EndToEndCycleTime | La duración total desde la creación de la solicitud hasta la liquidación. | ||
| Descripción Calcula la diferencia de tiempo entre 'Solicitud de Pago Creada' y 'Pago Liquidado'. Esto sirve como la métrica principal para el KPI de 'Tiempo Promedio del Ciclo de Transacción de Pago' y el análisis general de eficiencia. Por qué es importante La métrica de nivel superior para la velocidad del proceso. Dónde obtener Calculado: Marca de Tiempo(Pago Liquidado) - Marca de Tiempo(Solicitud de Pago Creada). Ejemplos 2 días 4 horas45 minutos12 segundos | |||
| Tipo de Pago PaymentType | La clasificación del instrumento de pago. | ||
| Descripción Clasifica el pago (por ejemplo, Transferencia, ACH, SEPA, RTGS). Diferentes tipos de pago a menudo tienen SLA y flujos de proceso muy distintos. Este atributo es una dimensión principal para filtrar el panel de 'Tiempo de Ciclo de Pago de Extremo a Extremo'. Por qué es importante Fundamental para distinguir entre flujos de pago de alta velocidad y pagos por lotes. Dónde obtener Encabezado de la transacción, 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 Captura quién realizó la acción, ya sea un usuario humano (por ejemplo, para aprobaciones) o una cuenta del sistema (por ejemplo, para liquidaciones automatizadas). Este atributo es vital para el 'Análisis de Cuellos de Botella' para identificar si usuarios o colas específicas están sobrecargados. Por qué es importante Permite el análisis de recursos y la auditoría de segregación de funciones. Dónde obtener Registros de auditoría o columnas 'UpdatedBy' en tablas de transacciones. Ejemplos SYSTEM_AGENT_01j.doegrupo_aprobador_aBATCH_PROCESS | |||
| ID de Conciliación ReconciliationId | Identificador que vincula el pago al libro mayor o al registro de conciliación. | ||
| Descripción Este ID se completa cuando ocurre la actividad 'Pago Conciliado'. Asegura que el pago en el motor de procesamiento coincide con la entrada en el sistema contable. La ausencia de este ID en los pagos liquidados indica fallos de conciliación. Por qué es importante Fundamental para el panel de 'Eficiencia en la Conciliación de Pagos'. Dónde obtener 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 en la transacción. El análisis de este campo puede ayudar a identificar proveedores o clientes específicos asociados con altas tasas de reprocesamiento o retrasos, apoyando el 'Análisis de Fallos y Reprocesamiento de Pagos'. Por qué es importante Identifica el destinatario del pago, útil para el análisis centrado en el cliente. Dónde obtener Líneas de detalle del pago, campos como CREDITOR_NAME, BENE_NAME o PAYEE. Ejemplos Acme CorpGlobal Supplies LtdJohn Smith | |||
| Pago Atrasado IsPaymentLate | Indicador que señala si el pago fue liquidado después de la fecha de vencimiento. | ||
| Descripción Un indicador booleano que compara la fecha de liquidación real con la Por qué es importante Simplifica los informes de cumplimiento. Dónde obtener Calculado: Fecha de Liquidación > Fecha de Vencimiento de Pago. Ejemplos truefalse | |||
| Región de Origen OriginatingRegion | La región geográfica donde se originó la solicitud de pago. | ||
| Descripción Indica la ubicación física o lógica del solicitante. Esto es útil para el 'Análisis de Variantes del Proceso de Pago' para ver si regiones específicas siguen rutas no estándar o experimentan tasas de rechazo más altas. Por qué es importante Proporciona contexto geográfico al rendimiento del proceso. Dónde obtener Encabezado de la transacción, a menudo derivado del Código de Sucursal o Código de País. Ejemplos América del NorteEMEAAPAC | |||
| Source System SourceSystem | El nombre del sistema donde se originaron los datos del evento. | ||
| Descripción Identifica la aplicación o módulo específico dentro del ecosistema de ACI Worldwide (por ejemplo, ACI MTS, ACI UPF) o sistemas externos involucrados en el flujo. Esto es particularmente importante al unir datos de múltiples libros contables o cuando el pago toca cámaras de compensación externas. Por qué es importante Proporciona contexto sobre dónde se extrajeron los datos, útil para depurar el linaje de datos. Dónde obtener Codificado rígidamente durante la extracción o derivado de una columna SystemID si existen varias instancias. Ejemplos ACI MTSACI UPPSAP GLPasarela SWIFT | |||
| Tiempo del Ciclo de Aprobación ApprovalCycleTime | Duración de la fase de aprobación. | ||
| Descripción Calcula el tiempo entre 'Pago Enviado para Aprobación' y 'Pago Aprobado' (o Rechazado). Esta métrica específica alimenta el panel de 'Análisis del Tiempo del Ciclo de Aprobación de Pagos', destacando los retrasos en los pasos de toma de decisiones humanas. Por qué es importante Aísla la parte del proceso que depende de la intervención humana. Dónde obtener Calculado: Marca de Tiempo(Pago Aprobado) - Marca de Tiempo(Pago Enviado para Aprobación). 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 Rastrea la frescura de los datos utilizados en el análisis. Esto no representa un tiempo de evento de proceso, sino el tiempo técnico de ingesta de datos. Asegura que los analistas sepan si están viendo instantáneas en tiempo real o históricas. Por qué es importante Garantiza la actualidad de los datos y ayuda a identificar datos obsoletos en los paneles de control. Dónde obtener Hora del sistema en el momento de la ejecución del script ETL. Ejemplos 2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z | |||
Actividades de 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 inválidos o una alerta de cumplimiento. Este evento se registra típicamente de forma explícita con un código de error asociado. | ||
| Por qué es importante Esta actividad es el punto de partida para todo el análisis de retrabajos y gestión de excepciones. Es esencial para los dashboards de 'Análisis de Fallos de Pago y Retrabajo' y 'Tiempo de Ciclo de Resolución de Errores'. Dónde obtener Busque entradas explícitas 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 estar vinculados al ID de Transacción de Pago. Capturar 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 se ha recibido la confirmación de la red de pagos de que los fondos han sido debitados con éxito de la cuenta del pagador. Esto generalmente se captura de un mensaje de estado entrante de la red. | ||
| Por qué es importante Confirma la ejecución exitosa del pago por parte de la red externa. Marca el inicio del período de liquidación y es una entrada clave para el KPI de 'Tiempo Promedio de Liquidación de Pagos'. Dónde obtener Este es un evento explícito desencadenado por un mensaje de actualización de estado entrante (por ejemplo, MT103 de SWIFT o una confirmación ACH) que actualiza el registro de pago. Capturar Registrado al recibir un mensaje de confirmación externa de la red de compensación. Tipo de evento explicit | |||
| Pago aprobado | Un hito clave en el que un usuario autorizado aprueba el pago, permitiendo que continúe su ejecución. Esto generalmente se captura como un evento explícito cuando el aprobador realiza una acción en la interfaz de usuario del sistema. | ||
| Por qué es importante Esta actividad es un punto de control importante y a menudo un cuello de botella significativo. Analizar los tiempos de espera antes de este paso y la duración del ciclo de aprobación ayuda a identificar oportunidades para acelerar los pagos. Dónde obtener Busque un evento explícito en una tabla de registro de aprobaciones o un cambio de estado a 'Aprobado' en la tabla principal de transacciones que esté vinculado a una acción de usuario y una marca de tiempo específicas. Capturar Registrado cuando un usuario autorizado completa la acción de aprobación en el sistema. Tipo de evento explicit | |||
| Pago autorizado | Representa la autorización a nivel de sistema del pago después de la aprobación humana, verificando los fondos o comprobando las reglas contra el fraude. Esto puede ser una entrada de registro explícita o inferirse de un cambio de estado que indica la preparación para la ejecución. | ||
| Por qué es importante Este es un punto de control crítico antes de que se instruyan los fondos para moverse. Los retrasos en esta etapa pueden indicar problemas de rendimiento del sistema o problemas con los subsistemas de cumplimiento y verificación de fraude. Dónde obtener Busque un registro explícito en un registro de procesamiento o seguridad del sistema. Alternativamente, se puede inferir de una actualización de estado de 'Aprobado' a 'Autorizado para Pago'. Capturar Registrado por el motor de pagos del sistema después de pasar las verificaciones internas finales. Tipo de evento explicit | |||
| Pago Liquidado | La confirmación final de que el proceso de pago está completo y los fondos han sido acreditados al beneficiario, concluyendo la transacción. Este es un evento crítico, que representa el final exitoso del ciclo de vida del pago. | ||
| Por qué es importante Este es el evento de fin de éxito principal para el proceso. Se utiliza para calcular el tiempo de ciclo general y el rendimiento, y es esencial para casi todos los dashboards de rendimiento de principio a fin. Dónde obtener Típicamente un evento explícito registrado cuando se recibe un mensaje de confirmación de liquidación final de la red o cuando el libro mayor interno se actualiza para reflejar la finalización de la transacción. Capturar Registrado al recibir un archivo o mensaje de liquidación final, actualizando el estado a 'Liquidado'. Tipo de evento explicit | |||
| Solicitud de Pago Creada | Esta actividad marca el inicio de una nueva transacción de pago dentro del sistema ACI Worldwide. Normalmente es un evento explícito registrado cuando un usuario o un sistema ascendente envía una solicitud de pago, creando un nuevo registro de transacción con un ID único. | ||
| Por qué es importante Este es el evento de inicio principal para el proceso de pago. Analizar el tiempo desde esta actividad hasta su finalización proporciona el tiempo de ciclo de principio a fin, que es esencial para medir la eficiencia general del proceso. Dónde obtener Este es probablemente un evento explícito registrado en la tabla de transacciones central o en un registro de eventos dedicado en ACI. Busque una marca de tiempo de creación asociada con el ID de Transacción de Pago. Capturar Identificado por el registro de creación o un evento explícito de 'Crear' en el registro de transacciones. Tipo de evento explicit | |||
| Detalles del Pago Validados | Representa la finalización de verificaciones automáticas o manuales para asegurar que los detalles del pago, como la información del beneficiario y los códigos bancarios, sean correctos. Esta actividad a menudo se infiere de un cambio en el estado de la transacción de 'Nuevo' a 'Validado' o 'Pendiente de Aprobación'. | ||
| Por qué es importante Rastrea la eficiencia de los pasos iniciales de validación de datos. Los retrasos aquí pueden crear cuellos de botella ascendentes y aumentar la probabilidad de errores de pago más adelante en el proceso. Dónde obtener Inferido de los campos de cambio de estado en la tabla principal de transacciones de pago. Compare las marcas de tiempo entre el estado 'Creado' y un estado posterior 'Validado' o similar. Capturar Inferido de un cambio en el campo de estado de pago, por ejemplo, de 'Ingresado' a 'Validado'. Tipo de evento inferred | |||
| Error de Pago Resuelto | Marca el punto en el que un error previamente identificado ha sido corregido por un usuario y el pago se vuelve a enviar para su procesamiento. Esto a menudo se infiere cuando el estado de un pago cambia de un estado de error a un estado de procesamiento normal. | ||
| Por qué es importante Esta actividad cierra el bucle de excepción. El tiempo entre 'Error de Pago Identificado' y este evento es el tiempo de ciclo de resolución de errores, una medida clave de la eficiencia operativa. Dónde obtener Inferido de un cambio de estado de 'Error' a un estado de procesamiento como 'Pendiente de Aprobación' o 'Validado'. También puede ser un registro explícito de acción de usuario. Capturar Inferido de un cambio de estado que sale de 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 punto en que la instrucción de pago se compila y se transmite a una red de pago externa como SWIFT, ACH o SEPA. Los sistemas 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. El seguimiento de esto ayuda a medir el tiempo de procesamiento interno antes de que las dependencias externas tomen el control. Dónde obtener Este es casi siempre un evento explícito registrado en los logs de transacciones o mensajes de ACI, a menudo incluyendo un número de referencia específico de la red. Capturar 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 donde la transacción de pago registrada en ACI se coteja con extractos bancarios o asientos contables. Esto puede ser un evento explícito de un módulo de conciliación o inferirse por un cambio de estado. | ||
| Por qué es importante Esta actividad mide la eficiencia del proceso de conciliación del back-office. Los retrasos aquí pueden afectar la precisión de los informes financieros y ocultar problemas de pagos no liquidados. Dónde obtener Esta información podría provenir de un módulo de conciliación dedicado dentro de ACI o de un sistema ERP externo. Se capturaría mediante una actualización de estado a 'Conciliado' en el registro de pago. Capturar Inferido de una actualización de estado final 'Conciliado', o de datos de conciliación unidos por ID de Pago. Tipo de evento inferred | |||
| Pago Confirmado | Representa el reconocimiento interno de que el pago ha sido procesado con éxito y se ha recibido una confirmación. Esto a menudo actúa como el punto de activación para notificar al beneficiario o a otros sistemas internos. | ||
| Por qué es importante Este hito es crucial para medir el cumplimiento de la fecha de vencimiento y la Tasa de Pago a Tiempo. Proporciona una marca de tiempo clara de cuándo la organización considera el pago ejecutado con éxito. Dónde obtener Esto se infiere típicamente de un cambio de estado en la tabla de transacciones de pago a un estado de 'Confirmado' o 'Completado' después de recibir la confirmación de la red externa. Capturar Inferido de un cambio de estado a 'Confirmado' o 'Procesado'. Tipo de evento inferred | |||
| Pago Enviado para Aprobación | Indica que el pago ha pasado la validación inicial y ha sido enrutado para la aprobación gerencial o financiera necesaria. Esto se captura típicamente mediante un cambio de estado dentro del flujo de trabajo de pago. | ||
| Por qué es importante Esto marca el inicio del subproceso de aprobación. Medir el tiempo desde este punto hasta 'Pago Aprobado' es crítico para el dashboard de 'Análisis del Tiempo de Ciclo de Aprobación de Pagos'. Dónde obtener Derivado de un cambio en el campo de estado de pago en los datos de la transacción, como pasar a 'Pendiente de Aprobación'. Capturar Inferido de un cambio de estado a 'Pendiente de Aprobación' o similar, junto con una marca de tiempo correspondiente. Tipo de evento inferred | |||
| Pago Fallido | Un estado terminal que indica que el pago no pudo completarse debido a un problema irrecuperable. Esto es distinto de un error resoluble y representa un estado final de fallo definitivo. | ||
| Por qué es importante El seguimiento de este evento final es crucial para calcular la tasa general de fallos de pago. Analizar las razones del fallo puede ayudar a mejorar la calidad de los datos y las reglas del proceso. Dónde obtener Inferido de un estado final y terminal como 'Fallido', 'Cancelado' o 'Rechazado por el Banco' en los datos de la transacción, que no cambia posteriormente. Capturar Inferido de un estado de fallo terminal en el registro de pago. Tipo de evento inferred | |||
| Pago Rechazado | Ocurre cuando un aprobador deniega la solicitud de pago, lo que a menudo requiere corrección y reenvío. Este es un evento explícito que detiene el avance del pago e inicia un bucle de reprocesamiento. | ||
| Por qué es importante Identifica reprocesos e ineficiencias del proceso. El seguimiento de la frecuencia de los rechazos ayuda a diagnosticar problemas con la calidad de los datos iniciales o las políticas de envío, apoyando el análisis de reprocesos. Dónde obtener Capturado como un evento explícito en el registro de aprobación o un cambio de estado a 'Rechazado' en la tabla de transacciones. El evento puede incluir un código de motivo para el rechazo. Capturar Registrado cuando un aprobador completa la acción de rechazo en el sistema. Tipo de evento explicit | |||
Guías de Extracción
Pasos
Acceda al entorno de la base de datos: Inicie sesión en la instancia de SQL Server que aloja la base de datos ACI Postilion Realtime utilizando 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 una clave única diferente (comosystem_trace_audit_nrcombinado contransmission_date_time), ajuste la selección de la consulta en consecuencia.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 en la ventana de extracción deseada (por ejemplo, los últimos 30 a 90 días) para optimizar el rendimiento.Revise la lógica de actividad: La consulta mapea 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 sentencias
CASEpara asegurarse de que se alinean con sus configuraciones de interfaz ACI específicas.Ejecute la consulta: Ejecute el script completo. La consulta utiliza
UNION ALLpara normalizar los diferentes estados de las transacciones en un único formato de registro de eventos.Verifique la salida de datos: Verifique los resultados para las columnas requeridas:
PaymentTransactionId,ActivityNameyEventTimestamp. Asegúrese de que ningún campo crítico contenga valoresNULLde forma inesperada.Exporte los datos: Haga clic derecho en la cuadrícula de resultados en SSMS y guarde la salida como un archivo CSV (por ejemplo,
ACI_Payments_EventLog.csv).Formato para ProcessMind: Abra el CSV y verifique que
EventTimestamptenga un formato estándar (YYYY-MM-DD HH:MM:SS) y quePaymentAmountcontenga solo valores numéricos.Cargue: Importe el CSV verificado en ProcessMind, mapeando las columnas a Case ID, Activity y Timestamp respectivamente.
Configuración
- Rango de fechas: Las tablas
post_trande ACI crecen muy rápidamente. Se recomienda encarecidamente limitar la extracción a una ventana móvil de 3 meses o usar el cambio de partición si está disponible. - Códigos de respuesta: La consulta asume que
rsp_code = '00'indica éxito. Si su institución utiliza códigos diferentes para aprobación/éxito (por ejemplo, '08' o '10'), actualice los filtros. - Tipos de mensaje (ISO 8583): El script se basa en tipos de mensaje estándar (0100/0200 para Solicitudes, 0210 para Respuestas). Los tipos de mensaje personalizados definidos en su configuración
source_node_namepueden requerir ajustes. - Rendimiento del sistema: Esta consulta utiliza sugerencias
NOLOCKpara evitar bloquear el procesamiento de transacciones en vivo. No elimine estas sugerencias en un entorno de producción. - Monedas: Los importes se extraen como cifras brutas. Asegúrese de que se utilice
tran_currency_codesi se requiere la normalización multimoneda 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;