Как реализованно у меня в проекте:
История по входящим и расчетным данным, способным изменяться задним числом реализована в виде 2 дат - даты ввода в действие (SaveDate) и даты расчетного месяца (CalcDate). То есть например на справочник ставок есть еще таблица значений ставок с структурой:
Salary_id int, SaveDate date, CalcDate date, Value numeric(15, 2)
Соответствующе например новое значение ставки на январь 2003 года, введенное в январе будет выглядеть как:
1.
2.
Salary_id SaveDate CalcDate Value
1 01 . 01 . 2003 01 . 01 . 2003 3 000 . 00
Если например в феврале оказалось, что с 1 января ставка изменилась задним числом, то в феврале добавиться корректирующая запись:
1.
2.
Salary_id SaveDate CalcDate Value
1 01 . 02 . 2003 01 . 01 . 2003 3 500 . 00
Следующий запрос вернет реальные значения истории ставок с точки зрения
февраля:
1.
2.
3.
4.
5.
6.
7.
8.
select sv.Salary_id, sv.SaveDate, sv.CalcDate, sv.Value
from SalaryValue sv
inner join
(select Salary_id, CalcDate, Max( SaveDate ) as LastSaveDate
from SalaryValue
where SaveDate <= '2003.02.01'
group by Salary_id, CalcDate) as svm on sv.Salary_id = svm.Salary_id and
sv.CalcDate = svm.CalcDate and
sv.SaveDate = svm.LastSaveDate
Если информация имеет четкое определение начала и конца действия (например налоговые вычеты или постоянные начисления), то соотвествующе получается 4 даты: SaveDate, CalcDate, SaveCloseDate, CloseDate. Аналогично пишутся запросы, в которые попадают близжайшие к текущему расчетному месяцу SaveDate и SaveCloseDate и эти записи считаются актуальными. Для облегчения работы с таким форматом легче всего написать серию запросов по различным разрезам (вся информация с точки зрения указанной SaveDate, информация на расчетный месяц по SaveDate и CalcDate и т.д.). В ASA я для этой цели использовал параметризированные вьюверы (вьюверы, ссылающиеся на глобальные сессионные переменные, значения в которых необходимо устанавливать перед вызовом запроса, ссылающегося на вьювер). Также в ASA 9 можно использовать для этой цели ХП, с учетом того, что их теперь так же можно вставлять в запросы, но я считаю это не слишком хорошей практикой (навеяно опытом работы с Interbase). Для MSSQL идеально подходит использование UDF. Ну соотвествующе на триггерах таблиц висит контроль, запрещающий добавлять, изменять или удалять записи, у которых месяц ввода в действие (SaveDate) меньше текущего расчетного месяца.
Также для расчета описана в виде таблиц обьектная расчетная модель, где каждое начисление, удержание, налог, входящие данные, промежуточные расчетные данные и системные алгоритмы (на основе которых базируются пользовательские начисления) - это обьекты. На каждый обьект может быть заведено неограниченное кол-во алгоритмов решений. На каждый алгоритм существует его реализация, указанная в виде имени ХП, которая храниться опять же во времени (SaveDate, CalcDate). Для расчетных и системных обьектов реализация указывает на имя ХП, отвественный за расчет по данному алгоритму. Для прочих обьектов реализация указывает на имя ХП, отвественной за возвращение данных по требованию (используется при детализации результатов расчета и позволяет расшифровать любое начисление, удержание или налог, показав из каких входящих данных был произведен расчет). Так же на расчетные обьекты во времени храняться зависимости на родительские обьекты и маски начислений (группы начислений, логически обьединенные в маску, состояние которой храниться историей с поддержкой задних чисел). Зависимости позволяют определить порядок вызова ХП алгоритмов расчетных обьектов, в детализации определить входящие данные обьекта и поддерживать в системе кэширования сброс зависимых данных (например при изменении значения ставки в кэшах будут очищены по всем договорам, на текущий момент ссылающимся на эту ставку начисление по окладу, ночные, сверхурочные, премии, подоходний и т.д. - то есть все те, кто по дереву зависимостей имеет родителем ставку). Про кэша писать не буду, раньше довольно много про них написал. Хочу только заметить, что в случае расчетов зп на большое кол-во сотрудников такую усложненную систему кэширования я считаю вполне оправданной, если же предполагается маленький обьем расчитываемой информации или же сами расчеты не столь наворочены, то овчинка явно выделки не стоит.
Соотвествующе под вышеописанную структуру модели расчетов есть центральная ХП, которая всем и занимается - определяет список кого считать, какие месяца сторнировать и для кого, вызывает ХП инициализации входящих кэшей (то же централизованная ХП), в которых хранятся денормализованные части входящих данных со сложной структурой в БД, получение которых запросами могло бы серьезно замедлить расчет и которые используются во многих местах расчета (например тот же справочник ставок уже разложен в входящий кэш ставок договоров, где на каждый договор уже храниться информация в виде Contract_id, Salary_id, BeginDate, EndDate, Value, DayValue, HourValue - то есть уже видны периоды начала и конца действия значения ставки для договора и ее оклад разложен в виде дневного и часового тарифа для последующего его использования например при расчетах ночных, сверхурочных или праздничных рабочих дней).
Что я получил от такой довольно таки сложный схемы реализации зп:
1. История алгоритмов расчетов - любые изменения самих алгоритмов храняться в виде истории, поэтому спокойно можно изменить например расчет больничных задним числом и автоматом пересчитать задним числом все больничные на изменяемый период даже с учетом того, что во входящей информации возможно не было изменений задними числами. Плюс поддержку правильного сторнирования в ситуациях, когда алгоритм изменился с текущего расчетного месяца, но необходимо еще произвести расчет задним числом месяцев, в которых должна участвовать старая версия алгоритма (например с июня изменился расчет больничного, однако необходимо еще пересчитать сотруднику больничный за март по старым правилам расчета больничных).
2. Хранение и централизация всей логики расчетов на сервере позволяет производить расчеты по требованию в любой момент времени - например при выставлении межрасчетными платежами премий, печати отчетов, организации прозрачности расчета для клиентского приложения, где пользователь проводя изменения всегда видит результаты расчетов с точки зрения актуальной информации в БД. Плюс поддержка обьектной расчетной модели, реализованная в БД в виде метаинформации позволяет получать полную информацию о состоянии обьектов, на основании которой можно производить детализацию расчетов, определять зависимости обьектов, получать ссылки на ХП алгоримов расчетных обьектов, действующих на указанный период и т.д.
3. Система кэширования позволяет ускорить расчеты, оптимизируя по принципу "Первый раз посчиталось, далее актуально, пока не изменились параметры родительских обьектов". Плюс данные в кэшах хранят много полезной и разложенной по полочкам информации, которая частенько используется при построении отчетных ведомостей (например в кэшах по договорам разложены по нарастающей начисления с начала года по различным используемым маскам начислений, действующие налоговые вычеты, сумма уже удержанного налога с физ.лиц, средняя зп за последние 3 месяца, различные флаги состояние договора и сотрудника - является ли резидентом, есть ли отклонения в работе от графика работ, закрывает ли ставка полный месяц и т.д. и т.п.).
4. Реализация поддержки пользовательских расчетных обьектов, ссылающихся на системные алгоритмы, позволила мне и пользователям однотипно создавать начисления и удержания, не требующие сложных расчетов (например премия окладная, надбавки, профвзносы и т.д.).
Насчет получения ТЗ я уже тоже писал. Насчет граблей в реализации - особо не наблюдалось, единственное что было не приятно, так это отсутствие квалифицированных постановщиков на первых этапах сбора требований ТЗ для проектирования структуры входящих данных. Далее как был реализован движок расчетных обьектов проблема сама собой отпала, так как он позволял мне на довольно таки элементарном уровне с помощью обычных запросов описывать автономные алгоритмы и любые неточности в постановке по расчетной части или же изменения в законодательстве без проблем исправляются простой корректировкой запроса в нужной ХП.
Очень надеюсь, что все вышеперечисленное здорово упростит сопровождение системы и если кэша и движок расчетов будут работать как часы, то для модернизации и сопровождения зп подойдет любой человек, знающий в средних обьемах SQL и очень неплохо Delphi (клиент написан на нем), потому как я после дописания сего проекта скорее всего переключусь на написание проекта автоматизации совсем другой отрасли - достала бухгалтерия, будь она не ладна :)
P.S. Больше сюда ничего писать не буду, все что мог уже сказал и не раз :) Если возникнут какие то конкретные вопросы, пишите пожалуйста мне на мыло.
