Бизнес требования для реализации подсистемы «Кадры

advertisement
Приложение №1
Функциональные требования к модулю «Кадры.
Заработная плата».
Документ содержит минимальные требования к функциональности подсистемы и структуре данных.
Документ описывает основные требования к процедурам, функциям, документообороту и информационным потокам подсистемы «Кадры. Заработная плата», которая предназначена для решения следующих задач:
1. Ведение информации по вакансиям, подбору персонала
- массив «Вакансии». Будет отличаться от вакансий для массива «Штатное
расписание»
- массив «Кандидаты»
- массив «Подбор и отбор»
Массив «Вакансии».
По вакансии указываются следующие свойства:
- должность (справочник)
- подразделение (справочник)
- тип вакансии (справочник)
- требования должности по вакансии (текст)
- условия найма (несколько полей, часть из которых будет добавляться из
справочника, часть добавляться в виде текста)
- дата открытия
- дата закрытия.
Должна быть возможность добавлять поля.
Необходима возможность ведения плана вакансий. Должно быть предусмотрено ведение мероприятий по вакансии:
- активирование плановой вакансии
- введение новой вакансии (для внеплановых)
- приостановка/заморозка вакансии
- закрытие вакансии.
По каждому мероприятию – дата его осуществления с хранением истории
Массив «Кандидаты».
Должна повторять карточку работника, но с другими требованием по обязательности полей
У каждого кандидата должно быть несколько статусов(из справочника):
Должна быть возможность интеграции с внешним сайтом, для импорта
данные из анкет, заполненных на сайте.
Массив «Подбор и отбор»
Производится сопоставление данных кандидатов и вакансий в виде мероприятий(из справочника). По каждому мероприятию должна проставляться
дата мероприятия и присваиваться дальнейшее мероприятие, конечным из
которых будет передача на оформление.
2. Ведение информации по работникам
Личная карточка – заводится при приеме на работу. Обязательно наличие
возможности выбора работника из списка кандидатов.
Наличие обязательных для заполнения полей без которых невозможно сохранить данные.
Мероприятия по карточке:
1) Добавление новой карточки
2) Внесение изменений в карточку
3) Отправить в архив (по уволенным работникам)
В карточке должна содержаться информация:
- табельный номер;
- персональные данные работника (ФИО, паспортные данные, пол и т.д.
для каждого отдельное поле);
- образование и дополнительное обучение;
- опыт работы (подробно с указанием организаций, дат, отрасли и т.д.);
- награды, звания, поощрения;
- должность, подразделение (из штатного расписания), дата назначения на
должность;
- информация о детях и ближайших родственниках;
Должна быть возможность создавать дополнительные поля в системе.
По персональным данным работника должна быть возможность указания
ФИО в разных падежах.
По признакам, которые изменяются (ФИО, паспортные данные, должность, подразделение, дата назначения на должность, обучение, опыт и т.д.) –
должна храниться вся история изменений и быть доступной для отчетов.
В системе необходимо предусмотреть возможность отслеживания стажа
работников, наступление определенных дат, пенсионного возраста.
В системе должна быть предусмотрена возможность экспорта всех данных.
3. Ведение штатного расписания
В системе должна быть возможность совершать следующие мероприятия:
–
просмотр списка штатных единиц;
–
просмотр истории штатной единицы;
–
создание штатной единицы;
–
изменение штатной единицы;
–
передача штатной единицы другому подразделению;
–
упразднение штатной единицы.
Массив «Штатные единицы»
На одной штатной должности может работать несколько работников, но
при этом на только один может быть активным, у остальных должен быть
признак нахождение в декретном отпуске, отпуске, на больничном.
При введении штатной единицы должны быть следующие поля
–
подразделение (справочник);
–
должность (справочник);
–
категория (справочник);
–
признак руководителя самостоятельного подразделения;
–
характер работы (справочник);
–
направление деятельности (справочник);
–
дата создания;
–
дата упразднения;
–
разряд (из справочника) разряду – будет соответствовать
тарифный коэффициент;
–
тарифный оклад/тарифная ставка;
–
дата введения штатной единицы;
–
порядок сортировки.
Должна быть возможность добавления полей с признаками. Значения поля с дополнительными признаками могут выбираться из справочника или задаваться в произвольной форме (по выбору пользователя)
Часть полей обязательная для заполнения. Должна храниться история изменений за все время ведения данных.
Расчет тарифного оклада должен производиться на основании ставки 1
разряда, заложенного в системе и тарифного коэффициента
Массив «Штатное расписание»
Штатные единицы должны сопоставляться с действующими работниками
или должно быть указано, что должность вакантна (не равна вакансии для
целей подбора).
По вакантным должностям должно автоматически производиться напоминание по истечении периода (устанавливается пользователем) о необходимости подачи сведений в центр занятости и формироваться отчет
В массив должны входить данные из массива «Штатные единицы» и следующая информация:
–
повышения тарифного оклада (несколько полей);
–
вид повышения тарифного оклада (из справочника);
–
должностной оклад/ставка;
–
надбавки к должностному окладу (несколько полей);
–
вид надбавки к должностному окладу (из справочника);
–
размер базовой премии;
–
вид мероприятия в соответствии с которым данный работник сопоставлен данной должности (из справочника);
–
данные работника, работающего на данной должности
(возможен случай работы на 1 должности нескольких работников –
описано ниже);
–
дата утверждения должностных обязанностей;
–
текст должностных обязанностей (поле);
–
грейд должности (справочник);
–
комментарий.
По каждому повышению тарифного оклада, надбавке, базовой премии
должна вестись дата установления текущего размера и история изменений и
доступна для отчетов.
Должна быть возможность добавлять поля.
Одной штатной должности может соответствовать несколько работников,
но при этом на только один может быть активным, у остальных должен быть
признак нахождения в декретном отпуске, отпуске, на больничном.
Если штатной должности будет соответствовать несколько работников, то
у одного работника должен быть статус, что он является основным работником. По умолчанию основной работник – тот, кто первым (по времени) закреплен за данной должностью.
При изменении штатной единицы должен готовиться проект изменений в
штатное расписание. Пользователь должен сам выбирать список должностей,
мероприятия, по которым вносятся в данное изменение.
Перечень изменений должен храниться за всю историю ведения данных.
На базе массива «Штатное расписание» должны выгружаться различные
варианты отчетов (настраиваемых пользователям, позволяющие включать
или не включать в него данные в зависимости от параметров заведенных в
системе).
Изменение в массиве «Штатное расписание» должен готовиться проект
приказа (об установлении должностного оклада, надбавки и т.д.). Изменения,
которые включаются в конкретный приказ должны выбираться пользователем.
4. Учет информации по отпускам работников
В подсистеме должна быть реализована возможность учета отпусков работников.
Для учета отпусков работников должно быть предусмотрено заполнение
следующих массивов данных:
–
график отпусков;
–
отпуска основной и дополнительные (несколько видов –
виды из справочника, для каждого вида – отдельное поле);
–
прочие отпуска.
Для работы с массивом должны быть предусмотрены следующие поля для
заполнения:
–
вид отпуска (выбор из справочника);
–
дата начала отпуска;
–
дата окончания отпуска;
–
количество дней отпуска (по видам, вид отпуска – справочник, каждый вид – в отдельном поле);
–
дата начала периода, за который предоставляется отпуск;
–
дата окончания периода, за который предоставляется отпуск;
–
примечание.
Должна быть предусмотрена возможность пересчета количества дней отпуска в зависимости от даты начала отпуска и даты окончания отпуска.
Если размер, каких-либо определенных работнику видов отпуска изменяется в течение рабочего года – система должна позволять автоматически пересчитывать фактически положенное количество дней отпуска
Массив «Отпуска» предназначен для хранения информации об отпусках
работника. Должен быть разработан механизм, позволяющий добавлять (изменять) информацию в массив. Для работы с массивом должны быть предусмотрены следующие поля для заполнения:
–
вид отпуска (выбор из справочника);
–
дата начала отпуска;
–
дата окончания отпуска;
–
номер приказа;
–
дата приказа;
–
номер приказа об отмене отпуска (отзыва из отпуска);
–
дата приказа об отмене отпуска (отзыва из отпуска);
–
количество дней отпуска (по видам);
–
количество дней отпуска неиспользованного в связи с отзывом
–
вид предоставления неиспользованного в связи с отзывом
отпуска.
–
дата начала периода, за который предоставляется отпуск;
–
дата окончания периода, за который предоставляется отпуск;
–
примечание.
Должна быть предусмотрена возможность пересчета количества дней отпуска в зависимости от даты начала отпуска и даты окончания отпуска.
В системе обязателен учет дней, которые являются праздничными и не
включаются в продолжительность отпуска
Для трудового отпуска должно быть предусмотрено автоматическое изменение отпускного периода при наличии у данного работника определенного
количества дней отпуска без сохранения и/или отпуска по беременности и
родам, отпуска по уходу за ребенком.
Массив «Прочие отпуска» предназначен для хранения информации о дополнительных отпусках работника (без сохранения заработной платы и др).
Для каждого вида отпуска в справочнике должен быть предусмотрено максимальное количество дней отпуска и автоматически проводиться контроль.
Для работы с массивом должны быть предусмотрены следующие поля для
заполнения:
–
–
–
вид отпуска (выбор из справочника);
количество дней отпуска;
примечание.
Для основного и дополнительного отпуска должно быть предусмотрено
автоматическое изменение отпускного периода при наличии у данного работника определенного количества дней отпуска без сохранения и/или отпуска по беременности и родам, отпуска по уходу за ребенком.
Отчетность.
1.Количество дней неиспользованного отпуска на дату (в разрезе работников, подразделений, в целом по Банку) как за всю историю по массиву данных, так и за определенный период.
2.Отчет о наступлении отпуска по графику за произвольный период времени до начала (выбирается пользователем).
3. Напоминание о неиспользовании 14 дней отпуска в течение раб года за
произвольный период времени до окончание раб года (выбирается пользователем).
5. Учет командировок работников
В подсистеме должна быть реализована возможность учета командировок
работников.
Для учета командировок должны быть предусмотрены следующие поля
для заполнения:
–
страна (поле должно заполняться посредством выбора значения из справочника);
–
город (выбор из справочника);
–
цель командировки;
–
организация;
–
дата начала;
–
дата окончания;
–
основание (номер и дата приказа- для каждого отдельное
поле) ;
–
отмена командировки (номер и дата приказа).
Приказ должен формироваться на основе заполненных данных (кроме основания для приказа). При этом исполнитель сам выбирает какие записи
включаются в приказ. Командировочное удостоверение формируется на основании заполненных данных, по установленному заказчиком шаблону. После регистрации приказа в системе, система заполняет поля по дате и номеру
приказа (о направлении в командировку и отмене командировки)
В подсистеме должен быть реализован архив хранения информации по
командировкам работников за весь период работы в системе Банка.
Поле «Отмена командировки» должно быть обязательно заполнено в случае, если планируемая командировка была отменена приказом руководителя
подразделения. При этом информация об отмененной командировке может
не отображаться в отчетных формах (опция для выбора пользователя системы).
На базе массива «Учет командировок» должны выгружаться различные
варианты отчетов (настраиваемых пользователям, позволяющие включать
или не включать в него данные в зависимости от параметров, заведенных в
системе) либо предусмотрена возможность экспорта данных.
6. Учет рабочего времени
В подсистеме должна быть реализована возможность ведения учета рабочего времени, отработанного работником.
По умолчанию следует вести учет рабочего времени работника следующим образом:
–
длительность рабочего дня – 8 часов;
–
длительность предпраздничного рабочего дня – 7 часов;
–
длительность рабочей недели – 5 дней.
В календаре рабочих дней должна быть реализована возможность учета
праздничных и предпраздничных дней.
Должна быть предусмотрена возможность изменения параметров, установленных по умолчанию.
Для работников, график работы которых имеет специфические отличия от
условий, указанных выше, необходимо разработать механизм добавления
информации в массив «Учет рабочего времени».
Для внесения информации в массив «Учет рабочего времени» должно
быть предусмотрено наличие следующих полей для заполнения:
–
вид работы (выбор из справочника);
–
дата приказа;
–
номер приказа;
–
примечание;
–
дата начала;
–
дата окончания;
–
количество отработанных часов;
–
количество часов, отработанных в ночное время
–
Количество сверхурочных часов
Обязательными для заполнения являются следующие поля:
–
вид работы;
–
дата начала;
–
дата окончания;
–
количество отработанных часов;
–
количество часов, отработанных в ночное время.
В подсистеме должна быть реализована возможность учета временной нетрудоспособности работников.
Для учета нетрудоспособности должны быть предусмотрены следующие
поля для заполнения:
–
вид нетрудоспособности (выбирается из справочника);
–
документ о нетрудоспособности:

серия;

номер;

дата открытия;

дата закрытия;
–
дата регистрации.
В подсистеме должен быть реализован архив хранения информации по
учету временной нетрудоспособности работников за весь период работы в
системе Банка.
В подсистеме должна быть реализована возможность ведения информации по работе в выходные дни по работникам. Должно быть предусмотрено
наличие следующих полей для заполнения:
–
дата приказа;
–
номер приказа;
–
вид компенсации за работу в выходной день(справочник);
–
примечание.
В системе должна быть предусмотрена возможность контроля лимита отработанных выходных дней (часов) в год. При попытке ввести большее значение – система должна дать сообщение об ошибке.
На основании данных учета рабочего времени должна быть реализована
возможность подготовки статистических отчетов (среднесписочная численность и др.).
7.Ведение кадрового делопроизводства
При введении мероприятий по персоналу в систему (прием, перевод, перемещение, увольнение, продление контракта, предоставление, отпусков изменении параметров штатных единиц) должны автоматически создаваться
проекты приказов и трудовых договоров (контрактов).
В подсистеме должно быть предусмотрено несколько видов контрактов и
трудовых договоров (выбирается пользователем). Трудовые договора (контракты) готовятся на основе шаблонов, установленных заказчиком. Шаблоны
трудовых договоров (контрактов) могут быть изменены пользователем.
После подтверждения приказа, приказ должен регистрироваться в соответствующем электронном журнале регистрации приказов, а информация
должна заноситься в карточки соответствующих работников.
По приказам система должна позволять автоматически делать выписки по
утвержденным приказам, уведомления работников.
При внесении изменений в контракты по каждому работнику формируется
итоговый вариант трудового договора (контракта) с учетом изменений. История изменений в контракты должна быть доступна по каждому работнику.
Приказы должны готовиться на основе шаблонов, установленных заказчиком.
В подсистеме должна быть предусмотрена возможность ведения установленных заказчиком журналов регистрации, а также предусмотрена возможность экспорта журналов.
В системе должна быть реализована автоматическая рассылка по устанавливаемым пользователем адресам при наступлении определенных дат (окончание контракта, окончание испытательного срока, адаптационного периода
и пр.) за определенный период (выбирается пользователем).
По делам, веденным в системе (приказы, штатное расписание) должна автоматически вестись архивная опись дела, быть доступной для экспорта.
8.Расчет заработной платы и функции расчета заработной платы,
выплаты пособий, отпускных и т.д.
Модуль должен обеспечивать:
- проведение всех расчетных и учетных операций по расчетам с персоналом по оплате труда и социальным выплатам и льготам, по расчетам вознаграждений по гражданско-правовым договорам, расчетам с бюджетом и внебюджетными фондами в соответствии с правилами бухгалтерского учета,
требованиями трудового и налогового законодательства и внутренними положениями об оплате труда;
- возможность ручного ввода и сохранения начислений и удержаний на
случай, не предусмотренный программой (например, при изменении законодательства);
- возможность ручного ввода, корректировки и сохранения сумм, входящих в базу для расчетов начислений на основе среднего заработка на случай,
не предусмотренный программой;
- формирование платежных документов, в т.ч. сводных ордеров, и соответствующих им файлов бухгалтерских проводок для экспорта в ОДБ Equation, формирование протоколов записи;
- формирование необходимых расчетных и платежных ведомостей, государственных статистических отчетов, связанных с расходами на заработную
плату, отчетов по подоходному налогу, сведений по персонифицированному
учету, справок о доходах работников, различных сводных выходных форм
для внутреннего потребления и прочих с возможностью сохранения в электронном виде и распечатки на бумажном носителе;
- контроль корректности сведений, расчетов и выходных форм, формирование контрольных ведомостей по запросу;
- возможность отката расчетных операций на несколько шагов;
- сохранение (восстановление) информационной базы на определенную
дату в архиве;
- копирование (восстановление) информационной базы для временного
хранения;
- возможность частичного изменения пользователем алгоритмов расчетов
начислений и удержаний;
- возможность частичного изменения пользователем алгоритмов расчетов
и формирования ведомостей, отчетов и аналитических форм для внутреннего
потребления;
- возможность настройки прав параллельного доступа к работе с модулем
нескольких пользователей, в т.ч. одновременного просмотра, корректировки
данных и выполнения независимых промежуточных расчетов;
- контроль и защиту от некорректных действий пользователя и несанкционированного доступа;
- импорт в базу данных по заработной плате необходимых сведений о работниках из массивов, формируемых в Департаменте управления персоналом, с предоставлением возможности оперативного обновления, дополнения, корректировки, сверки;
- возможность корректировки и дополнения новых сведений в информационные поля, добавления новых полей;
- персонифицированный учет, формирование и проверка сведений по
форме ПУ-3 для передачи электронных файлов на портал ФСЗН.
Система должна в автоматическом режиме производить расчет расходов
связанных с отпусками и вознаграждениями работников, в связи с изменениями национальных стандартов финансовой отчетности и приведения их к
МСФО.
Суммы начислений и удержаний необходимо накапливать по видам и
группам по каждому работнику. Система должна автоматически контролировать ограничение сумм с целью соблюдения определяемых заказчиком лимитов при налогообложении доходов, расчета страховых взносов и других требований в соответствии с законодательными актами.
Коды начислений и удержаний должны храниться и вестись в виде справочника (определяется заказчиком системы), возможность изменения и добавления новых видов начислений и удержаний.
Виды материальной помощи с допустимыми размерами должны храниться и вестись в справочнике. Система должна автоматически контролировать
соблюдение размеров при вводе данных исполнителем.
Должен автоматически производиться расчет отпускных на базе информации по начислениям работников, данных об отпуске которые хранятся в
системе.
При расчете премии необходима возможность выплате премии в абсолютной сумме или в % от базы расчетов, как с пересчетом на отработанное время, так и без.
Премия должна выплачиваться в зависимости коэффициента, определяющего его эффективность (по алгоритму). Алгоритм устанавливается для каждого работника отдельно (по умолчанию – алгоритм определенный для подразделения, к которому принадлежит работник).
Все проводимые начисления и удержания должны автоматически отражаться по бухгалтерскому учету в ОДБ EQUATION, маркировка проводок в
ОДБ.
9. Подготовка отчетов и других документов по персоналу и заработной плате.
Виды отчетов (установленные законодательством):
- ПУ (1,2,3)
- 6т
- 12- Отчет по труду и заработной плате
- отчет о средствах фонда социальной защиты населения (с импортом
данных необходимых для отчета с ОДБ EQUATION)
- отчет о средствах по обязательному страхованию от несчастных случаев на производстве (с импортом данных необходимых для отчета с ОДБ
EQUATION).
- расчетные листки
- справки (заработная плата и др. – полный перечень будет указан в ТЗ).
- формирование отчетов (сведений) по расходам на персонал в разрезе
ЦФО.
- получение иных выходных форм.
Кратчайшие сроки обновления, изменения и устранения выхода из строя
ПО.
10. Интеграция с программными комплексами.
Должна быть предусмотрена возможность импорта данных из имеющейся
базы данных по персоналу.
Должно быть реализована возможность интеграция с ПО Cogness, ПО
ОДБ “Equation” (подробно будет описано в ТЗ), ПО WEB Tutor, внутренним
корпоративным порталом.
11. Общие требования ко всему программному комплексу
Программный комплекс должен обеспечивать:
-возможность настройки прав параллельного доступа к работе с модулем
нескольких пользователей, в т.ч. одновременного просмотра, корректировки
данных и выполнения независимых промежуточных расчетов.
- контроль и защиту от некорректных действий пользователя и несанкционированного доступа;
- отката операций на несколько шагов;
- сохранение (восстановление) информационной базы на определенную
дату в архиве;
- копирование (восстановление) информационной базы для временного
хранения;
- возможность корректировки и дополнения новых сведений в информационные поля, добавления новых полей.
Download