Integración de SAP PI a diferentes bancos usando SwiftNet y BCM

Actualizado: 22 nov 2022

SAP BCM es una aplicación del módulo financiero que permite integrar los procesos financieros con diferentes bancos de la forma más eficiente posible, permitiendo reducir así los costes operativos y además ajustarse a las políticas corporativas al mismo tiempo que hacer frente a nuevos retos necesarios para la agilización de los procesos de pago.

Oportunidades, estrategias e iniciativas:

• Reducción costes de mantenimiento ya que es independiente de estándares de pago y productos específicos de e-banking y con la posibilidad de escalar la solución de forma rápida y sencilla.
• Mejoras en la seguridad y “compliance” de la empresa, con una gestión transparente de todos los pagos sin infracciones en materia de controles internos.
• Monitorear todos los pagos realizados segmentándolos por cada uno de los status posibles (emitido, pendiente aprobación, nuevo, etc…)
• Mejorar el control y el cumplimiento de la liberación de los pagos aumentando la eficiencia operativa por medio de firmas digitales.
• Aprovechamiento de las tecnologías móviles para aprobar los lotes de pago con una aplicación móvil SAP.
• Establecer una pasarela de pago segura y estándar con múltiples bancos a través de la integración de SWIFT.

BCM

Hay 2 tipos principales de pagos que se generan a partir del sistema ECC. La clasificación de los pagos es la siguiente:

• FIN (transferencia de institución financiera) – Pagos internacionales transfronterizos

El mensaje FIN se utiliza para pagos y gestión de efectivo

• FTA (solicitud de impuestos federales): pago nacional dentro del país

La Solicitud de impuestos federales proporciona un mecanismo de pago de impuestos federales en el mismo día para los contribuyentes comerciales y los procesadores de nómina a través de sus instituciones financieras.

Los pagos creados en ambos casos son diferentes. El formato del archivo depende del tipo de pago y del banco. A continuación, se muestran algunos de los ejemplos:

El mapeo de campo para MT101 es estándar de SAP y parte de ERP. Para XML, esto es parte de la configuración a través de la transacción DMEE1 también en ERP. No se requiere interpretación o conversión de los archivos por parte de la interfaz.

El pago se genera con todas las condiciones necesarias para el Banco definitivo y luego se envía para aprobación. Después de la aprobación, se ejecuta un trabajo por lotes en el sistema ECC para crear el pago colectivo en un solo archivo. Luego, el archivo se cifra en el módulo BCM.

El archivo se envía a las carpetas respectivas ubicadas en el servidor ECC. Los detalles se pueden ver usando T-Code AL11. Hay diferentes carpetas creadas para diferentes Bancos y además también tenemos una carpeta de archivo que se explicará más adelante.

Una vez creado el archivo por lotes, se puede ver el estado del lote en BNK_MONI. A continuación, se muestran los estados del archivo de pago:

Podemos verificar el historial de estado del pago seleccionando la Fila y haciendo clic derecho en ella:

Integración de BCM y SwiftNet con SAP PI

Los archivos procesados ​​y enviados por BCM a través de SAP PI están en formato estándar para que SwiftNet los procese. No hemos utilizado ninguna asignación para cambiar el formato de archivo entrante. PI sondea los archivos del directorio AL11 del sistema ECC y envía el mismo archivo al sistema de terceros a través de la red SwiftNet. El tercero es responsable de la entrega de pagos al banco y la recepción de extractos bancarios del banco. El diagrama de flujo es el siguiente:

El producto SWIFT estándar proporcionado por SAP debe importarse en ESR (Enterprise Service Repository) en SAP PI system. Los formatos estándar para FIN y FTA se utilizan desde el módulo SWIFT en SWIFT 622:

Comprobación de cifrado y firma

Se utilizo SFTP Adpater para sondear los archivos del sistema ECC. El “Protocolo de transferencia de archivos SSH” o SFTP es un protocolo de red que proporciona funcionalidad de transferencia y manipulación de archivos sobre cualquier flujo de datos confiable. Por lo general, se usa con el protocolo SSH-2 para proporcionar una transferencia de archivos segura. SFTP cifra la sesión, evitando la detección casual de nombre de usuario, contraseña o cualquier cosa que se esté transmitiendo. Un beneficio clave de SFTP es su capacidad para manejar múltiples transferencias de archivos seguras a través de un solo canal cifrado. Al usar una sola tubería encriptada, hay menos agujeros en el firewall corporativo.

Todos los archivos creados en la carpeta AL11 del sistema ECC contendrán una firma. La verificación de la firma se realiza en PI system utilizando la clave del módulo y el parámetro del módulo SWIFT.

Para mostrar el archivo cifrado y firmado, hemos tomado la siguiente pantalla, ya que no hay archivos actualmente en la carpeta fileAct en el sistema ECC.

Configuración en el directorio de integración para pagos

Configuración del canal remitente

Hemos utilizado diferentes canales para diferentes Bancos. Esto facilita el apoyo a las pruebas para los bancos cuando sea necesario. Se apagarán los canales de los bancos que no estén en el ámbito de la prueba.

La firma se verifica mediante el parámetro «VerifyBackendSignature» disponible en el módulo SWIFT como en:

Detalles sobre los parámetros del módulo en el remitente:

• IsNotificationRequested: este parámetro está marcado como ‘verdadero’ para recibir notificaciones del banco sobre los pagos realizados.

• IsUrgent: el parámetro se marca como ‘falso’ para evitar la urgencia.

• KeyId: este es el ID de clave único para cada sistema integrado con SwiftNet en el paisaje. El formato del valor es SWIFT_ <SID>. SID – ID del sistema de desarrollo / prueba / sistema de producción

• UseLocalSecurity: los mensajes se intercambian de forma segura y confiable entre bancos y otras instituciones financieras

• VerifyBackendSignature: todos los archivos entrantes de ECC se comprobarán si están firmados por el módulo BCM. Los archivos sin cantar no se procesarán y el canal mostrará un mensaje de error en PI system.

• Exit es el módulo estándar para SFTP

Nota : La verificación de firma en el remitente se utiliza solo para pagos internacionales. No hemos utilizado el parámetro de verificación de firma para el canal del remitente para pagos nacionales.

Enmascaramiento de archivos entrantes:

El directorio de origen contiene la ubicación del directorio AL11. El esquema de nombre de archivo representa la nomenclatura de los archivos que se seleccionarán de la carpeta de AL11. La selección avanzada de archivos de origen también se ha realizado para no enviar archivos innecesarios al banco y solo procesar el archivo de pago requerido.

• Mseg. Para esperar antes de la modificación compruebe dónde PI espera algún tiempo desde que encuentra el archivo por primera vez, hasta que lo lee y procesa más tarde, y el archivo solo se procesa si no ha cambiado durante el período de espera. Como se muestra a continuación, PI espera 10 minutos hasta que se completa el archivo

• Enmascaramiento: supongamos que queremos procesar todos los archivos que tienen la extensión ‘.nfs’, pero queremos excluir todos los archivos que comienzan con la letra ‘GB2’. Para hacer esto, siga lo siguiente:

Además, mencione los parámetros de conexión como el nombre de host del servidor de envío, el puerto, el ID de usuario y la contraseña para la autenticación. El ID de usuario y la contraseña deben mantenerse en el nivel del servidor y no deben ser un usuario de diálogo / sistema.

Colocamos los archivos procesados ​​en carpetas de archivo en el sistema ECC.

Configuración del canal del receptor:

El canal del receptor contendrá la información de terceros . Hemos utilizado el cifrado PGP (Pretty Good Privacy) también ocurre cuando el pago se envía desde PI system

Detalles sobre los parámetros del módulo en el receptor:

• Armadura: si el protocolo (o) el canal de transmisión solo admite caracteres imprimibles ASCII, los datos que se van a transferir deben codificarse como texto sin formato. Esto se conoce como codificación binaria a texto. Si se aplica en el texto sin formato en sí y se descodifica en el extremo del receptor, se denomina «Armadura ASCII». Para activar el valor que ingresamos es «verdadero».

• EncryptionAlgorithm: en criptografía, Triple DES es el nombre común del cifrado de bloque del algoritmo de cifrado de datos triple (TDEA o Triple DEA), que aplica el algoritmo de cifrado del estándar de cifrado de datos (DES) tres veces a cada bloque de datos.

• PublicKeyRing : la clave pública se utiliza para codificar un mensaje digital con el fin de hacerlo ilegible sin el uso de una clave privada, que normalmente toma la forma de una contraseña.

• Destinatario: ID del destinatario de correo de destino.

Nota : La verificación de la firma en el receptor se utiliza solo para pagos nacionales. No hemos utilizado el parámetro de verificación de firma para los pagos internacionales en el extremo del destinatario.

Asignaciones:

Asignaciones FIN y FTA

Se utilizan asignaciones estándar para pagos FIN y FTA como se muestra en la siguiente figura:

Extractos bancarios y notificaciones de bancos / sistema de terceros

Tan pronto como el pago llega al sistema de terceros, que se conecta con diferentes Bancos, se envía un acuse de recibo técnico al sistema PI notificando la recepción de los pagos. Estos archivos de retroalimentación son enviados por terceros para pagos FTA y FIN. Además de estos comentarios, los bancos envían una notificación de estado de pago PAIN al sistema SAP PI después de recibir el pago. El estado de pago se envía al sistema ECC usando Proxy y el estado se cambia en consecuencia en la transacción BNK_MONI. También recibimos notificaciones del Banco para pagos FIN y FTA. Estas notificaciones tienen dos formatos diferentes, a saber, formato de archivo TXT y XML. Esto se discutirá en la siguiente sección.

Notificaciones de pago y extractos bancarios

Los Pagos enviados a Terceros son reconocidos por el Sistema de Terceros y el Banco. Tan pronto como el archivo de pago llega al sistema de terceros, se envía un acuse de recibo técnico a PI y el mismo se envía al sistema ECC. El estado en ECC se actualiza en BNK_MONI (Transacción del módulo BCM) (consulte la Figura: 5).

Reconocimiento de pago FIN y FTA por parte de un tercero

• El acuse de recibo se recibe del sistema de terceros cuando se recibe un pago FIN en un tercero. No se realiza encriptación para el proceso de reconocimiento.

• Las asignaciones utilizadas son de la asignación de operaciones estándar SwiftFIN_PaymentStatus y SwiftFTA_PaymentStatus del módulo SWIFT. (Consulte la Figura: 7)

DOLOR Reconocimiento por parte del banco

• El acuse de recibo enviado por el Banco a PI está en un formato diferente y al mismo nos referimos como DOLOR.

• Sin encriptación ni verificación realizada.

• El formato del archivo enviado es un informe que se puede encontrar en el componente de software Versión ISO20022 1.0 en el espacio de nombres http://sap.com/xi/ISO20022 y el nombre del informe como PaymentStatusReportV02.

• Este informe se asigna a CollectivePaymentOrderNotificationMessage, que es una estructura de SAP APPL 6.04 en el espacio de nombres http://sap.com/xi/APPL/Global2 .

Notificaciones de extractos bancarios

Notificación de extracto bancario TXT para pagos FIN:

La declaración se envía como un archivo de texto sin formato y el mismo se envía al sistema ECC de dos formas diferentes:

• El archivo se envía directamente al directorio AL11 para realizar un seguimiento de los extractos bancarios
• Se envía un mensaje de servicio a ECC mediante SOAP.

No hay ninguna asignación que se utilice exclusivamente para los formatos TXT, excepto que el nombre del archivo se obtiene de forma dinámica durante el tiempo de ejecución.

Notificación de extracto bancario XML para pagos FTA:

Las Notificaciones enviadas en formato XML usan el formato XSD que se ha recibido del Banco.

También se ha utilizado la interfaz (BankAccountStatementNotification_In) y el espacio de nombres http://sap.com/xi/APPL/SE/Global del componente de software ESA ECC-SE 604 para mapear los campos obligatorios.

Problemas y resolución

# Pagos duplicados al banco

• Los pagos duplicados no se procesan en el extremo de Terceros, lo que anula el riesgo.

# Pagos enviados a diferentes bancos provocando retrasos e inconsistencias.

• La versión del adaptador SFTP tenía un error al enrutar los pagos a canales incorrectos, lo que generaba inconsistencias y escaladas. Se implementó una nueva versión que resolvió el problema.

# Problemas con el anillo de claves públicas en el canal de comunicación

• La clave pública para el mecanismo de validación y establecimiento de comunicación debe implementarse a nivel de servidor en PI system. Esta clave la proporciona un tercero.

# Estado actualizado incorrectamente en BNK_MONI en el sistema ECC

• Debido a problemas de red entre SAP PI y Terceros o Terceros y el Banco, el estado se asigna incorrectamente en BNK_MONI. Por ejemplo: Aceptado por el banco se envía antes de Recibido por el banco. Es necesario realizar comprobaciones de red durante las pruebas de conectividad para garantizar que no haya retrasos