Firstly, it is important to stress that forms correspond to a tool with the capacity to either consult data or manipulate existing data.

In result, forms are created and related between themselves, these forms permit users to fill a number of imput fields that are important for the correct application operation.

A form example in the current application can be the one referring to non-working days.

Clients are asked for a date or a description to look-up for non-working days in the calendar.

Once the date has been facilitated, the form displays a calendar and a list where the non-working days after the date input are shown.

To introduce data in the forms; some fields such as: date and description are able to be modified, after the modification, the register will be recorded into the database by clicking in the "+" sign on the right-upper corner (as it can be seen in the image).

If at some point, the data introduced is not correct, one can modify and save it in the same record as it was previously introduced by clicking in the disk button placed at the right side of the "+" button.

Moreover, it is possible to move between registers by clicking in the arrows that are on the options bar, delete register by clicking in the trash button or make a new blank register by clicking at the sheet icon.

However, in the case of CEB, most forms correspond to transactional forms, which are the ones that manage information related with other forms and also have a query before accessing to them that is able to filter the data existing according to user's interest. In the previous case (non-working dates) the data was isolated from the rest of the application. In contrast, the form that controls the bank's information is already coupled with the branches of the same bank.

In this example, the relation between the two objects is explicit, but in some others the link between them can be done behind the client window. Anyway, from client's perspective this is not important as the application will make the linking work no matter if it is shown explicitly or not. Concretely, the data addition follows the same method as explained in the previous section.

In the current application, the main form corresponds to the transaction's one. The running principles of this form are conditional (due to the pay types and modes), thus, it is important to understand how the data input is made.

The conditional casuistry is explained in the following schema (the information between brackets correspond to the fields required in that case):

• Pay type
  • Bill (account number, area code)
    • Bulk
    • Ordinary
  • Pay in advance (PIV number, cost center, category)

• Pay mode
  • Cash
  • Cheque (Cheque number, bank code, branch code)
  • Bank Draft (Money order number, bank code, branch code)
  • Money Order
  • Credit Card

Apart from the fields that are conditional, in one hand, there are some other fields that are always required as the date, the amount and the total. In the other hand, the rest of the inputs are not required, but can be introduced if the client considers them to be relevant.

Sometimes, the users may need a form's printing to obtain a report. For that reason, a printing template has been created to display the data efficiently. To access to the pdf document the user must click on the printing icon that is situated at the right-upper corner.

After selecting a concrete transaction, by clicking in the printing button, the client will be asked to "download", "print" or "preview". Depending on user's interest, the different options can be choosed and executed by the system.

In case that the user do not have a printer associated, the preview option can be selected and then print the document from that preview window.