Как исправить ошибку деления на ноль в «1С:Комплексная автоматизация 1.1» при расчете партий в регистре «Расходы при УСН»?

← На главную

В процессе эксплуатации конфигураций «1С:Комплексная автоматизация 1.1» (КА 1.1) и «1С:Управление производственным предприятием 1.3» (УПП 1.3) на упрощенной системе налогообложения пользователи часто сталкиваются с неприятной системной ошибкой. При проведении платежных документов (например, документа Списание с расчетного счета или Платежное поручение исходящее) система внезапно аварийно завершает работу, выдавая ошибку деления на ноль. В этой статье мы подробно разберем причины этой проблемы, проанализируем, почему «быстрые» методы исправления могут навредить учету, и рассмотрим три надежных способа устранения этой ошибки.

Выясняем причину: откуда берется деление на ноль?

Для того чтобы понять природу ошибки, нам необходимо заглянуть в механизм работы партионного учета при УСН. При проведении документов реализации или отчетов комиссионера система списывает партии товаров и делает записи в регистр накопления РасходыПриУСН. Расчет себестоимости списываемых товаров часто происходит пропорционально по формуле:


К = КоличествоСписания / Строка.Количество;
НоваяСтрока.Сумма = К * НоваяСтрока.Сумма;

Из-за применения деления и последующего умножения в регистре начинают накапливаться погрешности округления. В результате на остатках регистра РасходыПриУСН по конкретной партии могут зависнуть микроскопические суммы — например, 0.001 рубля по ресурсу Сумма и -0.001 рубля по ресурсу НДС при фактически нулевом количестве товара.

Когда мы пытаемся провести оплату этой поставки исходящим платежом, программа обращается к остаткам регистра РасходыПриУСН для распределения суммы оплаты. В общем модуле НалоговыйУчетУСН выполняется расчет коэффициента распределения:

КоэффРасчетов = СуммаСписания / (Строка.Сумма + Строка.НДС);

Если сложить наши зависшие остатки (0.001 + (-0.001)), то в знаменателе получается ровно 0. Попытка разделить сумму платежа на этот ноль и приводит к аварийному завершению проведения документа.

Почему увеличение разрядности ресурса — плохое решение?

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

Перенос проблемы: Мы не устраняем саму ошибку округления, а лишь отодвигаем ее появление на более поздний срок или на другие документы. Рано или поздно дробные части снова накопятся и дадут в сумме ноль.
Расходхождение с бухучетом: В бухгалтерском учете все расчеты жестко ведутся с точностью до двух знаков после запятой (до копеек). Наличие тысячных долей копеек в налоговом регистре неизбежно приведет к тому, что КУДиР (Книга учета доходов и расходов) и регламентированная отчетность перестанут сходиться с данными баланса.

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

Способ №1. Программная защита от деления на ноль (быстрый и надежный фикс)

Самый простой способ предотвратить остановку работы пользователей — внедрить в код конфигурации проверку знаменателя перед делением. Для этого нам необходимо открыть конфигуратор, найти общий модуль НалоговыйУчетУСН и локализовать строку расчета коэффициента списания.

Заменим потенциально опасную формулу на безопасный блок ветвления:


Знаменатель = Строка.Сумма + Строка.НДС;
Если Знаменатель = 0 Тогда
    КоэффРасчетов = 0; // Или 1, в зависимости от контекста закрытия остатка
Иначе
    КоэффРасчетов = СуммаСписания / Знаменатель;
КонецЕсли;

Такая доработка гарантирует, что программа никогда не выбросит критическую ошибку при проведении платежных поручений, даже если в регистре накопления присутствуют некорректные копеечные остатки.

Способ №2. Исправление логики списания партий (устранение первопричины)

Чтобы копеечные остатки вообще не появлялись в регистре РасходыПриУСН, необходимо доработать алгоритм проведения документов списания (таких как ОтчетКомиссионераОПродажах или РеализацияТоваровУслуг). Главное правило партионного учета гласит: при списании последней единицы товара из партии должна списываться вся оставшаяся сумма этой партии без остатка.

Проанализируем пример логики, которую необходимо внедрить в модули проведения:


Если СписываемоеКоличество = ОстатокКоличестваПоПартии Тогда
    // Если списываем всё количество, забираем всю сумму под ноль, игнорируя формулы пропорции
    СуммаСписания = ОстатокСуммыПоПартии;
    НДССписания   = ОстатокНДСПоПартии;
Иначе
    // Если списывается только часть партии, рассчитываем сумму пропорционально с округлением
    СуммаСписания = Округлить(СписываемоеКоличество * (ОстатокСуммыПоПартии / ОстатокКоличестваПоПартии), 2);
    НДССписания   = Округлить(СписываемоеКоличество * (ОстатокНДСПоПартии / ОстатокКоличестваПоПартии), 2);
КонецЕсли;

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

Способ №3. Очистка зависших остатков в информационной базе вручную

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

Разберем этот процесс по шагам:

Используя Универсальный отчет или написав простой запрос в Консоли запросов, сформируйте остатки по регистру накопления Расходы при УСН.
Установите фильтр: Количество = 0, а ресурсы Сумма или НДС при этом не равны 0. Это позволит локализовать все «зависшие» дробные копейки, которые мешают проведению документов.
Создайте в системе новый документ Корректировка записей регистров.
В табличную часть добавьте регистр накопления Расходы при УСН.
Заполните движения вида Расход по выявленным аналитикам (номенклатура, партия, договор) на те микросуммы, которые зависли в регистре, чтобы полностью обнулить остатки по этим позициям.

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

Резюме

Мы проанализировали проблему деления на ноль в «1С:Комплексная автоматизация 1.1» при учете расходов по УСН. Изменение разрядности метаданных в конфигураторе дает лишь иллюзию решения проблемы, в то время как правильным подходом является внедрение безопасного деления в модуле НалоговыйУчетУСН или принудительное закрытие партионных сумм в ноль при списании последней единицы запасов. Выберите наиболее подходящий для вашей компании метод доработки, чтобы обеспечить стабильную и безошибочную работу системы.