При разработке или использовании внешних отчетов для анализа продаж в конфигурации 1С:Бухгалтерия предприятия 8.2 (редакция 2.0) пользователи часто сталкиваются с критической ошибкой: отчет некорректно суммирует себестоимость, если товар списывается из разных партий. Вместо того чтобы рассчитать средневзвешенную цену или просто просуммировать реальную себестоимость каждой единицы, система выдает фантастические цифры, которые делают расчет валовой прибыли бессмысленным.
В этой статье мы подробно разберем, почему возникает эта математическая аномалия, проанализируем структуру запроса к регистру бухгалтерии и выясним, как правильно настроить систему компоновки данных (СКД), чтобы итоги в отчете «бились» с реальностью.
Рассмотрим классическую ситуацию, описанную пользователем. Имеется товар, поступивший двумя партиями:
При реализации всех 90 штук правильная себестоимость должна составить: (30 * 17,85) + (60 * 17,31) = 1574,1. Однако отчет выдает сумму 3164,4. Проанализируем логику ошибки: отчет берет цену первой партии (17,85), прибавляет цену второй партии (17,31), получает 35,16 и умножает это число на общее количество (90). Результат — завышенная в два раза себестоимость и колоссальный убыток в документах, где на самом деле есть прибыль.
Выясним причину. Проблема кроется в двух аспектах: неправильный выбор таблицы в запросе и ошибка настройки ресурсов в СКД.
В исходном отчете используется таблица РегистрБухгалтерии.Хозрасчетный.ДвиженияССубконто. Это детальная таблица записей, которая выгружает каждую проводку отдельно. Использование этой таблицы для анализа продаж в 1С:БП 2.0 является избыточным и опасным.
Разберем представленный в теме запрос:
ВЫБРАТЬ
ХозрасчетныйДвиженияССубконто.Организация,
ХозрасчетныйДвиженияССубконто.Регистратор КАК Документ,
ХозрасчетныйДвиженияССубконто.СубконтоКт1 КАК Номенклатура,
ВЫБОР
КОГДА ХозрасчетныйДвиженияССубконто.КоличествоКт > 0
ТОГДА ХозрасчетныйДвиженияССубконто.Сумма / ХозрасчетныйДвиженияССубконто.КоличествоКт
ИНАЧЕ ХозрасчетныйДвиженияССубконто.Сумма
КОНЕЦ КАК ЦенаЗакупа,
ХозрасчетныйДвиженияССубконто.КоличествоКт КАК КоличествоКт
ИЗ
РегистрБухгалтерии.Хозрасчетный.ДвиженияССубконто(&НачалоПериода, &КонецПериода, Организация = &Организация) КАК ХозрасчетныйДвиженияССубконто
Проанализируем этот код. Здесь вычисляется ЦенаЗакупа прямо в тексте запроса. Когда СКД группирует данные по номенклатуре в итогах, она не знает, как обрабатывать это поле. Если в ресурсах для поля ЦенаЗакупа стоит функция Сумма, то СКД просто сложит цены разных партий, что мы и видим в ошибке.
Для правильного анализа продаж в Бухгалтерии 8.2 профессионалы рекомендуют использовать виртуальную таблицу Хозрасчетный.ОборотыДтКт. Рассмотрим, почему это эффективнее:
Используя ОборотыДтКт, мы сразу получаем готовую сумму списания (себестоимость) без необходимости делить сумму на количество в каждой строке и гадать, к какой партии она относится.
Если в организации включен партионный учет (ФИФО), то на счете 41 появляется третье субконто — Партии (документы поступления). Если мы хотим видеть корректную себестоимость, нам нужно убедиться, что запрос учитывает эти разрезы. В исходном запросе автора партий нет, есть только СубконтоКт1 (Номенклатура).
Чтобы исправить ситуацию, проанализируем структуру субконто. Обычно в БП 2.0 на 41 счете:
Добавим в запрос поле СубконтоКт3, чтобы СКД могла корректно разделять записи разных партий внутри одного документа реализации.
Это самый важный этап. Даже с идеальным запросом отчет будет врать, если неправильно настроена вкладка «Ресурсы». Рассмотрим типичную ошибку: разработчик добавляет поле Цена и Количество в ресурсы с функцией Сумма. Затем он создает вычисляемое поле СебестоимостьИтого = Цена * Количество. Это в корне неверно!
Правильный подход:
Сумма (которая является себестоимостью проводки Дт 90.02 - Кт 41).Себестоимость (сумма) указываем выражение Сумма(Себестоимость).Количество указываем Сумма(Количество).ВЫБОР КОГДА Сумма(Количество) <> 0 ТОГДА Сумма(Себестоимость) / Сумма(Количество) ИНАЧЕ 0 КОНЕЦ.Только в таком случае СКД сначала сложит все суммы, затем все количества и только в самом конце (для итоговой строки) выполнит деление. Это исключит ситуацию, когда складываются цены разных партий.
Посмотрим на ситуацию из сообщения №9: автор удивляется, почему при огромной себестоимости отчет показывает прибыль. Это происходит из-за того, что в запросе не связаны данные о выручке и данные о себестоимости. Скорее всего, в отчете используется два источника данных, которые соединяются по регистратору.
Проанализируем правильную формулу валовой прибыли:
Валовая прибыль = Выручка (без НДС) - Себестоимость
В терминах бухгалтерских счетов это выглядит так:
Прибыль = (Оборот Дт 62 Кт 90.01) - (Оборот Дт 90.03 Кт 68.02) - (Оборот Дт 90.02 Кт 41)
Если ваш отчет игнорирует счет 90.03 (НДС), то данные о прибыли будут завышены на 18% или 20% в зависимости от налоговой ставки. Рекомендуем объединить все эти показатели в одном запросе, используя конструкцию ОБЪЕДИНИТЬ ВСЕ из разных виртуальных таблиц или используя левое соединение к таблице продаж по документу и номенклатуре.
Разберем, как мог бы выглядеть фрагмент правильного запроса для получения данных о себестоимости с учетом партий:
ВЫБРАТЬ
ХозрасчетныйОборотыДтКт.Организация КАК Организация,
ХозрасчетныйОборотыДтКт.Регистратор КАК Документ,
ХозрасчетныйОборотыДтКт.СубконтоКт1 КАК Номенклатура,
ХозрасчетныйОборотыДтКт.СубконтоКт3 КАК Партия,
ХозрасчетныйОборотыДтКт.КоличествоОборотКт КАК Количество,
ХозрасчетныйОборотыДтКт.СуммаОборот КАК Себестоимость
ИЗ
РегистрБухгалтерии.Хозрасчетный.ОборотыДтКт(&НачалоПериода, &КонецПериода, Авто, СчетДт = ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.СебестоимостьПродажНеОблагаемаяНДС) ИЛИ СчетДт = ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.СебестоимостьПродаж), , , , ) КАК ХозрасчетныйОборотыДтКт
В этом примере мы сразу получаем СуммаОборот. Это и есть наша себестоимость. Нам не нужно ничего делить или умножать в запросе. В настройках СКД мы просто просуммируем это поле.
Проанализировав проблему, мы можем сделать следующие выводы для исправления отчета №97700:
Сумма(), а не сложные формулы умножения цен на количество.СубконтоКт3. Если отчет сводный — убедитесь, что СКД корректно сворачивает данные, суммируя именно ресурс «Сумма».Применяя эти шаги, мы превратим некорректно работающий отчет в надежный инструмент финансового контроля, который будет показывать реальную маржинальность каждой сделки, независимо от количества партий в документе реализации.