Імена об'єктів метаданих у конфігураціях

Згідно із загальними правилами найменування метаданих.
Наприклад: Фінанси, Маркетинг, НастройкаИАдминистирование.

Див. також: Використання підсистем

Див. Правила створення загальних модулів

Згідно із загальними правилами найменування метаданих.
Наприклад: ТекущийПользователь, ОбменДаннымиВключен, ПредлагатьУстановкуРасширенияРаботыСФайлами.

Див. також: Використання параметрів сеансу

Під час найменування ролей рекомендується дотримуватися двох схем:

«прикладні» ролі, що відповідають посадовим обов'язкам певної категорії користувачів інформаційної системи, слід називати від назви посади, наприклад Бухгалтер, Кассир, Администратор.

ролі, що надають доступ до більш «дрібних» функціональних блоків для більш «тонкого» налаштування прав доступу користувачів, рекомендується називати від опису дозволеної дії. Наприклад: ДобавлениеИзменениеНСИ, ЧтениеДополнительныхСведений, ИнтерактивноеОткрытиеВнешнихОтчетовИОбработок.

Див. також: Стандартні ролі

Згідно із загальними правилами найменування метаданих.

Імена планів обміну рекомендується називати за такими принципами:

• у назві планів обміну РІБ (ознака Распределенная ИБ увімкнена) стисло описуються правила синхронізації даних. Наприклад: Полный, ПоОрганизациям, ПоСкладамИОрганизациям
• імена планів обміну між різними конфігураціями слід формувати з імені джерела та імені приймача. Імена планів обміну в джерелі та приймачі мають бути однаковими. Наприклад: ОбменУправлениеНебольшойФирмойБухгалтерияПредприятия, ОбменУправлениеТорговлейРозничнаяТорговля.

За потреби організації обміну з різними версіями (редакціями) конфігурацій до імен приймача та джерела додаються номери версій (редакцій). Наприклад, ОбменУправлениеТорговлей110РозничнаяТорговля10 (обмін даними між конфігураціями редакцій 11.0 і 1.0)

Імена підписок на події рекомендується задавати від суті виконуваної дії та утворювати від неозначеної форми дієслова. Наприклад,
неправильно
ЗапретРедактированияРеквизитовОбъектовПередЗаписьюОбъекта
НастройкаПорядкаЭлементовПередЗаписью

правильно:
ПроверитьИзменениеРеквизитовОбъекта
ПересчитатьПорядковыйНомерЭлемента

Імена регламентних завдань рекомендується давати в однині та утворювати від іменника. Наприклад,
неправильно
УстановитьПериодРасчитанныхИтогов
УведомитьИсполнителейОНовыхЗадачах

правильно
УстановкаПериодаРасчитанныхИтогов
УведомлениеИсполнителейОНовыхЗадачах

Імена функціональних опцій, пов'язаних із константами, рекомендується утворювати від опису функціональності, що вмикається (або вимикається) з їхньою допомогою. Наприклад, для функціональних опцій типу Булево:
ИспользоватьБизнесПроцессыИЗадачи
ИспользоватьВерсионированиеОбъектов

для функціональної опції інших типів:
ПрефиксИнформационнойБазы (тип Строка)
ВариантыВерсионированияОбъектов (параметризована функціональна опція, пов'язана з регістром відомостей)

Див. також: Використання функціональних опцій

Імена параметрів функціональних опцій рекомендується задавати від опису параметра. При цьому необов'язково, щоб ім'я параметра функціональної опції збігалося з найменуванням реквізитів об'єктів, на які посилається параметр. Наприклад:

Организация – пов'язаний із довідником Организации;
ТипОбъектаКонфигурации – пов'язаний із двома ресурсами регістрів відомостей:

• РегистрСведений.НазначениеДополнительныхОбработок.Измерение.ТипОбъекта, і
• РегистрСведений.НастройкаВерсионированияОбъектов.Измерение.ТипОбъекта

Див. також: Використання функціональних опцій

Імена визначуваних типів рекомендується задавати в однині та утворювати від їх призначення. При цьому не слід називати їх так само, як називаються інші типи даних (наприклад: «Строка», «Число», …), і не використовувати слова, від вилучення яких зміст не змінюється (наприклад: «Тип...», «Объект…», «Ссылка…»).

Наприклад, неправильно:
Строка25, СсылкиНаКонтактыВзаимодействий

Правильно:
АртикулНоменклатуры – рядок фіксованої довжини 25 символів, який використовується в довіднику номенклатури організації, довідниках номенклатури постачальників, звітах і обробках, призначених для роботи з номенклатурою.
КонтактВзаимодействий – складений тип, що включає посилання на різні довідники, елементи яких є контактами взаємодій (електронних листів, телефонних дзвінків, зустрічей тощо). Наприклад, Пользователи, КонтактныеЛицаПартнеров, Партнеры та інші.

Імена загальних форм рекомендується утворювати від іменників. При цьому слід уникати в назві форм слів, від вилучення яких зміст не змінюється, наприклад: «Форма…», «Окно…», «Диалог…».

Приклади: НастройкаСистемы, МоиНастройки, ПараметрыПроксиСервера, ВыборОбъектовМетаданных.

Імена загальних команд рекомендується задавати за такими принципами:

• якщо команда призначена для розміщення на панелі навігації тієї чи іншої форми або розділу командного інтерфейсу, то її назва має позначати список об'єктів, які вона відкриває. Наприклад:
  ДополнительныеОтчетыИОбработкиЗаполнениеОбъекта,
  ЗадачиПоБизнесПроцессу
• в інших випадках, як правило, імена загальних команд утворюються від неозначеної форми дієслова, що позначає дію команди, наприклад:
  ВыполнитьСопоставление,
  УстановитьРасширениеРаботыСФайлами

Див. також: Керівництво зі стилю

Згідно із загальними правилами найменування метаданих.

Див. також: Загальні правила побудови інтерфейсів, Загальні інтерфейси

Згідно із загальними правилами найменування імен метаданих. Наприклад:
Найти – універсальна картинка для команд пошуку, для використання в різних підсистемах конфігурації.
ЗакрепитьВариантОтчета – картинка команди «Закрепить вариант отчета».

Допускається зазначати специфікатори розміру, наприклад:
Папка – картинка розміром 16x16 пікселів
УправлениеПоиском32 – картинка розміром 32x32 пікселів
ДлительнаяОперация48 – картинка розміром 48x48 пікселів

Для позначення картинок-колекцій до імені додається префікс Коллекция. Наприклад: КоллекцияВариантыВажностиЗадачи.

При цьому слід уникати в назві загальних картинок слів, від вилучення яких зміст не змінюється, наприклад: «Картинка…», «Изображение…», «Пиктограмма…».

Імена XDTO-пакетів рекомендується утворювати російською мовою від іменників, що дають коротке уявлення про вміст або призначення пакета. При цьому слід уникати в назві слів, від вилучення яких зміст не змінюється, наприклад: «Пакет…», «ХDTO…».

Приклад: Файлы.

Імена Web-сервісів рекомендується утворювати англійською мовою від іменників, що дають коротке уявлення про їх призначення. Не рекомендується використовувати кирилицю, оскільки сторонні інформаційні системи можуть її не підтримувати, а також слова, від вилучення яких зміст не змінюється, наприклад: «Service», «WebService».

Приклади: Files, accounts, FlightStatus.

Імена операцій Web-сервісів, а також їх параметри рекомендується також писати англійською мовою.

Приклад: GetCurrencyRate

Імена WS-посилань рекомендується утворювати від іменників, що дають коротке уявлення про призначення Web-сервісу. При цьому слід уникати в назві слів, від вилучення яких зміст не змінюється, наприклад: «WebСервис…», «Сервис…», «Ссылка…».

Приклади: ДанныеОтгрузки, КонверторВалют.

Імена елементів стилю рекомендується утворювати від іменників, що дають коротке уявлення про їх призначення.
Наприклад: ВыполненнаяЗадача, ПоясняющийТекст, НеСтартованныйБизнесПроцесс.

Також в імені елемента стилю допускається уточнення щодо визначуваного параметра стилю,
наприклад: УдаленныйДополнительныйРеквизитЦвет, УдаленныйДополнительныйРеквизитШрифт.

Див. також: Елементи стилю (для режиму звичайного застосунку див. Стилі)

Згідно із загальними правилами найменування метаданих.

Див. також: Стилі (для звичайного застосунку)

Імена констант рекомендується задавати за такими принципами:

• Якщо константа пов'язана з функціональною опцією, то співзвучно функціональній опції;
• В інших випадках ім'я константи утворюється від опису об'єкта, значення якого вона зберігає. Наприклад: ТипХраненияФайлов, НастройкаПроксиСервера.
• Якщо тип значення константи – Булево, то ім'я може бути утворене від неозначеної форми дієслова, що позначає дію, яка вмикається або вимикається. Наприклад: ВыполнятьПроверкуЭЦПНаСервере, ИзвлекатьТекстыФайловНаСервере, ИзменятьЗаданияЗаднимЧислом.

При цьому слід уникати в назві констант слів, від вилучення яких зміст не змінюється, наприклад: «Константа…».

Імена довідників рекомендується давати у множині та утворювати від опису списку об'єктів, значення яких зберігаються в довіднику. Наприклад: Валюты, ГруппыИсполнителейЗадач, ПрофилиГруппДоступа, Пользователи.

При цьому слід уникати в назві довідників слів, від вилучення яких зміст не змінюється, наприклад: «Справочник…».

Імена документів, навпаки, даються в однині. Наприклад: ЗаказПокупателя, ПеремещениеТоваров, Анкета.

При цьому слід уникати в назві довідників слів, від вилучення яких зміст не змінюється, наприклад: «Документ…».

Під час вибору імені документа слід розрізняти два випадки:

1. Насамперед слід прагнути відобразити в імені документа суть процесу, який відображається в системі цим документом. При цьому саме ім'я має бути максимально лаконічним, рекомендується уникати слів «Накладная…», «Акт…» тощо.

Наприклад, у системі автоматизовано процес «Сверка взаиморасчетов», який завершується підписанням сторонами, що беруть участь у звірці, друкованого документа «Акт сверки товаров». Оскільки в цьому разі в системі документом фіксується саме процес, то документ називається СверкаВзаиморасчетов.

2. Якщо документ не відображає будь-який процес у системі, а призначений лише для отримання відповідної друкованої форми, то допустимо утворювати ім'я документа від імені друкованої форми. У цьому разі допустимо використовувати слова «Накладная», «Акт» тощо в імені документа. Як правило, такий документ не має статусів, на його підставі не вводяться інші документи, а сам процес отримання друкованої форми може бути автоматизований іншими документами.

Наприклад, для отримання друкованої форми «Товарно транспортная накладная» (ТТН) у системі є документ, який містить реквізити, специфічні для цього друкованого документа. При цьому, оскільки весь процес формування ТТН пов'язаний з іншими документами («Реализация товаров и услуг», «Перемещение товаров»), то документ доцільно назвати від імені друкованої форми: ТоварноТранспортнаяНакладная.

Імена журналів документів рекомендується задавати у множині та утворювати від опису списку об'єктів, які містяться в журналі. Наприклад: СкладскиеДокументы, КорректировкиНДС.

При цьому слід уникати в назві слів, від вилучення яких зміст не змінюється, наприклад: «Документы…».

Імена переліків у конфігурації рекомендується задавати у множині.

Наприклад, неправильно
ДействиеСДокументамиПоДвойномуЩелчку
ВажностьЗадачи
SMTPАутентификация

Правильно:
ДействияСДокументамиПоДвойномуЩелчку
ВариантыВажностиЗадачи
ВидыSMTPАутентификации

Будь-який виняток із цього правила має бути обґрунтованим. Наприклад:
ПолФизическогоЛица

1. Імена звітів і варіантів звітів рекомендується утворювати від іменника.
Наприклад: ДинамикаИзмененийФайлов, СписокЗависшихЗадач, СправкаОбИсполнительскойДисциплине.

2. Рекомендується передбачати виведення заголовка, якщо звіт або варіант звіту призначений для друку.

3. Під час вибору подання варіанта звіту слід дотримуватися таких рекомендацій:

• Подання має лаконічно й однозначно описувати суть даних, які виводяться в цьому варіанті звіту.
  
  Наприклад, для звіту «Валовая прибыль», неправильно:
  «Основной», «По заказам» (подібні назви можуть траплятися у варіантів інших звітів)
  
  Правильно:
  «Валовая прибыль по контрагентам», «Валовая прибыль по заказам»
  
  
• Якщо для варіанта звіту виводиться заголовок, то його подання має збігатися із заголовком друкованої форми. Це дасть змогу користувачу однозначно визначати варіант звіту за його друкованою формою.
• Не рекомендується утворювати подання від імені звіту з уточненням специфіки варіанта звіту в дужках або з використанням інших роздільників. Це може перевантажити списки варіантів звітів повторами, роздільниками та уточненнями, знизивши простоту візуального сприйняття.

4. При цьому слід уникати в назвах звітів і варіантів звітів слів, від вилучення яких зміст не змінюється, наприклад: «Отчет…».

Імена обробок рекомендується утворювати від іменника.
Наприклад: КонтрольЖурналаРегистрации, РегламентныеИФоновыеЗадания, УправлениеИтогамиИАгрегатами.

При цьому слід уникати в назві обробок слів, від вилучення яких зміст не змінюється, наприклад: «Обработка…».

Якщо форму обробки передбачається відкривати з панелі навігації тієї чи іншої форми або розділу командного інтерфейсу, то ім'я обробки має збігатися з іменем команди для її відкриття. Наприклад, команда РегламентныеИФоновыеЗадания відкриває обробку РегламентныеИФоновыеЗадания.

Імена планів рахунків рекомендується задавати в однині, утворюючи ім'я від іменника, що дає коротке уявлення про призначення плану рахунків. При цьому слід уникати в імені плану рахунків слів, від вилучення яких зміст не змінюється, наприклад: «ПланСчетов…». Водночас у синонімі може задаватися повне найменування.
Наприклад (ім'я – синонім):
ЕПСБУ - "ЕПСБУ"
БухгалтерскийУчет - "План счетов бухгалтерского учета"
УправленческийУчет - "План счетов управленческого учета"
МеждународныйУчет - "План счетов международного учета"
Бюджетирование - "План счетов для бюджетирования"
тощо.

Для додаткових уточнень можна використовувати властивість Пояснение, значення якої виводиться в підказці до команди відкриття плану рахунків.
Наприклад:

• НалоговыйУчет - синонім "План счетов налогового учета",
  пояснення: "План счетов налогового учета (по налогу на прибыль)"
• ЕПСБУ - синонім "ЕПСБУ",
  пояснення: "Единый план счетов бюджетного учета"

Імена бізнес-процесів рекомендується задавати, як і імена документів, в однині.
Наприклад: Задание, Согласование, Утверждение, Поручение.

Імена зовнішніх джерел даних рекомендується утворювати від опису імпортованих даних. При цьому слід уникати в назві слів, від вилучення яких зміст не змінюється: «Данные…», «ИсточникДанных…».

Приклади: ДоговорыУправленческойУчетнойСистемы, ФайлыОсновнойСЭД.

Таблиці зовнішніх джерел даних рекомендується називати згідно із загальними правилами найменування об'єктів метаданих.

Приклади: Договоры, Номенклатура.