Переопределяемый модуль 1с что это

Обновлено: 06.01.2025

Эта статья продолжает цикл статей «Первые шаги в разработке на 1С». В ней на практических примерах рассматривается механизм предопределенных данных, в т.ч. и в распределенной информационной базе.

Применимость

В статье рассматривается платформа 1С:Предприятие версии 8.3.4.465. Материал актуален и для текущих релизов платформы.

Предопределенные элементы в «1С:Предприятие 8.3»

При реализации алгоритмов разработчики часто опираются на определенные данные – элементы справочников, планов счетов, планов видов расчета и т.д.

Во встроенном языке существуют методы для поиска данных, например, НайтиПоКоду() или НайтиПоНаименованию().

Однако алгоритмы, опирающиеся на код или наименование, зачастую являются ненадежными.

Поскольку в пользовательском режиме код или наименование элемента справочника могут быть изменены, что может привести к неработоспособности алгоритмов.

Именно для решения этой проблемы и предназначены предопределенные данные – данные, созданные в конфигураторе, обратиться к которым возможно по имени, не прибегая к предварительному поиску элемента.

Таким образом, у предопределенных данных есть две “стороны”: во-первых, существует список предопределенных элементов, созданный в конфигураторе, а, во-вторых, для данных информационной базы указывается, является ли конкретный элемент предопределенным.

Предопределенные элементы могут быть созданы у:

справочников;
планов счетов;
планов видов характеристик;
планов видов расчета.

В статье рассмотрены новшества, касающиеся предопределенных данных на платформе 8.3, а также особенности работы с ними в распределенных базах (как центральных, так и периферийных) и в информационных базах в режиме разделения данных.

Для примера, создадим в справочнике Организации предопределенный элемент ОсновнаяОрганизация:

Для увеличения нажмите на изображение.

Обращение к этому элементу из программного кода будет следующим:

В платформе 8.3 реализована возможность связать предопределенные данные с элементами соответствующего типа.

Для этого у объектов, которые могут иметь предопределенные элементы (они указаны выше), добавлено новое свойство ИмяПредопределенныхДанных. Оно отображается в списке стандартных реквизитов:

Выберем при помощи запроса все поля из справочника Организации:

Для увеличения нажмите на изображение.

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

Предопределенный элемент в списке отображается специальной пиктограммой:

Чтобы “отсоединить” элемент данных от элемента предопределенных данных, нужно присвоить свойству ИмяПредопределенныхДанных пустую строку и записать элемент:

&НаКлиенте
Процедура Отсоединить ( Команда )
ОтсоединитьНаСервере ();
КонецПроцедуры

Пиктограмма в списке изменилась:

Теперь предопределенный элемент существует только в конфигурации и в данных нет элемента, привязанного к идентификатору ОсновнаяОрганизация:

Для увеличения нажмите на изображение.

Обращение из программного кода к предопределенному элементу вызовет исключение:

Чтобы связать предопределенный элемент с новой записью, нужно присвоить свойству ИмяПредопределенныхДанных имя предопределенного элемента:

&НаКлиенте
Процедура Привязать ( Команда )
ПривязатьНаСервере ();
КонецПроцедуры

Переопределяемые и поставляемые объекты библиотеки

Область применения: управляемое приложение, мобильное приложение, обычное приложение.

1. С точки зрения возможностей по настройке функциональности библиотеки для работы в конкретной конфигурации-потребителе все объекты библиотеки условно делятся на три категории:

Непереопределяемые объекты – «готовые» объекты, которые можно брать и использовать в конфигурации-потребителе «как есть». Их не следует изменять в конфигурации-потребителе, чтобы они были гарантированно одинаковы во всех конфигурациях, основывающихся на данной библиотеке. Более того, такие объекты обязательно должны присутствовать в конфигурациях, использующих библиотеку. Примеры: справочник Пользователи .
Переопределяемые объекты – «изменяемые» объекты для настройки библиотеки под конкретную конфигурацию. Они могут или должны быть изменены в конфигурации-потребителе. С помощью таких объектов решаются задачи изменения поведения библиотечной функциональности, ее параметризации спецификой конфигурации-потребителя, а также для подключения библиотечной функциональности к объектам конфигурации-потребителя.
Определители типов – объекты-«классификаторы», которые не имеют базовой реализации. Предназначены для формирования единого пространства имен в конфигурациях, а реализация при этом может как угодно сильно различаться в конфигурациях-потребителях. Например: справочники-классификаторы, в которых определено только «название»; сущность «организация» должна быть везде представлена справочником с именем Организации и т.п.

2. Рекомендуется устанавливать для объектов этих категорий следующие правила поставки :

Непереопределяемые объекты – «изменения не рекомендуются»;
Переопределяемые объекты и определители типов – «изменения разрешены».

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

Непереопределяемые объекты – это зона ответственности разработчиков библиотеки, поэтому они не должны разрабатываться «по месту» в конфигурациях-потребителях. Но если необходимость изменений носит срочный характер (например, исправление критичной ошибки) или продиктована какими-то другими особыми соображениями, то допускается вносить изменения в непереопределяемые библиотечные объекты непосредственно в конфигурациях-потребителях. При этом нужно иметь в виду, что эти изменения могут быть потеряны при следующем обновлении версии библиотеки в конфигурации-потребителе, если не принять специальные меры (донести до разработчиков библиотеки необходимость внесения изменений или задокументировать этот отход от общей инструкции по обновлению библиотеки).
Переопределяемые объекты и определители типы должны или могут быть изменены в конфигурации-потребителе, исходя из их назначения.

3. Для того чтобы упростить настройку библиотеки и снизить трудоемкость последующих обновлений версии библиотеки в конфигурации-потребителе следует минимизировать количество переопределяемых объектов с помощью следующих методик:

Настройка состава типов переопределяемых реквизитов (свойств) тех или иных объектов библиотеки – для подключения библиотечной функциональности к объектам конфигурации-потребителя.
Например: можно подключить библиотечную функциональность к конкретным объектам конфигурации с помощью расширения состава типов общей команды, измерения составного типа в регистре сведений и т.п.
Добавление предопределенных элементов – для параметризации библиотечной функциональности спецификой конфигурации-потребителя.
Например: для библиотечной подсистемы ведения и обработки контактной информации с помощью предопределенных элементов библиотечного справочника ВидыКонтактнойИнформации можно указать, какие виды контактной информации (телефон, адрес, электронный адрес и т.п.) должны быть предусмотрены для объектов конфигурации-потребителя.
Переопределяемые общие модули – для изменения поведения библиотечной функциональности в конкретной конфигурации-потребителе
- с помощью переопределения тех или иных «обработчиков событий», предоставляемых библиотекой; например:
  ПриПодготовкеМакетаОписанияОбновлений
  ПриЗаписиСпискаБизнесПроцессов
- а также для того, чтобы сообщить ту или иную информацию из конфигурации-потребителя в библиотеку. Например:
  ПриОпределенииБазовойВерсииКонфигурации
  ПриДобавленииОбработчиковОбновления
3.1. Переопределяемые общие модули следует называть с постфиксом Переопределяемый .

3.2. Переопределяемые общие модули должны содержать только экспортные процедуры, которые вызываются из кода самой библиотеки. Другими словами, не следует допускать вызовов процедур переопределяемых модулей непосредственно из кода конфигурации-потребителя.

Такое ограничение обусловлено соображением повышения устойчивости кода конфигурации, который вызывает библиотечные процедуры и функции, составляющие программный интерфейс библиотеки. К программному интерфейсу библиотеки следует относить только экспортные процедуры и функции непереопределяемых общих модулей.

Например, в библиотеке имеются модули ПапкиФайлов и ПапкиФайловПереопределяемый . Для использования в конфигурациях-потребителях в модуле ПапкиФайлов реализуется экспортная функция:

Функция ПапкаФайлов(ВладелецФайловСсылка) Экспорт

СтандартнаяОбработка = Истина;
Результат = Неопределено;
ПапкиФайловПереопределяемый.ПриПолученииПапкиФайлов(ВладелецФайловСсылка, Результат, СтандартнаяОбработка);

Если СтандартнаяОбработка Тогда
// реализация по умолчанию
Результат = .
КонецЕсли;
Возврат Результат;

а в модуле ПапкиФайловПереопределяемый - процедура-обработчик ПриПолученииПапкиФайлов :

// Вызывается из библиотеки при необходимости получить папку файлов для указанного владельца.
//
// Параметры:
// ВладелецФайловСсылка – ЛюбаяСсылка - владелец файлов, для которого нужно вернуть папку.
// ПапкаФайлов – СправочникСсылка.ПапкиФайлов - в этот параметр нужно записать результат.
// СтандартнаяОбработка – Булево - по умолчанию, Истина. В этом случае папка будет получена способом по умолчанию.
// Если значение параметра установить в Ложь, то в этой процедуре можно реализовать свой способ,
// которым в конфигурации получают папки файлов.
//
Процедура ПриПолученииПапкиФайлов(ВладелецФайловСсылка, ПапкаФайлов, СтандартнаяОбработка) Экспорт

При этом все вызовы из конфигурации-потребителя должны идти только к библиотечному модулю ПапкиФайлов . Обращение к ПапкиФайловПереопределяемый разрешается только из библиотечного модуля ПапкиФайлов .

3.3. При этом в переопределяемом модуле следует располагать только экспортные процедуры с пустой реализацией. В нем не должно быть каких-либо других не-экспортных процедур или функций. Базовую реализацию переопределяемых процедур и функций следует располагать в непереопределяемом коде.

Такое ограничение вызвано необходимостью снизить трудоемкость последующих обновлений переопределяемых модулей в конфигурации-потребителе.
Например, неправильно поставлять переопределяемый модуль МояБиблиотекаПереопределяемый с какой-либо реализацией:

Функция НастройкаПараметровРаботы() Экспорт

ПараметрыРаботы = Новый Структура;
// если настройки по умолчанию не подходят, то измените их.
ПараметрыРаботы.Вставить("ПоказыватьЕдинственныйРаздел", Ложь);
ПараметрыРаботы.Вставить("ЗадаватьДатуДляПрочихРазделов", Ложь);
ПараметрыРаботы.Вставить("ИспользоватьВнешнихПользователей", Ложь);
Возврат ПараметрыРаботы;

// Позволяет настроить работу подсистемы.
//
// Параметры:
// ПараметрыРаботы - Структура - содержит свойства:
// * ПоказыватьЕдинственныйРаздел - Булево - по умолчанию Ложь.
// * ЗадаватьДатуДляПрочихРазделов - Булево - по умолчанию Ложь.
// * ИспользоватьВнешнихПользователей - Булево - по умолчанию Ложь.
//
Процедура ПриПолученииНастроекПараметровРаботы(ПараметрыРаботы) Экспорт

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

ПараметрыРаботы = Новый Структура;
// настройки по умолчанию
ПараметрыРаботы.Вставить("ПоказыватьЕдинственныйРаздел", Ложь);
ПараметрыРаботы.Вставить("ЗадаватьДатуДляПрочихРазделов", Ложь);
ПараметрыРаботы.Вставить("ИспользоватьВнешнихПользователей", Ложь);

// а теперь запросим конфигурацию-потребитель на случай,
// если эти умолчания не устраивают
МояБиблиотекаПереопределяемый.ПриПолученииНастроекПараметровРаботы(ПараметрыРаботы);
Возврат ПараметрыРаботы;

3.4. При обновлении версии библиотеки в конфигурации-потребителе особого внимания требуют модули корневого объекта конфигурации и переопределяемые общие модули, так как автоматическое обновление таких «узких мест» конфигурации-потребителя невозможно. Для настройки в конфигурации переопределяемых общих модулей рекомендуется придерживаться общего подхода:

Этот расчет – функционал базовой библиотеки, которая будет лежать в основе остальных библиотек.

Возможно нам понадобится расчет налогов. Не вдаваясь в тонкости налогового учета, допустим что налог – это некая сумма, рассчитанная по ставке и просто добавляемая к основной сумме.

Аналогичным образом формализуем учет скидок:

Каждая из этих формул, а также объекты, содержащие все необходимые для расчета данные, реализованы в своей библиотеке. Но проблема в том, что запуск расчета производится в форме документа, в базовой библиотеке, в которой может быть ничего не известно о функционале, да и вообще о наличии других библиотек. Классический подход подразумевает реализацию в базовой библиотеке переопределяемого модуля расчета суммы, который в итоговой конфигурации должен быть дополнен (изменен) вызовами методов других библиотек.

Но можно поступить иначе. Предположим, в итоговой конфигурации у нас есть некий перечень методов, вызывая которые, мы сделаем все необходимые расчеты. Список этих методов может быть различным, в зависимости от конкретной конфигурации. Каждый метод реализован в модуле своей библиотеки. Все что нужно сделать при запуске расчета в базовой библиотеке – это передать такой перечень механизму, который обработает каждый элемент этого списка. Но где задать нам этот список методов? Опять использовать переопределяемый модуль и получить проблемы с обновлением? А пусть он создается сам, в зависимости от наличия той или иной библиотеки! Давайте придумаем некий механизм, который в зависимости от наличия каких-нибудь объектов метаданных, поймет, какие методы каких модулей надо включить в список для выполнения расчета. Здесь появляется небольшая проблема: для поиска среди объектов метаданных можно использовать только имя, а объекты одного вида с одинаковым именем создавать нельзя. Т.е. нельзя в каждой библиотеке создать свой общий модуль с именем "РасчетСуммы" и объединить их в одну конфигурацию. Но можно создавать подсистемы с одинаковыми именами, если они принадлежат разным родителям. Получается следующая схема:

Для каждой библиотеки создана своя подсистема, в которой есть подсистема с именем "РасчетСумм". В составе последних включены общие модули, в которых реализован экспортный метод, выполняющий расчет (имена методов также одинаковы). Подсистемы библиотек лежат в пределах одной группы, для упрощения поиска. Таким образом, ориентируясь на имя подсистем "РасчетСумм" мы легко можем получить список модулей и методов для проведения расчета.

Несколько слов по поводу выполнения этих методов. Самый простой вариант – создание некоего "менеджера", который будет последовательно вызывать каждую процедуру. Но я решил остановиться на другом способе – вызывать самую последнюю процедуру из списка и передавать ей управление. Решение о вызове предыдущего метода полностью возлагается на эту процедуру. Такой вариант более гибок – предыдущий метод может быть вызван в любом месте, а может и быть просто проигнорирован, если в нем нет нужды. Порядок методов в списке определяется порядком расположения подсистем библиотек внутри "ПереопределяемыеОбъектыБиблиотек".

Как это выглядит на практике:

В документе "Продажа" реализована команда:

В серверной процедуре получаем последовательность описаний методов и запускаем выполнение последнего из них. В нашем случае это будет РасчетСуммСоСкидкой.РасчетСумм

В процессе расчета мы сначала выполняем предыдущий метод РасчетСуммСНалогом.РасчетСумм, а затем производим обработку скидки.

Перед налоговым расчетом мы так же вызываем предыдущий метод РасчетСуммБазовый.РасчетСумм:

В котором выполняем самый первый расчет.

в последнем случае метод УправлениеБиблиотеками.ВыполнитьПредыдущуюПроцедуруНаСервере не выполнит ничего, так как предыдущих процедур не осталось.

Описанный выше механизм можно применять и для других целей, например для создания общего списка строковых или табличных ресурсов. Вот так реализовано описание конфигурации, которое создается на основе табличных макетов, принадлежащих разным библиотекам:

В обработке "Инфо" создается общий табличный документ:

Как внедрять или обновлять получившиеся библиотеки.

Процесс внедрения и обновления библиотек – обычное сравнение объединение конфигураций. В этом режиме надо отметить объекты по подсистемам файла:

и выполнить объединение. При этом никаких других действий, таких как редактирования модулей, делать не надо.

Подобное объединение можно проводить в автоматическом режиме. Для этого служит специальная команда пакетного режима конфигуратора. Пример такой команды:

здесь c:\bases\prod\ - путь к файловой базе, c:\bases\lib1.cf - конфигурация библиотеки, c:\bases\UpdLib1Settings.xml - файл настроек объединения.

здесь мы указываем, что не меняем свойства конфигурации, разрешаем удалять объекты, помечаем для объединения объекты нужных нам подсистем. Обратите внимание, что каждую подсистему мы указываем дважды: в новой конфигурации (для добавленных и измененных объектов) и в основной конфигурации (для измененных и удаленных объектов).

В результате обновления мы получим итоговую конфигурацию, в которой может быть (а может и не быть) одна или две библиотеки. Существуют несложные средства, которые позволят нам так же автоматически поместить эти изменения в хранилище 1С или же в Git.

Итак, вот что мы получили: базовую библиотеку и две дополнительные библиотеки, на основе которых можем в автоматическом режиме собрать четыре разные конфигурации для разных заказчиков. Эти конфигурации различаются по функциональным возможностям и могут иметь разную продажную стоимость, что позволит более гибко составлять коммерческие предложения.

Конечно же, предлагаемый подход не панацея. Так, он не поможет при работе с определяемыми типами, с переопределяемыми макетами и некоторыми другими объектами, но облегчить работу он может значительно. Надо отметить, что и стандартные возможности платформы включают в себе нечто подобное, хотя и менее функциональное. Это - подписки на события.

Рассмотренный пример вы можете увидеть в приложенном к статье файле. Это архив, содержащий в себе:
- Папка base – базовая библиотека
- Папки lib1, lib2 – 2 библиотеки
- Папка prod – итоговая конфигурация
- 1_CreateBase.bat – пакетный файл для создания итоговой конфигурации на основе базовой библиотеки
- 2_AddLib1.bat, 3_AddLib2.bat – пакетные файлы для первоначального внедрения в итоговую конфигурацию библиотек lib1, lib2
- 4_UpdLib1.bat, 5_UpdLib2.bat – пакетные файлы для обновления в итоговой конфигурации библиотек lib1, lib2
- *Settings.xml – файлы с настройками объединения
Желательно чтобы все эти папки и файлы находились в каталоге c:\bases, так как в пакетных файлах используются абсолютные пути. Также надо указать путь к файлу 1cv8.exe в зависимости от версии платформы.

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

Область применения: управляемое приложение, мобильное приложение, обычное приложение.

1.1. Общие модули создаются для реализации процедур и функций, объединенных по некоторому признаку. Как правило, в один общий модуль помещаются процедуры и функции одной подсистемы конфигурации (продажи, закупки) или процедуры и функции сходного функционального назначения (работа со строками, общего назначения).

1.2. При разработке общих модулей следует выбирать один из четырех контекстов выполнения кода:

Тип общего модуля Пример наименования Вызов сервера Сервер Внешнее соединение Клиент
(обычное приложение) Клиент
(управляемое приложение) 1. Серверный ОбщегоНазначения (или ОбщегоНазначенияСервер)
2. Серверный для вызова с клиента ОбщегоНазначенияВызовСервера 3. Клиентский ОбщегоНазначенияКлиент (или ОбщегоНазначенияГлобальный)
2.1. Серверные общие модули предназначены для размещения серверных процедур и функций, не доступных для использования из клиентского кода. В них реализуется вся внутренняя серверная бизнес-логика приложения.
Для корректной работы конфигурации в режимах внешнего соединения, управляемого и обычного приложений, серверные процедуры и функции следует размещать в общих модулях с признаками:
- Сервер (флажок Вызов сервера снят),
- Клиент (обычное приложение) ,
- Внешнее соединение .
В таком случае гарантируется возможность вызова серверных процедур и функций с параметрами мутабельных типов (например, СправочникОбъект , ДокументОбъект и т.п.). Как правило, это:

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

В отдельных случаях для предотвращения конфликта имен со свойствами глобального контекста может быть добавлен постфикс "Сервер" (англ. "Server" ).
Например: РегламентныеЗаданияСервер , ОбменДаннымиСервер, ScheduledJobsServer .

2.2. Серверные общие модули для вызова с клиента содержат серверные процедуры и функции, доступные для использования из клиентского кода. Они составляют клиентский программный интерфейс сервера приложения.
Такие процедуры и функции размещаются в общих модулях с признаком:

Серверные общие модули для вызова с клиента называются по общим правилам именования объектов метаданных и должны именоваться с постфиксом "ВызовСервера" (англ. "ServerCall" ).
Например: РаботаСФайламиВызовСервера, CommonServerCall .

Следует иметь в виду, что экспортные процедуры и функции в таких общих модулях не должны содержать параметров мутабельных типов ( СправочникОбъект , ДокументОбъект и т.п.), так как их передача из (или в) клиентского кода невозможна.

2.3. Клиентские общие модули содержат клиентскую бизнес-логику (функциональность, определенную только для клиента) и имеют признаки:
- Клиент (управляемое приложение) ,
- Клиент (обычное приложение) .
Исключение составляют случаи, когда клиентские процедуры и функции должны быть доступны только в режиме управляемого приложения (только в режиме обычного приложения или только в режиме внешнего соединения). В таких случаях, допустима иная комбинация двух этих признаков.

Клиентские общие модули именуются с постфиксом "Клиент" (англ. "Client" ).
Например: РаботаСФайламиКлиент , ОбщегоНазначенияКлиент, StandardSubsystemsClient .

2.4. Для того чтобы избежать дублирования кода, рекомендуется создавать клиент-серверные общие модули с теми процедурами и функциями, содержание которых одинаково на сервере и на клиенте. Такие процедуры и функции размещаются в общих модулях с признаками:
- Клиент (управляемое приложение) ,
- Сервер (флажок Вызов сервера сброшен),
- Клиент (обычное приложение) ,
- Внешнее соединение .
Общие модули этого вида именуются с постфиксом "КлиентСервер" (англ. "ClientServer" ).
Например: РаботаСФайламиКлиентСервер , ОбщегоНазначенияКлиентСервер, UsersClientServer .

В то же время, как только возникает необходимость ветвить код в клиент-серверных общих модулях на серверный и клиентский, то не следует использовать для этого инструкции препроцессора. Вместо этого, функциональность, различную для клиента и для сервера, рекомендуется реализовывать по общим правилам в модулях соответствующего типа – см. пп. 2.1 и 2.3. Такое явное разделение клиентской и серверной бизнес-логики продиктовано соображениями повышения модульности прикладного решения, упрощения контроля со стороны разработчика над клиент-серверным взаимодействием и снижением риска ошибок из-за принципиальных отличий требований к разработке клиентского и серверного кода (необходимость минимизации кода, выполняемого на клиенте, разной доступностью объектов и типов платформы и др.). При этом нужно иметь в виду неизбежное увеличение числа общих модулей в конфигурации.

Особым случаем смешанных клиент-серверных модулей являются модули форм и команд, которые специально предназначены для реализации серверной и клиентской бизнес-логики в одном модуле.

3.1. Имена общих модулей рекомендуется строить по общим правилам именования объектов метаданных. Название общего модуля должно совпадать с названием подсистемы или отдельного механизма, процедуры и функции которой он реализует. Рекомендуется избегать в названиях общих модулей таких общих слов как "Процедуры", "Функции", "Обработчики", "Модуль", "Функциональность" и т.п. и применять их только в исключительных случаях, когда они более полно раскрывают назначение модуля.

Для того чтобы различать общие модули одной подсистемы, которые созданы для реализации процедур и функций, выполняемых в разных контекстах, рекомендуется задавать им постфиксы, описанные ранее в пп. 2.1-2.4.

3.2. Дополнительно к общим модулям могут быть добавлены уточняющие постфиксы.

3.2.1. Для глобальных модулей добавляется постфикс "Глобальный" (англ. "Global" ), в этом случае постфикс "Клиент" добавлять не следует.
Например: РаботаСФайламиГлобальный, InfobaseUpdateGlobal .

3.2.2. Модули, выполняющиеся в привилегированном режиме, имеющие признак Привилегированный , именуются с постфиксом "ПолныеПрава" (англ. "FullAccess" ).
Например: РаботаСФайламиПолныеПрава .

3.2.3. Модули, предназначенные для реализации на сервере или на клиенте функций с повторным использованием возвращаемых значений (на время вызова или на время сеанса), именуются с постфиксом "ПовтИсп" (англ. "Cached" ) и "КлиентПовтИсп" (англ. "ClientCached" ) соответственно.
Например: РаботаСФайламиКлиентПовтИсп, UsersInternalCached .

3.2.4. Серверные и клиентские модули библиотечных конфигураций (которые предназначены не для самостоятельного использования, а для разработки других конфигураций) с процедурами и функциями, допускающие изменение своей реализации, именуются с постфиксами "Переопределяемый" (англ. "Overridable" ) и "КлиентПереопределяемый" (англ. "ClientOverridable" ).
Например: РаботаСФайламиКлиентПереопределяемый, CommonOverridable .

3.2.5. В локализуемых конфигурациях, на базе которых выпускаются национальные прикладные решения для различных стран или регионов, модули, реализующие национальную специфику, именуются с постфиксами "Локализация" (англ. "Localization" ) и "КлиентЛокализация" (англ. "Client Localization " ).
Например: ЭлктроннаяПодписьЛокализация, ElectonicSignature Localization .

Читайте также: