Многие специалисты, сопровождающие конфигурации на базе 1С:Бухгалтерия 3.0, в начале 2025 года могли столкнуться с неприятной ситуацией. При закрытии месяца за январь 2025 года программа внезапно меняет способ начисления амортизации для старых основных средств (ОС) с «По единым нормам исчисления амортизации» на «Линейный способ». Более того, часто это сопровождается единовременным списанием всей остаточной стоимости актива в расходы, хотя в декабре 2024 года всё рассчитывалось корректно.
Разберем детально, почему так происходит, проанализируем код конфигурации, вызвавший это поведение, и рассмотрим способы решения проблемы.
Ситуация выглядит следующим образом: в базе ведется учет основных средств, принятых к учету очень давно (часто до 2002 года). Для них установлен способ начисления амортизации По единым нормам амортизационных отчислений (использование ЕНАОФ). В настройках указана годовая норма в процентах (например, 2.5%).
При расчете амортизации за декабрь 2024 года (и весь 2024 год) алгоритм работает привычно: балансовая стоимость умножается на годовую норму и делится на 12 месяцев. Однако при расчете за январь 2025 года:
Пользователи при этом не вносили никаких изменений в документы, не проводили документы изменения параметров амортизации или модернизации.
Чтобы понять причину, нам необходимо заглянуть «под капот» конфигурации. В ходе обсуждения и отладки выяснилось, что разработчики 1С заложили механизм принудительного отказа от старых алгоритмов, не соответствующих ФСБУ 6/2020, начиная с определенной даты.
Виновником изменения поведения является код в общем модуле УчетОС (или аналогичном модуле, отвечающем за расчет амортизации в БУ). Давайте рассмотрим функцию, которая проверяет возможность использования алгоритмов ПБУ 6/01:
Функция СпособыАмортизацииДопускаютПрименениеАлгоритмовПБУ6(Период, Организация)
// Жесткая проверка даты!
Если Период < '2025-01-01' Тогда
// Для совместимости (сохранения поведения при повторном выполнении операций)
// система разрешает использовать старые методы до 2025 года.
Возврат Истина;
КонецЕсли;
// Если наступил 2025 год, включается строгая проверка по ФСБУ 6
Возврат Не ПрименяютсяСпособыАмортизацииФСБУ6(Период, Организация);
КонецФункции
Как мы видим, в коде присутствует явное условие: Если Период < '2025-01-01'. Это означает, что разработчики дали пользователям переходный период (2022, 2023, 2024 годы) для адаптации к ФСБУ 6/2020, но с 1 января 2025 года поддержка старых алгоритмов (включая расчет по единым нормам) отключается на уровне программного кода.
Когда программа переключается в режим строгого соответствия ФСБУ 6, способ «По единым нормам» интерпретируется как линейный, так как ФСБУ 6 требует амортизировать стоимость через срок полезного использования (СПИ).
Процесс происходит так:
Рассмотрим несколько путей решения данной ситуации, от «технического патча» до методологически верного исправления.
В некоторых версиях конфигураций существует служебная константа, которая управляет датой перехода. Проверьте наличие константы с именем, похожим на ДатаОкончанияПримененияАлгоритмовАмортизацииНаОсновеПБУ6.
Если такая константа доступна для редактирования (через «Все функции» или «Функции для технического специалиста»), попробуйте установить в ней дату 01.01.2026. Это может отсрочить применение нового алгоритма еще на год без изменения кода конфигурации.
Если вы хотите сохранить старый метод расчета и понимаете риски несоответствия методологии ФСБУ 6, можно создать расширение конфигурации. В расширении необходимо перехватить функцию СпособыАмортизацииДопускаютПрименениеАлгоритмовПБУ6 в общем модуле УчетОС.
Суть изменения заключается в сдвиге жестко прописанной даты. Рассмотрим пример кода для расширения:
&Вместо("СпособыАмортизацииДопускаютПрименениеАлгоритмовПБУ6")
Функция Расш_СпособыАмортизацииДопускаютПрименениеАлгоритмовПБУ6(Период, Организация)
// Сдвигаем дату проверки, например, на 2030 год
Если Период < '2030-01-01' Тогда
Возврат Истина;
КонецЕсли;
// Вызываем продолжение типовой логики, если нужно,
// или копируем логику функции "Не ПрименяютсяСпособыАмортизацииФСБУ6"
// Но проще вернуть результат базовой функции с измененной датой, если архитектура позволяет.
// В данном случае мы полностью перекрыли проверку даты.
Возврат ПродолжитьВызов(Период, Организация);
КонецФункции
Важно: Это решение является «костылем». Вы заставляете программу работать по устаревшим правилам, которые могут быть удалены из конфигурации в следующих обновлениях полностью.
Самым правильным подходом является приведение учета в соответствие с требованиями ФСБУ 6/2020. Стандарт требует пересмотра элементов амортизации ежегодно. Если ОС все еще эксплуатируется, значит, его срок полезного использования (СПИ) не истек, даже если нормативные 40 лет прошли.
Необходимо выполнить следующие действия:
После этого действия в январе 2025 года программа:
Проблема с амортизацией в январе 2025 года вызвана запланированным отказом 1С от поддержки устаревших методов учета (ЕНАОФ), которые противоречат современным стандартам ФСБУ 6. Хардкод даты 2025-01-01 в модуле УчетОС служит триггером этого перехода.
Хотя проблему можно решить технически, изменив код проверки даты, мы настоятельно рекомендуем воспользоваться документом Изменение элементов амортизации ОС для актуализации сроков полезного использования. Это обеспечит корректный учет и защитит от проблем при будущих обновлениях.