Иерархический справочник и Axapta.

[Тимур_imported]

Цитата:

Сообщение от =A=L=X=

Суммирование итогов по иерархиям многоуровневого древовидного справочника ассортимента позволяет дать ответы на вопросы типа "какое товарное направление даёт больше прибыли, т.е. какую ветвь ассортимента имеет смысл развивать и анализировать в первую очередь", ну и т.п. Тут кстати видно что есть возникнет много спорных моментов за и против, но представте что у вас ассортимент из 50000 позиций... Фильтры по поставщику и товарному направлению тут не дадут желаемого эффекта.
Теперь предположим мы хотим дать скидку 10% на шурупы, но ни на какой другой товар, вклюая например гвозди... Фильтр "*шуруп*" по наименованию даст неожиданную скидку на "шуруповёрт....(назв. модели)" к примеру... А вот ассортиментный древовидный каталог на порядок упрощает задачу (пусть даже фильрации в данном случае).

Цитата:

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

А что изменилось по вашему с тех времен коренным образом, что перевернуло ситуацию с ног на голову?

Цитата:

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

Сложно? Отчего же? А мне совсем не сложно. Например счёт налогов вроде бы логично отнести к убыткам - убыток ведь от прибыли... или например расчёты с покупателями отнести к издержкам производства - ведь каждое произведенное изделие в стоимость будет включать свою себестоимость...
Тут дело спасает только здравый смысл (как и в случае с ассортиментом) и законодательная база.

Цитата:

И даже если программист напишет, а пользователь будет пользоваться иерархическим номенклатурным справочником, то стоит задуматься к чему это может привести? А собственно будет ли удобно работать другим пользователям? Как они будут бороться с дубликатами?

С этим спорить сложно. Всё так и есть. Но эти же проблемы существуют и у плоских справочников. Те же самые.

Мы как то в итоге раскололи своё видение на "можно/нельзя"... А это неправильно... Я бы в итогде сказал бы "нежелательно". Причём не "крайне нежелательно", а скорее "если не хотите программить - нежелательно".
А тут нужно помнить главный лозунг этого форума "не программьте!"

Фильтры должны делаться по полям, которые являются списками. То есть существует классификаторы номенклатурных позиций.
Если выбрали "шурупы", то отфильтруются только позиции со значением "шурупы".

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

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

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