При переносе данных между идентичными конфигурациями 1С:Зарплата и Управление Персоналом 3.1 часто возникают ситуации, когда документ Ведомость после загрузки отображается некорректно: система разбивает одну выплату на несколько строк с положительными и отрицательными суммами. Давайте разберем, почему это происходит и как правильно организовать перенос данных, чтобы избежать подобных ошибок.
Первое, что необходимо усвоить — Ведомость в ЗУП 3.1 является сложным расчетным документом, работа которого тесно связана с регистрами накопления. В отличие от простых документов, ведомость имеет специфическую структуру табличных частей, где данные взаимосвязаны:
Состав — содержит список физлиц и, что самое важное, уникальный идентификатор строки для каждого участника.Зарплата — содержит детализацию выплат (суммы, документы-основания) с привязкой к идентификатору строки из ТЧ Состав.НДФЛ — содержит информацию об исчисленном и удержанном налоге.Ошибки возникают именно в момент нарушения логической связи между этими табличными частями. Если при загрузке документа идентификаторы генерируются случайным образом или не совпадают между ТЧ, программа «теряет» связь между человеком и его начислениями, пытаясь при проведении компенсировать «потерянные» данные автоматическими проводками.
Когда вы видите в ведомости строки вида -10 000 и +30 000, это означает, что система пытается провести корректировку взаиморасчетов. Если данные в регистрах Зарплата к выплате не соответствуют тому, что загружено в документ, программа выполняет сторнирование и начисление заново. Рассмотрим ключевые факторы:
Идентификатор строки (тип УникальныйИдентификатор) в ТЧ Зарплата не совпадает с таковым в ТЧ Состав, система не может сопоставить выплату конкретному сотруднику корректно.Начисление зарплаты и взносов не перенеслись или указаны неверно, программа не понимает природу выплаты (аванс это или расчет за месяц) и пытается «выровнять» сальдо сотрудника, создавая виртуальные корректировки.Зарплата к выплате и Взаиморасчеты с сотрудниками остались пустыми, программа будет «додумывать» состояние взаиморасчетов, что приводит к непредсказуемому поведению при проведении.Для корректного переноса данных рекомендуем придерживаться следующей последовательности действий:
Состав, получайте значения идентификаторов, а затем используйте эти же УникальныйИдентификатор при заполнении ТЧ Зарплата.Посмотрим на пример логики формирования структуры документа:
// Пример логики привязки идентификаторов
Для Каждого СтрСостав Из Источник.Состав Цикл
НоваяСтрока = Ведомость.Состав.Добавить();
ЗаполнитьЗначенияСвойств(НоваяСтрока, СтрСостав);
Идентификатор = НоваяСтрока.ИдентификаторСтроки; // Получаем GUID
// В ТЧ Зарплата обязательно используем этот же GUID
СтрокаЗарплаты = Ведомость.Зарплата.Добавить();
СтрокаЗарплаты.ИдентификаторСтроки = Идентификатор;
СтрокаЗарплаты.Сумма = ИсходнаяСумма;
СтрокаЗарплаты.ДокументОснование = СсылкаНаНачисление;
КонецЦикла;
Даже если отчеты выглядят корректно, наличие отрицательных сумм в ведомости является критической ошибкой. В будущем это приведет к следующим проблемам:
ЗУП 3.1 не позволяет проводить ведомости с отрицательными суммами к выплате.Расчеты налогоплательщиков с бюджетом по НДФЛ. Некорректная структура строк приведет к ошибкам в удержании налога и, как следствие, к проблемам в регламентированной отчетности.Подводя итог: всегда стремитесь к тому, чтобы цепочка документов переносилась целостно, включая регистры, а идентификаторы строк были идентичны в обеих табличных частях документа. Если проблема уже возникла, единственным верным решением будет удаление некорректных ведомостей и их повторная загрузка с соблюдением описанных правил связки данных.