Построить представление с иерархией из данных с разных документов

  • Автор темы John_V
  • Дата начала
Статус
Закрыто для дальнейших ответов.
J

John_V

#1
Есть база, в которой присутствуют документы пользователей и документы подразделений.
Причем структура подразделения может иметь несколько (кол-во м.б. разным) уровней вложенности, т.е. Организация-отдел-группа (например), а организация от отдела отличается только наличием в названии вида юр лица, т.е. ОАО, ООО, ЗАО и пр.
Как можно построить представление, чтоб оно сначало отображало список организаций, и как подчиненные списки, работников этих организаций?
Я уже голову сломал, сделал пока статично, по идентификатору документа организации, но хотелось бы чтоб это строилось либо по даным из словаря, либо как-то еще, но автоматом... пока я не придумал как это решить :(

Спасибо
 
S

Sandr

#3
Создавайте документы работников как дочерние к документам отелов. Документы отделов в свою очередь как ответные к документам организаций. Документы во вьюхе показывайте в виде иерархии...

Если связь на респонсах не приемлема, но есть какой-то признак, связывающий документы, то можно использовать фичу вьюхи под названием Default. Например:

Есть документ организации. Есть документ подразделения. Есть документ сотрудника. Документы связаны между собой только присутвием поля ParentUNID (связи отец-сын нету).

Тогда во вьюхе, в отборе пишите такое

Default $Ref:=ParentUNID;
а дальше что там у вас в формуле отбора было...


Вьюхе говорите отображать в виде иерархии...

Только нужно учесть, что ParentUNID должен хранить значение запписанное не LS, а собакой и без @Text. тобишь значение должно быть реальным унидом, а не его тектовым эквивалентом...
 

fedotxxl

Well-known member
09.11.2005
614
0
#4
Для: Sandr
Default $Ref:=ParentUNID;
а дальше что там у вас в формуле отбора было...
Млин, ну зачем такие вещи рассказывать?... Вот если бы я об этом не знал, то был бы рад... А так народ должен находить такое где-нить в трущебах официального форума :(
 
J

John_V

#5
Создавайте документы работников как дочерние к документам отелов. Документы отделов в свою очередь как ответные к документам организаций. Документы во вьюхе показывайте в виде иерархии...

Если связь на респонсах не приемлема, но есть какой-то признак, связывающий документы, то можно использовать фичу вьюхи под названием Default. Например:

Есть документ организации. Есть документ подразделения. Есть документ сотрудника. Документы связаны между собой только присутвием поля ParentUNID (связи отец-сын нету).

Тогда во вьюхе, в отборе пишите такое

Default $Ref:=ParentUNID;
а дальше что там у вас в формуле отбора было...
Вьюхе говорите отображать в виде иерархии...

Только нужно учесть, что ParentUNID должен хранить значение запписанное не LS, а собакой и без @Text. тобишь значение должно быть реальным унидом, а не его тектовым эквивалентом...
Боюсь, что такой способ тоже не пойдет. Или я может, быть чего-то не допонял, ибо опыта мало.
Некоторые организации тоже являются не первыми в иерархии (такое представление у меня работает):
--Группа Компаний+
.................................|--Департамент1+
.................................|.............................|--Организация1+
.................................|.............................|................
...........|-Отдел1+(сотрудники)
.................................|.............................|
.................................|.............................|--Организация2+(сотрудники)
.................................|
.................................|--Департамент2+
.................................|.............................|--Организация3+(сотрудники)
.................................|--Организация3(Управляющая компания)+(сотрудники)
А надо чтобы, отображался список организаций, а под каждой организацией список ее сотрудников, причем без отделов, ибо в БД занесены куча отделов и более 200 человек и иерархия выглядит страшно :(.
Данные по виду организации хранятся в базе словарей (ООО, ОАО, ЗАО и пр.), по этим данным из структуры ГруппыКомпаний выбираются именно организации (в форме этот алгоритм я реализовал).
Но как это сделать в представлении? Можно ли для этих целей использовать глобальные переменные?
 
S

Sandr

#6
В документе сотрудника есть есть признак, к какой организации он принадлежит?
Если да, то сделайте вьюху, в которой будут отображаться только сотрудники (уберите галку иерархии если они респонсы), первую колонку групируйте по названию организации.. И все...

Для: fedotxxl

Это что, военная тайна?
 
J

John_V

#7
В документе сотрудника есть есть признак, к какой организации он принадлежит?
Если да, то сделайте вьюху, в которой будут отображаться только сотрудники (уберите галку иерархии если они респонсы), первую колонку групируйте по названию организации.. И все...
В документе сотрудника есть признак, к какому подразделению он относиться, а не именно к организации, он может быть в отделе, в бюро, и непосредственно в организации.
В документе сотрудника также есть поле в котором перечислены все идентификаторы вышестоящих подразделений, но нет названий этих подразделений.
Сейчас я временно сделал вьюху, какую мне надо, но там выборка типо
@If(ПОЛЕсИДЕНТИФИКАТОРАМИ = "Идентиф.организации1"; "ООО \"Орг1\"";
ПОЛЕсИДЕНТИФИКАТОРАМИ = "Идентиф.организации2"; "ОАО \"Орг2\"";
и так далее)
Но если в структуру добавиться новая организация, то опять придется править представление, а это не гут.
А надо чтобы этот запрос на выборку формировался автоматом каждый раз.

Проблема как раз в том как сформировать первую колонку по организации.
Так... первую колонку по организации? Щас попробую...

Это не вышло, проблему решил через создание агента, который в документы пользователей вставил поле с название организации :rolleyes:
 
K

K-Fire

#8
Суть как ваша вьюшка должна быть организована, все эти связи Организация->Депарамент->Сотрудник и т.п. вряд ли кто-то объяснит, т.к. вьехать в конкретный бизнес-смысл по паре сообщений сложно.
Но вот объяснить как такое представление может быть организовано, можно.
Есть 2 способа:

1) Иерархическая вьюшка, в которой документы связаны по UNID-ам. Либо по полю $Ref, либо по любому другому, но с использованием DEFAULT $REF.

2) Категоризованная вьюшка, где поле использумое для категоризации имеет вид: Значение1\Значение2\...\Значение X. Тогда каждое такое значение будет показываться как отдельная строка.

В первом случае вам надо будет в нужном документе где прописывается значение из справочника, прописать (например на PostSave) юниды документа справочника. Т.е. есть док сотрудника, выбираете там в поле значение департамента. Значит в сотруднике должно быть поле хранящее юнид департамента.

Во втором случае работает агент, который в каждый документ который должен быть в этой вьюхе вычислит и запишет значение "Группа Компаний Альфа\Департамент 1\Организация Ч".
 
J

John_V

#9
Суть как ваша вьюшка должна быть организована, все эти связи Организация->Депарамент->Сотрудник и т.п. вряд ли кто-то объяснит, т.к. вьехать в конкретный бизнес-смысл по паре сообщений сложно.
Но вот объяснить как такое представление может быть организовано, можно.
Есть 2 способа:

1) Иерархическая вьюшка, в которой документы связаны по UNID-ам. Либо по полю $Ref, либо по любому другому, но с использованием DEFAULT $REF.

2) Категоризованная вьюшка, где поле использумое для категоризации имеет вид: Значение1\Значение2\...\Значение X. Тогда каждое такое значение будет показываться как отдельная строка.

В первом случае вам надо будет в нужном документе где прописывается значение из справочника, прописать (например на PostSave) юниды документа справочника. Т.е. есть док сотрудника, выбираете там в поле значение департамента. Значит в сотруднике должно быть поле хранящее юнид департамента.

Во втором случае работает агент, который в каждый документ который должен быть в этой вьюхе вычислит и запишет значение "Группа Компаний Альфа\Департамент 1\Организация Ч".
Проблему решил через создание агента, который в документы пользователей вставляет поле с название организации ;)
Кроме как посоветовал K-Fire ее видимо не решить.

Всем огромное спасибо за участие!
 
Статус
Закрыто для дальнейших ответов.