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

Su Template de datos de 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 de procesamiento de pagos

Este Template ofrece una guía completa de los atributos de datos y las actividades de proceso esenciales para analizar eficazmente el procesamiento de pagos. También incluye indicaciones prácticas para extraer esta información crítica 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 debe supervisar
Guía de extracción

¿Es nuevo en los registros de eventos? Aprenda a crear un registro de eventos de 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
	ID de transacción de pago PaymentTransactionId	El identificador único de la instrucción de pago o transacción específica.
Descripción Este atributo actúa como clave central para vincular todos los eventos de un mismo ciclo de vida del pago. Permite a los analistas 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 independientes en instancias de proceso. Permite visualizar el flujo de principio a fin y constituye la base de todas las métricas por caso, como el tiempo de ciclo y los ciclos de retrabajo. Por qué es importante Es el conector fundamental del Process Mining, ya que permite reconstruir actividades dispersas como un recorrido coherente. Dónde obtenerlo Consultar la documentación de FIS Global Ejemplos TRX-2023-899102PAY-US-99281ACH-7721-X99WIRE-2210-001
	Marca de tiempo del evento EventTimestamp	La fecha y hora específicas en que tuvo lugar la actividad.
Descripción Este atributo proporciona el contexto temporal de cada evento del proceso de pagos. Registra el momento exacto en que el sistema registró una acción, lo que permite ordenar cronológicamente las actividades. En el análisis, se utiliza para calcular la duración entre pasos, los tiempos de ciclo totales y las tasas de rendimiento. Permite identificar cuellos de botella al poner de relieve los retrasos entre etapas específicas del proceso. Por qué es importante El análisis basado en el tiempo es imposible sin este campo; impulsa todos los KPI de rendimiento y eficiencia. Dónde obtenerlo Consultar la documentación de FIS Global Ejemplos 2023-10-12T08:30:15Z2023-10-12T09:45:00Z2023-10-13T14:20:10Z
	Nombre de la actividad ActivityName	El nombre del paso del proceso o evento específico que tuvo lugar.
Descripción Este campo registra la acción específica realizada en un momento determinado, como «Payment Request Created» o «Payment Settled». Define los nodos del mapa de procesos y determina la estructura del flujo del proceso. Los analistas utilizan este atributo para comprender la secuencia de operaciones. Es fundamental para identificar desviaciones de la ruta habitual, detectar pasos omitidos o descubrir 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 sus variantes. Dónde obtenerlo Consultar la documentación de FIS Global Ejemplos Solicitud de pago creadaDatos del pago validadosPago aprobadoPago liquidado
	Código de moneda CurrencyCode	El 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 o 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 entre pagos transfronterizos y nacionales. Por qué es importante Es fundamental en entornos multidivisa para interpretar correctamente los volúmenes financieros. Dónde obtenerlo Consultar la documentación de FIS Global Ejemplos USDEURGBPJPY
	Fecha de vencimiento del pago PaymentDueDate	La fecha en la que se espera que el pago esté liquidado.
Descripción Este atributo registra el plazo del pago solicitado por quien lo inicia o definido por las condiciones de la factura. Sirve como referencia objetivo para medir el rendimiento puntual. Este campo es fundamental para el Dashboard «Payment Due Date Adherence». Al comparar esta fecha con la fecha real de «Payment Settled», los analistas pueden identificar pagos atrasados, calcular posibles penalizaciones y evaluar el cumplimiento de los acuerdos con proveedores. Por qué es importante Proporciona la base para medir el cumplimiento de los niveles de servicio y la puntualidad. Dónde obtenerlo Consultar la documentación de FIS Global Ejemplos 2023-11-012023-11-15
	Fecha real de liquidación ActualSettlementDate	La fecha en la que el pago se finalizó y liquidó realmente.
Descripción Este atributo registra la fecha efectiva en la que se transfirieron los fondos o se consideró completada la transacción. Se diferencia de la marca de tiempo de procesamiento porque refleja la fecha valor. En el análisis, se utiliza junto con la fecha de vencimiento para calcular el «On-Time Payment Rate». También activa la fase de conciliación, por lo que es fundamental para analizar el «Payment Reconciliation Cycle Time». Por qué es importante Representa la conclusión financiera del pago y es clave para analizar el flujo de caja. Dónde obtenerlo Consultar la documentación de FIS Global Ejemplos 2023-11-022023-11-14
	Importe del pago PaymentAmount	El 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 rendimiento financiero y el riesgo. Los analistas utilizan este campo para segmentar los procesos según pagos de importe alto o bajo, que a menudo siguen rutas de aprobación diferentes. Respaldan el Dashboard «Payment Throughput» y ayudan a identificar si los pagos de importe elevado tienen tiempos de ciclo más largos debido a controles más estrictos. Por qué es importante Añade la dimensión financiera al Process Mining y permite priorizar según el valor. Dónde obtenerlo Consultar la documentación de FIS Global Ejemplos 1500.00250.501000000.0045.99
	Tipo de pago PaymentType	La clasificación del método o instrumento de pago.
Descripción Este atributo clasifica el pago en tipos como transferencia bancaria, ACH, SEPA, pago en tiempo real (RTP) o cheque. Cada tipo de pago sigue reglas de procesamiento y SLA claramente diferentes. Los analistas utilizan este campo para comparar el «Payment Reconciliation Cycle Time» entre distintos canales de pago. Ayuda a explicar por qué algunos pagos se liquidan al instante y otros tardan días, y garantiza que el rendimiento se mida con el punto de referencia adecuado. Por qué es importante Es la dimensión principal para segmentar los flujos de procesos, ya que cada tipo tiene características únicas de enrutamiento y tiempos. Dónde obtenerlo Consultar la documentación de FIS Global Ejemplos Transferencia bancariaCrédito ACHSEPA InstantCheque
	Unidad de negocio BusinessUnit	La división o departamento interno que origina el pago.
Descripción Este atributo asigna el pago a una unidad organizativa específica, como «Banca minorista», «Préstamos comerciales» o «Tesorería». Se utiliza para agregar KPI como «Payment Throughput» y «Average Payment Cycle Time» por departamento. Esto ayuda a la dirección a comparar el rendimiento entre distintas divisiones y asignar recursos de forma eficaz. Por qué es importante Permite realizar comparaciones internas y asignar responsabilidades sobre el rendimiento del proceso. Dónde obtenerlo Consultar la documentación de FIS Global Ejemplos TesoreríaCuentas por pagarOperaciones minoristasGestión patrimonial
	Usuario de procesamiento ProcessingUser	El identificador o nombre del usuario o 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, como «SYSTEM_BATCH». Estos datos se utilizan para analizar el uso de recursos, identificar cuellos de botella manuales y auditar la segregación de funciones. Ayudan a calcular la «Processing User Utilization Rate» y a distinguir entre tareas manuales y automatizadas. Por qué es importante Esencial para el análisis de recursos, las tasas de automatización y las auditorías de cumplimiento. Dónde obtenerlo Consultar la documentación de FIS Global Ejemplos jsmithSYSTEM_AUTOBOTmdoe_approverAPI_GATEWAY
	¿El pago está atrasado? IsLatePayment	Una marca que indica si el pago se liquidó después de la fecha de vencimiento.
Descripción Este es un atributo booleano calculado. Devuelve true si la fecha de «Payment Settled» es posterior a la fecha de «Payment Due Date». Este atributo impulsa directamente el KPI «On-Time Payment Rate». Simplifica la creación de Dashboards, ya que permite filtrar rápidamente los casos problemáticos sin utilizar 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 Derivado de PaymentDueDate y ActualSettlementDate Ejemplos truefalse
	¿Requiere intervención manual? IsManualIntervention	Una marca que indica si la actividad implicó trabajo manual.
Descripción Este atributo booleano marca las actividades o los casos que requirieron intervención humana, como «Payment Error Resolved» o las aprobaciones manuales, frente al procesamiento directo (STP). Es esencial para el Dashboard «Manual Payment Intervention Rate». Ayuda a cuantificar el porcentaje de pagos que no están completamente automatizados y pone de relieve oportunidades de transformación digital. Por qué es importante Distingue entre el rendimiento automatizado y el esfuerzo manual, y orienta los cálculos del ROI de la automatización. Dónde obtenerlo Derivado de ActivityName o ProcessingUser Ejemplos truefalse
	Autoridad de aprobación ApprovalAuthority	El rol, 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, normalmente en función de un umbral de importe. Ayuda a seguir el enrutamiento del Workflow de aprobación. Los analistas lo utilizan para respaldar el Dashboard «Payment Authorization Bottlenecks». Permite desglosar los tiempos de aprobación por nivel de autoridad y comprobar si determinadas capas directivas están provocando retrasos. Por qué es importante Permite analizar la jerarquía de aprobación de la organización y detectar cuellos de botella. Dónde obtenerlo Consultar la documentación de FIS Global Ejemplos Gerente de nivel 1CFOEquipo de CumplimientoSistema de aprobación automática
	Canal de pago PaymentChannel	El canal a través del cual se inició la solicitud de pago.
Descripción Este atributo describe el origen de la instrucción de pago, como banca en línea, aplicación móvil, API o sucursal. Ayuda a comprender el canal de entrada de la transacción. Los analistas lo utilizan para comparar la eficiencia del procesamiento entre distintos canales. Por ejemplo, permite determinar si los pagos iniciados mediante API tienen tasas de error inferiores a las de los pagos 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 Consultar la documentación de FIS Global Ejemplos Banca en líneaAplicación móvilGateway corporativoCajero de sucursal
	Código de error de validación ValidationErrorCode	El código o motivo que indica por qué un pago no superó la validación.
Descripción Este atributo se completa cuando un pago entra en la actividad «Payment Error Identified». Contiene detalles específicos del fallo, como «Invalid IBAN», «Insufficient Funds» o «Missing Beneficiary Address». Este campo impulsa el Dashboard «Payment Data Validation Error Rates». Agrupar los datos por este atributo revela las causas más frecuentes del retrabajo y permite aplicar correcciones específicas en la introducción de datos de origen o en la configuración del sistema. Por qué es importante Identifica las causas raíz de las fricciones del proceso y de los ciclos de retrabajo. Dónde obtenerlo Consultar la documentación de FIS Global Ejemplos ERR-001: Cuenta no válidaERR-055: Coincidencia con sancionesERR-009: Transacción duplicada
	Cuenta del ordenante SenderAccount	El número de cuenta desde el que se debitan los fondos.
Descripción Este atributo identifica la cuenta de origen de la transacción. Proporciona granularidad al analizar pagos procedentes de cuentas internas específicas. En el análisis, ayuda a identificar si determinadas cuentas de financiación son propensas a errores, como fondos insuficientes, o a retrasos. 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 Consultar la documentación de FIS Global Ejemplos 123456789987654321ACC-TREASURY-01
	País del beneficiario BeneficiaryCountry	El código de 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 la supervisión del cumplimiento de los pagos y el análisis del enrutamiento. Los pagos internacionales suelen implicar distintos intermediarios, controles de cumplimiento y tiempos de ciclo más largos, por lo que 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 Consultar la documentación de FIS Global Ejemplos USDECNGB
	Sistema de origen SourceSystem	El 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 motor bancario central, la pasarela de pagos o la herramienta de análisis de sanciones. Es fundamental para la trazabilidad 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 tuvieron lugar determinadas actividades y facilita la resolución de problemas de calidad de datos. Por qué es importante Garantiza la trazabilidad y el contexto, especialmente en entornos complejos con varios motores de pagos integrados. Dónde obtenerlo Consultar la documentación de FIS Global Ejemplos FIS OPFTraxPaymentHub_01SanctionsScreeningDB
	Última actualización de datos LastDataUpdate	La marca de tiempo en la que el registro se extrajo o actualizó por última vez.
Descripción Este atributo indica la actualidad de los datos utilizados en el análisis. Ayuda a comprender si se están consultando datos en tiempo real o una instantánea de un periodo anterior. En los Dashboards, este campo suele utilizarse para mostrar una etiqueta «Datos actualizados a». Garantiza que las decisiones se basen en la información más relevante disponible y facilita la gestión de las cargas de datos incrementales. Por qué es importante Establece la vigencia de los datos y genera confianza en la actualidad de los informes. 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 debe capturar en su registro de eventos para descubrir y optimizar el proceso con precisión.

6 Recomendado 7 Opcional

	Actividad	Descripción
	Instrucción de pago enviada	Esta actividad marca el momento en que el sistema de FIS envía la instrucción de pago finalizada a la red de pagos correspondiente, como ACH, Fedwire o SWIFT. Es 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 interno de procesamiento. Es fundamental para analizar la eficiencia del enrutamiento y el tiempo necesario para el procesamiento externo. Dónde obtenerlo Se registra en un registro de transacciones o mensajes que realiza el seguimiento de las comunicaciones con redes de pagos externas. Busque un registro que indique la transmisión correcta de un mensaje saliente junto con una marca de tiempo. Recopilar Evento generado por el sistema cuando el mensaje de pago se envía a la red de compensación. Tipo de evento explicit
	Pago aprobado	Un hito clave en el que una persona usuaria autorizada aprueba el pago y permite que avance a la siguiente etapa. Casi siempre se registra como un evento explícito con el ID de la persona aprobadora y una marca de tiempo cuando esta realiza la acción 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 garantizar el cumplimiento de los controles financieros. Los retrasos en esta etapa pueden afectar considerablemente el rendimiento de los pagos puntuales. Dónde obtenerlo Se captura en una tabla de registros de aprobación o como un evento explícito en el historial principal de transacciones. El registro de eventos vincularía el Payment Transaction ID, el ID de usuario de la persona aprobadora y la marca de tiempo de la aprobación. Recopilar Se registra cuando una persona usuaria con derechos de aprobación ejecuta la acción 'approve' sobre un pago. Tipo de evento explicit
	Pago autorizado	Representa un paso de autorización final, que suele ser necesario para pagos de gran importe o cuando debe intervenir una autoridad diferente después de la aprobación inicial. Esta acción se registra 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 localizar los retrasos en los procesos de aprobación multinivel. Dónde obtenerlo Se registra en un registro de auditoría o de transacciones. Este 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. Recopilar 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
	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 tratarse de un proceso por lotes automatizado o de una acción manual de un usuario.
Por qué es importante Esta actividad marca el final absoluto del ciclo de vida del pago. Analizar el «Payment Reconciliation Cycle Time» 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 final cambia a «Reconciled» en un módulo financiero o contable vinculado al sistema de pagos. Recopilar Se identifica cuando se completa una fecha de conciliación o cuando el estado cambia a «Reconciled». Tipo de evento inferred
	Pago liquidado	Esta actividad marca la finalización de la transferencia de fondos, cuando la transacción se considera liquidada financieramente. Normalmente se registra al recibir la confirmación final de liquidación de la red de pagos o de 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 la finalización satisfactoria del proceso central de ejecución del pago. Dónde obtenerlo Se infiere a partir de un cambio de estado final del registro de pago a «Settled», «Completed» o «Posted». Este cambio de estado se produce mediante archivos de liquidación por lotes o mensajes en tiempo real del sistema de compensación. Recopilar Un cambio de estado de la transacción de pago a «Settled» o su equivalente. Tipo de evento inferred
	Solicitud de pago creada	Este es el primer evento del ciclo de vida del pago y representa el momento en que se inicia una nueva transacción de pago en el sistema de FIS. Normalmente se registra como una entrada explícita en una tabla de registro de transacciones cuando un usuario 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 pagos de principio a fin y analizar el rendimiento y el volumen generales de los pagos. Dónde obtenerlo Se registra en una tabla central de transacciones, identificada por 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'. Recopilar Evento registrado al crear un nuevo registro de transacción de pago. Tipo de evento explicit
	Datos del pago validados	Esta actividad indica que los datos del pago han superado las comprobaciones de validación automatizadas iniciales de formato, integridad y exactitud. A menudo se deduce de un cambio de estado del registro de 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 lugar en que se producen los errores de introducción de datos. Es un requisito previo para analizar el KPI Payment Data Validation Error Rate y comprender las fuentes de retrabajo. Dónde obtenerlo Se deduce de un campo de cambio de estado o situación en la tabla de transacciones de pago. El paso de un estado inicial a un estado 'validated', junto con la marca de tiempo correspondiente, marca este evento. Recopilar Se identifica mediante un cambio en el campo de estado del pago a 'Validated' o a un valor similar. Tipo de evento inferred
	Error de pago identificado	Indica que se detectó un error en algún momento del proceso después de la validación inicial, como el 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 un usuario señala un problema, creando un registro con un código de error y una marca de tiempo. Recopilar Se registra un código de excepción o error asociado a la transacción de pago. Tipo de evento explicit
	Error de pago resuelto	Marca la resolución de un error de pago identificado previamente, lo que permite volver a procesar o cancelar el pago. Es una acción explícita realizada por un usuario para eliminar el estado de excepción.
Por qué es importante Esta actividad cierra el ciclo de la excepción. La duración entre «Error Identified» y este evento es una medida clave de la eficiencia operativa en la gestión de excepciones. Dónde obtenerlo Se registra cuando un usuario elimina una alerta de error o saca la transacción de una cola de excepciones. Esta acción se captura en un registro de auditoría o en el historial de transacciones con una marca de tiempo. Recopilar Una acción del usuario elimina 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 «On-Time Payment Rate» y el Dashboard «Payment Due Date Adherence». Ayuda a cuantificar el impacto de los retrasos del proceso en las relaciones con los proveedores y en posibles cargos por demora. Dónde obtenerlo No se extrae directamente. Se calcula durante la transformación de datos comparando la marca de tiempo de «Settlement Date» con el campo «Payment Due Date». Si la fecha de liquidación es posterior a la fecha de vencimiento, se genera este evento. Recopilar Se calcula si «Settlement Date» > «Payment Due Date». Tipo de evento calculated
	Pago confirmado	Representa la recepción de una confirmación de la red de pagos o del banco beneficiario que indica que el pago se ha recibido. Este evento se activa mediante un mensaje entrante 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 «Instruction Sent» y «Confirmed» mide la latencia de la red externa y el tiempo de procesamiento. Dónde obtenerlo Se genera al analizar los mensajes de confirmación entrantes de las redes de pagos. El sistema actualiza el estado del pago y registra una marca de tiempo de confirmación. Recopilar Un mensaje entrante de una red de compensación actualiza el estado del pago a «Confirmed». Tipo de evento explicit
	Pago enviado para aprobación	Representa el momento en que un pago validado se envía al Workflow de aprobación. Normalmente se registra mediante un cambio de estado que indica que el pago está a la espera 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 entre este evento y 'Payment Approved' es fundamental para comprender los cuellos de botella de aprobación. Dónde obtenerlo Se deduce de un cambio en el campo de estado del pago a 'Pending Approval', 'Submitted for Approval' o un estado similar dentro de un Workflow o registro de estados de transacción. Recopilar Un cambio de estado de la transacción de pago de 'Validated' a 'Pending Approval'. Tipo de evento inferred
	Pago rechazado	Esta actividad se produce cuando una persona aprobadora rechaza una solicitud de pago, lo que normalmente exige corregirla y volver a enviarla o cancelarla por completo. Es una acción explícita de usuario que se registra con fines de auditoría.
Por qué es importante El seguimiento de los rechazos ayuda a identificar las causas habituales de los fallos de pago, las desviaciones del proceso y los bucles de retrabajo. También pone de manifiesto problemas de calidad de los datos iniciales o de cumplimiento. Dónde obtenerlo Se registra como un evento explícito en una tabla de historial de aprobación o de 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. Recopilar Evento registrado cuando una persona usuaria ejecuta la acción 'reject' para un pago. Tipo de evento explicit

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 mensajes XML ISO 20022 sin procesar, incluidos pacs.008, con instrucciones de pago, y pacs.002, con informes de estado de pago, en una ubicación accesible del sistema de archivos. Obtenga la ruta del archivo, la convención de nombres, la configuración de espacios de nombres, el periodo de conservación y la correspondencia entre Payment Transaction ID y los identificadores ISO 20022, como EndToEndId, TxId, InstrId o UETR.
Instale Python 3.10 o posterior y los módulos de la biblioteca estándar utilizados por el script, incluidos pathlib, xml.etree.ElementTree, csv, datetime, decimal y collections. La implementación de referencia no requiere paquetes externos. Confirme 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, la fecha de inicio, la fecha de finalización, 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 hecho que un nombre de 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 correctas, rechazadas, fallidas, reparadas 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 de procesamiento o agente del sistema, el tipo de pago y la unidad de negocio. Actualice las rutas XPath configuradas si la implementación de FIS utiliza rutas diferentes.
Ejecute primero el script con un intervalo de fechas limitado. El analizador lee cada archivo XML, extrae datos a nivel de mensaje y de transacción, asigna los códigos de estado y motivo ISO 20022 a actividades explícitas y escribe una fila de evento 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 únicamente cuando la liquidación se produjo después de la fecha de vencimiento.
Revise el CSV generado y el informe de validación. Confirme que PaymentTransactionId, ActivityName y EventTimestamp estén informados en todas las filas, que puedan aparecer los 13 nombres de actividad obligatorios y que las marcas de tiempo estén normalizadas de forma coherente. Investigue las transacciones con identificadores ausentes, códigos de estado no compatibles, eventos duplicados o fechas contradictorias antes de ampliar el intervalo de extracción.
Concilie el número de eventos con el archivo de origen y, cuando 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. Conserve el nombre del archivo de origen y la línea o referencia del mensaje de origen en la salida de auditoría si necesita trazabilidad operativa.
Programe el script después de completar el archivo de origen del periodo seleccionado o ejecútelo de forma incremental con una ventana de solapamiento controlada para capturar mensajes pacs.002 que lleguen tarde. Elimine duplicados utilizando PaymentTransactionId, ActivityName, EventTimestamp y la identidad del mensaje de origen, pero conserve las actividades repetidas 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 de caso, ActivityName como actividad y EventTimestamp como marca de tiempo del evento. ProcessMind lee el Registro de eventos tal cual y no infiere actividades ausentes.

Configuración

Ruta del archivo de entrada: configure el directorio que contiene los archivos XML ISO 20022 sin procesar. Incluya todos los subdirectorios relevantes si el archivo está particionado 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 únicamente después de validar sus identificadores y la semántica de sus estados en la implementación de FIS.
Correspondencia de identificadores: configure los candidatos XPath que resuelven el Payment Transaction ID. Dé prioridad al identificador utilizado 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 las correspondencias de códigos de estado y motivo para la creación, validación, envío para aprobación, aprobación, rechazo, autorización, envío de instrucciones, confirmación, liquidación, identificación de errores, resolución de errores y conciliación. El script proporcionado utiliza asignaciones configurables e indicadores de origen explícitos, en lugar de inferir eventos ordinarios del ciclo de vida a partir de registros ausentes.
Intervalo de fechas: comience con entre 3 y 6 meses de datos. Utilice un intervalo más corto para las pruebas iniciales o para archivos de gran volumen, e incluya un periodo de solapamiento cuando los mensajes de estado puedan llegar después de la fecha de pago original.
Filtros de fecha: configure las fechas de inicio y finalización utilizando la marca de tiempo del evento de origen cuando esté disponible. Si un mensaje no tiene marca de tiempo del evento, el script puede utilizar la marca de tiempo de modificación del archivo únicamente cuando se habilite de forma explícita. Documente esta alternativa, ya que no representa la marca de tiempo de un evento de negocio.
Filtros empresariales y organizativos: configure filtros de empresa, unidad de negocio, entidad legal, producto de pago o tipo de documento únicamente cuando los elementos XML correspondientes estén presentes y sus valores hayan sido validados. 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, códigos de motivo e indicadores explícitos de reparación o excepción que representen Payment Error Identified y Payment Error Resolved. No clasifique todos los rechazos como errores salvo que esa sea la definición empresarial aprobada.
Indicadores de conciliación: configure el estado explícito de conciliación, el mensaje de conciliación, el indicador de coincidencia con el libro mayor o el resultado del lote utilizado por la implementación de FIS. Si la conciliación se almacena fuera del archivo XML, proporcione una fuente aprobada independiente y una regla de correlación.
Rendimiento: procese los archivos de forma iterativa en lugar de cargar todo el archivo en memoria. Divida las ejecuciones grandes por fecha o directorio, escriba resultados intermedios y utilice un área de preparación local con espacio suficiente en disco. Para archivos muy grandes, paralelice por particiones de directorios independientes únicamente después de confirmar que el orden de salida y la eliminación de duplicados siguen bajo control.
Requisitos previos: acceso de lectura al archivo XML, acceso de escritura a la ubicación de salida, permisos para ejecutar Python, acceso aprobado a los datos de pagos 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.

a 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 poner en marcha la mejora de su procesamiento de pagos. Descubra eficiencias y refuerce el control financiero mediante información precisa sobre sus procesos.

Volver a la guía de mejora Descargar Template

Optimice hoy su procesamiento de pagos de FIS Global

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

Inicie ahora su prueba gratuita

No necesita tarjeta de crédito; comience en minutos

Su Template de datos de procesamiento de pagos

Su Template de datos de procesamiento de pagos

Atributos del procesamiento de pagos

Actividades del procesamiento de pagos

Guías de extracción

Análisis en Python de archivos de Registro de eventos XML ISO 20022

Pasos

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Optimice hoy su procesamiento de pagos de FIS Global

Valoramos su privacidad