При формировании статистической отчетности, в частности формы П-4, пользователи могут столкнуться с неприятной и не очевидной на первый взгляд проблемой: по отдельным сотрудникам сумма начисленной заработной платы удваивается. При этом проверка расчетных документов, таких как «Начисление зарплаты и взносов», и анализ данных в отчете «Свод начисленной зарплаты» показывают корректные цифры. Расшифровка же самого отчета П-4 показывает, что все начисления по конкретному человеку увеличены ровно в два раза.
Такая ситуация может возникнуть даже по тем сотрудникам, у которых в отчетном месяце не было никаких кадровых движений — только стандартный оклад и надбавки. Проблема также может проявляться и в других формах статистической отчетности, например, в ЗП-ЗДРАВ. Давайте разберемся, в чем причина этой ошибки и как ее исправить.
На первый взгляд, логично предположить, что отчет П-4 берет данные из регистра накопления Начисления и удержания по сотрудникам. Однако, это не совсем так. Для корректного формирования статистических отчетов система также анализирует данные о том, в каком состоянии находился сотрудник в отчетном периоде (работал, был в отпуске, на больничном и т.д.). Эта информация хранится в регистре сведений Состояния сотрудников.
Корень проблемы кроется именно в этом регистре. В результате программной ошибки, которая была официально признана разработчиками 1С, в регистре сведений Состояния сотрудников на одну и ту же дату для одного сотрудника могли создаваться две абсолютно идентичные записи со статусом «Работа».
Когда система формирует отчет П-4, она видит эти две записи и обрабатывает каждую из них. В результате все начисления по этому сотруднику за период действия дублирующихся записей учитываются дважды, что и приводит к удвоению итоговой суммы в отчете.
Эта проблема была зарегистрирована как Ошибка 10228645. Разработчики выпустили исправления в версиях 3.1.14.394 и 3.1.16.133. Однако важно понимать: обновление конфигурации предотвращает появление таких ошибок в будущем, но не исправляет уже существующие некорректные данные в вашей информационной базе. Поэтому, даже работая на обновленной версии, вы можете столкнуться с последствиями этой ошибки, если она возникла ранее. Исправить накопленные ошибки необходимо вручную.
Этот способ является наиболее простым и быстрым, если проблема обнаружена по одному или нескольким сотрудникам. Суть метода заключается в том, чтобы заставить программу принудительно пересчитать и перезаписать историю состояний сотрудника, тем самым удалив дублирующуюся запись.
Рассмотрим пошаговый алгоритм действий:
Отсутствие (болезнь, прогул, неявка) или Командировка.Состояния сотрудников новую запись, например, «Отсутствие по невыясненной причине», и корректно закроет предыдущий период работы.Этот метод эффективно «встряхивает» регистр состояний и заставляет его перестроиться в правильную последовательность записей, убирая дубли.
Если проблема носит массовый характер, исправление по одному сотруднику может быть трудоемким. В этом случае стоит воспользоваться официальными рекомендациями от фирмы "1С".
Согласно рекомендациям, задвоение записей в регистре состояний могли вызывать определенные кадровые документы, проведенные в версиях программы, содержащих ошибку (например, больничные листы, отпуска). Если вы можете предположить, какие документы могли стать причиной, можно выполнить их перепроведение.
Для этого необходимо найти эти документы за прошлые периоды, отменить их проведение и провести заново. При повторном проведении в обновленной версии программы сработает уже исправленный алгоритм, который корректно запишет данные в регистр Состояния сотрудников.
Для автоматического исправления большого количества некорректных записей фирма "1С" распространяла через свою техническую поддержку специальную внешнюю обработку ОбновитьСостоянияСотрудника.epf.
Как это работает:
Состояния сотрудников для всех или выбранных сотрудников.Этот способ является наиболее предпочтительным при массовом характере ошибки, так как он экономит время и снижает риск человеческой ошибки.
В заключение, отметим, что стандартные процедуры, такие как очистка кэша или Тестирование и исправление (ТИИ), в данном конкретном случае, скорее всего, не помогут, так как проблема заключается не в физическом повреждении базы, а в логической ошибке в данных, которую необходимо исправлять целенаправленно одним из описанных выше способов.