← На главную

Переход с конфигурации «Зарплата и управление персоналом», редакция 2.5 (ЗУП 2.5), на редакцию 3.1 (ЗУП 3.1) — это сложный процесс, особенно когда речь идет о «кратком» переносе данных (перенос остатков). Одной из наиболее часто встречающихся проблем является ситуация с переходящими событиями. Например, когда сотрудник заболел в июне (еще в старой базе), а выздоровел в июле (уже в новой базе). Рассмотрим детально, как обеспечить корректное отражение таких случаев в учете, чтобы данные в табеле, расчете среднего заработка и взаиморасчетах с сотрудником оставались верными.

Анализ исходной ситуации

Разберем типичный сценарий: перенос данных осуществлен на 01.07.2019. В старой базе ЗУП 2.5 был зарегистрирован больничный лист, период которого захватывает июнь и часть июля. Сумма начисления за весь период болезни уже была учтена в задолженности (сальдо), которая перенеслась в новую базу. Однако в ЗУП 3.1 в июле в табеле учета рабочего времени этот период остается «пустым», так как документ Больничный лист в новой базе отсутствует. Нам необходимо проставить код «Б» в табеле и при этом не допустить задвоения начислений и искажения взаиморасчетов.

Вариант 1. Использование документа «Больничный лист» (рекомендуемый способ)

Этот метод считается наиболее методологически верным, так как он позволяет корректно зафиксировать стаж сотрудника и учесть период болезни для будущих расчетов среднего заработка. Проанализируем шаги, которые необходимо предпринять:

1. Создание документа: Введем в ЗУП 3.1 новый документ Больничный лист. Укажем в нем полный период болезни (например, с середины июня по 10 июля).
2. Работа с регистром «Периоды, оплаченные до начала эксплуатации»: Это ключевой механизм системы. Проверим, есть ли записи в этом регистре. Если при переносе данных информация о переходящем больничном туда не попала, ее необходимо внести вручную. Программа использует этот регистр, чтобы «понимать», какая часть периода уже была оплачена в старой программе.
3. Корректировка начислений: После выбора периода на вкладке «Оплата» программа должна автоматически определить, что дни июня уже оплачены. Если же программа пытается начислить сумму повторно, проанализируем вкладку «Пересчет прошлого периода». Часто в таких случаях приходится вручную обнулять суммы начислений, оставляя только зафиксированные дни отсутствия.
4. Проверка среднего заработка: Поскольку при кратком переносе данные о доходах за предыдущие годы переносятся в свернутом виде (документами Перенос данных), обязательно проверим расчет среднего заработка в самом больничном. При необходимости внесем данные о доходах вручную в форму расчета среднего.

Вариант 2. Отражение через документ «Отсутствие (болезнь, прогул, неявка)»

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

Создадим документ Отсутствие (болезнь, прогул, неявка) с видом отсутствия «Болезнь (больничный еще не закрыт)» или просто «Болезнь». Этот документ не производит никаких расчетов, но делает необходимые записи в регистры для формирования табеля. Важно понимать: этот способ является «быстрым решением», но он может вызвать сложности в будущем при формировании персонифицированной отчетности (ЕФС-1/СЗВ-СТАЖ), так как системе будет сложнее идентифицировать это отсутствие именно как оплачиваемый период болезни.

Работа с регистром «Очередь перерасчетов»

Выясним важную техническую деталь: при вводе документов «задним числом» (даже если мы просто хотим закрыть «хвост» июня) ЗУП 3.1 автоматически создает записи в регистре Очередь перерасчетов. Если оставить это без внимания, то при следующем начислении зарплаты программа попытается пересчитать прошлый период, что приведет к появлению ненужных строк в расчетном листке и может исказить сальдо.

Чтобы избежать этой проблемы, выполним следующие действия:

1. Перейдем в раздел Зарплата — Сервис — Перерасчеты.
2. Найдем записи, созданные нашим документом (больничным или отсутствием).
3. Выделим их и нажмем кнопку «Удалить» или «Отменить». Мы должны убедиться, что список перерасчетов пуст, если мы не планируем реально изменять суммы за прошлые месяцы.

Использование документа «Перенос данных» для тонкой настройки

Проанализируем ситуацию, когда типовые документы не дают нужного результата. В ЗУП 3.1 существует универсальный инструмент — документ Перенос данных. С его помощью можно напрямую вносить записи в любые регистры системы:

Если мы хотим, чтобы в табеле стояло «Б», но не хотим вводить документ Больничный лист, мы можем добавить в документ Перенос данных записи по регистру накопления Данные о времени для расчета среднего заработка (общий) и другим связанным регистрам. Однако этот путь требует глубокого понимания структуры метаданных ЗУП 3.1. Посмотрим, какие записи оставляет обычный больничный лист в регистрах сведений и накопления, и попробуем воспроизвести их для нужного периода июля.

Рекомендации по Пилотному проекту ФСС (Прямые выплаты)

Если ваша организация находится в регионе с прямыми выплатами, крайне важно учитывать следующее: если больничный был закрыт уже после даты перехода (в июле), то реестр прямых выплат должен формироваться в ЗУП 3.1. Для этого документ Больничный лист должен быть введен полноценно. В противном случае вы не сможете сформировать корректные сведения для передачи в фонд. Если же реестр был отправлен еще из ЗУП 2.5, то в новой базе достаточно лишь зафиксировать факт отсутствия сотрудника любым из вышеописанных способов.

Итоговый алгоритм действий

Подведем итог и составим краткий чек-лист для успешного отражения переходящего события:

1. Определяем, нужно ли нам подавать сведения в ФСС/СФР из новой базы.
2. Если нужно — создаем полноценный документ Больничный лист, проверяем средний заработок и обнуляем начисления за июнь.
3. Если нужно только отражение в табеле — используем документ Отсутствие (болезнь, прогул, неявка).
4. Проверяем регистр «Периоды, оплаченные до начала эксплуатации».
5. Обязательно очищаем сервис перерасчетов (раздел Зарплата — Перерасчеты), чтобы избежать появления «фантомных» сумм в будущем.
6. Формируем табель за июль и убеждаемся, что код «Б» проставлен верно.

Следуя этим инструкциям, мы сможем корректно завершить переход на новую версию программы, сохранив целостность данных и чистоту учета.