29 Февраль 2012 
Андрей Суров Регистрация нового сотрудника в системе не так уж и тривиальна, как того хотелось бы. Когда разрабатывалась такая сложная и громоздкая процедура регистрации, имели место быть благие намерения обеспечить гибкость. Ну а куда такие намерения ведут — известно уже не первое тысячелетие.
Сразу наведу еще жути, а потом перейдем к конструктиву. Если вы хотите зарегистрировать нового сотрудника в системе, готовьтесь к тому, что вам придется заполнить четыре справочника (!), не считая дерева структуры (!!). Дальше о порядке этого заполнения и о том, зачем же все таки понадобилось все это.
Как это устроено
Структура — это, фактически, голое, но иерархическое дерево. Его ветви заканчиваются точками, выделенными на рисунке. Различаются два вида точек: узловые (от которых растут новые ветви) и конечные (от которых уже ничего не растет). Узловые точки — это структурные подразделения организации, а конечные — должностные единицы.
Вот как это выглядит на практике:
Полужирными начертаниями выделены узловые точки, все остальное — конечные.
Узловые точки связаны отношением «один к одному» со справочником Подразделения. Т.е. одно подразделение из этого справочника может находиться в Структуре единожды.
С конечными точками дела обстоят сложнее. Они связаны со справочником Должности (связь «один к одному»), который в свою очередь связан («один ко многим») со справочником Сотрудники, а тот со справочником Пользователи («один к одному»).
Что это дает
- За исключением дерева Структуры все строится на обыкновенных справочниках, что позволяет администратору без проблем расширить модель под конкретные нужды (к примеру, добавить новые поля в справочники Подразделения, Должности, Сотрудники, Пользователи).
- На основании п.1 следует вывод, что администратору, изучившему справочники системы, не нужно осваивать ничего нового. Преимущество несколько сомнительное, но для более внушительного количества достоинств вполне сгодится.
- Можно гибко управлять правами доступа. Например, в справочнике Сотрудники хранятся персональные данные, поэтому доступ к нему должен быть жестко регламентирован. А в справочнике Пользователи хранятся данные, которыми должны управлять ИТ-администраторы (логины, пароли, серверы).
- Модель обеспечивает возможность занятия одним сотрудником нескольких должностей, благодаря связи «один ко многим» между справочниками Должности и Сотрудники. Благодаря ей же, легко реализуется механизм замещающих.
Как это заполнять
Можно начать заполнение со справочника Пользователи. Создав новую запись, достаточно ввести имя пользователя, пароль и вызвать мини-представление справочника Сотрудники, нажав соответствующую кнопочку. В открывшемся окне мини-представления нащупать плюсик аккурат под кнопкой Найти. В открывшейся новой вкладке справочника Сотрудника ввести Отображаемое имя и закрыть вкладку. В мини-представлении нажать на пиктограмму, символизирующую обновление (рядом с плюсиком) и выбрать введенного сотрудника. Далее отправиться в справочники Должности, создать новую запись, ввести название должности и выбрать нашего сотрудника. Последний штрих — добавить созданную должностную единицу в соответствующее подразделение Структуры через контекстное меню этого подразделения.
Ввод подразделений выполняется много проще: заполняется справочник Подразделения, а затем выстраивается иерархия в Структуре при помощи того же контекстного меню.
Рубрика: 
Метки:
Андрей, у меня такой вопрос. По какой причине отношение справочника «Сотрудник» и «Должность» строится как один к одному. К примеру в организации несколько департаментов, но при этом должность будет именоваться как Директор департамента — т.е. именование должности единое, понятно, что 2-х директоров в одном департаменте быть не может, но мне кажется что это должно разделяться на уровне справочника подразделений. Так же и внутри самого подразделения может быть несколько одинаковых должностей (к примеру 3 менеджера, направления разные но именуются должности одинаково). Просто считаю не совсем логичным появление в справочнике должности записей аналогичных количеству сотрудники, в таком случае должность должна бы была отойти в справочник «Сотрудники». Или же я не прав?!
Если избавиться от справочника Должности, т.е. привести цепочку Структура — Должности — Сотрудники — Пользователи к виду Структура — Сотрудник — Пользователи (свести Должности на уровень простого классификатора), то возникнут следующие вопросы:
1. Представьте, есть сотрудник Иванов. Он занимает две должности: инженер и дворник (у нас и не такое случается). Для описания сотрудника нужно будет добавить в справочник Сотрудники поле Должности, в котором будут выбраны инженер и дворник. А теперь нужно будет одну запись справочника Сотрудники (Иванов) связать с несколькими точками Структуры, причем, для каждой точки нужно указать соответствие должности. Существующая модель справочников, на которой базируется весь механизм пользователей-сотрудников, такое не поддерживает.
Можно, конечно, подойти было бы подойти к вопросу с другой стороны и навесить классификатор должностей на Структуру, а не на Сотрудников. Но в свое время сделали структуру в виде «голого» дерева для того, чтобы использовать это дерево в других местах системы. Потому и не стали нагружать дополнительными «названиями точек», т.е. должностями.
2. Если Вы обратили внимание, то поле Структуры в режиме просмотра представляет собой гиперссылку, которая ведет на справочник Должности. А справочник Должности легко расширить, добавив такие параметры как, номер телефона, номер кабинета и т.д. И сделать этот справочник общедоступным. Т.е. любой сотрудник сможет получить информацию по рабочему телефону сослуживца, номеру его кабинета и т.д. А личная информация о сотруднике хранится в справочнике с ограниченным доступом под названием Сотрудники. Можно было бы, конечно, хранить персональные данные сотрудника и в справочнике Должности, но для этого бы потребовалась возможность регулирования прав доступа на уровне полей записи справочника, а такого функционала в системе нет.
3. Существующий механизм позволяет видеть вакантные позиции, облегчает ротацию кадров. В структуре можно навешать пустые должности в нужном количестве в соответствии со штатным расписанием организации. А ротация осуществляется просто изменением сотрудника в справочнике Должности и все документы, с которым работал предшественник автоматически перейдут к преемнику.
Спасибо, за исчерпывающий ответ. Понял, что просто необходимо сменить угол обзора проблемы и в принципе все стает на свои места.
Добрый день Андрей!
создал новую структуру — но пользователей пока не назначил…
теперь вхожу под админом — но корректировать справочники не дает — пишет что нет доступа — обратитесь к администратору…
структуру забил большую — не хотелось бы все переустанавливать
как зайти в систему с полными правами?
Вообще-то система не дает уничтожать учетную запись, под которой Вы заполняли структуру. Или Вы зашли под пользовательской учеткой, удалили админа, а теперь не можете работать от его имени? Уточните, пожалуйста.
Если я правильно понял, то я сталкивался с этим. Зайдите в Администрирование, справочники и выставите там права на изменение какого либо справочника ))
А можно поменять авторизацию или сделать чтобы регистрация была автоматической(данные о себе заполняют сами сотрудники), а администратор только подтверждает этого юзера и выставляет ему права доступа и т.д. С функцией «забыли пароль».
По умолчанию, такой возможности нет. Дописать несложно; можете самостоятельно или обращайтесь к нам, — просчитаем стоимость.
Ребят, всем привет! Посмотрел вашу разработку — впечатляет!!! Коль уж здесь задают вопросы по пользователям — то у меня вопрос: будет ли NTLM авторизация через домен и импорт пользователя из домена. Лично у меня там все данные на юзеров заполнены. Логин, пароль, ФИО, должность, подразделение, емаил, телефоны, аська.