СКД в BAS для бухгалтера-аналитика: как создать свой отчет и не переписывать типовую конфигурацию

Начинаем не с конструктора, а с управленческого вопроса

Практический модуль: учебная база и один завершенный сценарий

Как СКД преобразует данные в отчет

Где заканчивается пользовательская настройка

Почему не стоит сразу изменять типовую конфигурацию

Проверка совместимости с конфигурацией и BAF

Как проверить отчет перед передачей пользователям

Типичные ошибки бухгалтера и консультанта

Профильное обучение: как использовать анонс практически

Чек-лист готовности отчета

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

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

Начинаем не с конструктора, а с управленческого вопроса

Фраза «сделайте отчет по продажам» для СКД слишком широка. Бухгалтер-аналитик должен разложить ее на проверяемые составляющие. Хорошее задание объясняет, кто принимает решение, какой показатель нужен, за какой период, в каких разрезах и до какого первичного документа нужно дойти при проверке.

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

• Показатели: количество, выручка, себестоимость, валовой результат.
• Аналитические разрезы: организация, склад, группа номенклатуры, номенклатура, менеджер, контрагент.
• Параметры: начало и конец периода, при необходимости организация.
• Отборы: конкретный склад, менеджер, контрагент или группа товаров.
• Расшифровка: от итога к строкам, регистратору и документу-источнику.
• Контроль: с каким типовым отчетом или регистром сверяем итог.

Последний пункт критичен. Отчет, который красиво группирует ошибочные данные, остается ошибочным. До начала разработки нужно зафиксировать контрольную сумму и объяснить, включаются ли возвраты, сторнирование, непроведенные документы, внутренние перемещения, НДС, скидки и корректировки. Эти вопросы определяют не дизайн, а экономический смысл результата.

Практический модуль: учебная база и один завершенный сценарий

Обучаться СКД лучше всего не на пустой конфигурации и не сразу на рабочей базе. Нужна копия или отдельная учебная информационная база с небольшим, но содержательным набором данных. Для упражнения достаточно условного оптового предприятия с двумя складами, тремя товарными группами, несколькими менеджерами, контрагентами, реализациями и возвратами за два месяца.

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

Подготовка данных

1. Создайте контрольный период, в котором есть обычная продажа, продажа со скидкой, возврат и документ в конце дня.
2. Проведите операции для двух складов и как минимум двух менеджеров.
3. Сформируйте типовой отчет, которому доверяет бухгалтерия, и запишите контрольные итоги.
4. Убедитесь, что пользователь видит нужные организации, склады и документы. Ограничения прав могут изменить результат запроса.
5. Сделайте резервную копию учебной базы или контрольную точку, чтобы повторить упражнение из начального состояния.

Ожидаемый результат модуля

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

Как СКД преобразует данные в отчет

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

1. Набор данных и запрос

Для учетного отчета источником часто становится запрос к регистру накопления, регистру бухгалтерии или нескольким связанным таблицам. Названия объектов зависят от конфигурации, поэтому приведенный ниже фрагмент следует воспринимать как логический шаблон, а не как код для прямого копирования:

ВЫБРАТЬ
    ПродажиОбороты.Номенклатура КАК Номенклатура,
    ПродажиОбороты.Склад КАК Склад,
    ПродажиОбороты.Менеджер КАК Менеджер,
    ПродажиОбороты.КоличествоОборот КАК Количество,
    ПродажиОбороты.СуммаОборот КАК Выручка,
    ПродажиОбороты.СебестоимостьОборот КАК Себестоимость
ИЗ
    РегистрНакопления.Продажи.Обороты(
        &НачалоПериода,
        &КонецПериода,
        ,
        ) КАК ПродажиОбороты

В реальной базе консультант сначала проверяет структуру метаданных и логику типовых отчетов. Если себестоимость рассчитывается другим регистром или окончательно определяется только после закрытия месяца, простое поле с условным названием «СебестоимостьОборот» не даст правильного результата. Бухгалтер здесь нужен не меньше разработчика: он определяет момент признания и правила сверки.

2. Поля, ресурсы и вычисления

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

3. Параметры и отборы

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

4. Группировки и структура

Начальный вариант должен соответствовать одному решению, а не демонстрировать все поля. Для руководителя это может быть иерархия «товарная группа → менеджер» с выручкой и валовым результатом. Для бухгалтера — «организация → склад → номенклатура» с количеством, суммой и документами. Оба варианта могут работать на одной схеме, если набор данных содержит нужные поля, а права не скрывают информацию.

5. Расшифровка

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

Где заканчивается пользовательская настройка

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

Есть полезный тест. Если запрос звучит как «покажи те же данные иначе», сначала проверяйте пользовательские настройки. Если звучит как «добавь новый источник, новый алгоритм или новое действие», это уже разработка. Между ними есть серая зона: поле может существовать в схеме, но быть намеренно скрытым из-за производительности, сложности трактовки или прав доступа.

Почему не стоит сразу изменять типовую конфигурацию

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

1. Настроить существующий типовой отчет и сохранить отдельный вариант.
2. Создать внешний отчет, если режим работы и политика безопасности это позволяют.
3. Использовать механизм расширения или другой штатный способ доработки, совместимый с конфигурацией.
4. Изменять основную конфигурацию только после оценки влияния на поддержку и обновления.

Для персонального разбора задачи полезно брать не абстрактный курс, а собственный пример с зафиксированными показателями. Страница индивидуальные конфигурации BAS описывает обучение под выбранную конфигурацию и рабочие задачи, но прямо указывает, что BAS Бухгалтерия в эту программу не входит. Поэтому перед записью следует назвать точную конфигурацию, редакцию, релиз, версию BAF и желаемый результат модуля, а для BAS Бухгалтерия — уточнить отдельную программу.

Проверка совместимости с конфигурацией и BAF

В задании без версии нельзя честно обещать, что готовый отчет будет одинаково работать везде. По состоянию на 11 сентября 2026 года правильная практика — проверять совместимость в конкретной среде, а не подставлять в материал произвольный номер релиза. Для паспорта отчета достаточно короткого чек-листа:

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

Совместимость — это не только «открывается или нет». Отчет может технически запускаться, но давать другой итог из-за изменения структуры регистра, правил проведения, прав или алгоритма себестоимости. Поэтому после обновления нужен короткий регрессионный тест на том же контрольном наборе данных.

Как проверить отчет перед передачей пользователям

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

Минимальный набор тестов

• Границы периода: документ в первый и последний день попадает в отчет ровно один раз.
• Пустой результат: отчет корректно объясняет отсутствие данных, а не зависает и не показывает старый результат.
• Возвраты и сторно: знак и влияние на выручку и количество соответствуют учетной политике.
• Группировки: сумма дочерних строк равна итогу родительской группы.
• Отборы: сочетание склада и менеджера не убирает и не дублирует чужие данные.
• Расшифровка: из итога можно объяснить каждую строку и открыть правильный документ, если переход предусмотрен.
• Права: пользователь с рабочей ролью видит только разрешенные данные, но получает понятный результат.
• Производительность: рабочий месяц и рабочий год формируются за приемлемое время без чрезмерной нагрузки.
• Сохраненный вариант: после повторного открытия не теряются нужные поля, отборы и порядок группировок.

Полезно вести короткий протокол: условия теста, ожидаемый результат, фактический результат и ссылку на контрольный документ внутри базы. Такой протокол значительно ценнее фразы «проверили — работает», особенно после обновления или переноса отчета в другую информационную базу.

Типичные ошибки бухгалтера и консультанта

Начинать со всех доступных полей

Избыточный набор полей усложняет схему, варианты и тестирование. Сначала нужен минимум, который отвечает на один бизнес-вопрос. Новый разрез добавляют только вместе с примером решения, которое он поможет принять.

Путать обороты, остатки и срез состояния

Продажи за период, остаток на дату и последнее актуальное значение — разные задачи. Неправильно выбранный источник может дать правдоподобную таблицу с ложным экономическим смыслом.

Соединять таблицы без контроля кратности

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

Выносить в пользовательские настройки все

Свобода настройки полезна, пока пользователь понимает поля и не может случайно сформировать бессмысленный итог. Базовый вариант должен быть безопасным: понятные названия, умеренное количество настроек, обязательный период и объясненные ресурсы.

Не документировать происхождение показателя

Название «Валовая прибыль» не объясняет формулу. В паспорте отчета следует записать источники, момент расчета себестоимости, отношение к возвратам и округление. Это защищает и бухгалтера, и разработчика от разных трактовок.

Профильное обучение: как использовать анонс практически

По состоянию на 11 сентября 2026 года в разделе UnionBA — новости опубликован анонс онлайн-курса «Механизм системы компоновки данных в системах автоматизации бизнеса», запланированного на 22–25 сентября 2026 года. Описание охватывает схему и наборы данных, настройки, связи, работу со встроенным языком, собственные формы и расшифровку. Для бухгалтера-аналитика это хороший ориентир уровней: от понимания структуры отчета до тем, где без технической подготовки уже не обойтись.

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

Чек-лист готовности отчета

• Отчет отвечает на сформулированный бизнес-вопрос, а не просто показывает доступные данные.
• Экономический смысл каждого ресурса согласован с бухгалтером.
• Источники и названия полей проверены именно в этой конфигурации и на этом релизе.
• Есть контрольный период и зафиксированная сумма для сверки.
• Начальный вариант понятен без перенастройки.
• Пользователю открыты только нужные поля, отборы и группировки.
• Расшифровка объясняет итог до документов в пределах прав.
• Возвраты, сторно, пустой результат и границы периода протестированы.
• Измерено время формирования на реальном объеме данных.
• Выбран способ подключения, который не создает лишних проблем при обновлении.
• Записана совместимость с конфигурацией и BAF и определен повторный тест после обновления.

Для бухгалтера-аналитика СКД — это не попытка стать программистом за один вечер. Это способ точнее формулировать требования, самостоятельно управлять разрешенными вариантами отчета и проверять результат языком учета. Для BAS-консультанта — возможность вынести стабильную логику в схему и оставить пользователю безопасную гибкость. Лучший первый проект небольшой: один вопрос, одна учебная база, один контрольный итог и понятная расшифровка. Именно с такого модуля начинается отчет, которому доверяют и бухгалтерия, и руководитель.