El Banco DOKA-NG emite una garantía MT760 (Propósito del mensaje como «ISSU») que le asesora a través de uno o más bancos avisadores al beneficiario. La emisión puede basarse en la recepción de un pedido electrónico entrante de la empresa (por ejemplo, SCORE o DTA) o un pedido no electrónico (basado en papel).

Cuando la solicitud de emisión se recibe electrónicamente, las etiquetas se asignan a los campos respectivos como se define en la transacción de mapeo entrante (en Mantenedor Mapeo de Mensajes Recibidos (DBISWH). El pedido electrónico entrante puede recibirse a través de Score (MT784), DTA (G01) o Bolero (429).

Cuando el «Propósito entrante» del mensaje de la empresa sea «ISSU», el «Propósito del mensaje» saliente será predeterminado como «ISSU» en la aplicación. El usuario puede seguir seleccionando otros códigos de «Objetivo del mensaje»: ISCO o ICCO proporcionan más flexibilidad al usuario. El «Tipo de manipulación» se predetermina en función del «Objetivo del mensaje» seleccionado.

Según el alcance SWIFT:

• Campo 50: Postulante -“Este campo especifica la parte nombrada en el compromiso como el postulante”.
• Campo 51: Obligador/Instructor: «Este campo especifica la parte obligada a reembolsar al emisor».

Por lo tanto, para cumplir con las expectativas de reservas de «responsabilidad» con la aplicación, existe un intercambio de roles para Tag 50 y 51 con los roles internos de las partes APL y CTR.

• La función «Solicitante» del mensaje entrante (Tag 50) se asigna a la función «CTR».
• La función «Garante» del mensaje entrante (Tag 51) se asigna a la función «APL».
• Si se establece la función CTR, la etiqueta 50 de (Aplicante) en el MT760 saliente contendrá detalles de la función CTR; de lo contrario, contendrá detalles de la función APL.
• La aplicación identifica el tipo de mensaje entrante (Score/DTA/Bolero) y marca la casilla de verificación «Pedido corporativo entrante».
• La asignación entrante de la etiqueta 52a de la secuencia B para mensajes corporativos se establece como no mapeada, ya que siempre sería el banco que emitía la garantía, es decir, Rol PROPIO. En este caso, 52a en la salida se establecerá siempre en la dirección PROPIA del banco.
• Para un pedido corporativo entrante, la casilla de verificación «Suprimir parte en SWIFT MT 760 saliente» se establece por defecto cuando se rellenan tanto el solicitante como el deudor de ambas partes. En tales casos, el tag 51 del MT760 saliente no se imprime y el tag 50 se llenará con el participante ingresado en el campo de deudor.
• Cuando se reciban instrucciones de confirmación de la empresa, la empresa podría haber sugerido un banco de confirmación (tag 58a). Esto se asigna a la función CNR (Banco Confirmador Entrante) y se almacena como información entrante. El usuario bancario tiene que decidir si seguir esta sugerencia o anular la empresa. A continuación, el usuario del banco debe añadir el participante en el campo Participante de confirmación (CON - Banco de confirmación) que, a continuación, se rellenaría en el MT760 saliente para la etiqueta 58a como Banco de confirmación solicitado.
• Para las L/C Standby, cuando se recibe «Disponible con» (Tag 41a) de la empresa, la parte se asigna a la Función AVB «Disponible con el banco». Este rol está disponible en la cuadrícula «partes adicionales».

Los mapeos de roles de la otra parte para BEN, ATB, AT2 siguen siendo los mismos.

Los roles de los participantes para los salientes siguen siendo los mismos, para una introducción manual por parte del usuario como antes de SR2021. El usuario tiene la flexibilidad de seleccionar a las partes en función del pedido entrante no electrónico. En este caso manual, la casilla de verificación «Pedido corporativo entrante» se establece automáticamente para la gestión adecuada del mensaje saliente. Para que la casilla de verificación sea más destacada para el uso y para evitar cualquier error en SWIFT MT 760 saliente, es obligatorio marcar la casilla de verificación «Orden corporativa entrante» o establecer la función «CTR» para «ISSU».

se muestra a continuación.

• Pedido corporativo entrante:
  • Esta casilla de verificación se activa cuando se recibe el mensaje de una empresa.
  • En este escenario, la recepción se basa en un pedido corporativo, por lo que la casilla de verificación está marcada.
    Esto significa que, si se establece la función CTR, CTR se rellenará en el Tag 50 de la función saliente MT 760; de lo contrario, APL.
• Receptor del mensaje saliente:
  • Si está disponible, Banco Avisador (ATB), de lo contrario, Beneficiario (BEN).

El Banco DOKA-NG emite un compromiso MT 760 (Propósito del mensaje como «ISSU») basado en un MT 760 entrante recibido del Banco Emisor del Contador solicitándole que emita su compromiso local hacia el beneficiario.

Cuando la emisión se recibe electrónicamente, las etiquetas se asignan a los campos respectivos como se define en el mapeo entrante (en la transacción DBISWH). Dado que la orden entrante es de un banco, la casilla de verificación «Orden corporativa entrante» no está marcada. El propósito saliente del mensaje será predeterminado como 'ISSU' cuando el código entrante sea ISCO. El usuario no puede seleccionar ningún otro código de «Propósito del mensaje», ya que la selección está restringida solo a ISSU. Este mensaje es reenviado por el banco emisor local directamente al Beneficiario (en caso de una relación directa) o a través de uno o más bancos avisadores. El «Tipo de manipulación» viene predeterminado según el «Objetivo del mensaje».

• El mensaje entrante contendrá tanto la Secuencia B como la Secuencia C, donde la Secuencia C incluye los detalles de la garantía local. Dado que la salida será una ISSU (solo la secuencia B con detalles de compromiso local permitidos), mapeamos las etiquetas de la secuencia C desde los paneles entrantes a los paneles de la secuencia B. En tales casos, la aplicación mapea las etiquetas de la Secuencia B que son iguales en los campos tanto de la Secuencia B como de la Secuencia C a Sin mapear.
  Por ejemplo: etiquetas como 56a,57a no tienen las etiquetas de secuencia C correspondientes, por lo tanto se asignarán al panel.
  Mientras que las etiquetas como 50,51,59, etc. tener también una etiqueta de secuencia C que luego se establecerá como no mapeada y el contenido de las etiquetas de secuencia C se asignará en la secuencia B.

• El banco emisor del mensaje Recibido se asigna al rol de parte «Solicitante / APL» para la reserva de responsabilidad. Esto sigue siendo el mismo que antes de SR2021.
• La etiqueta 50 (Aplicante) del mensaje recibido se asignará a la función 'CTR' (Contable/Obligador) y luego se rellenará con la etiqueta 50 del MT760 saliente. Por lo tanto, en caso de una ISSU saliente, la función CTR es obligatoria y se genera un mensaje de error cuando no se establece la función CTR.
• Tag 51 (Garante) si se recibe del mensaje recibido se asignará a la función 'APR' (Solicitante de Reembolso) y luego se rellenará en el Tag 51 del MT760 saliente.
• Cuando se reciben las instrucciones de confirmación, el banco de confirmación (etiqueta 58a) se asigna a la función CNR (Banco de confirmación entrante). Esto es para almacenar la información entrante; el usuario debe agregar el participante en el campo Participante de confirmación (CON - Banco de confirmación) que luego se rellenaría en el MT760 saliente para la etiqueta 58a.
• Si el código de propósito entrante del mensaje es ISCO y si el código de propósito saliente ISSU, el contenido se asigna al campo «Undertaking Text» (Texto de Garantía) (campo GIDTXT) en la Secuencia B. En todos los demás casos, el campo 77L se asigna a «Undertaking Text» (Texto de Garantía) (campo GIDTXTC) en la Secuencia C.

Los mapeos de roles de la otra parte para BEN, ATB, AT2 siguen siendo los mismos.

Los roles de los participantes para los salientes siguen siendo los mismos, para una introducción manual por parte del usuario como antes de SR2021. En este caso, la función CTR es obligatoria y el usuario debe establecer CTR para el Tag 50 en el MT 760 saliente.

se muestra a continuación.

• Receptor del mensaje: si está disponible, Banco Avisador (ATB) o Beneficiario (BEN)
• Entrante de Orden Corporativa: Este indicador no está establecido cuando se recibe el mensaje de un Banco. El CTR de rol debe establecerse cuando se recibe el mensaje de un banco. Solo entonces, el solicitante (Tag 50) en el MT 760 saliente se rellenará, por lo tanto, Doka-NG ordena llenar el CTR en este caso.