Creation of input reports
Written by Bettina Schmoll
Updated at May 13th, 2025
Table of Contents
BI4-Controlling Creation of simple input reports
Table of contents
2.1. Decision-making for storage
3. Creating an input report/data table
3.1. Display rows for all master data
3.2. Show columns for empty outline areas
3.3. Application example “Recording meter readings”
4. Creating an input report / Flex.Parameter
Generally
In addition to displaying and evaluating data, the web client also offers the option of entering and then saving values.
This feature can be used for a variety of tasks. An example is a budget report where the user enters the values.
Another example is entering a comment on a value line. This could be a report that sorts all purchase invoice lines for each document.
Another option would be the convenient maintenance of exchange rates.
You can see that the application possibilities here are diverse.
Requirements
The data entered from the web can be saved in two different ways.
The first option is to store the data in a data table. This requires an extended amount type, and the data table that will store the data must contain all the dimensions included in the report's outline.
The second option is to store the data in a Flex.Parameter. This must also contain the dimensions of the report outline and a date field.
Decision-making for storage
Both storing data in a data table and storing it in Flex.Parameter have advantages and disadvantages. Therefore, before installing the system, it's important to consider what will happen to the data and which storage method makes sense.
Data table:
The advantage of storing data in a data table is that it creates values that are easy to sum. These values immediately appear when the extended amount type is queried and are seamlessly integrated into the values in the data table.
The disadvantage, however, is that only numbers can be stored meaningfully and that the elements of a structure are not displayed without the presence of a second value in the period.
Possible applications for this type of storage include budget entry, entering a distribution key for a levy, or recording a meter reading or working hours.
Flex.Parameters:
The advantage of storing data in a Flex.Parameter is the versatility it offers with regard to date usage, dimension usage, and value fields. This allows you to store not only numbers but also entire texts—even with HTML formatting.
The disadvantage, however, is that the query works via a formula in the report and, depending on the type of query, some parameters must be passed along. This can be complicated and therefore error-prone.
A possible application for this type of storage is the recording of an exchange rate, a price, a discount or a comment to an existing data record.
Creating an input report / data table
To create a simple input report, the recording of working hours per employee per day in one week was chosen for this documentation.
As a prerequisite, a data table "Working Hours" has now been created. This contains only one value field, "Hours," and, in addition to the system dimensions, the dimension for employees.
After that, it’s time to create an input report.
To do this, a new reporting schema is first created.
To enable a weekly display of the entered hours, the default date in the report schema was set to "-LW" for the start date and "+LW" for the end date. "Date" was used as the date type.
In order for the input to be used subsequently, the checkbox for “Web manual inputs” must be set in the report schema in the “Web access” section:
Next, a column schema was created that contains the extended amount type from the previously created data table twice. The first column is defined as the total column. The second column is structured according to the service date -> year-month-day, so that there is an input field for each day of the week.
So that the system knows in which column the user can now make entries, if there is an outline at column level, the check mark in the “Editable” column is set in the outline, otherwise in the row of the column.
In the column scheme, only one row, "Total," has been created, and a breakdown by employee has been placed on it. Here, too, the "Editable" checkbox must be checked in the breakdown at the level where the data is to be entered:
The result in the web client then (unfortunately) looks like this:
Neither an outline of employees in the rows nor an outline by days in the columns is displayed.
This behavior is due to the fact that there is not a single record in the newly created table.
But even if a data record existed, the system would only display an entry for the days and employees for which a data record already existed.
However, since we want to collect new data first, this solution does not seem practical at first glance.
Show rows for all master data
Since by default the row schema only displays those rows that have at least one value other than 0 in the columns, we have to use the following trick to make the system display these rows as well.
The following additions must be made to the line scheme:
In the existing row, the value “With master data” must be set in the structure in the “Master data” column.
This will now display all entries from the row structure:
Show columns for empty outline areas
We now need to use a similar trick for the columns, since here too the structure by date is only carried out if there is at least one value per date.
To do this, create another row in the row schema before the existing row. This can be designated "Dummy" and set to "Never" in the "Display" column. Then, in the row details, in the "Extra Parameters" tab, set the amount type to "Daily Entry."
This setting triggers the display of columns per day in the set period.
The result then looks like this on the web:
This completes the creation of a simple input report.
Application example “Recording meter readings”
The recording of meter readings, such as gas, water, electricity, or energy meters, can subsequently be used as a distribution key for allocating costs to individual production areas and thus to individual products. However, this requires knowledge of consumption for the respective period, usually per month.
To ensure that the user who is responsible for entering the values does not have to manually calculate the consumption on the individual meters and enter it for the respective period, there are some settings in the report definition that relieve the user of this task and they only have to enter the currently displayed meter reading.
For such an input report, we need a separate data table and a dimension containing the counter labels. This dimension must be assigned to the data table as a posting dimension.
In the report schema, a date field is sufficient for us, which has “Performance Date End” entered for the first date usage.
Furthermore, the “Web Manual Entries” field can be checked in the “Web Access” tab.
Only a simple summary row is inserted in the row scheme. The dimension containing the labels for the individual counters is inserted as a structure.
As described in previous chapters, the special feature is that all counters must be displayed. Therefore, "With Master Data" must be selected in the Master Data column. The web preview should also be set to "Expanded."
Furthermore, the check mark must be placed in the “Editable” column.
Since a total sum of the meter readings does not make sense here, the “Display” column in the totals row can be set to “Suppress total”:
The special feature, however, is hidden in the column scheme.
Here, you select the amount type of the data table into which the meter readings should be written. However, instead of the "Transaction" column type, you should use the "Balance to Date" column type.
Further, in the details of the column in the “Web Access” tab, the checkbox “Editable” must be checked and the “Edit Date Suggestion” must be changed from “Month Range” to “End Date”.
These settings ensure that the system always displays the total of all previous meter reading entries. Furthermore, overwriting the current meter reading with the current meter reading triggers a new difference entry to the previous meter reading on the set due date. This calculates and saves the consumption since the last entry on the selected due date.
In the web report, the initial value was initially recorded as 10,000 units. The value was then overwritten with 12,500 units in the following month. The values are then saved in the data table as follows, with the difference calculation clearly visible:
Creating an input report / Flex.Parameter
As an example of an input report in a Flex.Parameter, the input of an exchange rate for a specific date was chosen here.
In contrast to the previous input report, two prerequisites are necessary for a functioning input report in a Flex.Parameter:
A Flex.Parameter for storing the values and
A data table used as an exists table.
The Flex.Parameter is created for the example of the exchange rate table with a currency dimension, a start date from which the rate is valid and the value for the rate:
For the Currency dimension, "Same Code" must be entered for the dimension usage. The date usage for the service date must be "Start Date," as this is the only way the exchange rate is valid from that point in time.
This completes the creation of the Flex.Parameter.
The second requirement is a so-called exists table. This contains an entry with a value for each dimension combination.
The existing data table can have itself entered as the base data table. However, this requires all system tables to be transferred to the booking dimensions.
Likewise, the dimension combination for which the Exist table is required must be included in the posting dimensions. In our example, this is the Currency dimension.
After the data table has been created, it can be filled immediately.
If the dimension contains many elements or values that are constantly being expanded, such as the item number, it is recommended to create a separate import definition for this table. For dimensions that hardly ever change and have only a small number of entries, this effort is usually not worthwhile.
In our example, we're assuming only a limited number of currencies to convert. Therefore, let's edit the data table manually and enter the following values:
The performance and reference date with 01.01.1900, the name of the data table, 1 for the quantity and the currency code.
This completes the creation and filling of the Exist table. We can now proceed to create an input report.
When creating the reporting scheme, the following 2 points must be changed:
Since there is only one cut-off date for entering the exchange rate, one entry in the web date fields must be deleted and the second must be renamed to "Cut-off Date" in the description. Furthermore, "Service End Date" must be entered for the first date usage and "Service Start Date" for the second date usage.
The checkbox for “Web manual input” must be checked so that the input fields can subsequently be activated.
A "Total" row should be created in the row scheme. However, this row should be hidden by selecting "Suppress Total" in the "Display" column.
A currency breakdown must be created on this row. This must be set to "Expanded" in the web preview so that the report displays values again.
Also in the outline, the checkbox “Editable” must be checked:
This completes the row schema and we can now tackle the column schema.
Two columns must now be added to the column schema. The first is used to display and enter the Flex parameter.
In BI4C versions with a program version prior to January 2020, a column of the type Formula must be entered for this purpose. The formula for a simple Flex.Parameter is
FLEXPARAM('[Name of the Flex.Parameter]';'[Name of the value field in the Flex.Parameter]')
The square brackets should be replaced with the actual names or labels. In this example, the complete formula is "FLEXPARAM('EXCHANGE CONVERSION';'Rate').
In BI4C versions updated after January 2020, an amount type can also be conveniently used. The name of this type is structured as follows: "Flex. [Name of the Flex.Parameter] -> [Name of the value field in the Flex.Parameter]".
! IMPORTANT !
The approach with the amount type only works if no value keys need to be passed to the Flex.Parameter!
In this column, you must also check the box next to “Editable”.
The second column should be the extended amount type from the previously created Exist table. However, the "All" type is used here, not "Movement." This is related to the service date setting. This ensures that, regardless of the service or reference date with which a data record was entered in the data table, it is always displayed in the report.
! IMPORTANT !
A report with only a formula in the column schema won't work. It requires at least one additional column with an extended amount type!
The input report is now almost finished.
On the web, the result now looks like this:
The input fields for all currencies previously recorded in the Exist table are now present and highlighted in yellow. However, the number 1.00 behind them is still annoying. This comes from the Exist table.
However, this cannot simply be hidden, as otherwise the input fields will not be displayed.
The only option is to hide the number from the user. To do this, the background color and font color must be set to the same value, preferably white. This is done by simply entering "background-color:white;color:white" in the "Formatting Values" column of the column schema.
This completes the creation of an input report for a Flex.Parameter.
Use case comment
The procedure for entering and saving a comment is similar to the example created previously. However, in this case, the Exist table is not necessary, since a comment always refers to an existing record.
The Flex parameter then needs to be configured with the same structure and order as in the report. Instead of the value field, you can use text or HTML text.
The advantage of HTML text is that it can be formatted. The disadvantage, however, is that it can no longer be exported to Excel.
Therefore, plain text is preferable to HTML text when exporting to Excel.
Here is an example of setting a Flex.Parameter for a comment on a supplier invoice:
+“Meter reading”, data on “Balance to date”, Web Portal “Edit date suggestion” on “End date”