Розмірності в Business Central: аналітика, яку читає фінансовий директор

Що таке розмірності і чому їх не варто плутати з рахунками

Коротка відповідь. Розмірність (Dimension) — це ознака, яку ви навішуєте на проводку: підрозділ, проєкт, напрямок, менеджер, склад. Замість того щоб плодити субрахунки на кшталт «631.1 Постачальники Київ» і «631.2 Постачальники Львів», ви тримаєте один рахунок і додаєте до нього розмірність «Регіон». План рахунків залишається коротким, а аналітика стає багатовимірною.

Практична різниця відчувається на другий місяць роботи. Коли керівник просить «покажи витрати по проєкту Х у розрізі підрозділів за квартал», система з розмірностями дає відповідь фільтром за півхвилини. Система з аналітикою, зашитою в номер рахунку, вимагає нового рахунку під кожну комбінацію — і через рік план рахунків розростається до кількох тисяч позицій, у яких уже ніхто не орієнтується.

Три типи розмірностей і чим вони відрізняються

Business Central розрізняє розмірності не за змістом, а за тим, наскільки швидко до них можна дістатися.

Комбінації розмірностей система зберігає як набори (Dimension Set Entries) — це означає, що додавання нової звичайної розмірності не перебудовує структуру таблиць і не вимагає простою. Дорого коштує лише зміна глобальних.

Як створити розмірність: послідовність кроків

1. Створіть саму розмірність. Пошук → Dimensions → новий рядок: код (наприклад, ПІДРОЗДІЛ) і назва. Код краще робити коротким і латиницею — він потрапляє у фільтри та вивантаження.
2. Заповніть значення. На рядку розмірності → Dimension Values. Тут задаються конкретні підрозділи, проєкти, напрямки.
3. Продумайте тип кожного значення. Крім звичайного Standard, доступні Heading, Begin-Total, End-Total і Total. Вони дозволяють згрупувати значення в ієрархію: наприклад, окремі цехи всередині групи «Виробництво», щоб у звіті бачити і деталізацію, і підсумок.
4. Призначте глобальні. General Ledger Setup → поля Global Dimension 1 Code і Global Dimension 2 Code. Це та сама точка неповернення — після проводок зміна виконується окремим інструментом і на великій базі займає час.
5. Розкладіть решту по слотах 3–8. General Ledger Setup → Shortcut Dimensions. Логіка проста: у слоти потрапляє те, що людина вводить руками щодня.

Розмірності за замовчуванням: як не покладатися на memory користувача

Найпоширеніша причина зіпсованої аналітики — не помилка налаштування, а людський фактор: менеджер забув поставити проєкт у рядку замовлення. Лікується це не інструктажем, а налаштуванням.

На картках клієнтів, постачальників, номенклатури, рахунків обліку, основних засобів і працівників є розділ Dimensions → Default Dimensions. Там задається значення, яке підставиться автоматично, і — головне — правило контролю в полі Value Posting:

Code Mandatory на рахунках витрат — найдешевший спосіб гарантувати повноту аналітики. Система просто не дасть провести документ без заповненого підрозділу, і питання дисципліни знімається саме собою.

Коли на одну проводку претендують кілька джерел за замовчуванням (клієнт каже одне, номенклатура інше), конфлікт вирішують Default Dimension Priorities — там задається, чия підказка старша.

Заборонені комбінації

Окремий механізм — Dimension Combinations. Він відповідає на питання «чи можна взагалі поєднувати ці дві розмірності в одній проводці» і має три стани: дозволено, Limited (дозволено лише перелічені пари значень) і Blocked (заборонено повністю).

Типовий сценарій: проєкт «Реконструкція складу» фізично не може належати підрозділу «Роздріб». Замість того щоб ловити такі помилки під час закриття місяця, ви забороняєте комбінацію один раз, і система відхиляє проводку в момент введення.

Де дивитися результат

• Analysis by Dimensions — зведена таблиця прямо в системі: рядки й колонки набираються з розмірностей, дані — з обраного набору аналізу. Швидкий спосіб перевірити, що аналітика взагалі заповнюється.
• Фільтри у стандартних звітах — оборотно-сальдова відомість і звіти по книгах приймають глобальні розмірності як звичайні фільтри, без доопрацювань.
• Power BI — саме тут розмірності розкриваються повністю: набори розмірностей віддаються назовні через API і стають зрізами дашборда.

Пʼять помилок, які коштують найдорожче

1. Обрати глобальні розмірності «на око». Це рішення на роки. Перед вибором випишіть десять звітів, які реально запитує керівництво, і подивіться, за якими двома ознаками вони ріжуться найчастіше.
2. Створити пʼятнадцять розмірностей «щоб було». Кожна розмірність — це поле, яке хтось має заповнювати. Незаповнена розмірність гірша за відсутню: вона створює ілюзію аналітики.
3. Використати розмірність там, де потрібен окремий довідник. Розмірність — це ознака проводки, а не сутність із власними властивостями. Якщо у «проєкту» мають бути бюджет, терміни й відповідальний — вам потрібні Jobs (проєкти), а не розмірність.
4. Не заповнити Default Dimensions на картках. Тоді повнота аналітики залежить від уважності людей — і на третій місяць вона перестає залежати від неї взагалі, бо аналітики просто немає.
5. Проєктувати розмірності після міграції даних. Історичні залишки заїдуть без аналітики, і порівнювати періоди буде неможливо. Структура розмірностей — це перше, що робиться перед перенесенням даних, а не останнє.

Якщо ви тільки плануєте перехід і ще не визначилися зі структурою аналітики — це якраз те, що ми розбираємо на безкоштовному аудиті процесів разом із обсягом впровадження.

Питання й відповіді