← На главную

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

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

Решение 1 (Рекомендуемое): Расширение составного типа существующего измерения

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

Почему этот вариант лучший?

1. Минимальные проблемы при обновлении. Это изменение легко отслеживается и принимается системой обновлений. Если использовать механизм расширений конфигурации, то основная конфигурация вообще остается на поддержке, что делает процесс обновления максимально простым.
2. Отсутствие реструктуризации таблицы. Изменение состава типов в реквизите не меняет физическую структуру таблицы в базе данных SQL. Система не будет запускать длительную и ресурсоемкую операцию реструктуризации, которая на больших базах может занять часы.
3. Сохранение логики запросов. Все существующие запросы к регистру, включая обращения к виртуальной таблице СрезПоследних, продолжат работать корректно без каких-либо доработок. Логика получения данных не меняется.

Что нужно сделать?

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

Решение 2 (Не рекомендуется): Добавление нового измерения

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

Последствия такого решения:

1. Реструктуризация таблицы. Добавление нового поля (измерения) в регистр — это изменение структуры таблицы в базе данных. Как уже говорилось, это может быть очень долгим процессом.
2. Нарушение логики уникальности и целостности. Регистр сведений идентифицирует записи по уникальной комбинации измерений. Добавляя новое измерение, вы меняете эту комбинацию. У вас появятся записи, где заполнено типовое измерение Документ, а ваше новое — пустое, и наоборот. Фактически, вы получаете два разных набора данных в одной таблице, что является грубой архитектурной ошибкой.
3. Необходимость доработки ВСЕХ запросов. Появление нового измерения означает, что все без исключения запросы к этому регистру нужно пересмотреть. Если этого не сделать, они могут начать возвращать неверные или дублирующиеся данные.
4. Некорректная работа СрезПоследних. Виртуальная таблица среза напрямую зависит от набора измерений. Старые запросы к СрезПоследних, не учитывающие новое измерение, будут работать неправильно, так как срез будет формироваться по новой, измененной комбинации полей.
5. Сложности при обновлениях. Такое серьезное изменение структуры типового объекта значительно усложняет процесс слияния и обновления конфигурации в будущем.

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

Решение 3 (Альтернативное): Создание нового, отдельного регистра сведений

Этот вариант предполагает, что мы вообще не трогаем типовой регистр, а создаем свой собственный, например, СтатусыДокументов_Наш, со своей структурой, где будем хранить статусы только для нашего нового документа.

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

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

Недостатки:

• Дублирование функциональности. Если вам нужны отчеты или обработки, которые показывают статусы всех документов (и типовых, и ваших), вам придется их серьезно дорабатывать.
• Усложнение логики запросов. Чтобы получить общую картину по статусам, придется писать сложные запросы с использованием ОБЪЕДИНИТЬ ВСЕ для объединения данных из двух регистров: типового и вашего. Это усложняет код и может сказаться на производительности.

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

Итоги

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

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