Описание оргструктуры предприятия

LuMee

Well-known member
02.05.2006
477
0
#1
Подскажите, плз, как лучше всего описать оргструктуру предприятия (у него есть отделы, у отделов - свои отделы, в отделах каждого уровня - люди). Сначала думал обойтись двумя документами: один описывает Отдел, другой - Сотрудника, оба response-to-response. Предполагается, что документы, описывающие подчиненные Отделы, будут ответами на соотв. вышестоящие Отделы, ну а Сотрудники - просто ответы на свои отделы. Однако тут не придумалось, как быть с отделами самого выского уровня, которые ни с чем уже не связаны (соотв-но, не могут быть ответами).
Думал тогда ввести еще один документ, описывающий такой Отдел верхнего уровня, но показалось, что это будет уже слишком запутанно.
Наконец, была мысль вообще сделать документ-Отдел не ответным, а потом эти документы уже программно (с помощью NotesDocument.MakeResponse()) связывать друг с другом, что, впрочем, еще более запутанно.
Расскажите, как обычно это делается?
 
E

Elena Nefedova

#2
Не знаю, как обычно, а у нас документы верхнего уровня - это организации
 
A

Axel

#5
<!--QuoteBegin-Elena Nefedova+10:07:2006, 11:43 -->
<span class="vbquote">(Elena Nefedova @ 10:07:2006, 11:43 )</span><!--QuoteEBegin-->У меня тоже одна. Но можно и две ввести, если потребуется. К тому же, где-то надо хранить реквизиты и прочее
[snapback]39788" rel="nofollow" target="_blank[/snapback]​
[/quote]

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

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

Guest

#8
$refOptions забивает свойство формы Type и позволяет сохранять респонсные документы по форме с тайп Document и наоборот
Разместите cwd-поле $refOptions с формулой @If(@IsResponseDoc; "1"; "0")
в форме документа Подразделения (только не в подформе) - иначе при интерфейсном сохранении ответные документы станут главными (если тип формы - Document) или нотес будет ругаться при сохранении главных документов (если тип формы - Response)
 
V

Veselinka

#9
Модель построения оргструктуры следующая:
1. сущность подразделение. Технологически строится как иерархия документов по альтернативному полю (не $REF)
2. сущность должность - сылается на подразделение (так же альтернативным полем)
3. сущность Сотрудник - назначается на должность, может совмещать несколько должностей.
4. Полномочия, компетенции и пр - является атрибутами должности.
5. Личные данные, резюме, выданные в подотчет матценности, курсы и тренинги пройденные и пр - является атрибутами сотрудника.

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

LuMee

Well-known member
02.05.2006
477
0
#10
Неужто стандартные методы Lotus, т.е. ответы, так ограничивают?
И потом, если строить связи на основе reference-полей (чтобы иметь возможность строить иерархии во вью на основании этих связей), то при копировании документов в другую БД все эти связи нарушатся.
Если же просто использовать текстовые поля с некими уникальными значениями, то эти связи не отразишь во вью, да и находить связанные документы будет небыстро.
 

GROMILA

Well-known member
08.04.2004
297
0
#11
... при копировании документов в другую БД все эти связи нарушатся.
Я извиняюсь, но задам Вам вопрос в стиле лотус-программистов B)
А ЗАЧЕМ ВАМ КОПИРОВАТЬ ДОКУМЕТЫ В ДРУГУЮ БАЗУ ???????

и отвечу в стиле лотус-программистов :)
НЕ КОПИРУЙТЕ :D))))

(да простят меня лотусисты, но критика не помешает)

Структура предприятия является справочником общего пользования и должна быть ОДНА на всю систему и даже на несколько систем, если речь идет о корпорации!!!

По поводу построения БД
Веселинка правильно рассказала про сущности, добавить нечего.
Замени слово СУЩНОСТЬ на слово ФОРМА и усе будзе добра.

Но вопрос к Веселинке
Технологически строится как иерархия документов по альтернативному полю (не $REF)
А почему не REF и уточните пожалуста про альтернативное поле ????
 

valmont

Well-known member
27.12.2004
64
0
#12
Для: Veselinka

поподрбобнее можно с моделью и желательно на примерах...
 

LuMee

Well-known member
02.05.2006
477
0
#13
Я извиняюсь, но задам Вам вопрос в стиле лотус-программистов :)
А ЗАЧЕМ ВАМ КОПИРОВАТЬ ДОКУМЕТЫ В ДРУГУЮ БАЗУ ???????

и отвечу в стиле лотус-программистов ;)
НЕ КОПИРУЙТЕ :)))))
Ну со структурой организации понятно - одна на всех. А вот в других ситуациях копирование вполне может занадобиться, и тут с альтернативными полями придется изрядно помучиться.
 

LuMee

Well-known member
02.05.2006
477
0
#14
Я извиняюсь, но задам Вам вопрос в стиле лотус-программистов :)
А ЗАЧЕМ ВАМ КОПИРОВАТЬ ДОКУМЕТЫ В ДРУГУЮ БАЗУ ???????

и отвечу в стиле лотус-программистов ;)
НЕ КОПИРУЙТЕ :)))))
Ну со структурой организации понятно - одна на всех. А вот в других ситуациях копирование вполне может занадобиться, и тут с альтернативными полями придется изрядно помучиться.
 
E

Elena Nefedova

#15
Если же просто использовать текстовые поля с некими уникальными значениями, то эти связи не отразишь во вью, да и находить связанные документы будет небыстро.
Еще как отразишь - нужно просто использовать правильную иерархию ключей в поле.
Например, "ЗАО Фреска\Отдел кадров" в категоризированной колонке отображается соответствующим образом.

$Ref - это возможножность, конечно, хорошая, и я часто пользуюсь; но при этом из группы документов можно построить единственное иерархическое дерево, что бывает маловато
 
30.05.2006
1 345
11
#16
$Ref - это возможножность, конечно, хорошая, и я часто пользуюсь; но при этом из группы документов можно построить единственное иерархическое дерево, что бывает маловато
$REF-ов можно сделать несколько! К сожалению, не получилось сделать multivalue ссылочное поле, но несколько ссылок, каждая в своем поле - программно создаются элементарно.
Для отображения деревьев во view потом используется конструкция DEFAULT $REF:=...
 
E

Elena Nefedova

#17
$REF-ов можно сделать несколько! К сожалению, не получилось сделать multivalue ссылочное поле, но несколько ссылок, каждая в своем поле - программно создаются элементарно.
Для отображения деревьев во view потом используется конструкция DEFAULT $REF:=...
А как вы многие $Ref'ы создаете?
У меня в свое время получилось только при помощи копирования имеющихся полей $Ref под другими именами: notesItem.CopyItemToDocument( document, newName$ )
Ну я и решила, что это, наверное, кривизна, и лотусом корректно не поддерживается. И бросила это дело.
Скажите, для DEFAULT $REF=.. обязательно использовать поля типа Response или можно текстовые?
 

LuMee

Well-known member
02.05.2006
477
0
#18
А как вы многие $Ref'ы создаете?
У меня в свое время получилось только при помощи копирования имеющихся полей $Ref под другими именами: notesItem.CopyItemToDocument( document, newName$ )
Ну я и решила, что это, наверное, кривизна, и лотусом корректно не поддерживается. И бросила это дело.
Скажите, для DEFAULT $REF=.. обязательно использовать поля типа Response или можно текстовые?
Годятся только Reference-поля. Жалко, что они не пересчитываются при копировании только (Лотус следит только за $Ref).
 
30.05.2006
1 345
11
#19
Годятся только Reference-поля. Жалко, что они не пересчитываются при копировании только (Лотус следит только за $Ref).
Да, только правильные ссылки. Побочный эффект: "нормальный" $REF использовать нельзя (иначе DEFAULT смысл потеряет).
А если копировать док-ты с сохранением исходных UNID-ов, то все ссылки остаются живыми!