Esta transacción procesa los mensajes entrantes de diferentes formatos. Un archivo puede contener uno o más mensajes en el formato correspondiente.

Se admite el procesamiento de mensajes parciales, como en SWIFT MT 700 y MT 701. Esto significa que los mensajes parciales individuales que pertenezcan juntos se contabilizarán como un mensaje completo y se proporcionarán para su posterior procesamiento.

Actualmente, la aplicación admite formatos de mensajes técnicos (consulte la tabla de la sección siguiente) en el procesamiento de mensajes entrantes.

Se pueden definir otras interfaces de mensajes de conformidad con el banco.

Los mensajes suelen almacenarse como archivos de texto en los subdirectorios de la partición «Datos».

Por lo tanto, los nombres de ruta relativos para definir los directorios de salida están relacionados con la partición «Datos». Si es necesario por razones organizativas, también se pueden definir nombres de ruta absolutos. Para ello, utilice el prefijo «db»: (archivos en bases de datos) también es posible. Opcionalmente, los mensajes entrantes se pueden enviar en directorios separados por entidad o en un directorio común para toda la instalación.

La transacción lleva a cabo los siguientes pasos:

1. Leer un mensaje de uno de los directorios especificados.
2. Decidir en función del subdirectorio qué formato de mensaje está disponible.
3. Si un archivo contiene más de un bloque de mensajes con su propio encabezado y pie de página, que es posible con mensajes DTA, DTE y DTG, el archivo se divide en varios archivos que contienen cada uno un bloque. El nombre del archivo se forma a partir del nombre del archivo original seguido de un número y la extensión. El archivo original se mueve al arco del directorio de archivo una vez creados los subarchivos.
4. Dividir un archivo que contiene múltiples mensajes en un mensaje en cada caso. Si el archivo contiene bloques de encabezado, cada mensaje individual va precedido de esta información, es decir, un archivo físico entrante puede tener varios remitentes. El remitente está incluido en una de las etiquetas A. Un archivo físico se divide en tantos archivos físicos como remitentes diferentes.
5. Segmentación de cada mensaje en campos individuales, según las reglas de sintaxis descritas en cada archivo TAG respectivo. El archivo TAG se almacena en la partición «Ini».
6. La combinación de mensajes divididos en varios mensajes (por ejemplo, 700 y 701), según la limitación de longitud SWIFT a un mensaje individual tan pronto como se encuentre el último mensaje de una secuencia (independientemente de la secuencia entrante). Si un mensaje SCORE contiene la etiqueta 23X con el canal FACT (FileAct), los mensajes solo se combinan cuando se han recibido todos los submensajes y el archivo referenciado en la etiqueta 23X.
7. Si no se cumplen los requisitos, se pueden acortar los mensajes SWIFT extralargos al final del mensaje. Estos mensajes truncados se envían a los clientes a través de la aplicación. Al mismo tiempo, el sistema mostrará una advertencia que indica que los datos de L/C están incompletos.
8. Si el bloque que contiene los campos no mapeados también es demasiado pequeño para el texto insertado (máx. 65 caracteres por 100 líneas), el contenido de la etiqueta respectiva se eliminará de «No mapeado». Además, se escribe un mensaje de error en «Unmapped» (No mapeado), lo que informa al usuario de que debe comprobarse el mensaje entrante.
9. Decidir sobre la transacción que se ejecutará para este mensaje, de acuerdo con las reglas establecidas en la regla «SRVSWI.DetermineMT». Porejemplo : La decisión sobre qué transacción se asignará en última instancia al directorio de entrada se toma en el módulo SRVSWI de la regla «DetermineMT()». En el caso más simple, se deriva del tipo de mensaje. Si no es obvio qué transacción se va a asociar con un tipo de mensaje, las etiquetas del mensaje se pueden usar para un análisis/identificación posterior.
   Manejo de números de referencia erróneos: El número de referencia propio (OWNREF) NUNCA se puede utilizar como destino para la cartografía. Si se encuentra un número de referencia propio en el SWM que no debe ignorarse y que no es igual al de la referencia actual, se almacena en el campo «unmapped» (no mapeado) y se mostrará un texto de error.
10. Visualización de los campos de datos en los campos de transacciones, tal y como se han definido en la asignación (véase «Mantenedor Mapeo de Mensajes Recibidos»).
11. Si el nombre del archivo es demasiado largo, el archivo se copiará como archivo con un nombre máximo de archivo. 28 caracteres. El encabezado incluye una marca de tiempo.
12. Generar una entrada «SMH - Structured Message Header» para el mensaje (conjunto SMH).
13. Impresión (si se especifica correctamente) de una copia formateada y/o no procesada del mensaje en la impresora exactamente especificada.
14. Generar una entrada en la lista de tareas pendientes.
15. Mover el archivo (si no se ha producido ningún error) al subdirectorio «arco» (por ejemplo, «swtin/arc») de la partición; de lo contrario, en el subdirectorio «error» de la partición.
    Nota: Un archivo puede contener más de un mensaje. Si se produce un error durante el procesamiento del contenido del mensaje, pero según sea el caso, otros mensajes ya se han procesado correctamente en este archivo, el archivo se moverá (y/o copiará) a «arco» (para archivar los mensajes procesados correctamente) así como a «error» (para los mensajes procesados sin éxito).

Al utilizar los switches -I <Nombre del archivo ini> en la línea de comandos del sistema de procesamiento, se pueden iniciar varias instancias de esta transacción (por ejemplo, una que inicie SWIFT desde las 8 a.m. hasta las 6 p.m. cada 10 minutos y otra instancia para los mensajes TradeConnect, que solo se iniciará una vez al día).

Para los tipos de mensaje SWIFT XML, también llamado SWIFT MX, (por ejemplo, mensajes de pago ISO20022 CBPR+ XML), se ha introducido el nuevo servicio SRVSXI. Este servicio se utiliza para importar mensajes entrantes, por ejemplo, Mensajes de transmisión Pacs.008, Pacs.009 y Technical Ack/Nack MX (como resultado de una validación técnica si el mensaje cumple las normas de Swift MX). Por ejemplo: Los mensajes entrantes de Pacs.008 se envían al CPTSET de la transacción (similar al MT103 entrante) y los mensajes entrantes de Pacs.009 al SPTROU de la transacción (similar al MT202). El mensaje de acuse de recibo técnico no está asignado a un contrato, sino que se recibe únicamente para registrar el estado de acuse de recibo del contrato.

Para que el procesamiento de los artículos entrantes funcione correctamente, es necesario introducir una entidad predeterminada en SWITSK.INI. Esta entidad predeterminada se utiliza si no se asignó ninguna otra entidad al usuario. El acceso se realiza de la siguiente manera:

Si se puede asignar un mensaje a una operación, se utiliza la entidad de la operación.

Si no hay ningún contrato disponible:

• En caso de mensajes SWIFT, el BIC del destinatario se utiliza para identificar la entidad. Al principio, el BIC de II_BIC se convierte en un BIC de 11 caracteres, si tiene 12 caracteres. Posteriormente, se buscará una dirección con este BIC, que se especifica como «Dirección propia» (Propia) en una entidad. En caso de que haya varias direcciones con este BIC, se utilizará la dirección marcada como «Dirección primaria». La entidad se determina a partir de la dirección encontrada.

• En el caso de mensajes DTA, DTE, DTG y TradeConnect, el DTA/DTE/DTG-ID o la TID de la entidad receptora se determina a partir del contenido de la etiqueta «A2» del mensaje. Si este campo solo consta de números, su contenido se interpretará como código bancario de compensación, de lo contrario, BIC. Posteriormente, se busca una dirección con este código de compensación bancaria o con este BIC, código de compensación bancaria o TID, que se ha especificado como «Dirección propia» en una entidad. En caso de que haya varias direcciones con este BIC, se utilizará la dirección marcada como «Dirección primaria». La entidad se determina a partir de la dirección encontrada.

Si no se ha identificado ninguna entidad de este modo, se utilizará la entidad predeterminada especificada en SWITSK.INI en el apartado [Configuración] de «DefaultETY=».

Esta lógica para asignar entidades se puede personalizar para proyectos individuales dentro de la regla «SWITSK.DetermineETY».

Si hay un contrato disponible, se selecciona el grupo de usuarios del usuario responsable del contrato. En todos los demás casos, el grupo de usuarios predeterminado de la entidad seleccionada se utiliza como grupo de usuarios.

Tag 23X en los mensajes SCORE se puede utilizar para indicar que un archivo (lógicamente, esto se ve como un archivo adjunto al mensaje) - en cualquier formato - se adjunta al mensaje (que consiste en varios mensajes parciales) que se transporta fuera del servicio SWIFT FIN. Si el canal de entrega indicado en Tag 23X es SWIFT FileAct, la aplicación recopila los diferentes submensajes y el archivo adjunto. El mensaje solo aparece en la bandeja cuando se han recibido el último submensaje y el archivo adjunto.

Procedimiento técnico:

Cuando se han recibido todos los mensajes de SCORE, el proceso de recopilación comprueba si hay un registro SMX en el que los detalles del remitente, el receptor y el nombre del archivo coinciden con los contenidos en la etiqueta 23X.

• De lo contrario, este registro SMX (excluido el registro SMH) se añade junto con una referencia al mensaje de PUNTUACIÓN correspondiente para que SRVSFI pueda recopilar los mensajes cuando llegue el adjunto.
• En caso afirmativo, se introduce una referencia adicional en el registro SMX que subordina el registro SMH que identifica el adjunto al primer mensaje SCORE y crea una entrada en la bandeja (SPT).

El servicio SRVSFI procesa los mensajes recibidos a través de FILEACT. Se genera un registro SMH, con un CORTYP de 'FIL' y un tipo de mensaje de 'FILEACT', para cada archivo entrante. Además, se ejecuta una comprobación para ver si ya hay un registro SMX en el que el remitente, el destinatario y el nombre del archivo coinciden con el archivo entrante.

• De lo contrario, este registro SMX (excluido el registro SMH) se añade para que SRVSFI pueda recopilar los mensajes cuando llegue el adjunto.
• En caso afirmativo, se utiliza este registro SMX. Si se encuentra una referencia adicional a un mensaje SCORE relevante con Tag 23X (generado por SRVSWI) en el registro SMX, el registro SMH para el adjunto está subordinado al registro SMH del primer mensaje SCORE, las partes del mensaje SCORE se cotejan y procesan y se genera una entrada en la bandeja (SPT).

Los formatos de activación «Swift Alliance Access XML v2 as Trigger» y «Swift Alliance Access XML v2 PDU via MQ» admiten la recepción de archivos adjuntos FILEACT a través de mensajes XMLv2.

Swift Alliance Access XML v2 como activador

• El directorio de entrada definido espera dos archivos. El archivo XMLv2 (o data pdu) activa el procesamiento. El <body> elemento espera el nombre físico del archivo adjunto. Si este archivo no existe, el mensaje recibido se moverá al directorio de errores y se omitirá. Si existe, ambos archivos se moverán al directorio de archivos. El archivo adjunto se puede renombrar según <LogicalFileName>.

Swift Alliance Access XML v2 vía MQ

• Al utilizar este activador, el proceso de MQ recuperará los archivos PDU de datos. El archivo XMLv2 y el archivo adjunto se extraerán de los archivos PDU de datos. Los siguientes pasos del procesamiento son idénticos al escenario «Swift Alliance Access XML v2 as Trigger».

Los mensajes de correo electrónico entrantes que contienen una firma pero para los que no se ha guardado ningún certificado o clave pública se pueden importar sin ningún campo.

Para ello, en el archivo «emlmod.ini» de la sección [Sistema], debe establecerse la entrada IGNSIGFLG='Y'.

Cuando se establece una marca, los errores en la verificación de la firma en elementos de varias partes/firmas se ignoran: el resultado de verificación negativo solo se registra en el texto sin procesar extraído.

Los gerentes que se ejecutan en el modo de primer plano siempre deben iniciarse manualmente.

Para algunos tipos de mensajes entrantes, es posible enviar un correo electrónico de notificación a un destinatario especificado. Este correo electrónico contendrá un enlace para que se inicie la transacción correcta para el mensaje recibido.

Si se marca «Enviar correo electrónico», se generará un correo electrónico de notificación.
El método de envío puede ser:

• Específico del cliente (se requiere una programación específica del cliente)
• Directorio de recogida ( Copiar correo electrónico a este directorio. El archivo se recogerá del software fuera de DNG )
• SMTP (Enviar correo electrónico por SMTP )
• Sendmail de Unix( send mail con sendmail de Unix )

En el directorio de recogida se generarán archivos de correo electrónico.

En el bloque SMTP, debe especificar la configuración SMTP.

Para el sistema Windows, normalmente se debe comprobar Convert Lineend (Convertir final de línea) a 0D0A.

El comando debe ser una URL del cliente HTML5 DNG con servidor y puerto.

Campos para el correo electrónico:

• E-mail
• Correo electrónico
• Asunto:
• Texto de E-Mail

El texto del correo electrónico debe contener la etiqueta <URL>. Esta etiqueta se sustituirá por el comando, se ampliará con un SPT.INR y un nombre de transacción. Cuando el destinatario del correo electrónico hace clic en esta URL, se inicia el cliente HTML5 y, después de iniciar sesión, se encadena directamente a la transacción para el mensaje entrante.

SWITSK tiene la posibilidad de recuperar correos electrónicos del buzón remoto a través de la interfaz POP3/IMAP estándar.
Actualmente, esta función está habilitada para los tipos de mensajes de SmartForms y EasySend. Para activarlo, marque la casilla Usar buzón.
Cuando esté activado, se comprobará si el buzón de correo electrónico contiene nuevos correos durante la actualización periódica de SWITSK.

Puede encontrar los ajustes de conexión en el botón E-mail Settings(Ajustes de correo electrónico). Una vez hecho clic en , aparecerá la siguiente ventana emergente con la configuración de cliente de correo estándar:

Las siguientes descripciones se aplican a todos los paneles de configuración para los formatos de mensaje.

Gestor para Mensajes Recibidos
SWIFT recibido
TradeConnect
Telex
DTA Import L/C
DTA Export L/C
DTA Guarantees
Email
Bolero
SWIFT FileAct + XMLv2
allNETT
allNETT STT
SmartForms
Envío Fácil
Doctos. Compra Deudas por Cob.
Bolero
RIVO
RIVO STT

Este es el panel principal que muestra todos los 'Mensajes entrantes' que están disponibles en sus respectivos directorios de destino. Se proporciona al usuario los criterios de selección para seleccionar los tipos de servicio/mensaje requeridos que se van a enumerar y los mensajes entrantes se muestran para los tipos de servicio seleccionados.

Este es el panel de configuración para los mensajes SWIFT y SCORE entrantes. La opción está disponible para especificar los directorios de destino entrantes para los mensajes SWIFT y SCORE, junto con la extensión de archivo necesaria para esos archivos de mensaje. Además, el usuario también puede configurar la Configuración de impresión y activar el hash de autenticación local proporcionando sus datos clave.

Este panel de configuración es para los mensajes TradeConnect para TCWEB. La opción está disponible para especificar los directorios de destino entrantes para los mensajes de TradeConnect, junto con la extensión de archivo necesaria para esos archivos de mensaje. La estructura de datos se combina con DTA para mensajes LC y DTG para mensajes de garantía. Además, el usuario también puede configurar la Configuración de impresión y activar el hash de autenticación local proporcionando sus datos clave.

Este panel de configuración es para los mensajes Telex entrantes (mensaje de comunicación electrónica, que se utilizaba ampliamente antes de SWIFT). La opción está disponible para especificar los directorios de destino entrantes para los mensajes Telex, junto con la extensión de archivo necesaria para esos archivos de mensaje. Además, el usuario puede configurar la impresora.

Este es el panel de configuración para el mensaje de DTA entrante para LC de importación. La opción está disponible para especificar los directorios de destino entrantes para los mensajes LC de importación DTA, junto con la extensión de archivo necesaria para esos archivos de mensaje. Además, el usuario también puede configurar la Configuración de impresión y activar el hash de autenticación local proporcionando sus datos clave.

Este es el panel de configuración para el mensaje de DTA entrante para la LC de exportación. La opción está disponible para especificar los directorios de destino entrantes para los mensajes LC de exportación DTA, junto con la extensión de archivo necesaria para esos archivos de mensaje. Además, el usuario también puede configurar la Configuración de impresión y activar el hash de autenticación local proporcionando sus datos clave.

Este es el panel de configuración para el mensaje de DTA entrante (DTG) para los mensajes de Garantía. La opción está disponible para especificar los directorios de destino entrantes para los mensajes de Garantía DTA, junto con la extensión de archivo requerida para esos archivos de mensaje. Además, el usuario también puede configurar la Configuración de impresión y activar el hash de autenticación local proporcionando sus datos clave.

Para obtener más información sobre la configuración del terminal Bolero, consulte Configuración de mensajes entrantes . La opción está disponible para especificar los directorios de destino entrantes para los mensajes de Bolero, junto con la extensión de archivo necesaria para esos archivos de mensaje. El usuario podría especificar el OWN RID/BIC del banco para recibir estos mensajes entrantes de Bolero. Además, se puede especificar el tipo de formato de impresión.

Este panel de configuración permite al usuario definir el formato de activación para los mensajes SWIFT Fileact entrantes. El formato XML se envuelve como un encabezado en el mensaje. El cuerpo de MT de dichos mensajes se envía internamente al servicio SWIFT entrante y se procesa en él. La opción también está disponible para especificar los directorios de destino entrantes para los mensajes Fileact, junto con la extensión de archivo necesaria para esos archivos de mensaje.

En el panel de configuración de allNETT, el usuario puede elegir el tipo de formato de impresión. La opción está disponible para seleccionar el procesamiento automático de los mensajes allNETT entrantes y también está disponible para especificar los directorios de destino entrantes junto con la extensión de archivo requerida para esos archivos de mensajes. El tipo/formato de mensaje es un estándar XSD interno patentado.

Para obtener más información sobre este tipo de mensaje, consulte "SmartForm" . La opción está disponible para elegir el formato del tipo de mensaje entrante para los formularios inteligentes entrantes. El formato/tipo más utilizado es 'PDF'. También está disponible la opción de especificar los directorios de destino entrantes junto con la extensión de archivo necesaria para esos archivos de mensajes. Dado que el PDF podría contener contraseñas, también podrían almacenarse para facilitar la importación de los archivos entrantes.

«EasySend» proporciona una plataforma sin código para transformar cualquier proceso basado en papeleo en un proceso digitalizado receptivo. La plataforma proporciona al usuario final formularios web personalizados que luego se convierten en PDF (también se admite la firma manual) y se envían a DOKA-NG. El contenido del formulario es entonces mapeado por esta transacción 'Manager of Incoming Messages (SWITSK)' en la transacción comercial relacionada y el PDF se adjunta como prueba.

La opción está disponible para elegir el formato del tipo de mensaje entrante para el mensaje recibido. El formato/tipo más utilizado es 'PDF'. También está disponible la opción de especificar los directorios de destino entrantes junto con la extensión de archivo necesaria para esos archivos de mensajes. Dado que el PDF podría contener contraseñas, también podrían almacenarse para facilitar la importación de los archivos entrantes.

Para obtener más información sobre este módulo de negocios, consulte APF. La opción está disponible para especificar los directorios de destino entrantes para los mensajes entrantes, junto con la extensión de archivo necesaria para esos archivos de mensaje.