Как убрать обязательное заполнение поля в 1С

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

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

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

Определите, где задана обязательность поля

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

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

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

Способ 1. Изменить свойство реквизита в конфигураторе

Прямое изменение конфигурации подходит, если база уже снята с полной поддержки или это собственная разработка. Порядок действий: откройте конфигуратор, перейдите к объекту (например, «Документы → РеализацияТоваровУслуг»), раскройте ветку «Реквизиты» и вызовите палитру свойств нужного реквизита. Найдите свойство «Проверка заполнения» и установите значение «Не проверять».

После этого обновите конфигурацию базы данных (F7 или меню «Конфигурация → Обновить конфигурацию базы данных»). Изменение свойства проверки заполнения не затрагивает данные, реструктуризация не требуется, обновление проходит быстро даже на больших базах.

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

Способ 2. Убрать обязательность через расширение конфигурации

Расширение — рекомендуемый путь для типовых конфигураций на поддержке. Создайте новое расширение (Конфигурация → Расширения конфигурации → Создать), задайте имя и префикс, затем добавьте в расширение нужный объект: в основной конфигурации вызовите контекстное меню объекта и выберите «Добавить в расширение».

После того как объект появился в расширении, откройте его реквизиты, найдите заимствованный реквизит и в палитре свойств установите «Проверка заполнения» = «Не проверять». Сохраните расширение и обновите конфигурацию базы данных. Собственные данные расширение не создаёт, поэтому обновление безопасно и не требует монопольного доступа надолго.

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

1. 1
   Сделайте резервную копию базы или работайте на тестовой копии
2. 2
   Создайте расширение конфигурации с понятным именем и префиксом
3. 3
   Добавьте в расширение документ или справочник с нужным реквизитом
4. 4
   В свойствах заимствованного реквизита установите «Проверка заполнения» = «Не проверять»
5. 5
   Сохраните расширение и обновите конфигурацию базы данных
6. 6
   Проверьте запись объекта с пустым полем в пользовательском режиме
7. 7
   Если ошибка осталась — переопределите ОбработкаПроверкиЗаполнения в модуле объекта расширения

Способ 3. Программное отключение проверки заполнения

Когда обязательность задана в коде, свойства реквизита недостаточно. В модуле объекта (в расширении — через аннотацию изменения и контроля) переопределите процедуру ОбработкаПроверкиЗаполнения и добавьте имя реквизита в массив НепроверяемыеРеквизиты. Тогда платформа пропустит это поле при проверке.

&После("ОбработкаПроверкиЗаполнения")
Процедура Расш1_ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
ОбщегоНазначения.УдалитьНепроверяемыеРеквизитыИзМассива(
ПроверяемыеРеквизиты,
СтрРазделить("Договор,Подразделение", ","));
КонецПроцедуры

В типовых конфигурациях на БСП для удаления реквизитов из проверяемых удобно использовать именно функцию ОбщегоНазначения.УдалитьНепроверяемыеРеквизитыИзМассива — она корректно обрабатывает и реквизиты табличных частей (указываются через точку, например «Товары.Склад»). Если БСП нет, можно просто найти индекс элемента в массиве и удалить его.

Обратная ситуация тоже встречается: проверка прописана не через массив проверяемых реквизитов, а прямым вызовом ОбщегоНазначения.СообщитьПользователю с установкой Отказ = Истина. В этом случае придётся аккуратно замещать или обходить соответствующий фрагмент кода, что требует внимательного чтения типового модуля и тестирования всех сценариев документа.

Способ 4. Настройки без доработки конфигурации

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

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

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

Сравнение вариантов

Свойство реквизита в конфигураторе

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

Расширение конфигурации

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

Программное переопределение обработчика

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

Функциональные опции и настройки

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

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

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

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

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

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

Запись объекта с пустым полем

Норма

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

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

Появляется сообщение «Поле не заполнено» — проверка осталась в коде

Другие виды операций и режимы записи

Норма

Ни в одном сценарии обязательность не возвращается

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

При отдельном виде операции ошибка появляется — условная проверка не обработана

Отчёты и обмены по этому реквизиту

Норма

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

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

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

Обновление конфигурации

Норма

Расширение совместимо с новым релизом, поведение сохраняется

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

После обновления расширение отключается или проверка возвращается

Ограничения и риски снятия обязательности

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

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

Частые вопросы

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

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

Почему после снятия галочки «Проверка заполнения» ошибка всё равно появляется?

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

Как убрать обязательность реквизита табличной части?

Теми же способами: свойство «Проверка заполнения» у реквизита табличной части в конфигураторе или расширении, либо программно — в массив непроверяемых реквизитов добавляется имя в формате «ТабличнаяЧасть.Реквизит», например «Товары.Склад».

Безопасно ли снимать обязательность для обменов с другими системами?

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

Чем расширение лучше прямого изменения конфигурации?

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

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

Штатного механизма «обязательность по ролям» в платформе нет. Такое поведение реализуется программно: в обработчике проверки заполнения анализируется текущий пользователь или его роль, и реквизит добавляется в непроверяемые по условию. Это доработка, требующая участия разработчика и тестирования.