При разработке отчетов на базе Системы компоновки данных (СКД) программисты часто сталкиваются с ситуацией, когда данные в строках отчета выглядят абсолютно корректно и совпадают с типовой Оборотно-сальдовой ведомостью (ОСВ), но Общий итог в подвале отчета выдает странные, заниженные или просто неверные цифры. Особенно остро эта проблема проявляется при работе с виртуальными таблицами остатков и оборотов бухгалтерских регистров.
В этой статье мы подробно разберем, почему стандартное суммирование в СКД не подходит для бухгалтерского учета, и научимся настраивать схему компоновки так, чтобы ваши отчеты всегда сходились с данными учетной системы, как это реализовано в продвинутом отчете ОСВ++.
Рассмотрим типичный запрос к виртуальной таблице РегистрБухгалтерии.Хозрасчетный.ОстаткиИОбороты, который часто используется в качестве основы для простых отчетов, или изучим готовый пример отчета по оборотам счета на СКД:
ВЫБРАТЬ
ОстаткиИОбороты.Счет КАК Счет,
ОстаткиИОбороты.СуммаНачальныйОстатокДт КАК БУНачальныйОстатокДт,
ОстаткиИОбороты.СуммаНачальныйОстатокКт КАК БУНачальныйОстатокКт,
ОстаткиИОбороты.СуммаОборотДт КАК БУОборотДт,
ОстаткиИОбороты.СуммаОборотКт КАК БУОборотКт,
ОстаткиИОбороты.СуммаКонечныйОстатокДт КАК БУКонечныйОстатокДт,
ОстаткиИОбороты.СуммаКонечныйОстатокКт КАК БУКонечныйОстатокКт
ИЗ
РегистрБухгалтерии.Хозрасчетный.ОстаткиИОбороты(&НачалоПериода, &КонецПериода, , , , , ) КАК ОстаткиИОбороты
На первый взгляд, запрос составлен верно. Мы выбираем счета и соответствующие им суммы остатков и оборотов. Однако при выводе такого отчета в СКД "из коробки" система воспринимает поля БУНачальныйОстатокДт и БУНачальныйОстатокКт как независимые числовые ресурсы. В итоге в строке Общий итог СКД просто складывает все дебетовые остатки и все кредитовые остатки. С точки зрения математики — это верно, но с точки зрения бухгалтерского учета — нет.
Главная причина расхождений кроется в развернутом сальдо. В бухгалтерском учете существуют активно-пассивные счета (например, 60 "Расчеты с поставщиками" или 62 "Расчеты с покупателями"). На таких счетах остаток может быть одновременно и в дебете, и в кредите (в разрезе контрагентов или договоров).
Проанализируем ситуацию: если СКД не знает, что Дебет и Кредит — это две стороны одного и того же показателя (Остатка), она произведет "взаимозачет" или, наоборот, простое суммирование без учета иерархии счетов. Для получения корректного итога, как в ОСВ, система должна понимать структуру регистра бухгалтерии.
Чтобы решить проблему, нам необходимо вручную настроить метаданные полей в наборе данных СКД. Это делается на закладке "Набор данных" в колонке "Роль". Рассмотрим алгоритм действий для настройки полей начального остатка:
БУНачальныйОстатокДт. Нажмите на кнопку выбора в колонке "Роль".НачальныйОстаток. Это критически важно — именно по этому имени СКД поймет, что поля связаны.Счет из вашего запроса. Это свяжет сумму с конкретным счетом и его признаком активности/пассивности.БУНачальныйОстатокКт: укажите то же имя группы НачальныйОстаток, но тип установите "Кредит".Повторите эти же действия для конечных остатков (используя другое имя группы, например, КонечныйОстаток).
После того как роли распределены, перейдем на закладку "Ресурсы". Проанализируем, как теперь будут рассчитываться итоги, включая расчет нарастающего итога и дельты. Для полей остатков мы по-прежнему используем стандартную функцию Сумма():
Сумма(БУНачальныйОстатокДт)
Сумма(БУНачальныйОстатокКт)
Важный нюанс: благодаря настроенным ролям, СКД изменит алгоритм расчета этой суммы. Теперь при расчете итогов по группировкам или общих итогов система будет не просто складывать цифры, а выполнять операцию "Свертки сальдо" с учетом аналитики и иерархии планов счетов. Если на уровне счета 60 по субсчетам есть и дебет, и кредит, СКД выведет их развернуто, если это предусмотрено настройками, либо корректно "схлопнет" на итоговом уровне, не теряя при этом бухгалтерский смысл.
Часто ошибки в итогах возникают из-за неправильной фильтрации данных. Разберем ситуацию: если вы накладываете условие на счета в секции ГДЕ основного запроса, вы рискуете получить неверные итоги по иерархии. Проанализируем правильный подход:
Фильтры по счетам, организациям и подразделениям старайтесь передавать напрямую в параметры виртуальной таблицы, что критически важно для отчетов по остаткам и оборотам в разрезе месяцев. Это не только ускорит работу отчета, но и позволит механизму СКД правильно инициализировать начальные значения для расчета итогов.
// Пример передачи условий в параметры таблицы
РегистрБухгалтерии.Хозрасчетный.ОстаткиИОбороты(
&НачалоПериода,
&КонецПериода,
Период,
,
Счет В ИЕРАРХИИ (&СписокСчетов), // Условие здесь!
,
Организация = &Организация
)
Многие разработчики полагаются на то, что СКД сама определяет роли полей. Однако при использовании сложных запросов, объединений (UNION) или вложенных запросов автоматическое определение может давать сбой. Выясним причину: СКД анализирует только простые конструкции. Как только в запросе появляется дополнительная логика или переименование полей, связь с объектом метаданных "Регистр" может потеряться.
Практический совет: всегда проверяйте роли вручную, если ваш отчет строится на базе бухгалтерских остатков. Это "золотое правило" разработки на СКД.
Подводя итог нашему разбору, выделим три главных фактора корректных итогов в бухгалтерском отчете:
Счет.Выполнив эти настройки, вы заметите, что Общий итог вашего отчета стал полностью соответствовать типовой ОСВ, а "дикие цифры" и странные минусы исчезли. Теперь ваш отчет пригоден для полноценного бухгалтерского анализа.