Общие реквизиты в 1С: что это такое и для чего они нужны

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

Такой подход решает две задачи. Первая — экономия труда при разработке и доработке: изменение типа, длины или синонима поля выполняется в одном месте и распространяется на все объекты-участники. Вторая — унификация: поле гарантированно называется одинаково и имеет одинаковый тип во всех объектах, что упрощает запросы, отчёты и обмены данными.

Общие реквизиты особенно важны в механизме разделения данных: в режиме SaaS именно общие реквизиты с включённым свойством «Разделение данных» определяют, как платформа отделяет данные одного абонента сервиса от данных другого. Это делает их не просто удобным инструментом, а элементом архитектуры прикладного решения.

Где находится объект «Общие реквизиты» и как он устроен

В дереве конфигурации общие реквизиты расположены в ветке «Общие» → «Общие реквизиты». Каждый элемент этой ветки — самостоятельный объект метаданных со своими свойствами: имя, синоним, тип данных, длина, признак обязательности заполнения, индексирование. По набору свойств общий реквизит почти не отличается от обычного реквизита документа или справочника.

Ключевое отличие — свойство «Состав» (в палитре свойств оно называется «Состав» или открывается кнопкой «Состав» в форме объекта). В нём перечислены все объекты конфигурации, и для каждого задаётся режим использования: «Автоматически», «Использовать» или «Не использовать». Режим «Автоматически» означает, что поведение определяется свойством самого общего реквизита «Автоиспользование»; «Использовать» принудительно включает поле в объект, «Не использовать» — исключает его.

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

Для чего общие реквизиты применяют на практике

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

Второй сценарий — упрощение запросов и отчётов. Когда поле называется одинаково во всех объектах, можно строить универсальные запросы с объединением таблиц без переименования колонок. Например, сводный отчёт по ответственным сотрудникам по всем документам пишется заметно проще, если реквизит «Ответственный» единообразен.

Третий сценарий — разделение данных в модели сервиса (SaaS). Общий реквизит с включённым свойством «Разделение данных» становится разделителем: платформа физически хранит значение разделителя в каждой записи и автоматически фильтрует данные текущего абонента. Без общих реквизитов реализовать такую изоляцию штатными средствами невозможно.

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

Как создать общий реквизит: пошаговый порядок

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

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

1. 1
   Откройте конфигуратор, ветка «Общие» → «Общие реквизиты», добавьте новый объект
2. 2
   Задайте имя, синоним и тип данных (например, СправочникСсылка.Пользователи)
3. 3
   Настройте дополнительные свойства: обязательность, индексирование, проверку заполнения
4. 4
   Откройте свойство «Состав» и отметьте объекты, в которые поле должно входить
5. 5
   При необходимости включите «Разделение данных» для работы в режиме сервиса
6. 6
   Обновите конфигурацию базы данных (F7) и дождитесь реструктуризации
7. 7
   Откройте несколько объектов из состава и убедитесь, что поле появилось на формах и в данных

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

Настройка состава и автоиспользования

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

Если автоиспользование выключено, каждый объект нужно включать в состав явно — режимом «Использовать». Такой вариант безопаснее для специфичных полей, которые нужны только в ограниченном наборе объектов: вы не рискуете случайно добавить лишнюю колонку в десятки таблиц.

Исключить отдельный объект из «массового» реквизита можно режимом «Не использовать» в составе. Типичный пример: поле «Организация» нужно во всех документах, кроме нескольких справочников, где оно не имеет смысла. Для этих справочников в составе ставится «Не использовать», остальные работают по правилу автоиспользования.

Общие реквизиты и разделение данных

В режиме сервиса общий реквизит со свойством «Разделение данных» становится разделителем. Платформа добавляет его значение в каждую запись разделённых объектов и прозрачно подставляет отбор по текущей области данных во все запросы. Прикладной код при этом обычно не меняется — разделение работает на уровне платформы.

Разделитель может быть двух видов по способу использования: независимый и совместно используемый. Это влияет на то, как объекты наследуют разделение друг от друга, например как записи регистров связываются с разделёнными документами-регистраторами. Настройка требует понимания модели разделения и тестирования на копии: ошибка в составе разделителей приводит либо к «протечке» данных между абонентами, либо к невозможности записать объект.

Ограничения и когда общий реквизит не подходит

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

Второе ограничение — не все объекты метаданных поддерживают общие реквизиты в одинаковой мере, а часть механизмов (например, отдельные виды регистров) имеет особенности по составу и индексированию. Перед проектированием проверьте в синтакс-помощнике, поддерживает ли нужный тип объекта включение в состав общего реквизита.

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

Общий реквизит или обычные реквизиты

Общий реквизит

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

Обычные реквизиты в каждом объекте

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

Подписки и расширения

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

Типичные ошибки и проверка результата

После внедрения общего реквизита результат проверяется в три шага: структурно, функционально и по данным. Структурно — поле видно в дереве метаданных и на формах целевых объектов. Функционально — поле доступно в запросах, отчётах и при программном обращении. По данным — существующие записи либо осознанно оставлены пустыми, либо заполнены обработкой.

Контрольные точки

Как проверить результат

Поле в объекте

Норма

Реквизит виден в форме и структуре объекта из состава

Тревожный признак

Поля нет — проверьте режим в свойстве «Состав»

Обновление базы

Норма

Реструктуризация завершилась без ошибок

Тревожный признак

Ошибки реструктуризации — смотрите сообщения, откатите на копию

Данные в старых записях

Норма

Понятно, пустые ли значения допустимы, есть план заполнения

Тревожный признак

Отчёты по полю дают неожиданно пустые итоги

Новые объекты

Норма

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

Тревожный признак

Поле не появилось — проверьте автоиспользование

Полезная практика — вести список объектов, исключённых из состава общего реквизита, с причиной исключения. Через полгода сопровождения это избавит от вопроса «почему в этом справочнике нет поля Комментарий» и от случайного включения поля туда, где оно не должно быть.

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

Частые вопросы об общих реквизитах

Можно ли добавить общий реквизит в типовую конфигурацию без снятия с поддержки?

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

Что произойдёт с данными, если исключить объект из состава общего реквизита?

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

Чем общий реквизит отличается от общего модуля и критерия отбора?

Общий реквизит — это данные (поле в таблицах объектов). Общий модуль — это код, доступный из разных мест конфигурации. Критерий отбора — механизм поиска объектов по значению реквизита. Это три независимых объекта из ветки «Общие», решающих разные задачи.

Обязательно ли использовать общие реквизиты для работы в режиме SaaS?

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

Почему после добавления общего реквизита обновление базы идёт очень долго?

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

Можно ли сделать общий реквизит обязательным только в части объектов?

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