В практике работы с конфигурацией «Управление производственным предприятием» (УПП) бухгалтеры и расчетчики часто сталкиваются с ситуацией, когда после очередного обновления системы привычные алгоритмы начинают вести себя иначе. Одной из таких массовых проблем стало появление копеек в колонке Результат документа НачислениеЗарплатыРаботникамОрганизаций, хотя ранее расчет всегда производился в целых рублях. В рамках этой статьи мы подробно разберем причины этой ситуации, проанализируем конкретные релизы, вызвавшие сбой, и рассмотрим способы возврата к корректному учету.
Проанализируем ситуацию: если в вашей информационной базе расчет зарплаты годами велся без копеек, а начиная с определенного месяца (например, с февраля) в документах начисления стали появляться дробные значения, в первую очередь необходимо проверить версию конфигурации. Как показывает практика и обсуждения в профессиональном сообществе, данная проблема локализована в релизах 1.3.154.1 и 1.3.154.2.
Разберем, почему это произошло. В указанных версиях разработчики внесли изменения в глобальные модули, отвечающие за расчет начислений (в частности, изменения затронули общий модуль ПроцедурыРасчетаЗарплаты). Целью изменений было повышение точности расчетов для обеспечения корректного исчисления НДФЛ и страховых взносов, так как даже расхождение в одну копейку в начислении может привести к ошибкам в налоговой отчетности при больших оборотах. Однако это привело к тому, что стандартные механизмы округления, заложенные в настройках программы, перестали срабатывать должным образом.
Прежде чем приступать к программным исправлениям, проверим стандартные настройки системы. Рассмотрим по шагам, где устанавливаются правила округления:
В «проблемных» релизах пользователи отмечали, что даже при установленном флажке система игнорировала это требование для определенных видов расчетов, таких как «Оклад по дням» или «Оклад по часам». Это связано с тем, что в программном коде приоритет был отдан точному значению, полученному в результате деления тарифной ставки на норму времени. Если результат деления получается дробным, он записывается в документ «как есть».
Наиболее правильным и безопасным способом решения является обновление конфигурации до актуального релиза. Рассмотрим хронологию исправлений:
Компания 1С признала наличие программной ошибки в ветке 1.3.154. В последующем релизе 1.3.155.1 и выше работа флага округления была стабилизирована. После обновления системы рекомендуется выполнить следующие действия:
НачислениеЗарплатыРаботникамОрганизаций за проблемный период.Если оперативное обновление конфигурации невозможно, проанализируем ситуацию с точки зрения настроек видов расчета. Мы можем принудительно заставить систему округлять результат, изменив формулу начисления. Рассмотрим это на примере начисления «Оклад по дням».
Разберем последовательность действий:
Окр().Например, если типовая формула выглядит так:
Результат = ТарифнаяСтавка / НормаВремениВДнях * ВремяВДнях
Мы можем изменить ее на следующую, чтобы гарантировать отсутствие копеек:
Результат = Окр(ТарифнаяСтавка / НормаВремениВДнях * ВремяВДнях, 0)
Важный момент: использование функции Окр(Значение, 0) округляет число до ближайшего целого. Это позволит избавиться от копеек в колонке Результат даже в тех релизах, где системный флаг не работает.
Проанализируем риски. Принудительное округление начислений до целых рублей напрямую влияет на расчет НДФЛ. В системе 1С НДФЛ рассчитывается нарастающим итогом с начала года по каждому сотруднику. Если мы убираем копейки из начислений, база для налогообложения меняется.
Рассмотрим пример: если за месяц сотруднику начислено 50000.45 руб., НДФЛ составит 6500 руб. (так как копейки налога всегда округляются по правилам НК РФ). Если мы округлим начисление до 50000.00 руб., НДФЛ останется тем же, но в регистрах учета возникнет микроскопическое расхождение между начисленной суммой и базой налога. В масштабах предприятия это может привести к необходимости ручных корректировок в отчетах 6-НДФЛ. Поэтому перед массовым пересчетом документов за прошлые периоды обязательно проконсультируйтесь с главным бухгалтером.
Часто копейки «вылетают» не сразу после обновления, а после группового перепроведения документов или изменения настроек отражения зарплаты в регламентированном учете. Посмотрим на пример: вы изменили способы отражения в справочнике СпособыОтраженияЗарплатыВРеглУчете и решили перепровести документы за январь и февраль. В этот момент система заново обращается к программным модулям расчета. Если на момент перепроведения у вас установлен «бажный» релиз 1.3.154.2, то даже в старых, ранее «ровных» документах, могут появиться копейки.
Чтобы этого избежать, при необходимости перепроведения старых периодов на новых релизах, следует использовать обработку «Групповое перепроведение документов» без режима пересчета результатов, если это позволяют задачи учета. Если же пересчет необходим, то единственным верным путем будет предварительное исправление кода модуля или использование расширения конфигурации (если ваша версия платформы поддерживает работу с расширениями для обычных форм).
Подводя итог, можно сказать, что ситуация с копейками в УПП — это классический пример того, как изменение в одном модуле (точность расчетов) влияет на всю цепочку формирования данных. Для исправления ситуации мы рекомендуем:
Окр().Своевременный анализ релизов и понимание внутренней логики работы механизмов 1С:УПП позволяют эффективно решать подобные задачи, сохраняя спокойствие бухгалтерии и точность управленческого учета.