Source:
Creating and Modifying Metadata Objects
1.1. Object synonyms should meaningfully and concisely describe respective objects. You cannot skip synonyms. In addition to metadata objects, this requirement also applies to metadata object attributes, table sections and attributes thereof, register dimensions and resources, and other configuration objects that have synonyms.
1.2. Avoid using abbreviations for object synonyms. The only exception are abbreviations (e.g., Ref.) or acronyms (e.g., VAT) commonly used or well understood by the target group.
1.3. If metadata objects have standard attributes (standard table sections), these should also get synonyms that describe the meaning of each attribute.
1.4. Standard attributes Parent and Owner also require synonyms other than synonyms given by the platform by default. For example, a configuration can have catalog Files with standard attribute Owner of type CatalogRef.FileFolders. Do not use Owner as a default synonym for standard attribute Owner. Instead, use some description like Folder or File Folder. Here is one more example. While for standard attribute Description in some catalogs, the default name Description is good enough as a synonym, it is reasonable to use Filename as a synonym for catalog Files or Full name for catalog Persons.
1.5. In a case where there are two (or more) metadata objects with a similar purpose, it is necessary that the synonyms for each object fully describe their meaning.
1.6. In most cases, object names come from synonyms, but it is necessary to remove spaces and characters not allowed in names. The first letter of every word should be capitalized. For example, catalog AdditionalAttributesAndInfoSets comes from synonym Additional Attributes and Info Sets.
1.7. Metadata object names should not exceed 80 characters.
1.8. Use comments when there is a need to share helpful information on a specific configuration object with developer team members.
1.9. Start every comment with a capital letter. Use full stop only after abbreviations.
The rules above apply to the naming of all metadata objects.
Also, when naming metadata objects, it is important to comply with the following:
2.1. Roles. You can follow one of the two approaches depending on the case. Use job titles for roles that correspond with the job responsibilities of users in the system. It includes accountants, administrators, and similar. For roles that grant access to smaller function units, thus allowing the system fine-tuning, use the names to describe actions such roles permit.
2.2. Filter criteria. Filter criteria names should be in the plural and present descriptions of objects to which respective filters apply.
2.3. Event subscriptions. Use infinitive verbs that describe actions performed by the relevant events.
2.4 . Scheduled jobs. Use nous in a single form.
2.5. Functional options. Names of functional options associated with constants should describe the functionality they switch on (or off).
2.6. Parameters for functional options. Use descriptive names for parameters of functional options. Still, functional parameter names do not need to be equal to attributes of objects that respective parameters refer to.
2.7. Common forms. Use nouns for common form names.
2.8. Common commands. Names of commands found in a form’s navigation bar or the command interface should describe objects accessed with respective commands. In other cases, use infinitive verbs that describe the actions of such commands.
2.9. Common templates. On naming common templates, use nouns that give a general idea of the contents or purpose of such templates.
2.10. Web services. Name web services in English only. Use nouns that give a general idea of the designation of the services.
2.11. Constants. For constants associated with functional options, use names similar to those of the functional options. In other cases, the names of constants should refer to the relating objects. For constants of type Boolean, use infinitive verbs denoting actions that such constants initiate or deactivate.
2.12. Catalogs. The names should be in plural and describe objects included in catalogs.
2.13. Documents. Use nouns in the singular form. A document name should give the idea of the process that a respective document handles in the system. At that, the name should be as concise as possible. Documents not associated with any processes and used for printed forms only can get names of respective printed forms.
2.14. Document journals. Names for document journals should be in the plural and describe the objects included in journals.
2.15. Enumerations. The names for enumerations utilized within configurations should be in the plural.
2.16. Reports. Use nouns for names of reports and report variants. It is advisable to include titles in reports or report variants that are to be printed. The titles should be concise and clearly describe the reports' data. If there is a title for a report variant, it should be identical to the title of a respective printed form. Do not append report titles with comments or additional information using parenthesis or other delimiters.
2.17. Handlers. Use nouns for handler names. If you intend to use the command interface or some form’s navigation panel to open a handler’s form, the opening command should be identical to the handler name.
2.18. Charts of characteristic types. Use nouns in plural form. The name should describe objects included in respective charts of characteristic types.
2.19. Charts of accounts. Use nouns in the singular form. The name should give a general idea of charts of accounts designation. Synonyms can contain non-abbreviated names.
2.20. Information registers and accumulation registers. Names for information and accumulation registers should be in plural and describe the content of such registers.
2.21. Business processes. Give names to business processes using single form nouns the same way as with names for documents.
2.22. Tasks. Create the names using single-form nouns.
2.23. External data sources. Names for external data sources should describe the imported data.