Переход с конфигурации «Зарплата и управление персоналом», редакция 2.5, на редакцию 3.1 — это сложный процесс, который часто сопровождается проблемами сходимости данных. Одной из самых трудоемких областей является учет северных отпусков. Различия в архитектуре регистров и логике расчета между старой и новой версиями программы приводят к тому, что остатки, которые в 2.5 выглядели логично, в 3.1 начинают «двоиться» или принимать гигантские значения. В рамках данной статьи мы подробно разберем, почему возникают такие расхождения и как правильно привести данные в порядок с помощью типовых инструментов системы.
Проанализируем сначала причины технических различий. В программе ЗУП 2.5 учет остатков отпусков велся в «плоских» таблицах, и зачастую пользователи могли вручную корректировать их непосредственно в карточке сотрудника. В ЗУП 3.1 реализован накопительный принцип. Все движения фиксируются в регистрах накопления, таких как ЗанятыеПозицииШтатногоРасписания и регистрах сведений ДанныеОПравахНаОтпуск.
Разберем основные факторы, влияющие на некорректный перенос:
Рассмотрим ситуацию, описанную в сообщениях форума: при вводе остатков вручную вместо ожидаемых -32 дней (перерасход) программа показывает 132 дня. Проанализируем причину такого поведения. Это происходит из-за того, что ЗУП 3.1 пытается «дозаполнить» историю. Если мы создаем документ ВводОстатковОтпусков и указываем дату начала рабочего года, которая значительно отстоит в прошлом, программа берет настройки должности (где прописано право на 24 дня северного отпуска) и пересчитывает стаж за все прошедшие годы. Она считает, что за этот период сотрудник не гулял, и плюсует эти дни к тем, что вы ввели вручную.
Выясним причину через основной диагностический инструмент — отчет «Справка по отпускам». Нам необходимо сформировать этот отчет в обеих базах (в 2.5 и в 3.1) и сравнить не итоговую цифру, а конкретные границы рабочих годов. Если в 3.1 границы периодов «поплыли», значит, проблема в данных о стаже или в настройках штатной расстановки.
Если после переноса и начала работы в новой базе вы обнаружили ошибки у отдельных сотрудников (особенно по «северникам»), использование документа ВводОстатковОтпусков является наиболее корректным способом исправления. Рассмотрим алгоритм действий по шагам:
РабочийГод. Если у сотрудника есть перерасход (отрицательный остаток), необходимо четко указать, в счет какого рабочего года этот аванс был предоставлен. В 3.1 отрицательный баланс без привязки к периоду может привести к ошибкам при расчете среднего заработка в будущем.Рассмотрим важный нюанс: если вы используете ВводОстатковОтпусков уже после того, как база была запущена в эксплуатацию, данные из этого документа «перекрывают» все накопления, сделанные до него. Однако будьте осторожны: если в документах ПереносДанных по регистрам ОстаткиОтпусков остались записи по этому сотруднику, система может продолжать учитывать их. Рекомендуется проанализировать регистр сведений ДанныеОПравахНаОтпуск через «Все функции» (или «Функции для технического специалиста») на предмет дублей записей на одну и ту же дату.
Многие пользователи пытаются править остатки в документе НачальнаяШтатнаяРасстановка. Проанализируем, почему это не всегда эффективно. Данный документ формируется в момент «краткого» переноса данных и фиксирует состояние на дату среза. Если вы уже начали вести учет, вводить отпуска и увольнения, то перепроведение НачальнойШтатнойРасстановки может повлечь за собой необходимость перепроведения всех последующих цепочек документов.
Как отмечалось в сообщениях форума, редактирование этого документа имеет смысл только в одном случае: если вы делаете это сразу после переноса и до начала ввода первичных документов в ЗУП 3.1. Если время упущено, ваш выбор — точечный ВводОстатковОтпусков.
Чтобы избежать ситуации, когда остаток внезапно увеличивается в несколько раз, выполним следующие проверки:
1. Настройка вида отпуска. Проверим справочник ВидыОтпусков. Убедимся, что для северного отпуска установлено значение «В календарных днях» и установлен флаг «Является ежегодным». Если по ошибке перенеслось значение «В рабочих днях», алгоритм расчета будет использовать шестидневку, что исказит остаток.
2. Территориальные условия в позиции штатного расписания. Если используется штатное расписание, проверим, прописаны ли там северные надбавки и территориальные условия. Если программа видит в настройках позиции «24 дня северного отпуска», она будет начислять их автоматически, даже если вы пытаетесь обнулить остаток вручную.
3. Проверка регистров. Посмотрим на содержимое регистра накопления ОстаткиОтпусков. Мы можем использовать следующий алгоритм для понимания картины:
// Пример логики анализа регистра для программиста
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ОстаткиОтпусков.Сотрудник,
| ОстаткиОтпусков.ВидЕжегодногоОтпуска,
| ОстаткиОтпусков.Количество,
| ОстаткиОтпусков.РабочийГодС,
| ОстаткиОтпусков.РабочийГодПо
|ИЗ
| РегистрНакопления.ОстаткиОтпусков КАК ОстаткиОтпусков
|ГДЕ
| ОстаткиОтпусков.Сотрудник = &Сотрудник";
Если в результате запроса мы видим, что за один и тот же период числятся разные виды отпуска (например, «Северный» и «Доп. отпуск за РКС»), то проблему нужно решать через удаление лишних записей в документах переноса данных или через полную замену прав документом ввода остатков.
Подведем итог нашему исследованию. Расхождения в северных отпусках при переходе из 2.5 в 3.1 — это следствие изменения методологии учета и более строгих проверок периодов стажа в новой платформе.
Для исправления ошибок мы рекомендуем:
ВводОстатковОтпусков на дату начала корректного учета.РабочегоГода в документах ввода остатков, чтобы избежать автоматических «доначислений» за прошлые периоды.Помните, что механическое исправление цифры в документе без понимания того, какой рабочий год «закрывает» программа, даст лишь временный эффект. Только синхронизация рабочих периодов между старой и новой базами позволит добиться идеального совпадения остатков.