Para comprender la forma en que se imprime la aplicación, es importante definir una serie de conceptos.
Un mensaje puede ser una carta o un mensaje electrónico. Un mensaje se basa siempre en un documento de texto existente al que se hace referencia mediante un registro correspondiente en la tabla SMH. Están disponibles los siguientes tipos de mensajes.
Un mensaje principal es un documento de texto, que se define en una transacción o en un módulo. Activa la creación inicial del mensaje. Un mensaje primario se guarda como documento de texto con un registro adjunto en la tabla SMH.
Se crea un mensaje secundario para reenviar un mensaje primario debido a las instrucciones de envío o haciendo clic en el botón [Copiar a] o [Enviar a] en el panel de detalles del mensaje. Si el medio del mensaje secundario lo permite (es decir, es una carta o permite adjuntos) se crea una portada con un enlace interno al mensaje principal. De lo contrario, el mensaje secundario se creará transformando el contenido del mensaje primario en un formato apropiado para el medio seleccionado (por ejemplo, un SWIFT MT 799). Cuando se guarda un mensaje secundario, se crea un registro en la tabla SMH que contiene un enlace a SMH del mensaje primario. La portada puede suprimirse. En este caso, solo se utiliza la referencia al mensaje principal.
Un documento adicional creado manualmente haciendo clic en el botón [ Add New] (Añadir nuevo) en el panel «attachment» (Adjunto).
Un archivo adjunto, creado manualmente al adjuntar un documento/archivo existente a un documento de nivel superior utilizando las funciones del panel «Attachment» (Adjunto) o creado automáticamente por la aplicación.
Este es el formato en el que se crea técnicamente el mensaje (por ejemplo, XML, SFT o TCO). Las transacciones pueden contener reglas para cada mensaje principal que cree el formato respectivo. Sin embargo, también es posible convertir automáticamente entre dos formatos (por ejemplo, el contenido de una carta puede convertirse en un mensaje SWIFT del tipo MT799 o MT999). Normalmente, un formato técnico se adjunta permanentemente a un canal de transmisión técnica («Carta» para publicar, mensaje «SWIFT» para SWIFT, etc.).
Un formulario técnico (TEF) describe el tipo de papel utilizado para imprimir (por ejemplo, papel de escritura con membrete preimpreso [LTR], papel en blanco [BLK] o papel de seguridad [SEC]). El formulario técnico determina la impresora que se utilizará y la bandeja para la impresión. Las bandejas contienen los distintos tipos de papel.
Un formulario de solicitud es una forma lógica en la que se imprime un mensaje. Los formularios de solicitud «Original» y «Copia del cliente» siempre están disponibles. Estos dos formularios de solicitud y cualquier otro posible formulario se guardan junto con sus textos largos en la tabla de códigos APFTYP.
Un conjunto de formularios define el número de mensajes que se imprimirán en cada formulario de solicitud. En un conjunto de formularios es posible definir qué formulario técnico (tipo de papel) se debe utilizar y cuántas copias se deben imprimir para cada formulario de solicitud.
Los tres primeros dígitos de una tecla de seis dígitos de un conjunto de formularios definen la clase del formulario. Las clases de forma posibles constan de dos grupos:
Las posibles clases de formulario para los documentos en papel determinan las categorías de los papeles (por ejemplo, carta general , documento de garantía, nota interna). Los valores posibles se determinarán específicamente para cada instalación (tabla de códigos integrada en el campo MLI:APFCLA).
También existe una clase de formulario para cada medio electrónico (SWIFT, Telex, FAX, Correo electrónico).
Los juegos de formularios se crean/mantienen con la transacción «Mantenedor Set Formularios» (DBIAPF) y tienen una clave de seis dígitos (COD). Los tres primeros dígitos determinan la clase del formulario (categoría de papel) y los tres dígitos restantes determinan el conjunto del formulario (número de impresiones) dentro de la clase del formulario.
Los valores de un formulario de solicitud dentro de un conjunto de formularios se definen en una línea en APF. Todas las líneas en APF con códigos coincidentes dan como resultado el conjunto de formularios.
La tabla APF contiene:
Dentro de la transacción comercial, se determinará un conjunto de formularios adecuado para la clase del formulario para cada mensaje. En el caso de los documentos en papel, la clase del formulario viene determinada por la transacción comercial. Si se utiliza un medio de transporte electrónico (p. ej., SWIFT, Telex, …), el medio determina la clase de la forma. Ejemplo: dentro de SWIFT, no se puede imprimir «Original», porque el documento original se envía por SWIFT. El sistema predeterminará automáticamente el formulario establecido con el código léxico más bajo de la clase de formulario (normalmente <Form Class>+'001'). Si existen varios conjuntos de formularios para la clase de formulario, el usuario puede seleccionar uno de ellos.
Si la definición del conjunto de formularios lo permite, el número de copias de algunos o de todos los formularios de solicitud del conjunto de formularios para un mensaje se puede modificar de forma interactiva.
Para Mensajes Secundarios, el conjunto de formularios define el número de copias de la portada (que se muestra en la primera columna) y si el tipo de reenvío es 'Copiar a:' los números respectivos del documento reenviado (en la segunda columna) si el medio en sí está en formato de carta (es decir, se imprime y transporta físicamente en papel). No se puede solicitar aquí la impresión de los «Originales» del mensaje principal reenviado.
Para mensajes secundarios que se reenvían como 'Enviar a:' la segunda columna con el número de copias del documento (es decir, mensaje principal) muestra los números respectivos del mensaje principal (incluido el número de originales).
Si se suprime la portada, solo se puede introducir el número de copias que se van a imprimir para el documento reenviado (en la segunda columna). En este caso, no se genera ni imprime ninguna portada y el icono de la lista de mensajes está desactivado (ya que el mensaje reenviado solo se puede mostrar en su posición original en la cuadrícula).
Los archivos adjuntos (y, en realidad, cualquier documento) solo se pueden imprimir automáticamente si la aplicación tiene un componente que sabe cómo formatear este tipo de documento. Por este motivo, los archivos adjuntos genéricos (como los documentos adjuntos mediante la función de arrastrar y soltar) no se pueden imprimir, ya que la aplicación desconoce su estructura interna. Para dichos documentos (donde el medio es «Archivo»), el número de copias debe ser «0» para todos los formularios de solicitud.
Cuando se trata de la impresión interactiva de documentos/informes mostrados, siempre se utiliza el sistema de impresión del cliente (Impresión del lado del cliente). Las impresoras disponibles se pueden seleccionar mediante el sistema operativo (p. ej., Diálogo de impresión de Windows). Una impresora predeterminada concreta para la aplicación no está disponible. Si se requieren otras impresiones de impresoras que no están conectadas directamente (por ejemplo, para sucursales o asociados), la función Remote Client Printing, descrita en la documentación del desarrollador, puede permitir que estos sistemas externos configuren sus propias impresoras.
Para imprimir un conjunto de formularios para un documento, tanto la impresora como la bandeja deben definirse para cada formulario técnico (tipo de papel) utilizado en el conjunto de formularios. Esto garantiza que la impresión esté cerca del usuario responsable del procesamiento posterior y en el tipo de papel adecuado. El mismo principio se aplica también a la impresión de mensajes entrantes. Sin embargo, en este caso solo se especifica un formulario técnico (es decir, no hay conjuntos de formularios con múltiples formularios).
Para definir una impresora dependiente del usuario para cada formulario técnico (tipo de papel), las impresoras y las bandejas se pueden especificar en los siguientes niveles:
Los diferentes editores de perfiles configuran los detalles para los usuarios (“ transacciónMantenedor Perfil de UsuariosDBIUSR”), grupos de usuarios (“ transacciónMantenedor Grupo de Usuarios DBIUSG”) y entidades (“ transacciónMantenedor EntidadesDBIETY”) y para los detalles predeterminados se configuran en «Administrador de Tareas» MGRTSK en el panel para el servicio. Hay espacio en esta pantalla para definir cualquier nivel de seguimiento (USR → USG → ETY) usado en la configuración. Si no hay entrada, la búsqueda continuará en el siguiente nivel superior (siguiente).
En el panel de impresión de cada formulario técnico, las especificaciones pueden determinar
En instalaciones cliente/servidor, la impresión controlada por el flujo de trabajo permite a los usuarios determinar si se debe utilizar el sistema de impresión para la interfaz de usuario (también llamado «impresión del lado del cliente») o el sistema de impresión para el servidor de la aplicación (también llamado «impresión del lado del servidor»). La selección de la impresora depende de esta elección.
Además, se aplica lo siguiente a los servidores de aplicaciones que se ejecutan en un sistema operativo Unix:
La transacción «Sistema de Prueba Impresión» (SYSPRT) se puede utilizar para verificar si la configuración de la impresora funciona según lo previsto.
Se pueden imprimir varios formularios de solicitud para una transacción comercial completada en varios momentos del flujo de trabajo. Esto se puede lograr de la siguiente manera.
Se pueden procesar varias instancias de los servicios de impresión (SRVPRT, SRVPRR, SRVPRS) en el gestor de flujo de trabajo. Todas las instancias de impresión se configuran en un panel de configuración común. Por ejemplo, si SRVPRT es procesado por la orden de servicio sin condición, pero SRVPRS solo debe ejecutarse después del servicio de compromiso de SRVCOM mientras que al mismo tiempo el formulario de solicitud 'COP'y se procesa en SRVPRT, pero el 'ORI'ginal se imprime en SRVPRS, la copia impresa estará disponible lo antes posible (por ejemplo, tiempo de liberación). Sin embargo, el original solo se imprimirá cuando la transacción ya no pueda revertirse (especialmente después de la liberación).
La impresión gestionada por el administrador de fondo se procesa de forma aleatoria, es decir, no se imprimen consecutivamente todos los documentos pertenecientes a una transacción. Para facilitar la asignación después de la impresión, 'Printcontext1' se rellena automáticamente con el nombre del trabajo de impresión (= TRNINR+número secuencial del documento para este TRN). La impresión de este número, por ejemplo, en un pequeño tamaño de fuente en el pie de página del margen izquierdo o derecho, permite determinar qué documento pertenece a cada transacción. Para ello, el pie de página del documento debe adaptarse en consecuencia.
Si los documentos deben imprimirse para el Grupo A, pero no para el Grupo B (por ejemplo, impresión automática de mensajes entrantes), el siguiente truco puede ser útil: configurar un nuevo formulario que se utilice para imprimir y una nueva impresora «CERO».
Para el Grupo A, el formulario se imprime en una impresora normal, para el Grupo B se utiliza la impresora «CERO».
El script de impresión se adapta de tal manera que no se genere ninguna impresión para la impresora «CERO».