Roles

Principles of the functioning

This management is based on :

• the definition of role codes (customer, Pay-by, representative, supplier...), which can be freely carried out in a miscellaneous table (number 60)
• the association, for the objects for which a filter is to be established, of a field in the main table with the role code. It is this association that will be used to establish the data filter criterion. The role management documented here is used to define these associations.
• in an operational way, the allocation in the user record, of one or more roles with the corresponding codes (30 maximum). It is this allocation that will define the automatic filters in the object management concerned.

Once these setups are defined and the roles (and the corresponding codes) have been defined in the user record :

• A filter is created in the object (quick select list, selection windows) on the code(s) defined in the user record.
• A control is made during the creation of the filtered fields.
• A filter can be carried out in the requester.

Notes and limitations

Warning, the filters have the following limitations:

• The quick select left list filtering is only made in the fields of the main table in the object (no filtering in the picking either)
• When the entry of a key is prohibited without using the selection, the entry is accepted initially, the control being carried out at the end. To avoid this, it is possible to carry out controls on the roles in real time on certain specific/custom fields and this is done very simply, using the CROLE action as the control action. This is not carried out as standard because its use on all the fields would provoke numerous exchanges between the client and the server, where as in general this type of control is carried out on very few fields.
• The filter introduced by the roles is not managed by the standard reports (this would be impossible due to the possible extremes of the setup), nor by the standards inquiries. It is therefore necessary to create specific reports if they should be made accessible to external users (but this is possible by playing with the access codes in order to dedicate reports specifically filtered for these users).
• a mass filter on the data in a table where the left list is not strictly sorted according to the filter criteria can be very heavily penalized in terms of the response time. It is therefore advisable to use optimization indexes and declare them in the left list.

In the case where several roles are defined in the user record, the rule is the following :

• if the roles are identical and the associated key is different, an or logic is carried out between the conditions.
• if the roles are different, an and logic is made between the conditions.

Examples

Here are a few examples to illustrate this logic. A filter is to be applied to:

• the products by buyer code (BUY field associated with the ITM object for the buyer role)
• the purchase orders by supplier (BPSNUM field associated with the POH object for the supplier role)
• the purchase orders also by buyer code (BUY field associated with the POH object for the buyer role)

If the user JOHNDOE possesses the buyer role for the codes MARTIN and DURAND, and the supplier role for the codes DUPONT, DUPUIS, and DUMONT, the filters will be as follows :

• On supplier order entry, only the orders made to the DUPONT ,DUPUIS, or DUMONT suppliers and involving the MARTIN or DURAND buyers will be available.
• If an order is created, the selection window for the buyers and suppliers will correctly filter the authorized buyers and orders. On the other hand, if a prohibited code is entered, it will only be controlled when an attempt is made to confirm the order.
• The products ordered will also be filtered directly at the time of their selection depending on the buyers. Even here, if a product that is not bought by one of the buyers is entered, the checks will only be made at the time of confirming the order.
• On the other hand, no filter is applied to the display of an order (if supplier orders have been made on products normally filtered for the user, it will be possible to select them, yet their modification will be eventually refused).

The technical implementation is made by the automatic addition of the filters to the table managed by the object management. These filters are both active in the standard selection and in the left list. Let us consider a more technical example. If the following associations are defined for the customer role (defined for example with the code BPC), and the commercial role (defined for example with the code REP) :

• in the object SIH (customer invoice), the BPC role introduces a filter on the BPR field (invoiced BP code).
• in the SOH object (customer order), the BPC role introduces a filter on the BPCORD field (sold-to customer).
• in the BPC object (customer), the BPC role introduces a filter on the BPCNUM field (customer code).
• in the SOH object (customer order), the REP role introduces a filter on the REP field (sales representative).

If a user possesses the BPC role in its record associated with the MARTIN code, a filter on the SIH object will be be automatically carried out: (BPR="MARTIN"), on the object SOH (BPCORD="MARTIN"), and on the object BPC (BPCNUM="MARTIN").

Of course, only the filters corresponding to a role associated with the user are active. This, if the user does not have the role BPC in its record, the filters defined above will not be carried out : the user will get all the orders, all the invoices and all the customer (provided no other filters - by group of sites, by other roles - have not been defined for the user).

The following illustrates the composition of several filters :

• if the user has the BPC role three times with the three customers MARTIN ,DURAND and DUPUIS, the filter on the customer record will be:
  (BPCNUM="MARTIN" or BPCNUM="DURAND" or BPCNUM="DUPUIS")
• if the user has the BPC role associated with the MARTIN code, and the REP code associated with the DUPUIS code, the filter carried out on the order management will be:
  (BPCORD="MARTIN") and (REP="DUPUIS")

Prerequisite

Refer to documentation Implementation

Screen management

Entry screen

Menu Bar

Copy	This button is used to copy the role to another folder accessible from the server where the current folder is located.

Error messages

The only error messages are the generic ones.

Tables used

Refer to documentation Implementation