> Mejora continua de procesos > Procesamiento de pagos > FIS Global > Template de datos

Su Template de datos para el procesamiento de pagos

FIS Global

Atributos del procesamiento de pagos(19) Actividades del procesamiento de pagos(13) Guías de extracción(1)

Su Template de datos para el procesamiento de pagos

Este Template ofrece una guía completa sobre los atributos de datos y las actividades del proceso necesarios para analizar eficazmente el procesamiento de pagos. También incluye indicaciones prácticas para extraer esta información clave de sus sistemas. Utilice este recurso para asegurarse de recopilar todos los datos necesarios para una iniciativa sólida de Process Mining.

Atributos recomendados para recopilar
Actividades clave que conviene registrar
Guía de extracción

¿Es nuevo en los registros de eventos? Aprenda a crear un Registro de eventos para Process Mining.

Descargar Template

Atributos del procesamiento de pagos

Estos son los campos de datos recomendados para incluir en su Registro de eventos y realizar un análisis completo del procesamiento de pagos.

3 Obligatorio 7 Recomendado 9 Opcional

	Nombre	Descripción
	Fecha y hora del evento EventTimestamp	Fecha y hora específicas en que tuvo lugar la actividad.
Descripción Este atributo aporta el contexto temporal de cada evento del proceso de pago. Registra el momento exacto en que el sistema anotó una acción y permite ordenar cronológicamente las actividades. En el análisis, se utiliza para calcular la duración entre pasos, el tiempo total del ciclo y las tasas de procesamiento. También permite identificar cuellos de botella al destacar las demoras entre etapas específicas del proceso. Por qué es importante Sin este campo, no es posible realizar análisis basados en el tiempo; de él dependen todos los KPI de rendimiento y eficiencia. Dónde obtenerlo Consulte la documentación de FIS Global Ejemplos 2023-10-12T08:30:15Z2023-10-12T09:45:00Z2023-10-13T14:20:10Z
	ID de transacción de pago PaymentTransactionId	Identificador único de la instrucción o transacción de pago específica.
Descripción Este atributo es la clave central que permite vincular todos los eventos de un mismo ciclo de vida del pago. Permite a quienes analizan el proceso seguir el pago desde la solicitud inicial hasta la validación, la aprobación y la liquidación o conciliación final. En el análisis, este ID es esencial para agrupar eventos individuales en instancias del proceso. Permite visualizar el flujo de principio a fin y sirve de base para todas las métricas por caso, como el tiempo del ciclo y los ciclos de retrabajo. Por qué es importante Es el elemento fundamental que conecta los datos en Process Mining y permite reconstruir actividades dispersas como un recorrido coherente. Dónde obtenerlo Consulte la documentación de FIS Global Ejemplos TRX-2023-899102PAY-US-99281ACH-7721-X99WIRE-2210-001
	Nombre de la actividad ActivityName	Nombre del paso específico del proceso o del evento que tuvo lugar.
Descripción Este campo registra la acción específica realizada en un momento determinado, como «Solicitud de pago creada» o «Pago liquidado». Define los nodos del mapa del proceso y determina la estructura del flujo del proceso. Quienes analizan el proceso utilizan este atributo para comprender la secuencia de operaciones. Es fundamental para identificar desviaciones de la ruta ideal, detectar pasos omitidos o encontrar actividades redundantes, como varios ciclos de aprobación. Por qué es importante Define el «qué» del proceso y permite visualizar los mapas de procesos y analizar las variantes. Dónde obtenerlo Consulte la documentación de FIS Global Ejemplos Payment Request CreatedPayment Details ValidatedPayment ApprovedPago liquidado
	Código de moneda CurrencyCode	Código ISO de tres letras que indica la moneda del pago.
Descripción Este atributo especifica la moneda del importe del pago (por ejemplo, USD, EUR, GBP). Es esencial para normalizar los datos financieros al analizar flujos de pagos globales. En el análisis, este campo permite segmentar el rendimiento del proceso por moneda, lo que suele estar relacionado con distintos sistemas de compensación y normativas. Ayuda a explicar las variaciones en los tiempos de liquidación de los pagos transfronterizos frente a los nacionales. Por qué es importante Es fundamental en entornos multidivisa para interpretar correctamente los volúmenes financieros. Dónde obtenerlo Consulte la documentación de FIS Global Ejemplos USDEURGBPJPY
	Fecha de vencimiento del pago PaymentDueDate	Fecha límite en la que se espera que el pago esté liquidado.
Descripción Este atributo registra la fecha límite del pago, según la solicitud de quien lo inicia o las condiciones de la factura. Sirve como referencia para medir el cumplimiento de los plazos. Este campo es fundamental para el Dashboard «Cumplimiento de las fechas de vencimiento de los pagos». Al comparar esta fecha con la fecha real de «Pago liquidado», quienes analizan el proceso pueden señalar los pagos atrasados, calcular posibles penalizaciones y evaluar el cumplimiento de los acuerdos con proveedores. Por qué es importante Proporciona la referencia para medir el cumplimiento de los niveles de servicio y la puntualidad. Dónde obtenerlo Consulte la documentación de FIS Global Ejemplos 2023-11-012023-11-15
	Fecha real de liquidación ActualSettlementDate	Fecha en que el pago se finalizó y liquidó efectivamente.
Descripción Este atributo registra la fecha efectiva en que se transfirieron los fondos o se consideró completada la transacción. Se diferencia de la fecha y hora de procesamiento porque refleja la fecha valor. En el análisis, se utiliza junto con la fecha de vencimiento para calcular el «Porcentaje de pagos puntuales». También activa la fase de conciliación, por lo que es fundamental para analizar el «Tiempo del ciclo de conciliación de pagos». Por qué es importante Representa la conclusión financiera del pago y es clave para analizar el flujo de caja. Dónde obtenerlo Consulte la documentación de FIS Global Ejemplos 2023-11-022023-11-14
	Importe del pago PaymentAmount	Valor monetario de la transacción de pago.
Descripción Este atributo representa el valor financiero asociado a la solicitud de pago. Es la métrica principal para analizar el volumen financiero y el riesgo. Quienes analizan el proceso utilizan este campo para segmentar los procesos según el importe de los pagos, ya sea alto o bajo, pues suelen seguir distintas rutas de aprobación. Sirve de apoyo al Dashboard «Volumen de pagos» y ayuda a identificar si los pagos de importes elevados tienen ciclos más largos debido a controles más estrictos. Por qué es importante Añade la dimensión financiera a Process Mining y permite establecer prioridades según el valor. Dónde obtenerlo Consulte la documentación de FIS Global Ejemplos 1500.00250.501000000.0045.99
	Tipo de pago PaymentType	Clasificación del método o instrumento de pago.
Descripción Este atributo clasifica los pagos por tipo, como transferencia bancaria, ACH, SEPA, pago en tiempo real (RTP) o cheque. Cada tipo de pago sigue reglas de procesamiento y acuerdos de nivel de servicio (SLA) distintos. Quienes analizan el proceso utilizan este campo para comparar el «Tiempo del ciclo de conciliación de pagos» entre distintos sistemas de pago. Ayuda a explicar por qué algunos pagos se liquidan al instante y otros tardan días, y permite medir el rendimiento con el valor de referencia adecuado. Por qué es importante Es la dimensión principal para segmentar los flujos del proceso, ya que cada tipo tiene características propias de enrutamiento y tiempos. Dónde obtenerlo Consulte la documentación de FIS Global Ejemplos Transferencia bancariaCrédito ACHSEPA instantáneoCheque
	Unidad de negocio BusinessUnit	División o departamento interno que origina el pago.
Descripción Este atributo asigna el pago a una unidad específica de la organización, como «Banca minorista», «Préstamos comerciales» o «Tesorería». Se utiliza para agregar KPI como «Volumen de pagos» y «Tiempo promedio del ciclo de pago» por departamento. Esto ayuda a la dirección a comparar el rendimiento entre distintas divisiones y a asignar los recursos de forma eficaz. Por qué es importante Permite comparar el rendimiento de los procesos dentro de la organización y asignar responsabilidades. Dónde obtenerlo Consulte la documentación de FIS Global Ejemplos TesoreríaCuentas por pagarOperaciones de banca minoristaGestión patrimonial
	Usuario que procesa ProcessingUser	Identificador o nombre de la persona o del agente del sistema que realiza la actividad.
Descripción Este atributo registra quién o qué ejecutó el paso del proceso. Permite distinguir entre operadores humanos (por ejemplo, «J.Smith») y cuentas automatizadas del sistema (por ejemplo, «SYSTEM_BATCH»). Estos datos se utilizan para analizar el uso de los recursos, identificar cuellos de botella manuales y auditar la segregación de funciones. También ayudan a calcular la «Tasa de utilización de usuarios de procesamiento» y a distinguir entre tareas manuales y automatizadas. Por qué es importante Esencial para analizar los recursos, las tasas de automatización y las auditorías de cumplimiento. Dónde obtenerlo Consulte la documentación de FIS Global Ejemplos jsmithSYSTEM_AUTOBOTmdoe_approverAPI_GATEWAY
	Autoridad de aprobación ApprovalAuthority	Cargo, grupo o persona responsable de autorizar el pago.
Descripción Este atributo indica qué nivel de autoridad o grupo de usuarios específico debe aprobar el pago, a menudo según un umbral de importe. Ayuda a seguir el enrutamiento del flujo de aprobación. Quienes analizan el proceso utilizan este atributo para el Dashboard «Cuellos de botella en la autorización de pagos». Permite desglosar los tiempos de aprobación por nivel de autoridad y comprobar si determinados niveles directivos causan demoras. Por qué es importante Permite analizar la jerarquía de aprobación de la organización e identificar cuellos de botella. Dónde obtenerlo Consulte la documentación de FIS Global Ejemplos Gerente de nivel 1CFOEquipo de cumplimientoSistema de aprobación automática
	Canal de pago PaymentChannel	Canal por el que se inició la solicitud de pago.
Descripción Este atributo describe el origen de la instrucción de pago, como la banca en línea, una aplicación móvil, una API o una sucursal. Ayuda a comprender cómo se inició la transacción. Quienes analizan el proceso utilizan este atributo para comparar la eficiencia del procesamiento entre distintos canales. Por ejemplo, permite determinar si los pagos iniciados mediante API tienen menos errores que los introducidos manualmente en una sucursal. Por qué es importante Ayuda a optimizar los canales y a comprender el comportamiento de los clientes. Dónde obtenerlo Consulte la documentación de FIS Global Ejemplos Banca en líneaAplicación móvilPasarela corporativaPersonal de ventanilla
	Código de error de validación ValidationErrorCode	Código o motivo que indica por qué no se pudo validar un pago.
Descripción Este atributo se completa cuando un pago entra en la actividad «Error de pago identificado». Contiene detalles específicos del fallo, como «IBAN no válido», «Fondos insuficientes» o «Falta la dirección del beneficiario». Este campo alimenta el Dashboard «Tasas de error en la validación de datos de pago». Agrupar los datos por este atributo revela las causas más comunes de retrabajo y permite aplicar correcciones específicas en la entrada de datos o la configuración de los sistemas. Por qué es importante Permite identificar las causas raíz de las dificultades del proceso y los ciclos de retrabajo. Dónde obtenerlo Consulte la documentación de FIS Global Ejemplos ERR-001: Cuenta no válidaERR-055: Coincidencia con sancionesERR-009: Transacción duplicada
	Cuenta de origen SenderAccount	Número de cuenta de la que se debitan los fondos.
Descripción Este atributo identifica la cuenta de origen de la transacción. Permite analizar con más detalle los pagos procedentes de cuentas internas específicas. En el análisis, ayuda a identificar si determinadas cuentas de financiación suelen presentar errores (por ejemplo, fondos insuficientes) o demoras. También facilita la conciliación al permitir cotejar los asientos del libro mayor con las actividades del proceso. Por qué es importante Es fundamental para la conciliación financiera y la resolución de problemas a nivel de cuenta. Dónde obtenerlo Consulte la documentación de FIS Global Ejemplos 123456789987654321ACC-TREASURY-01
	Es un pago atrasado IsLatePayment	Indicador que señala si el pago se liquidó después de la fecha de vencimiento.
Descripción Este atributo booleano calculado devuelve «verdadero» si la fecha de «Pago liquidado» es posterior a la «Fecha de vencimiento del pago». Este atributo determina directamente el KPI de porcentaje de pagos puntuales. Simplifica la creación de Dashboards, ya que permite filtrar rápidamente los casos problemáticos sin aplicar una lógica de fechas compleja en la capa de visualización. Por qué es importante Simplifica los informes de excepciones y el análisis de cumplimiento. Dónde obtenerlo Se deriva de PaymentDueDate y ActualSettlementDate Ejemplos truefalse
	País del beneficiario BeneficiaryCountry	Código del país del destinatario del pago.
Descripción Este atributo identifica el país de destino de los fondos. Se utiliza para distinguir entre pagos nacionales e internacionales. Este contexto es fundamental para el «Monitoreo del cumplimiento de pagos» y el análisis del enrutamiento. Los pagos internacionales suelen involucrar distintos intermediarios, controles de cumplimiento y ciclos más largos. Por eso, analizar el rendimiento por país ayuda a aislar estas variables. Por qué es importante Es una dimensión clave para el análisis geográfico y la evaluación del riesgo de cumplimiento. Dónde obtenerlo Consulte la documentación de FIS Global Ejemplos USDECNGB
	Requiere intervención manual IsManualIntervention	Indicador que señala si la actividad requirió trabajo manual.
Descripción Este atributo booleano señala las actividades o los casos que requirieron intervención humana, como «Error de pago resuelto» o las aprobaciones manuales, en lugar de un procesamiento totalmente automatizado (STP). Es esencial para el Dashboard «Tasa de intervención manual en pagos». Ayuda a cuantificar el porcentaje de pagos que no están totalmente automatizados y a identificar oportunidades de transformación digital. Por qué es importante Distingue el volumen procesado automáticamente del trabajo manual y orienta los cálculos del retorno de la inversión en automatización. Dónde obtenerlo Se deriva de ActivityName o ProcessingUser Ejemplos truefalse
	Sistema de origen SourceSystem	Nombre del sistema del que proceden los datos del evento.
Descripción Este atributo identifica el componente de software o la base de datos específicos de los que se extrajo el registro, como el sistema bancario central, la pasarela de pagos o la herramienta de verificación de sanciones. Es fundamental para el linaje y la validación de los datos. Al analizar flujos de principio a fin que abarcan varias plataformas, este campo ayuda a distinguir dónde se realizaron determinadas actividades y a investigar problemas de calidad de los datos. Por qué es importante Garantiza la trazabilidad y aporta contexto, especialmente en entornos complejos con varios motores de pago integrados. Dónde obtenerlo Consulte la documentación de FIS Global Ejemplos FIS OPFTraxPaymentHub_01SanctionsScreeningDB
	Última actualización de datos LastDataUpdate	Fecha y hora de la última extracción o actualización del registro.
Descripción Este atributo indica qué tan actualizados están los datos utilizados en el análisis. Ayuda a saber si se están consultando datos en tiempo real o una instantánea de un período anterior. En los Dashboards, este campo suele utilizarse para mostrar la etiqueta «Datos actualizados al». Permite tomar decisiones con la información más pertinente disponible y facilita la gestión de las cargas incrementales de datos. Por qué es importante Indica la vigencia de los datos y genera confianza en que los informes están actualizados. Dónde obtenerlo Metadatos del proceso ETL Ejemplos 2023-10-14T00:00:00Z2023-10-15T06:00:00Z

Obligatorio Recomendado Opcional

Actividades del procesamiento de pagos

Estos son los pasos clave y los hitos del proceso que conviene incluir en su Registro de eventos para descubrir y optimizar el proceso con precisión.

6 Recomendado 7 Opcional

	Actividad	Descripción
	Pago conciliado	Esta es la actividad contable final, en la que la transacción de pago se coteja con un extracto bancario o un asiento del libro mayor interno. Puede realizarse mediante un proceso automatizado por lotes o una acción manual.
Por qué es importante Esta actividad marca el final absoluto del ciclo de vida del pago. Analizar el «Tiempo del ciclo de conciliación de pagos» es fundamental para comprender la eficiencia de los procesos de cierre financiero. Dónde obtenerlo A menudo se infiere cuando se completa el campo «reconciliation_date» o cuando el estado cambia finalmente a «Conciliado» en un módulo financiero o contable vinculado al sistema de pagos. Capturar Se identifica cuando se completa una fecha de conciliación o el estado cambia a «Conciliado». Tipo de evento inferred
	Pago liquidado	Esta actividad marca la finalización de la transferencia de fondos, cuando la transacción se considera liquidada desde el punto de vista financiero. Por lo general, se registra al recibir la confirmación definitiva de liquidación de la red de pagos o la cámara de compensación.
Por qué es importante Este es el punto final principal para medir el tiempo del ciclo de pago y el porcentaje de pagos puntuales. Indica que el proceso central de ejecución del pago se ha completado correctamente. Dónde obtenerlo Se infiere a partir de un cambio final en el estado del pago a «Liquidado», «Completado» o «Contabilizado». Este cambio de estado se produce a partir de archivos de liquidación por lotes o mensajes en tiempo real del sistema de compensación. Capturar Un cambio en el estado de la transacción de pago a «Liquidado» o un estado equivalente. Tipo de evento inferred
	Payment Approved	Hito clave en el que una persona usuaria autorizada aprueba el pago para que avance a la siguiente etapa. Casi siempre queda registrado como un evento explícito, con el ID de la persona aprobadora y una marca de tiempo de la acción realizada en el sistema.
Por qué es importante Este es un punto de control crítico para medir los tiempos del ciclo de aprobación y verificar el cumplimiento de los controles financieros. Las demoras en esta etapa pueden afectar considerablemente el pago puntual. Dónde obtenerlo Se registra en una tabla de aprobaciones o como un evento explícito en el historial principal de transacciones. El registro de eventos vincula el Payment Transaction ID, el ID de usuario de la persona aprobadora y la marca de tiempo de la aprobación. Capturar Se registra cuando una persona usuaria con permisos de aprobación selecciona la acción 'approve' para un pago. Tipo de evento explicit
	Payment Authorized	Indica una etapa final de autorización, que suele ser necesaria para pagos de gran importe o cuando debe intervenir una autoridad distinta después de la aprobación inicial. Esta acción queda registrada como un evento explícito cuando una persona usuaria con credenciales de autorización confirma el pago.
Por qué es importante Esta actividad es clave para el Dashboard «Payment Authorization Bottlenecks». Separarla de «Payment Approved» ayuda a identificar las demoras en los procesos de aprobación con varios niveles. Dónde obtenerlo Se registra en un registro de auditoría o de transacciones. El evento se activa cuando una persona usuaria con permisos de autorización específicos actúa sobre el pago y genera un registro con su ID y una marca de tiempo. Capturar Se crea una entrada explícita en el registro cuando una persona usuaria realiza la acción de autorización final. Tipo de evento explicit
	Payment Instruction Sent	Esta actividad marca el momento en que el sistema FIS envía la instrucción de pago definitiva a la red de pagos correspondiente, como ACH, Fedwire o SWIFT. Se trata de un evento crítico generado por el sistema.
Por qué es importante Este es un hito importante que indica que el pago ha salido del entorno de procesamiento interno. Es fundamental para analizar la eficiencia del enrutamiento y el tiempo que requiere el procesamiento externo. Dónde obtenerlo Se registra en un registro de transacciones o mensajes que hace seguimiento de las comunicaciones con redes de pago externas. Busque un registro que indique el envío correcto de un mensaje saliente y su marca de tiempo. Capturar Evento generado por el sistema cuando el mensaje de pago se envía a la red de compensación. Tipo de evento explicit
	Payment Request Created	Este es el primer evento del ciclo de vida del pago y corresponde al momento en que se inicia una nueva transacción de pago en el sistema FIS. Por lo general, queda registrado explícitamente en una tabla de transacciones cuando una persona usuaria o un sistema automatizado envía una nueva solicitud de pago.
Por qué es importante Esta actividad marca el inicio definitivo del proceso. Es esencial para medir el tiempo del ciclo de pago de principio a fin y analizar el volumen y el rendimiento general de los pagos. Dónde obtenerlo Se registra en una tabla central de transacciones y se identifica mediante la marca de tiempo de creación asociada al Payment Transaction ID. Busque tablas como 'Payment_Transactions' o 'Payment_Requests' y campos como 'creation_date' o 'entry_date'. Capturar Evento registrado al crear una nueva transacción de pago. Tipo de evento explicit
	Error de pago identificado	Indica que se detectó un error en algún momento del proceso, después de la validación inicial, por ejemplo, un rechazo del banco receptor o una alerta interna de cumplimiento. A menudo se registra como un evento explícito cuando se genera una excepción.
Por qué es importante Esta actividad es el punto de entrada de todos los ciclos de retrabajo y gestión de excepciones. Es esencial para calcular los KPI de tasa de intervención manual y tiempo de resolución de errores de pago. Dónde obtenerlo Se registra en un módulo de gestión de excepciones o en el registro de transacciones. Puede activarse automáticamente mediante una regla del sistema o manualmente cuando una persona señala un problema; se crea así un registro con un código de error y una fecha y hora. Capturar Se registra una excepción o un código de error en la transacción de pago. Tipo de evento explicit
	Error de pago resuelto	Marca la resolución de un error de pago identificado previamente y permite volver a procesar o cancelar el pago. Es una acción explícita que realiza una persona para borrar el estado de excepción.
Por qué es importante Esta actividad cierra el ciclo de la excepción. El tiempo transcurrido entre «Error identificado» y este evento es una medida clave de la eficiencia operativa en la gestión de excepciones. Dónde obtenerlo Se registra cuando una persona borra una alerta de error o saca la transacción de una cola de excepciones. La acción queda registrada con fecha y hora en un registro de auditoría o en el historial de transacciones. Capturar Una acción de una persona borra el estado de error y queda registrada en un registro de auditoría. Tipo de evento explicit
	Pago atrasado identificado	Evento derivado que indica que el pago se liquidó después de la fecha de vencimiento especificada. Esta actividad no se registra explícitamente, sino que se calcula comparando dos campos de fecha.
Por qué es importante Esta actividad calculada respalda directamente el KPI de porcentaje de pagos puntuales y el Dashboard «Cumplimiento de las fechas de vencimiento de los pagos». Ayuda a cuantificar el impacto de los retrasos del proceso en las relaciones con los proveedores y en las posibles comisiones por demora. Dónde obtenerlo No se extrae directamente. Se calcula durante la transformación de datos, comparando la fecha y hora de «Fecha de liquidación» con el campo «Fecha de vencimiento del pago». Si la fecha de liquidación es posterior a la fecha de vencimiento, se genera este evento. Capturar Se calcula si «Fecha de liquidación» > «Fecha de vencimiento del pago». Tipo de evento calculated
	Payment Confirmed	Representa la recepción de una confirmación de la red de pagos o del banco beneficiario que indica que el pago ha sido recibido. Este evento se activa cuando llega un mensaje del sistema o una actualización de estado.
Por qué es importante La confirmación garantiza que el pago ha llegado a su destino. El tiempo transcurrido entre «Instrucción enviada» y «Confirmado» mide la latencia de la red externa y el tiempo de procesamiento. Dónde obtenerlo Se genera al analizar los mensajes de confirmación recibidos de las redes de pago. El sistema actualiza el estado del pago y registra la fecha y hora de la confirmación. Capturar Un mensaje entrante de una red de compensación actualiza el estado del pago a «Confirmado». Tipo de evento explicit
	Payment Details Validated	Esta actividad indica que los datos del pago superaron las comprobaciones automáticas iniciales de formato, integridad y exactitud. Suele inferirse a partir de un cambio de estado del registro del pago, por ejemplo, de 'New' a 'Validated' o 'Pending Approval'.
Por qué es importante El seguimiento de esta actividad ayuda a identificar la frecuencia y el origen de los errores de entrada de datos. Es un requisito previo para analizar el KPI de tasa de errores de validación de datos de pago y comprender las causas del retrabajo. Dónde obtenerlo Se infiere a partir de un cambio en el campo de estado de la tabla de transacciones de pago. El evento queda marcado por el cambio del estado inicial a 'validated', junto con la marca de tiempo correspondiente. Capturar Se identifica cuando el campo de estado del pago cambia a 'Validated' o a un valor similar. Tipo de evento inferred
	Payment Rejected	Esta actividad ocurre cuando una persona aprobadora rechaza una solicitud de pago. Por lo general, es necesario corregirla y volver a enviarla, o cancelarla por completo. Se trata de una acción explícita de una persona usuaria que queda registrada para fines de auditoría.
Por qué es importante El seguimiento de los rechazos ayuda a identificar las causas habituales de los pagos fallidos, las desviaciones del proceso y los ciclos de retrabajo. También pone de manifiesto problemas de calidad inicial de los datos o de cumplimiento. Dónde obtenerlo Se registra como un evento explícito en una tabla del historial de aprobaciones o transacciones cuando una persona aprobadora selecciona la opción 'reject'. El registro suele incluir una marca de tiempo, el ID de usuario y, a menudo, un código de motivo. Capturar Evento registrado cuando una persona usuaria ejecuta la acción 'reject' para un pago. Tipo de evento explicit
	Payment Sent For Approval	Indica el momento en que un pago validado se envía al flujo de trabajo de aprobación. Por lo general, queda registrado mediante un cambio de estado que indica que el pago está pendiente de la acción de una persona aprobadora.
Por qué es importante Esta actividad marca el inicio del subproceso de aprobación. Analizar el tiempo transcurrido hasta «Payment Approved» es fundamental para comprender los cuellos de botella en las aprobaciones. Dónde obtenerlo Se infiere a partir de un cambio en el campo de estado del pago a 'Pending Approval', 'Submitted for Approval' o un estado similar en un registro del flujo de trabajo o del estado de la transacción. Capturar Cambio del estado de la transacción de pago de 'Validated' a 'Pending Approval'. Tipo de evento inferred

Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de FIS Global

Pasos

Confirme que el motor de pagos de FIS Global archive los mensajes XML ISO 20022 sin procesar, incluidas las instrucciones de pago pacs.008 y los informes de estado de pago pacs.002, en una ubicación accesible del sistema de archivos. Obtenga la ruta del archivo, la convención para nombrar archivos, la configuración de espacios de nombres, el período de retención y la correspondencia entre Payment Transaction ID y los identificadores ISO 20022, como EndToEndId, TxId, InstrId o UETR.
Instale Python 3.10 o una versión posterior y los módulos de la biblioteca estándar que utiliza el script, incluidos pathlib, xml.etree.ElementTree, csv, datetime, decimal y collections. La implementación de referencia no requiere paquetes externos. Compruebe que la cuenta de ejecución pueda leer el archivo XML y escribir el archivo de salida de ProcessMind.
Configure el directorio de entrada, el archivo de salida, las fechas de inicio y fin, la zona horaria y los filtros específicos de la empresa en la sección de configuración del script. Sustituya únicamente los marcadores de posición documentados. No dé por sentado que el nombre de un archivo o un elemento XML contiene el identificador de caso de ProcessMind hasta validar la correspondencia con archivos representativos.
Revise archivos pacs.008 y pacs.002 representativos de transacciones completadas, rechazadas, fallidas, corregidas y liquidadas. Confirme los espacios de nombres XML e identifique los elementos que contienen el identificador de transacción, el importe, la moneda, la fecha de ejecución solicitada, la fecha de liquidación, el código de estado, el código de motivo, la marca de tiempo del evento, el usuario o agente del sistema que procesó la operación, el tipo de pago y la unidad de negocio. Actualice las rutas XPath configuradas si la implementación de FIS utiliza otras rutas.
Ejecute primero el script con un intervalo de fechas limitado. El analizador lee cada archivo XML, extrae los datos del mensaje y de la transacción, asigna los códigos de estado y motivo ISO 20022 a actividades explícitas y escribe una fila por cada actividad extraída. El script también crea filas Payment Error Identified y Payment Error Resolved a partir de indicadores explícitos de error o reparación, y crea Late Payment Identified solo cuando la liquidación se produjo después de la fecha de vencimiento.
Revise el CSV generado y el informe de validación. Compruebe que PaymentTransactionId, ActivityName y EventTimestamp estén completos en todas las filas, que puedan aparecer los 13 nombres de actividad requeridos y que las marcas de tiempo estén normalizadas de forma coherente. Investigue las transacciones con identificadores ausentes, códigos de estado no admitidos, eventos duplicados o fechas contradictorias antes de ampliar el período de extracción.
Concilie el recuento de eventos con el archivo de origen y, si están disponibles, con los informes operativos o las extracciones de auditoría de FIS. Valide una muestra de transacciones de principio a fin, incluidos la aprobación, el rechazo, la autorización, el envío de instrucciones, la confirmación de la red, la liquidación, la gestión de errores, la conciliación y la lógica de pagos atrasados. Si necesita trazabilidad operativa, conserve en el resultado de auditoría el nombre del archivo de origen y la referencia a la línea o al mensaje de origen.
Programe el script para que se ejecute cuando el archivo de origen esté completo para el período seleccionado, o ejecútelo de forma incremental con un período de solapamiento controlado para capturar mensajes pacs.002 que lleguen tarde. Elimine duplicados usando PaymentTransactionId, ActivityName, EventTimestamp y la identidad del mensaje de origen, pero conserve las repeticiones legítimas cuando el origen registre varias ocurrencias.
Exporte el Registro de eventos final como CSV UTF-8, con una fila por evento y las columnas PaymentTransactionId, ActivityName, EventTimestamp, ProcessingUser, PaymentAmount, CurrencyCode, PaymentType, PaymentDueDate, ActualSettlementDate y BusinessUnit. Cargue el archivo en ProcessMind y configure PaymentTransactionId como identificador del caso, ActivityName como actividad y EventTimestamp como marca de tiempo del evento. ProcessMind lee el Registro de eventos tal como está y no deduce las actividades que faltan.

Configuración

Ruta del archivo de entrada: configure el directorio que contiene los archivos XML ISO 20022 sin procesar. Incluya todos los subdirectorios pertinentes si el archivo está dividido por fecha, empresa, tipo de mensaje o estado de procesamiento.
Tipos de mensaje: incluya pacs.008 para las instrucciones de pago y pacs.002 para los informes de estado de pago. Añada otros tipos de mensaje solo después de validar sus identificadores y el significado de sus estados en la implementación de FIS.
Correspondencia de identificadores: configure las rutas XPath candidatas que permiten resolver Payment Transaction ID. Priorice el identificador que se utilice de forma coherente en el registro de transacciones de FIS y en todos los mensajes ISO 20022 relacionados. No combine identificadores no relacionados sin una regla de correlación documentada.
Asignación de actividades: configure la correspondencia de códigos de estado y motivo para la creación, la validación, el envío para aprobación, la aprobación, el rechazo, la autorización, el envío de instrucciones, la confirmación, la liquidación, la identificación de errores, la resolución de errores y la conciliación. El script proporcionado utiliza asignaciones configurables e indicadores explícitos del origen, en lugar de deducir eventos habituales del ciclo de vida a partir de registros ausentes.
Intervalo de fechas: comience con entre 3 y 6 meses de datos. Utilice un período más corto para las pruebas iniciales o los archivos de gran volumen, e incluya un período de solapamiento si los mensajes de estado pueden llegar después de la fecha original del pago.
Filtros de fecha: configure las fechas de inicio y fin usando la marca de tiempo del evento de origen, cuando esté disponible. Si un mensaje no tiene marca de tiempo del evento, el script puede usar la marca de tiempo de modificación del archivo solo si esta opción se habilita explícitamente. Documente esta alternativa, ya que no representa la hora de un evento de negocio.
Filtros de empresa y organización: configure filtros de empresa, unidad de negocio, entidad legal, producto de pago o tipo de documento solo si los elementos XML correspondientes están presentes y sus valores se han validado. Utilice [Configure based on your system] para los filtros específicos de cada implementación.
Zona horaria: establezca la zona horaria del sistema de origen o la política de normalización a UTC. Aplique la misma política a todos los mensajes para garantizar un orden fiable de los eventos.
Indicadores de error y reparación: configure los códigos de estado y motivo, así como los marcadores explícitos de reparación o excepción que representan Payment Error Identified y Payment Error Resolved. No clasifique todos los rechazos como errores, salvo que esa sea la definición de negocio aprobada.
Indicadores de conciliación: configure el estado de conciliación explícito, el mensaje de conciliación, el indicador de coincidencia con el libro mayor o el resultado del lote que utilice la implementación de FIS. Si la conciliación se almacena fuera del archivo XML, proporcione una fuente independiente aprobada y una regla de correlación.
Rendimiento: procese los archivos de forma iterativa en lugar de cargar todo el archivo en la memoria. Divida las ejecuciones grandes por fecha o directorio, escriba resultados intermedios y utilice un área de almacenamiento provisional local con espacio suficiente. Para archivos muy grandes, distribuya el procesamiento entre directorios independientes solo después de confirmar que el orden de salida y la eliminación de duplicados estén controlados.
Requisitos previos: acceso de lectura al archivo XML, acceso de escritura a la ubicación de salida, permiso para ejecutar Python, acceso aprobado a los datos de pago y una correspondencia validada de los identificadores y códigos de estado de FIS. Este método basado en archivos no presupone ningún código de transacción, ruta de menú, endpoint de API, nombre de tabla o licencia específicos de FIS.

Consulta de ejemplo python

from __future__ import annotations

import csv
import hashlib
import re
import sys
import xml.etree.ElementTree as ET
from collections import defaultdict
from datetime import date, datetime, timezone
from decimal import Decimal, InvalidOperation
from pathlib import Path
from typing import Dict, Iterable, List, Optional, Tuple

class=class="hl-string">"hl-comment"># Replace only these documented placeholders.
INPUT_DIRECTORY = Path(class="hl-string">"[Your XML archive directory]")
OUTPUT_FILE = Path(class="hl-string">"[Your ProcessMind event log output path].csv")
START_DATE = class="hl-string">"[YYYY-MM-DD]"
END_DATE = class="hl-string">"[YYYY-MM-DD]"
SOURCE_TIMEZONE = timezone.utc
COMPANY_FILTER = class="hl-string">""  class=class="hl-string">"hl-comment"># Leave empty unless a validated company or business-unit value is required.

class=class="hl-string">"hl-comment"># Update these candidates after inspecting representative FIS XML files.
IDENTIFIER_PATHS = [
    class="hl-string">"EndToEndId", class="hl-string">"TxId", class="hl-string">"InstrId", class="hl-string">"UETR", class="hl-string">"PaymentTransactionId",
    class="hl-string">"PaymentId", class="hl-string">"TransactionId"
]
AMOUNT_PATHS = [class="hl-string">"InstdAmt", class="hl-string">"IntrBkSttlmAmt", class="hl-string">"Amt", class="hl-string">"Amount"]
CURRENCY_PATHS = [class="hl-string">"InstdAmt", class="hl-string">"IntrBkSttlmAmt", class="hl-string">"Amt", class="hl-string">"Currency", class="hl-string">"Ccy"]
DUE_DATE_PATHS = [class="hl-string">"ReqdExctnDt", class="hl-string">"ReqdColltnDt", class="hl-string">"DueDate", class="hl-string">"RequestedExecutionDate"]
SETTLEMENT_DATE_PATHS = [class="hl-string">"SttlmDt", class="hl-string">"SettlementDate", class="hl-string">"ActualSettlementDate"]
TIMESTAMP_PATHS = [
    class="hl-string">"CreDtTm", class="hl-string">"AccptncDtTm", class="hl-string">"AccptncDt", class="hl-string">"OrgnlCreDtTm", class="hl-string">"TxDtTm",
    class="hl-string">"SttlmDt", class="hl-string">"SettlementDate", class="hl-string">"EventTimestamp", class="hl-string">"Timestamp"
]
USER_PATHS = [class="hl-string">"UserId", class="hl-string">"UserID", class="hl-string">"Operator", class="hl-string">"Approver", class="hl-string">"ProcessingUser", class="hl-string">"Initiator"]
PAYMENT_TYPE_PATHS = [class="hl-string">"PmtMtd", class="hl-string">"SvcLvl", class="hl-string">"LclInstrm", class="hl-string">"CtgyPurp", class="hl-string">"PaymentType"]
BUSINESS_UNIT_PATHS = [class="hl-string">"BusinessUnit", class="hl-string">"CompanyCode", class="hl-string">"Company", class="hl-string">"OrgUnit", class="hl-string">"LegalEntity"]
STATUS_PATHS = [class="hl-string">"TxSts", class="hl-string">"GrpSts", class="hl-string">"Status", class="hl-string">"PaymentStatus", class="hl-string">"TransactionStatus"]
REASON_PATHS = [class="hl-string">"Cd", class="hl-string">"Rsn", class="hl-string">"ReasonCode", class="hl-string">"StatusReason", class="hl-string">"AddtlInf"]
ERROR_PATHS = [class="hl-string">"Error", class="hl-string">"Exception", class="hl-string">"Failure", class="hl-string">"ErrorCode", class="hl-string">"ExceptionCode"]
REPAIR_PATHS = [class="hl-string">"Repair", class="hl-string">"Resolved", class="hl-string">"Resolution", class="hl-string">"ErrorResolved", class="hl-string">"ExceptionResolved"]
RECONCILIATION_PATHS = [class="hl-string">"Reconciled", class="hl-string">"ReconciliationStatus", class="hl-string">"LedgerMatched", class="hl-string">"BankStatementMatched"]

class=class="hl-string">"hl-comment"># Validate and extend these mappings against the FIS implementation.
STATUS_ACTIVITY_MAP = {
    class="hl-string">"NEW": class="hl-string">"Payment Request Created",
    class="hl-string">"RECEIVED": class="hl-string">"Payment Request Created",
    class="hl-string">"VALIDATED": class="hl-string">"Payment Details Validated",
    class="hl-string">"PENDING_APPROVAL": class="hl-string">"Payment Sent For Approval",
    class="hl-string">"AWAITING_APPROVAL": class="hl-string">"Payment Sent For Approval",
    class="hl-string">"APPROVAL_PENDING": class="hl-string">"Payment Sent For Approval",
    class="hl-string">"APPROVED": class="hl-string">"Payment Approved",
    class="hl-string">"REJECTED": class="hl-string">"Payment Rejected",
    class="hl-string">"AUTHORIZED": class="hl-string">"Payment Authorized",
    class="hl-string">"SENT": class="hl-string">"Payment Instruction Sent",
    class="hl-string">"DISPATCHED": class="hl-string">"Payment Instruction Sent",
    class="hl-string">"ACCP": class="hl-string">"Payment Confirmed",
    class="hl-string">"ACCEPTED": class="hl-string">"Payment Confirmed",
    class="hl-string">"CONFIRMED": class="hl-string">"Payment Confirmed",
    class="hl-string">"SETTLED": class="hl-string">"Payment Settled",
    class="hl-string">"BOOK": class="hl-string">"Payment Settled",
    class="hl-string">"RECONCILED": class="hl-string">"Payment Reconciled",
}
ERROR_STATUS_CODES = {class="hl-string">"RJCT", class="hl-string">"REJECTED", class="hl-string">"FAILED", class="hl-string">"ERROR", class="hl-string">"EXCEPTION", class="hl-string">"CANCELLED"}
RESOLVED_STATUS_CODES = {class="hl-string">"REPAIRED", class="hl-string">"RESOLVED", class="hl-string">"CORRECTED", class="hl-string">"REPROCESSING", class="hl-string">"REPROCESSED"}

OUTPUT_COLUMNS = [
    class="hl-string">"PaymentTransactionId", class="hl-string">"ActivityName", class="hl-string">"EventTimestamp", class="hl-string">"ProcessingUser",
    class="hl-string">"PaymentAmount", class="hl-string">"CurrencyCode", class="hl-string">"PaymentType", class="hl-string">"PaymentDueDate",
    class="hl-string">"ActualSettlementDate", class="hl-string">"BusinessUnit"
]


def local_name(tag: str) -> str:
    return tag.rsplit(class="hl-string">"}", 1)[-1].lower()


def text_values(root: ET.Element, candidates: Iterable[str]) -> List[str]:
    wanted = {candidate.lower() for candidate in candidates}
    values: List[str] = []
    for element in root.iter():
        if local_name(element.tag) in wanted:
            value = (element.text or class="hl-string">"").strip()
            if value:
                values.append(value)
            for key, attribute_value in element.attrib.items():
                if key.rsplit(class="hl-string">"}", 1)[-1].lower() in {class="hl-string">"ccy", class="hl-string">"currency"} and attribute_value.strip():
                    values.append(attribute_value.strip())
    return values


def first_value(root: ET.Element, candidates: Iterable[str]) -> str:
    values = text_values(root, candidates)
    return values[0] if values else class="hl-string">""


def normalize_code(value: str) -> str:
    return re.sub(rclass="hl-string">"[^A-Z0-9_]", class="hl-string">"", value.upper().replace(class="hl-string">"-", class="hl-string">"_"))


def parse_datetime(value: str) -> Optional[datetime]:
    if not value:
        return None
    candidate = value.strip()
    if candidate.endswith(class="hl-string">"Z"):
        candidate = candidate[:-1] + class="hl-string">"+00:00"
    try:
        parsed = datetime.fromisoformat(candidate)
    except ValueError:
        for fmt in (class="hl-string">"%Y-%m-%d %H:%M:%S", class="hl-string">"%Y-%m-%d", class="hl-string">"%Y%m%d%H%M%S", class="hl-string">"%Y%m%d"):
            try:
                parsed = datetime.strptime(value.strip(), fmt)
                break
            except ValueError:
                parsed = None
        if parsed is None:
            return None
    if parsed.tzinfo is None:
        parsed = parsed.replace(tzinfo=SOURCE_TIMEZONE)
    return parsed.astimezone(timezone.utc)


def output_timestamp(value: Optional[datetime]) -> str:
    return value.astimezone(timezone.utc).isoformat().replace(class="hl-string">"+00:00", class="hl-string">"Z") if value else class="hl-string">""


def output_date(value: str) -> str:
    parsed = parse_datetime(value)
    return parsed.date().isoformat() if parsed else (value[:10] if re.match(rclass="hl-string">"^\d{4}-\d{2}-\d{2}", value) else class="hl-string">"")


def normalize_amount(value: str) -> str:
    if not value:
        return class="hl-string">""
    try:
        return format(Decimal(value.replace(class="hl-string">",", class="hl-string">"").strip()), class="hl-string">"f")
    except InvalidOperation:
        return value.strip()


def source_message_id(path: Path, root: ET.Element) -> str:
    raw = path.as_posix() + class="hl-string">"|" + first_value(root, [class="hl-string">"MsgId", class="hl-string">"MessageId", class="hl-string">"BizMsgIdr"])
    return hashlib.sha256(raw.encode(class="hl-string">"utf-8")).hexdigest()


def in_date_range(event_time: Optional[datetime]) -> bool:
    if not event_time:
        return True
    start = datetime.fromisoformat(START_DATE).replace(tzinfo=timezone.utc)
    end = datetime.fromisoformat(END_DATE).replace(tzinfo=timezone.utc)
    return start <= event_time < end.replace(hour=23, minute=59, second=59, microsecond=999999)


def add_event(events: List[Dict[str, str]], seen: set, transaction_id: str, activity: str,
              event_time: Optional[datetime], user: str, amount: str, currency: str,
              payment_type: str, due_date: str, settlement_date: str, business_unit: str,
              message_id: str) -> None:
    if not transaction_id or not event_time or not in_date_range(event_time):
        return
    row = {
        class="hl-string">"PaymentTransactionId": transaction_id,
        class="hl-string">"ActivityName": activity,
        class="hl-string">"EventTimestamp": output_timestamp(event_time),
        class="hl-string">"ProcessingUser": user,
        class="hl-string">"PaymentAmount": amount,
        class="hl-string">"CurrencyCode": currency,
        class="hl-string">"PaymentType": payment_type,
        class="hl-string">"PaymentDueDate": output_date(due_date),
        class="hl-string">"ActualSettlementDate": output_date(settlement_date),
        class="hl-string">"BusinessUnit": business_unit,
    }
    key = (transaction_id, activity, row[class="hl-string">"EventTimestamp"], message_id)
    if key not in seen:
        seen.add(key)
        events.append(row)


def parse_file(path: Path, events: List[Dict[str, str]], seen: set) -> None:
    try:
        root = ET.parse(path).getroot()
    except (ET.ParseError, OSError) as exc:
        print(fclass="hl-string">"Could not parse {path}: {exc}", file=sys.stderr)
        return
    message_id = source_message_id(path, root)
    transaction_id = first_value(root, IDENTIFIER_PATHS)
    if not transaction_id:
        return
    business_unit = first_value(root, BUSINESS_UNIT_PATHS)
    if COMPANY_FILTER and business_unit != COMPANY_FILTER:
        return
    amount = normalize_amount(first_value(root, AMOUNT_PATHS))
    currency = first_value(root, CURRENCY_PATHS)
    if len(currency) != 3 and currency:
        currency = currency.upper()
    due_date = first_value(root, DUE_DATE_PATHS)
    settlement_date = first_value(root, SETTLEMENT_DATE_PATHS)
    user = first_value(root, USER_PATHS)
    payment_type = first_value(root, PAYMENT_TYPE_PATHS)
    status_values = text_values(root, STATUS_PATHS)
    reason_values = text_values(root, REASON_PATHS)
    error_values = text_values(root, ERROR_PATHS)
    repair_values = text_values(root, REPAIR_PATHS)
    reconciliation_values = text_values(root, RECONCILIATION_PATHS)
    event_time = parse_datetime(first_value(root, TIMESTAMP_PATHS))
    if not event_time:
        return

    message_name = next((local_name(element.tag) for element in root.iter() if local_name(element.tag) in {class="hl-string">"pacs.008", class="hl-string">"pacs.002", class="hl-string">"document"}), class="hl-string">"")
    normalized_statuses = [normalize_code(value) for value in status_values + reason_values]
    normalized_text = class="hl-string">" ".join(normalize_code(value) for value in error_values)
    normalized_repairs = class="hl-string">" ".join(normalize_code(value) for value in repair_values)
    normalized_reconciliation = class="hl-string">" ".join(normalize_code(value) for value in reconciliation_values)

    if message_name or status_values:
        add_event(events, seen, transaction_id, class="hl-string">"Payment Request Created", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if any(code in {class="hl-string">"NEW", class="hl-string">"RECEIVED"} for code in normalized_statuses) else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Details Validated", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if class="hl-string">"VALIDATED" in normalized_statuses else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Sent For Approval", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if any(code in {class="hl-string">"PENDING_APPROVAL", class="hl-string">"AWAITING_APPROVAL", class="hl-string">"APPROVAL_PENDING"} for code in normalized_statuses) else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Approved", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if class="hl-string">"APPROVED" in normalized_statuses else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Rejected", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if any(code in {class="hl-string">"REJECTED", class="hl-string">"RJCT"} for code in normalized_statuses) else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Authorized", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if class="hl-string">"AUTHORIZED" in normalized_statuses else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Instruction Sent", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if any(code in {class="hl-string">"SENT", class="hl-string">"DISPATCHED"} for code in normalized_statuses) else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Confirmed", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if any(code in {class="hl-string">"ACCP", class="hl-string">"ACCEPTED", class="hl-string">"CONFIRMED"} for code in normalized_statuses) else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Settled", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if any(code in {class="hl-string">"SETTLED", class="hl-string">"BOOK"} for code in normalized_statuses) else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Reconciled", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if class="hl-string">"RECONCILED" in normalized_statuses or any(code in normalized_reconciliation for code in {class="hl-string">"TRUE", class="hl-string">"MATCHED", class="hl-string">"RECONCILED"}) else None

    if any(code in ERROR_STATUS_CODES for code in normalized_statuses) or normalized_text:
        add_event(events, seen, transaction_id, class="hl-string">"Payment Error Identified", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id)
    if any(code in RESOLVED_STATUS_CODES for code in normalized_statuses) or any(code in normalized_repairs for code in {class="hl-string">"TRUE", class="hl-string">"RESOLVED", class="hl-string">"REPAIRED", class="hl-string">"CORRECTED"}):
        add_event(events, seen, transaction_id, class="hl-string">"Payment Error Resolved", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id)

    due = parse_datetime(due_date)
    settled = parse_datetime(settlement_date)
    if due and settled and settled.date() > due.date():
        add_event(events, seen, transaction_id, class="hl-string">"Late Payment Identified", settled, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id)


def main() -> None:
    events: List[Dict[str, str]] = []
    seen = set()
    for path in sorted(INPUT_DIRECTORY.rglob(class="hl-string">"*.xml")):
        parse_file(path, events, seen)
    events.sort(key=lambda row: (row[class="hl-string">"PaymentTransactionId"], row[class="hl-string">"EventTimestamp"], row[class="hl-string">"ActivityName"]))
    OUTPUT_FILE.parent.mkdir(parents=True, exist_ok=True)
    with OUTPUT_FILE.open(class="hl-string">"w", newline=class="hl-string">"", encoding=class="hl-string">"utf-8") as handle:
        writer = csv.DictWriter(handle, fieldnames=OUTPUT_COLUMNS)
        writer.writeheader()
        writer.writerows(events)
    print(fclass="hl-string">"Wrote {len(events)} event rows to {OUTPUT_FILE}")


if __name__ == class="hl-string">"__main__":
    main()

¿Listo para comenzar?

Utilice este Template para agilizar la recopilación de datos y comenzar a mejorar el procesamiento de pagos. Identifique oportunidades de eficiencia y refuerce el control financiero con información precisa sobre los procesos.

Volver a la guía de mejora

Descargar Template

Optimice hoy el procesamiento de pagos de FIS Global

Alcance un procesamiento directo del 98 % y elimine los problemas de conciliación.

Comience hoy su prueba gratuita.

No se requiere tarjeta de crédito. Comience en unos minutos.

Su Template de datos para el procesamiento de pagos

Su Template de datos para el procesamiento de pagos

Atributos del procesamiento de pagos

Actividades del procesamiento de pagos

Guías de extracción

Análisis con Python de archivos de registro XML ISO 20022

Pasos

Configuración

Consulta de ejemplo python

¿Listo para comenzar?

Optimice hoy el procesamiento de pagos de FIS Global