Загальні налаштування бухобліку

Бухоблік - Налаштування - Налаштування

Фіскальна локалізація

Вибір локалізації

Якщо підприємство є резидентом України, необхідно в полі «Упаковка» обрати:👉 🇺🇦 Україна — План рахунків ПСБО та зберегти налаштування.

Для використання всього функціоналу встановлених модулів Oblik ERP на компанії обов’язково має бути встановлена українська локалізація ПСБО. В іншому випадку частина функціоналу буде недоступна або працюватиме некоректно.

Що відбувається після вибору ПСБО

Після збереження система автоматично ініціалізує базову модель бухгалтерського обліку.

1. Створення базової облікової моделі

Система автоматично створює:

План рахунків (CoA)
(рахунки класів 1–9 відповідно до ПСБО: 20, 28, 36, 63, 64 тощо)
Журнали обліку
(продажі, закупки, інші операції, ПДВ)
Типові податки
(ПДВ 20% для продажу та придбання)

👉 Це означає, що система отримує базову структуру для формування бухгалтерських проводок.

2. Активація української облікової логіки

Після вибору ПСБО в системі стають доступними функціональні блоки:

ПДВ
МШП (малоцінні швидкозношувані предмети)
Податкова амортизація
Підзвітні особи

👉 Ключове: ці блоки працюють тільки з планом рахунків ПСБО.

Що це означає для обліку?

Після вибору ПСБО:

система переходить на українську модель бухгалтерського обліку
проводки формуються відповідно до ПСБО
з’являється можливість вести:
- податковий облік ПДВ
- облік МШП
- податкову амортизацію
- авансові звіти

❗Важливе обмеження

Якщо НЕ обрати ПСБО:

функціонал ПДВ буде недоступний
не працюватиме податкова амортизація
не буде логіки МШП
бухгалтерські проводки не відповідатимуть українським стандартам

👉 Така система не підходить для ведення обліку в Україні.

Стан системи після вибору

Після вибору ПСБО:

базова структура створена ✅
українська логіка активована ✅
але облік ще не повністю налаштований ⚠️

Імпорт бухобліку

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

👉 як саме буде ініціалізовано бухгалтерський облік

Це рішення визначає:

чи буде в системі історія операцій
як будуть внесені початкові дані
рівень деталізації обліку

Доступні варіанти

Критерій	Огляд вручну (Баланс на кінець року)	Імпорт (для повної історії)
Що це означає	Система запускається без історії операцій	Система веде облік з нуля
	Вносяться тільки початкові залишки	Всі операції створюються в Odoo
Що вноситься в систему	- залишки по рахунках - залишки по контрагентах - залишки по складу	- закупки - продажі - платежі - складські операції
Як виглядає облік	- немає історичних документів - немає зв’язків між операціями - облік починається з “поточного стану”	- всі документи взаємопов’язані - повний ланцюжок операцій - історія доступна
Вплив на ПДВ	- немає історичних ПН - обмежена логіка першої події	- коректна логіка ПДВ - працює перша подія
Переваги	✔ швидкий запуск ✔ мінімум даних	✔ повна прозорість ✔ точна аналітика ✔ коректний ПДВ
Обмеження	❗ немає історії ❗ обмежена аналітика ❗ складніше працювати з ПДВ	❗ довший запуск ❗ потрібні якісні дані
Коли використовувати	- перехід з іншої системи перехід з іншої системи без потреби в історії операцій - старт “з поточної дати”	- перехід з іншої системи з потребою в відтворенні відкритих операцій - новий бізнес - повна автоматизація - важлива аналітика
Рівень складності впровадження	Низький	Високий

Як це робиться на практиці

У більшості впроваджень використовується гібридний підхід.

Критерій	Практичний підхід (рекомендовано)
Суть	Часткове перенесення історії
Що вноситься	- відкриті інвойси - аванси - часткові відвантаження/оплати - залишки
Історичні документи	⚠️ тільки відкриті
Зв’язок між документами	✔ для відкритих операцій
ПДВ	✔ коректний для відкритих операцій
Перша подія	✔ відтворюється для відкритих операцій
Переваги	✔ баланс швидкості і якості ✔ коректний ПДВ ✔ достатня аналітика
Ризики	⚠️ помилки при визначенні відкритих операцій
Коли використовувати	👉 перехід з іншої системи (більшість кейсів)

Ключове застереження

Обраний варіант визначає:

структуру даних у системі
можливості аналітики
коректність роботи ПДВ

❗ Зміна цього підходу після початку роботи в системі є складною або неможливою.

Рекомендація для аналітика

Перед вибором необхідно узгодити з клієнтом:

чи потрібна історія операцій
чи важлива аналітика по періодах
чи буде використовуватись повний функціонал ПДВ
чи є можливість підготувати якісні історичні дані

Уточнення щодо переходу з іншої системи

При переході з іншої системи:

❌ НЕ рекомендується переносити:

закриті операції
історичні інвойси
старі податкові документи

✅ Рекомендується переносити:

відкриті інвойси
аванси
часткові відвантаження та оплати

➕ Додатково:

решта даних відображається як початкові залишки

Чому це важливо

Такий підхід дозволяє:

уникнути дублювання даних
забезпечити коректну роботу ПДВ
зменшити складність впровадження

Примітка: Початкові дані повинні вноситись лише після завершення всіх налаштувань системи.

Податки

Налаштування (UA / EN)

Що це означає

Як працює в системі

Наслідки для обліку

Рекомендація

Типові податки (Default Taxes)

Податки за замовчуванням для товарів

Створюєш товар
→ автоматично підставляється податок

Створюєш інвойс
→ податок береться з товару

Визначають ставку ПДВ по замовчуванню у всіх операціях

Перевірити відповідність бізнесу (20%, 7%, 0%, звільнено)

Податок на продаж (Sales Tax)

Податок для реалізації

Використовується в інвойсах продажу

Формує податкові зобов’язання

Налаштувати окремо для типів операцій

Податок на купівлю (Purchase Tax)

Податок для закупок

Використовується в рахунках постачальника

Формує податковий кредит

Перевірити відповідність реальним закупкам

Ціни (Prices)

Чи включає ціна ПДВ

Визначає, як система рахує базу і податок

Без податків:

ціна = 100
ПДВ = 20
разом = 120

З податками:

ціна = 120
база = 100
ПДВ = 20

Впливає на базу ПДВ і округлення

✅ Без податків (рекомендовано для України)

менше розбіжностей
стабільні розрахунки
краще сходиться з Medoc

Чому Ризики при "з ПДВ"

❌ копійчані різниці

❌ складні перерахунки

❌ проблеми з ПН

Метод округлення (Rounding Method)

Коли округлюється ПДВ

По рядку або по підсумку

По рядку:

База	ПДВ
33.33	6.67
33.33	6.67

→ ПДВ 6.67+6.67= 13.34

По підсумку:

66.66 × 20% = 13.33

👉 різниця = 0.01

Впливає на копійчані різниці і ПН

✅ По підсумку (Round per Tax)

Критичний нюанс

❗ зміна після запуску:

→ може змінити старі документи

Odoo не зберігає округлення як окрему бізнес-логіку, воно:
1) перераховується щоразу при відкритті документа
2) залежить від налаштувань компанії на момент відкриття документа

Періодичність повернення податку (Tax Return Periodicity)

Частота подачі декларації

Використовується у звітах

Не впливає на проводки

Для підприємств України рекомендується встановити:

періодичність — щомісяця
кінцевий термін — 20 днів після закінчення періоду

Це відповідає строкам подання декларації з ПДВ.

❗ Налаштування використовується лише для звітності та не впливає на розрахунок податку.

Журнал (Tax Returns Journal)

Журнал для ПДВ

Журнал використовується стандартною логікою Odoo для формування податкових записів.

Впливає на структуру обліку

У випадку використання кастомної реалізації ПДВ Oblik ERP не використовується.

Налаштуйте ваші рахунки податку

Перехід до списку податків і їх груп для налаштування параметрів оподаткування (зокрема ознаки ПДВ)

Відкривається список податків, де для кожного податку/групи визначається тип (ПДВ / не ПДВ), склад податку та інші параметри. На основі цих налаштувань система визначає логіку обліку податку

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

Обов’язково перевірити, що всі податки, які мають відноситись до ПДВ, мають відповідну ознаку. Виконати перевірку перед початком роботи і не змінювати без аналізу після старту

Перевірка номерів ПДВ (Verify VAT Numbers)

Дозволяє перевіряти дійсність ПДВ-номерів контрагентів через європейський сервіс VIES.

Виконується при введенні контрагента-нерезидента

Підвищує якість даних

🔹 Коли використовувати

👉 Якщо:

компанія працює з контрагентами з ЄС;
є операції з VAT-номерами (intra-community).

🔹 Коли не потрібно

👉 Якщо:

діяльність тільки в Україні;
перевірка VAT-номерів ЄС не використовується.

Нарахування касовим методом (Cash Basis)

ПДВ по оплаті

ПДВ виникає при оплаті

Змінює логіку обліку ПДВ
👉 змінюється момент виникнення ПДВ

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

Країна оподаткування (Fiscal Country)

Країна податкового обліку

Визначає правила локалізації

Впливає на податкову логіку

Україна

Податкова амортизація (Tax Fixed Assets)

Податковий облік ОЗ

Паралельно з бухгалтерським обліком

Опція активує ведення податкової амортизації основних засобів паралельно з бухгалтерською амортизацією.

Коли активувати

👉 Якщо компанія:

веде облік основних засобів;
застосовує податкову амортизацію відповідно до законодавства;
потребує:
- окремого розрахунку податкової амортизації;
- формування податкових витрат;
- контролю строків амортизації для податкових цілей.

✔ Типово для:

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

Коли НЕ активувати

👉 Якщо:

компанія не веде податкову амортизацію;
облік ведеться:
- лише в бухгалтерському контурі;
- без податкових різниць;
використання основних засобів:
- мінімальне або відсутнє;
це перший етап впровадження, і блок ОЗ ще не запускається.

✔ Типово:

ФОП;
спрощена система;
невеликі компанії без складного обліку ОЗ.

Логіка роботи при активації

При увімкненні:

в системі з’являється можливість:
- налаштовувати моделі податкової амортизації;
- вести окремий графік податкової амортизації;
амортизація:
- розраховується окремо від бухгалтерської;
- формує окремі бухгалтерські записи;
використовується лише прямолінійний метод.

Важливо

❗ Опція впливає на:

план рахунків (додаються рахунки для податкової амортизації);
поведінку модуля основних засобів;
структуру обліку витрат.

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

ПДВ

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

Рахунки за замовчуванням, що застосовуються до операцій з ПДВ

Система містить попередньо налаштований набір рахунків для обліку ПДВ відповідно до стандартної моделі. Користувач може змінити їх відповідно до облікової політики компанії.

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

Автоматичне створення документів постачальника

Призначення

Опція визначає спосіб створення податкових накладних постачальника в системі: автоматично на основі операцій або через імпорт/інтеграцію.

Коли НЕ активувати

👉 Якщо планується:

імпорт податкових накладних зі сторонніх систем (M.E.Doc, СОТА тощо);
інтеграція з сервісами обміну ПН;
використання зовнішнього джерела як єдиного джерела істини по ПН.

У цьому випадку:

податкові накладні постачальника створюються через імпорт;
дублювання документів у системі не відбувається.

Коли активувати

👉 Якщо податкові накладні постачальника не імпортуються, а формуються безпосередньо в системі.

Логіка роботи при активації

При увімкненні опції:

система автоматично створює:
- запис першої події;
- податкову накладну постачальника на основі господарських операцій (інвойсів, оплат тощо).

Далі користувачу необхідно:

Звірити автоматично створену податкову накладну з фактично отриманою від постачальника;
Заповнити у документі:
- номер податкової накладної з ЄРПН;
- дату (за потреби);
Переконатися, що суми та номенклатура відповідають первинному документу.

❗ Рекомендується використовувати лише один підхід: або автоматичне створення в системі, або імпорт/інтеграцію. Одночасне використання двох підходів може призвести до дублювання податкових документів.

Пропорційне ПДВ

Опцію слід активувати у випадках, коли підприємство здійснює як оподатковувані, так і неоподатковувані операції і необхідно розраховувати пропорційний податковий кредит.

Зверніть увагу, що в такому випадку імпорт податкових документів постачальника буде неможливим і потрібно обов’язково активувати опцію "Автоматичне створення податкових документів постачальника"

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

Податки на товар за замовчуванням, що будуть застосовуватись при внесенні авансового платежу (передоплати):

Податок на продаж - вибір податку зі сферою застосування “Продаж”, який буде використовуватися для створення записів по першій події, в разі відсутності пов’язаного документа з номенклатурою для визначення суми податку.
Податок на купівлю - вибір податку зі сферою застосування “Купівля”, який буде використовуватися для створення записів по першій події, в разі відсутності пов’язаного документа з номенклатурою для визначення суми податку.
Товар за замовчуванням - товар по замовчуванню для податкових накладних в разі відсутності пов’язаного документа з номенклатурою для визначення суми податку.

❗ Дані налаштування використовуються лише у випадках, коли система не може визначити номенклатуру для розрахунку ПДВ (наприклад, при обліку авансових платежів без прив’язки до замовлення або інвойсу).

Журнали для відображення операцій з ПДВ

Під кожен тип бухгалтерських записів в системі необхідно створити окремі журнали, в яких будуть відображені:

Податкові накладні та розрахунки-коригування до них – журнал для податкових зобов’язань;
Податкові документи постачальника (податкові накладні та розрахунки-коригування) – журнал для податкового кредиту;
Записи по першій події – журнал для першої події по ПДВ.

Користувачем повинен бути створений окремий журнал для податкових зобов’язань. Це важливо для правильної (послідовної) нумерації податкових накладних та розрахунків-коригування під час їх генерації у системі.

Строки реєстрації ПН та РК

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

На документах ПН та РК для зручності є наявне поле щодо терміну реєстрації, яке буде розраховуватись автоматично згідно заданих вище правил.

Нумерація податкових документів по податкових зобов'язань

Для автоматичної нумерації податкових документів в системі потрібно встановити період нумерації, в якому нумерація ПН/РК буде починатися з 1.

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

Користувач може обрати один з наступних періодів для автоматичної нумерації податкових документів:

Щоденно - нумерація податкових документів починається з одиниці кожного наступного дня.
Щомісячно - нумерація податкових документів починається з одиниці кожного наступного місяця.
Щорічно - нумерація податкових документів починається з одиниці кожного наступного року.

Обраний період нумерації повинен відповідати прийнятій політиці компанії та не змінюватися в процесі роботи без необхідності.

Відповідальна особа за виписку податкових накладних у компанії

Для забезпечення автоматичного заповнення поля "Посадова (уповноважена) особа" у Податковій накладній /Розрахунків коригування під час їх створення, необхідно попередньо налаштувати відповідного співробітника в системі.

У загальних налаштуваннях слід заповнити параметр: "Відповідальна особа за виписку ПН".

У цьому полі можна вибрати співробітника зі списку працівників, внесених до системи. Після збереження цього значення система автоматично підставляє його при створенні кожної нової Податкової накладної/Розрахунків коригування.

МШП

Призначення

Розділ МШП призначений для налаштування обліку малоцінних та швидкозношуваних предметів у системі.

Функціонал дозволяє:

відображати передачу МШП в експлуатацію;
автоматично формувати бухгалтерські записи;
вести кількісний облік МШП після списання (на позабалансових рахунках);
контролювати рух МШП за відповідальними особами.

Активація функціоналу

Для використання обліку МШП необхідно:

активувати чекбокс «Дозволити використовувати операції з МШП»;
зберегти налаштування.

Після активації стають доступними поля для налаштування рахунків та журналу.

Налаштування рахунків

Рахунок витрат

Визначає рахунок, на який буде списуватись вартість МШП при передачі в експлуатацію.

👉 Використовується у проводці:

Дт рахунку витрат
Кт рахунку обліку запасів

Рекомендується обирати рахунки класу:

91 — загальновиробничі витрати
92 — адміністративні витрати
93 — витрати на збут

Журнал

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

👉 Рекомендується створити окремий журнал типу:

«МШП» — для відокремлення таких операцій від інших.

Позабалансовий рахунок

Використовується для кількісного обліку МШП після їх списання на витрати.

👉 Дозволяє:

контролювати наявність МШП у відповідальних осіб;
відслідковувати залишки після передачі в експлуатацію.

Кореспондуючий рахунок

Технічний рахунок, який використовується у парі з позабалансовим рахунком для формування записів.

👉 Формується проводка:

Дт позабалансового рахунку
Кт кореспондуючого рахунку

Принцип обліку МШП

Облік МШП у системі побудований за наступною логікою:

При передачі МШП в експлуатацію:
- їх вартість списується на витрати;
- МШП вибувають зі складу (кількісно).
Одночасно:
- МШП відображаються на позабалансовому рахунку;
- забезпечується подальший контроль їх використання.

Формування бухгалтерських записів

При проведенні операції введення МШП в експлуатацію система автоматично формує:

Балансові проводки:

Дт рахунку витрат
Кт рахунку обліку запасів

Позабалансові проводки:

Дт позабалансового рахунку
Кт кореспондуючого рахунку

Особливості налаштування

Налаштування виконуються окремо для кожної компанії.
Значення рахунків можуть бути змінені відповідно до облікової політики підприємства.
Обрані рахунки безпосередньо впливають на бухгалтерські записи та звітність.

Коли використовувати

Активувати функціонал МШП, якщо:

підприємство веде облік МШП окремо від запасів;
необхідно контролювати МШП після передачі в експлуатацію;
використовується позабалансовий облік.

Коли не використовувати

Не активувати, якщо:

МШП списуються одразу на витрати без подальшого контролю;
облік ведеться як для звичайних товарів;
позабалансові рахунки не використовуються.

Важливо

❗ Некоректне налаштування може призвести до:

неправильного відображення витрат;
відсутності контролю за МШП після списання;
помилок у бухгалтерській та управлінській звітності.

Підзвітні особи

Призначення

Розділ Підзвітні особи призначений для налаштування обліку розрахунків з підзвітними особами у системі.

Функціонал дозволяє:

обліковувати видачу коштів під звіт;
формувати авансові звіти;
відображати витрати підзвітних осіб;
контролювати використання виданих коштів;
розділяти підтверджені та непідтверджені витрати.

Активація функціоналу

Функціонал доступний за замовчуванням у локалізації.

Для коректної роботи необхідно:

перевірити налаштування рахунків;
визначити журнал для обліку авансових звітів;
зберегти налаштування.

Налаштування рахунків

Налаштування	Що означає та як працює в системі	Рекомендовано використовувати
Розрахунки в національній валюті	Визначає основний рахунок обліку розрахунків з підзвітними особами в гривні. 👉 Використовується для: обліку заборгованості підзвітної особи; закриття авансових звітів.	372100 Розрахунки з підзвітними особами в національній валюті
Розрахунки в іноземній валюті	Визначає рахунок обліку розрахунків у валюті. 👉 Використовується для: валютних авансів; витрат у валюті; розрахунку курсових різниць.	372200 Розрахунки з підзвітними особами в іноземній валюті
Журнал	Визначає журнал, у якому будуть створюватись бухгалтерські записи по авансових звітах.	створити окремий журнал «Авансові звіти»
Видані аванси не відзвітовані в національній валюті	Використовується для обліку коштів, виданих підзвітній особі до моменту підтвердження витрат. 👉 Дозволяє: контролювати видані, але не закриті аванси.	372101 Розрахунки з підзвітними особами за непідтвердженими авансами в національній валюті
Витрати не підтверджені в авансовому звіті в національній валюті	Використовується для обліку витрат, які не підтверджені документами. 👉 Дозволяє: контролювати витрати, які не підтверджені документами або не включені до авансового звіту.	372102 Розрахунки з підзвітними особами за непідтвердженими витратами в національній валюті
Аванси в іноземній валюті	Використовується для обліку коштів, виданих підзвітній особі до моменту підтвердження витрат. 👉 Дозволяє: контролювати видані, але не закриті аванси.	372201 Розрахунки з підзвітними особами за непідтвердженими авансами в іноземній валюті
Витрати в іноземній валюті	Використовується для обліку витрат, які не підтверджені документами. 👉 Дозволяє: контролювати витрати, які не підтверджені документами або не включені до авансового звіту.	372202 Розрахунки з підзвітними особами за непідтвердженими витратами в іноземній валюті

Особливості налаштування

Налаштування виконуються окремо для кожної компанії
Використовуються у всіх операціях з підзвітними особами
Забезпечують розділення:
- виданих авансів
- підтверджених витрат
- непідтверджених витрат

Коли використовувати

Функціонал використовується, якщо:

є підзвітні особи;
здійснюються витрати через співробітників;
використовуються авансові звіти;
необхідний контроль за використанням коштів.

Важливо

❗ Некоректне налаштування може призвести до:

змішування авансів і витрат;
відсутності контролю за підзвітними сумами;
некоректного закриття авансових звітів;
помилок у фінансовій звітності.

Валюти

Основна валюта

Що робити:

встановити валюту компанії (для України — UAH)

Важливо:

❗ не змінювати після початку роботи

Довідник валют

Що робити:

активувати тільки ті валюти, які реально будуть використовуватись

✔ Якщо валюта активна:

курс буде оновлюватись автоматично
зберігається історія курсів

❌ Не активувати “про запас”

Автоматичне виставлення курсу валют

Вмикати / не вмикати

✔ Вмикати, якщо:

є операції в іноземній валюті
потрібні актуальні курси
є валютні розрахунки / контракти

❌ Не вмикати, якщо:

облік тільки в UAH
курси встановлюються вручну (внутрішня політика)

Послуга

✔ Обирати:

Національний банк України

(для стандартного обліку в Україні)

Інтервал

✔ Рекомендується:

Щодня

❗ Не використовувати “Вручну”, якщо включене автооновлення

Ключові рекомендації

одна компанія → одна основна валюта
автооновлення + НБУ + щодня → стандарт для України
не змішувати:
- або автоматичні курси
- або ручні

Важливо

❗ Якщо курси не оновлюються:

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

Рахунки клієнта

Налаштування	Коли вмикати	Рекомендація
Податки у валюті компанії	якщо є валютні операції	обов’язково вмикати для України
Ліміт кредиту продажів	якщо є відстрочка платежу	вмикати при роботі з дебіторкою
Заокруглення готівки	якщо є готівкові розрахунки	вмикати тільки при потребі
Snailmail	якщо використовується відправка рахунків поштою через Odoo	рекомендується вмикати
Загальна сума рахунку літерами	Загальна сума рахунку літерами	рекомендується вмикати

Особливості

Налаштування поділяються на:

облікові (впливають на ПДВ і розрахунки)
документальні (впливають на вигляд і юридичність документів)

2. Основна увага при впровадженні:

коректне відображення ПДВ
валютні операції
контроль дебіторської заборгованості

Додаткові налаштування (опціонально)

Можуть використовуватись залежно від бізнес-процесів:

Адреси клієнта
Друк (колір, двосторонній, фон)
Квитанція продажу
Типовий інкотерм
Загальні положення та умови
Уповноважена особа

Важливо

❗ Облікові налаштування мають пріоритет над візуальними.

❗ Надмірна активація опцій може ускладнити роботу користувачів без впливу на облік.

Одиниці виміру та упаковки (Units & Packagings)

Призначення

Розділ дозволяє використовувати різні одиниці виміру та варіанти упаковки для товарів у системі.
Ключове налаштування

Налаштування	Коли вмикати	Рекомендація
Одиниці виміру та упаковки	якщо товари продаються/закуповуються в різних одиницях (шт, кг, упаковки, коробки тощо)	рекомендується вмикати

Коли вмикати

✔ якщо є:

продаж в різних одиницях (наприклад: шт → коробка)
закупівля в одній одиниці, продаж в іншій
упаковки (ящик, палета, набір)

Коли можна не вмикати

❌ якщо:

всі товари використовуються тільки в одній одиниці
немає упаковок і перерахунків

Особливості

Налаштування впливає на:
- продажі
- закупівлі
- складський облік
Не впливає безпосередньо на бухгалтерські проводки

Важливо

❗ Якщо не увімкнути при потребі:

будуть обмеження в роботі з товарами
доведеться переробляти налаштування після запуску

Платежі клієнта

Призначення

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

Ключові налаштування

Налаштування	Коли вмикати	Рекомендація для стандартного кейсу (UA бухгалтерія)
Виставити рахунок на онлайн-оплату	якщо використовується онлайн-еквайринг (LiqPay, Stripe тощо)	❌ не вмикати без інтеграції
Групові платежі	якщо обробляється велика кількість платежів з одним і тим самим способом оплати. Використовується для зарплатного блоку.	⚠️ обов’язково залишити увімкненим
QR-коди	якщо використовується QR для оплат. Ця функція доступна лише для компаній у кількох європейських країнах, таких як Австрія, Бельгія, Фінляндія, Німеччина та Нідерланди.	❌ опціонально
Add QR-code link on PDF	якщо QR-код має бути у PDF рахунку	❌ не обов’язково

Особливості

Налаштування не впливають на бухгалтерські проводки
Впливають на:
- спосіб оплати
- зручність роботи користувача
Пов’язані з інтеграціями платіжних систем

Важливо

❗ Вмикати онлайн-оплату тільки при наявності:

підключеного платіжного провайдера
налаштованої інтеграції

Рахунки постачальників

Налаштування	Коли вмикати	Рекомендація
Автоматичне підтвердження рахунків	використовується при автоматичному створенні рахунків постачальника з файлів (PDF, сканів).	❌ не вмикати для обліку з ПДВ та аналітикою
Прогноз товару рахунку від постачальника	якщо використовується автоматичне розпізнавання рахунків (OCR)	❌ не обов’язково

Особливість

⚠️ Автоматичне підтвердження рахунків:

автоматично проводить рахунок без участі користувача
може призвести до помилок у ПДВ, рахунках обліку та аналітиці

Платежі постачальника

Налаштування	Коли вмикати	Рекомендація
Чеки для оплати постачальникам	якщо використовується чекова форма розрахунків	❌ не використовується
Кредитні перекази SEPA (ISO20022)	якщо компанія працює з банками ЄС (SEPA)	❌ не використовується

Функціонал розділу орієнтований на інші платіжні системи (США, ЄС) і не застосовується у стандартному впровадженні для України.

Діджиталізація

Налаштування	Коли вмикати	Рекомендація
Оцифрування документу (OCR)	якщо планується використання розпізнавання PDF/сканів	❌ не використовувати
Рахунки постачальників — Оцифровувати автоматично	якщо масово імпортуються рахунки через OCR	❌ не вмикати
Рахунки клієнта — Оцифровувати лише на вимогу	якщо інколи потрібно розпізнати документ	⚠️ можна використовувати точково
Єдиний рядок рахунку на податок	якщо потрібно агрегувати ПДВ в один рядок	❌ не використовувати

🔻 Важливе уточнення (різниця 17 vs 19)

👉 у 17:

це просто OCR (ручний запуск)

👉 у 19:

OCR + AI + автологіка

🔴 Критично для українського обліку

❗ Оцифрування може:

неправильно визначити:
- ПДВ
- рахунки
- аналітику

👉 що критично при:

першій події
формуванні ПН

🔻 По “Єдиний рядок рахунку на податку”

👉 виглядає безпечно, але:

ламає деталізацію ПДВ

немає розбивки по ставках
складніше звіряти
ризик для звітності

Рекомендація: не використовувати OCR у базовому впровадженні та залишити ручний контроль

Типові рахунки

Проведення курсових різниць

Налаштування	Коли використовується в системі	Для чого потрібно	Рекомендований рахунок
Журнал	при оплаті або переоцінці валютних операцій	щоб система окремо створювала записи курсових різниць	окремий журнал «Курсові різниці»
Прибуток	коли курс змінився у “плюс”	система покаже дохід від зміни курсу	714000 Дохід від операційної курсової різниці
Втрати	коли курс змінився у “мінус”	система покаже витрати від зміни курсу	945000 Втрати від операційної курсової різниці

Опублікувати записи курсових різниць з купівлі/продажу іноземної валюти

Налаштування	Коли використовується	Для чого потрібно	Рекомендований рахунок
Дохід від купівлі/продажу іноземної валюти	при виграші на курсі під час обміну	показати прибуток від операції з валютою	711000 Дохід від купівлі-продажу іноземної валюти
Втрати від купівлі/продажу іноземної валюти	при втраті на курсі	показати витрати	942000 Витрати на купівлю-продаж іноземної валюти
Рахунок для банківської комісії	при списанні комісії банку	облік витрат банку	920000 Адміністративні витрати
Грошові кошти в дорозі в національній валюті	при обміні валюти або складних банківських операціях	тимчасове зберігання коштів	333000 Грошові кошти в дорозі в національній валюті
Грошові кошти в дорозі в іноземній валюті	аналогічно для валюти	контроль руху валютних коштів	334000 Грошові кошти в дорозі в іноземній валюті

Банківські транзакції та оплати

Налаштування	Коли використовується	Для чого потрібно	Рекомендований рахунок
Кошти до з’ясування	при імпорті банківської виписки	тимчасове зберігання операцій до узгодження	311002 Тимчасовий банківський рахунок
Внутрішнє проведення		Використовується як проміжний рахунок для внутрішніх переказів між банківськими рахунками. Такі операції не впливають на фінансовий результат підприємства, а лише змінюють структуру грошових активів.	333001 Передача ліквідності

Записи витрат майбутніх періодів

Налаштування	Коли використовується	Для чого потрібно	Рекомендований рахунок
Журнал	при автоматичному розподілі витрат	зберігання записів	«Інші операції»
Витрати майбутніх періодів	якщо витрата відноситься на кілька періодів	щоб не списувати одразу
Згенерувати записи	при підтвердженні рахунку	автоматизація	При підтвердженні рахунку постачальника
Базується на	при налаштуванні розподілу	визначає період	Місяці

Записи доходів майбутніх періодів

Налаштування	Коли використовується	Для чого потрібно	Рекомендований рахунок
Журнал	при розподілі доходу	зберігання записів	«Інші операції»
Доходи майбутніх періодів	якщо дохід отримано наперед	щоб розподілити по періодах	690000 Доходи майбутніх періодів
Згенерувати записи	автоматично	контроль доходів	На затвердженні рахунку
Базується на	при налаштуванні розподілу	визначає період	Місяці

Знижки рядка рахунка-фактури

Налаштування	Коли використовується	Для чого потрібно	Рекомендація
Рахунки клієнта	якщо є знижки в рахунках	👉 тільки якщо бізнес хоче: бачити знижки окремо аналізувати: скільки дали знижок кому чому	Використовується для окремого обліку знижок. У більшості випадків в Україні не застосовується. Рекомендується залишити значення "той самий рахунок як і товар".
Рахунки постачальника	що є знижки в рахунках	👉 тільки якщо бізнес хоче: бачити знижки окремо аналізувати: скільки дали знижок кому чому	Використовується для окремого обліку знижок. У більшості випадків в Україні не застосовується. Рекомендується залишити значення "той самий рахунок як і товар".

Рахунки обліку товарів і послуг (Product Accounts)

Налаштування	Коли використовується	Для чого потрібно	Рекомендований рахунок
Рахунок доходів	при продажі	формування виручки	702000 Дохід від реалізації товарів
Рахунок витрат	при продажі	формування собівартості	902000 Собівартість реалізованих товарів
Рахунок авансів від покупців (Downpayment Account)	у стандартному Odoo використовується для обліку авансових інвойсів через один рахунок	У рішенні не використовується, оскільки не відповідає методології українського бухгалтерського обліку та логіці першої події.	Залишати пустим

Оцінка запасів

1. Метод обліку запасів. Є два типи оцінки запасів:

Безперервна (при закритті документів)
Періодична (при закритті періоду)

Критерій	Безперервна (при закритті документів)	Періодична (при закритті періоду)
Суть	Собівартість і вартість запасів формуються в момент кожної операції (надходження, переміщення, продаж).	Протягом періоду облік ведеться лише в кількості, а собівартість і залишки розраховуються під час закриття періоду.
Особливості	при надходженні одразу формується вартість запасів; при продажу одразу формується собівартість (COGS); фінансові звіти (Balance, P&L) актуальні в будь-який момент часу.	закупівлі відображаються на витратних рахунках; складські рухи не формують бухгалтерських проводок; наприкінці періоду виконується розрахунок: залишків, собівартості, фінансового результату.
Коли обирати	Рекомендується використовувати, якщо: потрібен контроль маржі в реальному часі; є складна логістика або виробництво; використовуються додаткові витрати (landed costs), імпорт, калькуляції; бізнес масштабується і потребує управлінської аналітики.	Рекомендується використовувати, якщо: бізнес невеликий або середній; відсутня складна складська логістика; аналіз фінрезультату виконується раз на період (місяць); важлива простота впровадження та супроводу.
Обмеження	складніші налаштування; більша кількість автоматичних проводок; критична залежність від коректності даних (ціни, рухи, дати).	відсутня собівартість у момент продажу; неможливо отримати актуальну маржу до закриття періоду; обмежені можливості управлінської аналітики.

Рекомендуємо обирати безперервну оцінку запасів (при закритті документів).

2. Періодичність оцінки:

Вручну
Щоденно
Щомісячно

3. Метод оцінки собівартості:

Standard Price (Стандартна ціна): Товари оцінюються за їх стандартною (обліковою) собівартістю, визначеною в картці товару.
First In First Out (FIFO): Товари оцінюються за припущенням, що ті, які першими надійшли на підприємство, першими й вибувають.
Average Cost (AVCO) (Середньозважена собівартість): Товари оцінюються за середньозваженою собівартістю.

4. Valuation Account (рахунок оцінки) – по замовчуванню стоїть 201000

5. Journal (Тип журналу для оцінки) - Inventory Valuation (Оцінка запасів).

Рекомендація для впровадження

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

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

Банк та готівка

Функціонал імпорту QIF використовується для завантаження банківських виписок у форматі QIF. У практиці українського обліку не застосовується, оскільки банки не використовують цей формат. Рекомендується не використовувати.

Звітні періоди

Налаштування	Коли використовується	Для чого потрібно	Рекомендація
Звітний період (Останній день)	завжди при налаштуванні системи	щоб система розуміла, де закінчується рік	✔ встановити 31 грудня
Поріг перемикача рахунків	якщо запускаєте систему не з початку року або мігруєте дані	розмежування старого і нового обліку 👉 якщо дата встановлена: ❌ рахунки до цієї дати не формують бухгалтерські проводки	⚠️ використовувати тільки при впровадженні
Звітні періоди (Fiscal Years)	якщо потрібні нестандартні фінансові роки	дозволяє використовувати періоди, відмінні від календарного року	❌ не використовувати
Динамічні звіти	при роботі зі звітністю	інтерактивна робота зі звітами: • перегляд деталізації • drill-down до проводок (клікнув → побачив з чого складається цифра) • швидкий аналіз даних	✔ залишити увімкненим

🔻 Важливо

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

Аналітика

Налаштування	Коли використовувати	Для чого потрібно	Рекомендація
Аналітичний бухоблік	якщо потрібно вести облік за проєктами, підрозділами, напрямками	деталізація доходів і витрат (не тільки по рахунках, а й по бізнес-напрямках)	✔ використовувати
Управління бюджетом	якщо ведеться планування бюджету та контроль відхилень	порівняння планових і фактичних показників	⚠️ використовувати тільки за наявності потреби
Аналіз маржі	якщо потрібно бачити маржу по товарах/послугах	розрахунок прибутковості (дохід – собівартість)	⚠️ використовувати обережно без якісного обліку запасів → дає хибні результати

Звітність

Налаштування	Коли використовувати	Для чого потрібно	Рекомендація
Restrictive Audit Trail	якщо потрібен контроль змін у проводках (аудит) 👉 Сценарій Бухгалтер: створив рахунок провів потім знайшов помилку (не той рахунок витрат)	Без Restrictive Audit Trail ✔ можна: зайти виправити перепровести 👉 стандартна робота бухгалтера З Restrictive Audit Trail ❌ не можна змінити проведений документ 👉 що доведеться робити: сторно створити новий документ	⚠️ використовувати обережно
Додати підсумки нижче розділів	при роботі зі звітами	відображає підсумки по кожному блоку звіту	✔ залишити увімкненим
Завантажте звіт перевірки незмінності даних	для аудиту або перевірки	формує звіт про незмінність даних	⚠️ не використовується у щоденній роботі
Використовувати журнал закриття фінрезультатів	при автоматизації закриття року	автоматично переносить фінрезультат (прибуток/збиток) Проблема ❗ бухгалтер: не бачить логіку не контролює процес не довіряє результату	⚠️ не використовувати

Бухоблік сторно

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

Режим бухгалтерських фірм

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