Почему при списании партии по средней стоимости в 1С рассчитывается неверная себестоимость товара?

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

Разберем детально, почему это происходит, как провести диагностику и какими способами можно восстановить правильный расчет партий.

Анализ методологических ошибок учета

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

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

Диагностика через детализацию отчетов и сверку остатков

Для выявления источника сбоя проанализируем движения товара по партиям:

1. Сформируем отчет по партиям (например, Ведомость по партиям товаров на складах), настроив группировки строк: номенклатура, склад, документ оприходования (партия), а в детальных записях — регистратор. Это позволит увидеть, с какой конкретно партии и по какой цене произошло списание.
2. Сверим физические движения с виртуальной таблицей остатков через консоль запросов. Если при суммировании всех приходов и расходов по регистру получается одна сумма, а виртуальная таблица Остатки на ту же дату выдает другую величину, имеет место нарушение целостности таблицы итогов СУБД.
3. Проверим служебный регистр Списанные товары. При наличии «зависших» некорректных записей алгоритм списания партий не может штатно сопоставить партии списания.

Устранение сбоя на уровне таблиц и итогов базы данных

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

Рассмотрим два способа решения проблемы: быстрый программный пересчет и полное тестирование базы.

Способ 1. Точечный программный пересчет итогов регистров

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

РегистрыНакопления.ПартииТоваровНаСкладах.ПересчитатьИтоги();
РегистрыНакопления.ТоварыНаСкладах.ПересчитатьИтоги();

Данный метод принудительно пересчитывает агрегаты только для указанных регистров накопления, после чего документ расхода необходимо перепровести.

Способ 2. Тестирование и исправление информационной базы

Если стандартное управление итогами не дало результата из-за разрушения физических индексов таблиц СУБД, используем комплексную утилиту конфигуратора. Выполним следующие шаги:

1. Создадим полную резервную копию информационной базы.
2. Откроем Конфигуратор и перейдем в меню Администрирование → Тестирование и исправление...
3. Установим следующие флаги:
   • Реиндексация таблиц информационной базы (перестраивает индексы таблиц СУБД);
   • Проверка логической целостности информационной базы;
   • Проверка ссылочной целостности информационной базы;
   • Пересчет итогов (заново формирует таблицы остатков регистров);
   • Реструктуризация таблиц информационной базы (принудительно пересоздает физические таблицы данных и индексы на сервере СУБД).
4. В блоке при наличии ссылочных ошибок выберем вариант Очищать ссылки.
5. Запустим процесс тестирования. На объемных базах процедура реструктуризации может занимать длительное время.

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