gifts2017

Контроль рабочего времени - синхронизация СКУД LYRIX с базами 1С ЗУП

Опубликовал Юрий П (nano1c) в раздел Программирование - Практика программирования

Часто бывает необходимо анализировать не просто данные с считывателей карт прохода в офис, но анализировать в режиме сопоставления с кадровыми данными 1с ЗУП. Актуальна также задача учета причин отсутствия и их визирования начальниками отделов. Существует простое решение на веб-клиенте 1с, с помощью объекта ВнешниеИсточникиДанных. Однако оно не обладает гибкостью - под каждые новые базы нужна перенастройка. По представленному описанию решение может быть легко воспроизведено для любых источников данных.

Редко в каких организациях существует решение, синхронизирующее данные системы контроля и управления доступом (СКУД) с кадровыми данными. Между тем, в 1с существует объект, позволяющий легко подключаться к разным источникам данных и, таким образом, легко создавать любые синхронизированные решения. Это ВнешниеИсточникиДанных - по сути, облегчающий написание прямых запросов. В описываемой реализации синхронизовались СКУД LYRIX и две 1с базы ЗУП. И плюс, и минус в том, что он работает напрямую с такими источниками, как SQL Server. Плюс, конечно же, в огромной скрости работы - сама БД Lyrix работает на порядок медленнее, и в ней крайне сложно собирать статистику. Минус в том, что имена полей и таблиц в базах 1с зашифрованы (в каждой базе они разные). Но в объекте ВнешниеИсточникиДанных их можно переименовать, для удобства:

рис1

Представляемое решение показало свою стабильность, удобство и автономность - бизнес-процесс замыкается на ответсвенных и работает "сам по себе" с авто-синхронизацией новых сотрудников, удалением уволенных и т.п. Как уже отмечалось, глубокая адаптация под новый холдинг неизбежна: помимо перенастройки объектов ВнешниеИсточникиДанных, требуются специфические фильтры считывателей карт, требуется переписывание алгоритма учета обедов и/или времени отсутствия в течение рабочего дня (у каждого холдинга своя специфика). Однако, универсальный подход к проблеме автоматического контроля отработанного времени можно фиксировать как решение в области дизайна, дружественного к пользователям. Самым простым и удобным здесь будет использование веб-клиента 1с, ибо каждому сотруднику необходимо видеть свое отработанное время и вносить комментарии к своим опозданиям и отсутствиям. Необходима также возможность распечатки табеля отработанного времени. Итак, страница обычного сотрудника имеет вид:

 рис2

 Сотрудник открывает ссылку в браузере, заходит по вин-аутентификации в базу и видит отчет с отбором (который нельзя изменить).  В зеленые поля можно вносить комментарий о недоработке. Второй отчет пользователя - ТабельОтработанного времени, который распечатывается, подписывается и сдается в кадры:

рис3

Норма вычисляется автоматически - дни отпуска не учитываются. Вид табеля переключается автоматически - для аванса период автоматически устанавливается за первую половину месяца.

Начальники Организаций или структурных единиц (например рецепшн, состоящий из сотрудниц разных Организаций), должны видеть из браузера данные с отбором по Организации или их списку:

рис4

Здесь также можно вносить комментарии - сотрудник, не пришедший на работу, звонит начальнику и объясняет причину отстутствия, а начальник ее вносит в базу. Цветами подсвечиваются выполнение нормы (бирюзовый недельная норма и белый дневная) и не выполнение (красный). У руководителя доступен уже почти полный спектр отчетов, о которых будет написано ниже.

Администратору доступны все отчеты и объекты управления БД. У него начальная страница открывается с отчетом ОтработанноеВремя без отбора:

рис1

 Работа через браузер наиболее хорошо подходит для задачи сотрудников по внесению комментариев, но необходимо заметить, что, например, прокрутка в некоторых версиях браузера может работать нестабильно. Другой негативный момент - расходование лицензий 1с. Поэтому, когда не требуется обратной связи в виде ввода комментариев и нет надобности в оперативности, наиболее правильно делать рассылку автоматически сформированных отчетов на почту ключевым участникам контроля. Отчеты формируются по таймеру из серверных процедур модуля объекта и форматируются в html и xls. Из последних форматов составляются письма и рассылаются Начальникам (Огранизаций или структ. единиц) и контрольным сотрудникам. В представленной реализации список писем выглядит следующим образом:

 рис6

 Как видно из рисунка, в понедельник контролирующему сотруднику приходит одно еженедельное письмо с результатом отчета ТабельРуководителей - он ведется по особому списку сотрудников (как правило, Начальников, но туда может быть помещен произвольный сотрудник (например, с большой зарплатой)). Второй вид писем - результат отчета КонтрольОпозданий, рассылается Начальникам с данными именно по их сотрудникам. Тела писем выглядят так же, как и, собственно, сами эти отчеты, и если нет необходимости в оперативности, смотреть их через почту комфортней. Вот еженедельное письмо:

рис7

А вот ежедневное  письмо Начальнику двух Организаций:

рис8

 Цветовые сигнализаторы здесь настроены на время прихода 10.00. Как можно видеть, Начальники и КонтрольноеЛицо получают исчерпывающую информацию о каждом сотруднике холдинговой структуры.

Поскольку представленное решение требует глубокой настройки на конкретный холдинг, то конфигурацию 1с не выкладываю. Опытный программист может легко воспроизвести ее "с нуля" за некоторое время по представленному описанию. Если нужны детали реализации - обращайтесь.

 

 

См. также

Подписаться Добавить вознаграждение

Комментарии

1. VVV (V_V_V) 16.12.14 11:39
Статья "для похвастаться"? Радченко в зубы - а ну-ка повтори! Так что ли? :)
djon10000; +1 Ответить
2. Софья (SuperSonyc) 17.12.14 07:59
отсутствие сотрудника по причине отпуска, служебной командировки - табелируется автоматически при наличии соответствующих кадровых документов в ЗуП или все равно необходимо писать комментарий?
3. Александр Макаров (DarLord) 17.12.14 09:42
В любом случае, возможность синхронизации актуальна только в том случае, когда все отделы компании имеют проходные (ну или точки пропуска). У нас, например, отдел кадров, учебный центр... не имеют проходных, т.е. синхронизация в принципе невозможна. Есть еще варианты, когда от одной проходной до другой идти более 30 минут...
4. Юрий П (nano1c) 17.12.14 12:22
(2) SuperSonyc, в моей реализации отпуска автоматически учитываются, НО: в реальности кадры не всегда заводят отпуск ДО отпуска. Часто бывает так что человек не вышел а потом звонит и говорит что у него отпуск за свой счет. Думаю с командировками -тоже самое будет. Так что у меня автомат то есть, но его надо корректировать вручную в случае неверной хронологии - сотр. или его начальник в браузере забивают слово "отпуск" - а алгоритм именно на это слово и реагирует, при вычислении нормы. Отмечу тут еще тот факт, что в ЗУП ужасно спроектированы регистры - любые вытаскивания данных это жуть, для тех, конечно, кто мало знаком со структурой ЗУПа.
5. Юрий П (nano1c) 17.12.14 12:34
(3) DarLord, тут все зависит от структуры БЦ. У нас, например, система считывателей общая и принадлежит упр.комп. УК может предоставлять данные арендаторам - там у меня, если заметили, отчет такой есть. То есть теоретически ничего не стоит подключить к этой системе любого арендатора, НО: как брать его кадровые данные? Конечно можно их и не брать - как правило арендатор не такой большой и ему будет достаточно иметь неотфильтрованные данные - там будут и всякие гостевые пропуска и т.п. По сути возможно все - можно наладить любой вариант, в том числе и с полноценным обменом. Отмечу тут важное обстоятельство: чтобы УК предоставляла такого рода услуги в вебе другим компаниям (причем не важно арендаторам или своим!) - она должна иметь статус партнера 1с. Есть вариант, и совсем простой: рассылка арендаторам, но тут теряется обратная связь в виде ввода комментариев...
6. Софья (SuperSonyc) 17.12.14 13:48
(4) nano1c, то есть, если начальник поставил отпуск, но кадры его не ввели, в табель все равно упадет отпуск? а как с больничными? они вообще вводятся только после того, как сотрудник его принес. Актуализации месяца по введенным данным нет?
7. Юрий П (nano1c) 17.12.14 13:59
(6) SuperSonyc, можно по-разному настроить, но из опыта я выработал такой оптимум:
1) приоритет за ручным комментарием - если он <>"" то ЗУП его не забивает
2) перезагрузка периода автоматом не делается - только администратором в спец.обратке, то есть тут надо понимать что делаеш. например бывают случаи смены фамилии, но надо чтобы табеля при этом корректно отображались, как быть? Очень просто: меняем фамилии с понедельника, а еще лучше - с 1го числа. После смены регистра синхронизации, понятное дело, надо перегрузить период. Есть более экзотические ситуации, требующие перегрузки периода...
3) Загрузка данных идет оперативно кусками (постоянно каждые Х минут), но в течение дня кадровые данные перекрываются - если ввели отпуск вечером то он изменит комментарий, если, до этого, его не ввели вручную.
4) С больничными сложнее - как правило "все в ручную".
8. юрий гулидов (gull22) 17.12.14 15:10
Интересное было почитать для расширения кругозора.
9. Антон Лосев (shootnik) 17.12.14 23:01
Писал что-то подобное, подскажите у Вас как-то решаются след. вопросы:

1. Работа в третью смену (когда начало смены приходитс на одни сутки, а конец на другие)
2. Как рассчитывается время обеда если сотрудник обедал не выходя за территорию (в заводской столовой), а после этого ушел с работы на час раньше. Вычитается ли в этом случае какое-то нормативное время обеда?
3. Обрабатыаются ли нестыковки, когда например количество входов не равно количеству выходов (сотрудник выехал с территории на служебном автомобиле, что не зафиксировано СКУД)?
10. Юрий П (nano1c) 22.12.14 01:11
(9) shootnik, основной плюс этой базы - в синхронизации с ЗУП, оттуда, в том числе, берется и производственный календарь. То есть система узнает о рабочих и праздничных днях. Когда у нас встала задача учитывать работу на выходных, я принял решение учитывать это на другом регистре. То есть в основной регистр попадают только дни из календаря ЗУП, а во второй - остальные. Ну а ваша задача - еще сложнее и я бы сделал ее также на другом регистре сведений. Если не обедал - не имееш права уходить на час раньше, у нас так, и, наверное, почти везде так. Нестыковок вроде описаной вами у нас нет: общее время берется как разность между первым и последним засветом карты (считыватели вне территории бизнес-парка не учитываются, если они есть). Алгоритм обеда сложнее и тут есть варианты, но это все должно согласовываться с руководством и любые варианты реализуемы.

Я еще не описал механизм автоматического создания пользователя БД - из AD, но механизм этот описан в другой публикации Инфостарта - тут ничего сложного не было.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа