A POV can filter a form in two ways:


  1. Reducing the valid records of a form column (basically, acting as a SQL clause WHERE)
  2. Reducing the look-ups acceptable values


In this article we will focus on the second way.


During a form reading, the acceptable values of the look-ups are extracted, according to configurations. You can filter look-up data by adding a POV on a column of the source table of a look-up (and not on a column of the form) to the catalog.


Example:


A form records sales, and writes on F_SALES table. On F_SALES table there is a POV for each State. 

The form has a look-up on customers, whose data are stored in L_CUSTOMERS table.

The aim is to ensure that data are divided according to the State and consequently that the customers available on the look-up are only the active customers in the State selected in the POV.

Let's suppose that both F_SALES and L_CUSTOMERS tables contains a STATE field.


In order to achieve the first requirement it is necessary to set a POV on a field with the State (logical name, this is the field the end-user sees in the form), the records shown are those of the selected State. 

In order to achieve the second requirement it is necessary to create a POV and to set the Column name on the physical name of the column that contains the State in the look-up. As a results, even if the system does not use the STATE field of the look-up, the acceptable values will be filtered according to the POV. 


Now, the user has two look-ups that can act on different column names. To complete the implementation you have to make the second POV Non-user editable, and make sure that the variable containing the working value is the same used by the first POV. In this way, the user will edit the only visible POV, but actually he's editing the two.