Serial correspondence

Applies to version: 2020.1.x and above; author: Dawid Golonka

Introduction

There are various reasons why companies implement electronic document workflow software.One of the most important is the need for business process automation. One example of such automation processes is the use of serial correspondence which generates documents based on the specific template in which the fields and values can be changed. These values can be loaded from an external data source.

Configuration

The topic will be discussed based on a business case in which you want to collect payments from contractors for unpaid invoices. For each of the contractors, a request for a payment document will be generated with information on the amount and invoice number that has not been paid.

To realize this, three processes have been created:

1. Invoice process
2. Serial correspondence process
3. Outgoing correspondence process

Fig. 1. The invoice workflow

To refer to data recorded in this workflow in other processes, you must create a BPS data source and select the newly created invoice process, specify a form type and select the “Archived” step in their configuration.

The following screenshot shows the form view at the registration step with examples of completed data. The “Contractor” field is selected from the dictionary. Sample values have been introduced without filling in the field with the date of payment for the invoice (invoice not paid).

Fig. 2. The registration of the unpaid invoice

On the form there is an “Invoices” form field where after selecting the contractor, you can see the list of all invoices issued for this contractor. To do this, you need to indicate the previously created BPS data source and narrow the results to the contractor indicated on the form.

Fig. 3. The configuration of the data table

Configuration of the serial correspondence

In the process of serial correspondence the contractors who have unpaid invoices will be selected. For each of them, a separate Outgoing correspondence subworkflow will be started, where the payment requests will be generated.

Fig. 4. The serial correspondence workflow

Below there is a screenshot showing the form view on the start step.

Fig. 5. The serial correspondence form on the start step

After selecting the contractor, you can check the value of invoices they have not paid. This value will appear in the “Value of unpaid invoices” field. You can do this by using the “Data row” form field and by creating a simple query to the BPS database – this query narrows only to results in which the “Payment date” field is empty. An example of such a query is below:

Fig. 6. A query in the data row form field

The “List of unpaid invoices” data table differs from that of the invoice process only by an additional filter. Only documents after the payment date are taken into account, where the payment field is empty.

Fig. 7. The filter in the data row form field

Knowing of which companies are in arrears with payments, you can add these companies to the “Contractors with arrears” item list. A list consists of two columns – contractor name and their debt. The contractor is selected from the dictionary and the arrears column is a data row configured in the same way as it is shown in Figure 6.

For each of the contractors on the list, you can start a subworkflow of the outgoing correspondence. On the “Register outgoing correspondence” transition path, configure the action of starting a subworkflow.

Fig. 8. The setting of the “Start a subworkflow” action on the path

The configuration of the action is described below:

Fig. 9. The configuration of the “Start a subworkflow” action

Fig. 10. The configuration of the “Start a subworkflow” action

This query refers to the table storing the data from the item lists. You indicate the contractor’s name placed on the “Contractors with arrears” item list to the “Contractor” form field in the “Outgoing correspondence” subworkflow. In the DET_WFCONID parameter, provide the item list ID from the data originates and the DET_WFDID refers to the given instance ID.

After going through the path and executing the action, the subworkflows will be created – in the number corresponding to the number of companies.

Fig. 11. The signatures of started subworkflows

The configuration of the Serial correspondence process

The Outgoing correspondence process consists of four steps. On the “Registration” step you need to enter the data where depending on the selected path, you can move to the “Waiting for scan” step or directly to the “Preparation and shipping” step. In this step the documents are generated which can be sent by e-mail – this is realized outside the workflow. After sending the correspondence, documents go to the “Archived” step.

When the workflow is started as a subworkflow of the “Serial correspondence” process, the document goes through the “Generate Word document” path directly from the “Register” step to the “Preparation and shipping” step.

Fig. 12. The Serial correspondence workflow

In the process, the form fields necessary to generate the demand for payments were created.

Fig. 13. A list of form fields use to generate the document

The name of the contractor from the “Serial correspondence” process is passed to the “Contractor” choice field. Based on them, the “List of invoices after the payment date” data table is filled in with the filter used as in Figure 7. A form field calculating the amount of debt has also the same configuration as in Figure 6.

On the “Generate Word document” transition path, the action of generating a Word document has been configured. For more information, see Storage methods of document templates.

.The prepared template along with the entered values form the process are as follows:

Fig. 14. The example prepared template

Final result

On figure 11 you can see that two subworkflows were generated for each of the companies separately. After entering to the form of one of them, the following view appears:

Fig. 15. The form view on the “Preparation and shipping” step

Documents with demand for payment are generated:

Fig. 16. A generated demand for payments (Company 1)

Fig. 17. A generated demand for payments (Company 2)