Documentation - DOKA-NG (Functional availability is per selected plan)

Si un contrato (por ejemplo, una L/C Importación) debe modificarse de forma perjudicial para el beneficiario; de lo contrario, el beneficiario tiene que aceptar dicha modificación; de lo contrario, no será efectiva. Estos tipos de enmienda son, por ejemplo, reducciones de cantidad y vencimiento o cambios en la descripción de los bienes, que describen una mejor calidad o inspecciones más estrictas/adicionales. Por lo general, el banco extranjero reenvía la solicitud de modificación al beneficiario, pero no tiene que asegurarse de que se deba devolver un acuse de recibo. Normalmente, el beneficiario ha coordinado previamente la modificación con el importador y, por lo tanto, no es necesario que envíe de nuevo un acuse de recibo, de modo que normalmente no se devuelve ningún acuse de recibo. De acuerdo con las normas vigentes actualmente y para este tipo de reconocimientos de modificaciones, no se establecen plazos, por lo que normalmente con la siguiente presentación de los documentos se puede identificar una aceptación implícita de la modificación.

Para complicar estas circunstancias, se pueden enviar solicitudes de modificación adicionales después de que se confirme una solicitud de modificación, pero antes de que se haya recibido la confirmación explícita o implícita de la otra parte.

Un gran reto en la gestión de dicha modificación es que el contrato subyacente no se puede cambiar sin haber recibido la confirmación. Por lo tanto, en cada modificación adicional del contrato, los empleados bancarios deben ser informados de que, por ejemplo, hay solicitudes de modificación no confirmadas disponibles.

Dentro del alcance de una solicitud de modificación, la información entrante se puede subdividir en dos áreas principales. Por un lado, hay información que se puede asignar directamente a determinados campos y, por otro lado, hay información procesable automáticamente, por ejemplo, cambios de importe o nuevos vencimientos. Esta información se transporta a través de SWIFT a etiquetas de campo separadas y, por lo tanto, se puede procesar automáticamente. De lo contrario, hay información de texto libre no estructurada que, por ejemplo, describe en texto sin formato en una etiqueta de campo SWIFT cómo se debe modificar el contrato. Esta información de texto libre puede contener datos arbitrarios (por ejemplo, especificaciones para sustituir párrafos específicos en la descripción de la mercancía o condiciones adicionales). En los contratos a la espera de confirmación, la forma de implementar esta información de texto libre es un problema que no se puede resolver, ya que el contrato básico, en el que se van a implementar los textos, no se puede identificar claramente.

Para lograr una representación formalmente correcta en una situación de este tipo y que también se pueda gestionar sin problemas en caso de rechazo, se implementan las siguientes soluciones en la aplicación:

1. Las enmiendas que no requieren confirmación de la otra parte y que se reciben cuando no se espera confirmación, se procesan en las transacciones de enmienda (xxxtransacciones AME). El monto respectivo, la responsabilidad y los cambios de texto se realizan dentro de la operación y el nuevo estado se almacena instantáneamente.

2. Las enmiendas que requieren confirmación o cambios normales, que deben procesarse, si se espera una confirmación de la otra parte, se procesan a través de la solicitud de transacciones de enmienda (xxxRAM transacciones), que registran una transacción xxxAME respectiva.

3. En cada modificación adicional de una operación que está esperando una confirmación de la otra parte (cuando una transacción xxxRAM aún no cerrada todavía está pendiente), se notifica al usuario que hay una solicitud de modificación no confirmada a mano.

4. Si, por ejemplo, la confirmación implícita o el rechazo son identificables a la presentación de los documentos, el empleado puede procesar rápidamente la modificación real con antelación mediante la recepción de la transacción xxxAME pendiente o puede notificar a la otra parte sobre el rechazo de la solicitud de modificación a través de un mensaje común. A continuación, se procesa la transacción actual (en este caso, la presentación de los documentos).

4.1. En caso de confirmación, los campos de datos estructurados y el texto libre no estructurado de la solicitud de modificación original se insertan en los campos correspondientes de la transacción xxxAME. De este modo, la información estructurada de la modificación se almacena automáticamente en los respectivos campos de destino. La distribución de la información de texto libre (cuando sea necesario) a los campos de texto respectivos para la descripción de mercancías, los documentos, etc. no se procesa hasta ahora cuando se gestiona la transacción xxxAME, ya que ahora el estado subyacente es claramente claro.

4.2. En caso de rechazo, debe gestionarse una transacción de mensaje común (xxxFRE) en lugar de la transacción xxxAME registrada. Esto se puede hacer redireccionando el registro a xxxFRE y tomando posteriormente el registro o iniciando manualmente la transacción xxxFRE y borrando el registro manualmente.

4.3. Cuando se reciba un mensaje entrante del beneficiario advirtiendo de su aceptación/rechazo, dicho mensaje podrá ser redirigido en SPTROU a xxTFRE (en caso de rechazo) o a xxTATT (en caso de aceptación), para almacenar el mensaje recibido. En caso de aceptación, el usuario puede recoger la transacción xxTAME registrada para procesar la modificación. En caso de rechazo, tome el xxTFRE reenviado para procesar el mensaje común y eliminar la xxTAME autoregistrada. Cuando se redirige a LxTFRE, el tipo de correspondencia se predetermina como «Reconocimiento» para enviar un MT730 con una etiqueta 72 predeterminada con la palabra clave /BENREJ/ o una carta equivalente con el mismo contenido.

5. En el contexto de las solicitudes de modificación enviadas en una enmienda (a través de xxxAME o xxxRAM), se puede señalar fácilmente que todavía hay mensajes de enmienda pendientes (en caso de que sea necesario en la instalación específica). Sin embargo, la operación subyacente aún no se ha almacenado, es decir, ni se modifican los campos de importes y fechas, ni se incorporan los cambios textuales deseados al contrato.

6. El resultado es que cada solicitud de modificación, incluso si se rechaza, se cuenta en la solicitud y se le asigna un número de modificación. El trabajo y la gestión de una enmienda han surgido, incluso si la solicitud de enmienda fue rechazada por la otra parte.

Esto significa que el trabajo real de incorporar una enmienda compleja en una L/C NO se realiza después de recibir la enmienda, pero la incorporación de las enmiendas (especialmente en los textos) no se realiza antes de que se hayan aceptado las enmiendas. Un efecto secundario importante de este procedimiento es que incluso si hay varias enmiendas en camino y no todas serán aceptadas pero algunas también serán rechazadas, cada enmienda individual puede ser aceptada y actualiza el contrato. También es importante que la actualización/almacenamiento del contrato sea trazable y claro. Mientras tanto, los mensajes que se hayan creado nunca contendrán números ni textos todavía no aceptados (y posiblemente rechazados posteriormente).

Sin embargo, en este caso hay que tener en cuenta que en correspondencia externa hay modificaciones pendientes, siempre que existan solicitudes xxxRAM pendientes.

Cuando una L/C Exportación existente está vinculada a una L/C Transferible o una L/C Back-to-Back, la enmienda de la L/C Maestra puede conducir a una enmienda de la L/C Transferible o L/C Back-to-Back. Esto es compatible con la aplicación mediante lo siguiente:

• Cuando se vincula a una L/C Transferida, al guardar la transacción, se almacena automáticamente Aviso Enmienda un autorregistro para la transacción si Solicitar Enmienda la transacción desencadenante bajo la L/C Exportación también fue una enmienda perjudicial (es decir, Solicitud de Enmienda).
• Si la transacción desencadenante bajo la L/C Exportación fue una LETAME (Aviso Enmienda), entonces se almacena un registro automático para la transacción Enmienda.

• Cuando se vincula a una L/C Back-To-Back, al guardar la transacción, se almacena automáticamente Aviso Enmienda un autorregistro para la transacción si Solicitud de Enmienda la transacción desencadenante bajo la L/C Exportación fue una enmienda perjudicial (es decir, Solicitud de Enmienda).
• Si la transacción desencadenante bajo la L/C Exportación fue una LETAME (Aviso Enmienda), entonces se almacena un registro automático para la transacción Enmienda.

Cualquier modificación del importe de la operación no se copia intencionadamente en la L/C Transferible ni en la L/C Back-To-Back. Al recoger el registro automático, los cambios de monto en la operación principal se enumerarán en los «campos no mapeados» y el usuario podrá copiarlos manualmente.