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

[mazzy]

Цитата:

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

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

Да, хотелось бы.

[MArshak IX]

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

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

• Иерархия позволяет указать суммирование значений элементов
  Примеры,
  - Бухгалтерский план счетов, где в счете суммируется итоги по субсчетам
  - Сруктура предприятия, где суммируется фонд оплаты труда, вакансии и занятые вакансии и т.п.
  - Статьи затрат, где в группы статей суммируются элементы статей затрат
  - и т.д.
• Упрощение ввода новых элементов
  Не секрет, что в различные группы могут вводиться элементы с разными значениями реквизитов по умолчанию. У нас так вводятся различные группы готовой продукции, что существенно упрощает для пользователя ввод новых элементов, так как ему необходимо правильно выбрать группу иерархии и значительная часть реквизитов будет определена по умолчанию.

Сделаю некоторое отступление:

• Глубина иерархии
  Обращу внимание, что при разработке не всегда известно какая глубина иерархии будет существовать при дальнейшей работе системы (месяц, год, десятилетие и т.д.), особенно со структурой предприятия и статьями затрат, которые могут измениться со временем.
• Пример реализации в САПе
  Интересная реализация иерархии была сделана в САПе для структуры Мест возникновения затрат (МВЗ):
  - Одновременно может существовать несколько структур иерархии одних и тех же элементов МВЗ
  - Каждая структура иерархии МВЗ может быть изменена со временем, но остается известным какая структура была до момента изменения
• Чего не хватает в 1С
  В 1С мне страшно не хватает одновременного использования иерархии и отбора элементов по фильтру. К сожалению, либо по дереву, либо по отбору элементов, а это позволило бы существенно упростить поиск в статьях затрат, плане счетов (когда план счетов существенно развернут) и т.д.

Что мне бы хотелось от функциональной возможности иерархии справочника:

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

Возможна ли реализация данных возможностей в Аксапте (оговорюсь, что я не спец по аксапте)?

[Alks]

Цитата:

Возможна ли реализация данных возможностей в Аксапте (оговорюсь, что я не спец по аксапте)?

Да.
Кроме того - последние мои посты сюда я спрашивал возможно ли в ней строить динамические запросы (тогда я понимал только статические запросы встроенные в синтаксис языка) - мне не ответили, но со временем я выяснил что да, можно, половина аксапты использует Query и QueryRun, которые имеют такой потенциал.

[Тимур_imported]

Цитата:

Сообщение от Marshak IX

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

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

• Иерархия позволяет указать суммирование значений элементов
  Примеры,
  - Бухгалтерский план счетов, где в счете суммируется итоги по субсчетам
  - Сруктура предприятия, где суммируется фонд оплаты труда, вакансии и занятые вакансии и т.п.
  - Статьи затрат, где в группы статей суммируются элементы статей затрат
  - и т.д.
  
  
• Упрощение ввода новых элементов
  Не секрет, что в различные группы могут вводиться элементы с разными значениями реквизитов по умолчанию. У нас так вводятся различные группы готовой продукции, что существенно упрощает для пользователя ввод новых элементов, так как ему необходимо правильно выбрать группу иерархии и значительная часть реквизитов будет определена по умолчанию.

Сделаю некоторое отступление:

• Глубина иерархии
  Обращу внимание, что при разработке не всегда известно какая глубина иерархии будет существовать при дальнейшей работе системы (месяц, год, десятилетие и т.д.), особенно со структурой предприятия и статьями затрат, которые могут измениться со временем.
  
  
• Пример реализации в САПе
  Интересная реализация иерархии была сделана в САПе для структуры Мест возникновения затрат (МВЗ):
  - Одновременно может существовать несколько структур иерархии одних и тех же элементов МВЗ
  - Каждая структура иерархии МВЗ может быть изменена со временем, но остается известным какая структура была до момента изменения
  
  
• Чего не хватает в 1С
  В 1С мне страшно не хватает одновременного использования иерархии и отбора элементов по фильтру. К сожалению, либо по дереву, либо по отбору элементов, а это позволило бы существенно упростить поиск в статьях затрат, плане счетов (когда план счетов существенно развернут) и т.д.

Что мне бы хотелось от функциональной возможности иерархии справочника:

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

Возможна ли реализация данных возможностей в Аксапте (оговорюсь, что я не спец по аксапте)?

Алексей.

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

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

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

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

[Alks]

Цитата:

Если говорить об объектах системы, то что дает суммирование номенклатурных позиций в иерархическом справочнике?

Алексей уже наверное спит в своём часовом поясе, а у меня только только дело приближается к полуночи, так что постараюсь ответить за него. Хотя это и моё имхо.

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

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

[mazzy]

Цитата:

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

А тут нужно помнить главный лозунг этого форума "не программьте!"

Похоже, что пора простой лозунг перевести в конструктивную форму:
программируйте эффективно и результативно

[mazzy]

Цитата:

Сообщение от Marshak IX

Возможна ли реализация данных возможностей в Аксапте (оговорюсь, что я не спец по аксапте)?

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

Но случились разные события, которые сильно отвлекли ресурсы.
Постараюсь закончить статью, как будет время.

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

[MArshak IX]

Был занят это время, поэтому не просматривал топик и не ответил сразу на сообщение Тимура.

Спасибо =A=L=X=, согласен на все 100 с твоим мнением.

Цитата:

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

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

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

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

[Тимур_imported]

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

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

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

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

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

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

[Тимур_imported]

Цитата:

Сообщение от Marshak IX

Был занят это время, поэтому не просматривал топик и не ответил сразу на сообщение Тимура.

Спасибо =A=L=X=, согласен на все 100 с твоим мнением.

Цитата:

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

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

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

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

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

[Alks]

Цитата:

Похоже, что пора простой лозунг перевести в конструктивную форму:
программируйте эффективно и результативно

О да, согласен. У меня только недавно начал формироваться "взляд с высоты птичьего полёта" на архитектуру и принципы программного устройства аксапты и оглядываясь назад вижу программисты, которые будут сопровождать мой код после меня нередко будут плеваться и костерить девелопера разными словами. К примеру уже есть табличка, в которой складская аналитика прошита не по InventDimId, а напрямую одним из своих полей (InventColorId). А почему так? Потому что документации минимум, до самых базовых вещей приходится добираться самому и вслепую.

Цитата:

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

Т.е. в виде реального дерева, а не отношения один-ко-многим?

[Alks]

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

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

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

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

[Alks]

Цитата:

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

Когда у вас 50000 товаров такой подход становится неэффективен, если не организовать в самом классификаторе уровни. Причём это можно делать и без дерева, по принцип один-ко-многим (см. например отношение склад-ячейка в wms Аксапты). И, что характерно, тут опять без программинга обойтись трудновато - в лукапах таких полей по идее должны срабатывать автофильтры подчинённых полей при выборе поля более высокого уровня... А это уже не всегда выполнимо...

Цитата:

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

Да ассортиментное дерево уже потому только имеет право на существование, что служит незаменимым классификатором для клиента. Реальный пример могу привести который со мной произошёл - решил я как то по нашей базе цены на шторы посмотреть, ввёл фильтр "*шторы*", "*штора*", не нашёл. Пожал плечами, залез в деревянный классификатор и за 5 кликов мышью нашёл что шторы в готовом виде у нас не продаются, а продаются такие вещи как "ткань тюлевая", "ткань портьерная" и т.п. В принципе я мог бы подойти к продавцам или менеджеру по этому товарному направлению и спросить, но сами понимаете что веб-магазин к примеру без древовидного классификатора номенклатуры может очень сильно потерять в прибыли из-за того что клиенты просто не найдут в справочнике номенклатуры что хотят, или ЧТО САМОЕ ГЛАВНОЕ - не найдут в справочнике того чего они не знали что захотят.

Цитата:

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

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

[MArshak IX]

Цитата:

Сообщение от Тимур

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

Кхм... очень, конечно, интересно поговорить с человеком, который АБСОЛЮТНО в чем-то убежден и не готов прислушиваться к словам аппонентов.

Но все-таки попробую, Тимур, еще раз тебе ответить на каждое отдельное предложение.

Цитата:

Надо думать для чего справочник.

Позвольте, а почему только справочник? Почему ограничиваемся только справочником, когда существуют множество примеров применения дерева:

• План счетов (не смотря на то, что он меняется редко, но он подвержен изменению)
  
  
• Цепочка ввода документов (заказ, счет, накладная, счет-фактура, приходный кассовый ордер, возвратная накладная и т.д.)
  
  
• Последовательность выполнения процедур бизнесс-процесса (как меня задолбала в нешей фирме выписка командировочных... кто бы знал!..)
  
  
• Зависимость метаданных (подчинение метаданных, которая существует в Аксапте в том числе)
  
  
• Создание цепочек обсуждения, событий и сообщений (к примеру в 1С сейчас появляется почтовый клиент. Плохо это или хорошо не говорю, но это явный пример применения иерархического дерева)
  
  
• и т.д.

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

Цитата:

Зачем инструмент, если он ненужен?

Упс... Встают непробиваемым частоколом список вопросов:

• Так все же, Тимур, ты говоришь об инструменте или о контретной реализации?
  
  
• Кто сказал, что этот инструмент (если ты об инструменте) не нужен вообще?
  
  
• Кто сказал, что не нужен в частности?
  
  
• Зачем задавать вопрос, если ты уже знаешь ответ?

Цитата:

Суммирование номенклатурных позиций - это полная бессмыслица.

Полностью с тобой согласен, то, что ты написал полная бессмыслица! А вот если попробовать просуммировать по группам номенклатурных поциций:

• выручку
• затраты
• себестоимость
• оказанные скидки покупателям
• маржинальную прибыль

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

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

[Alks]

Так, по мелочам поправлю MarshakIX:

Цитата:

Цепочка ввода документов (заказ, счет, накладная, счет-фактура, приходный кассовый ордер, возвратная накладная и т.д.)
...
Последовательность выполнения процедур бизнесс-процесса (как меня задолбала в нешей фирме выписка командировочных... кто бы знал!..)

В данном случае идет речь скорее о древовидном представлении информации, а не древовидном хранении.

Цитата:

А вот если попробовать просуммировать по группам номенклатурных поциций

По себе знаю - привычку суммировать по группам номенклатурных позиций имеют программисты и пользователи 1С. У нас на предприятии таким образом обычно оцениваются целиком торговые отделы (которых сравнительно немного и реализованы они могут быть простым для аксапты способом - через одну из финансовых аналитик). Вот с итогами по подгруппами уже сложнее - с одной стороны менеджеру интересно бывает поанализировать свои товары целиком по подгруппам, но если задуматься тут возможны варианты, как ему добится желаемого используя совсем другую информацию.

Вспомните еще что против "древовидных классификаторов" в конечном итоге никто не спорит - например BOM в аксапте реализованы таким способом, ибо другого способа нет. Но как то исторически повелось-закрутилось что весь спор разгорелся вокруг ассортиментного классификатора н-ры, т.к. тут действительно сталкиваются две волны, идущих к аксапте из 1С, где деревья поощерялись и "бывалых" аксаптовцев. Последние знают мощь и силу аксаптовских фильтров и, как правило, лучше владеют принципами СУРБД, поэтому споры разгорались наижарчайшие.

В остальном согласен.

[Тимур_imported]

Цитата:

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

Да ассортиментное дерево уже потому только имеет право на существование, что служит незаменимым классификатором для клиента. Реальный пример могу привести который со мной произошёл - решил я как то по нашей базе цены на шторы посмотреть, ввёл фильтр "*шторы*", "*штора*", не нашёл. Пожал плечами, залез в деревянный классификатор и за 5 кликов мышью нашёл что шторы в готовом виде у нас не продаются, а продаются такие вещи как "ткань тюлевая", "ткань портьерная" и т.п. В принципе я мог бы подойти к продавцам или менеджеру по этому товарному направлению и спросить, но сами понимаете что веб-магазин к примеру без древовидного классификатора номенклатуры может очень сильно потерять в прибыли из-за того что клиенты просто не найдут в справочнике номенклатуры что хотят, или ЧТО САМОЕ ГЛАВНОЕ - не найдут в справочнике того чего они не знали что захотят.

Расскажу я актуальную историю (декабрь) про то, как я заказывал в Интернете дополнительный модуль памяти для ноутбука.
Вроде бы акссесуар? Ага пользуюсь "гениальным" интерфейсом - древовидным справочником, который как бы вроде должен быть удобен покупателю (черт, наверное, я нетипичный покупатель ) Ищу в ряде магазинов модуль в разделе "Аксессуары": пусто. В некоторых есть. Причем поисковая система мне четко сообщила, что и в тех и в других магазинах этот модуль имеется.
Воспользовался поиском на сайте. Ага! Есть только в разделе модули памяти.
Так вот мне понравился поиск только в нескольких магазинах, которые дают возможность искать по классификаторам.
Мне все равно отбрасывает ли система сразу недопустимые значения в подчиненных классификаторах или классификаторы независимы. Суть - фильтрация - критерии поиска, многомерный поиск (я бы так сказал), а не плоское "ползанье" по дереву.
Да, а в некоторых магазинах модуль нашелся аж в трех разделах.

Если покупатель не знает, что есть новая примочка к компьютеру, то зайдя в магазин, врядли он будет рыться в деревьях.
Простой пример, когда дерево летит к чертовой бабушке: как правильно строить дерево? По вендору? (Я например, сразу хочу отфильтровать по вендору IBM) Или по группе? Или по типу? Мне, как потребителю, неудобно пользоваться чьей иерархией. А вот фильтры классификационные очень удобны.
И боролся я успешно с пользователями в компьютерной компании за то, чтобы не было этих деревьев.

P.S. Коллеги. Иерархию имеет смысл использовать там, где что-то суммируется. В номенкатурном справочнике ничего не суммируется! Даже если будет в таблице товаров хранится информация о материнском узле, то в другие таблицы (где собственно используется номенклатура), она не будет попадать, а если попадает - то это на мой взгляд, увеличение базы данных - "бездумное и беспощадное".

[Тимур_imported]

Цитата:

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

Вспомните еще что против "древовидных классификаторов" в конечном итоге никто не спорит - например BOM в аксапте реализованы таким способом, ибо другого способа нет. Но как то исторически повелось-закрутилось что весь спор разгорелся вокруг ассортиментного классификатора н-ры, т.к. тут действительно сталкиваются две волны, идущих к аксапте из 1С, где деревья поощерялись и "бывалых" аксаптовцев. Последние знают мощь и силу аксаптовских фильтров и, как правило, лучше владеют принципами СУРБД, поэтому споры разгорались наижарчайшие.

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

[Тимур_imported]

Цитата:

Сообщение от Marshak IX

Последовательность выполнения процедур бизнесс-процесса (как меня задолбала в нешей фирме выписка командировочных... кто бы знал!..)

или я не знаю?

[Тимур_imported]

Цитата:

Сообщение от Marshak IX

Кстати, почему в САПе вводится отдельный справочник "Номенклатурные группы" именно для эмуляции дерева справочника Номенклатуры, но этот справочник не позволяет дальнейшей детализации.

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

Ну не могу сказать отчего в SAP R/3 это сделано, потому что в первый раз слышу, что есть такая визуализация как иерархия в справочнике "Материалы".
:P

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

[Maxim Gorbunov]

Цитата:

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

Цитата:

Сообщение от Marshak IX

Возможна ли реализация данных возможностей в Аксапте (оговорюсь, что я не спец по аксапте)?

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

Еще раз выскажу свое мнение: "правильной" реализации дерева в Axapta нет. Варианты реализации дерева на основе реляционной СУБД описаны в статье на SQL.RU (ссылка уже дважды давалась выше по теме). В том числе там есть вариант, который mazzy описывает и в своей статье. Каждый из вариантов, по моему убеждению, имеет право на существование, а выбор конкретной реализации в каждом конкретном случае диктуется условиями задачи. Тот факт, что для решения задачи используется Axapta, влияет на выбор решения не более, чем то, что для хранения данных используется реляционная СУБД.