Существуют ли шаблонные пути реализации таких требований?

[Romb]

Цитата:

Сообщение от Ivanhoe

Пользователю удобнее физ. поля в основной таблице.

Почему вы так считаете? Пользователь вообще не знает что за этими полями. Для него они просто есть в форме (формах).

[mazzy]

Цитата:

Сообщение от Romb

Почему вы так считаете? Пользователь вообще не знает что за этими полями. Для него они просто есть в форме (формах).

вы вообще или про Аксапту?
и почему говорите только про формы? а отчеты? а кубы? а права? а полнотекстовый поиск? а импорт/экспорт? aif? а excel addon для редактирования данных?

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

Если работаете с 2012, то попробуйте даже тупую унаследованную таблицу, не говоря уже о foreign

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

программиста же отдельная таблица вынуждает очень много программировать на формах (см. как приходится вручную управлять таблицей InventDim в формах), много программировать очистку данных (при удалении master данных), программировать логику экспорта/импорта, дополнительно предусматривать join в отчетах и кубах. не говоря уже о правах, особенно rls

=======================
В общем, поля в таблицах - значительно проще. (не факт, что лучше в данном конкретном случае)
Но не забывайте, что заказы - это черновики (заказы - могут удаляться). Поэтому данные в заказах хранить нельзя. Фактические данные нужно протаскивать в документы.

[pitersky]

Цитата:

Сообщение от mazzy

не забывайте, что заказы - это черновики (заказы - могут удаляться). Поэтому данные в заказах хранить нельзя. Фактические данные нужно протаскивать в документы.

уже второй раз встречаю этот тезис.
насколько я понимаю логику системы, удалять можно строки заказа/журнала. Ибо важны не строки, а проводки.
Но заголовок??? Производные документы (отборки, накладные) далеко не всегда содержат данные, которые есть в заголовке заказа. Те же кластеры, к примеру, которые протаскивать в накладные совершенно не нужно. Да и бизнес-логика в удалении именно заголовка заказа мне лично непонятна.

[mazzy]

Цитата:

Сообщение от pitersky

уже второй раз встречаю этот тезис.
насколько я понимаю логику системы, удалять можно строки заказа/журнала. Ибо важны не строки, а проводки.
Но заголовок??? Производные документы (отборки, накладные) далеко не всегда содержат данные, которые есть в заголовке заказа. Те же кластеры, к примеру, которые протаскивать в накладные совершенно не нужно. Да и бизнес-логика в удалении именно заголовка заказа мне лично непонятна.

ответил в отдельной ветке.
черновики (заказы - могут удаляться). Поэтому данные в заказах хранить нельзя. Фактические данные нужно протаскивать в документы.

[Romb]

Цитата:

Сообщение от mazzy

вы вообще или про Аксапту?
и почему говорите только про формы? а отчеты? а кубы? а права? а полнотекстовый поиск? а импорт/экспорт? aif? а excel addon для редактирования данных?

Mazzy, спасибо за комментарий, не совсем понимаю что на него отвечать, я просто поясню свою позицию.

I. Тут присутствует работа с требованиями (RM).

Приведенные требования:

Цитата:

При создании заказа по умолчанию он наследует эти же 6 характеристик от клиента, но можно указать другие или удалить некоторые и тд.

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

В требованиях не написано ничего о кубах, отчетах, EDI и т.д.. Можно самостоятельно расширять дерево функциональности за заказчика, придумывать за него требования, но применительно к характеристикам обсуждены и предложены всего два сценария "указать другие" и "удалить некоторые", с предусловием "при создании заказа". (и, очевидно, что будут свои требования на обработку граничных условий, например "у клиента изменились характеристики, в этом случае характеристики у уже созданных заказов на этого клиента должны быть изменены...").

II. Дизайн.
1. Появляется одна новая сущность "Характеристика" с отношением "один ко многим" к сущностям "Заказ" и "Клиент".
2. Схему данных тут надо делать так: 1. Создать таблицу "Характеристики". 2. Создать таблицу "Наборы характеристик", которая и будет реализовывать связь с Характеристик с Заказами и Клиентами.
3. В случае с добавлением 6-и полей схема данных просто не будет нормализована. Это, например, выльется в т.ч. в явные проверки в коде по этому количеству полей, или, как минимум постоянные проверки на соответствие типов-массивов в разных таблицах и циклы по перебору этих полей в соответствии с размерностью типов. В это же время, при схеме данных из варианта №2, код будет написан один раз для любого количества характеристик.

III. Кодирование. Не думаю, что правильно применять тут оценки "в этом случае работы программисту больше/меньше". Последнюю оценку может давать только конкретный специалист-исполнитель. Но, важным ключом к количеству работы программиста является эффективность схемы данных, даже в такой небольшой задаче. Поэтому, надо придерживаться приоритетов при выполнении работы: 1) Утвердили требования (сценарии) 2) Смоделировали сущности 3) Смоделировали нормализованную схему данных. 4) Кодируем логику.

Прошу извинить за объем комментария, у меня нет цели вступить в спор/обсуждение. Буду рад, если моя аргументация окажется кстати, или некстати. Главное же результат.

[mazzy]

Цитата:

Сообщение от Romb

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

в вашем рассуждении есть неявное условие.
вы неявно подразумеваете "только":
* только через формы,
* только "указывать", только "удалять".
* только клиент Аксапты

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

Хоть этого и нет в требованиях, но пользователи рано или поздно захотят анализировать введенную информацию. Без такого подразумеваемого желания никто дополнительную информацию вводить не будет.

Если анализировать - то это или запросная форма в клиенте Аксапты, или отчет в Reporting Service (так уж устроена Аксапта), либо куб. Либо еще как-то.

Но это точно не только клиент Аксапты, не только через формы, не только указывать и удалять.

Шах и мат

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

Цитата:

Сообщение от Romb

В требованиях не написано ничего о кубах, отчетах, EDI и т.д.. Можно самостоятельно расширять дерево функциональности за заказчика, придумывать за него требования, но применительно к характеристикам обсуждены и предложены всего два сценария "указать другие" и "удалить некоторые", с предусловием "при создании заказа".

Ну, если такова ваша принципиальная позиция...
Как скажете

[Ivanhoe]

Цитата:

Сообщение от Romb

Почему вы так считаете? Пользователь вообще не знает что за этими полями. Для него они просто есть в форме (формах).

mazzy уже ответил. От себя добавлю - пользователю все равно до тех пор, пока эти поля работают "как ожидается". Т.е. работают фильтры и сортировки, поля можно легко и просто двигать, добавлять, использовать в расширенном фильтре. Хотя бы это. Дальше - целиком согласен с mazzy.

И да, ответственному за user experience в AX 2012 надо бы всё оторвать, что можно. Это ужас какой-то.