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

[LuMee]

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

 

[Elena Nefedova]

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

 

[LuMee]

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

У меня это не имеет смысла, ибо организация одна.

 

[Elena Nefedova]

У меня это не имеет смысла, ибо организация одна.

У меня тоже одна. Но можно и две ввести, если потребуется. К тому же, где-то надо хранить реквизиты и прочее

 

[Axel]

<!--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]

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

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

 

[Guest]

не забудьте только в форме поле $refOptions

 

[Elena Nefedova]

не забудьте только в форме поле $refOptions

Облазила весь хелп - ничего про это поле не нашла.
Не расскажете ли поподробнее, раз уж зашла об этом речь?

 

[Guest]

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

 

[Veselinka]

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

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

 

[LuMee]

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

 

[GROMILA]

... при копировании документов в другую БД все эти связи нарушатся.

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

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

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

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

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

Но вопрос к Веселинке

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

А почему не REF и уточните пожалуста про альтернативное поле ????

 

[valmont]

Для: Veselinka

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

 

[LuMee]

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

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

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

 

[LuMee]

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

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

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

 

[Elena Nefedova]

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

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

$Ref - это возможножность, конечно, хорошая, и я часто пользуюсь; но при этом из группы документов можно построить единственное иерархическое дерево, что бывает маловато

 

[Constantin A Chervonenko]

$Ref - это возможножность, конечно, хорошая, и я часто пользуюсь; но при этом из группы документов можно построить единственное иерархическое дерево, что бывает маловато

$REF-ов можно сделать несколько! К сожалению, не получилось сделать multivalue ссылочное поле, но несколько ссылок, каждая в своем поле - программно создаются элементарно.
Для отображения деревьев во view потом используется конструкция DEFAULT $REF:=...

 

[Elena Nefedova]

$REF-ов можно сделать несколько! К сожалению, не получилось сделать multivalue ссылочное поле, но несколько ссылок, каждая в своем поле - программно создаются элементарно.
Для отображения деревьев во view потом используется конструкция DEFAULT $REF:=...

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

 

[LuMee]

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

Годятся только Reference-поля. Жалко, что они не пересчитываются при копировании только (Лотус следит только за $Ref).

 

[Constantin A Chervonenko]

Годятся только Reference-поля. Жалко, что они не пересчитываются при копировании только (Лотус следит только за $Ref).

Да, только правильные ссылки. Побочный эффект: "нормальный" $REF использовать нельзя (иначе DEFAULT смысл потеряет).
А если копировать док-ты с сохранением исходных UNID-ов, то все ссылки остаются живыми!

 

[LuMee]

А если копировать док-ты с сохранением исходных UNID-ов, то все ссылки остаются живыми!

Хм, а это как? А если в базе, куда копируем, такие юниды уже есть?