Как исправить ведомости на выплату зарплаты в 1С:ЗУП 3.1, если в них разъехались суммы и периоды?

Программист 1С v8.3 (Управляемые формы) 1С:Зарплата и Управление Персоналом Бухгалтерский учет IT и автоматизация бизнеса
← На главную

В процессе работы с программой 1С:Зарплата и управление персоналом (редакция 3.1) многие пользователи и разработчики сталкиваются с ситуацией, когда при автоматическом заполнении ведомостей на выплату зарплаты начинается хаос. В ведомости подтягиваются некорректные суммы, непонятные прошлые периоды, а при детальном анализе сумм («проваливании» в расшифровку) обнаруживается множество строк со знаками «плюс» и «минус» за разные месяцы.

Такая ситуация обычно возникает, когда бухгалтеры вручную корректируют суммы к выплате непосредственно в ведомостях, не заботясь о том, чтобы эти изменения соответствовали начисленным суммам в разрезе месяцев, подразделений, статей расходов и документов-оснований. В результате в регистрах накопления образуется пересортица. Перепроводить весь прошлый период за несколько лет — задача практически невыполнимая и опасная, так как это может повлечь за собой искажение сданной отчетности по НДФЛ и страховым взносам. Рассмотрим детально, как локализовать и исправить эту проблему наиболее эффективными методами.

Почему возникает хаос во взаиморасчетах в 1С:ЗУП 3.1?

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

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

Для решения проблемы нам необходимо проанализировать и скорректировать три ключевых регистра накопления:

  1. ЗарплатаКВыплате — этот регистр напрямую отвечает за заполнение ведомостей. Если в нем зависают остатки, автозаполнение ведомостей будет работать некорректно.
  2. ВзаиморасчетыССотрудниками — регистр, данные которого выводятся в расчетные листки сотрудников и аналитические отчеты по зарплате.
  3. БухгалтерскиеВзаиморасчетыССотрудниками — регистр, отвечающий за отражение расчетов в бухгалтерском учете и проводки.

Проанализируем пошагово три основных способа исправления сложившейся ситуации без тотального перепроведения документов прошлых периодов.

Способ №1: Схлопывание аналитики с помощью «технических» нулевых ведомостей

Этот метод является самым простым, безопасным и не требует программирования или использования сложных инструментов корректировки регистров. Он идеально подходит, если сальдо по сотруднику в целом верное (то есть реального долга перед ним нет), но внутри программы висит куча «плюсов» и «минусов» по разным месяцам и документам-основаниям.

Разберем алгоритм действий по шагам:

  1. Создадим новую ведомость (в банк или кассу — в зависимости от того, как обычно выплачивается зарплата) текущей датой. Рекомендуется делать это последним числом месяца, предшествующего месяцу начала «чистого» учета.
  2. В поле «Месяц выплаты» укажем текущий месяц, в котором мы производим исправление.
  3. Нажмем кнопку «Подобрать» и выберем проблемных сотрудников, у которых в ведомостях разъезжаются суммы.
  4. Если итоговое сальдо по сотруднику равно нулю, в ведомости его общая сумма к выплате заполнится как 0 (или будет пустой). Однако, если мы дважды кликнем по колонке «К выплате» (или нажмем кнопку «Изменить зарплату»), откроется детальное окно расшифровки платежа.
  5. В открывшемся окне мы увидим множество строк с положительными и отрицательными суммами за разные прошлые месяцы и по разным документам-основаниям. Важно: ни в коем случае не удаляем эти строки вручную! Программа сама подобрала их так, чтобы они в сумме дали ноль.
  6. Проведем созданную ведомость.

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

Способ №2: Принудительное обнуление регистров через документ «Перенос данных»

Если ручных правок за прошлые периоды было слишком много, и «технические» ведомости не помогают или приводят к ошибкам расчета НДФЛ, лучшим решением будет принудительное закрытие регистров на определенную дату (например, на начало нового отчетного года) и ввод чистых остатков.

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

  1. Перейдем в раздел Администрирование -> Переносы данных (в некоторых интерфейсах данный документ доступен через функции для технического специалиста).
  2. Создадим новый документ ПереносДанных. Дату документа установим на конец года (например, 31.12.2018), чтобы с нового года (01.01.2019) начать чистый учет. Номер документа программа присвоит автоматически.
  3. Нажмем кнопку «Настройка состава регистров» на командной панели документа.
  4. Перейдем на вкладку «Регистры накопления» и установим флажки напротив трех ключевых регистров взаиморасчетов:
    • Зарплата к выплате
    • Взаиморасчеты с сотрудниками
    • Бухгалтерские взаиморасчеты с сотрудниками
  5. После сохранения настроек в документе появятся соответствующие вкладки для каждого регистра.
  6. Для каждого проблемного сотрудника нам необходимо внести записи движений. Чтобы обнулить зависшие остатки, мы должны сделать записи с видом движения «Расход» по тем аналитикам, где висит положительный остаток, и «Приход» (или расход с отрицательным знаком) туда, где висит минус.

Поскольку ручное заполнение сотен строк в документе ПереносДанных — это колоссальный труд, для автоматизации этого процесса программисты часто используют внешние обработки с профильных ресурсов (например, Инфостарт). Такие обработки анализируют остатки по регистрам на выбранную дату и автоматически формируют документ ПереносДанных, который выравнивает все остатки строго в ноль.

Способ №3: Ввод корректного входящего сальдо

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

Для этого в системе 1С:ЗУП 3.1 предназначен специальный документ:

  1. Перейдем в раздел Выплаты -> Начальная задолженность по зарплате. Если этого пункта нет в меню, его можно включить через настройку навигации раздела.
  2. Создадим новый документ НачальнаяЗадолженностьПоЗарплате. Дату документа установим равной дате начала ведения «чистого» учета (например, 01.01.2019).
  3. Месяц взаиморасчетов укажем как месяц, предшествующий началу учета (например, Декабрь 2018).
  4. Заполним табличную часть документа реальными суммами задолженности перед сотрудниками на эту дату. Суммы должны быть взяты из проверенной бухгалтерской отчетности или оборотно-сальдовой ведомости по счету 70.
  5. Проведем документ.

Этот документ сформирует новые, абсолютно чистые и корректные остатки в регистрах ЗарплатаКВыплате, ВзаиморасчетыССотрудниками и БухгалтерскиеВзаиморасчетыССотрудниками без привязки к старым ошибочным документам-основаниям прошлых лет. Теперь при заполнении первой ведомости в новом периоде программа подтянет именно эти правильные остатки.

Важный нюанс: Очистка регистра сведений «Пересчет зарплаты»

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

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

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

Внимание! Контроль учета НДФЛ при корректировках

В программе 1С:ЗУП 3.1 учет выплаты зарплаты и учет НДФЛ связаны неразрывно. В момент проведения ведомости на выплату зарплаты происходит фактическое удержание налога. Если бухгалтеры месяцами правили суммы в ведомостях вручную, то регистры учета НДФЛ (такие как РасчетыНалогоплательщиковСБюджетомПоНДФЛ и РасчетыНалоговыхАгентовСБюджетомПоНДФЛ) также пришли в негодность. Это гарантированно приведет к ошибкам при заполнении регламентированного отчета 6-НДФЛ.

При обнулении или корректировке зарплатных регистров обязательно проконтролируйте состояние учета по НДФЛ:

Заключение и организационные выводы

Мы подробно разобрали технические методы исправления пересортицы во взаиморасчетах. Однако важно понимать: если расчетная служба организации продолжит бесконтрольно править суммы выплат в ведомостях вручную, описанный хаос вернется уже через 2–3 месяца.

Главное правило работы в 1С:ЗУП 3.1: любые отклонения, удержания, частичные выплаты или переплаты должны регистрироваться исключительно специализированными расчетными документами (НачислениеЗарплатыИВзносов, РазовоеНачисление, УдержаниеДобровольныхВзносов и т.д.). Ручные правки непосредственно в ведомостях допускаются только в самых крайних случаях и должны быть жестко контролируемы в разрезе аналитики расшифровки платежа.

← На главную