Аналогичная задача актуальна в каждой организации, и чем организация крупнее и сложнее хозяйственная деятельность, тем сложнее расчёт зарплаты. Да и родное государство скучать не даёт, законы меняет только успевай дорабатывать систему расчёта. И плюс ещё различный фонды, налоги, статистика и т.д...

Перед началом работ стояла также задача выбора, либо покупное ПО, либо своё.
Перебрали варианты, проанализировали плюсы и минусы, остановились на своей разработке.
Мне удалось реализовать расчёт зарплаты на предприятии, вид деятельности: производство, персонал: несколько тыс. человек. На данный момент все, что можно автоматически рассчитать уже реализовано, введена масса ограничений на неверные действия операторов, количество ошибок практически свелось к нулю. После каждого изменения вводимых данных, происходит автоматический расчёт, по каждому лицевому счёту в реальном времени. В результате работ по оптимизации системы, скорость работы высокая.
Система реализована на MSSQL 2000, клиентские места на C++ Builder.
Со временем кадры стали самостоятельным модулем, а З/п интегрировал в информационную систему предприятия, тоже полностью разработанной на предприятии.
Так что привожу факт успешной реализации проекта своими силами.

Зарплатой занимаюсь 15 лет, до этого у меня был вариант в DOS на Clipper. Прога работала в 9 местах, причём как в бюджетных организациях, так и на производстве. В трёх местах работает до сих пор, причём в двух местах бухучёт ведут на 1С, зарплату так и оставили мою. Зарплата в 1С им не понравилась. Чтобы избавиться от DOS варианта, готовлю "малый" вариант з/п под Windows на MSSQLExpress.

Меня также интересует как реализовали эту задачу другие разработчики.

Будут ко мне вопросы, постараюсь ответить.

Удачи.

Ещё добавлю, в своей системе на данный момент, реализован расчёт повремённой зарплаты, для этого достаточно табеля и тарифных ставок, окладов, контрактов и т.д. Для сдельщиков готовые суммы вводятся с нарядов.
Автоматизация расчёта сдельной оплаты труда дело громоздкое и решаться должно отдельно.
Для этого я сейчас занимаюсь созданием и внедрением учёта всех операций в производственных процессах, то есть учёт трудоёмкости. От уже неё планирую перейти к учёту сдельной оплаты и автоматическом внесением в з/п.
Дело в том, что к сожалению всё охватить невозможно, поэтому приходится делать все поэтапно.

По скорости работы: как я уже отмечал, почти во всех местах после ввода данных происходит полный расчёт л/с сотрудника, кроме ввода табеля (для сохранения скорости ввода).
Есть возможность в любой момент рассчитать всех сотрудников. Время расчёта 36 сек.
Хранимые процедуры и индексы позволили добиться хорошей скорости работы системы.

Удачи.

Более 3000 тыс.

Ещё добавлю, сервак не очень шустрый. В процедуре расчёта каждого л/с происходит более 100 запросов, поэтому с оптимизацией пришлось повозиться основательно, да выбранная структура БД оказалась удачной, благо прежнего опыта было достаточно.

2Alex_Toms вопрос: я так понял что у Вас после изменения любых данных усотрудника идет расчет.. А эсли не секрет зачем ?

Для работы системы в реальном режиме времени, дело в том, что кто то увольняется, кто то уходит в отпуск, в течении месяца приносят больничные, им бывает нужны получить суммы побыстрее, в общем есть необходимость в шустрой работе системы.

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

Мне такое не позволительно.

У меня расчёт больничных и отпусков занимаем несколько сек., в основном время тратится на ввод данных, проблем с этим нет.
Данные в з/п необходимо вводить по мере их поступления в течении месяца. Так как в конце месяца приносят табели, список различных премий и др. начислений и всё это необходимо ввести без ошибок за 2-3 дня, проверить каждый л/с на ошибки и т.д. Каждый бухгалтер ведёт 600-700 чел., при этом они ещё и болеют и в отпуск уходят и на это время на кого-то падает дополнительная нагрузка на это колич. чел. и всё это необходимо успеть. А через месяц одну сокращают и каждой добавят ещё где то по 150 чел. Поэтому откладывать всё на конец месяца просто не реально.
О структуре БД:
Описание структуры очень в крупную клетку, названия таблиц .
Данные о сотрудниках хранятся в таблице «Кадры», сейчас это отдельная БД, ведёт её отдел кадров, сопровождает задачу программист.
Для з/п перечислю некоторые основные таблицы: «Подразделения», «Лицевой счёт», «Журнал сумм начислений/удержаний (Н/У)», «Справочник Н/У» и ряд справочников и т.д.
«Центральная» таблица: «Лицевой счёт», в ней есть ссылки на приведённые таблицы, в ней хранятся данные о л/с каждого сотрудника, Таб №, отчётный период, иждивенцы, льготы, постоянные Н/У (например алименты), табель и т.д. В неё я заношу все необходимые рассчитанные данные о л/с, начислено, удержано, к выдаче, налоги НДФЛ и ЕСН, ряд промежуточных данных для расчёта налогов, необходимых для проверки правильности расчёта и т.д., пока 147 полей. Для каждого месяца своя запись.
В «Журнал Н/У» заносятся суммы Н/У для каждой записи л/с.
В «Справочнике Н/У» хранятся коды и названия Н/У.
Простым запросом данные из этих таблиц собирается для одного л/с, либо для различных сводов.
Полный расчёт всех мыслимых и не мыслимых сумм по каждому л/с, производится хранимой процедурой, для полного расчёта достаточно одного запуска. Запускать её можно неограниченное число раз не опасаясь ошибок. Для этого разработан такой алгоритм расчёта.
При проектирование структуре БД максимально руководствовался правилами построения реляционных БД. Удалось избежать избыточности данных, в системе нет ни одного триггера, а это тоже скорость работы.
Вот очень кратко структуре…

Удачи.

После моего сообщения, интерес к теме почемуто пропал, уже ни кому не интересно?

smeh а что представляет из себя Справочник Н/У ?

Поля: Код Н/У, наименование, признак: этод код начисление или удержание, далее признаки: входит ли в НДФЛ, ЕСН, больничный, очер. отп, ученич. отп, профсоюз и т.д. Эти признаки я использую для рачёта различных видов начислений.

2Alex_Toms - мне бы хотелось увидеть структуру таблицы - гдевы храните начисления и удеражния по лицевому счетте с краткими комментариями.

Суммы хранятся в таблице: «Журнал сумм начислений/удержаний (Н/У)»
Поля: ID, вн. ключ к записи в таблице л/с, вн. ключ к записи в таблице Справочник Н/У,
сумма, признак ручного или авт. ввода суммы, комментарий.
Признак ручного или авт. ввода суммы разрешает редактировать сумму.
Бухгалтер видит её например так: Код 5, Премия, 10000.00, За то, что сотрудник бывает на работе.

План счетов предприятия, хранится в отдельной таблице.
В таблице подразделениЙ есть ссылки на "План счетов"

Lamazoid Я в свой проге отказался от всех признаков касающихся Входимости в определенные базы. Точнее не отказался а ввел таблицу в которых виды расчетов собраны в определенные группы ....

А я наоборот это ввёл, и по ходу жизни их добавляю, это удобно.
Редактирует справочник руководитель расчётной части, куда и что входит, я ей всё обяснил и кроме своего контороля в это дело не вмешиваюсь. Так что если что ни так, спрос с неё...
Я стараюсь делать так, чтобы служба работала максимально самостоятельно от меня, поэтому ввёл в систему максимум бухгалтерских настроек, чтобы я как можно меньше касался этой задачи. Кроме неё есть ещё задачи.

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

Для smeh... В системе для сотрудника есть старый оклад/тариф, ставим табель 9 дней, рассчитываем, расчётные суммы заносим в ручную, изменяем оклад и табель с 10 по..., рассчитываем, расчётные суммы заносим в ручную, убираем оклад, чтобы в этом месяце от табеля не было расчёта, ставим табель за месяц. На следующий месяц ставим оклад и работаем как обычно. Вся эта процедура занимает всего несколько минут, а такие ситуации бывают крайне редко. Как правило такие изменения бывают с начала месяца и придумывать, что либо на единичные случаи я ни чего не стал.

Всё наше обсуждение свелось к "самодельному" ПО. Но хотелось бы услышать отзывы наших коллег о покупном ПО, о плюсах и минусах, например "Камин" и др.

Удачи.

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