find what you are looking for or ask a new question


Download Available only for registered users

Works with latest WEBCON BPS version


Advances is an application used to support the process of issuing and settling advance payments for employees.


A request for an advance is registered by an employee, it is then evaluated by their direct superior, and by a member of the accounting department after that. Once the request receives both approvals and the advance payment is issued, it is then settled and must again be approved by the supervisor and accounting department.

All actors of the workflow can communicate with one-another via the comment box, which is available on every step of the workflow.


Processes & workflows

The Advances applications is built from two processes:

  • Dictionary, which contains one dictionary workflow: Groups – used for designating a list of people in the financial/accounting department who will approve and settle the advance payments. The list of active users can be updated (Update button), or can be made inactive. The workflow must contain one and only one active group.
  • Advances – contains the main workflow, whose steps represent the stages necessary to obtain and then settle an advance. The direct superior (Supervisor) is selected based on the organization structure of the company (e.g. AD or AAD). For the accounting approval steps, one member of the accounting/financial group defined in the dictionary workflow is sufficient to complete the task


Main workflow diagram



Actors & roles

Employee – registers a request for an advance payment, and lists the expected expenses. Later on, they enter info about the actual costs they incurred [Settlement of the advance].

Supervisor – evaluates and approves the advance request [Supervisor approval] and later verifies the settlement of the payment [Supervisor verification]. By default, the supervisor is defined based on the company structure – most often found in the AD or AAD.

Accountant group – is a person or group of people, whos task is to approve the advance request, and later to verify the settlement of the payment. The accounting team is defined using a workflow in the dictionary process. The task is considered complete as long as one person of the group completes it.


Analyses & Reports

Once the Advances application is imported, a dedicated application site will be available for it on WEBCON BPS Portal. This site will include the necessary buttons for starting the aforementioned processes: New Advance to start a new advance payment request and Add Group to create a new accounting group in the dictionary.

The application also comes with a set of reports to help you manage it – these are also available on Portal once you import the application.

  • [Dictionary] Groups – list of accounting teams that can evaluate and approve advances,
  • [All Advances] – lists all advances in the process,
  • [All Advances (by step)] – lists all advances in the processgrouped by step,
  • [Settlement details]– Information about advances that are currently being settled (Accounting & Supervisor verification steps) or have already been settled [Done (Settled)].


The application also comes with dashboards. The first – System Dashboard – contains start buttons and suggested reports. The list is populated based on user activity – most used will be prioritized.

The Advances dashboard is as compilation of available system elements – buttons, reports, task counters (in the context of the current application). Feel free to modify this dashboard to fit your taste, you can even set it as the default page of the application.


FAQ & additional tidbits

To what extent can this application be modified?
The primary goal of all starter applications is to serve as inspiration for your own custom solutions. In WEBCON BPS Designer Studio you are able to modify all forms and their fields, as well as add or remove steps from the workflow. The graphical layout of buttons, available reports, and dashboards can all be modified can also be modified from the end-user interface, by switching Portal into edit mode.

How to create an accounting team responsible for evaluating and settling advances?
The team is saved as a workflow instance (i.e. record) in the Dictionary process. To add a group, launch the dictionary workflow and designate a person (or multiple people) that will be responsible for the accounting tasks in the workflow. It is extremely important to remember that only one group can be active at one time –there are multiple actions defined on the workflow paths to ensure this.

How to change the members of an active accounting group?
Open the Dictionary Groups report, and then the current accounting group. Enter edit mode on the workflow instance using the ‘Edit’ button on the ribbon, enter any necessary changes, then use the path button ‘Update’.

How are tasks assigned to the active accounting group?
Paths that lead to steps where the main actors are members of the accounting team will have actions defined on them. These actions are Create task type actions. The action is based on a template to quickly replicate it on other paths, the template is called: Task assign - Members of the accounting group. In the template configuration, a SQL rule searches the dictionary for an active group. Only one of the assigned people needs to complete the task – the instance will then move to the next step.

What if there is no active accounting group?
Paths that lead to steps where the main actors are members of the accounting team will have actions defined on them. These are Validate form type actions. They check if an active accounting group exists – if not, the user will receive a message about missing configuration.

How is the requested amount juxtaposed with the actual cost on the form?
The difference is calculated using a form rule: [Calculate difference (Requested - (Settled amount))], that is triggered to activate when the value of the Settled amount form field is changed (i.e. on value change rule activation).

The format of the difference (if greater than zero – bold orange text, if equal to zero – green text) is controlled using a form rule defined on the form field itself in the Style and behavior tab of the configuration. This form rule is saved as a process form rule.