стандарт 683

ID: #std683

# Общие сведения об организации хранения данных

#### 1.

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

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

#### 2.

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

```mermaid
flowchart TB
    subgraph STORAGE["Хранение данных"]

        BLOCK1["<b>1. Условно-постоянная информация</b><br/>────────────────────────<br/>Константы<br/>Справочники<br/>Перечисления<br/>Планы видов характеристик<br/>Планы счетов<br/>Планы видов расчета"]

        BLOCK2["<b>2. События процессов предметной области</b><br/>────────────────────────<br/>Документы<br/>Бизнес-процессы<br/>Задачи"]

        BLOCK3["<b>3. Накопленные сведения, значения показателей</b><br/>────────────────────────<br/>Регистры сведений<br/>Регистры накопления<br/>Регистры бухгалтерии<br/>Регистры расчета"]

        BLOCK2 --> BLOCK1
        BLOCK3 --> BLOCK1
        BLOCK3 --> BLOCK2

    end

    REPORTS["Получение отчетности и обработка данных<br/>────────────────────────<br/>Отчеты<br/>Обработки"]

    STORAGE <--> REPORTS
```

*Стрелки на схеме обозначают взаимосвязи между данными (взаимные ссылки).*

На схеме выделяются три блока:

1. **Условно-постоянная информация**.
   Информация вводится один раз,
   сравнительно редко меняется
   и многократно используется.
   Примеры: классификаторы,
   настройки,
   перечни,
   реестры,
   нормативно-справочная информация.
2. **События процессов предметной области**.
   События привязаны ко времени
   и при регистрации
   могут порождать сведения
   или изменять значения показателей.
   Примеры: документооборот,
   учетные события,
   регистрация заявок и звонков.
3. **Накопленные сведения, значения показателей**.
   Данные характеризуют процессы
   и текущее состояние прикладной области.
   В отличие от первых двух блоков,
   это данные необъектной природы:
   они не являются самостоятельными сущностями.
   Примеры: история продаж,
   остатки на складах,
   текущий баланс,
   история курсов валют.

Отдельно выделяются средства анализа и обработки данных:
отчеты и механизмы,
которые опираются на данные всех блоков,
но сами данные не хранят.

Подробнее о задачах и принципах хранения информации:
книга
[«Профессиональная разработка в системе 1С Предприятие 8»](https://buh.ru/books/detail.php?ID=42696),
глава 6.

#### 2.1.

Упрощенно,
для каждой сущности предметной области
сначала выберите блок:

- если нужно хранить сравнительно редко изменяющуюся информацию,
  не привязанную ко времени,
  выбирайте блок условно-постоянной информации (`1`);
- если нужно регистрировать события,
  требующие документального подтверждения,
  и отслеживать последовательность на временной оси,
  выбирайте блок событий процессов (`2`);
- в остальных случаях
  относите сущность
  к блоку сведений и значений показателей (`3`).

Развернутые критерии выбора блока:

#### Условно-постоянная информация

| Критерий | Значение |
| --- | --- |
| Основное предназначение | Хранение нормативно-справочной информации и реестров. |
| Отслеживание изменения состояния | Не требуется. |
| Иерархия и группировка данных | Требуется, в том числе между разными сущностями. |
| Ключевые свойства | Нужны `Наименование` и `Код`. |
| Хранение значений дополнительных реквизитов сущности | Нужно хранить редко изменяемые реквизиты произвольных данных. |
| Нумерация | Нужны серии кодов по всем элементам типа или в пределах иерархии. |

#### События процессов предметной области

| Критерий | Значение |
| --- | --- |
| Основное предназначение | Регистрация событий процессов и документальное подтверждение сведений. |
| Отслеживание изменения состояния | Требуется. Например: регистрация/отмена регистрации документа, учет запусков и окончаний процесса, смена состояния задач, формирование движений. |
| Иерархия и группировка данных | Не требуется. |
| Ключевые свойства | Нужно учитывать дату события и его номер. |
| Хранение значений дополнительных реквизитов сущности | Нужно хранить ссылки на другие объекты и параметры, характеризующие событие. |
| Нумерация | Нужны серии номеров по всем элементам данного типа или в пределах периода по дате, включая сквозную нумерацию объектов разных типов. |

#### Накопленные сведения, значения показателей

| Критерий | Значение |
| --- | --- |
| Основное предназначение | Хранение данных, характеризующих процессы и текущее состояние прикладной области. |
| Отслеживание изменения состояния | Не требуется. |
| Иерархия и группировка данных | Не требуется. |
| Ключевые свойства | Не требуется. |
| Хранение значений дополнительных реквизитов сущности | Нужно хранить только значения реквизитов для других объектов базы. |
| Нумерация | Не требуется. |

#### 2.2.

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

#### Уточнение

Для пп. `2.2.1`-`2.2.3`
область применения:
`управляемое приложение`, `обычное приложение`.

#### 2.2.1.

Для хранения условно-постоянной информации:

1. Для хранения плана счетов
   по [принципам двойной записи](https://its.1c.ru/db/garant/content/10036812/hdoc/1)
   используйте объект метаданных
   [«План счетов»](https://its.1c.ru/db/v8devgloss/content/28/hdoc/01).
2. Для хранения перечня видов расчета
   для [учета начислений и удержаний](https://its.1c.ru/db/garant/content/12025268/hdoc/1020)
   используйте объект метаданных
   [«План видов расчета»](https://its.1c.ru/db/v8devgloss/content/28/hdoc/03).
3. Для хранения списка характеристик,
   когда состав списка,
   тип характеристик
   и их состав определяет пользователь,
   используйте
   [«План видов характеристик»](https://its.1c.ru/db/v8devgloss/content/28/hdoc/02).
4. Для хранения одиночного значения,
   редактируемого пользователем
   (обычно администратором)
   и не требующего ссылок из других данных,
   используйте
   [«Константа»](https://its.1c.ru/db/v8devgloss/content/26/hdoc).
5. Для фиксированного списка значений,
   который не редактируется пользователем
   и не имеет дополнительных реквизитов,
   используйте
   [«Перечисление»](https://its.1c.ru/db/v8devgloss/content/62/hdoc).
6. В остальных случаях,
   как правило,
   используйте
   [«Справочник»](https://its.1c.ru/db/v8devgloss/content/22/hdoc).

Развернутые критерии выбора типа объекта:

#### Константа

| Критерий | Значение |
| --- | --- |
| Основное предназначение | Хранение одиночных значений, предопределенных данных. |
| Добавление и редактирование пользователем | Требуется только изменение значения. |
| Иерархия и группировка данных | Не требуется. |
| Хранение значений дополнительных реквизитов сущности | Не требуется. |
| Хранение списков значений дополнительных реквизитов | Не требуется. |
| Возможность ввода на основании других объектов | Не требуется. |
| Нумерация | Не требуется. |

#### Перечисление

| Критерий | Значение |
| --- | --- |
| Основное предназначение | Хранение списка неизменных представлений без дополнительных атрибутов. |
| Добавление и редактирование пользователем | Не требуется. |
| Иерархия и группировка данных | Не требуется. |
| Хранение значений дополнительных реквизитов сущности | Не требуется. |
| Хранение списков значений дополнительных реквизитов | Не требуется. |
| Возможность ввода на основании других объектов | Не требуется. |
| Нумерация | Не требуется. |

#### План видов характеристик

| Критерий | Значение |
| --- | --- |
| Основное предназначение | Хранение списка сущностей и значений характеристик экземпляров сущности. |
| Добавление и редактирование пользователем | Требуется добавление, удаление, изменение элементов, редактирование состава и значений характеристик сущности. |
| Иерархия и группировка данных | Требуется в пределах одной сущности. |
| Хранение значений дополнительных реквизитов сущности | Нужно хранить произвольные данные для атрибутов сущности. |
| Хранение списков значений дополнительных реквизитов | Требуется хранение списков наборов значений реквизитов для сущности. |
| Возможность ввода на основании других объектов | Нужен ввод новых элементов с использованием информации других объектов. |
| Нумерация | Нужны серии кодов по всем элементам одного типа или в пределах группировки. |

#### Справочник

| Критерий | Значение |
| --- | --- |
| Основное предназначение | Хранение списка объектов и значений их атрибутов. |
| Добавление и редактирование пользователем | Требуется добавление, удаление и изменение элементов. |
| Иерархия и группировка данных | Требуется в пределах одной сущности или между разными сущностями. |
| Хранение значений дополнительных реквизитов сущности | Нужно хранить произвольные данные для атрибутов сущности. |
| Хранение списков значений дополнительных реквизитов | Требуется хранение списков наборов значений реквизитов для сущности. |
| Возможность ввода на основании других объектов | Нужен ввод новых элементов с использованием информации других объектов. |
| Нумерация | Нужны серии кодов по всем элементам одного типа, в пределах группировки или подчинения. |

#### 2.2.2.

Для хранения событий процессов предметной области:

1. Если нужен учет одиночных событий,
   адресованных исполнителю
   (пользователю,
   сотруднику,
   группе,
   роли)
   и не требующих формирования движений,
   используйте
   [«Задача»](https://its.1c.ru/db/v8devgloss/content/94/hdoc).
2. Если нужно регистрировать возникновение
   и ход регулярного процесса
   как последовательность действий,
   используйте
   [«Бизнес-процесс»](https://its.1c.ru/db/v8devgloss/content/42/hdoc).
   Для учета событий в рамках процесса
   используйте
   [«Задача»](https://its.1c.ru/db/v8devgloss/content/94/hdoc).
3. В остальных случаях,
   как правило,
   используйте
   [«Документ»](https://its.1c.ru/db/v8devgloss/content/23/hdoc).

Развернутые критерии выбора типа объекта:

#### Задача

| Критерий | Значение |
| --- | --- |
| Основное предназначение | Учет одиночных событий, адресованных исполнителям. |
| Вложенность | Не требуется. |
| Объединение в журналы | Не требуется. |
| Состояние объекта | Нужны состояния `новый`, `выполнено`. |
| Нумерация | Нужны серии номеров по всем задачам данного вида или в пределах периода по дате. |

#### Бизнес-процесс (с задачами)

| Критерий | Значение |
| --- | --- |
| Основное предназначение | Учет последовательности событий, адресованных исполнителям. |
| Вложенность | Нужен учет процессов, вложенных в другие процессы (иерархия задач). |
| Объединение в журналы | Не требуется. |
| Состояние объекта | Нужны состояния `новый`, `в работе`, `завершен`. |
| Нумерация | Нужны серии номеров по всем процессам данного вида или в пределах периода по дате, плюс нумерация событий внутри процесса. |

#### Документ

| Критерий | Значение |
| --- | --- |
| Основное предназначение | Регистрация событий во времени и генерация вторичных данных, соответствующих этим событиям. |
| Вложенность | Не требуется. |
| Объединение в журналы | Нужно объединение документов разных видов в одном журнале. |
| Состояние объекта | Нужны состояния `проведен`, `не проведен`. |
| Нумерация | Нужны серии номеров для документов разных видов: сквозные или в пределах периода по дате. |

#### 2.2.3.

Для хранения накопленных сведений
и значений показателей:

1. Для хранения данных учета
   с использованием
   [принципа двойной записи](https://its.1c.ru/db/garant/content/10036812/hdoc/1)
   используйте
   [«Регистр бухгалтерии»](https://its.1c.ru/db/v8devgloss/content/20/hdoc/04).
2. Для хранения результатов расчета
   [учета начислений и удержаний](https://its.1c.ru/db/garant/content/12025268/hdoc/1020)
   используйте
   [«Регистр расчета»](https://its.1c.ru/db/v8devgloss/content/20/hdoc/05).
3. Если требуется хранить изменения показателей
   (приход/расход)
   и получать остатки и обороты за период,
   используйте
   [«Регистр накопления»](https://its.1c.ru/db/v8devgloss/content/151/hdoc).
4. Во всех остальных случаях
   используйте
   [«Регистр сведений»](https://its.1c.ru/db/v8devgloss/content/152/hdoc).

Развернутые критерии выбора типа объекта:

#### Регистр накопления

| Критерий | Значение |
| --- | --- |
| Основное предназначение | Хранение изменений данных (приход и расход значений показателей). |
| Получение данных | Нужно получать остатки и обороты. |
| Подтверждение происхождения данных | Требуется обязательная связь с регистрирующим документом. |

#### Регистр сведений

| Критерий | Значение |
| --- | --- |
| Основное предназначение | Хранение информации в виде наборов записей, регистрация сведений и значений. |
| Получение данных | Нужно получать срез на момент времени или текущее значение показателей. |
| Подтверждение происхождения данных | Связь с регистрирующим документом не обязательна. |

#### 3.

Пример выбора типов объектов метаданных.

Пусть организация
периодически проводит анкетирование.
При заполнении анкеты
указывается дата анкетирования,
набор вопросов
и набор ответов.
Сущность `Анкета`
привязана к дате
и порождает статистику
(ответы на вопросы).

Следовательно:

- это периодическое событие,
  привязанное ко времени,
  которое порождает значения параметров,
  то есть второй блок
  «события предметной области»;
- внутри второго блока
  это должен быть `Документ`,
  потому что анкета
  формирует вторичные данные
  (результаты ответов на вопросы).

#### Источник

https://its.1c.ru/db/v8std#content:683

Общие сведения об организации хранения данных #std683


стандарт 686

ID: #std686

# Работа с параметром "Отказ" в обработчиках событий

#### 1.

Параметру `Отказ` не присваивайте `Ложь`.

Если ему присвоить `Ложь`, то можно случайно сбросить ранее установленный `Истина`.

Установка `Ложь` может быть неявной: через булеву функцию. Потому и результат функции тоже не присваивайте.

#### Неправильно

```bsl
Процедура ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
    ...
    Отказ = ЕстьОшибки();
    ...
КонецПроцедуры
```
и
```bsl
Процедура ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
    ...
    Отказ = Ложь;
    ...
КонецПроцедуры
```

#### Правильно

```bsl
Процедура  ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
    ...
    Если ЕстьОшибки() Тогда
        Отказ = Истина;
    КонецЕсли;
    ...
КонецПроцедуры
```
или
```bsl
Отказ = Отказ Или ЕстьОшибки();
```

#### Проверки
[#v8cs:event-heandler-boolean-param](https://v8std.ru/diagnostics/v8-code-style/event-heandler-boolean-param/)

#### 2.

Вообще это правило подходит для любых возвращаемых булевых параметров, например `СтандартнаяОбработка`, `Выполнение`.

#### 3.

Если устанавливаете параметр `Отказ` в `Истина`, то объясняйте пользователю что случилось.

Платформа покажет сообщение об ошибке с текстом, например `Не удалось записать "Заказ покупателя"!`, из которого пользователь не поймет что именно произошло.

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

#### См. также

- [#std499: Перехват исключений в коде](https://v8std.ru/std/499/)

#### Проверки
[#bslls:UsingCancelParameter](https://v8std.ru/diagnostics/bslls/UsingCancelParameter/)

[#acc:144](https://v8std.ru/diagnostics/acc/144/)
#### Источник

https://its.1c.ru/db/v8std#content:686

Параметру Отказ не присваивайте Ложь.

Присвоение параметру "Отказ" значения, отличного от "Истина". АПК:144

Работа с параметром "Отказ" BSLLS:UsingCancelParameter

Использование булевого параметра обработчика события (event-heandler-boolean-param)

Перехват исключений в коде #std499

Работа с параметром "Отказ" в обработчиках событий #std686


стандарт 689

ID: #std689

# Настройка ролей и прав доступа

Действует для конфигураций УП (ERP), УТ 11 и входящих в них библиотек.
Для других конфигураций рекомендуется к применению.

#### 1.

Общие положения.

#### 1.1.

Стройте роли атомарно: одна роль должна покрывать одну элементарную функцию.

Из атомарных ролей формируйте профили пользователей.
Профили назначайте пользователям средствами БСП.

#### 1.2.

Роли `ПолныеПрава` и `АдминистраторСистемы` обеспечивают максимальный доступ.
Подробности: [#std488: Стандартные роли](https://v8std.ru/std/488/)

#### 1.3.

Ни одна роль, включая `ПолныеПрава` и `АдминистраторСистемы`, не должна давать интерактивное удаление ссылочных объектов.

После добавления нового объекта проверяйте это в роли `ПолныеПрава`.

#### 1.4.

Права на удаление ссылочных объектов должны быть только у ролей `ПолныеПрава` и `АдминистраторСистемы`.

#### 1.5.

Флаг «Устанавливать права для новых объектов» оставляйте только у роли `ПолныеПрава`.
Для остальных ролей флаг должен быть снят.

#### 1.6.

Если право нужно только администратору (например, запуск служебной обработки), отдельную роль создавать не нужно.
Достаточно `ПолныеПрава` или `АдминистраторСистемы`.

#### 1.7.

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

Исключение: документы, предназначенные для прямой корректировки регистров.

#### Проверки
[#v8cs:document-post-in-privileged-mode](https://v8std.ru/diagnostics/v8-code-style/document-post-in-privileged-mode/)

#### 1.8.

Для функциональных опций обычно включайте привилегированный режим получения.

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

#### Проверки
[#v8cs:functional-option-privileged-get-mode](https://v8std.ru/diagnostics/v8-code-style/functional-option-privileged-get-mode/)

#### 1.9.

Кроме стандартных ролей БСП не создавайте роли, дающие общие системные права (`Администрирование`, `ТонкийКлиент` и т.п.).

#### 1.10.

Для неконфиденциальных и общедоступных данных права чтения включайте в:

- `БазовыеПрава`;
- `БазовыеПраваВнешнихПользователей` (если есть внешние пользователи).

#### 1.11.

Одна роль не должна объединять права на объекты разных библиотек и разных подсистем.
Подробности: [#std668: Разработка ролей в библиотеках](https://v8std.ru/std/668/)

#### 2.

Правила создания ролей к элементарным функциям.

#### 2.1.

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

Если объекты в одной функции, должно быть невозможно корректно настроить доступ к ним раздельно.

#### 2.2.

Если есть сомнение, относятся ли два объекта к одной функции, разделяйте их.

#### 2.3.

Каждый объект должен быть отнесен ровно к одной элементарной функции.

#### 2.4.

Объекты разных библиотек не объединяйте в одну элементарную функцию.

#### 3.

Ссылочные объекты и регистры.

#### 3.1.

Для функций со ссылочными объектами и независимыми регистрами сведений обычно создавайте две роли:

- `Чтение` (`Read`);
- `ДобавлениеИзменение` или `Изменение`.

Роль изменения должна включать права роли чтения плюс права изменения.

#### 3.2.

Для регистров, подчиненных регистратору, права изменения обычно не назначают (см. п. 1.7).

#### 4.

Журналы документов.

#### 4.1.

Если все документы журнала относятся к одной элементарной функции, права чтения и просмотра журнала включайте в роли этой функции.

#### 4.2.

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

#### 5.

Константы.

#### 5.1.

Если константу должен менять только администратор, права изменения должны быть только у `ПолныеПрава` и/или `АдминистраторСистемы`.

#### 5.2.

Если константу может менять пользователь, добавляйте права в существующую настроечную роль или создавайте отдельную роль `Изменение`.

#### 5.3.

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

#### 5.4.

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

#### 6.

Подсистемы, отображаемые в главном командном интерфейсе.

#### 6.1.

Для каждой подсистемы верхнего уровня создавайте роль `Подсистема` (`Subsystem`) с правом просмотра.

#### 6.2.

Если часть функций подсистемы вынесена в отдельную форму (например, «Настройки и справочники»), роль подсистемы должна включать права просмотра этой формы.

#### 7.

Отчеты.

#### 7.1.

Если отчет построен на данных одной элементарной функции, права на отчет можно включать в роли этой функции.

#### 7.2.

Если на внедрении может понадобиться отдельная настройка доступа к отчету, создавайте отдельную роль `ПросмотрОтчета`.

#### 7.3.

Если отчет использует данные из нескольких элементарных функций, создавайте отдельную роль `ПросмотрОтчета`.

#### 7.4.

Однотипные отчеты можно объединять в одну элементарную функцию, если:

- отчеты не входят в другие элементарные функции;
- на внедрении не требуется различная настройка доступа к этим отчетам.

#### 8.

Обработки и общие формы.

#### 8.1.

Для каждой обработки-рабочего места (есть отдельная команда в интерфейсе) создавайте роль `ИспользованиеОбработки` (`UseDataProcessor`).

#### 8.2.

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

#### 8.3.

Права к обработкам только для администратора назначайте только через `ПолныеПрава` и/или `АдминистраторСистемы`.

#### 8.4.

Те же правила применяются к общим формам.
Для общих форм используйте роль `ИспользованиеОбщейФормы`.

#### 8.5.

Исключения из этого подхода допустимы только в явно обоснованных сценариях проектирования интерфейса (см. п. 6.2).

#### 9.

Команды.

#### 9.1.

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

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

#### 9.2.

Для команды, которая изменяет данные, право просмотра назначайте роли, дающей право изменения соответствующих объектов.

#### 10.

Права, не связанные с доступом к объектам.

#### 10.1.

Если нужно выдать дополнительное прикладное право, создавайте отдельную роль ``, которая не дает доступ к объектам метаданных.

В имени роли не используйте слово `Право`.

#### 10.2.

В коде проверяйте наличие такой роли.
Пользователь с ролью `ПолныеПрава` должен проходить проверку без добавления этой роли в профиль.

Для проверки используйте `Пользователи.РолиДоступны`.

#### 10.3.

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

#### 11.

Права для внешних пользователей.

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

Например:

- `СамообслуживаниеОформлениеПретензий`;
- `СамообслуживаниеПросмотрОтчетаСостояниеВыполненияЗаказа`;
- `СамообслуживаниеДобавлениеИзменениеКонтрагентов`.

#### 12.

Права к устаревшим объектам.

Объекты метаданных с префиксом `Удалить` исключайте из всех ролей, кроме `ПолныеПрава` и `АдминистраторСистемы`.

#### См. также

- [#std488: Стандартные роли](https://v8std.ru/std/488/)
- [#std485: Использование привилегированного режима](https://v8std.ru/std/485/)
- [#std534: Удаление устаревших объектов метаданных из конфигурации](https://v8std.ru/std/534/)
- [#std658: Эффективные условия запросов](https://v8std.ru/std/658/)
- [#std668: Разработка ролей в библиотеках](https://v8std.ru/std/668/)
- [#std705: Отнесение библиотечных объектов к подсистемам](https://v8std.ru/std/705/)
- [#std737: Проверка прав доступа](https://v8std.ru/std/737/)

#### Проверки
[#v8cs:using-isinrole](https://v8std.ru/diagnostics/v8-code-style/using-isinrole/)

[#acc:226](https://v8std.ru/diagnostics/acc/226/)
[#acc:227](https://v8std.ru/diagnostics/acc/227/)
[#acc:228](https://v8std.ru/diagnostics/acc/228/)
[#acc:229](https://v8std.ru/diagnostics/acc/229/)
[#acc:232](https://v8std.ru/diagnostics/acc/232/)
[#acc:233](https://v8std.ru/diagnostics/acc/233/)
[#acc:234](https://v8std.ru/diagnostics/acc/234/)
[#acc:290](https://v8std.ru/diagnostics/acc/290/)
[#acc:291](https://v8std.ru/diagnostics/acc/291/)
[#acc:336](https://v8std.ru/diagnostics/acc/336/)
[#acc:359](https://v8std.ru/diagnostics/acc/359/)
[#acc:360](https://v8std.ru/diagnostics/acc/360/)
[#acc:375](https://v8std.ru/diagnostics/acc/375/)
[#acc:419](https://v8std.ru/diagnostics/acc/419/)
[#acc:420](https://v8std.ru/diagnostics/acc/420/)
[#acc:421](https://v8std.ru/diagnostics/acc/421/)
[#acc:422](https://v8std.ru/diagnostics/acc/422/)
[#acc:423](https://v8std.ru/diagnostics/acc/423/)
[#acc:424](https://v8std.ru/diagnostics/acc/424/)
[#acc:442](https://v8std.ru/diagnostics/acc/442/)
[#acc:443](https://v8std.ru/diagnostics/acc/443/)
[#acc:507](https://v8std.ru/diagnostics/acc/507/)
[#acc:508](https://v8std.ru/diagnostics/acc/508/)
[#acc:510](https://v8std.ru/diagnostics/acc/510/)
[#acc:511](https://v8std.ru/diagnostics/acc/511/)
[#acc:512](https://v8std.ru/diagnostics/acc/512/)
[#acc:513](https://v8std.ru/diagnostics/acc/513/)
[#acc:541](https://v8std.ru/diagnostics/acc/541/)
[#acc:1375](https://v8std.ru/diagnostics/acc/1375/)
#### Источник

https://its.1c.ru/db/v8std#content:689

В правах роли установлены ограничения (RLS) для устаревшего объекта метаданных. АПК:1375

В документе, предполагающем проведение, не установлен флаг "Привилегированный режим при проведении". АПК:226

В документе, предполагающем проведение, не установлен флаг "Привилегированный режим при отмене проведения". АПК:227

В функциональной опции не установлен флаг "Привилегированный режим при получении". АПК:228

В роли есть право на изменение регистра, подчиненного регистратору. АПК:229

Неверно установлены права на константу. АПК:232

Для подсистемы верхнего уровня, отображаемой в командном интерфейсе, не найдено роли. АПК:233

В роли не установлено право просмотра для подсистемы. АПК:234

Неверно установлены права в роли для чтения. АПК:290

Неверно установлены права в роли для изменения. АПК:291

Использован метод "РольДоступна()". АПК:336

Ограничения на уровне записей в разных ролях не совпадает для той же таблицы и права. АПК:359

Ограничения для права "Добавление" не совпадает с ограничением права "Изменение". АПК:360

Избыточно установлены права на устаревший объект метаданных (с префиксом "Удалить"). АПК:375

В правах роли установлены ограничения (RLS) для объекта метаданных. АПК:419

В праве "Удаление" роли установлены ограничения (RLS) для объекта метаданных. АПК:420

Права на константу установлены в обеих ролях: "Полные права" и "Администратор системы". АПК:421

Права на константу не установлены ни в одной из ролей: "Полные права" и "Администратор системы". АПК:422

Для роли "Изменение" установлены права на другой объект метаданных. АПК:423

Для роли "Чтение" установлены права на другой объект метаданных. АПК:424

Ошибка выполнения проверки: не удалось получить версию БСП. АПК:442

Ошибка выполнения проверки: не удалось получить назначение ролей пользователей. АПК:443

Роль дает права на объекты других подсистем. АПК:507

Неверно заданы права на обработку (должны быть у ИспользованиеОбработки, БазовыеПрава или Подсистема). АПК:508

Ни в одной роли нет прав на просмотр команды. АПК:510

Неверно заданы права на команду (есть права на просмотр команды, но нет прав на чтение или просмотр объекта). АПК:511

Неверно заданы права на команду (есть права на чтение или просмотр объекта, но нет прав на просмотр команды). АПК:512

Неверно заданы права на команду (права на команды печати должны быть назначены роли "БазовыеПрава"). АПК:513

Неверно установлены права базовой роли на объект метаданных. АПК:541

В документе, предполагающем проведение, не установлен флаг "Привилегированный режим при проведении / отмене проведения" (document-post-in-privileged-mode)

В функциональной опции не установлен флаг "Привилегированный режим при получении" (functional-option-privileged-get-mode)

Использован метод "РольДоступна" (using-isinrole)

Использование привилегированного режима #std485

Стандартные роли #std488

Удаление устаревших объектов метаданных из конфигурации #std534

Эффективные условия запросов #std658

Разработка ролей в библиотеках #std668

Отнесение объектов библиотек к подсистемам #std705

Проверка прав доступа #std737

Настройка ролей и прав доступа #std689


стандарт 690

ID: #std690

# Обработчики обновления информационной базы

Стандарт действует для конфигураций на базе Библиотеки стандартных подсистем (БСП) и уточняет требования других стандартов.

Подробности по подсистеме см. в документации ИТС: https://its.1c.ru/db/bspdoc.

#### 1.

Основные сведения о библиотеке (основной конфигурации)

#### 1.1.

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

- имя;
- версию;
- список обработчиков обновления;
- зависимости от других библиотек.

Эти сведения размещайте в специальном общем модуле, имя которого начинается с `ОбновлениеИнформационнойБазы...`.

Пример: в УТ 11 модуль называется `ОбновлениеИнформационнойБазыУТ`.

Имена модулей всех используемых библиотек явно перечисляйте в общем модуле `ПодсистемыКонфигурацииПереопределяемый`:

```bsl
Процедура ПриДобавленииПодсистем(МодулиПодсистем) Экспорт

    МодулиПодсистем.Добавить("ОбновлениеИнформационнойБазыУТ");

КонецПроцедуры
```

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

При создании общего модуля `ОбновлениеИнформационнойБазы...` используйте шаблон:

#### Шаблон модуля

```bsl
////////////////////////////////////////////////////////////////////////////////
// Обновление информационной базы <библиотеки или конфигурации>.
//
/////////////////////////////////////////////////////////////////////////////

#Область ПрограммныйИнтерфейс

#Область ДляВызоваИзДругихПодсистем

// СтандартныеПодсистемы.ОбновлениеВерсииИБ

#Область СведенияОБиблиотекеИлиКонфигурации

// Заполняет основные сведения о библиотеке или основной конфигурации.
// Библиотека, имя которой имя совпадает с именем конфигурации в метаданных, определяется как основная конфигурация.
//
// Параметры:
//  Описание - Структура:
//
//   * Имя                 - Строка - имя библиотеки, например, "СтандартныеПодсистемы".
//   * Версия              - Строка - версия в формате из 4-х цифр, например, "2.1.3.1".
//
//   * ИдентификаторИнтернетПоддержки - Строка - уникальное имя программы в сервисах Интернет-поддержки.
//   * ТребуемыеПодсистемы - Массив - имена других библиотек (Строка), от которых зависит данная библиотека.
//                                    Обработчики обновления таких библиотек должны быть вызваны ранее
//                                    обработчиков обновления данной библиотеки.
//                                    При циклических зависимостях или, напротив, отсутствии каких-либо зависимостей,
//                                    порядок вызова обработчиков обновления определяется порядком добавления модулей
//                                    в процедуре ПриДобавленииПодсистем общего модуля
//                                    ПодсистемыКонфигурацииПереопределяемый.
//   * РежимВыполненияОтложенныхОбработчиков - Строка - "Последовательно" - отложенные обработчики обновления выполняются
//                                    последовательно в интервале от номера версии информационной базы до номера
//                                    версии конфигурации включительно или "Параллельно" - отложенный обработчик после
//                                    обработки первой порции данных передает управление следующему обработчику, а после
//                                    выполнения последнего обработчика цикл повторяется заново.
//   * ЗаполнятьДанныеНовыхПодсистемПриПереходеСДругойПрограммы - Булево - если установить Истина, то при переходе с
//                                    другой программы будут автоматически выполнены обработчики начального заполнения
//                                    новых подсистем. При описании обработчика обновления можно при необходимости
//                                    отключить его выполнение, указав свойство НеВыполнятьПриПереходеСДругойПрограммы.
//
Процедура ПриДобавленииПодсистемы(Описание) Экспорт

    Описание.Имя    = "<Имя библиотеки>";
    Описание.Версия = "XX.XX.XX.XX";
    Описание.ТребуемыеПодсистемы.Добавить("СтандартныеПодсистемы");
    Описание.РежимВыполненияОтложенныхОбработчиков = "Последовательно";

КонецПроцедуры

#КонецОбласти

#Область ОбработчикиОбновленияИнформационнойБазы

// Добавляет в список процедуры-обработчики обновления данных ИБ
// для всех поддерживаемых версий библиотеки или конфигурации.
// Вызывается перед началом обновления данных ИБ для построения плана обновления.
//
// Параметры:
//  Обработчики - см. ОбновлениеИнформационнойБазы.НоваяТаблицаОбработчиковОбновления
//
// Пример:
//  Для добавления своей процедуры-обработчика в список:
//  Обработчик = Обработчики.Добавить();
//  Обработчик.Версия              = "1.1.0.0";
//  Обработчик.Процедура           = "ОбновлениеИБ.ПерейтиНаВерсию_1_1_0_0";
//  Обработчик.РежимВыполнения     = "Оперативно";
//
Процедура ПриДобавленииОбработчиковОбновления(Обработчики) Экспорт

    // Обработчики, выполняемые при каждом обновлении ИБ

    // Обработчики, выполняемые при переходе на определенную версию

    // Обработчики, выполняемые при заполнении пустой ИБ

КонецПроцедуры

// См. ОбновлениеИнформационнойБазыПереопределяемый.ПередОбновлениемИнформационнойБазы.
Процедура ПередОбновлениемИнформационнойБазы() Экспорт

КонецПроцедуры

// Вызывается после завершения обновления данных ИБ.
// В зависимости от тех или иных условий можно отключить штатное открытие формы
// с описанием изменений в новой версии программы при первом входе в нее (после обновления),
// а также выполнить другие действия.
//
// Не рекомендуется выполнять в данной процедуре какую-либо обработку данных.
// Такие процедуры следует оформлять штатными обработчиками обновления, выполняемыми на каждую версию "*".
//
// Параметры:
//   ПредыдущаяВерсия     - Строка - версия до обновления. "0.0.0.0" для "пустой" ИБ.
//   ТекущаяВерсия        - Строка - версия после обновления. Как правило, соответствует Метаданные.Версия.
//   ВыполненныеОбработчики - ДеревоЗначений:
//     * НачальноеЗаполнение - Булево - если Истина, то обработчик должен срабатывать при запуске на "пустой" базе.
//     * Версия              - Строка - например, "2.1.3.39". Номер версии конфигурации, при переходе
//                                      на которую должна быть выполнена процедура-обработчик обновления.
//                                      Если указана пустая строка, то это обработчик только для начального заполнения
//                                      (должно быть указано свойство НачальноеЗаполнение).
//     * Процедура           - Строка - полное имя процедуры-обработчика обновления/начального заполнения.
//                                      Например, "ОбновлениеИнформационнойБазыУПП.ЗаполнитьНовыйРеквизит"
//                                      Обязательно должна быть экспортной.
//     * РежимВыполнения     - Строка - режим выполнения обработчика обновления. Допустимые значения:
//                                      Монопольно, Отложенно, Оперативно. Если значение не заполнено, обработчик
//                                      считается монопольным.
//     * ОбщиеДанные         - Булево - если Истина, то обработчик должен срабатывать до
//                                      выполнения любых обработчиков, использующих разделенные данные.
//                                      Допустимо указывать только для обработчиков с режимом выполнения Монопольно и Оперативно.
//                                      Если указать значение Истина для обработчика с режимом
//                                      выполнения Отложенно, будет выдано исключение.
//     * УправлениеОбработчиками - Булево - если Истина, то обработчик должен иметь параметр типа Структура, в котором
//                                          есть свойство РазделенныеОбработчики - таблица значений со структурой,
//                                          возвращаемой этой функцией.
//                                      При этом колонка Версия игнорируется. В случае необходимости выполнения
//                                      разделенного обработчика в данную таблицу необходимо добавить строку с
//                                      описанием процедуры обработчика.
//                                      Имеет смысл только для обязательных (Версия = *) обработчиков обновления
//                                      с установленным флагом ОбщиеДанные.
//     * Комментарий         - Строка - описание действий, выполняемых обработчиком обновления.
//     * Идентификатор       - УникальныйИдентификатор - необходимо заполнять для обработчиков отложенного обновления,
//                                                 для остальных заполнение не требуется. Требуется для идентификации
//                                                 обработчика в случае его переименования.
//
//     * БлокируемыеОбъекты  - Строка - необходимо заполнять для обработчиков отложенного обновления,
//                                      для остальных заполнение не требуется. Полные имена объектов через запятую,
//                                      которые следует блокировать от изменения до завершения процедуры обработки данных.
//                                      Если заполнено, то также требуется заполнить и свойство ПроцедураПроверки.
//     * ПроцедураПроверки   - Строка - необходимо заполнять для обработчиков отложенного обновления,
//                                      для остальных заполнение не требуется. Имя функции, которая для переданного объекта
//                                      определяет, завершена ли для него процедура обработки данных.
//                                      Если переданный объект обработан, то следует вернуть значение Истина.
//                                      Вызывается из процедуры ОбновлениеИнформационнойБазы.ПроверитьОбъектОбработан.
//                                      Параметры, передаваемые в функцию:
//                                         Параметры - см. ОбновлениеИнформационнойБазы.МетаданныеИОтборПоДанным.
//     * ПроцедураЗаполненияДанныхОбновления - Строка - указывается процедура, которая регистрирует данные,
//                                      подлежащие обновлению данным обработчиком.
//     * ЗапускатьТолькоВГлавномУзле  - Булево - только для обработчиков отложенного обновления с режимом выполнения Параллельно.
//                                      Указать Истина, если обработчик обновления должен выполняться только в главном
//                                      узле РИБ.
//     * ЗапускатьИВПодчиненномУзлеРИБСФильтрами - Булево - только для обработчиков отложенного обновления с режимом
//                                      выполнения Параллельно.
//                                      Указать Истина, если обработчик обновления должен также выполняться в
//                                      подчиненном узле РИБ с фильтрами.
//     * ЧитаемыеОбъекты              - Строка - объекты, которые обработчик обновления будет читать при обработке данных.
//     * ИзменяемыеОбъекты            - Строка - объекты, которые обработчик обновления будет изменять при обработке данных.
//     * ПриоритетыВыполнения         - ТаблицаЗначений - таблица приоритетов выполнения между отложенными обработчиками,
//                                      изменяющими или читающими одни и те же данные. Подробнее см. в комментарии
//                                      к функции ОбновлениеИнформационнойБазы.ПриоритетыВыполненияОбработчика.
//     * ВыполнятьВГруппеОбязательных - Булево - следует указывать, если обработчик требуется
//                                      выполнять в одной группе с обработчиками на версии "*".
//                                      При этом возможно менять порядок выполнения обработчика
//                                      относительно других путем изменения приоритета.
//     * Приоритет           - Число  - для внутреннего использования.
//     * МонопольныйРежим    - Неопределено
//                           - Булево - если указано Неопределено, то обработчик
//                                      должен безусловно выполняться в монопольном режиме.
//                                      Для обработчиков перехода на конкретную версию (версия <> *):
//                                        Ложь   - обработчик не требует монопольного режима для выполнения.
//                                        Истина - обработчик требует монопольного режима для выполнения.
//                                      Для обязательных обработчиков обновления (Версия = "*"):
//                                        Ложь   - обработчик не требует монопольного режима.
//                                        Истина - обработчик может требовать монопольного режима для выполнения.
//                                                 В такие обработчики передается параметр типа структура
//                                                 со свойством МонопольныйРежим (типа Булево).
//                                                 При запуске обработчика в монопольном режиме передается
//                                                 значение Истина. В этом случае обработчик должен выполнить
//                                                 требуемые действия по обновлению. Изменение параметра
//                                                 в теле обработчика игнорируется.
//                                                 При запуске обработчика в немонопольном режиме передается
//                                                 значение Ложь. В этом случае обработчик не должен вносить никакие
//                                                 изменения в ИБ.
//                                                 Если в результате анализа выясняется, что обработчику требуется
//                                                 изменить данные ИБ, следует установить значение параметра в Истина
//                                                 и прекратить выполнение обработчика.
//                                                 В этом случае оперативное (немонопольное) обновление ИБ будет
//                                                 отменено и будет выдана ошибка с требованием выполнить обновление в
//                                                 монопольном режиме.
//   ВыводитьОписаниеОбновлений - Булево - если установить Ложь, то не будет открыта форма
//                                с описанием изменений в новой версии программы. По умолчанию Истина.
//   МонопольныйРежим           - Булево - признак того, что обновление выполнилось в монопольном режиме.
//
Процедура ПослеОбновленияИнформационнойБазы(Знач ПредыдущаяВерсия, Знач ТекущаяВерсия,
        Знач ВыполненныеОбработчики, ВыводитьОписаниеОбновлений, Знач МонопольныйРежим) Экспорт

КонецПроцедуры

// См. ОбновлениеИнформационнойБазыПереопределяемый.ПриПодготовкеМакетаОписанияОбновлений.
Процедура ПриПодготовкеМакетаОписанияОбновлений(Знач Макет) Экспорт

КонецПроцедуры

// Позволяет переопределить режим обновления данных информационной базы.
// Для использования в редких (нештатных) случаях перехода, не предусмотренных в
// стандартной процедуре определения режима обновления.
//
// Параметры:
//   РежимОбновленияДанных - Строка - в обработчике можно присвоить одно из значений:
//              "НачальноеЗаполнение"     - если это первый запуск пустой базы (области данных);
//              "ОбновлениеВерсии"        - если выполняется первый запуск после обновление конфигурации базы данных;
//              "ПереходСДругойПрограммы" - если выполняется первый запуск после обновление конфигурации базы данных,
//                                          в которой изменилось имя основной конфигурации.
//
//   СтандартнаяОбработка  - Булево - если присвоить Ложь, то стандартная процедура
//                                    определения режима обновления не выполняется,
//                                    а используется значение РежимОбновленияДанных.
//
Процедура ПриОпределенииРежимаОбновленияДанных(РежимОбновленияДанных, СтандартнаяОбработка) Экспорт

КонецПроцедуры

// Добавляет в список процедуры-обработчики перехода с другой программы (с другим именем конфигурации).
// Например, для перехода между разными, но родственными конфигурациями: базовая -> проф -> корп.
// Вызывается перед началом обновления данных ИБ.
//
// Параметры:
//  Обработчики - ТаблицаЗначений:
//    * ПредыдущееИмяКонфигурации - Строка - имя конфигурации, с которой выполняется переход;
//                                           или "*", если нужно выполнять при переходе с любой конфигурации.
//    * Процедура                 - Строка - полное имя процедуры-обработчика перехода с программы
//                                           ПредыдущееИмяКонфигурации.
//                                  Например, "ОбновлениеИнформационнойБазыУПП.ЗаполнитьУчетнуюПолитику"
//                                  Обязательно должна быть экспортной.
//
// Пример:
//  Обработчик = Обработчики.Добавить();
//  Обработчик.ПредыдущееИмяКонфигурации  = "УправлениеТорговлей";
//  Обработчик.Процедура                  = "ОбновлениеИнформационнойБазыУПП.ЗаполнитьУчетнуюПолитику";
//
Процедура ПриДобавленииОбработчиковПереходаСДругойПрограммы(Обработчики) Экспорт

КонецПроцедуры

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

КонецПроцедуры

// Конец СтандартныеПодсистемы.ОбновлениеВерсииИБ

#КонецОбласти

#КонецОбласти

#КонецОбласти
```

#### 1.2.

Обработчики обновления данных ИБ предназначены для дополнительной обработки данных после реструктуризации базы:

- инициализация новых констант, новых реквизитов и реквизитов новых предопределенных элементов;
- перенос данных из устаревших структур метаданных в новые;
- генерация новых данных;
- другие операции подготовки данных.

Для автогенерируемых строк, записываемых в ИБ программно (например, при заполнении наименований предопределенных элементов), руководствуйтесь [#std784: требованиями по локализации автогенерированных данных](https://v8std.ru/std/784/)

#### 1.3.

Обработчик обновления состоит из двух частей:

- описательной: когда обработчик должен выполняться и где находится в конфигурации;
- программной: код модификации данных ИБ в экспортной процедуре.

Описание нового обработчика добавляйте в `ПриДобавленииОбработчиковОбновления` по шаблону:

```bsl
Обработчик = Обработчики.Добавить();
Обработчик.Версия = "<номер версии>";
Обработчик.Процедура = "<полное имя экспортной процедуры>";
Обработчик.НачальноеЗаполнение = {Истина|Ложь};
Обработчик.РежимВыполнения = {"Монопольно"|"Оперативно"|"Отложенно"};
```

Поля строки таблицы `Обработчики`:

- `Версия` (`Строка`): номер версии конфигурации, при обновлении на которую вызывается обработчик.
  - Формат: `Р.П.В.С` (редакция, подредакция, версия, сборка).
  - Если указано `*`, обработчик выполняется при каждом обновлении ИБ (обычно для служебных системных данных).
  - Если `Версия` не задана, `НачальноеЗаполнение` должно быть `Истина`.
- `Процедура` (`Строка`): полный путь к процедуре-обработчику, например `"Справочник.Валюты.ЗаполнитьКодДляПоиска"`.
- `НачальноеЗаполнение` (`Булево`): если `Истина`, обработчик вызывается при первом запуске пустой ИБ (`0.0.0.0`), созданной из поставки.
- `РежимВыполнения` (`Строка`): `Монопольно`, `Оперативно`, `Отложенно`.
  - `Монопольно`: без активных пользовательских сеансов, регламентных заданий, внешних соединений и веб-сервисов.
  - `Оперативно`: в редких случаях, когда важно минимизировать ожидание пользователей при динамическом переходе на исправительные релизы без изменения структуры данных.
  - `Отложенно`: в фоне, после завершения монопольных/оперативных обработчиков, когда пользователи уже могут входить в программу.

Если обязательный обработчик (`Версия = "*"`) требует определить необходимость монопольного режима программно, учитывайте двухфазный вызов:

- первый вызов: `Параметры.МонопольныйРежим = Ложь`, данные ИБ модифицировать нельзя;
- если требуется изменение данных, обработчик ставит `Параметры.МонопольныйРежим = Истина` и завершает выполнение;
- второй вызов: `Параметры.МонопольныйРежим = Истина`, данные можно модифицировать.

Если используется параллельный режим отложенного обновления (`РежимВыполненияОтложенныхОбработчиков = "Параллельно"`), применяйте отдельные требования к таким обработчикам.

#### Пример описания обработчика

```bsl
Обработчик = Обработчики.Добавить();
Обработчик.РежимВыполнения = "Монопольно";
Обработчик.Версия = "11.1.0.0";
Обработчик.Процедура = "Справочник.МойСправочник.ЗаполнитьКодДляПоиска";
```

#### Пример реализации обработчика

```bsl
// Обработчик обновления УТ 11.1.0.0
//
// Перебираются все элементы справочника, в которых не заполнен код для поиска,
// и заполняется кодом справочника без лидирующих нулей и префиксов.
//
Процедура ЗаполнитьКодДляПоиска() Экспорт
...
```

#### 2.

Расположение обработчиков обновления

#### 2.1.

Процедура-обработчик должна быть экспортной.

Размещайте ее в модуле менеджера объекта метаданных, который она обновляет.

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

#### 2.2.

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

В этом случае процедура должна находиться в служебной части модуля, в подразделе `Обновление ИБ`.

#### 3.

Реализация обработчиков обновления

#### 3.1.

К процедуре-обработчику предъявляются требования:

- не должно быть интерактивного взаимодействия с пользователем;
- алгоритм не должен прерывать или зацикливать обработку, не должен оставлять необработанные данные и не должен требовать действий пользователя для продолжения;
- в параллельных отложенных обработчиках нельзя вызывать исключения, которые остановят всю процедуру обновления;
- в остальных обработчиках исключение допустимо только при критической ошибке, когда другие способы обхода проблемы исчерпаны;
- обработчик должен быть идемпотентным: повторный запуск на тех же данных дает тот же результат и не создает дубликаты;
- в пределах одной версии обработчики не должны зависеть от порядка выполнения; если зависимость есть, обработчики объединяют;
- при использовании [#std701: планов обмена РИБ с отборами](https://v8std.ru/std/701/) учитывайте, что в подчиненном узле могут быть неполные данные (например, есть движения, но нет регистратора), и такие данные нужно пропускать

#### 3.2.

Обработчик обновления не должен содержать лишних действий с данными. Он должен выполняться максимально быстро.

#### 3.2.1.

Отключайте бизнес-логику при обработке данных.
В большинстве случаев используйте признак `ОбменДанными.Загрузка`:

```bsl
ДокументОбъект.ОбменДанными.Загрузка = Истина;
```

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

```bsl
ДокументОбъект.ДополнительныеСвойства.Вставить("ОтключитьМоюБизнесЛогику");
```

#### 3.2.2.

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

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

Исключение: создание ссылочных объектов, которые должны переноситься механизмами обмена в другие узлы РИБ с тем же значением реквизита `Ссылка`.

#### 3.2.3.

Вместо простого вызова:

```bsl
ДокументОбъект.Записать();
```

используйте:

```bsl
ДокументОбъект.ОбменДанными.Загрузка = Истина; // отключить всю бизнес-логику при записи
ДокументОбъект.ДополнительныеСвойства.Вставить("ОтключитьМеханизмРегистрацииОбъектов");
ДокументОбъект.ОбменДанными.Получатели.АвтоЗаполнение = Ложь;
ДокументОбъект.Записать();
```

Для БСП 2.1.4 и выше используйте процедуру `ЗаписатьДанные` общего модуля `ОбновлениеИнформационнойБазы`:

```bsl
ОбновлениеИнформационнойБазы.ЗаписатьДанные(ДокументОбъект);
```

#### 3.3.

Перед процедурой-обработчиком должен быть комментарий.

Первая строка комментария должна содержать версию конфигурации, для которой предназначен обработчик.

Следующие строки должны отвечать на вопросы:

- какие данные будут изменены;
- какие изменения будут внесены.

#### Пример комментария

```bsl
// Обработчик обновления УТ 11.1.0.0
//
// Перебираются все элементы справочника, в которых не заполнен код для поиска,
// и заполняется кодом справочника без лидирующих нулей и префиксов.
//
Процедура ЗаполнитьКодДляПоиска() Экспорт
```

#### 4.

Переход на новые версии библиотек

#### 4.1.

При постановке конфигурации на поддержку новой версии библиотеки увеличивайте номер версии конфигурации.

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

#### См. также

- [#std556: Начальные действия при работе конфигурации](https://v8std.ru/std/556/)

#### Проверки

[#acc:1363](https://v8std.ru/diagnostics/acc/1363/)
#### Источник

https://its.1c.ru/db/v8std#content:690

В обработчике обновления информационной базы при записи объекта не используется метод "Библиотеки стандартных подсистем". АПК:1363

Начальные действия при работе конфигурации #std556

Разработка планов обмена с отборами #std701

Автогенерированные данные в информационной базе: требования по локализации #std784

Обработчики обновления информационной базы #std690


стандарт 693

ID: #std693

# Использование объектов типа Структура

Требования направлены на читаемость кода и удобство сопровождения.
Читабельный код снижает риск ошибок и упрощает работу команды.

#### 1.

Не передавайте в конструктор структуры более 3 значений.
Для остальных значений используйте `Вставить` или присваивание свойствам.

#### Неправильно

```bsl
ПараметрыФормыКомпоновки = Новый Структура(
    "НеПомещатьНастройкиВСхемуКомпоновкиДанных,
    |НеРедактироватьСхемуКомпоновкиДанных,
    |НеНастраиватьУсловноеОформление,
    |НеНастраиватьВыбор,
    |НеНастраиватьПорядок,
    |АдресСхемыКомпоновкиДанных,
    |АдресНастроекКомпоновкиДанных,
    |УникальныйИдентификатор,
    |Заголовок",
    Истина,
    Истина,
    Истина,
    Истина,
    Истина,
    ТекущиеДанные.АдресСхемыКомпоновкиДанных,
    ?(АдресНастроекСхемыКомпоновкиДанных <> Неопределено,
        АдресНастроекСхемыКомпоновкиДанных,
        ТекущиеДанные.АдресНастроекСхемыКомпоновкиДанных),
    УникальныйИдентификатор,
    ЗаголовокФормыНастройкиСхемыКомпоновкиДанных);
```

#### Правильно

```bsl
ПараметрыФормыКомпоновки = Новый Структура;
ПараметрыФормыКомпоновки.Вставить("НеПомещатьНастройкиВСхемуКомпоновкиДанных", Истина);
ПараметрыФормыКомпоновки.Вставить("НеРедактироватьСхемуКомпоновкиДанных", Истина);
ПараметрыФормыКомпоновки.Вставить("НеНастраиватьУсловноеОформление", Истина);
ПараметрыФормыКомпоновки.Вставить("НеНастраиватьВыбор", Истина);
ПараметрыФормыКомпоновки.Вставить("НеНастраиватьПорядок", Истина);
ПараметрыФормыКомпоновки.Вставить("АдресСхемыКомпоновкиДанных", ТекущиеДанные.АдресСхемыКомпоновкиДанных);
ПараметрыФормыКомпоновки.Вставить("АдресНастроекКомпоновкиДанных",
    ?(АдресНастроекСхемыКомпоновкиДанных <> Неопределено,
        АдресНастроекСхемыКомпоновкиДанных,
        ТекущиеДанные.АдресНастроекСхемыКомпоновкиДанных));
ПараметрыФормыКомпоновки.Вставить("УникальныйИдентификатор", УникальныйИдентификатор);
ПараметрыФормыКомпоновки.Вставить("Заголовок", ЗаголовокФормыНастройкиСхемыКомпоновкиДанных);
```

#### 2.

Не используйте в конструкторе структуры конструкторы других объектов, если они принимают параметры.
Особенно избегайте вложенных структур с заполнением свойств.

#### Неправильно

```bsl
НоменклатураСервер.ЗаполнитьСлужебныеРеквизитыПоНоменклатуреВКоллекции(
    Объект.Товары,
    Новый Структура(
        "ЗаполнитьПризнакХарактеристикиИспользуются,
        |ЗаполнитьПризнакТипНоменклатуры,
        |ЗаполнитьПризнакВариантОформленияПродажи",
        Новый Структура("Номенклатура", "ХарактеристикиИспользуются"),
        Новый Структура("Номенклатура", "ТипНоменклатуры"),
        Новый Структура("Номенклатура", "ВариантОформленияПродажи")
    )
);
```

#### Правильно

```bsl
ПараметрыЗаполненияРеквизитов = Новый Структура;
ПараметрыЗаполненияРеквизитов.Вставить("ЗаполнитьПризнакХарактеристикиИспользуются",
    Новый Структура("Номенклатура", "ХарактеристикиИспользуются"));
ПараметрыЗаполненияРеквизитов.Вставить("ЗаполнитьПризнакТипНоменклатуры",
    Новый Структура("Номенклатура", "ТипНоменклатуры"));
ПараметрыЗаполненияРеквизитов.Вставить("ЗаполнитьПризнакВариантОформленияПродажи",
    Новый Структура("Номенклатура", "ВариантОформленияПродажи"));

НоменклатураСервер.ЗаполнитьСлужебныеРеквизитыПоНоменклатуреВКоллекции(
    Объект.Товары,
    ПараметрыЗаполненияРеквизитов);
```

#### 3.

Не вызывайте в конструкторе структуры функции с большим числом параметров (более 3).

#### Неправильно

```bsl
СведенияОТоваре = Новый Структура("ПараметрыТовара, ЦенаПродажиИОстаткиТовара, ЦенаЗакупкиИОстаткиТовара",
    ПодборТоваровКлиентСервер.ПараметрыТовара(),
    ПодборТоваровВызовСервера.ЦенаПродажиИОстаткиТовара(
        Номенклатура,
        Характеристика,
        Соглашение,
        Валюта,
        ВидыЦен),
    ПодборТоваровВызовСервера.ЦенаЗакупкиИОстаткиТовара(
        Номенклатура,
        Характеристика,
        Соглашение,
        Валюта,
        ВидыЦен));
```

#### Правильно

```bsl
СведенияОТоваре = Новый Структура("ПараметрыТовара, ЦенаПродажиИОстаткиТовара, ЦенаЗакупкиИОстаткиТовара");
СведенияОТоваре.ПараметрыТовара = ПодборТоваровКлиентСервер.ПараметрыТовара();
СведенияОТоваре.ЦенаПродажиИОстаткиТовара = ПодборТоваровВызовСервера.ЦенаПродажиИОстаткиТовара(
    Номенклатура,
    Характеристика,
    Соглашение,
    Валюта,
    ВидыЦен);
СведенияОТоваре.ЦенаЗакупкиИОстаткиТовара = ПодборТоваровВызовСервера.ЦенаЗакупкиИОстаткиТовара(
    Номенклатура,
    Характеристика,
    Соглашение,
    Валюта,
    ВидыЦен);
```

#### 4.1.

Не добавляйте свойства структуры в разных местах кода с последующей проверкой их наличия.
Создавайте структуру со значениями по умолчанию сразу.

#### Неправильно

```bsl
ПараметрыВыполнения = Новый Структура;
...
УникальныйИдентификатор = ?(ПараметрыВыполнения.Свойство("УникальныйИдентификатор"),
    ПараметрыВыполнения.УникальныйИдентификатор,
    Неопределено);
```

#### Правильно

```bsl
ПараметрыВыполнения = ПараметрыВыполнения();
УникальныйИдентификатор = ПараметрыВыполнения.УникальныйИдентификатор;
...

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

#### 4.2.

Исключение — структуры с нефиксированным форматом:

- структуры из внешних источников (HTTP-ответ, данные сканера штрихкодов, терминала сбора данных);
- системные параметры формы, параметры выбора в параметрах формы;

Пользовательские параметры формы, объявленные на закладке «Параметры» редактора формы.

#### См. также

- [#std640: Параметры процедур и функций](https://v8std.ru/std/640/)
- [#std641: Структуры и таблицы значений в качестве параметров процедур и функций](https://v8std.ru/std/641/)

#### Проверки
[#bslls:NumberOfValuesInStructureConstructor](https://v8std.ru/diagnostics/bslls/NumberOfValuesInStructureConstructor/)

[#acc:293](https://v8std.ru/diagnostics/acc/293/)
[#acc:294](https://v8std.ru/diagnostics/acc/294/)
[#acc:295](https://v8std.ru/diagnostics/acc/295/)
#### Источник

https://its.1c.ru/db/v8std#content:693

В конструкторе объекта типа "Структура" указано более 3-х значений свойств. АПК:293

В конструкторе объекта типа "Структура" использован конструктор другого объекта с параметрами. АПК:294

В конструкторе объекта типа "Структура" использован вызов функции с количеством параметров более 3-х. АПК:295

Ограничение на количество значений свойств, передаваемых в конструктор структуры BSLLS:NumberOfValuesInStructureConstructor

Параметры процедур и функций #std640

Структуры и таблицы значений в качестве параметров процедур и функций #std641

Использование объектов типа Структура #std693


стандарт 697

ID: #std697

# Использование предопределенных элементов

#### Для информации

Стандарт действует для платформы `8.3.3` и выше без режима совместимости с `8.2`.

#### 1.1.

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

#### 1.2.

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

Так проще и безопаснее работать с ними в коде.

Примеры: страна `Россия` в справочнике `СтраныМира`, профиль групп доступа `Администратор`.

Для этого:

- оставляйте свойство `ОбновлениеПредопределенныхДанных = Авто`;
- не переключайте режим в коде через `УстановитьОбновлениеПредопределенныхДанных`;
- запретите пользователям интерактивное удаление предопределенных данных.

Отключите следующие права ролей (по умолчанию они выключены):

- `ИнтерактивноеУдалениеПредопределенныхДанных`;
- `ИнтерактивнаяПометкаУдаленияПредопределенныхДанных`;
- `ИнтерактивноеСнятиеПометкиУдаленияПредопределенныхДанных`;
- `ИнтерактивноеУдалениеПомеченныхПредопределенныхДанных`.

См. [#std488: Стандартные роли](https://v8std.ru/std/488/)

#### 1.3.

#### Для информации

Уточнение действует для управляемого и обычного приложения.

Исключение: подчиненные узлы РИБ.

В подчиненном узле предопределенные элементы:

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

В этом режиме:

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

#### Пример

```bsl
Если ПланыОбмена.ГлавныйУзел() = Неопределено Тогда
    // Заполняем предопределенные элементы.
    ...
КонецЕсли;
```

При использовании подсистемы `Обмен данными` БСП версии `2.1.4` и выше требования 1 и 2 снимаются.

#### 1.4.

Для таблиц с предопределенными элементами, которые:

- не входят в состав плана обмена РИБ;
- не связаны с таблицами, входящими в план обмена РИБ;

устанавливайте свойство `ОбновлениеПредопределенныхДанных = ОбновлятьАвтоматически`.

Значение `Авто` здесь не подходит:
в подчиненном узле `Авто` означает `НеОбновлятьАвтоматически`, и элементы автоматически не создаются.

Если включен режим совместимости с `8.3.3`, при первом запуске подчиненного узла РИБ (сразу после обновления конфигурации) также устанавливайте автоматическое обновление данных программно:

```bsl
Справочники.<ИмяСправочника>.УстановитьОбновлениеПредопределенныхДанных(
    ОбновлениеПредопределенныхДанных.ОбновлятьАвтоматически);
```

#### 2.

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

Пример: предопределенные виды расчета в плане видов расчета `Начисления` зависят от функциональных опций `ИспользоватьУчетВремениСотрудниковВЧасах`, `ИспользоватьСдельныйЗаработок` и др.

В этом случае:

- устанавливайте `ОбновлениеПредопределенныхДанных = Не обновлять автоматически`;
- реализуйте в прикладном коде создание элемента и, при необходимости, [#std638: пометку недействительным](https://v8std.ru/std/638/)
- учитывайте в коде, что элемент может отсутствовать.

#### Пример

```bsl
Если ПолучитьФункциональнуюОпцию("ИспользоватьУчетВремениСотрудниковВЧасах") Тогда
    НачислениеОбъект = ПланыВидовРасчета.Начисления.СоздатьВидРасчета();
    НачислениеОбъект.ИмяПредопределенныхДанных = "ОкладПоЧасам";
    ...
    НачислениеОбъект.Записать();
КонецЕсли;
```

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

#### Неправильно

```bsl
... = ПланВидовРасчета.Начисления.ОкладПоЧасам;
... = ПредопределенноеЗначение("ПланВидовРасчета.Начисления.ОкладПоЧасам");
```

При использовании БСП версии `2.1.4` и выше применяйте функцию `ПредопределенныйЭлемент()` общих модулей `ОбщегоНазначения` или `ОбщегоНазначенияКлиент`.
Она возвращает `Неопределено`, если элемента нет в ИБ.

#### Правильно

```bsl
... = ОбщегоНазначенияКлиент.ПредопределенныйЭлемент(
    "ПланВидовРасчета.Начисления.ОкладПоЧасам");
```

#### См. также

- [#std443: Получение предопределенных значений на клиенте](https://v8std.ru/std/443/)

#### Проверки

[#acc:192](https://v8std.ru/diagnostics/acc/192/)
[#acc:193](https://v8std.ru/diagnostics/acc/193/)
[#acc:194](https://v8std.ru/diagnostics/acc/194/)
[#acc:195](https://v8std.ru/diagnostics/acc/195/)
[#acc:304](https://v8std.ru/diagnostics/acc/304/)
[#acc:305](https://v8std.ru/diagnostics/acc/305/)
[#acc:1149](https://v8std.ru/diagnostics/acc/1149/)
#### Источник

https://its.1c.ru/db/v8std#content:697

Установлено право "Интерактивное удаление". АПК:1149

Установлено право "ИнтерактивноеУдалениеПредопределенныхДанных". АПК:192

Установлено право "ИнтерактивнаяПометкаУдаленияПредопределенныхДанных". АПК:193

Установлено право "ИнтерактивноеСнятиеПометкиУдаленияПредопределенныхДанных". АПК:194

Установлено право "ИнтерактивноеУдалениеПомеченныхПредопределенныхДанных". АПК:195

Неверно установлено значение свойства "ОбновлениеПредопределенныхДанных". АПК:304

Программный вызов метода "УстановитьОбновлениеПредопределенныхДанных" используется для переключения режима "ОбновлениеПредопределенныхДанных". АПК:305

Получение предопределенных значений на клиенте #std443

Стандартные роли #std488

Работа с неактуальными (недействительными) объектами #std638

Использование предопределенных элементов #std697


стандарт 701

ID: #std701

# Разработка планов обмена с отборами

#### 1.1.

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

Узлы-получатели определяйте в событиях [#std464: ПередЗаписью](https://v8std.ru/std/464/) и [#std752: ПередУдалением](https://v8std.ru/std/752/)
В этих событиях реализуйте логику регистрации изменений на узлах плана обмена (далее - логика регистрации).

#### Для информации

Если используется подсистема `Обмен данными` БСП, логику регистрации можно задать декларативно в правилах регистрации объектов (ПРО), которые разрабатываются в конфигурации `Конвертация данных`.
Подробнее см. документацию к подсистеме `Обмен данными`.

#### 1.2.

При проектировании логики регистрации учитывайте особенности:

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

#### Для информации

При синхронизации с другими программами (не РИБ, по правилам конвертации) через подсистему `Обмен данными` БСП первые два пункта можно не учитывать в правилах регистрации для ссылочных типов (`СправочникСсылка`, `ДокументСсылка` и т. п.).
Причина: регистрация ссылочных объектов выполняется отложенно, отдельной операцией, после загрузки всех данных из сообщения обмена.

#### 2.

С учетом этих особенностей придерживайтесь следующих правил.

#### 2.1.

Обеспечивайте самодостаточность данных, участвующих в обмене.

Таблицы обмена (справочники, документы, регистры и т. п.) должны содержать все данные, необходимые для логики регистрации.
Логика регистрации должна работать только с данными основной таблицы и не обращаться к полям связанных таблиц.

Пример:

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

Если самодостаточность нельзя обеспечить по другим соображениям, рассмотрите варианты из п. 2.2 и 2.3.

#### 2.2.

Исключайте из обмена вторичные данные.

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

Пример:

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

#### 2.3.

Регистрируйте изменения связанных данных.

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

Пример:

- регистрация идет в разрезе организаций;
- в обмене участвуют справочник `Основные средства` и регистр сведений `Основные средства организаций`, где хранится связь основного средства и организации;
- при записи элемента справочника и набора записей регистра к выгрузке регистрируются оба объекта;
- если при загрузке данных сначала загружается элемент справочника, он записывается, но не регистрируется к выгрузке, потому что набор записей регистра еще не загружен;
- когда позже загружается набор записей регистра, регистрируются изменения и самого набора, и соответствующего элемента справочника.

#### См. также

- [#std477: Самодостаточность регистров](https://v8std.ru/std/477/)
- [#std654: Разыменование ссылочных полей составного типа в языке запросов](https://v8std.ru/std/654/)

#### Источник

https://its.1c.ru/db/v8std#content:701

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

Обработчик события ПередЗаписью #std464

Самодостаточность регистров #std477

Разыменование ссылочных полей составного типа в языке запросов #std654

Обработчик события ПередУдалением #std752

Разработка планов обмена с отборами #std701


стандарт 704

ID: #std704

# Использование определяемых типов

#### 1.

Определяемые типы используйте для данных, которые:

- часто применяются в конфигурации;
- могут меняться при внедрении прикладного решения.

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

#### См также

[Объекты конфигурации - Определяемые типы](https://its.1c.ru/db/v83doc/bookmark/dev/TI000000236)

#### 2.

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

#### 2.1.

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

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

#### Примеры

- `НомерСчетаФактуры`: строка, длина `30`.
  Единый формат номера счета-фактуры в документах `ПоступлениеТоваровИУслуг`, `ЗаписьКнигиПокупок`, `ВозвратТоваровОтКлиента` и др.
- `АдресДоставки`: строка, длина `500`.
  Текст адреса доставки в документах `ЗаказПоставщику`, `ЗаявкаНаВозвратТоваровОтКлиента`, в обработке `ПомощникПродаж` и др.

#### 2.2.

Для определения [#std728: составного типа](https://v8std.ru/std/728/), который массово используется в объектах подсистемы или во всем прикладном решении

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

#### Пример

В подсистеме `Взаимодействия` задан определяемый тип `КонтактВзаимодействий`:
`ФизическиеЛица`, `Партнеры`, `КонтактныеЛицаПартнеров`.

Этот тип используется в документах (`Встреча`, `ЗапланированноеВзаимодействие`, `СообщениеSMS`, `ТелефонныйЗвонок`), общих формах (`АдреснаяКнига`, `ВыборКонтакта`) и в параметрах макетов.

Без определяемого типа пришлось бы задавать состав типов во всех этих местах вручную и снимать объекты подсистемы с поддержки.

#### 2.3.

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

#### Пример

Тип подсистемы `Поставщики` при внедрении может быть заменен на прикладной тип конфигурации `Контрагенты`.

#### 3.

Не используйте определяемые типы:

- как «синоним» уже существующего типа;
- для «подмены» сущностей;
- для локального (немассового) использования без реальной потребности внедрения в другие конфигурации;
- только ради гипотетического удобства будущей доработки.

Обычно это признак ошибки проектирования или некорректного выбора исходного имени типа.

#### Неправильно

В конфигурации есть справочник `Контрагенты`, который используется в нескольких регистрах сведений, реквизитах форм и других объектах.

Если это не внедряемая подсистема и тип не предполагается расширять, не нужно создавать отдельный определяемый тип из единственного типа `Контрагенты` «на всякий случай».

Это размывает прикладной смысл сущности.

#### См. также

- [#std728: Ограничения на использование реквизитов составного типа](https://v8std.ru/std/728/)
- [Объекты конфигурации - Определяемые типы (документация)](https://its.1c.ru/db/v83doc/bookmark/dev/TI000000236)

#### Источник

https://its.1c.ru/db/v8std#content:704

Ограничения на использование реквизитов составного типа #std728

Использование определяемых типов #std704


стандарт 705

ID: #std705

# Отнесение объектов библиотек к подсистемам

#### 1.

Все объекты библиотеки должны относиться к одной корневой подсистеме.

Например, для объектов БСП это подсистема `СтандартныеПодсистемы`.
Корневая подсистема из этого пункта не должна содержать командный интерфейс.

#### 2.

Допустимо наличие нескольких дополнительных корневых подсистем, которые содержат командный интерфейс.

#### См. также

- [#std543: Использование подсистем](https://v8std.ru/std/543/)

#### Проверки

[#acc:1147](https://v8std.ru/diagnostics/acc/1147/)
#### Источник

https://its.1c.ru/db/v8std#content:705

Не задана принадлежность объекта к подсистемам. АПК:1147

Использование подсистем #std543

Отнесение объектов библиотек к подсистемам #std705


стандарт 706

ID: #std706

# Ограничения на переименование объектов метаданных

#### 1.

Не переименовывайте общий модуль с последующим созданием нового модуля с тем же именем.

Если модуль нужно переименовать, создайте новый общий модуль с новым именем и перенесите в него код исходного модуля.

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

#### 2.

Если при изменении структуры метаданных нужно удалить объект и создать новый объект с тем же именем, сначала переименуйте устаревший объект, добавив префикс `Удалить`.

#### Пример

Такое переименование часто требуется при сужении состава измерений регистра.

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

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

См. также: [#std534: Удаление устаревших объектов метаданных из конфигурации](https://v8std.ru/std/534/)

#### 3.

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

#### 3.1.

Если БСП не используется, храните полные имена объектов метаданных в строковых реквизитах (`Строка`, `255`).

#### Примеры

В справочнике `ШаблоныСообщений`: реквизит `ПолноеИмяТипаПараметраВводаНаОсновании`.

В регистре сведений `НастройкиПечатиОбъектов`: измерение `ТипОбъекта`.

При переименовании или удалении объектов метаданных в обновлении ИБ обязательно заменяйте или удаляйте соответствующие имена в данных.

Иначе ссылки на имена объектов станут рассогласованными, и подсистемы, которые на них опираются, начнут работать с ошибками.

#### 3.2.

Если используется БСП, храните ссылки на объекты метаданных через справочник `ИдентификаторыОбъектовМетаданных`.

Преимущества:

- централизованное хранение ссылок на имена объектов с автоматическим учетом переименований, удалений и добавлений;
- меньший объем данных (ссылка вместо строки длиной `255`), что улучшает производительность.

Исключение: для ролей и подсистем автоматическое отслеживание переименований не выполняется.
Для них переименования нужно описывать явно.

Подробнее: [Документация к БСП](https://its.1c.ru/db/bspdoc).

Если не описать переименование ролей и подсистем, ссылки в `ИдентификаторыОбъектовМетаданных` рассогласуются
(старый элемент будет помечен на удаление, вместо него появится новый), что приведет к ошибкам.

#### Примеры последствий

Варианты отчетов, связанные с переименованной подсистемой, исчезнут из панели отчетов.

Дополнительные отчеты и обработки, выведенные пользователями в раздел переименованной подсистемы, пропадут из списка.

Переименованные роли из профилей групп доступа не будут назначаться пользователям.

#### 3.3.

Справочник `ИдентификаторыОбъектовМетаданных` не предназначен для ссылок на объекты метаданных других конфигураций
(например, в интеграционных механизмах).

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

#### 3.4.

Если ведется две и более параллельных ветки разработки (например, `2.0` и `3.0`):

- в текущей и младших версиях запрещены переименование с последующим созданием нового объекта с тем же полным именем;
- в текущей и младших версиях запрещено двойное переименование;
- такие переименования выполняйте только в самой старшей версии.

Иначе при переходе с младшей версии на старшую переименование может быть учтено дважды,
что приведет к рассогласованию ссылок на объекты метаданных.

Если используются ссылки через `ИдентификаторыОбъектовМетаданных` БСП,
этот запрет действует только для ролей и подсистем.

Подробнее: [Документация к БСП](https://its.1c.ru/db/bspdoc).

#### См. также

- [#std550: Имена объектов метаданных в конфигурациях](https://v8std.ru/std/550/)
- [#std534: Удаление устаревших объектов метаданных из конфигурации](https://v8std.ru/std/534/)

#### Источник

https://its.1c.ru/db/v8std#content:706

Удаление устаревших объектов метаданных из конфигурации #std534

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

Ограничения на переименование объектов метаданных #std706


стандарт 708

ID: #std708

# Разрешение итогов для периодических регистров сведений

#### 1.1.

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

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

Полный перечень случаев, когда используются итоги регистра сведений, см. в [документации к платформе 1С:Предприятие](https://its.1c.ru/db/v83doc/content/63/hdoc/IssOgl3_5.14.1.1.Общаяинформацияорегистрахсведений).

#### Пример

Частотный запрос к регистру `ЦеныНоменклатуры` для получения текущих цен:

```sdbl
ВЫБРАТЬ
    Номенклатура.Артикул КАК Артикул,
    ЦеныНоменклатуры.Цена КАК Цена,
    ...
ИЗ
    Справочник.Номенклатура КАК Номенклатура
    ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры.СрезПоследних(, ВидЦены = &ВидЦены) КАК ЦеныНоменклатуры
        ПО ЦеныНоменклатуры.Номенклатура = Номенклатура.Ссылка
    ...
```

Если все условия выше выполняются, включение свойства `Разрешить итоги: срез последних` может существенно ускорить такие запросы: выборка идет из дополнительных таблиц с первыми/последними значениями.

#### 1.2.

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

Пример: если иногда данные в регистр `ЦеныНоменклатуры` записываются будущей датой, а в форме подбора всегда выполняется запрос к `СрезПоследних` с явно заданной текущей датой, итоги такой запрос не ускорят.

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

#### 2.

Во всех остальных случаях итоги для периодических регистров сведений разрешать не следует. В первую очередь, если:

- чаще всего к `СрезПервых`/`СрезПоследних` выполняются запросы на конкретный период (например, на дату документа);
- в условиях для `СрезПервых`/`СрезПоследних` чаще всего используются подзапросы и соединения (обращение через точку к связанным таблицам).

#### Пример

```sdbl
ВЫБРАТЬ
    ...
ИЗ
    РегистрСведений.КурсыВалют.СрезПоследних(, Валюта.Код = &КодВалютыСклада) КАК КурсыВалют
```

#### 3.

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

Исключение: случаи, когда актуализация итогов при записи была отключена вызовом `РегистрСведенийМенеджер.УстановитьИспользованиеИтогов(Ложь)`.

#### Источник

https://its.1c.ru/db/v8std#content:708

Разрешение итогов для периодических регистров сведений #std708


стандарт 709

ID: #std709

# Технология разветвленной разработки конфигураций

Цели внедрения технологии:

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

#### 1.

Определения

**Плановая версия конфигурации** - версия,
содержащая существенное развитие функционала,
с заранее назначенным сроком выпуска.

**Исправительная версия** - версия,
которая выпускается при необходимости
срочной публикации исправлений критичных ошибок.
В исключительных случаях
исправительная версия может содержать
новый функционал
(например, изменения для поддержки законодательства).
Срок выпуска определяется
по количеству и критичности ошибок,
обнаруженных в плановой версии.

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

Для организации разработки и сопровождения конфигураций
(в том числе для ведения технических проектов и списка ошибок)
рекомендуется использовать
**Систему проектирования прикладных решений (СППР)**.

#### 2.

Разработка исправительных версий

#### 2.1.

Для выпуска каждой исправительной версии
создавайте новое хранилище
на основе конфигурации
последней выпущенной версии.

#### Важно

Создавайте новое хранилище,
а не копируйте основное.

#### 2.2.

В исправительной версии
не должно быть объемных доработок конфигурации.
Иначе нужно пересматривать
сроки выпуска плановой версии.

#### 2.3.

Все закладки в хранилище исправительной версии
должны содержать комментарий.

Требования к комментариям
аналогичны требованиям
к закладкам в хранилище плановой версии
(см. п. 3.4).

#### 2.4.

Все изменения,
которые выполняются в исправительном релизе,
должны синхронно повторяться
в основном хранилище.

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

#### 2.5.

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

#### 3.

Разработка плановой версии

#### 3.1.

Плановые версии
разрабатываются в основном хранилище конфигурации.

#### 3.2.

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

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

#### 3.3.

В основном хранилище
разрешается выполнять:

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

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

#### 3.4.

Все закладки в основное хранилище
должны содержать комментарий.

Содержание комментария
зависит от характера выполненных работ:

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

#### 3.5.

Все изменения по техническому проекту
переносите в основное хранилище
за одну закладку.

Если нужно переносить изменения несколько раз,
открывайте несколько проектов.

#### 3.6.

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

Для пересмотра проектных решений
нужно открывать новый проект.

#### 3.7.

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

#### 4.

Разработка технических проектов

#### 4.1.

Каждый технический проект
разрабатывайте в отдельном хранилище.

При использовании **СППР**
хранилище технического проекта
может создаваться автоматически.
Если **СППР** не используется,
хранилище технического проекта
нужно создавать вручную
по порядку,
описанному в приложении 1.

#### 4.2.

При постановке хранилища технического проекта
на поддержку от основного хранилища
платформа устанавливает
для всех объектов правило:
«Объект поставщика, не редактируется».

Для работы над техническим проектом
измените это правило
на «Объект поставщика редактируется
с сохранением поддержки».

Устанавливайте это правило
только для тех объектов,
которые изменяются в проекте.
Делайте это максимально точечно.

Например,
если в проекте меняется только форма,
измените правило только для формы,
а для объекта,
к которому она относится,
оставьте правило
«Объект поставщика, не редактируется».

Чтобы изменить правила поддержки,
захватывайте только корень конфигурации.
Сами объекты захватывать не нужно.

Это упрощает перенос изменений
между основным хранилищем
и хранилищем технического проекта.

#### 4.3.

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

На частоту обновления влияют,
например, такие факторы:

- затрагивает ли проект
  объекты других ответственных;
- проводится ли в это время
  рефакторинг общих механизмов;
- ведется ли сейчас
  массовое исправление ошибок
  в основном хранилище.

Порядок обновления хранилища
описан в приложении 2.

#### 4.4.

После окончания разработки
ответственный согласует:

- сроки завершения отладочного тестирования;
- сроки внесения технического проекта
  в основное хранилище.

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

Ответственные за другие проекты
могут попросить перенести сроки внесения.

В **СППР** сроки встраивания
можно согласовывать
через функциональность
контрольных точек
по техническому проекту.

#### 4.5.

Вносите проект
в основное хранилище
только после завершения
отладочного тестирования.

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

#### 4.6.

Внесение наработок технического проекта
в основное хранилище
не должно приводить
к длительному захвату объектов
основного хранилища.

Для этого сначала
обновляйте хранилище технического проекта
до состояния основного хранилища
(по методике из приложения 2).

Если изменений много,
обновление может занимать
достаточно долгое время
(до нескольких дней).
За это время
конфигурация основного хранилища
может измениться.

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

После каждой итерации
целесообразно выполнять
быструю проверку работоспособности
функционала,
который разрабатывается в проекте.

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

#### 4.7.

Ответственный за технический проект
должен внимательно относиться
к внесению изменений
в основное хранилище.

Помните:
основное хранилище
в любой момент времени
должно быть готово
к выпуску плановой версии.

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

Объем и порядок проверок
определяет ответственный за проект.

#### 4.8.

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

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

#### 4.9.

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

#### 5.

Нумерация сборок

Изменение номеров версий
регламентируется стандартом
[#std483: Нумерация редакций и версий](https://v8std.ru/std/483/)

Ниже приведены правила
изменения номера сборки
(четвертое число в номере версии).

#### 5.1.

Номер сборки
следует увеличивать
как в основном хранилище,
так и в хранилище исправительного релиза,
в двух случаях:

- непосредственно перед сборкой релиза.
  Это нужно,
  чтобы полный номер собранного релиза
  гарантированно отличался
  от полного номера предыдущего релиза;
- при закладке в хранилище
  обработчика обновления информационной базы.
  Это нужно,
  чтобы после обновления из хранилища
  у всех участников разработки
  добавленный обработчик
  запускался автоматически
  (только для конфигураций,
  основанных на **Библиотеке стандартных подсистем**).

#### 5.2.1.

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

Возможны два сценария:

- обработчик добавляется
  при разработке технического проекта
  в хранилище технического проекта.
  В этом случае
  при переносе изменений
  в основное хранилище
  увеличивайте номер сборки
  основного хранилища;
- обработчик добавляется
  в рамках исправления ошибки.
  Если ошибка исправляется
  только в одном хранилище
  (основном или исправительном),
  номер сборки повышается только в нем.
  Если в двух,
  номер нужно увеличить
  в обоих хранилищах.

#### 5.2.2.

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

Обработчик обновления
должен быть «привязан»
к тому номеру сборки,
который вместе с ним
помещается в хранилище.

#### 5.2.3.

Если в одной конфигурации
обработчики обновления
разбиты по технологическим подсистемам
(например, в конфигурации **1С:ERP**
обработчики разбиты
на подсистемы `УправлениеПредприятием`
и `УправлениеТорговлей`),
повышайте номер сборки
как подсистемы,
к которой относится обработчик,
так и конфигурации.

#### 5.3.

Номер сборки
нужно изменять:

1. в свойствах конфигурации;
2. в процедуре `ОбновлениеИнформационнойБазы.ПриДобавленииПодсистемы`
   (только для конфигураций,
   основанных на **Библиотеке стандартных подсистем**).

#### Приложение 1.

Порядок создания хранилища технического проекта

1. Обновите из хранилища
   конфигурацию информационной базы,
   подключенную к основному хранилищу.
2. Создайте файл поставки
   конфигурации основного хранилища (`*.cf`).
3. В информационную базу,
   которая будет использоваться
   для работы над техническим проектом,
   **загрузите** конфигурацию
   из файла поставки.
   После загрузки
   конфигурация будет находиться на поддержке
   без возможности изменения.
4. Создайте хранилище конфигурации
   в соответствующей общей папке.
   При создании хранилища
   платформа включит в конфигурации
   возможность изменения.
5. Добавьте пользователя `ТолькоПросмотр`
   (без пароля,
   без права захвата объектов).
   Этого пользователя
   не нужно использовать
   для подключения базы к хранилищу.
   Он нужен только для обновления из хранилища
   (получения конфигурации хранилища).
6. Добавьте в хранилище пользователей,
   перечисленных в проекте
   (логин - фамилия сотрудника,
   без пароля,
   с правом захвата объектов).
   Не используйте для работы
   логин пользователя `ТолькоПросмотр`.

#### Приложение 2.

Порядок обновления хранилища технического проекта до состояния основного хранилища

Перед переносом изменений
из *хранилища технического проекта*
(далее - ХТП)
в *основное хранилище*
(далее - ОХ)
обновите ХТП до состояния ОХ.

Для этого выполните следующие действия:

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

   Изображение: Отчет о сравнении конфигураций (709.img1.png)

5. Обновите конфигурацию
   (`Конфигурация - Поддержка - Обновить конфигурацию - Выбор файла обновления`)
   и укажите файл поставки,
   созданный на шаге 2.

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

   Изображение: Фильтр в окне сравнения и объединения конфигураций (709.img2.png)

   На эти объекты
   нужно обратить внимание при объединении.
   Остальные изменения
   можно объединять без проверки.

   Изображение: Результат фильтрации дважды измененных свойств (709.img3.png)

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

   Для всех остальных
   установите флаг
   `Сохранять текущий режим`
   (по умолчанию он установлен).

   Изображение: Параметры выполнения объединения конфигураций (709.img4.png)

7. После завершения объединения
   исправьте объекты,
   затрагиваемые техническим проектом,
   изменения в которых
   затерлись при обновлении.
   По сути это означает,
   что нужно повторно внести доработки,
   реализованные в рамках проекта,
   в объекты конфигурации.
8. Запустите сравнение
   обновленной основной конфигурации
   технического проекта
   и обновленной конфигурации поставщика
   (`Конфигурация - Сравнить конфигурации`).

   Изображение: Сравнение обновленной конфигурации проекта с конфигурацией поставщика (709.img5.png)

9. Сохраните результаты сравнения в файл.
   Имя файла должно отличаться
   от имени файла,
   созданного на шаге 6.
   В меню `Действия`
   выберите пункт
   `Отчет о сравнении конфигураций`.
   Для дальнейшего использования
   лучше сохранить отчет
   в текстовом формате.
10. Сравните файлы,
    созданные на шагах 4 и 9.
    При корректном обновлении
    сравнение не должно показать отличий.

#### Источник

https://its.1c.ru/db/v8std#content:709

Цели внедрения технологии:

Нумерация редакций и версий #std483

Технология разветвленной разработки конфигураций #std709