Показать сообщение отдельно
Старый 27.01.2021, 22:53   #19  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,655 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Это не о том

Здесь речь идет о выборе в головной таблице того ТИПА объекта с которым в дальнейшем будет осуществляться работа. Не фиксация уже свершившегося факта как с InventTrans.TransType, а именно выбор. Каким путем дальше пойдет работа

Соответственно, на это завязано много "спец.эффектов". Когда переключая значение Base Enum автоматически переключаем и ряд функций, связанных с полем-ссылкой. Выпадающие списки, переход к основной таблице, контроль. И все это "автоматически". Без дополнительного кодирования

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

Хотите работать с разными типами объектов - создавайте разные документы. Не надо смешивать в одном документе несколько типов объектов одновременно. Речь не идет о логах и проводках (итоговая "свалка"). Речь идет именно о самих исходных документах

Ну, условно говоря, если стоит вопрос, с поставщиком или с клиентом будем создавать заказ, то это надо делать 2 разных типа документов (набора таблиц): заказы с поставщиком и заказы с клиентом. Не надо пытаться "впихнуть" это все в один набор таблиц с фильтром по Base Enum


Если бы речь шла только и исключительно о ссылочной целостности, то это как раз показательный пример с InventTrans.Там же просто тупо выбросили TransType и все.

Не проводка выбирает с кем будет работать, а проводку создают из заранее известного документа. Поэтому TransType в ней выполнял не управляющую, а информационную (справочную) функцию. Избыточно с точки зрения нормализации (лишнее поле). Вот его и выбросили. А что связи искать потребуется больше времени, так это не аргумент
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...