2.3 Перерасчеты

«Не нужно бояться перерасчетов» – гласила презентация, найденная в Сети. Действительно, при переходе на расчет заработной платы в SAP многие расчетчики начинают «бояться» перерасчетов. Тому есть несколько причин.

Как правило, многие системы, в которых работали люди до SAP, были построены как документоориентированные системы. Первичным был документ, будь то документ начислений, удержаний, документ табеля, документ расчета. В крупных компаниях, где ИТ-системы формировались долгие годы, встречаются решения, когда перерасчеты нужно было делать вручную и оформлять отдельным документом. Консультант SAP привык, что перерасчет – это нормально, свободно оперирует словами: «Сейчас перерассчитаем всех». У бухгалтера появляется легкий шок на лице, так как руки еще помнят, что такое ручные перерасчеты.

Вторая, менее эмоциональная причина – это возникновение дополнительных строчек в расчетном листе, которые нужно объяснять работникам. Консультантам этого не понять, так как они практически никогда не общаются с простым рабочим, который считает каждую копейку. Консультанту надо обновить базы, «положить вид в кластер», «создать технический вид» – все очень умно звучит и еще больше пугает простого бухгалтера. Каждый перерасчет, отраженный в расчетном листе, в «плюс» или в «минус», вызывает вопрос у работника: «Что же мне посчитали неверно?» Вполне резонный вопрос, следует заметить. Так как бухгалтер в начале своего опыта работы с системой еще плохо представляет, как устроен внутренний механизм перерасчетов, как найти и объяснить причину возникновения перерасчета, то бравирование консультанта его только пугает.

Самая неэмоциональная причина, с которой пришлось столкнуться на одном из проектов, – это возникновение отрицательных разниц. Такое бывает только в начале проекта, когда система откровенно недонастроена, не протестирована. Первые месяцы расчеты идут корректно, люди получают деньги, вопросы не задают. А затем обнаруживается, что все это время что-то считалось неверно. Например, средний заработок, который обычно составляет существенную часть фондов оплаты труда. Система выполняет перерасчет заработной платы за прошлые периоды, и работник уходит в «минус». Из-за неверных вычислений в предыдущих месяцах выплаты были завышены настолько, что в текущем периоде вся зарплата была удержана для компенсации перерасчета. Нехорошая ситуация, работник должен компании существенную сумму денег. Все это отягощается тем, что по российскому законодательству нельзя удерживать более 50% от суммы заработной платы, и то в ограниченных случаях. Технически в системе нельзя ограничить именно сумму удержания в результате перерасчета.

Перерасчеты в системе – это стандартное решение, которое автоматически (акцентирую на этом внимание) распознает изменения, существенные для расчета заработной платы, и перерассчитывает заработную плату с момента возникновения такой причины. Расчет ведется по алгоритмам того времени, когда возникло событие. Разница, сформированная в результате перерасчета, выплачивается/удерживается и проводится в текущем расчетном периоде. Весь процесс автоматизирован и запротоколирован в системе. Всегда можно увидеть, что было посчитано до перерасчета и после перерасчета. Есть понятия «для периода», «в периоде», о которых мы поговорим позже. В части перерасчета есть ограничение для учета рабочего времени, где система не хранит историю изменений данных в балансах времени (кластере оценки времени), а всегда содержит только актуальную информацию.

Чтобы обезопасить себя на первых порах работы в системе, могу порекомендовать две простые вещи:

• Перед запуском расчета заработной платы формируйте отчет по инфотипу 0003 «Статус расчета», чтобы увидеть, по каким людям система будет запускать перерасчет. Отчет делается с помощью оперативного запроса по полю «Дата последнего изменения». Так вы сможете увидеть «необычные» случаи с очень далекими перерасчетами.
• Чтобы понять, почему возник перерасчет (почему система изменила дату в ИТ0003 и будет запускать перерасчет), попросите администраторов включить протоколирование изменений в инфотипах. Если вы видите необычный случай перерасчета, с помощью протокола изменений инфотипов по сотруднику можно понять, кто, что и когда изменил. Вполне безобидный случай, как ограничение выплаты, которая была мигрирована в ИТ0014 с даты старта системы, а сейчас нужно ее ограничить, вызовет перерасчет с даты начала записи (начала старта системы). Такие случаи можно распознать и вручную изменить дату в ИТ0003, чтобы избежать лишних вопросов.
• Во время моделирования расчета заработной платы или после первого расчета формируйте расчетные листы «для себя». Попросите сделать вам такой расчетный лист, в котором будут отражены все строчки перерасчета с указанием, за какой период был перерасчет. Пусть это будет большой листок, даже больше одной страницы, но он поможет вам понять, что случилось, и дать корректное объяснение работнику. Необязательно выдавать такие листочки работникам.

Резюме

Перерасчеты – это инструмент, который полностью автоматизирован и не требует ваших трудозатрат. Перерасчеты помогают найти ошибки в системе, что сохранит ваши нервы при выяснении, куда делись десять копеек. Перерасчеты позволяют выплачивать работникам то, что они заработали, так как система перерассчитает сумму выплаты на «правильную, заработанную»..

2.4 Налоговая отчетность и в периоде/для периода

Хочу рассказать вам одну ситуацию, с которой пришлось столкнуться лишь однажды, но нервов она попортила много. Это хороший урок, как не надо делать. В одной компании стартовал SAP. Думаю, многие знают, что во время стабилизации системы, то есть исправления ошибок, приходится много раз перерассчитывать заработную плату. Бывали случаи, когда перерассчитывали целый год из-за какого-нибудь налога, а под раздачу попадали и прочие виды оплаты. Для пользователя как будто ничего страшного нет. Но наступает время сдавать годовую отчетность, и начинаются проблемы. Чтобы лучше понять природу проблемы, объясню, что такое в периоде и для периода.

Допустим, сегодня апрель. Мы запускаем расчет заработной платы за апрель. То есть с точки зрения системы месяц или расчетный период еще не закрыт. Зачастую закрытие происходит в первые десять дней после окончания расчетного периода. Итак, 30 апреля закрываемся. Технически мы в апреле запускаем расчет за апрель, так как единицу расчета еще не перевели на следующий расчетный период. Все корректно и красиво.

Сегодня май. Какая-то «редиска» принесла больничный лист за апрель. Мы вводим в апрель больничный. Сегодня 31 мая. Мы запускаем расчет заработной платы за май. Но система помнит, что у нас есть «редиска», которая принесла больничный за апрель. Значит, нужно этот больничный посчитать и разницу доплатить или удержать в мае за апрель. Замените выражение «за апрель» на «для апреля». Сделаем одолжение апрелю и посчитаем его в мае еще раз «на чистовик». Но в системе уже есть один расчет апреля, который мы делали месяц назад. Именно в этот момент и появляется понятие «для периода».

Система повторно считает апрель с новыми данными, сохраняет в базе данных. Чтобы отличить первоначальный расчет от последующего, система ставит две отметки:

• статус расчета. A – актуальный (actual), P – предыдущий (previous) и O – оригинальный (original);
• для какого периода этот расчет, и в каком периоде он образовался: те самые для периода и в периоде.

Если запустить транзакцию PC_PAYRESULT, выбрать любого рассчитанного человека, то вы увидите эти колонки (Рис. 2.1).

Рис. 2.1

Остановимся чуть подробнее