Моделирование расчетного листка. Мозговой штурм

1) и 2) базируются на типовых алгоритмах

3) сами собираем расчетные листок:
берем плановые начисления +
средние прочие начисления/удержания за 3 (?) предыдущих месяца +
считаем с получившихся начислений взносы и НДФЛ (желательно используя типовые модули)
Плюсы: скорость
Минусы: алгоритм полностью не типовой, трудности с поддержкой при сильном изменении ЗУП

Просьба высказывать идеи. Или комментировать те, что уже озвучены.

Среди вариантов не хватает "нулевой гипотезы" и "административного решения"

Нулевая гипотеза. "Прежде чем решать задачу нужно убедится, что задача реально существует и сформулирована верно"
А надо ли? Неужели все тысячи сотрудников предприятия получают два расчетных листка, один из которых предварительный и, в общем, неверный. Может там идет расчет аванса и его просто нужно вынести в отдельный документ? Или этими листками пользуется полтора человека в отделе статистики и им лучше зайдет сводный отчет? Или там отдел продаж в предвкушении бонусов не может подождать недельку чтобы получить расчет по всем правилам и им бы простенький отчетец по прибыли выдать?

Административный ресурс. "Мы внедрили новое ПО , будем подстраивать бизнес-процессы под него"
Обязать пользователей формировать документы, когда нужны листочки, а потом пускай перепроводят в конце месяца. Накинуть по 500р к их окладу, это все равно будет на порядок выгоднее чем продолжать обслуживание SAP

Мне кажется, Иван, вам справедиливо указали, что для полноценного обсуждения темы вы недостаточно конкретно определили цель.
Вы намекаете, что, мол, не можете публично раскрыть точные функциональные требования заказчика. Ну хорошо, вы их сформулируйте как "допущение от себя". Типа: я как инициатор дискуссии исхожу из того, что основной целью т. н. "моделирования р/л" в рамках ДАННОГО ОБСУЖДЕНИЯ является тот-то и то-то.

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

Если рассуждать абстракто, то "моделирование р/л" может решать две основных цели:
- Посмотреть, сколько получит каждый сотрудник ПРИ УСЛОВИИ ПОЛНОСТЬЮ ОТРАБОТАННОГО ВРЕМЕНИ и допущении, что начисления, не зависящие от отработанного времени, будут выболняться по некому формализуемому сценарию (например, в том же размере, как и в предыдущем квартале). Это используется, например, при бюджетировании, дирекуиями по персоналу при обосновании изменений в системе мотивации и штатном расписании и т. д. Очевидно, что в рамках этой цели надо выбирать между 2-м и 3-м вариантом.
- До продуктивного расчета зарплаты выявить максимальный процент ОШИБОК РАСЧЕТА КОНКРЕТНОГО МЕСЯЦА, возникших на фазе ввода после предыдущего закрытия (кадровые движения, плановые начисления, неявки, данные оперативного и табельного учета и т. п.). Очевидно, что для этой цели ни 2-й, ни 3-й вариант не подходят, у вас просто нет выбора, кроме как с теми или иными вариациями реализовывать 1-й.

Не думаю, что вам удастся совместить обе цели в одном функционале.

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

В SAP есть платформенная фишка, которая позволяет моделировать РЛ до момента закрытия месяца. Расчетчики этим пользуются на свой страх и риск, поскольку сами процессы расчета зарплаты на порядок сложнее, чем в 1С:ЗУП. Для нас важна следующая особенность: расчетный листок формируется с учетом введенных документов отклонений в ткущем месяца до момента его закрытия.

Вероятно, надо проводить воспитательно-просветительскую работу, показать как быстро и просто ЗУП закрывает месяц, что к 5 числу следующего месяца можно сформировать реальный РЛ без всякого моделирования.

Тема закрыта.