Handling Read-Only Pages

This document describes the consistency rules that have been defined for functions that were switched from version 6 to read-only pages mode. It only lists the normalization rules, and assumes that the purpose of the switch is to display the data exactly as it existed in version 6. Make sure you carefully read the instructions given in the dedicated section of this documentation before developing the code that performs the switch from version 6 to version 7.

Preliminary general recommendations

• Use the default values given in the dictionaries.
• If you decide to switch a function to read-only mode for workstations only, discard all CRUD methods except the Read method. Do not define the Edit facet, and create a specific representation for the desktop.
• Make sure you leave the fields related to authorization empty. They will be filled later.
• If you have any question regarding information in a dictionary, read the corresponding documentation in the workbench section.
• Keep using the normalization rules as they were defined for version 6.

Facets definition policy

The table below summarizes the recommendations when building representations corresponding to version 6 functions.

Rule	Details
Function access	The menu items giving access to read-only pages must open the page in the same tab, and not create a new tab.
Search policy	Carefully define the entities in which a search is useful, and avoid indexing too many properties. Usually, only codes and descriptions are indexed. Indexing a date or an amount is possible, but it should be done as an exception.
Query facet	Columns defined in a query: All columns included in version 6 left lists must be included. The columns of the primary key must appear first. The default sort order must be on the primary key. A magnifying glass must be present on each reference column of the selection header line. This is automated if a dedicated data type exists. This data type must refer to a class and a representation. The description displayed should be the short one. When the legislation code is found in the table, use the following rules: If the legislation code is found in the key, the following fields should appear in this order: the data code, the legislation code, the label associated with the data, and the other elements. If the legislation code is just a filter, the following fields should appear in this order: the data code, the label associated with the data, the legislation code, and the other elements. Page links present: Creation and modification links must always be present. Microsoft Excel and Word links must always be present. Microsoft Word mail merge links must be present only if they are useful, at least for all the business partners representations (customers, suppliers, carriers, etc.). Access to details from the lines: A hyperlink must be directly present on the key value if the key to the detail record has only one component. It should also be present in the actions menu for consistency purposes. If the key to the detail record has several components, the proposal is as follows: If all the components of the key are fixed except one, the link has to be set on the key element that varies. The link has to be done through the actions menu. If the modification is done in "Classic" mode, use the Pencil icon. Hyperlinks to fields that are references to other entities can be set up on the query lines.
Detail facet	All the properties of the class must be included in the Detail facet. This includes the information that was displayed through a menu or a right-click, such as texts or valuation information. Remember that this information can be placed in collapsible sections or on tabs through personalization if the resulting page becomes too large. You should avoid displaying repeated information such as hidden fields in the address grid for business partners. All the properties that are references to other entities must have a hyperlink to the detail of the entity they are linked to. Always add the Microsoft Excel and Word links on the Detail facet. The global List link that returns to the query facet must also be present. To facilitate the transition for version 6 users, create a section in the representation for each screen present in the window, and a block for each block previously present in the screens. The description displayed should be the long one.
Lookup facet	This facet is not mandatory if it is not used in another Edit facet.

Classes normalization

The following rules have been defined to ensure a normalization of the classes that will replace version 6 objects. The naming conventions are as follows:

Element	Naming rules	Examples, if relevant
Class name	Use the code of the main table of the object.	The BPC object is replaced with the BPCUSTOMER class.
Child classes linked to a secondary table.	Use the table's abbreviation.	In the BPCUSTOMER class, the BPARTNER embedded instance is coded BPR.
Properties of the class present in the table.	Use the column name in the table to ensure the automatic transfer.	-
Collections for array properties that are not child class collections.	No normalization rule. Use the most meaningful names, and avoid unnecessary prefixes.	DIMENSIONS can be used to define a collection of dimension codes and dimension types.

Supervisor services

The Supervisor manages additional services for the development partner. It reduces the number of lines a development partner will have to write if the recommendations provided are followed.

Issue	Recommendation
Display pictures	The display of binary data such as pictures is managed by the Supervisor if you follow the corresponding rules.
Quantity linked to unit	The handling quantity linked to units is managed by the Supervisor. It only requires to reference the unit at the quantity field level.
Links on properties	The links management for properties that reference other classes is managed automatically by the Supervisor if the data type dictionary is filled. You can also refer to the links definition section.
References	Use references when a property in a class is the key of another instance of another class (for example, when a field is a link to another object in version 6 terminology). This is done by creating a dedicated data type associated with the right class. In this case: The Supervisor will read the short and long descriptions when reading the class. The navigation hyperlink that brings you to the linked record details will be automated if the Detail representation exists. You will have to read the table record manually if additional information from the referenced record has to be displayed. Caution: Do not over-use embedded classes to manage the automatic reading of columns in the linked table record. This can be disastrous from a performance point of view.