Подниму тему расчёта ЗП.
maytonВот тото меня и беспокоит. При количестве сотрудников over 9000 чел трудно
дождаться завершения процесса начисления. Но поверить в то что каждая
итерация принципиально несократима я не могу. Вот я и ищу концепт.
Generic-решение. Без 1С. Без Oracle. Без Excelей и всего прочего.
Голая теория. А именно. Что. Мы. Ждем. Что является узким местом
или принципиально сложным во всех бухгалтерских процессах.
Во всех знакомых мне учётных системах используеся метод последовательных вычислений различных частей ЗП с сохранением промежуточных результатов или повторным их вычислением. Именно здесь и кроются основные тормоза.
Одно время пытался на спор написать прототип расчёта ЗП на чистом SQL, без использования последовательных алгоритмов и итераций.
Столкнулся с необходимостью решить две задачи.
1. Последовательный расчёт частей начислений. Например, для того, чтобы вычислить размер премии, нужно сначала вычислить оплату по окладу, добавить разные надбавки и т.п. А размер премии в том числе необходим для вычисления налогов.
2. Расчёт средней ЗП за предыдущие несклько месяцев для опрелеления больничных и некоторых других выплат.
С первой задачей справился успешно. В результате на совсем немощном ноутбуке расчёт ЗП для сотни людей за весь год осуществлялся практически в реальном времени. Чуть более секунды. При включённом логировании, конечно, больше, так как требуется записать кучу промежуточной информации.
Вторую задачу не решил. Надобность отпала. Но, полагаю, напрягши мозги, и это можно реализовать.

mayton,

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

В вольном формате докладываю.

ЗП рассчитывается по частям: "начислениям".
Некоторые начисления зависят от других. То есть должна быть определённая последовательность расчёта.
Начисления сгруппированы по нескольким уровням. Начисления, не зависящие от других начислений, должны рассчитываться в первую очередь (пусть это будет "0 уровень"). Затем те начисления, которые зависят только от начислений 0 уровня. Пусть это "уровень 1". И так далее.
На практике неожиданной казалось, что этих уровней для реальных данных бюджетного учреждения никак не более 3-4 уровней. Хотя видов начислений - более десятка.
PostgreSQL позволяет строить иерархические запросы. Этим и пользовался.

Запрос получился на пару-тройку экранов, но это был один SQL-запрос. Ну, таковы были условия задачи.

По ходу приходилось решать несколько задач, как то:
- ведение табеля учёта рабочего времени и пометки, кто работает по табелю, а кто на окладе;
- расчёт размера оплаты пропорционально отработанным рабочим дням и ведение календаря рабочих дней;
- учёт изменений в окладах в том числе с середины месяца;
- учёт отпусков;
- учёт надбавок за выходные.

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

Ivan Durakрасчет себистоимости давно на чистом скуле ведется....
Можете указать, в каких программных продуктах?