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

Без указания что груз режимный/нережимный документ не должен проводиться*

(0) сделать либо РС, либо перечислением

(0) > Есть наименее затратные методы решения?
Все зависит что такое для тебя "затратные"

(1) Ну, можешь еше завести два булевых "режимный" и "не режимный". Одинаковые значения в них забанить при проверке заполнения.

(1) Можешь завести число и ставить туда 0,1,2

(1) можешь завести строку из одного символа и писать туда "А" или "Б", запрещая пустоту

(1) Можешь сделать микросервис на GO

(3) что-то оптимальное между затрачиваемыми усилиями и не утяжелением базы. РС, думаю, будет лишним, хотя, я не особо компетентен в том, на сколько сильно влияют эти вещи на объем базы. Да, сделаю либо через 0,1,2, либо перечислением. С микросервисом не знаком

Спасибо за ответы:)

Наиболее правильно - перечисление, имхо

(0) чем не устраивает механизм дополнительных сведений?

Составной тип сделай

А Неопределено при заполнении отменили?

Добавлю к (5). Переключатель. По умолчанию устанавливается значение невидимое и недоступное на форме, будет красиво. Но я не люблю подобные числовые реквизиты, лучше перечисление.

+ булево "ТерморежимностьГрузаОпределена"

(8) Не надо думать об утяжелении базы. Выкинь эти заботы из головы. Перечисление достаточно оптимальный вариант. По умолчанию пусто, при проведении проверять в ОбработкаПроверкиЗаполнения

(8) Добавлю. Стоимость хранилищ данных сегодня дешево, завтра будет еще дешевле. Поэтому надо исходить из парадигмы "Удобство разработки важнее объема данных"

(17) всё так... Только потом появляется 100500 промежуточных абстракций и все начинает тормозить. УФ открываются дольше обычных существенно

(18) если тормозит из-за большого числа реквизитов формы, значит надо выносить доп реквизиты в отдельную форму.

(18) Добавлю. Не знаю все ли реквизиты формы обмениваются между клиентом и сервером. Надеюсь что платформу уже оптимизировали под передачу исключительно изменённых реквизитов с сервера в копию на клиенте и обратно. И по идее большее число реквизитов на новых версиях платформы затруднений вызывать не должно.

(16) Думать об утяжелении базы нужно всегда.
(20) Конечно, конечно... После появления 8.3, работа с 1С просто описана в рассказе Теффи "Жизнь и воротник".

(20) Это будет скоро. В 9.6.29.

(21) Не нужно думать. Это плохой подход, эхо из эпохи программирования калькуляторов и микроконтроллеров. Мы же не на ассемблере задачу решаем, а на высокоуровневом языке. Я вообще не вижу проблемы утяжеления базы исходя из требований в (0)

(21) > описана в рассказе
А типовые кофигурации, начиная с 7.7 - в сказках Гайдука.

(7) хорошая шутейка) А по поводу  вопроса ТС, лучше сделай перечисление. Если документ типовой с БСП и есть возможность доп реквизитов, то делай через них с галкой, чтобы было обязательным заполнение.

(23) Это не плохой подход.
Это подход программиста.

(24) Я уже бросила курить. Так что - тебе виднее.