Creating Correspondence Requests

You want to create a correspondence request. When you do, the correspondence tool generates a correspondence container for each correspondence recipient. Each correspondence container saves references to correspondence data in an abstract form and the control parameters for creating correspondence.

Prerequisites

You clarified what data is needed for creating correspondence and which references and data you want to be stored in the correspondence container.

You created application-specific events for your application, as described in Creation of Correspondence Requests.

The recipients are assigned and the system settings for the correspondence type and control parameters used for creating the correspondence are maintained.

Procedure

Calling function module FKK_WRITE_CORR with buffering type No Buffering makes it possible to create correspondence requests without reducing performance, if you create all correspondence requests within one LUW, or if you do not want them created in the case of termination, and you do not want immediate output . The buffering type No Buffering is implemented in the local class LCL_BUFFER_NULL.

When processing is successful, you close the LUW using COMMIT WORK. If processing terminated, you have to close the LUW using ROLLBACK WORK .

Sequence Diagram 1: Common Creation or Resetting of Correspondence Requests Within an LUW

This graphic is explained in the accompanying text.

Periodic correspondence is frequently created in mass runs. To improve performance, a large number of business objects are processed within an LUW. If an error occurs when an object is being processed, it has to be ensured that the correspondence requests for the successfully processed objects are retained.

This aim can be achieved by using the buffer model with instance management. The buffer model with instance management was implemented in the local class LCL_BUFFER_LUW. Using the CL_FKK_CORR_PERSISTENCE=>GET_BUFFER_HANDLER_INTERFACE class method, you can make a reference to the buffer handler available, so that it is possible to confirm or reset already created correspondence requests for an object.

If the buffer is not yet active, you have to enter the buffer mode you want again when calling the FKK_WRITE_CORR function module.

You have to close the LUW with COMMIT WORK , even if there are errors in the processing of individual objects. Using ROLLBACK WORK is advisable only in the case of serious errors, but the system then also invalidates objects that were processed successfully.

Sequence Diagram 2: Individualized Creation or Resetting of Correspondence Requests Within an LUW

This graphic is explained in the accompanying text.

When correspondence requests are created, you need to close the LUW using COMMIT WORK or ROLLBACK WORK. Doing so is the only way to ensure, when you use an application form of the form type Data Dispatch that any necessary buffer synchronization can be performed. Exceptions are possible, but result in limitations on the end user when he or she uses application forms of the form type Data Dispatch.

You need to be especially careful within display transactions due to the possible lack of a COMMIT WORK and also within the update transaction. It is not possible to use the buffer model with instance management in either of these cases.

Result

When a correspondence request is created, the system creates a correspondence container for each correspondence recipient it determines. In order for correspondence to be created, these correspondence containers need to be output. When the correspondence request is successfully created, this means that the correspondence is successfully created for the application. All subsequent processing steps are asynchronous, are responsible for successful execution, and have to allow for repetition in case of problems.

Example

Changes to business objects in dialog mode, which you want to document to the customer using correspondence, are examples for when you would create correspondence requests for a business object within an LUW. For instance, after a business object was successfully created or changed, various correspondence can be created (event-controlled correspondence). As an example: The account holder of an account changes. The old account holder can receive an account statement and be informed that he is no longer the holder of the account. The new account holder can be sent the information that he is now the account holder, along with a balance confirmation.

Periodic correspondence (such as, bank statements, invoices, dunning notices) is frequently created in mass runs. This type of correspondence provides an example of processing a large number of business objects within an LUW.

Creation of a correspondence request was implemented in report RFKKCORR_EXP_CREATE_REQUEST in the form CORR_CREATE. Depending on the report parameters, the system creates a correspondence container for an original, and if you choose, a correspondence container for a copy. The correspondence containers can only be created. Then they can be output immediately, or it is possible to create containers for a print preview.