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