1. In general flags must have the extension FLG as postfix.
→ Thereby, it can easily be identified as a flag.
2. Queries about status or value of value of a flag should always be carried out via “isempty” (res. “isempty”).
→ Thus, the characters that have been used to mark the set status do not matter any more.
3. Embedded codetables should neither be created nor used with flags. Yes/No codetables may not be distributed over the whole software.
→ No redundant Level 5 codetables are required. This way the software remains less complex and less customer overlays need to be handled.
4. In case a flag is to be set, “clear(xxxFLG)” or “xxxFLG=“X”” can be used, whereas “X” is a wildcard.
→ A fast and clearly structured implementation of logic is possible.
5. If a flag has to be switchable via a checkbox by a user, the checkbox needs to be defined wit two discrete values “ ” and “X”.
→ This enables a quick and clearly structured implementation of checkboxes.
6. The name of the flag variables should always be selected in a way that the 'enabled / set' state is represented by the name.
(Examples: ATTCUSFLG means, that if the flag is set a Customized rule has to be used for attachments. NONLOGFLG would mean, that no LOG has to be displayed, when the flag is set.)
→ Less logic errors will occur, as the meaning becomes obvious by reading the name. The field documentation has also to be used less often.
Further information about flags can be found in 'Field Naming Conventions'.