Имена объектов метаданных в конфигурациях

Согласно общим правилам наименования метаданных.
Например: Финансы, Маркетинг, НастройкаИАдминистирование.

См. также: Использование подсистем

См. Правила создания общих модулей

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

См. также: Использование параметров сеанса

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

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

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

См. также: Стандартные роли

Согласно общим правилам именования метаданных.

Имена планов обмена рекомендуется называть по следующим принципам:

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

При необходимости организации обмена с разными версиями (редакциями) конфигураций, к именам приемника и источника добавляются номера версий (редакций). Например, ОбменУправлениеТорговлей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. При этом следует избегать в названиях отчетов и вариантов отчетов слов, от удаления которых смысл не меняется, например: «Отчет…».

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

При этом следует избегать в названии обработок слов, от удаления которых смысл не меняется, например: «Обработка…».

Если форму обработки предполагается открывать из панели навигации той или иной формы, или раздела командного интерфейса, то имя обработки должно совпадать с именем команды для ее открытия. Например, команда РегламентныеИФоновыеЗадания открывает обработку РегламентныеИФоновыеЗадания.

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

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

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

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

Имена внешних источников данных рекомендуется образовывать от описания импортируемых данных. При этом следует избегать в названии слов, от удаления которых смысл не меняется: «Данные…», «ИсточникДанных…».

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

Таблицы внешних источников данных рекомендуется называть согласно общим правилам наименования объектов метаданных.

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