Обязательное заполнение единиц измерения в карточке Лоцман

[Askell]

Добрый день.

Необходимо заставить пользователей заполнять единицы измерения при указании количества используемых материалов (длина/ширина/высота/масса) в карточке метриала.
Во первых, почему-то изначально там поле единиц измерения не активно (cart.png) и соответственно пользователи нередко тупо вбивают число подразумевая размерность в меру своей испорченности - кто в длину мм меряет, а кто в м и т.д. Уже задолбало бегать за пользователями и уточнять "а тебе 8 м или 8 мм золотой проволоки надо?" при рассчете себестоимости. Если же открыть окно свойств и в нем карточку - то после ввода числа, поле единиц измерения становится активно, но оно все равно пустое (cart2.png).
Во вторых, даже при редактировании через вкладку "Атрибуты" - все практически нормально - по умолчанию выбрана правильная величина (в конфигураторе указан аттрибут "по умолчанию") , например "длина" (attr1.png) и не заполнить еденицу измерения просто невозможно, однако и тут пользователи находят лазейку - можно выбрать "не определено" (attr2.png) и опять в атрибуте будет число без размерности.
Как быть? Может настройки какие есть у справочника единиц измерения или в конфигураторе карточек скрытые возможности? В конце концов, может в API плагинов есть возможность подписаться на события и про сохранении изделия в базу проверять? Как сделать валидацию чтобы в базу не попадали некорректные данные? Или проще написать плагин дублирующий функциональность карточки матриалов и не дающий ввести некорректные данные? Правда в этом случае придется обяснять пользователем что теперь вместо удобной карточки им придется лазить куда-то в главное меню программы.
Версия Лоцмана - 8.5

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

[tur]

Знакомая проблема!
На мой взгляд однозначного решения не имеет. Мы боролись с подобной проблемой более года.

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

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

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

P.S. Не совсем понятно как Вы хотите программно определить правильно выбрана единица измерение или нет. Например, у нас может использоваться около 20 единиц измерения для одного и того же атрибута и доверить машине проверку достаточно рискованно.

[Askell]

Спасибо за понимание. В нашем случае уже хочется ввести аттрибут "домашние адреса конструктора и его ближайших родственников"...

[Maxxx]

Так как в ЛОЦМАН 8.5, насколько я помню, не было еще обработки серверных событий, то Вашу задачу можно решить с помощью своего плагина (который будет использоваться для заполнения данных вместо карточки). Лазейка конечно все равно остается (т.е. не захотел - не воспользовался плагином), но это уже решается организационно.

[tur]

Спасибо за понимание. В нашем случае уже хочется ввести аттрибут "домашние адреса конструктора и его ближайших родственников"...

Прекрасно понимаю!

Но боюсь как и сказал тут Maxxx:

..... Лазейка конечно все равно остается (т.е. не захотел - не воспользовался плагином), но это уже решается организационно.

Поэтому, только организационно.

[Danila]

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

Такие модули являются подмогой Нормоконтролю при переведении в архив, а также нам, специалистам АСУП, при получении необходимых данных для дальнейшей их ретрансляции в учетную систему.

[tur]

Мы решили эту поблему организационно.
Задача обязательного правильного заполнения любых атрибутов решабельна только организационно.
........

Что и требовалось доказать. Молодцы!