Projects:Dunning/Configuration Manual
Contents |
Introduction
Dunning is the process of methodically communicating with customers to ensure the collection of payments. Openbravo supports you in automatically handling late payments using customer-specific dunning policies and business processes.
This manual describes the configuration of the dunning module using dunning policies, work flows and dunning statuses.
The user manual of the dunning module can be found here.
Demo
The following demo gives an overview of the configuration of the dunning module:
Dunning Configuration: after module installation
Import Standard Dunning Work Flow/Policies
After installing the dunning module you need to import reference data which contains a standard dunning policy definition and standard dunning business process:
Automatically start dunning work flows
The dunning process should normally work automatically in the background. To configure this automatic process go to the process request window (through quick launch is the easiest) and setup the dunning start work flow process using a schedule fitting to your business requirements:
Note the interval (in calendar days) of the process request should be less than the value of the late time parameter (next section).
Late Time in Days Parameter
The automatic dunning process will run in an interval and is assumed to 'catch' every late payment for which a dunning policy is defined. Based on the interval it only needs to look a certain number of days in the past for checking late payments. For example if the interval is 5 days, the automatic dunning process only needs to select late payments which are maximum 5 days late, as earlier late payments were caught by the previous run. But any value for the number-of-days parameter will work fine, higher values will result in a bit slower system.
The number of days in the past, considered by the automatic process, is controlled with the lateTimeInDays preference (available from version 1.0.5 onwards). The default value is 5. This means that only payments that are 5 days late are considered by the automatic start of the work flow.
Defining a Dunning Policy
The dunning process is controlled through a dunning policy. A dunning policy defines (for a customer) how to handle late payments. It consists of 2 main parts:
- one or more dunning statuses: a payment has a dunning status depending on the late-days (how many days late the payment is), the dunning status defines extra parameters such as if an email can/should be sent or the definition of the letter to generate.
- dunning work flow/business process: when a payment is late a dunning business process is started automatically. The dunning business process computes the dunning status for a late payment and can take specific actions depending on the parameters in the dunning status
Dunning Policy
Dunning policies are defined through the dunning configuration window (General Setup > Application). The dunning policy has the following fields:
- name and description: informational fields
- work flow: the link to the business process to execute for the late payment
A dunning policy has a child tab which defines the dunning statuses of the policy.
Dunning work flow
The core of the dunning solution is the use a specific business process (work flow) to handle the late payment. The first step of the configuration of the dunning module is therefore to create a business process within Openbravo. This is described in more detail in the BPM documentation.
The dunning module is delivered with a pre-set business process. It is available in the work flow definition window (when in the System Administrator role): General Setup > Application > Work Flow Definitions.
A visualization of the standard work flow delivered with the dunning module:
The standard work flow process is described here in more detail.
When creating your own work flows you can use the following variables in the logic and conditions in the work flow:
- paymentSchedule, for example: ${paymentSchedule.outstandingAmount}, the paymentSchedule will contain the payment plan business object
- businessPartner: for example: ${businessPartner._Identifier} the business partner business object
For both of these parameters you can use the dot-notation (paymentSchedule.outstandingAmount) to refer to related information. Note: you can go maximum 2 levels deep, for example paymentSchedule.invoice._documentNo.
Dunning Status
The dunning status is an important part of the definition. It controls what type of actions the standard work flow executes when it computes a new status for a late payment.
The dunning status has these fields:
- Sequence number: used for ordering in the dunning policy, the dunning work flow will iterate over the dunning statuses in this order
- Name and description: informational, displayed in the dunning log and in the task list of the user
- Days late cumulative: calendar days, defines if the status applies for a late payment, the status with the highest applicable days late cumulative setting is used. If not set then this status is assumed to be set manually by the user
- User maintained: if flagged then this is assumed to be a user task, when this status is reached a task is created for the role defined in the next field. All users with that role will see that task and can claim it
- Role: applies if user maintained is flagged
- Final Status: if this status is reached then the dunning work flow will exit.
Letter and Email definition
Within a dunning status you can define a document template and an email definition. The email definition and document template control what the standard dunning work flow does. If the computed dunning status has an email definition then the standard business process will send an email to the user contact defined in the invoice. The reply to is set to the sales representative defined in the invoice (if there is any there). The email will have a body and a letter attached to it. The attached letter is generated on the basis of the document template.
The email definition allows you to use invoice specific information within the body of the email. For example the ${invoice.businessPartner.name} will be converted to the name of the business partner in the email body.
Note: the default dunning work flow will make use of the dunning status to control its behavior (for example send an email or not), but a dunning policy can have any work flow, and different work flows can handle/work with dunning statuses in different ways.
On hold status
Normally the dunning work flow process will continuously recompute the status and if a new status is computed will execute the appropriate actions. However, sometimes it makes sense to put a dunning process on hold, the default dunning policy has an on hold status
The following applies: an on hold status is a status without a days late value set, the default dunning business process will not change the status of a payment if the current status does not have a days late value set. It is assumed that this status is a status set manually by the user.
Linking a Dunning Policy to a Bussiness Partner
The final step of the configuration is to link a dunning policy to a business partner. So that the dunning process knows how to handle a late payment for a specific customer. A dunning policy is linked to a business partner in the customer tab of the business partner window (see in the bottom of the screenshot):
Goto the business partner window, then in the customer tab select the correct dunning policy and save the record.