СКД у 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-консультанта — можливість винести стабільну логіку в схему та залишити користувачеві безпечну гнучкість. Найкращий перший проєкт невеликий: одне запитання, одна навчальна база, один контрольний підсумок і зрозуміле розшифрування. Саме з такого модуля починається звіт, якому довіряють і бухгалтерія, і керівник.