Переход с устаревшей конфигурации 1С:Зарплата и управление персоналом редакции 2.5 на актуальную редакцию 3.1 — процесс, часто сопровождающийся методическими сложностями. Одной из наиболее распространенных и неприятных проблем является корректное отражение переходящего больничного листа (например, когда болезнь началась в декабре старого года, а закончилась в январе нового, уже после даты переноса данных).
В этой статье мы подробно разберем, почему возникает проблема со сторнированием начислений прошлого периода, почему «схлопываются» строки в регистре учета доходов по страховым взносам, и рассмотрим несколько практических способов решения этой задачи — от официальных методических рекомендаций до «обходных» маневров.
Рассмотрим ситуацию, с которой сталкивается большинство расчетчиков. Данные перенесены на 01.01.2018. В январе 2018 года сотрудник приносит больничный лист за период с 16.12.2017 по 17.01.2018. При попытке провести документ Больничный лист в новой базе ЗУП 3.1 программа не формирует автоматические сторнирующие записи за декабрь 2017 года.
Причина кроется в особенностях переноса данных. При рекомендованном (свернутом) переносе данных в новой базе ЗУП 3.1 отсутствуют сами расчетные документы за прошлые периоды (такие как Начисление зарплаты и взносов за декабрь). Информация о доходах и начислениях прошлых лет хранится исключительно в виде записей в технических документах Перенос данных. Поскольку физического документа-основания за декабрь в базе нет, новый документ Больничный лист просто «не видит», что именно и какими документами нужно сторнировать.
Попытка исправить ситуацию «в лоб» — то есть вручную ввести сторнирующие строки на вкладке перерасчета прошлого периода в документе Больничный лист — часто приводит к другой ошибке. Например, расчетчик вручную вносит три строки сторно за декабрь:
В расчетном листке и своде начислений все выглядит корректно. Однако при анализе регистра накопления Учет доходов для исчисления страховых взносов обнаруживается, что вместо трех строк программа делает одну общую запись на сумму -9 200 руб. с видом дохода «Премия».
Проанализируем, почему так происходит. В ЗУП 3.1 записи в регистры по страховым взносам при сторнировании формируются на основании настроек видов расчета и их связи с вытесняющими начислениями. Так как первичного документа начисления в системе нет, программа не может сопоставить ручные сторно-строки оклада и ночных с их реальными источниками. Система распределяет сторнируемый доход некорректно или «схлопывает» его по первому попавшемуся виду расчета, у которого совпадает категория дохода.
Ниже приведены четыре практических способа решения этой проблемы.
Если вы только планируете переход или у вас есть возможность перенести данные заново, этот способ является самым чистым с точки зрения методологии 1С.
Начисление по больничному листу за весь период болезни.Перенос данных.Если первичный лист нетрудоспособности (декабрьская часть) уже был рассчитан и закрыт в старой базе, а в январе сотрудник принес продолжение:
Больничный лист.Этот способ позволяет избежать «ломания» кадровой истории в новой базе. Сторнирование декабря производится напрямую в регистрах:
Больничный лист в январе на вкладке «Главное» укажите реальный период болезни. Программа рассчитает сумму пособия. Перейдите на вкладку «Пересчет прошлого периода» и очистите (или удалите) все сторно-строки, чтобы документ не делал неверных движений по взносам.Перенос данных за декабрь 2017 года с кодами ЗП (зарплата) и РЛ (расчетные листки). Внесите туда сторнирующие записи (со знаком минус) по окладу, ночным и премии.Перенос данных по регистру накопления Учет доходов для исчисления страховых взносов. Разбейте общую сумму сторно строго по видам доходов, чтобы отчетность по РСВ сошлась без искажений.Если ручная правка регистров кажется вам слишком сложной, можно прибегнуть к методу временной симуляции расчета за прошлый месяц. Внимание: данный метод требует повышенной аккуратности, так как он затрагивает историю кадрового учета.
Разберем этот алгоритм по шагам:
Начальная штатная расстановка (или других документов ввода начальных данных) с 01.01.2018 на декабрь 2017 года.Начисление зарплаты и взносов за декабрь 2017 года по данному сотруднику (база должна соответствовать тому, что было начислено в ЗУП 2.5). Чтобы расчет прошел корректно, убедитесь, что график работы сотрудника за декабрь заполнен.Больничный лист. Теперь программа увидит созданный документ начисления декабря и автоматически и корректно сформирует сторнирующие записи по всем видам расчетов.Больничный лист.Начисление зарплаты и взносов за декабрь.Начальная штатная расстановка обратно на 01.01.2018.Важные нюансы этого способа: если в вашей организации ведется история изменения штатного расписания или у сотрудников настроены вредные условия труда (класс условий труда), подобные манипуляции могут «подвинуть» даты начала действия этих условий. Вам придется временно распроводить документы утверждения штатного расписания и корректировать историю вручную.
Кроме того, после таких расчетов в системе могут возникнуть фантомные записи в очередях перерасчетов. Для их очистки рекомендуется использовать специальную обработку или воспользоваться следующим кодом на встроенном языке 1С:
// Очистка регистра сведений "Перерасчет зарплаты" для предотвращения ложных доначислений
НаборЗаписей = РегистрыСведений.ПерерасчетЗарплаты.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Сотрудник.Установить(ВыбранныйСотрудник);
НаборЗаписей.Записать();
При переходящих больничных критически важно проверить пенсионный стаж сотрудника за декабрь. Даже если вы успешно проведете сторно начислений в ЗУП 3.1, в перенесенном регистре Параметры периодов стажа ПФР дни декабря могут остаться со старым кодом (например, «ОКЛАД» или «НЕОПЛ» вместо «ВРНЕТРУД»).
Рекомендуем перейти в «Функции для технического специалиста», открыть регистр сведений Параметры периодов стажа ПФР, найти записи по сотруднику за декабрь и убедиться, что период болезни закодирован верно. При необходимости скорректируйте эти записи вручную в соответствующем документе Перенос данных, иначе годовая отчетность по стажу сформируется с ошибками.