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

[IKA]

Достаточно стандартная задача, но интересно, как можно ее эллегантно решить:
К клиенту может быть привязан набор характеристик (варианты доставки или ких-нить ответственных лиц - все, что угодно), каждая из которых ссылается на один и тот же справочник. Заказчик уверяет, что в нашем случае этих конкретных характеристик может быть для клиента указано не более 6.
При создании заказа по умолчанию он наследует эти же 6 характеристик от клиента, но можно указать другие или удалить некоторые и тд.

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

3) можно при создании набора характеристик для клиента этому набору свой идентификатор присваивать и его копировать в создаваемый заказ. Если переопределяется набор на уровне заказа, то ему присваивается новый идентификатор.
Но тут опять таки же те же вопросы, как и с 2) - как сделать удобным интерфейс и не городить кучу кода.

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

Поделитесь опытом. Буду благодарна сслыкам на примеры реализации.

AX2012 R2

[mazzy]

Цитата:

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

а потом в таблицу клиентов добавить 6 полей и в заказы тоже 6 полей

Сперва:
заказ - это черновик!
заказ (как и черновик) может быть удален в любой момент.
данные нельзя оставлять в заказе!
данные должны быть протащены через SalesParm* до фактических документов - Invoice и СФ.

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

поэтому добавить в таблицы (как минимум):
* клиент
* заказ
* SalesParmTable / PurchParmTable
* Накладная, СФ


щас будет ответ по сути.

[mazzy]

раньше ответ был бы простой: используйте функционал модуля CRM в Аксапте.

сейчас ответ будет непростым. Дело в том, что сейчас Майкрософт не будет развивать модуль CRM в Аксапте. а будет двигать в сторону связки с Dynamics CRM. Поэтому фиг его знает как сэкономить усилия в будущем.

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

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

[gl00mie]

Что касается наборов характеристик - в 2012-й есть прекрасный пример с табличками DimensionAttributeValueSet + DimensionAttributeValueSetItem, стоит полюбопытствовать, сколько кода наверчено вокруг них
По-моему, если поля совсем-совсем нестандартные (вариант доставки точно ли не связан со стандартным функционалом?), то лучше на самом деле сделать отдельные поля. К слову, кроме таблиц еще имеет смысл прописать логику работы с этими полями в AxBC-классах, чтобы потом не мучиться с импортами/интеграциями/проч.

[SRF]

Если характеристики одинаковые, то чем не устраивает старый добрый Dimension(т.е. поле массив) ?

В случае если количество характеристик должно быть динамическим и также должно отображаться - то надо действительно смотреть в сторону фин. аналитик в dax2012, но тут сразу должны понимать, что эти поля придется показывать на отдельной вкладе и отображение их в гриде будет достаточно проблематичным, если вообще возможным.

Если количество всегда одно и тоже, то в качестве шаблона для пункта три можно было бы посмотреть в сторону InventDim.

[Ivanhoe]

Пользователю удобнее физ. поля в основной таблице. Программисту - намного проще шесть полей (или dimension). Если реально не планируется 6 превратить в 60, то первый вариант оптимален.

[Romb]

Цитата:

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

Думаю надо так сделать:

Создавайте таблицу из второго варианта. При создании заказа _всегда_ копируйте в нее набор характеристик со значениями из клиента. В формах (заказ, клиенты) редактирование набора характеристик делается несложно (строки же заказа отображаются приджойненым датасорсом - также и редактирование набора характеристик). Каким ключом вы будете идентифицировать наборы - есть варианты (например, код таблицы + код записи в таблице и там уже не важно к чему именно эти наборы привязывать). С точки зрения среды разработки АХ необходимости в куче кода нет. А вариант №1 - это головняк, в любом случае! "Поля-уродыши" суть нарушение нормальной формы отношений.
imho

[Romb]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

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

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

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

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

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

[pitersky]

Цитата:

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

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

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

[belugin]

Тут вопрос компромисса между гибкостью и полнотой использования morphx.

1. Если характеристики заранее неизвестны, то EAV
2. Если характеристики известны, то либо добавить в те же таблицы + создать map для доступа к ним единообразно (здесь MorphX будет использоваться наиболее полно)
3. Либо дополнительную таблицу (тогда либо отдельной формой редактировать, либо придтся геморроиться как с inventDim или LedgerJournalTrans_RAsset)

Учтите, что в Ax 2012 появилась такая вещь как registerOverrideMethod (см, например, \Classes\AccountingDistributionFormView\registerOverloadMethods) то есть больше функциональности можно вынести из формы (я, правда, с источниками данных их не пробовал).

Попробуйте привети все сведения об этих полях, что о них известно (количество <= 6, тип?, сколько заполнено одновременно)

[Romb]

Цитата:

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

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

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

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

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

Цитата:

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

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

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

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

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

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

[Ivanhoe]

Цитата:

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

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

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

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

[mazzy]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

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

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

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

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

Шах и мат

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

Цитата:

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

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

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

[EVGL]

Удивительно: по задаче, не стоящей и выеденного яйца, такие дискуссии. Создайте новую таблицу, сделайте там поле типа массив и приджойните по RecId для начала к таблице клиентов. Ее же или потомка от нее (чтобы разделить таблицу справочных данных и таблицу оперативных данных; к несчастью, унаследованная таблица в R2 будет физически одна и та же таблица) приджойните к таблице заказов.

[fed]

На мой взгляд - лучшее решение - это просто забить на это требование, а пользователю поставить -20 в карму Если пользователь рассуждает об "аттрибутах", то надо сначала спросить - какие это аттрибуты, как они влияют на бизнес процессы и тп. Есть большие шансы, что процентов 20-30 этих аттрибутов очень даже влияют и по ним надо писать детальную постановку (и думать как их положить в систему). А оставшиеся 70-80 процентов аттрибутов можно будет пообещать в светлом будущем, и по возможности, просто задинамить эту задачу...

[EVGL]

Цитата:

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

На мой взгляд - лучшее решение - это просто забить на это требование, а пользователю поставить -20 в карму Если пользователь рассуждает об "аттрибутах", то надо сначала спросить - какие это аттрибуты, как они влияют на бизнес процессы и тп. Есть большие шансы, что процентов 20-30 этих аттрибутов очень даже влияют и по ним надо писать детальную постановку (и думать как их положить в систему). А оставшиеся 70-80 процентов аттрибутов можно будет пообещать в светлом будущем, и по возможности, просто задинамить эту задачу...

Метод опытного консультанта: организационное решение

[axguru]

если есть возможность лучше разделить характеристики клиента (для всех заказов) и заказа (значение по умолчанию из клиента), с точки зрения программирования - задача простая, решал ее двумя способами

1. три таблицы, например
CustVendParamTable - таблица параметров (поля: код параметра, тип значения 0 - ссылка, 1 - строка)
CustVendParamValue - набор значений для параметра, если тип параметра ссылка (поля: код параметра, код значения, наименование )
CustVendParam - таблица со значения параметров для контрагента, заказа и т.д. (поля: refTableId, refRecId - ссылка на исх. запись, код параметра, значение)
Интерфейс - грид на закладке или отдельная форма

2. отдельная таблица связана с родителем (Клиенты, Заказы, Накладные и т.д.) например через tableId, recId, каждое поле фикс. тип параметра. Да таблица пухнет, но проще собирать отчетность. Интрефейс - грид с темповой таблицей на закладке или отдельная форма.

[mazzy]

Цитата:

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

Создайте новую таблицу, сделайте там поле типа массив

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

ни в коем случае не используйте массив.
в массив майкрософт так и не смог. от слова никак.

элементам массива нельзя задать разные права (вернее, можно. но через жопу)
с элементами массива будет непросто написать select-запросы. (особенно в части group by, order by)
с элементами массива глючит autoRelation

В общем, массив - в последнюю очередь.

================================