Pre-paid – electronic transactions in WEBCON BPS

Applies to version: 2020.3.x and above; author: Agnieszka Burda



The following article is an extension of the Lunchtime article – see: Lunchtime application.

The “Lunchtime” application has been enhanced with dictionary processes that allow you to pay for meals with money previously paid into your personal account.

  • [LT Account] – a dictionary that stores information about employee’s account
  • [LT Transactions] – a dictionary that stores information about carried out transactions, it is divided into four types of forms corresponding to four types of transactions which can be done on a given account:
  • Deposit – to deposit money into your account
  • Refund – to return money paid into the account
  • Payment – to pay for meals
  • Repayment – to return money for unrealized orders

Application page

The application page consists of two dashboards:

  • Lunchtime

Fig. 1. The main page of the application


  • Lunchtime administration

Fig. 2. Lunchtime administration


The first of them has been enhanced with the “Balance” section, visible in the upper right part which shows the user’s current account balance. The report with the status for the currently logged in user was created, and then the “Report Tile” element was embedded on the dashboard which presents one column from the selected report.

Fig. 3. The configuration of the Raport Tile – Account


On the “Lunchtime” dashboard, a new “My transactions” report that contains all transactions carried out on a given account was added. To the second dashboard, two dictionary reports have been added:

  • Transactions – that contains all employee’s transactions
  • Account – that contains all account created

The reports were divided into Active and Inactive views. On the “Account” report, the amounts of employees whose account balance is 0 are marked in red.

Account dictionary

From the “Lunchtime administration” level you can create new accounts using the “New” button visible on the “Account” report.

Fig. 4. The “New” button to create new accounts


After clicking the button, a new “Account” dictionary instance is opened in which the following fields are visible:

  • Employee – a person type field that downloads data from the AD related
  • Registration date – a field in the read-only mode with the current date
  • Balance – a field in the read-only mode with the current account balance
  • Active – a checkbox that informs whether an account is active or inactive

To register an account- fill out the “Employee” required field and go through the “Save” path.

Fig. 5. A new Account dictionary instance


After going through the path, a user’s account is created – this form is the level from which you can add money to them or return them (by using the “New deposit” or “New Refund” buttons).

There is no option to create a new account for an employee who already has such an account – so after going through the “Save” path, an appropriate message will be displayed.

Fig. 6. The Account dictionary


From the configuration side, the buttons are hyperlink global actions.

Fig. 7. The configuration of the “New deposit” button


The user’s login is the only passed parameter.

Fig. 8. The configuration of the hyperlink used to start an instance


Transactions dictionary

Using the “Transactions” dictionary you can change the employee’s account balance which is related to the “Account” dictionary by the user’s login. There are four types of forms: Deposit, Payment, Refund and Repayment. All form types use with the same workflow that consists of one step with one “Save” path. From the configuration side, there are three actions on the “Save” path – the first of them is the validation action that checks if a given amount is positive for each form type.

Fig. 9. The configuration of the validation action


The second action is “Change value of single field” which depending on the form type, sets a value in the “Transaction” field as negative or positive. This is due to the fact that when you pay money to an employee or for lunch – the account balance decreases, while when money is deposited or returned to the account – it increases. It is possible to use one field for this purpose for all transaction types, but it is more intuitive for users to enter a positive value for each type of transaction.


Fig. 10. The configuration of the “Change value of a single field” action


The last action is “Move a workflow (SQL)” that moves the “Account” workflow to update the amount in the “Balance” field. In the configuration window in the “Parameters” tab enter the “_Update” technical path which moves the workflow.

Fig. 11. The configuration of the “Move a workflow (SQL)” action


In the “Data” tab, an SQL query is created that adds a new value from the “Transaction” field to the current value in the “Balance” field. The employee’s account balance is increased or decreased by the specified amount.

Fig. 12. Edition of the query


The next part of the article describes the different types of transactions that can be done on your account.


An employee wants to deposit money to their pre-paid account. After creating such an account, create a transaction of depositing money by the employee. To do this, select the “New Deposit” button that allows you to create a new instance of this dictionary.

Fig. 13. Deposit – new instance


In the “Deposit” field, enter the amount transferred by an employee. The other fields are read-only mode. After going through the “Save” button, the user’s account balance will be increased by the specified amount.

The entered change is visible for employee from the main dashboard level in two places:

  • New amount is visible in the “Balance” section
  • New transaction is visible in the “Transaction” report

The administrator can also view the transaction from the level of the “Account” dictionary. The value in the “Balance” field has been updated and a new row has been added in the “Transactions” table.

Fig. 14. The account after Deposit transaction



If an employee wants to return the money (for any reason) they deposited to the pre-paid account, the “New Refund” button should be used. After selecting this button, a new instance for this dictionary is opened. In the “Refund” field they enter the amount that should be returned (the value in this field must be positive). The other fields are read-only.

Fig. 15. Refund – new instance


After going through the “Save” path, the user’s account will be updated.


There is no option to manually start an instance for this form type – it is automatically started from the “Lunchtime” workflow.

When the “Lunchtime” workflow is at the “Food choices” step, a user has the option to make an order. On the “Today’s order” list adds a new row and selects the “Pre-paid” field.

Fig. 16. Making orders with the pre-paid option


After approving the order, three action are executed at the “Final call” step (after going through the “Finish Collecting Orders” path). The first action (Change items list values type) unchecks the “Paid Up” field in the employee’s orders where there is not enough money to pay for the meal.

Fig. 17. The configuration of the action unchecking the “Pre-paid” field


The second action creates a new instance in the “Transactions” dictionary with the “Payment” form for each row with the “Pre-paid” field selected. We used the “Start a subworkflow (SQL)” action to create the payment transaction. In the “Basic” tab of the action configuration window, the appropriate process with the form type and a path, has been selected.

Fig. 18. Starting a new “Payment” transaction


In the “Data” tab, the SQL query has been created that prescribes the appropriate values from the “Today’s Order” item list where the “Pre-paid” field for the newly created transaction has been added.

Fig. 19. Starting a new “Payment” transaction


After the action is executed, the completed transaction can be seen on the user’s account. The amount in the “Balance” field has been decreased by the amount of the order placed (18 pln) and a new row has been added in the “Transactions” table.

Fig. 20. The account after the “Payment” transaction


The last action executed on this path is the change of the item list value that automatically selects orders as paid (the “Paid Up” field) if the “Pre-paid” checkbox is selected.

Fig. 21. The configuration of the action updating the “Today’s Order” list


After going through the path, the “Paid Up” column is updated. Already paid orders are marked as green. In addition, a “Debtors” list appears above the “Today’s Order” list with employees who have not paid for this meal with the total amount that should be paid for lunch.

Fig. 22. List of debtors


When employees paid for a meal, select the “Paid Up” field and save the form – the debtors will disappear from the debtors’ list.


When the money for lunch is debited from the user’s account, but for some reason the order has to be canceled (e.g. an employee has not gone to the company) – money should be returned to the user’s account. For this purpose, the last of the transaction types – “Repayment” is used.

In the “Lunchtime” process, the “Cancel” path is visible on the “Ordering” and “Awaiting Delivery” steps. The action of creating the “Repayment” transaction has been created in both places.

To create the repayment transaction, the action of starting subworkflows (SQL) has been used – in the configuration of the action, fields about the process, form type and transition type have been completed in the “Basic” tab.

Fig. 23. The configuration of the repayment starting


In the “Data” tab there is the SQL query that describes the appropriate fields from the “Today’s Order” item list to the fields in newly created transaction.

Fig. 24. The SQL query used to start repayment


After executing the action, the money will be returned to the users’ accounts and the next row will appear in the “Transactions table.

Fig. 25. Account after repayments



Extending the “Lunchtime” app with the pre-paid function is a good solution for people who want to avoid paying for the delivered food every time. It is also a great convenience for the person who manages such a workflow.

The pre-paid solution can also be applied to other workflows in the company. Wherever there is an employee’s account and some form of regular deposits – the traditional way of paying can be replaced with a pre-paid. The user will be able to charge their account once every so often and deplete their pre-paid pool over an extended period of time – reducing hassle and the need to carry cash.

Leave a Reply

Your email address will not be published. Required fields are marked *