Групи проводок у Business Central: фундамент, який визначає всю бухгалтерію

Що станеться, якщо груп проводок не буде

Коротка відповідь. Кожен користувач системи мав би бути бухгалтером.

Уявіть: менеджер оформлює замовлення клієнту. Щоб операція потрапила в облік коректно, хтось має вирішити, на який рахунок доходу її віднести, який рахунок ПДВ застосувати, куди списати собівартість. Якщо система цього не знає, вирішувати доводиться людині — і менеджер із продажів раптом має розбиратися в плані рахунків.

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

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

Дві координати: з ким працюємо і що продаємо

Основна пара груп працює разом і поодинці не має сенсу.

Логіка проста, коли її один раз побачити. Для обліку не має значення, звуть клієнта Мельник чи Коваленко — має значення, що він з України, з ЄС або з-за меж ЄС, бо від цього залежать рахунки доходу й ставка ПДВ. Так само не має значення конкретна назва товару — має значення, це сировина, готова продукція чи послуга.

Перетин цих двох груп і дає відповідь на питання «які рахунки використати». Наприклад, комбінація «внутрішній ринок + товари» веде на один рахунок доходу, «експорт + послуги» — на інший, з іншою ставкою ПДВ.

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

Спеціальні групи: клієнти, постачальники, запаси

Крім двох головних, є групи, що відповідають за конкретні ділянки обліку. Правило запам'ятовується легко: працюєте з клієнтами — потрібні групи обліку клієнтів; працюєте з постачальниками — потрібні групи обліку постачальників. Тут система негнучка: без налаштованих груп облікувати документ просто не вийде.

Важлива деталь: групи обліку відповідають за балансові рахунки — заборгованість, запаси, гроші. А загальні бізнес- і товарні групи — за операційні: доходи, витрати, ПДВ. Плутанина між цими рівнями призводить до найзаплутаніших помилок, коли заборгованість лягає правильно, а дохід — ні.

Скільки груп насправді потрібно

Найчастіше питання звучить так: скільки груп заводити? І відповідь неочікувана — рівно стільки, скільки розрізняє ваш план рахунків.

Можна створити сто комбінацій груп. Але якщо у звіті про прибутки та збитки у вас один рахунок доходу, усі сто комбінацій приведуть операції на цей самий рахунок. Кількість груп має значення лише тоді, коли структура плану рахунків її підтримує.

Тому порядок дій правильний такий:

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

Зв'язок із розмірностями: коли що використовувати

Групи проводок і розмірності виглядають схоже — обидва механізми додають операції ознаки. Але завдання в них різні, і плутати їх дорого.

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

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

Типові помилки й чим вони обертаються

• Група під кожного контрагента. Таблиця комбінацій розростається до сотень рядків, у ній з'являються прогалини, і частина документів перестає обліковуватися.
• Групи заведені, а рахунки в комбінаціях не заповнені. Система не дасть облікувати документ, і причину помилки шукатимуть у документі, а не в налаштуванні.
• Групи не відповідають плану рахунків. Аналітика ніби є, а у звіті все зливається в одну суму.
• Зміна груп після старту експлуатації. Нові документи йдуть за новими правилами, старі лишаються за старими — звітність за період стає неоднорідною.
• Копіювання структури зі старої системи. Логіка Business Central інша, механічне перенесення дає найгірший результат із можливих.

Порядок перевірки перед запуском

Групи проводок — та ділянка, де помилку дешево виправити до старту й дуже дорого після. Тому перевірка обов'язкова й виконується на тестовому середовищі.

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

І лише коли всі чотири пункти пройдені — запускати в продуктивній базі.

Групи ПДВ: окремий рівень, який плутають найчастіше

Паралельно з загальними бізнес- і товарними групами існує окрема пара — ПДВ бізнес-група та ПДВ товарна група. Вони влаштовані за тим самим принципом перетину, але відповідають виключно за податок.

Питання, яке виникає одразу: навіщо дублювати, якщо значення схожі? Тому що вони збігаються не завжди. Клієнт може бути з внутрішнього ринку, але неплатником ПДВ. Товар може продаватися на внутрішньому ринку за ставкою 20 %, а той самий товар на експорт — за нульовою. Якби ці рівні були об'єднані, довелося б заводити комбінації під кожен виняток.

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

Приклад: як одна операція знаходить свої рахунки

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

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

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

Часті запитання