Нужно организовать полноценный каталог внутри, но для меня сложность стоит в иерархии номенклатуры - как ее ввизуально представить пользователю.
Кто сталкивался, м.б. есть примеры пощупать?
Нужно организовать полноценный каталог внутри, но для меня сложность стоит в иерархии номенклатуры - как ее ввизуально представить пользователю.
Кто сталкивался, м.б. есть примеры пощупать?
Что понимаете под "номенклатурой" в данном случае? В сюите можно дерево процессов организовать и вести версионность.
Цитирую Andrey Glukhov:
Что понимаете под "номенклатурой" в данном случае? В сюите можно дерево процессов организовать и вести версионность.
Пускай имеем две сущности - номенклатура и строки заказа
Строки заказа (мастер) привязываем к номенклатуре (параметр), а номенклатуру - саму на себя.
Тогда когда будем в строках выбирать номенклатуру, естественно хотелось бы, чтобы она выдавалась в форме дерева
Цитирую cr2sh:
Пускай имеем две сущности - номенклатура и строки заказа
Строки заказа (мастер) привязываем к номенклатуре (параметр), а номенклатуру - саму на себя.
Тогда когда будем в строках выбирать номенклатуру, естественно хотелось бы, чтобы она выдавалась в форме дерева
Поясните, какая у Вас цель? Что Вы хотите реализовать в bpms? Встроенный data-modeler в сюите, конечно, есть и то, чего Вы хотите, спроектировать можно, не понятно только зачем. Вы хотите вести учет в bpms?
Цель - обрабатывать заявки вовремя. Это не учет, а отдельный длиннющий БП по согласованию и обработке данных заявок.
Вопрос по наполнению номенклатуры даже не стоит - она будет из вне.
Тем не менее вопрос использования деревьев, думаю, не маловажный. Кроме номенклатуры еще много чего может строиться деревьями. ЦФО, например.
Глупо было бы оставить только согласование, а обработку вести в другом ПО, также глупо заставить людей разучивать номенклатурные коды - система должна упрощать работу, а не создавать дополнительную.
Цитирую cr2sh:
Пускай имеем две сущности - номенклатура и строки заказа
Строки заказа (мастер) привязываем к номенклатуре (параметр), а номенклатуру - саму на себя.
Тогда когда будем в строках выбирать номенклатуру, естественно хотелось бы, чтобы она выдавалась в форме дерева
Я бы сделал так - Заказ (Process entity - Master), к нему Строки заказа (Collection), к строкам Номенклатура (Parameter).
Цитирую Andrey Glukhov:
Я бы сделал так - Заказ (Process entity - Master), к нему Строки заказа (Collection), к строкам Номенклатура (Parameter).
Так и планируется, но представьте себе справочник номенклатуры в пару тысяч строк. Разворачивать и рыскать по нему без деревьев будет очень не удобно. Дерево подразумевает вложенность, т.е. в справочнике номенклатуры имеем ключ IsCatalog, если в строке А IsCatalog=1, то должен разворачиваться деревом с содержащимися позициями, ключ Parent которых равен UniqueID строки А.
Вот второй рисунок - представление в форме дерева
Цитирую cr2sh:
Так и планируется, но представьте себе справочник номенклатуры в пару тысяч строк. Разворачивать и рыскать по нему без деревьев будет очень не удобно. Дерево подразумевает вложенность, т.е. в справочнике номенклатуры имеем ключ IsCatalog, если в строке А IsCatalog=1, то должен разворачиваться деревом с содержащимися позициями, ключ Parent которых равен UniqueID строки А.
Вот второй рисунок - представление в форме дерева
![]()
Знакомые картинки УПП :-) Делайте несколько вложенных сущностей типа Parameter - сначала группы...и на самом нижнем уровне номенклатура.
Цитирую Andrey Glukhov:
Знакомые картинки УПП :-) Делайте несколько вложенных сущностей типа Parameter - сначала группы...и на самом нижнем уровне номенклатура.
УПП для примера - первое, что нашел гугль
Несколько вложенных сущностей - эт изврат, как для работы, так и для обработки БД. У нас не всегда будет одинаковое количество уровней дерева, да и кроме Bizagi будут и другое ПО работать с БД.
ЧТо, совсем нет человеческого способа работы с деревьями?
Цитирую cr2sh:
УПП для примера - первое, что нашел гугль
Несколько вложенных сущностей - эт изврат, как для работы, так и для обработки БД. У нас не всегда будет одинаковое количество уровней дерева, да и кроме Bizagi будут и другое ПО работать с БД.
ЧТо, совсем нет человеческого способа работы с деревьями?
Тогда поставьте нормальную систему НСИ, от bpms такого функционала я бы не стал требовать. Хотя, может быть я чего-то и не знаю, спросите у Анатолия Белайчука, он наверняка даст Вам правильный ответ :-)
Цитирую cr2sh:
УПП для примера - первое, что нашел гугль
Несколько вложенных сущностей - эт изврат, как для работы, так и для обработки БД. У нас не всегда будет одинаковое количество уровней дерева, да и кроме Bizagi будут и другое ПО работать с БД.
ЧТо, совсем нет человеческого способа работы с деревьями?
Подумал еще над Вашей проблемой. Вполне можно обойтись одной параметрической таблицей (да, она будет очень большая), добавив доп. поля с ключами, показывающими принадлежность элемента к той или иной группе. Потом по этим полям фильтровать таблицу скриптом по динамическому фильтру когда нужно извлечь группу или ее часть.
Вообще-то специалисты по юзабилити говорят, что деревья - это прошлый век. К примеру, продвинутые пользователи Windows давно уже не ходят по папкам в проводнике, а сразу пользуются поиском.
Здесь мы можем пойти тем же путем - у Bizagi есть полезный контрол под названием "Suggest". Номенклатурный справочник в несколько тысяч записей? Поиск по первым буквам решает проблему.
Если же позарез нужно именно дерево, то можно разработать свой виджет.
Вы должны авторизоваться, чтобы публиковать сообщения.