K2 ERP Wiki - Внесок користувача [uk]

Під гуркіт російських ракет вони захищають російську 1С

2026-07-19T06:25:52Z

[[Файл:Бухгалтер 1С.png|центр|міні|800x800пкс|Під гуркіт російських ракет вони захищають російську 1С]]

''Як коментарі під TAX Podcast показали справжній масштаб технологічної залежності України''

<div style="box-sizing:border-box; width:100%; margin:20px 0; padding:18px 22px; background:#fff1f1; border-left:6px solid #c62828; border-radius:6px; overflow-wrap:anywhere;">
'''Знову грім. Знову вибухи. Знову Київ та інші українські міста прокидаються від російських ракет. А паралельно частина українського бізнесу продовжує захищати російську технологічну платформу, ніби дванадцять років війни — це ще недостатня причина хоча б почати думати про технологічну незалежність.'''
</div>

Росія вкотре намагається знищити нашу енергетику, підприємства, будинки, життя і саме право України бути незалежною державою. А майже в той самий час під подкастом про небезпеку російського програмного забезпечення з’являються українські коментатори, які кидаються захищати 1С і BAS з такою відданістю, ніби їм за це вже нараховують премію — обов’язково через документ «Нарахування лояльності агресору».

Саме це стало для мене справжнім шоком після виходу [https://www.youtube.com/watch?v=fKgTSDcHUAo&list=PLRyc83tAN5QOOCknL2Bv_gHaz0Yzgyehe TAX Podcast про 1С, BAS, санкції та майбутнє українського бізнесу]. Тема випуску була сформульована гранично чітко: чому тисячі українських компаній досі працюють на 1С і BAS, які ризики несе така залежність, чому бізнес відкладає перехід і хто повинен брати на себе відповідальність за зміну корпоративної інформаційної системи.

'''У подкасті взагалі не було реклами K2 ERP.''' Там не проводилася презентація продукту, не демонструвалися модулі, не показувалися інтерфейси, не оголошувалися тарифи і не звучали заклики негайно щось купувати. K2 ERP згадувалася лише там, де це було природно й необхідно: як доказ того, що українські технологічні альтернативи існують і що українські розробники здатні створювати власні ERP-платформи.

Більша частина розмови була присвячена боротьбі з ворожим програмним забезпеченням, походженню 1С і BAS, санкціям, кіберризикам, відповідальності власників бізнесу та необхідності розвивати власні технології. Проте частина аудиторії вперто не захотіла чути саме це.

Замість розмови по суті почалося колективне виробництво інформаційного шуму. Хтось оголосив випуск «PR-подкастом». Хтось вирішив, що K2 ERP нібито хоче «прийти на все готове» і забрати собі ринок 1С та BAS. Хтось витягнув максимальну можливу ціну майбутньої комплектації й почав доводити, що український продукт дорогий. Інші заявили, що наведені аргументи — «не аргументи», а в студії нібито сидять люди, які не розуміють, про що говорять.

Виникло дивне відчуття, що під відео працює не група живих людей, а погано налаштований бот, якому завантажили один-єдиний сценарій: '''за будь-яку ціну не допустити розмови про російську природу 1С і BAS'''. Не відповідай на поставлене питання. Не аналізуй ризики. Не сперечайся з основною тезою. Переведи розмову на особистість спікера, знайди максимальну ціну, вимагай нескінченних доказів, оголоси все рекламою — і головна проблема потоне у болоті другорядних суперечок.

== Коли немає відповіді по суті, усе оголошують рекламою ==

Назвати подкаст рекламним — найпростіший спосіб його не слухати. Це дуже зручна інтелектуальна послуга: думати не потрібно, перевіряти сказане не потрібно, відповідати на незручні питання також не потрібно. Достатньо приклеїти ярлик «PR», після чого можна з почуттям виконаного громадянського обов’язку повернутися до російського конфігуратора.

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

Коли людина після такої розмови пише лише про «рекламу K2 ERP», це не критика подкасту. Це демонстрація того, що вона або не слухала випуск, або свідомо намагається розмити його зміст. Бо обговорювати справжню проблему незручно. Доведеться визнати, що дванадцять років війни підприємство працювало на російській технологічній основі, не створило плану переходу і тепер гарячково шукає пояснення, чому багаторічну бездіяльність потрібно вважати професійною мудрістю.

'''Оголосити розмову рекламою значно легше, ніж відповісти на просте запитання: чому під час війни ваш бізнес досі працює на російській платформі?'''

== BAS — це не споріднена технологія. BAS — це 1С ==

<div style="box-sizing:border-box; width:100%; margin:20px 0; padding:18px 22px; background:#eef6ff; border-left:6px solid #1565c0; border-radius:6px; overflow-wrap:anywhere;">
'''BAS — це 1С. Не «схожа система», не «споріднена технологія» і не нова незалежна українська платформа. Це 1С, перейменована та перефарбована для продовження роботи на українському ринку. Зміна логотипу не змінила технологічної суті продукту.'''
</div>

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

BAS не виникла як нова українська технологія, створена з нуля українськими інженерами. Вона з’явилася як спосіб продовжити використання продуктів екосистеми 1С після того, як російський бренд став токсичним, санкційним і незручним для відкритого просування на українському ринку.

Змінили напис на заставці. Перемалювали логотип. Перепакували маркетинг. Почали переконувати ринок, що це вже нібито зовсім інший продукт. Але людина, яка хоча б раз відкривала конфігуратор, працювала з метаданими, запитами, формами, документами та регістрами, чудово розуміє, що відбулося.

Один із коментаторів намагався довести, що BAS нібито стала іншою технологією, тому що в окремих функціях запитів виникли відмінності, а російська 1С за цей час «пішла вперед». Це приблизно як доводити, що автомобіль перестав бути автомобілем, тому що у новішій моделі переставили кнопку підігріву сидіння.

Відмінності між релізами, конфігураціями чи окремими функціями не змінюють технологічної природи продукту. Навпаки, саме твердження, що BAS колись відокремилася від 1С, уже визнає її походження. Далі залишається здійснити надзвичайно складну інтелектуальну операцію: скласти два і два.

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

'''BAS не стала українською технологією через зміну напису на заставці. Перейменування продукту — це не технологічне імпортозаміщення. Це лише імпортозаміщення логотипу.'''

== Перефарбована нафта, перефарбований газ і перефарбована 1С ==

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

Але походження від цього не змінюється. Нафта не стає демократичною після зміни танкера. Газ не вивчає європейські цінності під час проходження митниці. Російський бізнес не очищується від свого минулого після заміни таблички біля входу.

Так само й 1С не стала українською після того, як на її місці з’явилися три латинські літери BAS. '''Перефарбування російського продукту не робить його українським. Воно лише дозволяє користувачеві психологічно комфортніше продовжувати робити те саме.'''

Найдивовижніше, що ця операція виявилася надзвичайно успішною. Для великої частини ринку зміни логотипу було достатньо, щоб оголосити проблему вирішеною. Раніше підприємство працювало на 1С, тепер воно працює на BAS — отже, у красивій презентації російського програмного забезпечення нібито стало менше.

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

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

== Це болісно нагадує перші дні великої війни ==

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

Сьогодні майже ніхто не ризикує виходити на вулицю з російським прапором. Але коли мова заходить про російські технології, ми раптом чуємо до болю знайомі інтонації: «Не треба все політизувати», «Це просто програма», «Без неї неможливо працювати», «Альтернатив немає», «BAS уже не російська», «Не потрібно поспішати», «Спочатку доведіть, що українське не гірше».

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

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

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

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

== «K2 ERP хоче прийти на все готове» ==

Це один із найкумедніших аргументів, які з’явилися після випуску. K2 ERP нібито хоче прийти на готовий ринок і забрати клієнтів 1С та BAS.

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

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

Прийти на все готове — це прийти в обладнаний офіс, увімкнути комп’ютер і почати працювати. Українські ERP-команди приходять не в обладнаний офіс, а в технологічний музей, де кожен експонат доробляли двадцять років, документацію давно загубили, а головний зберігач музею забороняє торкатися системи, тому що «воно поки працює».

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

Якщо це називається «прийти на все готове», то можна лише уявити, як виглядає складний ринок.

== Знайти максимальну ціну — ще не означає порахувати вартість ==

<div style="box-sizing:border-box; width:100%; margin:20px 0; padding:18px 22px; background:#fff8e1; border-left:6px solid #f9a825; border-radius:6px; overflow-wrap:anywhere;">
'''Порівнювати максимальну комплектацію українського продукту з мінімальною ціною коробки BAS — це не фінансовий аналіз. Це цирковий номер із калькулятором. Справжнє порівняння повинно враховувати повну вартість володіння системою протягом кількох років.'''
</div>

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

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

Не порівнюється український продукт і з реальними західними ERP-системами, де впровадження, консалтинг, ліцензії та підтримка можуть коштувати зовсім інших грошей. Західній системі дозволено бути дорогою, бо вона західна. BAS дозволено бути дорогою, бо до неї звикли. Українська система, згідно з народною економічною доктриною, повинна бути функціональнішою за SAP, простішою за Excel і бажано коштувати дешевше за підписку на музичний сервіс.

Справжнє порівняння починається з повної вартості володіння. Скільки система коштує протягом п’яти чи десяти років? Скільки людей потрібно для її підтримки? Наскільки складно її розвивати? Які ризики вона створює? Наскільки підприємство залежить від конкретного постачальника, програміста або вузької технології? Скільки коштуватиме подальше відкладання переходу?

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

== Великі компанії, які раптом стають дуже бідними ==

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

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

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

'''Це не відсутність грошей. Це відсутність пріоритету.'''

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

== «Ніхто нікуди не поспішає» ==

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

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

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

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

== Дев’яносто п’ять відсотків залежності, яку сховали перейменуванням ==

За моєю професійною оцінкою, реальне проникнення російського програмного забезпечення в український бізнес залишається на рівні '''90–95%'''. Це не офіційна державна статистика, а оцінка, сформована на основі багаторічної роботи з підприємствами різного масштабу.

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

Формально показник міг зменшитися. Але часто не тому, що підприємства перейшли на українські чи західні платформи, а тому, що 1С перестали називати 1С. Частину того самого технологічного масиву тепер записують у статистиці як BAS, локальний продукт або окрему екосистему.

Так легко перемогти будь-яку залежність. Потрібно лише перейменувати її.

Не відмовилися від російської платформи — змінили назву. Не провели імпортозаміщення — оновили логотип. Не створили технологічної незалежності — перемістили рядок в інший розділ таблиці. Звіт зелений, презентація красива, залежність залишилася.

'''Український ринок не пішов із 1С. Він значною мірою просто перейшов із напису «1С» на напис «BAS».'''

== «Ваші аргументи — не аргументи» ==

Ще одна зручна позиція — оголосити всі наведені аргументи недостатніми. Дванадцять років війни — не аргумент. Російське походження платформи — не аргумент. Санкції — не аргумент. Кіберризики — не аргумент. Технологічна залежність — не аргумент. Необхідність розвивати українські продукти — також не аргумент.

Тоді що саме вони хочуть почути? Скільки ще має пройти років? Скільки українських міст повинні почути російські ракети, щоб питання технологічної залежності перестало здаватися передчасним? Чи потрібна персональна ракета з накладною та актом виконаних робіт, щоб керівник нарешті визнав аргумент достатньо переконливим?

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

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

І навіть після цього знайдеться вирішальний аргумент: «А от у нас є один звіт, який у BAS відкривається двома натисканнями».

== «У студії сидять не спеціалісти» ==

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

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

Досвід роботи в 1С може бути глибоким і цінним, але він не дає автоматичної монополії на розуміння всіх технологій. Знання синтаксису однієї платформи не робить людину експертом із сучасної вебархітектури, хмарних систем, розподілених середовищ, PostgreSQL, API-first підходів, мобільних клієнтів або розробки платформ швидкого створення бізнес-застосунків.

І навпаки, людина, яка створює сучасну ERP-платформу, має повне право оцінювати технологічні обмеження 1С і BAS. Особливо якщо до цього десятиліттями працювала з 1С, розробляла на ній, упроваджувала її, бачила її сильні та слабкі сторони й зрештою вирішила створити іншу технологічну основу.

'''Назвати опонента некомпетентним — це не аргумент. Це словесна ширма, за якою часто ховається страх професійних змін.'''

== Український продукт повинен бути ідеальним ще до того, як у нього почнуть вкладати ==

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

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

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

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

'''Не можна тридцять років вкладати в 1С, а потім обурюватися, що українській платформі також потрібні гроші, час і клієнти.'''

== Найстрашніше — не 1С. Найстрашніше — добровільна капітуляція мислення ==

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

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

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

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

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

== BAS — це 1С. А підміна теми — її найкращий захист ==

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

Але жодна з цих маніпуляцій не відповідає на головне запитання: '''чому український бізнес після дванадцяти років війни досі масово працює на російській технологічній платформі?'''

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

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

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

<div style="box-sizing:border-box; width:100%; margin:24px 0; padding:20px 24px; background:#eef8ef; border-left:6px solid #2e7d32; border-radius:6px; overflow-wrap:anywhere;">
'''Та вони пов’язані. Технологічна залежність — це також залежність. Російська технологія не стає українською після зміни назви. BAS — це 1С. І доки український бізнес не матиме мужності назвати речі своїми іменами, справжнього технологічного звільнення не буде.'''
</div>

== Дивіться повний випуск TAX Podcast ==

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

'''Дивитися:''' [https://www.youtube.com/watch?v=fKgTSDcHUAo&list=PLRyc83tAN5QOOCknL2Bv_gHaz0Yzgyehe 1С та BAS під санкціями: чому бізнесу вже час переходити | TAX Podcast]

[[Категорія:1С]]
[[Категорія]]
[[Категорія:Російське програмне забезпечення]]
[[Категорія:Імпортозаміщення]]
[[Категорія:Українські ERP-системи]]
[[Категорія ERP]]
[[Категорія:Технологічна незалежність України]]

Під гуркіт російських ракет вони захищають російську 1С

2026-07-19T06:25:26Z

[[Файл:Бухгалтер 1С.png|центр|міні|800x800пкс|Під гуркіт російських ракет вони захищають російську 1С]]

''Як коментарі під TAX Podcast показали справжній масштаб технологічної залежності України''

<div style="box-sizing:border-box; width:100%; margin:20px 0; padding:18px 22px; background:#fff1f1; border-left:6px solid #c62828; border-radius:6px; overflow-wrap:anywhere;">
'''Знову грім. Знову вибухи. Знову Київ та інші українські міста прокидаються від російських ракет. А паралельно частина українського бізнесу продовжує захищати російську технологічну платформу, ніби дванадцять років війни — це ще недостатня причина хоча б почати думати про технологічну незалежність.'''
</div>

Росія вкотре намагається знищити нашу енергетику, підприємства, будинки, життя і саме право України бути незалежною державою. А майже в той самий час під подкастом про небезпеку російського програмного забезпечення з’являються українські коментатори, які кидаються захищати 1С і BAS з такою відданістю, ніби їм за це вже нараховують премію — обов’язково через документ «Нарахування лояльності агресору».

Саме це стало для мене справжнім шоком після виходу [https://www.youtube.com/watch?v=fKgTSDcHUAo&list=PLRyc83tAN5QOOCknL2Bv_gHaz0Yzgyehe TAX Podcast про 1С, BAS, санкції та майбутнє українського бізнесу]. Тема випуску була сформульована гранично чітко: чому тисячі українських компаній досі працюють на 1С і BAS, які ризики несе така залежність, чому бізнес відкладає перехід і хто повинен брати на себе відповідальність за зміну корпоративної інформаційної системи.

'''У подкасті взагалі не було реклами K2 ERP.''' Там не проводилася презентація продукту, не демонструвалися модулі, не показувалися інтерфейси, не оголошувалися тарифи і не звучали заклики негайно щось купувати. K2 ERP згадувалася лише там, де це було природно й необхідно: як доказ того, що українські технологічні альтернативи існують і що українські розробники здатні створювати власні ERP-платформи.

Більша частина розмови була присвячена боротьбі з ворожим програмним забезпеченням, походженню 1С і BAS, санкціям, кіберризикам, відповідальності власників бізнесу та необхідності розвивати власні технології. Проте частина аудиторії вперто не захотіла чути саме це.

Замість розмови по суті почалося колективне виробництво інформаційного шуму. Хтось оголосив випуск «PR-подкастом». Хтось вирішив, що K2 ERP нібито хоче «прийти на все готове» і забрати собі ринок 1С та BAS. Хтось витягнув максимальну можливу ціну майбутньої комплектації й почав доводити, що український продукт дорогий. Інші заявили, що наведені аргументи — «не аргументи», а в студії нібито сидять люди, які не розуміють, про що говорять.

Виникло дивне відчуття, що під відео працює не група живих людей, а погано налаштований бот, якому завантажили один-єдиний сценарій: '''за будь-яку ціну не допустити розмови про російську природу 1С і BAS'''. Не відповідай на поставлене питання. Не аналізуй ризики. Не сперечайся з основною тезою. Переведи розмову на особистість спікера, знайди максимальну ціну, вимагай нескінченних доказів, оголоси все рекламою — і головна проблема потоне у болоті другорядних суперечок.

== Коли немає відповіді по суті, усе оголошують рекламою ==

Назвати подкаст рекламним — найпростіший спосіб його не слухати. Це дуже зручна інтелектуальна послуга: думати не потрібно, перевіряти сказане не потрібно, відповідати на незручні питання також не потрібно. Достатньо приклеїти ярлик «PR», після чого можна з почуттям виконаного громадянського обов’язку повернутися до російського конфігуратора.

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

Коли людина після такої розмови пише лише про «рекламу K2 ERP», це не критика подкасту. Це демонстрація того, що вона або не слухала випуск, або свідомо намагається розмити його зміст. Бо обговорювати справжню проблему незручно. Доведеться визнати, що дванадцять років війни підприємство працювало на російській технологічній основі, не створило плану переходу і тепер гарячково шукає пояснення, чому багаторічну бездіяльність потрібно вважати професійною мудрістю.

'''Оголосити розмову рекламою значно легше, ніж відповісти на просте запитання: чому під час війни ваш бізнес досі працює на російській платформі?'''

== BAS — це не споріднена технологія. BAS — це 1С ==

<div style="box-sizing:border-box; width:100%; margin:20px 0; padding:18px 22px; background:#eef6ff; border-left:6px solid #1565c0; border-radius:6px; overflow-wrap:anywhere;">
'''BAS — це 1С. Не «схожа система», не «споріднена технологія» і не нова незалежна українська платформа. Це 1С, перейменована та перефарбована для продовження роботи на українському ринку. Зміна логотипу не змінила технологічної суті продукту.'''
</div>

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

BAS не виникла як нова українська технологія, створена з нуля українськими інженерами. Вона з’явилася як спосіб продовжити використання продуктів екосистеми 1С після того, як російський бренд став токсичним, санкційним і незручним для відкритого просування на українському ринку.

Змінили напис на заставці. Перемалювали логотип. Перепакували маркетинг. Почали переконувати ринок, що це вже нібито зовсім інший продукт. Але людина, яка хоча б раз відкривала конфігуратор, працювала з метаданими, запитами, формами, документами та регістрами, чудово розуміє, що відбулося.

Один із коментаторів намагався довести, що BAS нібито стала іншою технологією, тому що в окремих функціях запитів виникли відмінності, а російська 1С за цей час «пішла вперед». Це приблизно як доводити, що автомобіль перестав бути автомобілем, тому що у новішій моделі переставили кнопку підігріву сидіння.

Відмінності між релізами, конфігураціями чи окремими функціями не змінюють технологічної природи продукту. Навпаки, саме твердження, що BAS колись відокремилася від 1С, уже визнає її походження. Далі залишається здійснити надзвичайно складну інтелектуальну операцію: скласти два і два.

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

'''BAS не стала українською технологією через зміну напису на заставці. Перейменування продукту — це не технологічне імпортозаміщення. Це лише імпортозаміщення логотипу.'''

== Перефарбована нафта, перефарбований газ і перефарбована 1С ==

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

Але походження від цього не змінюється. Нафта не стає демократичною після зміни танкера. Газ не вивчає європейські цінності під час проходження митниці. Російський бізнес не очищується від свого минулого після заміни таблички біля входу.

Так само й 1С не стала українською після того, як на її місці з’явилися три латинські літери BAS. '''Перефарбування російського продукту не робить його українським. Воно лише дозволяє користувачеві психологічно комфортніше продовжувати робити те саме.'''

Найдивовижніше, що ця операція виявилася надзвичайно успішною. Для великої частини ринку зміни логотипу було достатньо, щоб оголосити проблему вирішеною. Раніше підприємство працювало на 1С, тепер воно працює на BAS — отже, у красивій презентації російського програмного забезпечення нібито стало менше.

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

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

== Це болісно нагадує перші дні великої війни ==

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

Сьогодні майже ніхто не ризикує виходити на вулицю з російським прапором. Але коли мова заходить про російські технології, ми раптом чуємо до болю знайомі інтонації: «Не треба все політизувати», «Це просто програма», «Без неї неможливо працювати», «Альтернатив немає», «BAS уже не російська», «Не потрібно поспішати», «Спочатку доведіть, що українське не гірше».

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

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

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

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

== «K2 ERP хоче прийти на все готове» ==

Це один із найкумедніших аргументів, які з’явилися після випуску. K2 ERP нібито хоче прийти на готовий ринок і забрати клієнтів 1С та BAS.

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

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

Прийти на все готове — це прийти в обладнаний офіс, увімкнути комп’ютер і почати працювати. Українські ERP-команди приходять не в обладнаний офіс, а в технологічний музей, де кожен експонат доробляли двадцять років, документацію давно загубили, а головний зберігач музею забороняє торкатися системи, тому що «воно поки працює».

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

Якщо це називається «прийти на все готове», то можна лише уявити, як виглядає складний ринок.

== Знайти максимальну ціну — ще не означає порахувати вартість ==

<div style="box-sizing:border-box; width:100%; margin:20px 0; padding:18px 22px; background:#fff8e1; border-left:6px solid #f9a825; border-radius:6px; overflow-wrap:anywhere;">
'''Порівнювати максимальну комплектацію українського продукту з мінімальною ціною коробки BAS — це не фінансовий аналіз. Це цирковий номер із калькулятором. Справжнє порівняння повинно враховувати повну вартість володіння системою протягом кількох років.'''
</div>

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

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

Не порівнюється український продукт і з реальними західними ERP-системами, де впровадження, консалтинг, ліцензії та підтримка можуть коштувати зовсім інших грошей. Західній системі дозволено бути дорогою, бо вона західна. BAS дозволено бути дорогою, бо до неї звикли. Українська система, згідно з народною економічною доктриною, повинна бути функціональнішою за SAP, простішою за Excel і бажано коштувати дешевше за підписку на музичний сервіс.

Справжнє порівняння починається з повної вартості володіння. Скільки система коштує протягом п’яти чи десяти років? Скільки людей потрібно для її підтримки? Наскільки складно її розвивати? Які ризики вона створює? Наскільки підприємство залежить від конкретного постачальника, програміста або вузької технології? Скільки коштуватиме подальше відкладання переходу?

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

== Великі компанії, які раптом стають дуже бідними ==

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

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

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

'''Це не відсутність грошей. Це відсутність пріоритету.'''

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

== «Ніхто нікуди не поспішає» ==

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

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

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

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

== Дев’яносто п’ять відсотків залежності, яку сховали перейменуванням ==

За моєю професійною оцінкою, реальне проникнення російського програмного забезпечення в український бізнес залишається на рівні '''90–95%'''. Це не офіційна державна статистика, а оцінка, сформована на основі багаторічної роботи з підприємствами різного масштабу.

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

Формально показник міг зменшитися. Але часто не тому, що підприємства перейшли на українські чи західні платформи, а тому, що 1С перестали називати 1С. Частину того самого технологічного масиву тепер записують у статистиці як BAS, локальний продукт або окрему екосистему.

Так легко перемогти будь-яку залежність. Потрібно лише перейменувати її.

Не відмовилися від російської платформи — змінили назву. Не провели імпортозаміщення — оновили логотип. Не створили технологічної незалежності — перемістили рядок в інший розділ таблиці. Звіт зелений, презентація красива, залежність залишилася.

'''Український ринок не пішов із 1С. Він значною мірою просто перейшов із напису «1С» на напис «BAS».'''

== «Ваші аргументи — не аргументи» ==

Ще одна зручна позиція — оголосити всі наведені аргументи недостатніми. Дванадцять років війни — не аргумент. Російське походження платформи — не аргумент. Санкції — не аргумент. Кіберризики — не аргумент. Технологічна залежність — не аргумент. Необхідність розвивати українські продукти — також не аргумент.

Тоді що саме вони хочуть почути? Скільки ще має пройти років? Скільки українських міст повинні почути російські ракети, щоб питання технологічної залежності перестало здаватися передчасним? Чи потрібна персональна ракета з накладною та актом виконаних робіт, щоб керівник нарешті визнав аргумент достатньо переконливим?

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

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

І навіть після цього знайдеться вирішальний аргумент: «А от у нас є один звіт, який у BAS відкривається двома натисканнями».

== «У студії сидять не спеціалісти» ==

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

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

Досвід роботи в 1С може бути глибоким і цінним, але він не дає автоматичної монополії на розуміння всіх технологій. Знання синтаксису однієї платформи не робить людину експертом із сучасної вебархітектури, хмарних систем, розподілених середовищ, PostgreSQL, API-first підходів, мобільних клієнтів або розробки платформ швидкого створення бізнес-застосунків.

І навпаки, людина, яка створює сучасну ERP-платформу, має повне право оцінювати технологічні обмеження 1С і BAS. Особливо якщо до цього десятиліттями працювала з 1С, розробляла на ній, упроваджувала її, бачила її сильні та слабкі сторони й зрештою вирішила створити іншу технологічну основу.

'''Назвати опонента некомпетентним — це не аргумент. Це словесна ширма, за якою часто ховається страх професійних змін.'''

== Український продукт повинен бути ідеальним ще до того, як у нього почнуть вкладати ==

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

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

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

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

'''Не можна тридцять років вкладати в 1С, а потім обурюватися, що українській платформі також потрібні гроші, час і клієнти.'''

== Найстрашніше — не 1С. Найстрашніше — добровільна капітуляція мислення ==

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

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

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

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

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

== BAS — це 1С. А підміна теми — її найкращий захист ==

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

Але жодна з цих маніпуляцій не відповідає на головне запитання: '''чому український бізнес після дванадцяти років війни досі масово працює на російській технологічній платформі?'''

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

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

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

<div style="box-sizing:border-box; width:100%; margin:24px 0; padding:20px 24px; background:#eef8ef; border-left:6px solid #2e7d32; border-radius:6px; overflow-wrap:anywhere;">
'''Та вони пов’язані. Технологічна залежність — це також залежність. Російська технологія не стає українською після зміни назви. BAS — це 1С. І доки український бізнес не матиме мужності назвати речі своїми іменами, справжнього технологічного звільнення не буде.'''
</div>

== Дивіться повний випуск TAX Podcast ==

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

'''Дивитися:''' [https://www.youtube.com/watch?v=fKgTSDcHUAo&list=PLRyc83tAN5QOOCknL2Bv_gHaz0Yzgyehe 1С та BAS під санкціями: чому бізнесу вже час переходити | TAX Podcast]

[[index.php?title=Категорія:1С]]
[[index.php?title=Категорія:BAS]]
[[index.php?title=Категорія:Російське програмне забезпечення]]
[[index.php?title=Категорія:Імпортозаміщення]]
[[index.php?title=Категорія:Українські ERP-системи]]
[[index.php?title=Категорія:K2 ERP]]
[[index.php?title=Категорія:Технологічна незалежність України]]

Під гуркіт російських ракет вони захищають російську 1С

2026-07-19T06:24:29Z

R: Створена сторінка: **TOC** = Під гуркіт російських ракет вони захищають російську 1С = ''Як коментарі під TAX Podcast показали справжній масштаб технологічної залежності України'' <div style="box-sizing:border-box; width:100%; margin:20px 0; padding:18px 22px; background:#fff1f1; border-left:6px solid #c62828; border-radius:6px; overflow-wrap:anywhere;"> '''...

**TOC**

= Під гуркіт російських ракет вони захищають російську 1С =

''Як коментарі під TAX Podcast показали справжній масштаб технологічної залежності України''

<div style="box-sizing:border-box; width:100%; margin:20px 0; padding:18px 22px; background:#fff1f1; border-left:6px solid #c62828; border-radius:6px; overflow-wrap:anywhere;">
'''Знову грім. Знову вибухи. Знову Київ та інші українські міста прокидаються від російських ракет. А паралельно частина українського бізнесу продовжує захищати російську технологічну платформу, ніби дванадцять років війни — це ще недостатня причина хоча б почати думати про технологічну незалежність.'''
</div>

Росія вкотре намагається знищити нашу енергетику, підприємства, будинки, життя і саме право України бути незалежною державою. А майже в той самий час під подкастом про небезпеку російського програмного забезпечення з’являються українські коментатори, які кидаються захищати 1С і BAS з такою відданістю, ніби їм за це вже нараховують премію — обов’язково через документ «Нарахування лояльності агресору».

Саме це стало для мене справжнім шоком після виходу [https://www.youtube.com/watch?v=fKgTSDcHUAo&list=PLRyc83tAN5QOOCknL2Bv_gHaz0Yzgyehe TAX Podcast про 1С, BAS, санкції та майбутнє українського бізнесу]. Тема випуску була сформульована гранично чітко: чому тисячі українських компаній досі працюють на 1С і BAS, які ризики несе така залежність, чому бізнес відкладає перехід і хто повинен брати на себе відповідальність за зміну корпоративної інформаційної системи.

'''У подкасті взагалі не було реклами K2 ERP.''' Там не проводилася презентація продукту, не демонструвалися модулі, не показувалися інтерфейси, не оголошувалися тарифи і не звучали заклики негайно щось купувати. K2 ERP згадувалася лише там, де це було природно й необхідно: як доказ того, що українські технологічні альтернативи існують і що українські розробники здатні створювати власні ERP-платформи.

Більша частина розмови була присвячена боротьбі з ворожим програмним забезпеченням, походженню 1С і BAS, санкціям, кіберризикам, відповідальності власників бізнесу та необхідності розвивати власні технології. Проте частина аудиторії вперто не захотіла чути саме це.

Замість розмови по суті почалося колективне виробництво інформаційного шуму. Хтось оголосив випуск «PR-подкастом». Хтось вирішив, що K2 ERP нібито хоче «прийти на все готове» і забрати собі ринок 1С та BAS. Хтось витягнув максимальну можливу ціну майбутньої комплектації й почав доводити, що український продукт дорогий. Інші заявили, що наведені аргументи — «не аргументи», а в студії нібито сидять люди, які не розуміють, про що говорять.

Виникло дивне відчуття, що під відео працює не група живих людей, а погано налаштований бот, якому завантажили один-єдиний сценарій: '''за будь-яку ціну не допустити розмови про російську природу 1С і BAS'''. Не відповідай на поставлене питання. Не аналізуй ризики. Не сперечайся з основною тезою. Переведи розмову на особистість спікера, знайди максимальну ціну, вимагай нескінченних доказів, оголоси все рекламою — і головна проблема потоне у болоті другорядних суперечок.

== Коли немає відповіді по суті, усе оголошують рекламою ==

Назвати подкаст рекламним — найпростіший спосіб його не слухати. Це дуже зручна інтелектуальна послуга: думати не потрібно, перевіряти сказане не потрібно, відповідати на незручні питання також не потрібно. Достатньо приклеїти ярлик «PR», після чого можна з почуттям виконаного громадянського обов’язку повернутися до російського конфігуратора.

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

Коли людина після такої розмови пише лише про «рекламу K2 ERP», це не критика подкасту. Це демонстрація того, що вона або не слухала випуск, або свідомо намагається розмити його зміст. Бо обговорювати справжню проблему незручно. Доведеться визнати, що дванадцять років війни підприємство працювало на російській технологічній основі, не створило плану переходу і тепер гарячково шукає пояснення, чому багаторічну бездіяльність потрібно вважати професійною мудрістю.

'''Оголосити розмову рекламою значно легше, ніж відповісти на просте запитання: чому під час війни ваш бізнес досі працює на російській платформі?'''

== BAS — це не споріднена технологія. BAS — це 1С ==

<div style="box-sizing:border-box; width:100%; margin:20px 0; padding:18px 22px; background:#eef6ff; border-left:6px solid #1565c0; border-radius:6px; overflow-wrap:anywhere;">
'''BAS — це 1С. Не «схожа система», не «споріднена технологія» і не нова незалежна українська платформа. Це 1С, перейменована та перефарбована для продовження роботи на українському ринку. Зміна логотипу не змінила технологічної суті продукту.'''
</div>

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

BAS не виникла як нова українська технологія, створена з нуля українськими інженерами. Вона з’явилася як спосіб продовжити використання продуктів екосистеми 1С після того, як російський бренд став токсичним, санкційним і незручним для відкритого просування на українському ринку.

Змінили напис на заставці. Перемалювали логотип. Перепакували маркетинг. Почали переконувати ринок, що це вже нібито зовсім інший продукт. Але людина, яка хоча б раз відкривала конфігуратор, працювала з метаданими, запитами, формами, документами та регістрами, чудово розуміє, що відбулося.

Один із коментаторів намагався довести, що BAS нібито стала іншою технологією, тому що в окремих функціях запитів виникли відмінності, а російська 1С за цей час «пішла вперед». Це приблизно як доводити, що автомобіль перестав бути автомобілем, тому що у новішій моделі переставили кнопку підігріву сидіння.

Відмінності між релізами, конфігураціями чи окремими функціями не змінюють технологічної природи продукту. Навпаки, саме твердження, що BAS колись відокремилася від 1С, уже визнає її походження. Далі залишається здійснити надзвичайно складну інтелектуальну операцію: скласти два і два.

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

'''BAS не стала українською технологією через зміну напису на заставці. Перейменування продукту — це не технологічне імпортозаміщення. Це лише імпортозаміщення логотипу.'''

== Перефарбована нафта, перефарбований газ і перефарбована 1С ==

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

Але походження від цього не змінюється. Нафта не стає демократичною після зміни танкера. Газ не вивчає європейські цінності під час проходження митниці. Російський бізнес не очищується від свого минулого після заміни таблички біля входу.

Так само й 1С не стала українською після того, як на її місці з’явилися три латинські літери BAS. '''Перефарбування російського продукту не робить його українським. Воно лише дозволяє користувачеві психологічно комфортніше продовжувати робити те саме.'''

Найдивовижніше, що ця операція виявилася надзвичайно успішною. Для великої частини ринку зміни логотипу було достатньо, щоб оголосити проблему вирішеною. Раніше підприємство працювало на 1С, тепер воно працює на BAS — отже, у красивій презентації російського програмного забезпечення нібито стало менше.

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

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

== Це болісно нагадує перші дні великої війни ==

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

Сьогодні майже ніхто не ризикує виходити на вулицю з російським прапором. Але коли мова заходить про російські технології, ми раптом чуємо до болю знайомі інтонації: «Не треба все політизувати», «Це просто програма», «Без неї неможливо працювати», «Альтернатив немає», «BAS уже не російська», «Не потрібно поспішати», «Спочатку доведіть, що українське не гірше».

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

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

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

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

== «K2 ERP хоче прийти на все готове» ==

Це один із найкумедніших аргументів, які з’явилися після випуску. K2 ERP нібито хоче прийти на готовий ринок і забрати клієнтів 1С та BAS.

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

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

Прийти на все готове — це прийти в обладнаний офіс, увімкнути комп’ютер і почати працювати. Українські ERP-команди приходять не в обладнаний офіс, а в технологічний музей, де кожен експонат доробляли двадцять років, документацію давно загубили, а головний зберігач музею забороняє торкатися системи, тому що «воно поки працює».

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

Якщо це називається «прийти на все готове», то можна лише уявити, як виглядає складний ринок.

== Знайти максимальну ціну — ще не означає порахувати вартість ==

<div style="box-sizing:border-box; width:100%; margin:20px 0; padding:18px 22px; background:#fff8e1; border-left:6px solid #f9a825; border-radius:6px; overflow-wrap:anywhere;">
'''Порівнювати максимальну комплектацію українського продукту з мінімальною ціною коробки BAS — це не фінансовий аналіз. Це цирковий номер із калькулятором. Справжнє порівняння повинно враховувати повну вартість володіння системою протягом кількох років.'''
</div>

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

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

Не порівнюється український продукт і з реальними західними ERP-системами, де впровадження, консалтинг, ліцензії та підтримка можуть коштувати зовсім інших грошей. Західній системі дозволено бути дорогою, бо вона західна. BAS дозволено бути дорогою, бо до неї звикли. Українська система, згідно з народною економічною доктриною, повинна бути функціональнішою за SAP, простішою за Excel і бажано коштувати дешевше за підписку на музичний сервіс.

Справжнє порівняння починається з повної вартості володіння. Скільки система коштує протягом п’яти чи десяти років? Скільки людей потрібно для її підтримки? Наскільки складно її розвивати? Які ризики вона створює? Наскільки підприємство залежить від конкретного постачальника, програміста або вузької технології? Скільки коштуватиме подальше відкладання переходу?

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

== Великі компанії, які раптом стають дуже бідними ==

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

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

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

'''Це не відсутність грошей. Це відсутність пріоритету.'''

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

== «Ніхто нікуди не поспішає» ==

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

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

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

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

== Дев’яносто п’ять відсотків залежності, яку сховали перейменуванням ==

За моєю професійною оцінкою, реальне проникнення російського програмного забезпечення в український бізнес залишається на рівні '''90–95%'''. Це не офіційна державна статистика, а оцінка, сформована на основі багаторічної роботи з підприємствами різного масштабу.

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

Формально показник міг зменшитися. Але часто не тому, що підприємства перейшли на українські чи західні платформи, а тому, що 1С перестали називати 1С. Частину того самого технологічного масиву тепер записують у статистиці як BAS, локальний продукт або окрему екосистему.

Так легко перемогти будь-яку залежність. Потрібно лише перейменувати її.

Не відмовилися від російської платформи — змінили назву. Не провели імпортозаміщення — оновили логотип. Не створили технологічної незалежності — перемістили рядок в інший розділ таблиці. Звіт зелений, презентація красива, залежність залишилася.

'''Український ринок не пішов із 1С. Він значною мірою просто перейшов із напису «1С» на напис «BAS».'''

== «Ваші аргументи — не аргументи» ==

Ще одна зручна позиція — оголосити всі наведені аргументи недостатніми. Дванадцять років війни — не аргумент. Російське походження платформи — не аргумент. Санкції — не аргумент. Кіберризики — не аргумент. Технологічна залежність — не аргумент. Необхідність розвивати українські продукти — також не аргумент.

Тоді що саме вони хочуть почути? Скільки ще має пройти років? Скільки українських міст повинні почути російські ракети, щоб питання технологічної залежності перестало здаватися передчасним? Чи потрібна персональна ракета з накладною та актом виконаних робіт, щоб керівник нарешті визнав аргумент достатньо переконливим?

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

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

І навіть після цього знайдеться вирішальний аргумент: «А от у нас є один звіт, який у BAS відкривається двома натисканнями».

== «У студії сидять не спеціалісти» ==

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

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

Досвід роботи в 1С може бути глибоким і цінним, але він не дає автоматичної монополії на розуміння всіх технологій. Знання синтаксису однієї платформи не робить людину експертом із сучасної вебархітектури, хмарних систем, розподілених середовищ, PostgreSQL, API-first підходів, мобільних клієнтів або розробки платформ швидкого створення бізнес-застосунків.

І навпаки, людина, яка створює сучасну ERP-платформу, має повне право оцінювати технологічні обмеження 1С і BAS. Особливо якщо до цього десятиліттями працювала з 1С, розробляла на ній, упроваджувала її, бачила її сильні та слабкі сторони й зрештою вирішила створити іншу технологічну основу.

'''Назвати опонента некомпетентним — це не аргумент. Це словесна ширма, за якою часто ховається страх професійних змін.'''

== Український продукт повинен бути ідеальним ще до того, як у нього почнуть вкладати ==

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

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

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

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

'''Не можна тридцять років вкладати в 1С, а потім обурюватися, що українській платформі також потрібні гроші, час і клієнти.'''

== Найстрашніше — не 1С. Найстрашніше — добровільна капітуляція мислення ==

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

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

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

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

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

== BAS — це 1С. А підміна теми — її найкращий захист ==

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

Але жодна з цих маніпуляцій не відповідає на головне запитання: '''чому український бізнес після дванадцяти років війни досі масово працює на російській технологічній платформі?'''

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

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

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

<div style="box-sizing:border-box; width:100%; margin:24px 0; padding:20px 24px; background:#eef8ef; border-left:6px solid #2e7d32; border-radius:6px; overflow-wrap:anywhere;">
'''Та вони пов’язані. Технологічна залежність — це також залежність. Російська технологія не стає українською після зміни назви. BAS — це 1С. І доки український бізнес не матиме мужності назвати речі своїми іменами, справжнього технологічного звільнення не буде.'''
</div>

== Дивіться повний випуск TAX Podcast ==

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

'''Дивитися:''' [https://www.youtube.com/watch?v=fKgTSDcHUAo&list=PLRyc83tAN5QOOCknL2Bv_gHaz0Yzgyehe 1С та BAS під санкціями: чому бізнесу вже час переходити | TAX Podcast]

[[Категорія:1С]]
[[Категорія:BAS]]
[[Категорія:Російське програмне забезпечення]]
[[Категорія:Імпортозаміщення]]
[[Категорія:Українські ERP-системи]]
[[Категорія:K2 ERP]]
[[Категорія:Технологічна незалежність України]]

Файл:Бухгалтер 1С.png

2026-07-19T06:24:26Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Головна сторінка

2026-07-19T06:24:10Z

R: Під гуркіт російських ракет вони захищають російську 1С

[[Файл:Wiki k2erp.png|центр|міні|800x800пкс|Wiki K2 ERP]]

== Про систему K2 ERP ==

[[K2 ERP]] — це комплексна система управління підприємством, яка об’єднує фінанси, бухгалтерію, продажі, склад, закупівлі, документообіг, CRM, аналітику та галузеві модулі в єдиному цифровому середовищі. Система допомагає автоматизувати щоденні процеси, зменшити ручну роботу й кількість помилок, контролювати ресурси в реальному часі, швидше обробляти заявки та документи, бачити повну картину бізнесу й приймати точні управлінські рішення на основі актуальних даних. Завдяки модульності, хмарному доступу та гнучкому налаштуванню K2 ERP підходить для компаній різного масштабу й допомагає бізнесу працювати прозоріше, ефективніше та впевнено масштабуватися.

Подробно про систему читайте в статті: [[K2 ERP]]

[[Відмова від 1С та BAS під ключ: перехід неминучий — питання лише в тому, хто встигне зробити його планово]]

[[Чому K2 ERP — реальна альтернатива 1С та BAS? Бо міняти російське ПЗ на “майже те саме” — це вже не стратегія, а бізнесовий мазохізм]]

[[ERP нового покоління: чому власна платформа K2 ERP на Python і TypeScript сильніша за спадщину 1С/BAS та важкі enterprise-рішення]]

[[Короткі відео про роботу в K2 ERP: українська ERP, яку можна побачити в дії]]

[[Ознайомче відео про K2 ERP]]

[[Альтернатива 1С: якою вона повинна бути насправді]]

[[Робимо бізнес разом!]]

[[Не витрачайте роки та гроші на ERP з нуля. Об’єднуймося навколо K2 ERP]]

[[Лавинний розвиток K2 ERP: чому відкрита українська ERP-система розвивається швидше за старий світ 1С/BAS]]

[[Чому K2 ERP йде шляхом швидкої розробки, моделей, конструкторів і об’єднання даних]]

[[Чому K2 ERP розвиває власну систему, а не Odoo, IT-Enterprise чи SAP]]

[[Візитка K2 ERP]]

[[Хто ваш клієнт, K2?]]

[[K2 ERP відкрила безкоштовну хмару для українського бізнесу]]

[[Інструменти розробника K2 ERP]]

[[Програмування зі швидкістю думки]]

[[Чим відрізняється робота в cloud.corp2.eu від власної хмари]]

[[Розробка K2 ERP на замовлення як правильний перехід з 1С та BAS]]

[[Продуктова компанія, інтегратор чи гібридна модель K2 ERP]]

[[Нові можливості K2 ERP: коли система розвивається з параболічною швидкістю (травень 2026)]]

[[Можливості K2 ERP — травень 2026]]

[[Новий модуль «Зарплата та кадри» в K2 ERP: коли зарплата рахується, кадри не губляться, а бухгалтер більше не живе в Excel]]

[[Виробництво без хаосу: як модуль «Виробництво» в K2 ERP веде виріб від специфікації до готової продукції]]

== Вартість K2 ERP ==
[[Скільки коштує K2 ERP: онлайн-калькулятор продуктів, ліцензій та обслуговування]]

[[Платний SaaS-сервіс K2 ERP: окрема ERP-система без купівлі серверної ліцензії]]

== Перехід з 1С та BAS на K2 ERP ==
[[Хакнути структуру 1С: чому “прозорий перехід” з BAS на старих базах — це пастка]]

== Стандартизація ==
[[ISO 9001 Scrum регламент K2 ERP: система якості, тижневі спринти, Zoom-записи, VDoc і Telegram-комунікації|ISO 9001 + Scrum + регламент K2 ERP: система якості, тижневі спринти, Zoom-записи, VDoc і Telegram-комунікації]]

== Акції та пропозиції ==
[[Навчайте студентів працювати з українською ERP-системою K2 ERP — альтернативою 1С та BAS]]

== Вакансії ==
[[Python-програмісти, які хочуть працювати з K2 ERP: не чекайте “колись”. Починайте зараз]]

== Історія про K2 ERP ==
[[Звідки взявся K2® ERP]]

== Сайти K2 ERP ==
[[Ресурси K2 ERP]]

== Комунікація з K2 ERP ==
[[Регламент K2]]

[[Звернення через HelpDesk]]

== Концептуальні підходи та принципи роботи ==
[[Кількість ліцензій BAS проти безліміту K2 ERP]]

[[Концепція передпродажних модулів K2 ERP: як малими внесками перемагати великі системи]]

[[Магія єдиної системи: чому модульний підхід K2 ERP у рази, десятки разів і навіть на порядки ефективніший за 1С/BAS]]

[[AI в K2 ERP: коли облік перестає бути нудним, а бізнес починає дихати на повні груди]]

[[Чи є ризик залежності від одного підрядника при автоматизації бізнесу?]]

[[Другий раз платити за той самий “зоопарк” ніхто не хоче: чому перехід з 1С на K2 ERP — це не про нову кастомізацію, а про нову логіку бізнесу]]

[[Чому “олдскульні” гриди насправді рятують бізнес: краса інтерфейсу не дорівнює силі продукту]]

[[Крос-платформеність: та сама “дрібниця”, на якій великі компанії щороку залишають купу грошей]]

== Пояснення термінів ==

[[Що таке ERP — і чому справжня ERP-система починається там, де закінчується звичка зводити бізнес до бухгалтерії]]

[[Що таке CRM і чому її інтеграція з ERP відкриває нові можливості для бізнесу]]

[[CMS у K2 ERP: сайт компанії, який не просто “висить в інтернеті”, а працює на бізнес]]

[[Інтернет-магазин у K2 ERP: коли онлайн-продажі стають частиною єдиної системи, а не окремим головним болем]]

== Для користувачів ==

[[Початок роботи з K2 ERP]]

[[Звіти в K2 Cloud ERP|Звіти в K2 ERP]]

[[CRM Файли в K2 ERP|CRM + Файли в K2 ERP]]

[[Повне відео демонстрації K2 ERP доступне з оригінальним голосом інтерфейсу та реального показу роботи системи]]

[[Хмара K2 ERP для безкоштовної реальної роботи]]

[[Управлінський облік K2 ERP]]

[[Бухгалтерія K2 ERP]]

[[CRM K2 ERP]]

[[Складський облік K2 ERP (WMS)]]

[[CMS K2 ERP]]

[[Інтернет-магазин K2 ERP]]

[[K2 VDoc]]

[[Галузеві рішення K2 ERP]]

[[Звіти та аналітика K2 ERP]]

[[Поширені питання K2 ERP]]

[[Використання штучного інтелекту в K2 ERP]]

== Для адміністраторів K2 ERP ==

[[Для адміністраторів K2 ERP]]

[[Адміністратор хмари K2 ERP]]

[[Адміністратор гілки K2 ERP]]

[[Адміністратор проєкту K2 ERP]]

[[Користувачі та ролі K2 ERP]]

[[Права доступу K2 ERP]]

[[Налаштування інтерфейсу K2 ERP]]

[[Друковані форми K2 ERP]]

[[Кастомізація звітів K2 ERP]]

[[Контроль і аудит K2 ERP]]

== Для програмістів ==

[[Розгортання системи K2 ERP Python для розробників]]

[[Архітектура K2 ERP]]

[[Встановлення K2 ERP]]

[[Розгортання K2 ERP]]

[[Створення модулів K2 ERP]]

[[База даних K2 ERP]]

[[API K2 ERP]]

[[Інтеграції K2 ERP]]

[[K2 CMS]]

[[Розробка веб-інтерфейсів K2]]

[[Бізнес-процеси K2 ERP]]

[[Права доступу K2 ERP]]

[[Рекомендації для розробників K2]]

[[Класи та команди K2 ERP Python]]

[[Стандарти UI K2 2025]]

== Атестаційні завдання по K2 ERP ==

[[Атестаційні завдання по K2 ERP]]

== K2 ERP PHP ==

[[Практична робота в K2 ERP PHP]]

[[Інструкція по розгортанню K2 ERP PHP]]

[[Класи та команди K2 Cloud ERP PHP]]

== Довідник та модулі системи K2 ERP ==

== Комплексні рішення K2 ERP ==

[[K2 ERP технологічна платформа]]

[[К2 Управлінський облік]]

== Модулі K2 ERP ==

[[K2 Ядро]]

[[K2 CMS]]

[[K2 Інтернет-магазин]]

[[К2 CRM]]

[[К2 WMS]]

[[K2 VDoc (Електронний документообіг)]]

[[К2 Система online-навчання]]

[[К2 Документообіг]]

[[К2 Дошка оголошень]]

[[К2 Портал творів мистецтва]]

[[К2 ТОІР та облік запчастин]]

[[K2 Update]]

[[K2 Фінансовий облік]]

[[K2 Каса]]

[[K2 Ресторан]]

[[K2 Готель]]

[[K2 Модуль Зарплата та кадри]]

[[K2 Модуль Виробництво]]

[[K2 multi-GAAP]]

[[K2 HelpDesk]]

[[K2 Мобільний додаток Android]]

[[K2 Мобільний додаток IOS]]

[[K2 Стоматологічна клініка]]

[[K2 Салон краси]]

[[K2 Бронювання послуг]]

[[K2 Автоперевезення]]

== Інтеграційні модулі K2 ERP ==
[[K2 Модуль Медок]]

[[K2 Модуль Вчасно]]

[[K2 Модуль Птах]]

[[K2 Модуль Мурашина логістика]]

[[K2 Модуль GPS-трекінг]]

[[K2 Модуль Вчасно Каса]]

[[K2 Модуль Ringostat до CRM]]

[[K2 Модуль Нова пошта]]

[[K2 Модуль Укрпошта]]

[[K2 Модуль Телеграм бот до CRM]]

[[K2 Модуль Whatsapp бот до CRM]]

[[K2 Модуль Turbosms до CRM]]

[[K2 Модуль Email до CRM]]

[[K2 Модуль Hurma]]

[[K2 Модуль обмінів з банками]]

[[K2 Модуль Horoshop]]

[[K2 Модуль Rozetka]]

[[K2 Модуль Prom]]

[[K2 Модуль Hotline]]

[[K2 Модуль ДПС]]

[[K2 Модуль Приватбанк]]

[[Модуль Edin]]

[[K2 Модуль Liqpay для інтернет-магазину]]

[[K2 Модуль Wayforpay для інтернет-магазину]]

== Інструментальні модулі K2 ERP ==
[[K2 Конструктор структури бази даних]]

[[K2 Конструктор звітів]]

[[K2 Конструктор BI звітів]]

[[K2 Реплікатор]]

[[IDE в K2 ERP]]

== Десктопні додатки ==
[[K2 Cloud ERP: Десктопний додаток для Linux, Windows та macOS — швидка робота з хмарами без хаосу вкладок]]

[[K2 Desktop — коли потужність розробки перетворюється на зручний інструмент]]

[[K2 Cloud ERP Desktop: один додаток замість десятків вкладок, ярликів і “вічного пошуку потрібного вікна”]]

== Торгове та перефірійне обладнання ==
[[РРО та ПРРО]]

== Модулі на PHP ==
[[Mantis BT K2]]

== Робота в K2 ==
[[Налаштування WireGuard]]

[[Веб-Пошта]]

== Навігація за категоріями ==
Усі статті бази знань автоматично групуються за категоріями:

* [[:Категорія:ERP-системи|ERP-системи]]
* [[:Категорія:Програмне забезпечення, розроблене в Україні|Українське ПЗ]]
* [[:Категорія:Програмне забезпечення для бізнесу|ПЗ для бізнесу]]

== Порівняння систем ==

[[Чим K2 ERP краще за 1С/BAS, Парус/Афіна, Бітрікс, BIMP, A5 та інші ERP]]

[[K2 ERP vs BAS ERP]]

[[K2 ERP vs BAS Управління торгівлею (UT)]]

[[K2 ERP vs Парус-Підприємство]]

[[K2 ERP vs SAP]]

[[K2 ERP vs Microsoft Dynamics 365]]

[[K2 ERP vs Oracle NetSuite]]

[[K2 ERP vs Odoo]]

[[K2 ERP vs Scoro]]

== Партнерство ==
[[Умови партнерства]]

[[Партнери K2 ERP]]

== Кейси K2 ERP ==

[[Кейс: як ми посилили ТОІР транспорту Нової пошти та цифровізували облік ремонтів і деталей для Kamag]]

== Статті по IT ==

[[Скільки реально коштують “дешеві” ліцензії Odoo, Microsoft Dynamics і SAP у порівнянні з K2 ERP]]

[[Україна має виростити власні продуктові IT-компанії. Інакше за нас це зроблять чужі]]

[[Смерть під ковдрою ілюзій: Чому перехід з 1С на BAS у 2026 році — це найдорожчий самообман українського бізнесу]]

[[BAS маскувалась під український продукт. А тепер російський K2 Cloud може маскувати K2 під російський? Дивний маскарад брендів триває]]

[[BAS нема чого запропонувати ринку, крім 1С]]

[[Давайте називати все своїми іменами: 1С, а не BAS. Говоріть завжди 1С, не йдіть на поводу ребрендіга 1С!]]

[[Пастка SaaS-систем]]

[[BAS стає токсичним — чому українському бізнесу час відмовитися від 1С/BAS]]

[[Росія виграє. 12:0 на користь росії]]

[[BAS у вишиванці, або 1С, яка сходила на ребрендинг]]

[[1С нагадує наші технології 20-річної давнини. Ба, це і є технології тих часів]]

[[BAS — це 1С]]

[[1С/BAS та іншому ворожому софту — капут]]

[[Еволюція веде до революції]]

[[Чому українські ERP досі не витіснили 1С та BAS з ринку України за 12 років війни]]

[[1С/BAS: 30 років російського запору в українському бізнесі]]

[[Гібридний трактор Lamborghini і гібридна ERP K2: як українська технологія може змінити ринок автоматизації]]

[[Як російські ERP-системи змінили прапор, але не змінили код]]

[[Кому “заборонено” 1С та BAS?]]

[[BASкетбол з санкціями: як “українська альтернатива 1С” закидає бізнесу рекламні трьохочкові]]

[[BAS, BaaS, BAF — це нова етикетка для старого 1С. Час називати речі своїми іменами]]

[[Як закалявся BAS, або як 1С фарбували на Великдень]]

[[Життя після 1С та BAS: Великий огляд українського ринку ERP-систем та реальних альтернатив у 2026 році]]

[[Відкритий похідний код, Open Source і K2 ERP: коли програмісти відкривають капот, але не віддають ключі від усього автопарку]]

[[Цифрова деокупація та санкції в Україні]]

[[Український бізнес і його токсичні стосунки з 1С/BAS: сміємося, платимо, страждаємо — і далі називаємо це “автоматизацією”]]

[[1С більше не законодавець мод. Тепер тренди створюють українські ERP]]

[[Безкоштовна українська хмара для малого бізнесу: стартуйте сьогодні, зростайте без обмежень]]

[[Не продавати доступ. Продавати свободу: чому майбутнє програмного забезпечення — за відкритими системами з чесною монетизацією]]

[[1С/BAS: софт для країни, де держава не довіряє бізнесу. І саме тому він не потрібен країні, яка хоче бути вільною]]

[[1С/BAS: система, в якій майбутнє давно натиснуло “Вийти без збереження”]]

== Мови програмування, тренди ==
[[Світ у 2025: які мови «правлять балом»]]

== Технічні завдання K2 ERP ==
[[Приклади технічного завдання K2 ERP]]

[[Приклади розрахунків]]

== Акції K2 ERP ==
[[Ловіть шару: передпродажний модуль Бухгалтерії та податкового обліку зараз включає CRM, CMS та інтернет-магазин]]

== Інвестиції в K2 ERP ==
[[Інвестиції в K2 ERP — українську платформу для заміни 1С/BAS та масової автоматизації бізнесу]]

[[Хто працює в K2 ERP]]

== Використання K2 ERP ==
[[K2: платформа, після якої старий софт починає нервово шукати валізу]]

[[Новий модуль K2 ERP для контролю звітності: коли сотні клієнтів, десятки дедлайнів і жодного права на ой, забули]]

[[K2 ERP як український Біткоїн]]

[[Варіанти використання K2 ERP по напрямкам]]

[[ERP продукти]]

[[K2 ERP — українська ERP для виробництва, складу, торгівлі, ФОП, агро, логістики та заміни BAS ERP]]

[[Всі ERP терміни]]

[[Всі бізнес-процеси]]

[[Всі інтеграції]]

[[Всі українські сервіси]]

[[Всі ERP модулі]]

[[BAS / 1С / SAP / Odoo / Dynamics]]

[[Всі 1С конфігурації]]

[[Всі BAS конфігурації]]

[[Всі 1С терміни]]

[[Всі BAS терміни]]

[[Всі отраслеві рішення 1С]]

== CRM ==
[[Варіанти використання K2 ERP CRM по напрямкам]]

[[CRM продукти]]

[[K2 ERP CRM - універсальна CRM для виробництва, складу, торговлі, ФОП, інтернет-магазину та заміни Bitrix24, 1C CRM]]

[[Всі терміни CRM]]

== Інтернет-магази ==
[[Варіанти використання K2 ERP інтернет-магазин по напрямкам]]

[[Продукти інтернет-магазинів]]

[[K2 ERP Інтернет-магазин - універсальний інтернет-магазин для заміни ShopScript та інших російських рішень]]

[[Всі терміни інтернет-магазинів]]

== Санкції та докази ==
[[Під гуркіт російських ракет вони захищають російську 1С]]

[[Поглинути 1С, BAS та інший ворожий софт: чому перенесення залишків — це ще не справжня відмова]]

[[Мені соромно за українські ЗМІ — чому медіа мають писати про український софт, K2 ERP та заміну 1С/BAS]]

[[Лавочка стала закриватись: 215 продуктів ворожого софту заборонено]]

[[Український бізнес інвестує в російське, бо думає, що українське помре]]

[[Схема мережі 1С, побудованої в Україні під виглядом BAS: коли “ми вже не 1С” звучить як “ми просто змінили табличку на дверях”]]

[[Пертнери BAS - партнери росії]]

[[Скільки грошей 1С намагається “збити” з українського бізнесу через листи щастя]]

[[Не продовжуйте ІТС на BAS. Бо BAS — це 1С]]

[[Вали російський бізнес, вали російський софт!]]

[[Програмне забезпечення, яким можна замінити ворожий софт]]

[[Докази, що BAS - це 1С]]

[[Список компаній, що розповсюджують BAS, не дивлячись на санкції січня 2026]]

[[Реєстр ворожого ПЗ і пов'язаних назв]]

[[Компанії, що почали переходити з ворожого софту]]

[[Реєстр компаній, що досі працюють на ворожому софті]]

[[Реєстр сервісів, що підтримують інтеграцію з ворожим софтом]]

== Реформи ==
[[Реформи К2]]

== Wikipedia ==
[[Різні статті]]

== Книги ==
[[Архітектура 1С-підприємства]]

[[Архітектура та розробка ERP-систем]]

Скільки коштує K2 ERP: онлайн-калькулятор продуктів, ліцензій та обслуговування

2026-07-18T19:43:49Z

{{DISPLAYTITLE:Скільки коштує K2 ERP: онлайн-калькулятор продуктів, ліцензій та обслуговування}}
[[Файл:Ціни K2 ERP.png|центр|міні|800x800пкс|Онлайн-калькулятор продуктів, ліцензій та обслуговування]]

'''Скільки коштуватиме K2 ERP саме для вашого підприємства?''' Відповідь залежить від кількості користувачів, потрібних модулів, способу розміщення системи, обраного формату ліцензування та обсягу послуг команди впровадження.

Щоб підприємству не доводилося проходити довгий «квест» із презентацій, дзвінків і запитів комерційних пропозицій лише заради розуміння базової вартості, створено '''онлайн-калькулятор K2 ERP''':

{| style="width:100%; margin:20px 0; border:1px solid #86c786; border-left:7px solid #2e9d43; background:#eef9f0; border-radius:6px;"
| style="padding:18px 22px;" |
<div style="font-size:125%; font-weight:bold; color:#176b2b;">Розрахуйте власну конфігурацію K2 ERP</div>

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

<div style="margin-top:12px; font-size:115%;">'''[https://calc.corp2.eu Відкрити калькулятор K2 ERP]'''</div>
|}

Калькулятор дозволяє порівняти три основні варіанти роботи:

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

Для кожного з цих варіантів можна окремо додати пакет технічного обслуговування.<ref name="calc">[https://calc.corp2.eu Калькулятор продуктів і послуг K2 ERP]</ref>

__TOC__

== Навіщо потрібен калькулятор K2 ERP ==

ERP-система не є одним стандартним програмним продуктом з однаковою конфігурацією для кожної компанії. Одному підприємству потрібні лише CRM, фінанси та контроль оплат. Іншому необхідні бухгалтерія, зарплата, виробництво, складська логістика, документообіг, корпоративна звітність та інтеграції із зовнішніми сервісами.

Саме тому поняття «ціна ERP» без уточнення конфігурації мало про що говорить.

Калькулятор K2 ERP допомагає побачити, '''з яких складових формується вартість''', і сформувати попередній бюджет ще до початку детального обстеження підприємства.

За допомогою калькулятора можна:

* порівняти безкоштовну хмару, SaaS і серверне ліцензування;
* обрати потрібні функціональні модулі;
* зазначити кількість користувачів;
* врахувати хостинг або розміщення на власному сервері;
* додати пакет обслуговування;
* розрахувати одноразові та щомісячні витрати;
* зберегти конфігурацію та отримати посилання;
* відкрити попередню комерційну пропозицію;
* передати сформований розрахунок колегам.

{| style="width:100%; margin:20px 0; border:1px solid #8fbce6; border-left:7px solid #2878bd; background:#eef6fd; border-radius:6px;"
| style="padding:18px 22px;" |
'''Головна перевага калькулятора — прозорість.'''

Клієнт бачить не абстрактну «вартість автоматизації», а окремо вартість програмних модулів, інфраструктури, користувачів, оновлень і роботи спеціалістів.
|}

== Три варіанти використання K2 ERP ==

=== Безкоштовна спільна хмара ===

Перший варіант — безкоштовна робота у спільній хмарі '''K2 ERP Cloud'''.

Зареєструватися та почати роботу можна за адресою:

'''[https://cloud.corp2.eu cloud.corp2.eu]'''

У спільній хмарі функціональні модулі доступні без оплати за самі модулі та кількість користувачів. Підприємство може знайомитися із системою, перевіряти її можливості, створювати власні структури обліку, працювати з документами, довідниками, звітами та іншими інструментами.<ref name="calc" />

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

* консультації користувачів;
* налаштування системи;
* перенесення даних;
* створення форм і звітів;
* розробку додаткової функціональності;
* навчання працівників;
* інтеграції із зовнішніми системами.

Безкоштовна хмара підходить для навчання, тестування, прототипування, демонстрації можливостей K2 ERP та запуску невеликих проєктів.

=== SaaS-підписка ===

Другий варіант — окрема база даних K2 ERP із щомісячною оплатою.

У моделі SaaS підприємство обирає необхідні модулі та кількість користувачів. Калькулятор визначає базову щомісячну вартість конфігурації та перераховує її відповідно до заданих параметрів.<ref name="calc" />

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

Наприклад, перший етап може включати:

# CRM;
# фінансовий облік;
# банківські виписки;
# контроль оплат;
# роботу з клієнтами та договорами.

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

У калькуляторі також можна обрати хостинг K2. Його щомісячна вартість розраховується за градацією кількості користувачів. Якщо хостинг K2 вимкнено, передбачається використання сервера клієнта та окреме одноразове розгортання системи.<ref name="calc" />

=== Ліцензія на власний сервер ===

Третій варіант — одноразове придбання технологічної платформи та функціональних модулів.

Такий формат підходить підприємствам, які хочуть розмістити K2 ERP:

* у власному дата-центрі;
* на орендованому сервері;
* у приватній хмарі;
* у корпоративній інфраструктурі;
* у гібридному середовищі.

При серверному ліцензуванні кількість користувачів не обмежується. Підприємство сплачує за технологічну платформу та обрані функціональні модулі, а не за кожне окреме робоче місце.<ref name="calc" />

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

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

== З чого формується підсумкова вартість ==

Загальна вартість K2 ERP складається не з одного показника. Калькулятор враховує декілька основних складових.

{| class="wikitable" style="width:100%;"
! style="width:28%;" | Складова
! Що враховується
|-
| '''Формат постачання'''
| Безкоштовна хмара, SaaS-підписка або серверна ліцензія.
|-
| '''Кількість користувачів'''
| Використовується під час розрахунку SaaS і хостингу.
|-
| '''Функціональні модулі'''
| Облік, CRM, виробництво, склад, документообіг, інтеграції та інші компоненти.
|-
| '''Інфраструктура'''
| Хостинг K2 або сервер підприємства.
|-
| '''Оновлення'''
| Сценарій щорічного продовження оновлень із другого року.
|-
| '''Обслуговування'''
| Погодинна робота або щомісячний пакет годин спеціалістів.
|}

Для SaaS загальну логіку можна представити так:

'''модулі + кількість користувачів + хостинг + обслуговування.'''

Для серверної моделі:

'''технологічна платформа + модулі + розгортання + оновлення + обслуговування.'''

== Які продукти можна обрати ==

Калькулятор містить велику кількість продуктів, функціональних модулів та інтеграцій K2 ERP. Їх можна підбирати відповідно до реальних процесів підприємства, а не купувати єдиний надмірно великий пакет.

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

До цієї групи належать:

* K2 Фінансовий облік;
* K2 Каса;
* K2 ERP Бухгалтерський облік;
* K2 Управлінський облік;
* K2 ERP Зарплата та кадри;
* K2 multi-GAAP;
* K2 SAF-T;
* модулі обміну з банками;
* інтеграції з М.E.Doc, Вчасно та ДПС.

=== CRM і робота з клієнтами ===

Підприємство може обрати:

* K2 CRM;
* CRM для контакт-центру;
* інтеграцію з Ringostat;
* Telegram-бот;
* WhatsApp-бот;
* Email для CRM;
* TurboSMS;
* модулі управління проєктами;
* корпоративний чат;
* HelpDesk.

=== Виробництво, склад і логістика ===

Для операційного управління доступні:

* K2 ERP Виробництво;
* K2 WMS для великого складу;
* ТОІР та облік запчастин;
* автотранспорт;
* автоперевезення;
* GPS-трекінг;
* інтеграції з Новою поштою та Укрпоштою;
* модулі транспортної та складської логістики.

=== Документообіг та аналітика ===

До цієї категорії входять:

* K2 Документообіг;
* VDoc;
* конструктор структури бази даних;
* конструктор звітів;
* конструктор BI-звітів;
* K2 Реплікатор;
* система оновлень K2 Update;
* K2 Projects;
* K2 LMS.

=== Інтернет-магазини та галузеві рішення ===

У калькуляторі також представлені:

* CMS;
* K2 Інтернет-магазин;
* великий інтернет-магазин;
* інтеграція з Horoshop;
* LiqPay;
* WayForPay;
* рішення для ресторану;
* рішення для готелю;
* рішення для стоматологічної клініки;
* рішення для салону краси;
* модуль бронювання послуг;
* модуль роботи з орендарями.

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

== Приклади базових цін ==

Нижче наведено декілька прикладів базової вартості, зазначеної в калькуляторі на момент публікації статті. Це не повний прайс, а лише приклади для розуміння різниці між SaaS і серверним ліцензуванням.<ref name="calc" />

{| class="wikitable sortable" style="width:100%; text-align:left;"
! Продукт
! Базова SaaS-вартість
! Серверна ліцензія
|-
| K2 ERP технологічна платформа
| —
| 1 500 EUR одноразово
|-
| K2 CRM
| 35 EUR/міс
| 1 000 EUR одноразово
|-
| K2 Фінансовий облік
| 35 EUR/міс
| 1 000 EUR одноразово
|-
| K2 ERP Бухгалтерський облік
| 85 EUR/міс
| 15 000 EUR одноразово за повний пакет
|-
| K2 ERP Зарплата та кадри
| 70 EUR/міс
| 2 000 EUR одноразово
|-
| K2 ERP Виробництво
| 170 EUR/міс
| 5 000 EUR одноразово
|-
| K2 WMS для великого складу
| 170 EUR/міс
| 15 000 EUR одноразово
|-
| K2 Реплікатор
| 180 EUR/міс
| 5 400 EUR одноразово
|-
| K2 Конструктор звітів
| 100 EUR/міс
| 3 000 EUR одноразово
|-
| K2 Управлінський облік
| 100 EUR/міс
| 3 000 EUR одноразово
|}

{| style="width:100%; margin:20px 0; border:1px solid #e0bd59; border-left:7px solid #d89900; background:#fff8dc; border-radius:6px;"
| style="padding:18px 22px;" |
'''Зверніть увагу.'''

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

Перед ухваленням рішення потрібно сформувати актуальний розрахунок на '''[https://calc.corp2.eu calc.corp2.eu]'''.
|}

== Обслуговування та робота спеціалістів ==

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

Підприємство може:

* використовувати систему самостійно;
* замовляти окремі години за потреби;
* обрати регулярний щомісячний пакет;
* сформувати постійну команду підтримки та розвитку.

У калькуляторі доступна погодинна оплата, а також пакети від 12 до 350 годин на місяць.<ref name="calc" />

На момент публікації передбачені такі варіанти:

{| class="wikitable" style="width:100%;"
! Пакет
! Годин на місяць
! Вартість
|-
| Погодинна оплата
| За фактом
| 90 EUR/год
|-
| ПРОФ
| 12 годин
| 720 EUR/міс
|-
| Малий бізнес
| 30 годин
| 1 650 EUR/міс
|-
| Середній бізнес
| 60 годин
| 3 420 EUR/міс
|-
| Великий бізнес
| 80 годин
| 4 400 EUR/міс
|-
| Ексклюзив
| 120 годин
| 6 360 EUR/міс
|-
| Ексклюзив
| 180 годин
| 9 000 EUR/міс
|-
| Ексклюзив
| 250 годин
| 11 750 EUR/міс
|-
| Бізнес Ексклюзив
| 350 годин
| 15 750 EUR/міс
|}

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

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

== Продовження оновлень ==

Для серверних ліцензій у калькуляторі передбачено декілька сценаріїв щорічного продовження оновлень, починаючи з другого року:

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

; Стандартне продовження
: Оформлюється вчасно, без тривалої перерви в отриманні оновлень.

; Прострочене продовження
: Використовується, якщо після завершення підтримки минуло від трьох місяців до двох років.<ref name="calc" />

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

== Вартість програмного забезпечення і впровадження — не одне й те саме ==

{| style="width:100%; margin:20px 0; border:1px solid #e4a3a3; border-left:7px solid #c33e3e; background:#fff1f1; border-radius:6px;"
| style="padding:18px 22px;" |
'''Важливо розрізняти вартість продуктів і вартість проєкту впровадження.'''

Калькулятор показує ліцензії, SaaS, хостинг, оновлення та обраний пакет обслуговування. Однак остаточний бюджет автоматизації залежить від стану даних, складності процесів, кількості інтеграцій та обсягу необхідних доробок.
|}

Повноцінне впровадження може включати:

* аналіз бізнес-процесів;
* підготовку технічного завдання;
* проєктування структури обліку;
* перенесення довідників і залишків;
* перенесення історичних даних;
* міграцію з 1С, BAS або інших систем;
* налаштування прав доступу;
* розробку документів, форм і звітів;
* інтеграцію з банками, обладнанням та зовнішніми сервісами;
* навчання користувачів;
* дослідну експлуатацію;
* підтримку після запуску.

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

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

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

== Можна почати з невеликої конфігурації ==

Перехід на K2 ERP не означає, що підприємство повинно автоматизувати всі процеси одночасно.

Проєкт можна розділити на послідовні етапи.

=== Приклад першого етапу ===

На першому етапі можна запустити:

* CRM;
* облік клієнтів і договорів;
* фінансовий облік;
* імпорт банківських виписок;
* контроль оплат;
* базову управлінську звітність.

=== Приклад другого етапу ===

Після стабілізації першого етапу можна додати:

* бухгалтерський і податковий облік;
* зарплату та кадри;
* документообіг;
* інтеграцію з М.E.Doc і Вчасно;
* бюджетування;
* розширену аналітику.

=== Приклад третього етапу ===

Для подальшого розвитку можна підключити:

* виробництво;
* WMS;
* ТОІР;
* транспортну логістику;
* мобільні застосунки;
* інтеграції з обладнанням;
* корпоративні BI-звіти.

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

== Як користуватися калькулятором ==

Щоб сформувати попередній розрахунок, потрібно:

# Відкрити '''[https://calc.corp2.eu калькулятор K2 ERP]'''.
# Обрати варіант постачання.
# Зазначити кількість користувачів.
# За потреби вказати назву клієнта.
# Обрати необхідні модулі.
# Увімкнути або вимкнути хостинг K2.
# Вибрати сценарій продовження оновлень.
# Додати пакет обслуговування.
# Переглянути підсумкову одноразову та щомісячну вартість.
# Зберегти конфігурацію або відкрити комерційну пропозицію.

Для автоматичного перерахунку сум у браузері має бути ввімкнений JavaScript.<ref name="calc" />

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

Це зручно, коли рішення про впровадження приймають спільно:

* власник підприємства;
* фінансовий директор;
* головний бухгалтер;
* ІТ-директор;
* керівники підрозділів;
* відповідальні за виробництво, склад або логістику.

== Як порівнювати SaaS і серверну ліцензію ==

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

=== SaaS може бути вигіднішим, якщо ===

* потрібно швидко запустити проєкт;
* кількість користувачів невелика;
* немає бажання одразу купувати всі ліцензії;
* конфігурація буде розширюватися поступово;
* підприємству зручніше планувати щомісячні витрати.

=== Серверна ліцензія може бути вигіднішою, якщо ===

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

=== Безкоштовна хмара підходить, якщо ===

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

== Прозоре ціноутворення замість «ціни за запитом» ==

На ринку корпоративного програмного забезпечення клієнт нерідко бачить лише напис «ціна за запитом». Після цього потрібно залишити контакти, чекати дзвінка, проводити зустріч і лише потім отримувати орієнтовну суму.

K2 ERP пропонує інший підхід.

Підприємство може самостійно:

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

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

{| style="width:100%; margin:24px 0; border:1px solid #efa765; border-left:7px solid #ed7d1a; background:#fff4e8; border-radius:6px;"
| style="padding:20px 24px;" |
<div style="font-size:130%; font-weight:bold; color:#a64a00;">Не ворожіть над ціною ERP — розрахуйте її</div>

Сформуйте власну конфігурацію, порівняйте SaaS і серверну ліцензію, додайте потрібні модулі та обслуговування.

<div style="margin-top:14px; font-size:118%;">'''[https://calc.corp2.eu Перейти до калькулятора K2 ERP]'''</div>

<div style="margin-top:8px;">'''[https://cloud.corp2.eu Почати безкоштовно у хмарі K2 ERP]'''</div>
|}

== Висновок ==

Не існує єдиної конфігурації K2 ERP, яка однаково підходить кожному підприємству.

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

Саме тому вартість потрібно розраховувати відповідно до реальних потреб бізнесу.

'''Калькулятор K2 ERP дає можливість побачити структуру витрат, порівняти різні моделі та сформувати попередній бюджет без прихованих складових.'''

== Див. також ==

* [https://corp2.eu Офіційний сайт K2]
* [https://erp.kyiv.ua Публікації та відео про K2 ERP]
* [https://wiki.erp.kyiv.ua Документація K2 ERP]
* [https://cloud.corp2.eu Безкоштовна хмара K2 ERP]
* [https://calc.corp2.eu Калькулятор K2 ERP]

== Джерела ==

<references />

[[Категорія:K2 ERP]]
[[Категорія:Ціни K2 ERP]]
[[Категорія:Ліцензування K2 ERP]]
[[Категорія:SaaS]]
[[Категорія:ERP-системи]]
[[Категорія:Автоматизація бізнесу]]
[[Категорія:Українське програмне забезпечення]]

Скільки коштує K2 ERP: онлайн-калькулятор продуктів, ліцензій та обслуговування

2026-07-18T19:43:34Z

{{DISPLAYTITLE:Скільки коштує K2 ERP: онлайн-калькулятор продуктів, ліцензій та обслуговування}}
[[Файл:Ціни K2 ERP.png|центр|міні|800x800пкс|Онлайн-калькулятор продуктів, ліцензій та обслуговування]]

'''Скільки коштуватиме K2 ERP саме для вашого підприємства?''' Відповідь залежить від кількості користувачів, потрібних модулів, способу розміщення системи, обраного формату ліцензування та обсягу послуг команди впровадження.

Щоб підприємству не доводилося проходити довгий «квест» із презентацій, дзвінків і запитів комерційних пропозицій лише заради розуміння базової вартості, створено '''онлайн-калькулятор K2 ERP''':

{| style="width:100%; margin:20px 0; border:1px solid #86c786; border-left:7px solid #2e9d43; background:#eef9f0; border-radius:6px;"
| style="padding:18px 22px;" |
<div style="font-size:125%; font-weight:bold; color:#176b2b;">Розрахуйте власну конфігурацію K2 ERP</div>

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

<div style="margin-top:12px; font-size:115%;">'''[https://calc.corp2.eu Відкрити калькулятор K2 ERP]'''</div>
|}

Калькулятор дозволяє порівняти три основні варіанти роботи:

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

Для кожного з цих варіантів можна окремо додати пакет технічного обслуговування.<ref name="calc">[https://calc.corp2.eu Калькулятор продуктів і послуг K2 ERP]</ref>

__TOC__

== Навіщо потрібен калькулятор K2 ERP ==

ERP-система не є одним стандартним програмним продуктом з однаковою конфігурацією для кожної компанії. Одному підприємству потрібні лише CRM, фінанси та контроль оплат. Іншому необхідні бухгалтерія, зарплата, виробництво, складська логістика, документообіг, корпоративна звітність та інтеграції із зовнішніми сервісами.

Саме тому поняття «ціна ERP» без уточнення конфігурації мало про що говорить.

Калькулятор K2 ERP допомагає побачити, '''з яких складових формується вартість''', і сформувати попередній бюджет ще до початку детального обстеження підприємства.

За допомогою калькулятора можна:

* порівняти безкоштовну хмару, SaaS і серверне ліцензування;
* обрати потрібні функціональні модулі;
* зазначити кількість користувачів;
* врахувати хостинг або розміщення на власному сервері;
* додати пакет обслуговування;
* розрахувати одноразові та щомісячні витрати;
* зберегти конфігурацію та отримати посилання;
* відкрити попередню комерційну пропозицію;
* передати сформований розрахунок колегам.

{| style="width:100%; margin:20px 0; border:1px solid #8fbce6; border-left:7px solid #2878bd; background:#eef6fd; border-radius:6px;"
| style="padding:18px 22px;" |
'''Головна перевага калькулятора — прозорість.'''

Клієнт бачить не абстрактну «вартість автоматизації», а окремо вартість програмних модулів, інфраструктури, користувачів, оновлень і роботи спеціалістів.
|}

== Три варіанти використання K2 ERP ==

=== Безкоштовна спільна хмара ===

Перший варіант — безкоштовна робота у спільній хмарі '''K2 ERP Cloud'''.

Зареєструватися та почати роботу можна за адресою:

'''[https://cloud.corp2.eu cloud.corp2.eu]'''

У спільній хмарі функціональні модулі доступні без оплати за самі модулі та кількість користувачів. Підприємство може знайомитися із системою, перевіряти її можливості, створювати власні структури обліку, працювати з документами, довідниками, звітами та іншими інструментами.<ref name="calc" />

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

* консультації користувачів;
* налаштування системи;
* перенесення даних;
* створення форм і звітів;
* розробку додаткової функціональності;
* навчання працівників;
* інтеграції із зовнішніми системами.

Безкоштовна хмара підходить для навчання, тестування, прототипування, демонстрації можливостей K2 ERP та запуску невеликих проєктів.

=== SaaS-підписка ===

Другий варіант — окрема база даних K2 ERP із щомісячною оплатою.

У моделі SaaS підприємство обирає необхідні модулі та кількість користувачів. Калькулятор визначає базову щомісячну вартість конфігурації та перераховує її відповідно до заданих параметрів.<ref name="calc" />

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

Наприклад, перший етап може включати:

# CRM;
# фінансовий облік;
# банківські виписки;
# контроль оплат;
# роботу з клієнтами та договорами.

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

У калькуляторі також можна обрати хостинг K2. Його щомісячна вартість розраховується за градацією кількості користувачів. Якщо хостинг K2 вимкнено, передбачається використання сервера клієнта та окреме одноразове розгортання системи.<ref name="calc" />

=== Ліцензія на власний сервер ===

Третій варіант — одноразове придбання технологічної платформи та функціональних модулів.

Такий формат підходить підприємствам, які хочуть розмістити K2 ERP:

* у власному дата-центрі;
* на орендованому сервері;
* у приватній хмарі;
* у корпоративній інфраструктурі;
* у гібридному середовищі.

При серверному ліцензуванні кількість користувачів не обмежується. Підприємство сплачує за технологічну платформу та обрані функціональні модулі, а не за кожне окреме робоче місце.<ref name="calc" />

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

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

== З чого формується підсумкова вартість ==

Загальна вартість K2 ERP складається не з одного показника. Калькулятор враховує декілька основних складових.

{| class="wikitable" style="width:100%;"
! style="width:28%;" | Складова
! Що враховується
|-
| '''Формат постачання'''
| Безкоштовна хмара, SaaS-підписка або серверна ліцензія.
|-
| '''Кількість користувачів'''
| Використовується під час розрахунку SaaS і хостингу.
|-
| '''Функціональні модулі'''
| Облік, CRM, виробництво, склад, документообіг, інтеграції та інші компоненти.
|-
| '''Інфраструктура'''
| Хостинг K2 або сервер підприємства.
|-
| '''Оновлення'''
| Сценарій щорічного продовження оновлень із другого року.
|-
| '''Обслуговування'''
| Погодинна робота або щомісячний пакет годин спеціалістів.
|}

Для SaaS загальну логіку можна представити так:

'''модулі + кількість користувачів + хостинг + обслуговування.'''

Для серверної моделі:

'''технологічна платформа + модулі + розгортання + оновлення + обслуговування.'''

== Які продукти можна обрати ==

Калькулятор містить велику кількість продуктів, функціональних модулів та інтеграцій K2 ERP. Їх можна підбирати відповідно до реальних процесів підприємства, а не купувати єдиний надмірно великий пакет.

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

До цієї групи належать:

* K2 Фінансовий облік;
* K2 Каса;
* K2 ERP Бухгалтерський облік;
* K2 Управлінський облік;
* K2 ERP Зарплата та кадри;
* K2 multi-GAAP;
* K2 SAF-T;
* модулі обміну з банками;
* інтеграції з М.E.Doc, Вчасно та ДПС.

=== CRM і робота з клієнтами ===

Підприємство може обрати:

* K2 CRM;
* CRM для контакт-центру;
* інтеграцію з Ringostat;
* Telegram-бот;
* WhatsApp-бот;
* Email для CRM;
* TurboSMS;
* модулі управління проєктами;
* корпоративний чат;
* HelpDesk.

=== Виробництво, склад і логістика ===

Для операційного управління доступні:

* K2 ERP Виробництво;
* K2 WMS для великого складу;
* ТОІР та облік запчастин;
* автотранспорт;
* автоперевезення;
* GPS-трекінг;
* інтеграції з Новою поштою та Укрпоштою;
* модулі транспортної та складської логістики.

=== Документообіг та аналітика ===

До цієї категорії входять:

* K2 Документообіг;
* VDoc;
* конструктор структури бази даних;
* конструктор звітів;
* конструктор BI-звітів;
* K2 Реплікатор;
* система оновлень K2 Update;
* K2 Projects;
* K2 LMS.

=== Інтернет-магазини та галузеві рішення ===

У калькуляторі також представлені:

* CMS;
* K2 Інтернет-магазин;
* великий інтернет-магазин;
* інтеграція з Horoshop;
* LiqPay;
* WayForPay;
* рішення для ресторану;
* рішення для готелю;
* рішення для стоматологічної клініки;
* рішення для салону краси;
* модуль бронювання послуг;
* модуль роботи з орендарями.

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

== Приклади базових цін ==

Нижче наведено декілька прикладів базової вартості, зазначеної в калькуляторі на момент публікації статті. Це не повний прайс, а лише приклади для розуміння різниці між SaaS і серверним ліцензуванням.<ref name="calc" />

{| class="wikitable sortable" style="width:100%; text-align:left;"
! Продукт
! Базова SaaS-вартість
! Серверна ліцензія
|-
| K2 ERP технологічна платформа
| —
| 1 500 EUR одноразово
|-
| K2 CRM
| 35 EUR/міс
| 1 000 EUR одноразово
|-
| K2 Фінансовий облік
| 35 EUR/міс
| 1 000 EUR одноразово
|-
| K2 ERP Бухгалтерський облік
| 85 EUR/міс
| 15 000 EUR одноразово за повний пакет
|-
| K2 ERP Зарплата та кадри
| 70 EUR/міс
| 2 000 EUR одноразово
|-
| K2 ERP Виробництво
| 170 EUR/міс
| 5 000 EUR одноразово
|-
| K2 WMS для великого складу
| 170 EUR/міс
| 15 000 EUR одноразово
|-
| K2 Реплікатор
| 180 EUR/міс
| 5 400 EUR одноразово
|-
| K2 Конструктор звітів
| 100 EUR/міс
| 3 000 EUR одноразово
|-
| K2 Управлінський облік
| 100 EUR/міс
| 3 000 EUR одноразово
|}

{| style="width:100%; margin:20px 0; border:1px solid #e0bd59; border-left:7px solid #d89900; background:#fff8dc; border-radius:6px;"
| style="padding:18px 22px;" |
'''Зверніть увагу.'''

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

Перед ухваленням рішення потрібно сформувати актуальний розрахунок на '''[https://calc.corp2.eu calc.corp2.eu]'''.
|}

== Обслуговування та робота спеціалістів ==

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

Підприємство може:

* використовувати систему самостійно;
* замовляти окремі години за потреби;
* обрати регулярний щомісячний пакет;
* сформувати постійну команду підтримки та розвитку.

У калькуляторі доступна погодинна оплата, а також пакети від 12 до 350 годин на місяць.<ref name="calc" />

На момент публікації передбачені такі варіанти:

{| class="wikitable" style="width:100%;"
! Пакет
! Годин на місяць
! Вартість
|-
| Погодинна оплата
| За фактом
| 90 EUR/год
|-
| ПРОФ
| 12 годин
| 720 EUR/міс
|-
| Малий бізнес
| 30 годин
| 1 650 EUR/міс
|-
| Середній бізнес
| 60 годин
| 3 420 EUR/міс
|-
| Великий бізнес
| 80 годин
| 4 400 EUR/міс
|-
| Ексклюзив
| 120 годин
| 6 360 EUR/міс
|-
| Ексклюзив
| 180 годин
| 9 000 EUR/міс
|-
| Ексклюзив
| 250 годин
| 11 750 EUR/міс
|-
| Бізнес Ексклюзив
| 350 годин
| 15 750 EUR/міс
|}

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

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

== Продовження оновлень ==

Для серверних ліцензій у калькуляторі передбачено декілька сценаріїв щорічного продовження оновлень, починаючи з другого року:

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

; Стандартне продовження
: Оформлюється вчасно, без тривалої перерви в отриманні оновлень.

; Прострочене продовження
: Використовується, якщо після завершення підтримки минуло від трьох місяців до двох років.<ref name="calc" />

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

== Вартість програмного забезпечення і впровадження — не одне й те саме ==

{| style="width:100%; margin:20px 0; border:1px solid #e4a3a3; border-left:7px solid #c33e3e; background:#fff1f1; border-radius:6px;"
| style="padding:18px 22px;" |
'''Важливо розрізняти вартість продуктів і вартість проєкту впровадження.'''

Калькулятор показує ліцензії, SaaS, хостинг, оновлення та обраний пакет обслуговування. Однак остаточний бюджет автоматизації залежить від стану даних, складності процесів, кількості інтеграцій та обсягу необхідних доробок.
|}

Повноцінне впровадження може включати:

* аналіз бізнес-процесів;
* підготовку технічного завдання;
* проєктування структури обліку;
* перенесення довідників і залишків;
* перенесення історичних даних;
* міграцію з 1С, BAS або інших систем;
* налаштування прав доступу;
* розробку документів, форм і звітів;
* інтеграцію з банками, обладнанням та зовнішніми сервісами;
* навчання користувачів;
* дослідну експлуатацію;
* підтримку після запуску.

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

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

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

== Можна почати з невеликої конфігурації ==

Перехід на K2 ERP не означає, що підприємство повинно автоматизувати всі процеси одночасно.

Проєкт можна розділити на послідовні етапи.

=== Приклад першого етапу ===

На першому етапі можна запустити:

* CRM;
* облік клієнтів і договорів;
* фінансовий облік;
* імпорт банківських виписок;
* контроль оплат;
* базову управлінську звітність.

=== Приклад другого етапу ===

Після стабілізації першого етапу можна додати:

* бухгалтерський і податковий облік;
* зарплату та кадри;
* документообіг;
* інтеграцію з М.E.Doc і Вчасно;
* бюджетування;
* розширену аналітику.

=== Приклад третього етапу ===

Для подальшого розвитку можна підключити:

* виробництво;
* WMS;
* ТОІР;
* транспортну логістику;
* мобільні застосунки;
* інтеграції з обладнанням;
* корпоративні BI-звіти.

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

== Як користуватися калькулятором ==

Щоб сформувати попередній розрахунок, потрібно:

# Відкрити '''[https://calc.corp2.eu калькулятор K2 ERP]'''.
# Обрати варіант постачання.
# Зазначити кількість користувачів.
# За потреби вказати назву клієнта.
# Обрати необхідні модулі.
# Увімкнути або вимкнути хостинг K2.
# Вибрати сценарій продовження оновлень.
# Додати пакет обслуговування.
# Переглянути підсумкову одноразову та щомісячну вартість.
# Зберегти конфігурацію або відкрити комерційну пропозицію.

Для автоматичного перерахунку сум у браузері має бути ввімкнений JavaScript.<ref name="calc" />

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

Це зручно, коли рішення про впровадження приймають спільно:

* власник підприємства;
* фінансовий директор;
* головний бухгалтер;
* ІТ-директор;
* керівники підрозділів;
* відповідальні за виробництво, склад або логістику.

== Як порівнювати SaaS і серверну ліцензію ==

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

=== SaaS може бути вигіднішим, якщо ===

* потрібно швидко запустити проєкт;
* кількість користувачів невелика;
* немає бажання одразу купувати всі ліцензії;
* конфігурація буде розширюватися поступово;
* підприємству зручніше планувати щомісячні витрати.

=== Серверна ліцензія може бути вигіднішою, якщо ===

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

=== Безкоштовна хмара підходить, якщо ===

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

== Прозоре ціноутворення замість «ціни за запитом» ==

На ринку корпоративного програмного забезпечення клієнт нерідко бачить лише напис «ціна за запитом». Після цього потрібно залишити контакти, чекати дзвінка, проводити зустріч і лише потім отримувати орієнтовну суму.

K2 ERP пропонує інший підхід.

Підприємство може самостійно:

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

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

{| style="width:100%; margin:24px 0; border:1px solid #efa765; border-left:7px solid #ed7d1a; background:#fff4e8; border-radius:6px;"
| style="padding:20px 24px;" |
<div style="font-size:130%; font-weight:bold; color:#a64a00;">Не ворожіть над ціною ERP — розрахуйте її</div>

Сформуйте власну конфігурацію, порівняйте SaaS і серверну ліцензію, додайте потрібні модулі та обслуговування.

<div style="margin-top:14px; font-size:118%;">'''[https://calc.corp2.eu Перейти до калькулятора K2 ERP]'''</div>

<div style="margin-top:8px;">'''[https://cloud.corp2.eu Почати безкоштовно у хмарі K2 ERP]'''</div>
|}

== Висновок ==

Не існує єдиної конфігурації K2 ERP, яка однаково підходить кожному підприємству.

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

Саме тому вартість потрібно розраховувати відповідно до реальних потреб бізнесу.

'''Калькулятор K2 ERP дає можливість побачити структуру витрат, порівняти різні моделі та сформувати попередній бюджет без прихованих складових.'''

== Див. також ==

* [https://corp2.eu Офіційний сайт K2]
* [https://erp.kyiv.ua Публікації та відео про K2 ERP]
* [https://wiki.erp.kyiv.ua Документація K2 ERP]
* [https://cloud.corp2.eu Безкоштовна хмара K2 ERP]
* [https://calc.corp2.eu Калькулятор K2 ERP]

== Джерела ==

<references />

[[index.php?title=Категорія:K2 ERP]]
[[index.php?title=Категорія:Ціни K2 ERP]]
[[index.php?title=Категорія:Ліцензування K2 ERP]]
[[index.php?title=Категорія:SaaS]]
[[index.php?title=Категорія:ERP-системи]]
[[index.php?title=Категорія:Автоматизація бізнесу]]
[[index.php?title=Категорія:Українське програмне забезпечення]]

Скільки коштує K2 ERP: онлайн-калькулятор продуктів, ліцензій та обслуговування

2026-07-18T19:42:36Z

R: Створена сторінка: {{DISPLAYTITLE:Скільки коштує K2 ERP: онлайн-калькулятор продуктів, ліцензій та обслуговування}} K2 ERP: прозорий розрахунок вартості без прихованих платежів '''Скільки коштуватиме K2 ERP саме для вашого підпр...

{{DISPLAYTITLE:Скільки коштує K2 ERP: онлайн-калькулятор продуктів, ліцензій та обслуговування}}

[[Файл:Ціна без прихованих платежів.png|центр|міні|1000пкс|K2 ERP: прозорий розрахунок вартості без прихованих платежів]]

'''Скільки коштуватиме K2 ERP саме для вашого підприємства?''' Відповідь залежить від кількості користувачів, потрібних модулів, способу розміщення системи, обраного формату ліцензування та обсягу послуг команди впровадження.

Щоб підприємству не доводилося проходити довгий «квест» із презентацій, дзвінків і запитів комерційних пропозицій лише заради розуміння базової вартості, створено '''онлайн-калькулятор K2 ERP''':

{| style="width:100%; margin:20px 0; border:1px solid #86c786; border-left:7px solid #2e9d43; background:#eef9f0; border-radius:6px;"
| style="padding:18px 22px;" |
<div style="font-size:125%; font-weight:bold; color:#176b2b;">Розрахуйте власну конфігурацію K2 ERP</div>

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

<div style="margin-top:12px; font-size:115%;">'''[https://calc.corp2.eu Відкрити калькулятор K2 ERP]'''</div>
|}

Калькулятор дозволяє порівняти три основні варіанти роботи:

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

Для кожного з цих варіантів можна окремо додати пакет технічного обслуговування.<ref name="calc">[https://calc.corp2.eu Калькулятор продуктів і послуг K2 ERP]</ref>

__TOC__

== Навіщо потрібен калькулятор K2 ERP ==

ERP-система не є одним стандартним програмним продуктом з однаковою конфігурацією для кожної компанії. Одному підприємству потрібні лише CRM, фінанси та контроль оплат. Іншому необхідні бухгалтерія, зарплата, виробництво, складська логістика, документообіг, корпоративна звітність та інтеграції із зовнішніми сервісами.

Саме тому поняття «ціна ERP» без уточнення конфігурації мало про що говорить.

Калькулятор K2 ERP допомагає побачити, '''з яких складових формується вартість''', і сформувати попередній бюджет ще до початку детального обстеження підприємства.

За допомогою калькулятора можна:

* порівняти безкоштовну хмару, SaaS і серверне ліцензування;
* обрати потрібні функціональні модулі;
* зазначити кількість користувачів;
* врахувати хостинг або розміщення на власному сервері;
* додати пакет обслуговування;
* розрахувати одноразові та щомісячні витрати;
* зберегти конфігурацію та отримати посилання;
* відкрити попередню комерційну пропозицію;
* передати сформований розрахунок колегам.

{| style="width:100%; margin:20px 0; border:1px solid #8fbce6; border-left:7px solid #2878bd; background:#eef6fd; border-radius:6px;"
| style="padding:18px 22px;" |
'''Головна перевага калькулятора — прозорість.'''

Клієнт бачить не абстрактну «вартість автоматизації», а окремо вартість програмних модулів, інфраструктури, користувачів, оновлень і роботи спеціалістів.
|}

== Три варіанти використання K2 ERP ==

=== Безкоштовна спільна хмара ===

Перший варіант — безкоштовна робота у спільній хмарі '''K2 ERP Cloud'''.

Зареєструватися та почати роботу можна за адресою:

'''[https://cloud.corp2.eu cloud.corp2.eu]'''

У спільній хмарі функціональні модулі доступні без оплати за самі модулі та кількість користувачів. Підприємство може знайомитися із системою, перевіряти її можливості, створювати власні структури обліку, працювати з документами, довідниками, звітами та іншими інструментами.<ref name="calc" />

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

* консультації користувачів;
* налаштування системи;
* перенесення даних;
* створення форм і звітів;
* розробку додаткової функціональності;
* навчання працівників;
* інтеграції із зовнішніми системами.

Безкоштовна хмара підходить для навчання, тестування, прототипування, демонстрації можливостей K2 ERP та запуску невеликих проєктів.

=== SaaS-підписка ===

Другий варіант — окрема база даних K2 ERP із щомісячною оплатою.

У моделі SaaS підприємство обирає необхідні модулі та кількість користувачів. Калькулятор визначає базову щомісячну вартість конфігурації та перераховує її відповідно до заданих параметрів.<ref name="calc" />

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

Наприклад, перший етап може включати:

# CRM;
# фінансовий облік;
# банківські виписки;
# контроль оплат;
# роботу з клієнтами та договорами.

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

У калькуляторі також можна обрати хостинг K2. Його щомісячна вартість розраховується за градацією кількості користувачів. Якщо хостинг K2 вимкнено, передбачається використання сервера клієнта та окреме одноразове розгортання системи.<ref name="calc" />

=== Ліцензія на власний сервер ===

Третій варіант — одноразове придбання технологічної платформи та функціональних модулів.

Такий формат підходить підприємствам, які хочуть розмістити K2 ERP:

* у власному дата-центрі;
* на орендованому сервері;
* у приватній хмарі;
* у корпоративній інфраструктурі;
* у гібридному середовищі.

При серверному ліцензуванні кількість користувачів не обмежується. Підприємство сплачує за технологічну платформу та обрані функціональні модулі, а не за кожне окреме робоче місце.<ref name="calc" />

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

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

== З чого формується підсумкова вартість ==

Загальна вартість K2 ERP складається не з одного показника. Калькулятор враховує декілька основних складових.

{| class="wikitable" style="width:100%;"
! style="width:28%;" | Складова
! Що враховується
|-
| '''Формат постачання'''
| Безкоштовна хмара, SaaS-підписка або серверна ліцензія.
|-
| '''Кількість користувачів'''
| Використовується під час розрахунку SaaS і хостингу.
|-
| '''Функціональні модулі'''
| Облік, CRM, виробництво, склад, документообіг, інтеграції та інші компоненти.
|-
| '''Інфраструктура'''
| Хостинг K2 або сервер підприємства.
|-
| '''Оновлення'''
| Сценарій щорічного продовження оновлень із другого року.
|-
| '''Обслуговування'''
| Погодинна робота або щомісячний пакет годин спеціалістів.
|}

Для SaaS загальну логіку можна представити так:

'''модулі + кількість користувачів + хостинг + обслуговування.'''

Для серверної моделі:

'''технологічна платформа + модулі + розгортання + оновлення + обслуговування.'''

== Які продукти можна обрати ==

Калькулятор містить велику кількість продуктів, функціональних модулів та інтеграцій K2 ERP. Їх можна підбирати відповідно до реальних процесів підприємства, а не купувати єдиний надмірно великий пакет.

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

До цієї групи належать:

* K2 Фінансовий облік;
* K2 Каса;
* K2 ERP Бухгалтерський облік;
* K2 Управлінський облік;
* K2 ERP Зарплата та кадри;
* K2 multi-GAAP;
* K2 SAF-T;
* модулі обміну з банками;
* інтеграції з М.E.Doc, Вчасно та ДПС.

=== CRM і робота з клієнтами ===

Підприємство може обрати:

* K2 CRM;
* CRM для контакт-центру;
* інтеграцію з Ringostat;
* Telegram-бот;
* WhatsApp-бот;
* Email для CRM;
* TurboSMS;
* модулі управління проєктами;
* корпоративний чат;
* HelpDesk.

=== Виробництво, склад і логістика ===

Для операційного управління доступні:

* K2 ERP Виробництво;
* K2 WMS для великого складу;
* ТОІР та облік запчастин;
* автотранспорт;
* автоперевезення;
* GPS-трекінг;
* інтеграції з Новою поштою та Укрпоштою;
* модулі транспортної та складської логістики.

=== Документообіг та аналітика ===

До цієї категорії входять:

* K2 Документообіг;
* VDoc;
* конструктор структури бази даних;
* конструктор звітів;
* конструктор BI-звітів;
* K2 Реплікатор;
* система оновлень K2 Update;
* K2 Projects;
* K2 LMS.

=== Інтернет-магазини та галузеві рішення ===

У калькуляторі також представлені:

* CMS;
* K2 Інтернет-магазин;
* великий інтернет-магазин;
* інтеграція з Horoshop;
* LiqPay;
* WayForPay;
* рішення для ресторану;
* рішення для готелю;
* рішення для стоматологічної клініки;
* рішення для салону краси;
* модуль бронювання послуг;
* модуль роботи з орендарями.

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

== Приклади базових цін ==

Нижче наведено декілька прикладів базової вартості, зазначеної в калькуляторі на момент публікації статті. Це не повний прайс, а лише приклади для розуміння різниці між SaaS і серверним ліцензуванням.<ref name="calc" />

{| class="wikitable sortable" style="width:100%; text-align:left;"
! Продукт
! Базова SaaS-вартість
! Серверна ліцензія
|-
| K2 ERP технологічна платформа
| —
| 1 500 EUR одноразово
|-
| K2 CRM
| 35 EUR/міс
| 1 000 EUR одноразово
|-
| K2 Фінансовий облік
| 35 EUR/міс
| 1 000 EUR одноразово
|-
| K2 ERP Бухгалтерський облік
| 85 EUR/міс
| 15 000 EUR одноразово за повний пакет
|-
| K2 ERP Зарплата та кадри
| 70 EUR/міс
| 2 000 EUR одноразово
|-
| K2 ERP Виробництво
| 170 EUR/міс
| 5 000 EUR одноразово
|-
| K2 WMS для великого складу
| 170 EUR/міс
| 15 000 EUR одноразово
|-
| K2 Реплікатор
| 180 EUR/міс
| 5 400 EUR одноразово
|-
| K2 Конструктор звітів
| 100 EUR/міс
| 3 000 EUR одноразово
|-
| K2 Управлінський облік
| 100 EUR/міс
| 3 000 EUR одноразово
|}

{| style="width:100%; margin:20px 0; border:1px solid #e0bd59; border-left:7px solid #d89900; background:#fff8dc; border-radius:6px;"
| style="padding:18px 22px;" |
'''Зверніть увагу.'''

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

Перед ухваленням рішення потрібно сформувати актуальний розрахунок на '''[https://calc.corp2.eu calc.corp2.eu]'''.
|}

== Обслуговування та робота спеціалістів ==

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

Підприємство може:

* використовувати систему самостійно;
* замовляти окремі години за потреби;
* обрати регулярний щомісячний пакет;
* сформувати постійну команду підтримки та розвитку.

У калькуляторі доступна погодинна оплата, а також пакети від 12 до 350 годин на місяць.<ref name="calc" />

На момент публікації передбачені такі варіанти:

{| class="wikitable" style="width:100%;"
! Пакет
! Годин на місяць
! Вартість
|-
| Погодинна оплата
| За фактом
| 90 EUR/год
|-
| ПРОФ
| 12 годин
| 720 EUR/міс
|-
| Малий бізнес
| 30 годин
| 1 650 EUR/міс
|-
| Середній бізнес
| 60 годин
| 3 420 EUR/міс
|-
| Великий бізнес
| 80 годин
| 4 400 EUR/міс
|-
| Ексклюзив
| 120 годин
| 6 360 EUR/міс
|-
| Ексклюзив
| 180 годин
| 9 000 EUR/міс
|-
| Ексклюзив
| 250 годин
| 11 750 EUR/міс
|-
| Бізнес Ексклюзив
| 350 годин
| 15 750 EUR/міс
|}

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

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

== Продовження оновлень ==

Для серверних ліцензій у калькуляторі передбачено декілька сценаріїв щорічного продовження оновлень, починаючи з другого року:

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

; Стандартне продовження
: Оформлюється вчасно, без тривалої перерви в отриманні оновлень.

; Прострочене продовження
: Використовується, якщо після завершення підтримки минуло від трьох місяців до двох років.<ref name="calc" />

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

== Вартість програмного забезпечення і впровадження — не одне й те саме ==

{| style="width:100%; margin:20px 0; border:1px solid #e4a3a3; border-left:7px solid #c33e3e; background:#fff1f1; border-radius:6px;"
| style="padding:18px 22px;" |
'''Важливо розрізняти вартість продуктів і вартість проєкту впровадження.'''

Калькулятор показує ліцензії, SaaS, хостинг, оновлення та обраний пакет обслуговування. Однак остаточний бюджет автоматизації залежить від стану даних, складності процесів, кількості інтеграцій та обсягу необхідних доробок.
|}

Повноцінне впровадження може включати:

* аналіз бізнес-процесів;
* підготовку технічного завдання;
* проєктування структури обліку;
* перенесення довідників і залишків;
* перенесення історичних даних;
* міграцію з 1С, BAS або інших систем;
* налаштування прав доступу;
* розробку документів, форм і звітів;
* інтеграцію з банками, обладнанням та зовнішніми сервісами;
* навчання користувачів;
* дослідну експлуатацію;
* підтримку після запуску.

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

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

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

== Можна почати з невеликої конфігурації ==

Перехід на K2 ERP не означає, що підприємство повинно автоматизувати всі процеси одночасно.

Проєкт можна розділити на послідовні етапи.

=== Приклад першого етапу ===

На першому етапі можна запустити:

* CRM;
* облік клієнтів і договорів;
* фінансовий облік;
* імпорт банківських виписок;
* контроль оплат;
* базову управлінську звітність.

=== Приклад другого етапу ===

Після стабілізації першого етапу можна додати:

* бухгалтерський і податковий облік;
* зарплату та кадри;
* документообіг;
* інтеграцію з М.E.Doc і Вчасно;
* бюджетування;
* розширену аналітику.

=== Приклад третього етапу ===

Для подальшого розвитку можна підключити:

* виробництво;
* WMS;
* ТОІР;
* транспортну логістику;
* мобільні застосунки;
* інтеграції з обладнанням;
* корпоративні BI-звіти.

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

== Як користуватися калькулятором ==

Щоб сформувати попередній розрахунок, потрібно:

# Відкрити '''[https://calc.corp2.eu калькулятор K2 ERP]'''.
# Обрати варіант постачання.
# Зазначити кількість користувачів.
# За потреби вказати назву клієнта.
# Обрати необхідні модулі.
# Увімкнути або вимкнути хостинг K2.
# Вибрати сценарій продовження оновлень.
# Додати пакет обслуговування.
# Переглянути підсумкову одноразову та щомісячну вартість.
# Зберегти конфігурацію або відкрити комерційну пропозицію.

Для автоматичного перерахунку сум у браузері має бути ввімкнений JavaScript.<ref name="calc" />

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

Це зручно, коли рішення про впровадження приймають спільно:

* власник підприємства;
* фінансовий директор;
* головний бухгалтер;
* ІТ-директор;
* керівники підрозділів;
* відповідальні за виробництво, склад або логістику.

== Як порівнювати SaaS і серверну ліцензію ==

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

=== SaaS може бути вигіднішим, якщо ===

* потрібно швидко запустити проєкт;
* кількість користувачів невелика;
* немає бажання одразу купувати всі ліцензії;
* конфігурація буде розширюватися поступово;
* підприємству зручніше планувати щомісячні витрати.

=== Серверна ліцензія може бути вигіднішою, якщо ===

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

=== Безкоштовна хмара підходить, якщо ===

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

== Прозоре ціноутворення замість «ціни за запитом» ==

На ринку корпоративного програмного забезпечення клієнт нерідко бачить лише напис «ціна за запитом». Після цього потрібно залишити контакти, чекати дзвінка, проводити зустріч і лише потім отримувати орієнтовну суму.

K2 ERP пропонує інший підхід.

Підприємство може самостійно:

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

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

{| style="width:100%; margin:24px 0; border:1px solid #efa765; border-left:7px solid #ed7d1a; background:#fff4e8; border-radius:6px;"
| style="padding:20px 24px;" |
<div style="font-size:130%; font-weight:bold; color:#a64a00;">Не ворожіть над ціною ERP — розрахуйте її</div>

Сформуйте власну конфігурацію, порівняйте SaaS і серверну ліцензію, додайте потрібні модулі та обслуговування.

<div style="margin-top:14px; font-size:118%;">'''[https://calc.corp2.eu Перейти до калькулятора K2 ERP]'''</div>

<div style="margin-top:8px;">'''[https://cloud.corp2.eu Почати безкоштовно у хмарі K2 ERP]'''</div>
|}

== Висновок ==

Не існує єдиної конфігурації K2 ERP, яка однаково підходить кожному підприємству.

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

Саме тому вартість потрібно розраховувати відповідно до реальних потреб бізнесу.

'''Калькулятор K2 ERP дає можливість побачити структуру витрат, порівняти різні моделі та сформувати попередній бюджет без прихованих складових.'''

== Див. також ==

* [https://corp2.eu Офіційний сайт K2]
* [https://erp.kyiv.ua Публікації та відео про K2 ERP]
* [https://wiki.erp.kyiv.ua Документація K2 ERP]
* [https://cloud.corp2.eu Безкоштовна хмара K2 ERP]
* [https://calc.corp2.eu Калькулятор K2 ERP]

== Джерела ==

<references />

[[Категорія:K2 ERP]]
[[Категорія:Ціни K2 ERP]]
[[Категорія:Ліцензування K2 ERP]]
[[Категорія:SaaS]]
[[Категорія:ERP-системи]]
[[Категорія:Автоматизація бізнесу]]
[[Категорія:Українське програмне забезпечення]]

Файл:Ціни K2 ERP.png

2026-07-18T19:42:29Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Головна сторінка

2026-07-18T19:42:14Z

R: Скільки коштує K2 ERP: онлайн-калькулятор продуктів, ліцензій та обслуговування

[[Файл:Wiki k2erp.png|центр|міні|800x800пкс|Wiki K2 ERP]]

== Про систему K2 ERP ==

[[K2 ERP]] — це комплексна система управління підприємством, яка об’єднує фінанси, бухгалтерію, продажі, склад, закупівлі, документообіг, CRM, аналітику та галузеві модулі в єдиному цифровому середовищі. Система допомагає автоматизувати щоденні процеси, зменшити ручну роботу й кількість помилок, контролювати ресурси в реальному часі, швидше обробляти заявки та документи, бачити повну картину бізнесу й приймати точні управлінські рішення на основі актуальних даних. Завдяки модульності, хмарному доступу та гнучкому налаштуванню K2 ERP підходить для компаній різного масштабу й допомагає бізнесу працювати прозоріше, ефективніше та впевнено масштабуватися.

Подробно про систему читайте в статті: [[K2 ERP]]

[[Відмова від 1С та BAS під ключ: перехід неминучий — питання лише в тому, хто встигне зробити його планово]]

[[Чому K2 ERP — реальна альтернатива 1С та BAS? Бо міняти російське ПЗ на “майже те саме” — це вже не стратегія, а бізнесовий мазохізм]]

[[ERP нового покоління: чому власна платформа K2 ERP на Python і TypeScript сильніша за спадщину 1С/BAS та важкі enterprise-рішення]]

[[Короткі відео про роботу в K2 ERP: українська ERP, яку можна побачити в дії]]

[[Ознайомче відео про K2 ERP]]

[[Альтернатива 1С: якою вона повинна бути насправді]]

[[Робимо бізнес разом!]]

[[Не витрачайте роки та гроші на ERP з нуля. Об’єднуймося навколо K2 ERP]]

[[Лавинний розвиток K2 ERP: чому відкрита українська ERP-система розвивається швидше за старий світ 1С/BAS]]

[[Чому K2 ERP йде шляхом швидкої розробки, моделей, конструкторів і об’єднання даних]]

[[Чому K2 ERP розвиває власну систему, а не Odoo, IT-Enterprise чи SAP]]

[[Візитка K2 ERP]]

[[Хто ваш клієнт, K2?]]

[[K2 ERP відкрила безкоштовну хмару для українського бізнесу]]

[[Інструменти розробника K2 ERP]]

[[Програмування зі швидкістю думки]]

[[Чим відрізняється робота в cloud.corp2.eu від власної хмари]]

[[Розробка K2 ERP на замовлення як правильний перехід з 1С та BAS]]

[[Продуктова компанія, інтегратор чи гібридна модель K2 ERP]]

[[Нові можливості K2 ERP: коли система розвивається з параболічною швидкістю (травень 2026)]]

[[Можливості K2 ERP — травень 2026]]

[[Новий модуль «Зарплата та кадри» в K2 ERP: коли зарплата рахується, кадри не губляться, а бухгалтер більше не живе в Excel]]

[[Виробництво без хаосу: як модуль «Виробництво» в K2 ERP веде виріб від специфікації до готової продукції]]

== Вартість K2 ERP ==
[[Скільки коштує K2 ERP: онлайн-калькулятор продуктів, ліцензій та обслуговування]]

[[Платний SaaS-сервіс K2 ERP: окрема ERP-система без купівлі серверної ліцензії]]

== Перехід з 1С та BAS на K2 ERP ==
[[Хакнути структуру 1С: чому “прозорий перехід” з BAS на старих базах — це пастка]]

== Стандартизація ==
[[ISO 9001 Scrum регламент K2 ERP: система якості, тижневі спринти, Zoom-записи, VDoc і Telegram-комунікації|ISO 9001 + Scrum + регламент K2 ERP: система якості, тижневі спринти, Zoom-записи, VDoc і Telegram-комунікації]]

== Акції та пропозиції ==
[[Навчайте студентів працювати з українською ERP-системою K2 ERP — альтернативою 1С та BAS]]

== Вакансії ==
[[Python-програмісти, які хочуть працювати з K2 ERP: не чекайте “колись”. Починайте зараз]]

== Історія про K2 ERP ==
[[Звідки взявся K2® ERP]]

== Сайти K2 ERP ==
[[Ресурси K2 ERP]]

== Комунікація з K2 ERP ==
[[Регламент K2]]

[[Звернення через HelpDesk]]

== Концептуальні підходи та принципи роботи ==
[[Кількість ліцензій BAS проти безліміту K2 ERP]]

[[Концепція передпродажних модулів K2 ERP: як малими внесками перемагати великі системи]]

[[Магія єдиної системи: чому модульний підхід K2 ERP у рази, десятки разів і навіть на порядки ефективніший за 1С/BAS]]

[[AI в K2 ERP: коли облік перестає бути нудним, а бізнес починає дихати на повні груди]]

[[Чи є ризик залежності від одного підрядника при автоматизації бізнесу?]]

[[Другий раз платити за той самий “зоопарк” ніхто не хоче: чому перехід з 1С на K2 ERP — це не про нову кастомізацію, а про нову логіку бізнесу]]

[[Чому “олдскульні” гриди насправді рятують бізнес: краса інтерфейсу не дорівнює силі продукту]]

[[Крос-платформеність: та сама “дрібниця”, на якій великі компанії щороку залишають купу грошей]]

== Пояснення термінів ==

[[Що таке ERP — і чому справжня ERP-система починається там, де закінчується звичка зводити бізнес до бухгалтерії]]

[[Що таке CRM і чому її інтеграція з ERP відкриває нові можливості для бізнесу]]

[[CMS у K2 ERP: сайт компанії, який не просто “висить в інтернеті”, а працює на бізнес]]

[[Інтернет-магазин у K2 ERP: коли онлайн-продажі стають частиною єдиної системи, а не окремим головним болем]]

== Для користувачів ==

[[Початок роботи з K2 ERP]]

[[Звіти в K2 Cloud ERP|Звіти в K2 ERP]]

[[CRM Файли в K2 ERP|CRM + Файли в K2 ERP]]

[[Повне відео демонстрації K2 ERP доступне з оригінальним голосом інтерфейсу та реального показу роботи системи]]

[[Хмара K2 ERP для безкоштовної реальної роботи]]

[[Управлінський облік K2 ERP]]

[[Бухгалтерія K2 ERP]]

[[CRM K2 ERP]]

[[Складський облік K2 ERP (WMS)]]

[[CMS K2 ERP]]

[[Інтернет-магазин K2 ERP]]

[[K2 VDoc]]

[[Галузеві рішення K2 ERP]]

[[Звіти та аналітика K2 ERP]]

[[Поширені питання K2 ERP]]

[[Використання штучного інтелекту в K2 ERP]]

== Для адміністраторів K2 ERP ==

[[Для адміністраторів K2 ERP]]

[[Адміністратор хмари K2 ERP]]

[[Адміністратор гілки K2 ERP]]

[[Адміністратор проєкту K2 ERP]]

[[Користувачі та ролі K2 ERP]]

[[Права доступу K2 ERP]]

[[Налаштування інтерфейсу K2 ERP]]

[[Друковані форми K2 ERP]]

[[Кастомізація звітів K2 ERP]]

[[Контроль і аудит K2 ERP]]

== Для програмістів ==

[[Розгортання системи K2 ERP Python для розробників]]

[[Архітектура K2 ERP]]

[[Встановлення K2 ERP]]

[[Розгортання K2 ERP]]

[[Створення модулів K2 ERP]]

[[База даних K2 ERP]]

[[API K2 ERP]]

[[Інтеграції K2 ERP]]

[[K2 CMS]]

[[Розробка веб-інтерфейсів K2]]

[[Бізнес-процеси K2 ERP]]

[[Права доступу K2 ERP]]

[[Рекомендації для розробників K2]]

[[Класи та команди K2 ERP Python]]

[[Стандарти UI K2 2025]]

== Атестаційні завдання по K2 ERP ==

[[Атестаційні завдання по K2 ERP]]

== K2 ERP PHP ==

[[Практична робота в K2 ERP PHP]]

[[Інструкція по розгортанню K2 ERP PHP]]

[[Класи та команди K2 Cloud ERP PHP]]

== Довідник та модулі системи K2 ERP ==

== Комплексні рішення K2 ERP ==

[[K2 ERP технологічна платформа]]

[[К2 Управлінський облік]]

== Модулі K2 ERP ==

[[K2 Ядро]]

[[K2 CMS]]

[[K2 Інтернет-магазин]]

[[К2 CRM]]

[[К2 WMS]]

[[K2 VDoc (Електронний документообіг)]]

[[К2 Система online-навчання]]

[[К2 Документообіг]]

[[К2 Дошка оголошень]]

[[К2 Портал творів мистецтва]]

[[К2 ТОІР та облік запчастин]]

[[K2 Update]]

[[K2 Фінансовий облік]]

[[K2 Каса]]

[[K2 Ресторан]]

[[K2 Готель]]

[[K2 Модуль Зарплата та кадри]]

[[K2 Модуль Виробництво]]

[[K2 multi-GAAP]]

[[K2 HelpDesk]]

[[K2 Мобільний додаток Android]]

[[K2 Мобільний додаток IOS]]

[[K2 Стоматологічна клініка]]

[[K2 Салон краси]]

[[K2 Бронювання послуг]]

[[K2 Автоперевезення]]

== Інтеграційні модулі K2 ERP ==
[[K2 Модуль Медок]]

[[K2 Модуль Вчасно]]

[[K2 Модуль Птах]]

[[K2 Модуль Мурашина логістика]]

[[K2 Модуль GPS-трекінг]]

[[K2 Модуль Вчасно Каса]]

[[K2 Модуль Ringostat до CRM]]

[[K2 Модуль Нова пошта]]

[[K2 Модуль Укрпошта]]

[[K2 Модуль Телеграм бот до CRM]]

[[K2 Модуль Whatsapp бот до CRM]]

[[K2 Модуль Turbosms до CRM]]

[[K2 Модуль Email до CRM]]

[[K2 Модуль Hurma]]

[[K2 Модуль обмінів з банками]]

[[K2 Модуль Horoshop]]

[[K2 Модуль Rozetka]]

[[K2 Модуль Prom]]

[[K2 Модуль Hotline]]

[[K2 Модуль ДПС]]

[[K2 Модуль Приватбанк]]

[[Модуль Edin]]

[[K2 Модуль Liqpay для інтернет-магазину]]

[[K2 Модуль Wayforpay для інтернет-магазину]]

== Інструментальні модулі K2 ERP ==
[[K2 Конструктор структури бази даних]]

[[K2 Конструктор звітів]]

[[K2 Конструктор BI звітів]]

[[K2 Реплікатор]]

[[IDE в K2 ERP]]

== Десктопні додатки ==
[[K2 Cloud ERP: Десктопний додаток для Linux, Windows та macOS — швидка робота з хмарами без хаосу вкладок]]

[[K2 Desktop — коли потужність розробки перетворюється на зручний інструмент]]

[[K2 Cloud ERP Desktop: один додаток замість десятків вкладок, ярликів і “вічного пошуку потрібного вікна”]]

== Торгове та перефірійне обладнання ==
[[РРО та ПРРО]]

== Модулі на PHP ==
[[Mantis BT K2]]

== Робота в K2 ==
[[Налаштування WireGuard]]

[[Веб-Пошта]]

== Навігація за категоріями ==
Усі статті бази знань автоматично групуються за категоріями:

* [[:Категорія:ERP-системи|ERP-системи]]
* [[:Категорія:Програмне забезпечення, розроблене в Україні|Українське ПЗ]]
* [[:Категорія:Програмне забезпечення для бізнесу|ПЗ для бізнесу]]

== Порівняння систем ==

[[Чим K2 ERP краще за 1С/BAS, Парус/Афіна, Бітрікс, BIMP, A5 та інші ERP]]

[[K2 ERP vs BAS ERP]]

[[K2 ERP vs BAS Управління торгівлею (UT)]]

[[K2 ERP vs Парус-Підприємство]]

[[K2 ERP vs SAP]]

[[K2 ERP vs Microsoft Dynamics 365]]

[[K2 ERP vs Oracle NetSuite]]

[[K2 ERP vs Odoo]]

[[K2 ERP vs Scoro]]

== Партнерство ==
[[Умови партнерства]]

[[Партнери K2 ERP]]

== Кейси K2 ERP ==

[[Кейс: як ми посилили ТОІР транспорту Нової пошти та цифровізували облік ремонтів і деталей для Kamag]]

== Статті по IT ==

[[Скільки реально коштують “дешеві” ліцензії Odoo, Microsoft Dynamics і SAP у порівнянні з K2 ERP]]

[[Україна має виростити власні продуктові IT-компанії. Інакше за нас це зроблять чужі]]

[[Смерть під ковдрою ілюзій: Чому перехід з 1С на BAS у 2026 році — це найдорожчий самообман українського бізнесу]]

[[BAS маскувалась під український продукт. А тепер російський K2 Cloud може маскувати K2 під російський? Дивний маскарад брендів триває]]

[[BAS нема чого запропонувати ринку, крім 1С]]

[[Давайте називати все своїми іменами: 1С, а не BAS. Говоріть завжди 1С, не йдіть на поводу ребрендіга 1С!]]

[[Пастка SaaS-систем]]

[[BAS стає токсичним — чому українському бізнесу час відмовитися від 1С/BAS]]

[[Росія виграє. 12:0 на користь росії]]

[[BAS у вишиванці, або 1С, яка сходила на ребрендинг]]

[[1С нагадує наші технології 20-річної давнини. Ба, це і є технології тих часів]]

[[BAS — це 1С]]

[[1С/BAS та іншому ворожому софту — капут]]

[[Еволюція веде до революції]]

[[Чому українські ERP досі не витіснили 1С та BAS з ринку України за 12 років війни]]

[[1С/BAS: 30 років російського запору в українському бізнесі]]

[[Гібридний трактор Lamborghini і гібридна ERP K2: як українська технологія може змінити ринок автоматизації]]

[[Як російські ERP-системи змінили прапор, але не змінили код]]

[[Кому “заборонено” 1С та BAS?]]

[[BASкетбол з санкціями: як “українська альтернатива 1С” закидає бізнесу рекламні трьохочкові]]

[[BAS, BaaS, BAF — це нова етикетка для старого 1С. Час називати речі своїми іменами]]

[[Як закалявся BAS, або як 1С фарбували на Великдень]]

[[Життя після 1С та BAS: Великий огляд українського ринку ERP-систем та реальних альтернатив у 2026 році]]

[[Відкритий похідний код, Open Source і K2 ERP: коли програмісти відкривають капот, але не віддають ключі від усього автопарку]]

[[Цифрова деокупація та санкції в Україні]]

[[Український бізнес і його токсичні стосунки з 1С/BAS: сміємося, платимо, страждаємо — і далі називаємо це “автоматизацією”]]

[[1С більше не законодавець мод. Тепер тренди створюють українські ERP]]

[[Безкоштовна українська хмара для малого бізнесу: стартуйте сьогодні, зростайте без обмежень]]

[[Не продавати доступ. Продавати свободу: чому майбутнє програмного забезпечення — за відкритими системами з чесною монетизацією]]

[[1С/BAS: софт для країни, де держава не довіряє бізнесу. І саме тому він не потрібен країні, яка хоче бути вільною]]

[[1С/BAS: система, в якій майбутнє давно натиснуло “Вийти без збереження”]]

== Мови програмування, тренди ==
[[Світ у 2025: які мови «правлять балом»]]

== Технічні завдання K2 ERP ==
[[Приклади технічного завдання K2 ERP]]

[[Приклади розрахунків]]

== Акції K2 ERP ==
[[Ловіть шару: передпродажний модуль Бухгалтерії та податкового обліку зараз включає CRM, CMS та інтернет-магазин]]

== Інвестиції в K2 ERP ==
[[Інвестиції в K2 ERP — українську платформу для заміни 1С/BAS та масової автоматизації бізнесу]]

[[Хто працює в K2 ERP]]

== Використання K2 ERP ==
[[K2: платформа, після якої старий софт починає нервово шукати валізу]]

[[Новий модуль K2 ERP для контролю звітності: коли сотні клієнтів, десятки дедлайнів і жодного права на ой, забули]]

[[K2 ERP як український Біткоїн]]

[[Варіанти використання K2 ERP по напрямкам]]

[[ERP продукти]]

[[K2 ERP — українська ERP для виробництва, складу, торгівлі, ФОП, агро, логістики та заміни BAS ERP]]

[[Всі ERP терміни]]

[[Всі бізнес-процеси]]

[[Всі інтеграції]]

[[Всі українські сервіси]]

[[Всі ERP модулі]]

[[BAS / 1С / SAP / Odoo / Dynamics]]

[[Всі 1С конфігурації]]

[[Всі BAS конфігурації]]

[[Всі 1С терміни]]

[[Всі BAS терміни]]

[[Всі отраслеві рішення 1С]]

== CRM ==
[[Варіанти використання K2 ERP CRM по напрямкам]]

[[CRM продукти]]

[[K2 ERP CRM - універсальна CRM для виробництва, складу, торговлі, ФОП, інтернет-магазину та заміни Bitrix24, 1C CRM]]

[[Всі терміни CRM]]

== Інтернет-магази ==
[[Варіанти використання K2 ERP інтернет-магазин по напрямкам]]

[[Продукти інтернет-магазинів]]

[[K2 ERP Інтернет-магазин - універсальний інтернет-магазин для заміни ShopScript та інших російських рішень]]

[[Всі терміни інтернет-магазинів]]

== Санкції та докази ==
[[Поглинути 1С, BAS та інший ворожий софт: чому перенесення залишків — це ще не справжня відмова]]

[[Мені соромно за українські ЗМІ — чому медіа мають писати про український софт, K2 ERP та заміну 1С/BAS]]

[[Лавочка стала закриватись: 215 продуктів ворожого софту заборонено]]

[[Український бізнес інвестує в російське, бо думає, що українське помре]]

[[Схема мережі 1С, побудованої в Україні під виглядом BAS: коли “ми вже не 1С” звучить як “ми просто змінили табличку на дверях”]]

[[Пертнери BAS - партнери росії]]

[[Скільки грошей 1С намагається “збити” з українського бізнесу через листи щастя]]

[[Не продовжуйте ІТС на BAS. Бо BAS — це 1С]]

[[Вали російський бізнес, вали російський софт!]]

[[Програмне забезпечення, яким можна замінити ворожий софт]]

[[Докази, що BAS - це 1С]]

[[Список компаній, що розповсюджують BAS, не дивлячись на санкції січня 2026]]

[[Реєстр ворожого ПЗ і пов'язаних назв]]

[[Компанії, що почали переходити з ворожого софту]]

[[Реєстр компаній, що досі працюють на ворожому софті]]

[[Реєстр сервісів, що підтримують інтеграцію з ворожим софтом]]

== Реформи ==
[[Реформи К2]]

== Wikipedia ==
[[Різні статті]]

== Книги ==
[[Архітектура 1С-підприємства]]

[[Архітектура та розробка ERP-систем]]

Регістри в K2 ERP

2026-07-17T19:40:20Z

{{DISPLAYTITLE:ТЗ. Підсистема регістрів K2 ERP}}
__TOC__

= 1. Паспорт документа =

{| class="wikitable"
! Атрибут !! Значення
|-
| Назва || Технічне завдання на розробку підсистеми «Регістри» платформи K2 ERP
|-
| Шифр || K2-ERP-TZ-REG-001
|-
| Версія || 1.2 (чернетка на узгодження; мова ядра — Python; +Додатки Д, Е)
|-
| Статус || На розгляді
|-
| Замовник || ''[підрозділ-замовник]''
|-
| Виконавець || ''[команда платформи K2 ERP]''
|-
| Тип документа || Технічне завдання (ГОСТ 34.602 адаптовано)
|-
| Аналог / прототип || Механізм регістрів платформи «1С:Підприємство 8.3»
|-
| Мова розробки || '''Python 3.12+''' (див. розділ 4.3)
|-
| Технологічний стек || SQLAlchemy Core 2.x, Pydantic v2, Alembic, lark, psycopg 3 / pyodbc
|-
| СКБД || PostgreSQL 14+ (основна), MS SQL Server 2019+ (додаткова)
|}

== 1.1. Необхідні розширення MediaWiki ==

{| class="wikitable"
! Розширення !! Теги / шаблони !! Використано в документі !! Постачання
|-
| '''Extension:Diagrams''' || <code><nowiki><graphviz></nowiki></code>, <code><nowiki><uml></nowiki></code> || 4 діаграми GraphViz + 5 діаграм PlantUML || Composer: <code>samwilson/diagrams</code>
|-
| Extension:SyntaxHighlight || <code><nowiki><syntaxhighlight></nowiki></code> || 64 блоки коду (Python, SQL, YAML, lark) || '''Входить до складу MediaWiki''' — окремо встановлювати не потрібно
|-
| <code>Template:Note</code> || <code><nowiki>{{Note|текст}}</nowiki></code> || Примітки та проєктні рішення || Створюється вручну (код нижче)
|}

=== Налаштування ===

<syntaxhighlight lang="php">
// LocalSettings.php — конфігурація ВІКІ, у якій публікується це ТЗ.
// MediaWiki написана на PHP; до мови розробки K2 ERP (Python, розділ 4.3) це не стосується.
wfLoadExtension( 'Diagrams' );

// ОБОВ'ЯЗКОВО. За замовчуванням Diagrams рендерить у PNG; ER-діаграми розділу 9
// містять десятки колонок і в растрі нечитабельні.
$wgDiagramsDefaultFormat = 'svg';

// Варіант А — локальний рендеринг (потрібні бінарники на веб-сервері):
// apt install graphviz plantuml
// Варіант Б — зовнішній сервіс рендерингу (з версії 0.4.0 — опційний):
// $wgDiagramsServiceUrl = 'https://diagrams.example.com/subdir';
</syntaxhighlight>

Шаблон <code>Template:Note</code>, якщо його немає у вікі:
<pre>
<div style="border-left:4px solid #36c; background:#eaf3ff; padding:8px 12px; margin:8px 0;">
'''ⓘ''' {{{1}}}
</div>
</pre>

=== Вимоги до версії ===

{{Note|'''Мінімальна версія — 1.0.0''' (реліз від 15.03.2026). Саме в ній додано <code>$wgDiagramsDefaultFormat</code>, без якого документ рендериться в PNG і ER-діаграми розділу 9 стають нечитабельними. Автор супроводжує підняття мажорної версії до 1 формулюванням, що проєкт вийшов на стабільність.}}

{{Note|'''Інфобокс на mediawiki.org станом на дату складання ТЗ застарілий''' — показує версію 0.10.0 (2022) і сумісність «MediaWiki ≤ 1.39», тоді як у репозиторії 27 релізів і остання — 1.0.0 від 15.03.2026. '''Джерело істини — GitHub''' (<nowiki>https://github.com/samwilson/diagrams-extension/releases</nowiki>), а не інфобокс вікі-сторінки.}}

=== Кодування: обов'язкове налаштування ===

{{Note|'''Найчастіша поломка цього документа.''' Якщо кирилиця в діаграмах виводиться як <code>◆◆◆◆◆◆</code> (U+FFFD), проблема '''не в шрифтах''', а в кодуванні. Java до версії 18 бере <code>file.encoding</code> з локалі процесу. Якщо веб-сервер працює з <code>LANG=C</code> або без локалі, PlantUML читає вхід як US-ASCII, і '''кожен байт UTF-8 понад 127 перетворюється на окремий <code>�</code>'''.}}

'''Як відрізнити дві різні проблеми:'''

{| class="wikitable"
! Симптом !! Діагноз !! Що робити
|-
| <code>����</code> — ромби зі знаком питання (U+FFFD). Кількість символів '''більша''' за кількість літер оригіналу: 1 кирилична літера → 2 ромби, стрілка <code>→</code> → 3 ромби || '''Кодування.''' Байти UTF-8 декодовані як ASCII/Latin-1 — по одному <code>�</code> на байт || Розділ нижче, п. «Виправлення»
|-
| <code>□□□□</code> — порожні прямокутники (tofu). Кількість '''збігається''' з кількістю літер || '''Шрифти.''' Кодування правильне, але у шрифті немає гліфів кирилиці || <code>apt install fonts-dejavu fonts-liberation</code>. У документі вже проставлено <code>skinparam defaultFontName "DejaVu Sans"</code> і <code>fontname="DejaVu Sans"</code> для GraphViz
|-
| <code>Ð¿ÑÐ¸Ð²ÑÑ</code> — «мохібейк» із латиниці з діакритикою || Подвійне перекодування UTF-8 ↔ Latin-1 || Перевірити <code>$wgDiagramsServiceUrl</code> — сервіс віддає не UTF-8
|}

'''Діагностика (на сервері вікі):'''

<syntaxhighlight lang="bash">
# 1. Що каже сам PlantUML про своє кодування
java -jar /usr/share/plantuml/plantuml.jar -version | grep -i "Default Encoding"
# Default Encoding: UTF-8 <- норма
# Default Encoding: ANSI_X3.4-1968 <- ЦЕ ПРИЧИНА (це US-ASCII)
# Default Encoding: ISO-8859-1 <- ЦЕ ПРИЧИНА

# 2. Локаль процесу веб-сервера (а не вашого shell — вони різні!)
sudo -u www-data env | grep -E 'LANG|LC_'
# порожньо або LANG=C / LANG=POSIX -> причина

# 3. Відтворення поза MediaWiki — ізолює проблему від вікі
printf '@startuml
A -> B : кирилиця та стрілка â
@enduml
' | java -jar /usr/share/plantuml/plantuml.jar -pipe -tsvg > /tmp/test.svg
grep -c 'кирилиця' /tmp/test.svg # 1 = добре; 0 = поламано

# 4. Чи є шрифти з кирилицею
java -jar /usr/share/plantuml/plantuml.jar -printfonts | grep -i dejavu
</syntaxhighlight>

'''Виправлення''' (за спаданням надійності — досить одного, але п. 1–2 разом надійніші):

<syntaxhighlight lang="php">
// LocalSettings.php

// СПОСІБ 1 (рекомендований): задати кодування явно в команді PlantUML.
// $wgDiagramsLocalCommands перевизначає команди локального рендерингу.
$wgDiagramsLocalCommands = [
'plantuml' => '/usr/bin/java -Dfile.encoding=UTF-8 '
. '-jar /usr/share/plantuml/plantuml.jar -charset UTF-8',
];
</syntaxhighlight>

<syntaxhighlight lang="bash">
# СПОСІБ 2: локаль процесу веб-сервера (systemd drop-in)
# /etc/systemd/system/php8.2-fpm.service.d/locale.conf
[Service]
Environment=LANG=C.UTF-8
Environment=LC_ALL=C.UTF-8
# далі: systemctl daemon-reload && systemctl restart php8.2-fpm

# СПОСІБ 3 (найчистіший): Java 18+.
# JEP 400 зробив UTF-8 кодуванням за замовчуванням незалежно від локалі ОС —
# проблема зникає структурно, без прапорців.
java -version
</syntaxhighlight>

{{Note|Спосіб 3 усуває цілий клас проблем і не лише для PlantUML. Якщо на сервері вікі Java 17 або старіша — це найкраща інвестиція з трьох.}}

=== Смоук-тест перед публікацією ===

Прогнати на цільовій вікі — по одному представнику кожного типу:

{| class="wikitable"
! # !! Що перевіряємо !! Де в документі !! Ознака успіху
|-
| 1 || '''Кодування кирилиці''' || 9.1 (підписи зв'язків) || Читається «є регістром», а не <code>���</code>. '''Перевіряти першим''' — решта тестів без цього безглузді
|-
| 2 || Гліфи кирилиці у шрифті || 5.1, 6.1 || Немає <code>□□□</code>
|-
| 3 || <code><nowiki><graphviz></nowiki></code>: <code>rankdir</code>, <code>shape=record</code>, <code>cylinder</code> || 5.1, 6.1, 8.8, 9.5, Д.1, Д.8 || Діаграма рендериться, підписи не обрізані
|-
| 4 || <code><nowiki><uml></nowiki></code> + <code>@startuml</code>, <code>entity</code>, <code>skinparam linetype ortho</code> || 9.1–9.4 || ER-модель із колонками та позначками PK/FK
|-
| 5 || '''<code><nowiki><uml></nowiki></code> + <code>@startgantt</code>''' || '''7.5.1''' || Діаграма Ганта. '''Головний ризик:''' якщо розширення обгортає вміст у <code>@startuml</code> автоматично, <code>@startgantt</code> не спрацює
|-
| 6 || <code>$wgDiagramsDefaultFormat = 'svg'</code> || будь-яка || У HTML сторінки <code><img src="…<b>.svg</b>"></code>, а не <code>.png</code>
|-
| 7 || GraphViz присутній для PlantUML || 9.1–9.4 || Немає повідомлення «Dot executable does not exist». PlantUML використовує dot для розкладки — <code>plantuml</code> без <code>graphviz</code> зрендерить лише sequence-діаграми (7.1), а ER-моделі — ні
|}

{{Note|'''Щодо п. 5.''' Документ використовує явні роздільники <code>@startuml…@enduml</code> / <code>@startgantt…@endgantt</code> всередині тегів. Це відповідає нормалізованій поведінці PlantUML: розробники вимагають <code>@startXYZ</code> усюди, зокрема з прапорцем <code>-pipe</code>, а можливість опускати роздільник збережена лише як застаріла опція для сумісності зі старими скриптами. Перевірити на живій вікі я не мав змоги — це єдине непідтверджене припущення розділу. Якщо <code>@startgantt</code> не відрендериться, замінити діаграму 7.5.1 на <code><nowiki><graphviz></nowiki></code> або повернути ASCII-схему з історії правок.}}

=== Альтернативи та запасний варіант ===

{| class="wikitable"
! Варіант !! Оцінка
|-
| '''Extension:Diagrams ≥ 1.0.0''' ''(обрано)'' || Одне розширення на всі формати документа; не зберігає рендери як файли вікі; є дві реалізації сервісу рендерингу — PHP (Symfony) та '''Python''' (остання узгоджується зі стеком проєкту, розділ 4.3).
|-
| Extension:GraphViz + Extension:PlantUML окремо || '''Не рекомендується.''' Extension:GraphViz за даними трекера Wikimedia не супроводжується й потребує правок для роботи з актуальними версіями MediaWiki. Два розширення замість одного.
|-
| Mermaid (<code><nowiki><mermaid></nowiki></code> у складі Diagrams або Extension:Mermaid) || Рендериться на клієнті, не потребує бінарників на сервері. Але <code>erDiagram</code> Mermaid суттєво менш виразний за <code>entity</code> PlantUML: ER-моделі розділу 9 містять типи, ознаки PK/FK та коментарі до полів — це не переноситься без втрат. Придатний для простих схем (5.1, Д.1).
|-
| Без розширень || Блоки діаграм відображатимуться як вихідний текст. '''Документ втрачає 9 із 12 схем''' — на відміну від версій ≤ 1.2, ASCII-дублів більше немає (див. нижче).
|}

=== Що навмисно залишено ASCII-схемами ===

Після переходу на Diagrams дублювання «діаграма + ASCII» прибрано: воно розходилося при правках. Але 8 блоків <code><nowiki><pre></nowiki></code> залишено свідомо — для них Diagrams не дає виграшу:

{| class="wikitable"
! Розділ !! Блок !! Чому не діаграма
|-
| 6.8.1–6.8.3 || Макети конструктора || PlantUML має <code>@startsalt</code> для wireframe'ів, але ASCII тут '''комунікує краще''': він явно читається як ескіз і не створює хибного враження затвердженого дизайну. Salt додає рендер-ризик без користі.
|-
| 7.4.1 || Timeline підсумків і ТА || Схема несе формулу («Залишок = Підсумок(P) + Σ рухів») поряд із віссю часу. Gantt це не передає, а <code>@startuml</code> timing — надмірність.
|-
| Д.9 || Наскрізний розрахунок ЗП || Це покроковий наратив із числами, а не структура. Діаграма не додасть змісту.
|-
| Д.11, Е.8 || Чек-лист і дерево репозиторію || Список і файлове дерево. <code><nowiki><pre></nowiki></code> — рівно те, що треба.
|}

= 2. Терміни, визначення та скорочення =

{| class="wikitable"
! Термін !! Визначення
|-
| '''Регістр''' || Об'єкт метаданих, призначений для зберігання та накопичення структурованої облікової інформації у вигляді записів фіксованої структури, з механізмами агрегації, зрізів і транзакційного зв'язку з документами-реєстраторами.
|-
| '''РВ''' || Регістр відомостей (аналог «Регистр сведений»).
|-
| '''РН''' || Регістр накопичення (аналог «Регистр накопления»).
|-
| '''РБ''' || Регістр бухгалтерії (аналог «Регистр бухгалтерии»).
|-
| '''РР''' || Регістр розрахунку (аналог «Регистр расчёта»).
|-
| '''Вимірювання''' (Dimension) || Поле регістру, що визначає розріз аналітики; входить у ключ запису/підсумку.
|-
| '''Ресурс''' (Resource) || Поле регістру, значення якого підсумовується (для РН/РБ/РР) або зберігається як значення (для РВ).
|-
| '''Реквізит''' (Attribute) || Довідкове поле запису, що не бере участі в ключі та не агрегується.
|-
| '''Реєстратор''' (Recorder) || Документ, який породив набір записів регістру та володіє ним.
|-
| '''Рухи''' (Movements) || Записи регістру, підпорядковані конкретному реєстратору.
|-
| '''Набір записів''' (RecordSet) || Прикладний об'єкт для читання/запису групи записів регістру за заданим відбором.
|-
| '''Підсумки''' (Totals) || Попередньо розраховані агрегати (залишки/обороти), що зберігаються в окремих таблицях.
|-
| '''ТА''' || Точка актуальності підсумків — момент часу, до якого підсумки розраховані.
|-
| '''Зріз останніх''' (SliceLast) || Вибірка останніх за періодом записів РВ у розрізі кожної комбінації вимірювань.
|-
| '''Субконто''' (ExtDimension, ED) || Додатковий розріз аналітики бухгалтерського рахунку.
|-
| '''ПВР''' || План видів розрахунку.
|-
| '''Витіснення''' || Механізм РР: запис із вищим пріоритетом скорочує фактичний період дії запису з нижчим.
|-
| '''Перерахунок''' (Recalculation) || Підпорядкований РР об'єкт, що реєструє записи, які потребують повторного розрахунку.
|-
| '''Віртуальна таблиця''' || Обчислювана таблиця в мові запитів, що не має фізичного відповідника (Залишки, Обороти, ЗрізОстанніх тощо).
|}

= 3. Призначення, цілі та підстава розробки =

== 3.1. Підстава ==
Поточна модель K2 ERP не має уніфікованого декларативного механізму накопичувального обліку. Регістроподібні структури реалізуються ''ad hoc'' — окремими таблицями та процедурами під кожну прикладну задачу, що спричиняє:
* дублювання коду розрахунку залишків та оборотів;
* відсутність гарантованої узгодженості «документ ↔ рухи»;
* деградацію продуктивності на великих обсягах (повний перерахунок з початку обліку);
* високу вартість введення нової аналітики (зміна схеми БД + правка десятків процедур).

== 3.2. Мета ==
Створити в K2 ERP підсистему '''декларативно описуваних регістрів''' чотирьох типів, функціонально еквівалентну механізму регістрів «1С:Підприємство 8.3», з автоматичною генерацією схеми БД, підтримкою підсумків, віртуальних таблиць у мові запитів і транзакційного проведення документів.

== 3.3. Цілі проєкту (вимірювані) ==
{| class="wikitable"
! № !! Ціль !! Критерій досягнення
|-
| Ц1 || Декларативне визначення регістру || Новий регістр з 5 вимірюваннями та 3 ресурсами створюється в конструкторі без написання коду; DDL генерується автоматично.
|-
| Ц2 || Автоматична агрегація || Залишки/обороти доступні запитом без ручних процедур перерахунку.
|-
| Ц3 || Продуктивність || Отримання залишків на дату за таблицею 1 млрд рухів — ≤ 200 мс (P95) на еталонному стенді.
|-
| Ц4 || Цілісність || Неможливість існування рухів без активного реєстратора (100 % сценаріїв у тесті цілісності).
|-
| Ц5 || Міграція || Перенесення ≥ 90 % наявних «регістроподібних» структур K2 на новий механізм без втрати даних.
|}

== 3.4. Що НЕ входить до обсягу (Out of scope) ==
* Механізм розподілених інформаційних баз / реплікації рухів (окреме ТЗ).
* Візуальний конструктор звітів поверх регістрів (окреме ТЗ, залежність).
* OLAP-куби та зовнішні аналітичні вітрини.
* Автоматичне перенесення прикладного коду замовника (тільки дані + мапінг).

= 4. Припущення та обмеження щодо платформи K2 ERP =

{{Note|Розділ фіксує припущення, які '''обов'язково''' підлягають верифікації з архітектором платформи до затвердження ТЗ. Місця, що потребують уточнення, позначені як ''[уточнити]''.}}

== 4.1. Припущення щодо платформи ==

{| class="wikitable"
! № !! Припущення !! Наслідок для ТЗ
|-
| П1 || K2 ERP має підсистему метаданих із власним репозиторієм об'єктів (документи, довідники, перерахування) і механізмом версіонування конфігурації. || Регістр вбудовується як новий '''рід''' об'єкта метаданих у наявний репозиторій (розділ 6).
|-
| П2 || Об'єкти-документи мають унікальний ідентифікатор посилання (GUID/UUID) та проведення як окрему операцію. || Реєстратор адресується парою «код типу + UUID» (розділ 8.2).
|-
| П3 || Платформа має власну мову запитів або транслятор у SQL. || Віртуальні таблиці реалізуються на рівні транслятора (розділ 7.6). Якщо мови запитів немає — потрібен окремий етап Е0 (розділ 14).
|-
| П4 || Цільова СКБД підтримує <code>MERGE</code>/<code>INSERT ... ON CONFLICT</code>, віконні функції, часткові та покривні індекси. || Алгоритми підсумків (розділ 10) використовують ці можливості.
|-
| П5 || Прикладний код виконується на сервері застосунків із керованими транзакціями. || Проведення документа — одна транзакція БД (розділ 7.1).
|-
| П6 || Максимальна довжина ідентифікатора об'єкта БД — 63 символи (PostgreSQL). || Фізичні імена таблиць будуються за сурогатним числовим кодом, а не за іменем регістру (розділ 8.1).
|-
| П7 || Ядро платформи розробляється на '''Python 3.12+'''; допускаються C-розширення (binary-драйвери) та, за потреби, власні нативні модулі. || Визначає стек (4.3) і архітектурні принципи АП-1…АП-6 (4.4). ''[верифікувати: greenfield чи є наявний Python-код K2]''
|-
| П8 || Прикладний (конфігураційний) код пишеться '''також на Python''' і виконується в тому самому процесі. || Породжує питання ізоляції та безпеки виконання довільного коду — '''відкрите питання В12'''. Якщо припущення хибне (потрібна вбудована мова) — обсяг Е1 зростає на ~2 чол.-міс.
|}

== 4.2. Обмеження ==

* О1. Зміна складу вимірювань/ресурсів існуючого регістру — операція реструктуризації з простоєм; онлайн-міграція не гарантується для таблиць > 100 млн записів.
* О2. Підсистема не гарантує коректність прикладної логіки проведення — лише цілісність механізму.
* О3. Мінімальна дискретність періоду — 1 секунда (тип <code>timestamp(0)</code>) ''[уточнити: чи потрібна мілісекундна]''.

== 4.3. Технологічний стек ==

{| class="wikitable"
! Шар !! Технологія !! Обґрунтування вибору
|-
| Мова ядра || '''Python 3.12+''' (цільова 3.12; щодо 3.13 — див. В14) || Рішення замовника. Наслідки — розділ 4.4.
|-
| Статична типізація || <code>mypy --strict</code> як gate у CI || Ядро метаданих у динамічній мові без статичної перевірки — неприйнятний ризик (Р11).
|-
| Опис і валідація метаданих || '''Pydantic v2''' || Маніфест регістру (розділ 6.7) стає типізованою моделлю: валідація, крос-полеві правила та JSON Schema для конструктора — «безкоштовно». Покриває ФТ-К-01. Приклад — Е.1.
|-
| Генерація DDL, абстракція діалектів СКБД || '''SQLAlchemy Core 2.x''' (''без ORM'') || Ключовий вибір. <code>MetaData</code>/<code>Table</code>/<code>Column</code> — готова модель схеми; діалекти PostgreSQL і MS SQL із коробки. Прямо закриває НФВ-16, НФВ-17 і знижує ризик Р7. Приклад — Е.2.
|-
| Міграції / реструктуризація || '''Alembic''' || Автогенерація <code>ALTER</code> при зміні складу полів (Е10, НФВ-13, НФВ-15).
|-
| Драйвери || '''psycopg 3''' (binary, pipeline mode) або <code>asyncpg</code>; <code>pyodbc</code> для MS SQL || Pipeline mode критичний для АП-1: пакетна вставка без round-trip на рядок.
|-
| Парсер мови запитів || '''lark''' (LALR) → AST → SQLAlchemy Core || Етап Е5. Дешевше за власний парсер; граматика декларативна. Ескіз — Е.4.
|-
| Гарячі шляхи || '''Cython''' / <code>mypyc</code>; за потреби '''Rust''' (PyO3 + maturin) || Тільки за результатами бенчмарку (АП-3, Р10, В13).
|-
| Сервер застосунків || FastAPI + uvicorn; окремий пул процесів для проведення || —
|-
| Паралелізм || '''Процеси''' + <code>asyncio</code> для IO. '''Потоки — ні''' (GIL) || Принцип АП-5.
|-
| Тестування || pytest, pytest-benchmark, '''hypothesis''' (property-based), testcontainers || Hypothesis обов'язковий для витіснення (Р5): інтервальна арифметика — ідеальний кандидат на property-based тести.
|-
| Профілювання || py-spy, scalene, <code>EXPLAIN (ANALYZE, BUFFERS)</code> || Етап Е11.
|-
| Збірка || uv, ruff, wheels із нативними розширеннями під усі цільові платформи || —
|}

'''Явні заборони:'''
* '''ORM SQLAlchemy не використовується.''' Регістри працюють наборами записів, а не об'єктами; identity map і lazy loading тут шкідливі й провокують порушення АП-1. Використовується '''лише Core'''.
* '''PyPy не розглядається''' — несумісність із binary-драйверами та нативними розширеннями.
* '''Free-threaded build (PEP 703)''' — моніторити, але не закладати в архітектуру (В14).

== 4.4. Наслідки вибору Python: архітектурні принципи ==

Python на CPU-навантаженні повільніший за компільовані мови приблизно в 30–80 разів. Проєктована архітектура цьому '''не суперечить''': основну роботу виконує СКБД, а ядро лише формує SQL. Але це вірно '''тільки за умови''' дотримання наведених принципів — їх порушення робить цілі НФВ недосяжними.

{| class="wikitable"
! ID !! Принцип !! Формулювання
|-
| '''АП-1''' || '''«Жодного рядка за раз»''' || '''Заборонено:''' цикл Python із запитом до БД усередині; вставка рухів по одному; читання підсумків по одному ключу. '''Обов'язково:''' <code>executemany</code> / <code>COPY</code> / pipeline, set-based <code>MERGE</code>, один запит на набір записів. Детектор порушень — Е.7.
|-
| '''АП-2''' || '''Ядро — оркестратор, СКБД — обчислювач''' || Python формує SQL і передає керування. Агрегація, з'єднання, сортування — в СКБД. Виняток — гарячі шляхи АП-4, де це неможливо.
|-
| '''АП-3''' || '''Гарячі шляхи ізольовані за інтерфейсом''' || Кожен кандидат на нативне переписування реалізується за <code>Protocol</code>-інтерфейсом з еталонною Python-реалізацією та бенчмарком у CI. Заміна на Cython/Rust не змінює виклик. Приклад — Е.5.
|-
| '''АП-4''' || '''Бюджет Python-часу зафіксовано''' || Див. 4.4.1. Перевищення бюджету — блокер приймання етапу.
|-
| '''АП-5''' || '''Паралелізм — процесами''' || GIL робить потоки марними для CPU-роботи. Проведення IO-bound → <code>asyncio</code>; масштабування — пулом процесів за кількістю ядер.
|-
| '''АП-6''' || '''Типізація на межах''' || <code>mypy --strict</code> на ядрі; Pydantic v2 на всіх межах. Динамічний доступ до полів регістру компенсується генерацією <code>.pyi</code>-стабів (ФТ-К-07, Е.6).
|}

=== 4.4.1. Бюджет Python-часу на гарячих шляхах (АП-4) ===

{| class="wikitable"
! Шлях !! Розділ !! Обсяг операцій !! Оцінка Python !! Ризик !! Мітигація
|-
| Формування рухів документа (100 рядків × 5 регістрів) || 7.1, Д.8 || ~500 конструювань об'єктів || 2–5 мс || Низький || —
|-
| Серіалізація рухів у пакетну вставку || 7.1 || ~500 кортежів || 1–3 мс || Низький || psycopg 3 pipeline / <code>COPY</code>
|-
| Оновлення підсумків || 10.2 || 1 SQL <code>MERGE</code> на регістр || ≈ 0 мс || Низький || set-based (Е.3)
|-
| Трансляція віртуальної таблиці || 7.3, 10.3 || парсинг + побудова AST || 1–10 мс || Середній || LRU-кеш скомпільованих запитів за хешем (текст + сигнатура параметрів)
|-
| '''Витіснення періодів дії''' || 10.4 || O(\|Z\|²) на ключ; 10 тис. ключів × ~10 записів ≈ 10<sup>6</sup> інтервальних операцій || '''1–3 с''' || '''Високий''' || Sweep-line O(n log n); ізоляція за АП-3; кандидат №1 на Cython/Rust; альтернатива — перенести в SQL на <code>daterange</code> + GiST (PostgreSQL)
|-
| '''Розрахунок ЗП''' || Д.9 || 80 тис. записів × формула || '''4–15 с''' || '''Високий''' || Заборона per-record запитів (АП-1); векторизація; кандидат №2 на нативний код
|-
| Реєстрація перерахунків || 10.5 || 1 SQL <code>INSERT … SELECT</code> || ≈ 0 мс || Низький || set-based
|-
| Генерація DDL, реструктуризація || 8, Е.2 || холодний шлях, разова операція || — || Низький || —
|}

=== 4.4.2. Висновок щодо НФВ ===

{| class="wikitable"
! НФВ !! Ціль !! Частка Python !! Вердикт
|-
| НФВ-01…03 (залишки, обороти) || 200 мс – 2 с || < 1 % (робота в СКБД) || '''Не залежить від мови ядра'''
|-
| НФВ-04 (проведення 100 рядків) || 300 мс || 5–15 мс ≈ '''5 %''' || Досяжно за дотримання АП-1
|-
| НФВ-05 (ОСВ) || 5 с || < 1 % || Не залежить від мови ядра
|-
| НФВ-06 (ЗП на 10 тис. осіб) || 10 хв || 4–15 с ≈ '''2,5 %''' || Досяжно; '''запас ×40'''
|-
| НФВ-07 (зріз останніх) || 500 мс || < 1 % || Не залежить від мови ядра
|-
| НФВ-08 (50 док/с) || — || 50 × 10 мс = 0,5 с CPU/с ≈ '''50 % одного ядра''' || Досяжно; пул процесів (АП-5)
|-
| НФВ-09 (перерахунок підсумків) || 4 год || < 1 % || Не залежить від мови ядра
|}

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

= 5. Класифікація регістрів =

== 5.1. Дерево типів ==

<graphviz>
digraph Registers {
rankdir=TB;
bgcolor="transparent";
node [shape=box, style="rounded,filled", fillcolor="#f5f5f5", fontname="DejaVu Sans", fontsize=10];
edge [fontname="DejaVu Sans", fontsize=8];

R [label="РЕГІСТР\n(абстрактний об'єкт метаданих)", fillcolor="#dbe9ff"];

RI [label="Регістр відомостей\n(РВ / Information)", fillcolor="#e8f5e9"];
RA [label="Регістр накопичення\n(РН / Accumulation)", fillcolor="#fff8e1"];
RB [label="Регістр бухгалтерії\n(РБ / Accounting)", fillcolor="#fce4ec"];
RC [label="Регістр розрахунку\n(РР / Calculation)", fillcolor="#ede7f6"];

R -> RI; R -> RA; R -> RB; R -> RC;

RI_np [label="Неперіодичний"];
RI_p [label="Періодичний"];
RI -> RI_np; RI -> RI_p;

RI_i [label="Незалежний\n(режим запису)", shape=note, fillcolor="#ffffff"];
RI_s [label="Підпорядкований\nреєстратору", shape=note, fillcolor="#ffffff"];
RI -> RI_i [style=dashed]; RI -> RI_s [style=dashed];

RA_b [label="Вид: Залишки\n(Balance)"];
RA_t [label="Вид: Обороти\n(Turnover)"];
RA -> RA_b; RA -> RA_t;

RB_c [label="З кореспонденцією\n(подвійний запис)"];
RB_n [label="Без кореспонденції\n(уніграфічний)"];
RB -> RB_c; RB -> RB_n;

RC_a [label="З періодом дії\n(+ витіснення)"];
RC_b [label="З базовим періодом\n(+ база розрахунку)"];
RC_g [label="З графіком часу"];
RC -> RC_a; RC -> RC_b; RC -> RC_g;
}
</graphviz>

== 5.2. Порівняльна матриця типів ==

{| class="wikitable"
! Характеристика !! РВ !! РН (Залишки) !! РН (Обороти) !! РБ !! РР
|-
| Ключ запису || Вимірювання (+Період) або Реєстратор+№ || Реєстратор+№ || Реєстратор+№ || Реєстратор+№ || Реєстратор+№
|-
| Незалежний запис || '''Так''' || Ні || Ні || Ні || Ні
|-
| Періодичність || Опційна || Обов'язкова (Період) || Обов'язкова || Обов'язкова || Обов'язкова
|-
| Ресурси підсумовуються || Ні || Так (±) || Так (+) || Так (Дт/Кт) || Так
|-
| Вид руху (Прихід/Витрата) || — || '''Так''' || — || Дт/Кт || —
|-
| Таблиця залишків || — || '''Так''' || — || '''Так''' || —
|-
| Таблиця оборотів || — || Так (опц.) || '''Так''' || Так || —
|-
| Зв'язок із планом рахунків || — || — || — || '''Так''' || —
|-
| Зв'язок із ПВР || — || — || — || — || '''Так'''
|-
| Період дії / витіснення || — || — || — || — || '''Так'''
|-
| Базовий період || — || — || — || — || '''Так'''
|-
| Графік часу || — || — || — || — || '''Так'''
|-
| Субконто || — || — || — || '''Так''' || —
|-
| Перерахунки || — || — || — || — || '''Так'''
|-
| Типові приклади || Курси валют, ціни, кадрова історія, графік роботи || Товари на складах, взаєморозрахунки || Продажі, витрати за статтями || Госпрозрахунковий, управлінський, податковий облік || Нарахування ЗП, утримання
|}

= 6. Метамодель: як регістр задається =

== 6.1. Місце в репозиторії метаданих ==

<graphviz>
digraph ConfigTree {
rankdir=LR; bgcolor="transparent"; ranksep=0.35; nodesep=0.12;
node [shape=box, style="filled,rounded", fontname="DejaVu Sans", fontsize=9, height=0.28];
edge [arrowhead=none, color="#9e9e9e"];

CFG [label="Конфігурація K2 ERP", fillcolor="#cfd8dc"];

C1 [label="Довідники", fillcolor="#eceff1"];
C2 [label="Документи", fillcolor="#eceff1"];
C3 [label="Плани рахунків", fillcolor="#eceff1"];
C4 [label="Плани видів характеристик", fillcolor="#eceff1"];
C5 [label="Плани видів розрахунку", fillcolor="#eceff1"];
REG [label="РЕГІСТРИ", fillcolor="#1976d2", fontcolor="white"];

CFG -> C1; CFG -> C2; CFG -> C3; CFG -> C4; CFG -> C5; CFG -> REG [penwidth=2, color="#1976d2"];

RI [label="Регістри відомостей", fillcolor="#e8f5e9"];
RA [label="Регістри накопичення", fillcolor="#fff8e1"];
RB [label="Регістри бухгалтерії", fillcolor="#fce4ec"];
RC [label="Регістри розрахунку", fillcolor="#ede7f6"];
REG -> RI; REG -> RA; REG -> RB; REG -> RC;

RI1 [label="КурсиВалют", fillcolor="#ffffff"];
RI -> RI1;
RI1d [label="Вимірювання: Валюта", shape=note, fillcolor="#fafafa", fontsize=8];
RI1r [label="Ресурси: Курс, Кратність", shape=note, fillcolor="#fafafa", fontsize=8];
RI1 -> RI1d; RI1 -> RI1r;

RA1 [label="ТовариНаСкладах", fillcolor="#ffffff"];
RA -> RA1;
RA1d [label="Вимірювання:\lНоменклатура\lСклад\lПартія\l", shape=note, fillcolor="#fafafa", fontsize=8];
RA1r [label="Ресурси: Кількість, Сума", shape=note, fillcolor="#fafafa", fontsize=8];
RA1a [label="Реквізити: Коментар", shape=note, fillcolor="#fafafa", fontsize=8];
RA1x [label="Реєстратори:\lПрихіднаНакладна\lВидатковаНакладна\l…\l", shape=note, fillcolor="#fafafa", fontsize=8];
RA1 -> RA1d; RA1 -> RA1r; RA1 -> RA1a; RA1 -> RA1x;

RB1 [label="Госпрозрахунковий", fillcolor="#ffffff"];
RB -> RB1;
RB1d [label="Вимірювання:\lОрганізація (баланс.)\lПідрозділ (небаланс.)\l", shape=note, fillcolor="#fafafa", fontsize=8];
RB1r [label="Ресурси:\lСума (баланс.)\lКількість\lВалютнаСума\l", shape=note, fillcolor="#fafafa", fontsize=8];
RB1 -> RB1d; RB1 -> RB1r;
RB1 -> C3 [style=dotted, color="#c2185b", arrowhead=vee, label="ПланРахунків", fontsize=7];

RC1 [label="Нарахування", fillcolor="#ffffff"];
RC -> RC1;
RC1d [label="Вимірювання:\lСпівробітник (базове)\lПідрозділ\l", shape=note, fillcolor="#fafafa", fontsize=8];
RC1r [label="Ресурси:\lРезультат\lВідпрацьованоДнів\l", shape=note, fillcolor="#fafafa", fontsize=8];
RC1p [label="Перерахунки:\lПерерахунокЗаБазою\l", shape=note, fillcolor="#fafafa", fontsize=8];
RC1 -> RC1d; RC1 -> RC1r; RC1 -> RC1p;
RC1 -> C5 [style=dotted, color="#5e35b1", arrowhead=vee, label="ПВР", fontsize=7];
}
</graphviz>

== 6.2. Загальні властивості будь-якого регістру ==

{| class="wikitable"
! Властивість !! Тип !! Обов'язк. !! Опис / допустимі значення
|-
| <code>Ім'я</code> || Ідентифікатор || Так || Унікальне в межах роду. Латиниця/кирилиця, ≤ 80 симв., без пробілів.
|-
| <code>Синонім</code> || Рядок || Ні || Подання для користувача.
|-
| <code>Коментар</code> || Текст || Ні || —
|-
| <code>ВидРегістру</code> || Перелік || Так || <code>Відомостей</code> / <code>Накопичення</code> / <code>Бухгалтерії</code> / <code>Розрахунку</code>. '''Незмінна після створення.'''
|-
| <code>РежимЗапису</code> || Перелік || Так || <code>Незалежний</code> / <code>ПідпорядкованийРеєстратору</code>. Для РН/РБ/РР — примусово <code>ПідпорядкованийРеєстратору</code>.
|-
| <code>Періодичність</code> || Перелік || Так || <code>Неперіодичний</code>, <code>ВМежахСекунди</code>, <code>ВМежахДня</code>, <code>ВМежахМісяця</code>, <code>ВМежахКварталу</code>, <code>ВМежахРоку</code>, <code>ПоПозиціїРеєстратора</code>.
|-
| <code>Реєстратори</code> || Список посилань на типи документів || Умовно || Обов'язково для РН/РБ/РР та підпорядкованого РВ. Порожній список = регістр непридатний до запису.
|-
| <code>БлокуванняДаних</code> || Перелік || Ні || <code>Автоматичне</code> / <code>Кероване</code> (за замовчуванням <code>Кероване</code>).
|-
| <code>ВключатиДоЗвітів</code> || Булево || Ні || Показувати в універсальному конструкторі звітів.
|-
| <code>ПравоДоступуЗаЗамовчуванням</code> || Перелік || Ні || <code>Заборонено</code> / <code>Читання</code>.
|-
| <code>ВикористовуватиРLS</code> || Булево || Ні || Row-level security (розділ 7.9).
|-
| <code>Партиціонування</code> || Структура || Ні || <code>Немає</code> / <code>ЗаПеріодом(RANGE, крок)</code> / <code>ЗаВимірюванням(HASH, n)</code>.
|}

== 6.3. Поля регістру ==

Кожне поле має:
{| class="wikitable"
! Властивість !! Опис
|-
| <code>Ім'я</code>, <code>Синонім</code> || Ідентифікація.
|-
| <code>Роль</code> || <code>Вимірювання</code> / <code>Ресурс</code> / <code>Реквізит</code>.
|-
| <code>Тип</code> || Примітивний (<code>Число(p,s)</code>, <code>Рядок(n)</code>, <code>Дата</code>, <code>Булево</code>, <code>УНІ</code>), посилальний (<code>Довідник.X</code>, <code>Документ.Y</code>, <code>Перерахування.Z</code>, <code>ПланРахунків.A</code>, <code>ПланВидівХарактеристик.B</code>) або '''складений''' (список типів).
|-
| <code>Індексувати</code> || <code>Не індексувати</code> / <code>Індексувати</code> / <code>ІндексуватиЗДодаткомВимірювань</code>.
|-
| <code>Ведуче</code> (Master) || Тільки для вимірювань. Якщо <code>Істина</code> — записи регістру видаляються разом з об'єктом, на який посилається вимірювання; регістр показується у формі цього об'єкта.
|-
| <code>ОсновнийВідбір</code> || Брати участь у стандартному відборі форми списку.
|-
| <code>ЗаборонитиНезаповненіЗначення</code> || Валідація на запис.
|}

Специфічні прапорці полів по типах регістрів:

{| class="wikitable"
! Прапорець !! Застосовний до !! Опис
|-
| <code>Балансовий</code> || Ресурс/Вимірювання РБ || Ресурс бере участь у контролі рівності Дт=Кт; має єдине значення на запис (а не пару Дт/Кт). Вимірювання балансове — однакове для Дт і Кт.
|-
| <code>Облік</code> (AccountingFlag) || Ресурс РБ || Посилання на ознаку обліку рахунка з ПР; ресурс заповнюється, лише якщо ознака встановлена.
|-
| <code>ОблікСубконто</code> || Ресурс РБ || Посилання на ознаку обліку субконто (напр. кількісний облік у розрізі субконто).
|-
| <code>Базове</code> (BaseDimension) || Вимірювання РР || Використовується для зіставлення записів під час отримання бази розрахунку.
|-
| <code>ВикористовуватиПоточніЗначення</code> || Ресурс/Реквізит РР || —
|}

== 6.4. Специфічні властивості за типами ==

=== 6.4.1. Регістр відомостей ===
{| class="wikitable"
! Властивість !! Значення !! Примітка
|-
| <code>Періодичність</code> || Неперіодичний … ПоПозиціїРеєстратора || Визначає наявність поля <code>Період</code> і його гранулярність.
|-
| <code>РежимЗапису</code> || Незалежний / ПідпорядкованийРеєстратору || У незалежному ключ = (Період) + Вимірювання.
|-
| <code>ОсновнийВідбір</code> || —
|-
| <code>ДозволитиПідсумки</code> || — || У РВ підсумків немає; замість них — зрізи.
|}

'''Ключ унікальності:'''
* Незалежний неперіодичний: <code>UNIQUE(Вимірювання…)</code>
* Незалежний періодичний: <code>UNIQUE(Період, Вимірювання…)</code>
* Підпорядкований: <code>PK(Реєстратор, НомерРядка)</code>, унікальність за вимірюваннями '''не''' контролюється.

=== 6.4.2. Регістр накопичення ===
{| class="wikitable"
! Властивість !! Значення
|-
| <code>ВидРегістру</code> || <code>Залишки</code> / <code>Обороти</code>
|-
| <code>ДозволитиПідсумкиЗалишків</code> || Булево (тільки для виду «Залишки»)
|-
| <code>ДозволитиПідсумкиОборотів</code> || Булево
|-
| <code>ПеріодичністьПідсумківОборотів</code> || <code>День</code> / <code>Місяць</code> (тільки для виду «Обороти»)
|-
| <code>Агрегати</code> || Список визначень агрегатів (тільки для виду «Обороти»), див. 7.4.4
|-
| <code>РежимАгрегатів</code> || <code>Агрегати</code> / <code>Підсумки</code>
|}

=== 6.4.3. Регістр бухгалтерії ===
{| class="wikitable"
! Властивість !! Значення !! Примітка
|-
| <code>ПланРахунків</code> || Посилання на об'єкт «План рахунків» || '''Обов'язково.''' Незмінне після створення.
|-
| <code>Кореспонденція</code> || Булево || <code>Істина</code> → подвійний запис (поля <code>РахунокДт</code>/<code>РахунокКт</code>); <code>Хиба</code> → уніграфічний (<code>Рахунок</code> + <code>ВидРуху</code>).
|-
| <code>ДозволитиРозділенняПідсумків</code> || Булево
|-
| <code>МаксКількістьСубконто</code> || Число (успадковується з ПР) || Ліміт платформи: 5 ''[узгодити; 1С — 3 за замовчуванням, до 5]''
|}

Пов'язаний об'єкт '''План рахунків''' повинен підтримувати:
* ієрархію рахунків, <code>Код</code>, <code>Найменування</code>, <code>Вид</code> (Активний/Пасивний/Активно-пасивний);
* <code>Забалансовий</code> (булево);
* <code>Ознаки обліку</code> (набір булевих реквізитів, напр. «Кількісний», «Валютний»);
* табличну частину <code>ВидиСубконто</code> (ВидСубконто → ПВХ, ''Тільки обороти'', ''Підсумкова сума'', ознаки обліку субконто);
* <code>МаксКількістьСубконто</code>.

=== 6.4.4. Регістр розрахунку ===
{| class="wikitable"
! Властивість !! Значення !! Примітка
|-
| <code>ПланВидівРозрахунку</code> || Посилання || '''Обов'язково.'''
|-
| <code>Періодичність</code> || <code>День</code>/<code>Місяць</code>/<code>Квартал</code>/<code>Рік</code> || Період реєстрації.
|-
| <code>ПеріодДії</code> || Булево || Вмикає поля <code>ПеріодДіїПочаток/Кінець</code>, фактичні періоди дії та витіснення.
|-
| <code>БазовийПеріод</code> || <code>БезБазовогоПеріоду</code> / <code>ЗаПеріодДії</code> / <code>ЗаПеріодРеєстрації</code> || Режим отримання бази.
|-
| <code>Графік</code> || Посилання на РВ || Регістр-графік часу.
|-
| <code>ЗначенняГрафіка</code> || Ресурс регістру-графіка || Напр. «Значення» (1/0 — робочий день) або «Годин».
|-
| <code>ДатаГрафіка</code> || Вимірювання регістру-графіка типу <code>Дата</code> || —
|-
| <code>Перерахунки</code> || Список підпорядкованих об'єктів «Перерахунок» || Див. 7.5.3.
|}

Об'єкт '''Перерахунок''' (підпорядкований РР):
* <code>Ім'я</code>;
* <code>Вимірювання</code> — список, кожне зіставляється з вимірюванням основного РР (<code>ВимірюванняРегістру</code>);
* правило: перерахунок реєструє «об'єкт перерахунку» = (Реєстратор, ВидРозрахунку, Вимірювання…).

'''План видів розрахунку''' повинен підтримувати:
* <code>ВикористовуєПеріодДії</code>;
* табличні частини <code>БазовіВидиРозрахунку</code>, <code>ВитісняючіВидиРозрахунку</code>, <code>ВедучіВидиРозрахунку</code>;
* <code>ЗалежністьВідБази</code>: <code>НеЗалежить</code> / <code>ЗаПеріодДії</code> / <code>ЗаПеріодРеєстрації</code>.

== 6.5. Стандартні реквізити (генеруються автоматично) ==

{| class="wikitable"
! Реквізит !! РВ !! РН !! РБ !! РР !! Тип
|-
| <code>Період</code> || якщо періодичний || + || + || + (період реєстрації) || Дата/час
|-
| <code>Реєстратор</code> || якщо підпорядкований || + || + || + || Складене посилання (ДокументПосилання)
|-
| <code>НомерРядка</code> || якщо підпорядкований || + || + || + || Число(9,0)
|-
| <code>Активність</code> || якщо підпорядкований || + || + || + || Булево
|-
| <code>ВидРуху</code> || — || тільки «Залишки» || — || — || Перелік {Прихід, Витрата}
|-
| <code>Рахунок</code> || — || — || + (без кореспонденції) || — || ПланРахунківПосилання
|-
| <code>РахунокДт</code>, <code>РахунокКт</code> || — || — || + (з кореспонденцією) || — || ПланРахунківПосилання
|-
| <code>ВидРухуРахунку</code> || — || — || + (без кореспонденції) || — || Перелік {Дебет, Кредит}
|-
| <code>Субконто</code> (колекція) || — || — || + || — || Відповідність(ВидСубконто→Значення)
|-
| <code>ВидРозрахунку</code> || — || — || — || + || ПВРПосилання
|-
| <code>ПеріодДіїПочаток</code>, <code>ПеріодДіїКінець</code> || — || — || — || + (якщо ПеріодДії) || Дата
|-
| <code>БазовийПеріодПочаток</code>, <code>БазовийПеріодКінець</code> || — || — || — || + (якщо БазовийПеріод) || Дата
|-
| <code>Сторно</code> || — || — || — || + || Булево
|}

== 6.6. Кількісні обмеження метамоделі ==

{| class="wikitable"
! Параметр !! Ліміт !! Примітка
|-
| Кількість вимірювань || 20 || Понад 8 — попередження конструктора (деградація підсумків)
|-
| Кількість ресурсів || 20 ||
|-
| Кількість реквізитів || 30 ||
|-
| Кількість типів у складеному типі поля || 32 ||
|-
| Кількість реєстраторів || Не обмежено ||
|-
| Максимум субконто на рахунок || 5 ||
|-
| Довжина ключа підсумків || ≤ 900 байт (обмеження індексу MS SQL) || Валідація в конструкторі
|-
| Глибина періодичності підсумків || День / Місяць || Тиждень/Квартал — не підтримуються (обчислюються згортанням)
|}

== 6.7. Декларативний опис (DSL) ==

Регістр зберігається в репозиторії у вигляді XML/YAML-маніфесту. Приклад:

<syntaxhighlight lang="yaml">
# --- Регістр накопичення (вид: Залишки) ---
register:
name: ТовариНаСкладах
kind: Accumulation
accumulationKind: Balance
synonym: "Товари на складах"
periodicity: WithinSecond
writeMode: SubordinateToRecorder
enableBalanceTotals: true
enableTurnoverTotals: true
partitioning: { mode: RangeByPeriod, step: month }

dimensions:
- { name: Номенклатура, type: "Довідник.Номенклатура", master: true, index: true }
- { name: Склад, type: "Довідник.Склади", master: true, index: true }
- { name: Партія, type: ["Документ.ПрихіднаНакладна", "Документ.ВведенняЗалишків"], index: false }
- { name: Характеристика, type: "ПланВидівХарактеристик.Характеристики", nullable: true }

resources:
- { name: Кількість, type: "Число(15,3)" }
- { name: Сума, type: "Число(15,2)" }

attributes:
- { name: Коментар, type: "Рядок(200)" }

recorders:
- Документ.ПрихіднаНакладна
- Документ.ВидатковаНакладна
- Документ.ПереміщенняТоварів
- Документ.Інвентаризація
</syntaxhighlight>

<syntaxhighlight lang="yaml">
# --- Регістр відомостей (періодичний, незалежний) ---
register:
name: КурсиВалют
kind: Information
periodicity: WithinDay
writeMode: Independent
dimensions:
- { name: Валюта, type: "Довідник.Валюти", master: true }
resources:
- { name: Курс, type: "Число(15,4)" }
- { name: Кратність, type: "Число(10,0)", default: 1 }
</syntaxhighlight>

<syntaxhighlight lang="yaml">
# --- Регістр бухгалтерії ---
register:
name: Госпрозрахунковий
kind: Accounting
chartOfAccounts: ПланРахунків.Госпрозрахунковий
correspondence: true
periodicity: WithinSecond
dimensions:
- { name: Організація, type: "Довідник.Організації", balance: true }
- { name: Підрозділ, type: "Довідник.Підрозділи", balance: false }
resources:
- { name: Сума, type: "Число(15,2)", balance: true }
- { name: Кількість, type: "Число(15,3)", balance: false, accountingFlag: Кількісний }
- { name: ВалютнаСума, type: "Число(15,2)", balance: false, accountingFlag: Валютний }
attributes:
- { name: Зміст, type: "Рядок(255)" }
- { name: Валюта, type: "Довідник.Валюти" }
recorders: [Документ.БухгалтерськаОперація, Документ.ПрихіднаНакладна]
</syntaxhighlight>

<syntaxhighlight lang="yaml">
# --- Регістр розрахунку ---
register:
name: Нарахування
kind: Calculation
calculationTypesPlan: ПланВидівРозрахунку.ОсновніНарахування
periodicity: Month
actionPeriod: true
basePeriod: ByActionPeriod
schedule:
register: РегістрВідомостей.ГрафікРоботи
valueResource: Значення
dateDimension: ДатаГрафіка
dimensions:
- { name: Співробітник, type: "Довідник.Співробітники", baseDimension: true, master: true }
- { name: Підрозділ, type: "Довідник.Підрозділи" }
resources:
- { name: Результат, type: "Число(15,2)" }
- { name: ВідпрацьованоДнів, type: "Число(5,0)" }
- { name: НормаДнів, type: "Число(5,0)" }
recalculations:
- name: ПерерахунокЗаБазою
dimensions:
- { name: Співробітник, registerDimension: Співробітник }
recorders: [Документ.НарахуванняЗарплати]
</syntaxhighlight>

{{Note|Розширений каталог із 17 прикладів регістрів усіх типів і підвидів — з деклараціями, даними у фізичних таблицях, запитами, наскрізними сценаріями та антипатернами — див. '''Додаток Д'''.}}

== 6.8. UI конструктора метаданих ==

=== 6.8.1. Загальний макет ===
<pre>
┌─ Конфігуратор K2 ERP ─────────────────────────────────────────────────────────┐
│ Файл Правка Конфігурація Адміністрування Сервіс Довідка │
├──────────────────────┬────────────────────────────────────────────────────────┤
│ Дерево конфігурації │ Регістр накопичення: ТовариНаСкладах │
│ │ ┌──────┬─────────┬──────────┬──────────┬───────────┐ │
│ ▾ Регістри │ │Основ.│Дані │Реєстратор│Форми │Права │ │
│ ▸ відомостей │ └──────┴─────────┴──────────┴──────────┴───────────┘ │
│ ▾ накопичення │ │
│ ▾ ТовариНаСклад. │ Ім'я [ТовариНаСкладах.............] │
│ ▾ Вимірювання │ Синонім [Товари на складах...........] │
│ Номенклат. │ Коментар [.............................] │
│ Склад │ │
│ Партія │ Вид регістру ( ) Обороти (•) Залишки │
│ ▾ Ресурси │ Періодичність [ У межах секунди ▾] │
│ Кількість │ Режим запису [ Підпорядкований реєстратору ▾] │
│ Сума │ │
│ ▸ Реквізити │ ☑ Дозволити підсумки залишків │
│ ▸ Форми │ ☑ Дозволити підсумки оборотів │
│ ▸ Взаєморозрах. │ Періодичність підсумків оборотів [Місяць ▾] │
│ ▸ бухгалтерії │ ☐ Дозволити розділення підсумків │
│ ▸ розрахунку │ │
│ │ Блокування даних [Кероване ▾] │
│ │ Партиціонування [За періодом, крок: місяць ▾] │
│ │ │
│ │ [ Конструктор рухів... ] [ Перевірити ] [ Закрити ] │
├──────────────────────┴────────────────────────────────────────────────────────┤
│ ⚠ Попередження: 4 вимірювання + місячні підсумки → оцінка таблиці підсумків │
│ ~ 12 млн записів/рік. Розгляньте виключення вимірювання «Партія» з підсумків.│
└───────────────────────────────────────────────────────────────────────────────┘
</pre>

=== 6.8.2. Палітра властивостей поля ===
<pre>
┌─ Властивості: Вимірювання «Партія» ────────────────┐
│ Ім'я [Партія...................] │
│ Синонім [Партія...................] │
│ Тип [Складений тип........ [...]]│
│ ├ Документ.ПрихіднаНакладна │
│ └ Документ.ВведенняЗалишків │
│ Індексувати [Не індексувати ▾] │
│ ☐ Ведуче │
│ ☐ Основний відбір │
│ ☐ Заборонити незаповнені значення │
│ ☑ Використовувати в підсумках │
│ Подання │
│ Підказка [Партія товару...........] │
└────────────────────────────────────────────────────┘
</pre>

=== 6.8.3. Вкладка «Реєстратори» ===
<pre>
┌─ ТовариНаСкладах → Реєстратори ────────────────────────────┐
│ ☑ Документ.ПрихіднаНакладна │
│ ☑ Документ.ВидатковаНакладна │
│ ☑ Документ.ПереміщенняТоварів │
│ ☑ Документ.Інвентаризація │
│ ☐ Документ.Замовлення │
│ ☐ Документ.РахунокНаОплату │
│ [Позначити всі] [Зняти]│
│ ───────────────────────────────────────────────────────── │
│ ⓘ Знімання прапорця для документа, що має рухи, вимагає │
│ очищення рухів. Знайдено рухів: 0 │
└────────────────────────────────────────────────────────────┘
</pre>

=== 6.8.4. Вимоги до конструктора ===
* ФТ-К-01. Валідація метаопису в реальному часі з переліком помилок/попереджень.
* ФТ-К-02. Попередній перегляд згенерованого DDL (кнопка «Показати SQL»).
* ФТ-К-03. Калькулятор оцінки обсягу таблиць підсумків (добуток кардинальностей вимірювань × кількість періодів).
* ФТ-К-04. Заборона неприпустимих комбінацій (напр. «Незалежний» + «Регістр накопичення»).
* ФТ-К-05. «Конструктор рухів» — генерація коду формування рухів за табличною частиною документа.
* ФТ-К-06. Порівняння/об'єднання конфігурацій має коректно обробляти об'єкти-регістри.
* ФТ-К-07. '''Генерація <code>.pyi</code>-стабів''' для кожного регістру за метаописом. Прикладний код звертається до полів динамічно (<code>__getattr__</code>), що недоступне для <code>mypy</code>; згенеровані стаби повертають статичну перевірку. Перегенеровуються при кожній зміні метаданих, перевіряються в CI (див. Е.6). ''Вимога специфічна для Python, аналога в 1С не має.''

= 7. Функціональні вимоги =

== 7.1. Набір записів і проведення документа ==

'''ФТ-01.''' Платформа надає прикладний об'єкт <code>НабірЗаписів</code> для кожного регістру з властивостями: <code>Відбір</code>, <code>Записувати</code>, і методами <code>Прочитати()</code>, <code>Записати(Заміщати)</code>, <code>Очистити()</code>, <code>ЗаблокуватиДляЗміни()</code>, <code>Вивантажити()</code>, <code>Завантажити()</code>.

'''ФТ-02.''' Для документа доступна колекція <code>Рухи</code> з наборами записів усіх регістрів, де документ вказано реєстратором.

'''ФТ-03. Сценарій проведення:'''

<uml>
@startuml
skinparam defaultFontName "DejaVu Sans"
skinparam monochrome false
skinparam shadowing false
actor Користувач
participant "Форма\nдокумента" as UI
participant "Об'єкт\nДокумент" as Doc
participant "Менеджер\nпроведення" as PM
participant "Набори\nзаписів" as RS
database "СКБД" as DB

Користувач -> UI: Провести
UI -> Doc: Записати(РежимЗапису.Проведення)
activate Doc
Doc -> PM: НачатьТранзакцию()
PM -> DB: BEGIN
Doc -> Doc: ПередЗаписью()
Doc -> DB: UPDATE doc SET Проведений=1
Doc -> Doc: ОбработкаПроведения(Отказ, Режим)
note right of Doc
Прикладний код:
Рухи.ТовариНаСкладах.Записувати = Істина;
Рух = Рухи.ТовариНаСкладах.Добавить();
Рух.ВидРуху = ВидРухуНакопичення.Витрата;
...
// контроль залишків (оперативне проведення)
end note
Doc -> RS: (формування рухів у пам'яті)
Doc -> PM: ЗаписатьДвижения()
PM -> RS: для кожного НЗ з Записувати=Істина
RS -> DB: DELETE FROM rg_a_0012 WHERE rec_ref = :doc
RS -> DB: INSERT INTO rg_a_0012 (...) VALUES (...)
RS -> PM: ОновитиПідсумки(delta)
PM -> DB: MERGE rg_a_0012_tb (див. розд. 10.2)
Doc -> Doc: ПриЗаписи() / ПослеЗаписи()
alt Відмова = Хиба
PM -> DB: COMMIT
PM --> UI: Успіх
else Відмова = Істина або виключення
PM -> DB: ROLLBACK
PM --> UI: Помилка "Документ не проведено: ..."
end
deactivate Doc
@enduml
</uml>

'''ФТ-04.''' Запис набору записів у режимі <code>Заміщати = Істина</code> (за замовчуванням для рухів) виконує <code>DELETE</code> усіх записів за відбором + <code>INSERT</code> нових — атомарно.

'''ФТ-05.''' Скасування проведення документа: усі набори записів за реєстратором очищуються, підсумки коригуються, документ отримує <code>Проведений = Хиба</code>.

'''ФТ-06.''' Видалення документа-реєстратора (у т.ч. позначеного на видалення) '''зобов'язане''' каскадно видалити всі його рухи в межах однієї транзакції. Реалізація — на рівні платформи (не FK, оскільки посилання поліморфне) + фонова перевірка цілісності (розділ 7.10).

'''ФТ-07.''' Режими проведення:
{| class="wikitable"
! Режим !! Умова !! Поведінка
|-
| '''Оперативне''' || Дата документа = поточна дата, документ у межах «оперативної точки» || Дозволено контроль залишків «на зараз»; дата може перепризначатися на поточну.
|-
| '''Неоперативне''' || Дата в минулому/майбутньому або документ перепроводиться || Контроль залишків виконується на дату документа; можливий негативний залишок за налаштуванням.
|}

== 7.2. Активність записів ==
'''ФТ-08.''' Реквізит <code>Активність = Хиба</code> означає, що запис фізично існує, але '''не''' впливає на підсумки та не потрапляє до віртуальних таблиць.
'''ФТ-09.''' Зміна активності будь-якого запису тягне коригування підсумків.
'''ФТ-10.''' Скасування проведення документа переводить усі його записи в <code>Активність = Хиба</code> '''або''' видаляє їх — залежно від налаштування регістру <code>ПоведінкаПриСкасуванні</code> (<code>Видаляти</code> — за замовчуванням / <code>Деактивувати</code>).

== 7.3. Віртуальні таблиці ==

'''ФТ-11.''' Мова запитів надає для кожного регістру набір віртуальних таблиць. Транслятор перетворює звернення до них на SQL із використанням таблиць підсумків та «живих» рухів після ТА.

{| class="wikitable"
! Регістр !! Віртуальна таблиця !! Параметри !! Повертає
|-
| rowspan="3" | '''РВ''' || <code>ЗрізОстанніх</code> || (Період, Умова) || Останній запис на кожну комбінацію вимірювань з періодом ≤ Період
|-
| <code>ЗрізПерших</code> || (Період, Умова) || Перший запис з періодом ≥ Період
|-
| ''(основна)'' || — || Усі записи
|-
| rowspan="4" | '''РН.Залишки''' || <code>Залишки</code> || (Період, Умова) || Вимірювання + <code><Ресурс>Залишок</code>
|-
| <code>Обороти</code> || (Початок, Кінець, Періодичність, Умова) || <code><Ресурс>Прихід</code>, <code><Ресурс>Витрата</code>, <code><Ресурс>Оборот</code>
|-
| <code>ЗалишкиІОбороти</code> || (Початок, Кінець, Періодичність, МетодДоповнення, Умова) || <code><Р>ПочатковийЗалишок</code>, <code><Р>Прихід</code>, <code><Р>Витрата</code>, <code><Р>Оборот</code>, <code><Р>КінцевийЗалишок</code>
|-
| ''(основна)'' || — || Рухи
|-
| '''РН.Обороти''' || <code>Обороти</code> || (Початок, Кінець, Періодичність, Умова) || <code><Ресурс>Оборот</code>
|-
| rowspan="6" | '''РБ''' || <code>Залишки</code> || (Період, УмоваРахунку, Субконто, Умова) || <code><Р>Залишок</code>, <code><Р>ЗалишокДт</code>, <code><Р>ЗалишокКт</code>
|-
| <code>Обороти</code> || (Початок, Кінець, Періодичність, УмоваРахунку, Субконто, Умова, УмоваКорРахунку, КорСубконто) || <code><Р>Оборот</code>, <code><Р>ОборотДт</code>, <code><Р>ОборотКт</code>
|-
| <code>ЗалишкиІОбороти</code> || (…) || Повний набір
|-
| <code>ОборотиДтКт</code> || (Початок, Кінець, Періодичність, УмоваРахункуДт, СубконтоДт, УмоваРахункуКт, СубконтоКт) || Кореспонденції
|-
| <code>ДвиженияССубконто</code> || (Початок, Кінець, УмоваРахунку, Субконто, Умова) || Рухи з розшифровкою субконто
|-
| <code>Субконто</code> || (Умова, Порядок…) || Значення субконто записів
|-
| rowspan="4" | '''РР''' || <code>ДаніГрафіка</code> || (Умова) || <code>ЗначенняПеріодуДії</code>, <code>ЗначенняПеріодуРеєстрації</code>, <code>ЗначенняБазовогоПеріоду</code>, <code>ЗначенняФактичногоПеріодуДії</code>
|-
| <code>ФактичнийПеріодДії</code> || (Умова) || Записи з фактичними (після витіснення) межами
|-
| <code>БазаРозрахунку</code> || (ВимірюванняБази, ВимірюванняОсновногоРегістру, Розрізи, ВидиРозрахунку, Умова) || Агреговані значення ресурсів базових видів розрахунку
|-
| ''(основна)'' || — || Рухи
|}

'''ФТ-12.''' Приклад запиту:
<syntaxhighlight lang="sql">
ВИБРАТИ
Залишки.Номенклатура,
Залишки.Склад,
Залишки.КількістьЗалишок,
Обороти.КількістьПрихід,
Обороти.КількістьВитрата
З
РегістрНакопичення.ТовариНаСкладах.ЗалишкиІОбороти(
&ПочатокПеріоду,
&КінецьПеріоду,
Місяць,
Рух,
Склад = &Склад
І Номенклатура В ІЄРАРХІЇ (&ГрупаНоменклатури)
) ЯК Залишки
</syntaxhighlight>

'''ФТ-13.''' Параметри віртуальних таблиць '''зобов'язані''' транслюватися у <code>WHERE</code> підзапиту до звернення до підсумків (push-down), а не фільтруватися після агрегації.

== 7.4. Підсумки ==

=== 7.4.1. Модель підсумків залишків ===
Таблиця залишків зберігає '''кумулятивний залишок на початок кожного періоду''' + спеціальний рядок «підсумок за всі періоди» з <code>period = '5999-11-01'</code> (маркер MAXPERIOD).

<pre>
Таблиця підсумків (місячна) ТА
┌────┬────┬────┬────┬────┐ ▼
─────┬────┬────┬───┴────┴────┴────┴────┴────┴────────────────────┬──────────►
│ │ │ 01.10 01.11 01.12 01.01 01.02 15.02 t
│ │ │ ● ● ● ● ●
│ │ │ бал. бал. бал. бал. бал.
└─ «живі» рухи ─┘
(сканування)
Залишок на 10.02 = Підсумок(01.02) + Σ рухів (01.02 … 10.02]
Залишок на 20.02 = Підсумок(01.02) + Σ рухів (01.02 … 20.02] // після ТА — теж
</pre>

'''ФТ-14.''' Регламентна операція «Перерахунок підсумків» перебудовує таблиці підсумків з нуля.
'''ФТ-15.''' Регламентна операція «Встановлення періоду розрахунку підсумків» переносить ТА вперед/назад.
'''ФТ-16.''' При записі рухів раніше ТА підсумки коригуються ''інкрементально'' (див. 10.2), без повного перерахунку.

=== 7.4.2. Розділення підсумків ===
'''ФТ-17.''' За увімкненого <code>ДозволитиРозділенняПідсумків</code> у таблиці підсумків додається колонка <code>splitter smallint</code>. Одночасні транзакції пишуть у різні «сплітери», що усуває конкуренцію за рядок. Читання агрегує по всіх сплітерах. Регламентне завдання зливає сплітери.

=== 7.4.3. Обороти ===
'''ФТ-18.''' Таблиця оборотів зберігає агрегати за календарний період (день або місяць — за налаштуванням), без кумуляції.

=== 7.4.4. Агрегати (тільки РН виду «Обороти») ===
'''ФТ-19.''' Агрегат — додаткова матеріалізована таблиця з підмножиною вимірювань і власною періодичністю (День/Місяць/Квартал/Рік). Оптимізатор запитів обирає найдешевший агрегат, що покриває запит.
'''ФТ-20.''' Режими: <code>Реальний час</code> (оновлюється при записі рухів) / <code>Регламентний</code> (оновлюється завданням; запит враховує рухи після дати актуальності агрегату).
'''ФТ-21.''' «Порадник агрегатів» аналізує статистику запитів і пропонує склад агрегатів (<code>ВизначитиОптимальніАгрегати()</code>).

== 7.5. Механіка регістру розрахунку ==

=== 7.5.1. Витіснення за періодом дії ===
'''ФТ-22.''' Якщо у ПВР для виду розрахунку A вказано B у складі «Витісняючі види розрахунку», то запис виду B скорочує фактичний період дії запису виду A на інтервал перетину.

<uml>
@startgantt
skinparam defaultFontName "DejaVu Sans"
title Витіснення за періодом дії. Період реєстрації: січень 2026
caption Пріоритет витіснення: Лікарняний > Відпустка > Оклад
printscale daily
Project starts 2026-01-01

-- Заявлені періоди дії (rg_c_0040.act_begin / act_end) --
[Оклад] as [O1] starts 2026-01-01 and ends 2026-01-31
[Відпустка] as [V1] starts 2026-01-10 and ends 2026-01-17
[Лікарняний] as [L1] starts 2026-01-14 and ends 2026-01-22
[O1] is colored in #BBDEFB
[V1] is colored in #FFE0B2
[L1] is colored in #F8BBD0

-- Фактичні періоди дії після витіснення (rg_c_0040_ap) --
[Оклад, інтервал 0] as [O2] starts 2026-01-01 and ends 2026-01-09
[Оклад, інтервал 1] as [O3] starts 2026-01-23 and ends 2026-01-31
[Відпустка, інтервал 0] as [V2] starts 2026-01-10 and ends 2026-01-13
[Лікарняний, інтервал 0] as [L2] starts 2026-01-14 and ends 2026-01-22
[O2] is colored in #1976D2
[O3] is colored in #1976D2
[V2] is colored in #F57C00
[L2] is colored in #C2185B
@endgantt
</uml>

{{Note|'''Ключове спостереження.''' Один запис «Оклад» породжує '''два''' фактичні інтервали — саме тому <code>rg_c_0040_ap</code> має власний ключ <code>interval_no</code> і зв'язок 1:N із таблицею рухів (розділ 9.4). «Відпустка» скорочена з 17.01 до 13.01, бо лікарняний має вищий пріоритет.}}

'''ФТ-23.''' Фактичні періоди дії матеріалізуються у службовій таблиці <code>rg_c_<код>_ap</code> під час запису набору записів.
'''ФТ-24.''' Витіснення обчислюється в межах збігу '''усіх''' вимірювань регістру та перетину періодів реєстрації, визначених ПВР.

=== 7.5.2. Базовий період і база розрахунку ===
'''ФТ-25.''' Віртуальна таблиця <code>БазаРозрахунку</code> повертає суму ресурсів записів базових видів розрахунку, зіставлених за базовими вимірюваннями, з урахуванням режиму <code>ЗалежністьВідБази</code>:
* <code>ЗаПеріодДії</code> — беруться записи, чий '''період дії''' перетинається з базовим періодом поточного запису; результат пропорційно розподіляється за часткою перетину (за графіком, якщо заданий);
* <code>ЗаПеріодРеєстрації</code> — беруться записи, чий '''період реєстрації''' потрапляє в базовий період.

=== 7.5.3. Перерахунки ===
'''ФТ-26.''' При записі/зміні/видаленні запису базового виду розрахунку платформа '''автоматично''' формує записи у таблиці перерахунку для всіх залежних записів (за збігом вимірювань перерахунку та потраплянням у базовий період).
'''ФТ-27.''' Прикладний код читає перерахунок як набір записів, перепроводить відповідні документи та очищує оброблені записи.
'''ФТ-28.''' Перерахунок доступний як об'єкт для звіту «Документи до перерахунку».

=== 7.5.4. Графік часу ===
'''ФТ-29.''' Графік — це РВ з обов'язковим вимірюванням типу <code>Дата</code> та числовим ресурсом. Віртуальна таблиця <code>ДаніГрафіка</code> повертає суму значень графіка за відповідний період (дії / реєстрації / базовий / фактичний період дії).
'''ФТ-30.''' Якщо у графіку є додаткові вимірювання (напр. <code>ВидГрафіка</code>), вони зіставляються з однойменними реквізитами/вимірюваннями РР.

== 7.6. Прикладний API ==

<syntaxhighlight lang="python">
from datetime import date
from decimal import Decimal

from k2.registers import AccumulationMovementType, DataLock, DataLockMode, Registers
from k2.documents import Document, PostingContext

# ============ Регістр відомостей: незалежний запис ============
mgr = Registers.information("КурсиВалют")

rm = mgr.create_record_manager()
rm.Період = date(2026, 7, 17)
rm.Валюта = usd
rm.Курс = Decimal("41.85")
rm.Кратність = 1
rm.write(replace=True) # INSERT ... ON CONFLICT DO UPDATE

# зріз останніх
row = mgr.get_last(date.today(), {"Валюта": usd})
курс: Decimal = row.Курс

# АП-1: масове завантаження — ОДИН запит, а не цикл із write() усередині
rs = mgr.create_record_set()
rs.load([{"Період": d, "Валюта": v, "Курс": k, "Кратність": 1}
for d, v, k in nbu_rates]) # 3 000 курсів
rs.write(replace=True) # 1 × executemany, ~40 мс

# ============ Регістр накопичення: рухи документа ============
class ВидатковаНакладна(Document):

def on_posting(self, ctx: PostingContext) -> None:
rs = self.movements.ТовариНаСкладах
rs.write = True # набір буде записано наприкінці транзакції
rs.clear()

# АП-1: набір наповнюється генератором, запис — одним batch
rs.extend(
rs.new(
Період=self.Дата,
ВидРуху=AccumulationMovementType.EXPENSE,
Номенклатура=r.Номенклатура,
Склад=self.Склад,
Партія=r.Партія,
Кількість=r.Кількість,
Сума=r.Сума,
)
for r in self.Товари
)

# керовані блокування перед контролем залишків
with DataLock() as dl: # __enter__ виконує lock()
li = dl.add("РегістрНакопичення.ТовариНаСкладах.Залишки")
li.mode = DataLockMode.EXCLUSIVE
li.data_source = rs.unload("Номенклатура", "Склад")
li.use_from_data_source("Номенклатура", "Номенклатура")
li.use_from_data_source("Склад", "Склад")

rs.write_now() # примусовий запис до контролю
self._control_balances(ctx) # прикладна перевірка від'ємних залишків

# ============ Регістр бухгалтерії ============
def _accounting(self) -> None:
rs = self.movements.Госпрозрахунковий
rs.write = True
for r in self.Товари:
e = rs.add_accounting_entry(
Період=self.Дата,
Організація=self.Організація,
РахунокДт=accounts["281"],
РахунокКт=accounts["631"],
Сума=r.Сума,
КількістьДт=r.Кількість,
)
e.subconto_dt[ВидиСубконто.Номенклатура] = r.Номенклатура
e.subconto_dt[ВидиСубконто.Склади] = self.Склад
e.subconto_kt[ВидиСубконто.Контрагенти] = self.Контрагент

# ============ Регістр розрахунку ============
def _calculation(self) -> None:
rs = self.movements.Нарахування
rs.write = True
rs.append(rs.new(
ВидРозрахунку=calc_types["Оклад"],
Період=self.Дата, # період реєстрації
ПеріодДіїПочаток=date(2026, 7, 1),
ПеріодДіїКінець=date(2026, 7, 31),
БазовийПеріодПочаток=date(2026, 6, 1),
БазовийПеріодКінець=date(2026, 6, 30),
Співробітник=self.Співробітник,
Результат=Decimal(0), # заповниться після розрахунку
))
rs.write_now()

# Отримання даних графіка та бази розрахунку — запитом (розділ 7.3), не циклом.
</syntaxhighlight>

{{Note|'''Про кириличні ідентифікатори.''' Python 3 підтримує Unicode в іменах (PEP 3131), тому <code>rm.Валюта</code> і <code>rs.new(Номенклатура=…)</code> — валідний код; прикладна термінологія зберігається без транслітерації. '''Але''' доступ до полів регістру динамічний, тому <code>mypy</code> його не перевіряє — компенсується генерацією <code>.pyi</code>-стабів (ФТ-К-07, Додаток Е.6). Ключові слова API (<code>write</code>, <code>clear</code>, <code>new</code>) залишаються англійськими; змішування — свідомий компроміс, підлягає узгодженню (В15).}}

{{Note|'''Антипатерн, специфічний для Python (А-15).''' Спокуса написати <code>for r in self.Товари: rs.add(...).write()</code> дає 100 round-trip'ів до СКБД замість одного і збільшує час проведення з 300 мс до ~10 с. Це порушення АП-1 і найчастіша помилка при переході з ORM-мислення. Детектор — Е.7.}}

== 7.7. Блокування та конкурентність ==

{| class="wikitable"
! № !! Вимога
|-
| ФТ-31 || Режим керованих блокувань — за замовчуванням. Рівень ізоляції транзакцій: <code>READ COMMITTED</code> (PostgreSQL) / <code>READ COMMITTED SNAPSHOT</code> (MS SQL).
|-
| ФТ-32 || Об'єкт <code>DataLock</code> дозволяє встановити розділювальне/виняткове блокування на «простір» регістру за значеннями вимірювань (реалізація — <code>pg_advisory_xact_lock</code> за хешем ключа або <code>SELECT ... FOR UPDATE</code> по таблиці підсумків).
|-
| ФТ-33 || Запис рухів документа блокує тільки записи цього реєстратора (PK містить реєстратор першим).
|-
| ФТ-34 || Оновлення підсумків не повинно призводити до дедлоків: усі <code>MERGE</code>-операції в межах транзакції виконуються у детермінованому порядку сортування ключа.
|-
| ФТ-35 || Гарантія: паралельне проведення двох документів з різними наборами вимірювань не конкурує (за увімкненого розділення підсумків).
|-
| ФТ-36 || Таймаут очікування блокування — 20 с (налаштовується); при перевищенні — керована помилка з текстом конфліктного ключа.
|}

== 7.8. Права доступу ==

'''ФТ-37.''' Для регістру визначаються права: <code>Читання</code>, <code>Додавання</code>, <code>Зміна</code>, <code>Видалення</code>, <code>Перегляд</code>, <code>Редагування</code>, <code>ПереглядПідсумків</code>.
'''ФТ-38.''' Обмеження на рівні записів (RLS) задаються шаблоном умови по вимірюваннях; транслюються в <code>WHERE</code> усіх звернень, включно з віртуальними таблицями.
'''ФТ-39.''' ''Ризик:'' RLS на віртуальних таблицях залишків потребує узгодженості з підсумками. Рішення — RLS дозволено тільки по вимірюваннях, що входять до ключа підсумків; конструктор валідує це правило.

== 7.9. Журналювання, аудит, службові сервіси ==

'''ФТ-40.''' Реєстрація в журналі: перерахунок підсумків, зміна ТА, реструктуризація регістру, злиття сплітерів.
'''ФТ-41.''' Службовий сервіс «Перевірка цілісності регістрів»:
* «висячі» рухи (реєстратор не існує або не проведений);
* розбіжність підсумків і сум рухів (контрольний перерахунок у тіньову таблицю з порівнянням);
* некоректні фактичні періоди дії РР;
* для РБ — порушення рівності Дт = Кт за балансовим ресурсом у межах реєстратора.
'''ФТ-42.''' Звіт «Аналіз розміру регістрів»: кількість записів, розмір таблиць та індексів, дата останнього перерахунку підсумків.

= 8. Модель даних (як це виглядає в базі даних) =

== 8.1. Конвенції іменування ==

Фізичні імена '''не''' успадковують прикладні імена (обмеження довжини ідентифікатора, кирилиця, перейменування об'єктів). Ім'я будується за сурогатним кодом об'єкта метаданих <code><id></code> (4-значний hex/dec).

{| class="wikitable"
! Шаблон !! Призначення !! Приклад
|-
| <code>rg_i_<id></code> || Регістр відомостей — основна таблиця || <code>rg_i_0007</code>
|-
| <code>rg_a_<id></code> || Регістр накопичення — рухи || <code>rg_a_0012</code>
|-
| <code>rg_a_<id>_tb</code> || РН — підсумки залишків (Totals Balance) || <code>rg_a_0012_tb</code>
|-
| <code>rg_a_<id>_tt</code> || РН — підсумки оборотів (Totals Turnover) || <code>rg_a_0012_tt</code>
|-
| <code>rg_a_<id>_ag<n></code> || РН — агрегат № n || <code>rg_a_0031_ag1</code>
|-
| <code>rg_b_<id></code> || Регістр бухгалтерії — проводки || <code>rg_b_0020</code>
|-
| <code>rg_b_<id>_ed</code> || РБ — субконто (якщо винесено в дочірню таблицю) || <code>rg_b_0020_ed</code>
|-
| <code>rg_b_<id>_tb<k></code> || РБ — підсумки залишків за рівнем субконто k (0…N) || <code>rg_b_0020_tb2</code>
|-
| <code>rg_b_<id>_tt<k></code> || РБ — підсумки оборотів за рівнем субконто k || <code>rg_b_0020_tt1</code>
|-
| <code>rg_b_<id>_tc</code> || РБ — обороти між рахунками (кореспонденції) || <code>rg_b_0020_tc</code>
|-
| <code>rg_c_<id></code> || Регістр розрахунку — рухи || <code>rg_c_0040</code>
|-
| <code>rg_c_<id>_ap</code> || РР — фактичні періоди дії || <code>rg_c_0040_ap</code>
|-
| <code>rg_c_<id>_rc<m></code> || РР — перерахунок № m || <code>rg_c_0040_rc1</code>
|-
| <code>rg_<*>_<id>_opt</code> || Службова: ТА підсумків, налаштування || <code>rg_a_0012_opt</code>
|-
| <code>md_*</code> || Таблиці метаданих || <code>md_register</code>
|}

Колонки полів: <code>d<n></code> — вимірювання, <code>r<n></code> — ресурс, <code>a<n></code> — реквізит, де <code>n</code> — порядковий номер поля в метаописі (стабільний, не перевикористовується після видалення поля). Мапінг «прикладне ім'я ↔ фізична колонка» зберігається в <code>md_register_field</code>.

== 8.2. Типізація та зберігання значень ==

=== 8.2.1. Примітивні типи ===
{| class="wikitable"
! Тип платформи !! PostgreSQL !! MS SQL
|-
| Число(p,s) || <code>numeric(p,s)</code> || <code>numeric(p,s)</code>
|-
| Рядок(n) || <code>varchar(n)</code> || <code>nvarchar(n)</code>
|-
| Рядок(необмежена) || <code>text</code> || <code>nvarchar(max)</code>
|-
| Дата / ДатаЧас || <code>timestamp(0)</code> || <code>datetime2(0)</code>
|-
| Булево || <code>boolean</code> || <code>bit</code>
|-
| УНІ || <code>uuid</code> || <code>uniqueidentifier</code>
|}

=== 8.2.2. Посилальні типи ===
* '''Простий''' (один тип): одна колонка <code>d<n>_r uuid NOT NULL</code>, зовнішній ключ до таблиці об'єкта. Порожнє посилання = <code>'00000000-0000-0000-0000-000000000000'</code> (а не NULL — щоб зберегти семантику «пустого значення» у ключах підсумків).
* '''Складений''' (кілька типів / примітив + посилання): група колонок:

{| class="wikitable"
! Колонка !! Тип !! Опис
|-
| <code>d<n>_t</code> || <code>smallint</code> || Код типу: 1=Невизначено, 2=Булево, 3=Число, 4=Рядок, 5=Дата, ≥100 = <code>md_type.id</code> посилального типу
|-
| <code>d<n>_b</code> || <code>boolean</code> || Значення, якщо _t=2
|-
| <code>d<n>_n</code> || <code>numeric(38,10)</code> || Значення, якщо _t=3
|-
| <code>d<n>_s</code> || <code>varchar(N)</code> || Значення, якщо _t=4
|-
| <code>d<n>_d</code> || <code>timestamp(0)</code> || Значення, якщо _t=5
|-
| <code>d<n>_r</code> || <code>uuid</code> || Значення, якщо _t≥100
|}

{{Note|'''Проєктне рішення №1.''' Для складених типів обрано «широку» денормалізацію (кілька колонок), а не JSONB/варіант, тому що: (а) колонки індексуються та беруть участь у ключах підсумків; (б) B-tree по <code>(d1_t, d1_r)</code> дає range-scan, JSONB — ні; (в) сумісно з обома цільовими СКБД. Ціна — до 6 колонок на одне складене поле.}}

=== 8.2.3. Реєстратор ===
Завжди складений (будь-який з дозволених документів):
* <code>rec_t smallint NOT NULL</code> — код типу документа (<code>md_type.id</code>);
* <code>rec_r uuid NOT NULL</code> — посилання.

FK неможливий (поліморфізм) → цілісність забезпечується платформою + сервісом перевірки (ФТ-41).

=== 8.2.4. Маркери періодів ===
{| class="wikitable"
! Константа !! Значення !! Використання
|-
| <code>MINPERIOD</code> || <code>0001-01-01 00:00:00</code> || Нижня межа
|-
| <code>MAXPERIOD</code> || <code>5999-11-01 00:00:00</code> || Рядок «підсумок за всі періоди» в таблицях залишків
|}

== 8.3. Таблиці метаданих ==

<syntaxhighlight lang="sql">
-- ============ РЕПОЗИТОРІЙ МЕТАДАНИХ ============

CREATE TABLE md_type ( -- реєстр усіх типів конфігурації
id smallint PRIMARY KEY,
kind varchar(20) NOT NULL, -- Catalog|Document|Enum|ChartOfAccounts|ChartOfCalcTypes|Register|...
name varchar(80) NOT NULL,
table_name varchar(63),
UNIQUE (kind, name)
);

CREATE TABLE md_register (
id smallint PRIMARY KEY, -- = md_type.id
name varchar(80) NOT NULL UNIQUE,
synonym varchar(255),
comment text,
kind varchar(12) NOT NULL
CHECK (kind IN ('Information','Accumulation','Accounting','Calculation')),
-- загальні
write_mode varchar(24) NOT NULL DEFAULT 'SubordinateToRecorder'
CHECK (write_mode IN ('Independent','SubordinateToRecorder')),
periodicity varchar(24) NOT NULL DEFAULT 'Nonperiodical'
CHECK (periodicity IN ('Nonperiodical','WithinSecond','WithinDay','WithinMonth',
'WithinQuarter','WithinYear','ByRecorderPosition')),
lock_mode varchar(12) NOT NULL DEFAULT 'Managed',
use_rls boolean NOT NULL DEFAULT false,
partition_mode varchar(20) NOT NULL DEFAULT 'None',
partition_step varchar(10),
-- РН
accumulation_kind varchar(10) CHECK (accumulation_kind IN ('Balance','Turnover')),
enable_bal_totals boolean NOT NULL DEFAULT true,
enable_tno_totals boolean NOT NULL DEFAULT false,
tno_totals_period varchar(6) CHECK (tno_totals_period IN ('Day','Month')),
split_totals boolean NOT NULL DEFAULT false,
split_count smallint NOT NULL DEFAULT 1,
aggregates_mode varchar(10),
-- РБ
chart_of_accounts_id smallint REFERENCES md_type(id),
correspondence boolean NOT NULL DEFAULT true,
max_extdim_count smallint NOT NULL DEFAULT 3,
-- РР
calc_types_plan_id smallint REFERENCES md_type(id),
use_action_period boolean NOT NULL DEFAULT false,
base_period_mode varchar(24)
CHECK (base_period_mode IN ('None','ByActionPeriod','ByRegistrationPeriod')),
schedule_register_id smallint REFERENCES md_register(id),
schedule_value_field smallint,
schedule_date_field smallint,
-- службове
physical_table varchar(63) NOT NULL,
struct_version int NOT NULL DEFAULT 1,
CONSTRAINT chk_kind_props CHECK (
(kind = 'Accumulation' AND accumulation_kind IS NOT NULL) OR
(kind = 'Accounting' AND chart_of_accounts_id IS NOT NULL) OR
(kind = 'Calculation' AND calc_types_plan_id IS NOT NULL) OR
(kind = 'Information')
)
);

CREATE TABLE md_register_field (
id smallint NOT NULL, -- порядковий номер поля (стабільний)
register_id smallint NOT NULL REFERENCES md_register(id) ON DELETE CASCADE,
name varchar(80) NOT NULL,
synonym varchar(255),
role varchar(12) NOT NULL CHECK (role IN ('Dimension','Resource','Attribute')),
data_type_expr text NOT NULL, -- серіалізований опис типу (може бути складеним)
is_composite boolean NOT NULL DEFAULT false,
precision_ smallint,
scale_ smallint,
length_ int,
index_mode varchar(28) NOT NULL DEFAULT 'None'
CHECK (index_mode IN ('None','Index','IndexWithAddDimensions')),
is_master boolean NOT NULL DEFAULT false, -- «Ведуче»
in_default_filter boolean NOT NULL DEFAULT false,
deny_empty boolean NOT NULL DEFAULT false,
use_in_totals boolean NOT NULL DEFAULT true,
-- РБ
is_balance boolean NOT NULL DEFAULT false,
accounting_flag varchar(80),
extdim_flag varchar(80),
-- РР
is_base_dimension boolean NOT NULL DEFAULT false,
-- фізика
column_prefix varchar(8) NOT NULL, -- 'd3','r1','a2'
PRIMARY KEY (register_id, id),
UNIQUE (register_id, name)
);

CREATE TABLE md_register_recorder (
register_id smallint NOT NULL REFERENCES md_register(id) ON DELETE CASCADE,
doc_type_id smallint NOT NULL REFERENCES md_type(id),
PRIMARY KEY (register_id, doc_type_id)
);

CREATE TABLE md_register_aggregate (
id smallint NOT NULL,
register_id smallint NOT NULL REFERENCES md_register(id) ON DELETE CASCADE,
name varchar(80) NOT NULL,
periodicity varchar(8) NOT NULL CHECK (periodicity IN ('Day','Month','Quarter','Year')),
use_mode varchar(12) NOT NULL DEFAULT 'Auto',
is_realtime boolean NOT NULL DEFAULT false,
actual_upto timestamp(0),
physical_table varchar(63) NOT NULL,
PRIMARY KEY (register_id, id)
);
CREATE TABLE md_register_aggregate_dim (
register_id smallint NOT NULL,
aggregate_id smallint NOT NULL,
field_id smallint NOT NULL,
PRIMARY KEY (register_id, aggregate_id, field_id),
FOREIGN KEY (register_id, aggregate_id) REFERENCES md_register_aggregate(register_id, id) ON DELETE CASCADE
);

CREATE TABLE md_register_recalc (
id smallint NOT NULL,
register_id smallint NOT NULL REFERENCES md_register(id) ON DELETE CASCADE,
name varchar(80) NOT NULL,
physical_table varchar(63) NOT NULL,
PRIMARY KEY (register_id, id)
);
CREATE TABLE md_register_recalc_dim (
register_id smallint NOT NULL,
recalc_id smallint NOT NULL,
name varchar(80) NOT NULL,
reg_field_id smallint NOT NULL, -- вимірювання основного регістру
column_prefix varchar(8) NOT NULL,
PRIMARY KEY (register_id, recalc_id, name),
FOREIGN KEY (register_id, recalc_id) REFERENCES md_register_recalc(register_id, id) ON DELETE CASCADE
);
</syntaxhighlight>

== 8.4. Регістр відомостей ==

=== 8.4.1. Незалежний періодичний (приклад: КурсиВалют) ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_i_0007 (
period timestamp(0) NOT NULL, -- Період (усічений до дня: WithinDay)
d1_r uuid NOT NULL, -- Вимірювання «Валюта»
r1 numeric(15,4) NOT NULL, -- Ресурс «Курс»
r2 numeric(10,0) NOT NULL DEFAULT 1, -- Ресурс «Кратність»
CONSTRAINT pk_rg_i_0007 PRIMARY KEY (period, d1_r)
);
-- Індекс для зрізу останніх у розрізі вимірювання
CREATE INDEX ix_rg_i_0007_d1 ON rg_i_0007 (d1_r, period DESC) INCLUDE (r1, r2);
ALTER TABLE rg_i_0007 ADD CONSTRAINT fk_rg_i_0007_d1
FOREIGN KEY (d1_r) REFERENCES cat_0003(ref); -- Довідник.Валюти
</syntaxhighlight>

=== 8.4.2. Підпорядкований реєстратору ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_i_0008 (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
period timestamp(0) NOT NULL,
active boolean NOT NULL DEFAULT true,
d1_r uuid NOT NULL,
r1 numeric(15,2) NOT NULL,
CONSTRAINT pk_rg_i_0008 PRIMARY KEY (rec_t, rec_r, line_no)
);
CREATE INDEX ix_rg_i_0008_period ON rg_i_0008 (period, rec_t, rec_r, line_no);
CREATE INDEX ix_rg_i_0008_d1 ON rg_i_0008 (d1_r, period) WHERE active;
</syntaxhighlight>

=== 8.4.3. Незалежний неперіодичний ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_i_0009 (
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
r1 varchar(200),
CONSTRAINT pk_rg_i_0009 PRIMARY KEY (d1_r, d2_r)
);
</syntaxhighlight>

== 8.5. Регістр накопичення ==

=== 8.5.1. Таблиця рухів ===
<syntaxhighlight lang="sql">
-- ТовариНаСкладах: dims = Номенклатура(d1), Склад(d2), Партія(d3, складений), Характеристика(d4)
-- res = Кількість(r1), Сума(r2); attr = Коментар(a1)
CREATE TABLE rg_a_0012 (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
period timestamp(0) NOT NULL,
active boolean NOT NULL DEFAULT true,
mvt smallint NOT NULL CHECK (mvt IN (0,1)), -- 0=Прихід, 1=Витрата
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
d3_t smallint NOT NULL, -- складене вимірювання «Партія»
d3_r uuid NOT NULL,
d4_r uuid NOT NULL,
r1 numeric(15,3) NOT NULL DEFAULT 0,
r2 numeric(15,2) NOT NULL DEFAULT 0,
a1 varchar(200),
CONSTRAINT pk_rg_a_0012 PRIMARY KEY (rec_t, rec_r, line_no)
) PARTITION BY RANGE (period);

CREATE TABLE rg_a_0012_p2026m07 PARTITION OF rg_a_0012
FOR VALUES FROM ('2026-07-01') TO ('2026-08-01');
-- ... інші секції створюються регламентним завданням

CREATE INDEX ix_rg_a_0012_period ON rg_a_0012 (period, rec_t, rec_r, line_no);
CREATE INDEX ix_rg_a_0012_d1 ON rg_a_0012 (d1_r, period, d2_r) WHERE active; -- Номенклатура (Індексувати з дод. вимірюваннями)
CREATE INDEX ix_rg_a_0012_d2 ON rg_a_0012 (d2_r, period, d1_r) WHERE active; -- Склад
</syntaxhighlight>

=== 8.5.2. Таблиця підсумків залишків ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_a_0012_tb (
period timestamp(0) NOT NULL, -- початок місяця; MAXPERIOD = підсумок за всі періоди
splitter smallint NOT NULL DEFAULT 0,
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
d3_t smallint NOT NULL,
d3_r uuid NOT NULL,
d4_r uuid NOT NULL,
r1 numeric(20,3) NOT NULL, -- Кількість, знаковий залишок
r2 numeric(20,2) NOT NULL, -- Сума
CONSTRAINT pk_rg_a_0012_tb PRIMARY KEY (period, d1_r, d2_r, d3_t, d3_r, d4_r, splitter)
);
-- покривний індекс для типового відбору «залишки по складу»
CREATE INDEX ix_rg_a_0012_tb_d2 ON rg_a_0012_tb (d2_r, period, d1_r) INCLUDE (r1, r2);
</syntaxhighlight>

'''Семантика:''' рядок з <code>period = P</code> містить залишок '''на початок''' періоду P. Рядок з <code>period = MAXPERIOD</code> — поточний залишок за всі періоди (використовується для запитів «залишки на зараз», найчастіший кейс).

=== 8.5.3. Таблиця підсумків оборотів ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_a_0012_tt (
period timestamp(0) NOT NULL, -- початок періоду агрегації (день/місяць)
splitter smallint NOT NULL DEFAULT 0,
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
d3_t smallint NOT NULL,
d3_r uuid NOT NULL,
d4_r uuid NOT NULL,
r1_in numeric(20,3) NOT NULL DEFAULT 0, -- Кількість Прихід
r1_out numeric(20,3) NOT NULL DEFAULT 0, -- Кількість Витрата
r2_in numeric(20,2) NOT NULL DEFAULT 0,
r2_out numeric(20,2) NOT NULL DEFAULT 0,
CONSTRAINT pk_rg_a_0012_tt PRIMARY KEY (period, d1_r, d2_r, d3_t, d3_r, d4_r, splitter)
);
</syntaxhighlight>

=== 8.5.4. Службова таблиця налаштувань ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_a_0012_opt (
id smallint PRIMARY KEY DEFAULT 1 CHECK (id = 1),
totals_actual_to timestamp(0) NOT NULL, -- ТА: підсумки розраховані до
use_bal_totals boolean NOT NULL DEFAULT true,
use_tno_totals boolean NOT NULL DEFAULT true,
min_period timestamp(0), -- період першого руху
last_recalc_at timestamp(0),
split_merge_at timestamp(0)
);
</syntaxhighlight>

=== 8.5.5. Агрегат (для РН виду «Обороти») ===
<syntaxhighlight lang="sql">
-- Агрегат «Продажі за місяцями по номенклатурі та складу» (без Партії, без Характеристики)
CREATE TABLE rg_a_0031_ag1 (
period timestamp(0) NOT NULL,
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
r1 numeric(20,3) NOT NULL,
r2 numeric(20,2) NOT NULL,
CONSTRAINT pk_rg_a_0031_ag1 PRIMARY KEY (period, d1_r, d2_r)
);
</syntaxhighlight>

== 8.6. Регістр бухгалтерії ==

=== 8.6.1. План рахунків (супутні таблиці) ===
<syntaxhighlight lang="sql">
CREATE TABLE coa_0005 ( -- ПланРахунків.Госпрозрахунковий
ref uuid PRIMARY KEY,
parent_ref uuid REFERENCES coa_0005(ref),
code varchar(20) NOT NULL,
order_code varchar(40) NOT NULL, -- впорядкований код для ієрархічних запитів
name varchar(150) NOT NULL,
acc_type smallint NOT NULL, -- 0=Активний,1=Пасивний,2=Активно-пасивний
off_balance boolean NOT NULL DEFAULT false,
ed_count smallint NOT NULL DEFAULT 0, -- фактична кількість субконто
fl_qty boolean NOT NULL DEFAULT false, -- ознака обліку «Кількісний»
fl_cur boolean NOT NULL DEFAULT false, -- ознака обліку «Валютний»
marked_del boolean NOT NULL DEFAULT false
);
CREATE UNIQUE INDEX ux_coa_0005_code ON coa_0005 (code);

CREATE TABLE coa_0005_ed ( -- ТЧ «ВидиСубконто»
ref uuid NOT NULL REFERENCES coa_0005(ref) ON DELETE CASCADE,
line_no int NOT NULL,
ed_type_r uuid NOT NULL, -- ПланВидівХарактеристик.ВидиСубконто
only_tno boolean NOT NULL DEFAULT false, -- «Тільки обороти»
sum_flag boolean NOT NULL DEFAULT true, -- «Підсумкова сума»
fl_qty boolean NOT NULL DEFAULT false, -- ознака обліку субконто «Кількісний»
PRIMARY KEY (ref, line_no)
);
</syntaxhighlight>

=== 8.6.2. Таблиця проводок (з кореспонденцією) ===
<syntaxhighlight lang="sql">
-- Госпрозрахунковий: dims = Організація(d1, балансове), Підрозділ(d2, небалансове)
-- res = Сума(r1, балансовий), Кількість(r2, небалансовий), ВалютнаСума(r3, небалансовий)
-- attr = Зміст(a1), Валюта(a2); max_extdim_count = 3
CREATE TABLE rg_b_0020 (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
period timestamp(0) NOT NULL,
active boolean NOT NULL DEFAULT true,

acc_dt_r uuid NOT NULL REFERENCES coa_0005(ref),
acc_kt_r uuid NOT NULL REFERENCES coa_0005(ref),

-- балансове вимірювання: одне значення на проводку
d1_r uuid NOT NULL,
-- небалансове вимірювання: окремо для Дт і Кт
d2_dt_r uuid NOT NULL,
d2_kt_r uuid NOT NULL,

-- субконто Дт (3 слоти, складений тип: ПВХ-значення)
ed_dt1_t smallint, ed_dt1_r uuid,
ed_dt2_t smallint, ed_dt2_r uuid,
ed_dt3_t smallint, ed_dt3_r uuid,
ed_dt_h bigint NOT NULL DEFAULT 0, -- хеш набору субконто Дт (для JOIN з підсумками)
-- субконто Кт
ed_kt1_t smallint, ed_kt1_r uuid,
ed_kt2_t smallint, ed_kt2_r uuid,
ed_kt3_t smallint, ed_kt3_r uuid,
ed_kt_h bigint NOT NULL DEFAULT 0,

-- балансовий ресурс: одне значення
r1 numeric(20,2) NOT NULL DEFAULT 0, -- Сума
-- небалансові ресурси: пара Дт/Кт
r2_dt numeric(20,3) NOT NULL DEFAULT 0, -- Кількість Дт
r2_kt numeric(20,3) NOT NULL DEFAULT 0, -- Кількість Кт
r3_dt numeric(20,2) NOT NULL DEFAULT 0, -- ВалютнаСума Дт
r3_kt numeric(20,2) NOT NULL DEFAULT 0,

a1 varchar(255),
a2_r uuid,
CONSTRAINT pk_rg_b_0020 PRIMARY KEY (rec_t, rec_r, line_no)
) PARTITION BY RANGE (period);

CREATE INDEX ix_rg_b_0020_period ON rg_b_0020 (period, rec_t, rec_r, line_no);
CREATE INDEX ix_rg_b_0020_acc_dt ON rg_b_0020 (acc_dt_r, period) WHERE active;
CREATE INDEX ix_rg_b_0020_acc_kt ON rg_b_0020 (acc_kt_r, period) WHERE active;
CREATE INDEX ix_rg_b_0020_ed_dt ON rg_b_0020 (ed_dt1_t, ed_dt1_r, period) WHERE active;
</syntaxhighlight>

{{Note|'''Проєктне рішення №2.''' Субконто зберігаються '''слотами в основній таблиці''', а не в дочірній таблиці «ключ-значення». Обґрунтування: (а) віртуальні таблиці <code>Залишки</code>/<code>Обороти</code> з відбором за субконто перетворюються на предикат по колонці замість <code>N</code> самоз'єднань; (б) кількість субконто жорстко обмежена (≤5) — «широка» таблиця прийнятна; (в) 1С використовує гібрид (<code>_AccRgED</code>), що дає складніші плани. '''Ціна:''' зміна <code>МаксКількістьСубконто</code> = реструктуризація таблиці. Альтернатива (дочірня таблиця <code>rg_b_0020_ed</code>) описана в Додатку Б і зберігається як план «Б» за результатами навантажувального тесту НТ-04.}}

=== 8.6.3. Таблиця проводок (без кореспонденції) ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_b_0021 (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
period timestamp(0) NOT NULL,
active boolean NOT NULL DEFAULT true,
acc_mvt smallint NOT NULL CHECK (acc_mvt IN (0,1)), -- 0=Дебет, 1=Кредит
acc_r uuid NOT NULL REFERENCES coa_0006(ref),
d1_r uuid NOT NULL,
ed1_t smallint, ed1_r uuid,
ed2_t smallint, ed2_r uuid,
ed3_t smallint, ed3_r uuid,
ed_h bigint NOT NULL DEFAULT 0,
r1 numeric(20,2) NOT NULL DEFAULT 0,
CONSTRAINT pk_rg_b_0021 PRIMARY KEY (rec_t, rec_r, line_no)
);
</syntaxhighlight>

=== 8.6.4. Підсумки РБ ===
Підсумки будуються на кількох «рівнях субконто» — щоб запит без відбору за субконто не сканував найдетальнішу таблицю.

<syntaxhighlight lang="sql">
-- Рівень 0: залишки по рахунку + балансові вимірювання (без субконто)
CREATE TABLE rg_b_0020_tb0 (
period timestamp(0) NOT NULL,
splitter smallint NOT NULL DEFAULT 0,
acc_r uuid NOT NULL,
d1_r uuid NOT NULL, -- Організація (балансове)
r1 numeric(24,2) NOT NULL, -- Сума: >0 = дебетовий, <0 = кредитовий залишок
r2 numeric(24,3) NOT NULL, -- Кількість
r3 numeric(24,2) NOT NULL,
CONSTRAINT pk_rg_b_0020_tb0 PRIMARY KEY (period, acc_r, d1_r, splitter)
);

-- Рівень 1..3: залишки з розшифровкою по субконто (тільки для рахунків з ed_count >= k)
CREATE TABLE rg_b_0020_tb1 (
period timestamp(0) NOT NULL, splitter smallint NOT NULL DEFAULT 0,
acc_r uuid NOT NULL, d1_r uuid NOT NULL,
ed1_t smallint NOT NULL, ed1_r uuid NOT NULL,
r1 numeric(24,2) NOT NULL, r2 numeric(24,3) NOT NULL, r3 numeric(24,2) NOT NULL,
CONSTRAINT pk_rg_b_0020_tb1 PRIMARY KEY (period, acc_r, d1_r, ed1_t, ed1_r, splitter)
);
CREATE TABLE rg_b_0020_tb2 (
period timestamp(0) NOT NULL, splitter smallint NOT NULL DEFAULT 0,
acc_r uuid NOT NULL, d1_r uuid NOT NULL,
ed1_t smallint NOT NULL, ed1_r uuid NOT NULL,
ed2_t smallint NOT NULL, ed2_r uuid NOT NULL,
r1 numeric(24,2) NOT NULL, r2 numeric(24,3) NOT NULL, r3 numeric(24,2) NOT NULL,
CONSTRAINT pk_rg_b_0020_tb2 PRIMARY KEY (period, acc_r, d1_r, ed1_t, ed1_r, ed2_t, ed2_r, splitter)
);
-- rg_b_0020_tb3 — аналогічно, 3 субконто

-- Обороти (аналогічні рівні): tt0..tt3
CREATE TABLE rg_b_0020_tt0 (
period timestamp(0) NOT NULL,
splitter smallint NOT NULL DEFAULT 0,
acc_r uuid NOT NULL,
d1_r uuid NOT NULL,
r1_dt numeric(24,2) NOT NULL, r1_kt numeric(24,2) NOT NULL,
r2_dt numeric(24,3) NOT NULL, r2_kt numeric(24,3) NOT NULL,
r3_dt numeric(24,2) NOT NULL, r3_kt numeric(24,2) NOT NULL,
CONSTRAINT pk_rg_b_0020_tt0 PRIMARY KEY (period, acc_r, d1_r, splitter)
);

-- Обороти між рахунками (кореспонденції)
CREATE TABLE rg_b_0020_tc (
period timestamp(0) NOT NULL,
splitter smallint NOT NULL DEFAULT 0,
acc_dt_r uuid NOT NULL,
acc_kt_r uuid NOT NULL,
d1_r uuid NOT NULL,
r1 numeric(24,2) NOT NULL,
CONSTRAINT pk_rg_b_0020_tc PRIMARY KEY (period, acc_dt_r, acc_kt_r, d1_r, splitter)
);
</syntaxhighlight>

'''Правило запису рівнів:''' для проводки з рахунком, що має <code>ed_count = k</code>, оновлюються таблиці <code>tb0 … tbK</code> (k+1 таблиць). Рахунки без субконто оновлюють лише <code>tb0</code>. Субконто з ознакою «Тільки обороти» не потрапляють у <code>tb*</code>, лише в <code>tt*</code>.

== 8.7. Регістр розрахунку ==

<syntaxhighlight lang="sql">
-- Нарахування: dims = Співробітник(d1, базове), Підрозділ(d2)
-- res = Результат(r1), ВідпрацьованоДнів(r2), НормаДнів(r3)
-- attr = Графік(a1)
CREATE TABLE rg_c_0040 (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
period timestamp(0) NOT NULL, -- період реєстрації (початок місяця)
active boolean NOT NULL DEFAULT true,
reversal boolean NOT NULL DEFAULT false, -- Сторно
calc_type_r uuid NOT NULL, -- ВидРозрахунку → pct_0011(ref)
act_begin timestamp(0) NOT NULL, -- ПеріодДіїПочаток
act_end timestamp(0) NOT NULL, -- ПеріодДіїКінець
base_begin timestamp(0), -- БазовийПеріодПочаток
base_end timestamp(0), -- БазовийПеріодКінець
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
r1 numeric(15,2) NOT NULL DEFAULT 0,
r2 numeric(5,0) NOT NULL DEFAULT 0,
r3 numeric(5,0) NOT NULL DEFAULT 0,
a1_r uuid,
CONSTRAINT pk_rg_c_0040 PRIMARY KEY (rec_t, rec_r, line_no),
CONSTRAINT chk_rg_c_0040_act CHECK (act_end >= act_begin)
);
CREATE INDEX ix_rg_c_0040_period ON rg_c_0040 (period, rec_t, rec_r, line_no);
CREATE INDEX ix_rg_c_0040_d1 ON rg_c_0040 (d1_r, period, calc_type_r) WHERE active;
CREATE INDEX ix_rg_c_0040_act ON rg_c_0040 (d1_r, act_begin, act_end) WHERE active;
CREATE INDEX ix_rg_c_0040_base ON rg_c_0040 (d1_r, calc_type_r, base_begin, base_end) WHERE active;

-- Фактичні періоди дії (після витіснення). Один запис → 0..N інтервалів.
CREATE TABLE rg_c_0040_ap (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
interval_no smallint NOT NULL,
calc_type_r uuid NOT NULL,
d1_r uuid NOT NULL, -- денормалізація базового вимірювання для швидкого JOIN
fact_begin timestamp(0) NOT NULL,
fact_end timestamp(0) NOT NULL,
CONSTRAINT pk_rg_c_0040_ap PRIMARY KEY (rec_t, rec_r, line_no, interval_no),
CONSTRAINT fk_rg_c_0040_ap FOREIGN KEY (rec_t, rec_r, line_no)
REFERENCES rg_c_0040 (rec_t, rec_r, line_no) ON DELETE CASCADE
);
CREATE INDEX ix_rg_c_0040_ap_d1 ON rg_c_0040_ap (d1_r, fact_begin, fact_end);

-- Перерахунок «ПерерахунокЗаБазою»
CREATE TABLE rg_c_0040_rc1 (
rec_t smallint NOT NULL, -- реєстратор запису, який треба перерахувати
rec_r uuid NOT NULL,
calc_type_r uuid NOT NULL, -- вид розрахунку, що потребує перерахунку
d1_r uuid NOT NULL, -- вимірювання перерахунку «Співробітник»
src_rec_t smallint NOT NULL, -- реєстратор, що спричинив перерахунок
src_rec_r uuid NOT NULL,
created_at timestamp(0) NOT NULL DEFAULT now(),
CONSTRAINT pk_rg_c_0040_rc1 PRIMARY KEY (rec_t, rec_r, calc_type_r, d1_r)
);
CREATE INDEX ix_rg_c_0040_rc1_src ON rg_c_0040_rc1 (src_rec_t, src_rec_r);
</syntaxhighlight>

== 8.8. Зведення: які таблиці породжує кожен тип регістру ==

<graphviz>
digraph Tables {
rankdir=LR; bgcolor="transparent"; ranksep=0.6; nodesep=0.08;
node [shape=box, style="filled,rounded", fontname="DejaVu Sans", fontsize=9, height=0.26];
edge [color="#9e9e9e", arrowhead=vee];

RI [label="РВ\n(незалежний або\nпідпорядкований)", fillcolor="#e8f5e9"];
RAB [label="РН «Залишки»", fillcolor="#fff8e1"];
RAT [label="РН «Обороти»", fillcolor="#fff8e1"];
RB [label="РБ", fillcolor="#fce4ec"];
RC [label="РР", fillcolor="#ede7f6"];

node [shape=cylinder, style=filled, fontname="Courier", fontsize=8, height=0.22];

i1 [label="rg_i_<id>", fillcolor="#c8e6c9"];
RI -> i1;

a1 [label="rg_a_<id>", fillcolor="#ffecb3"];
a2 [label="rg_a_<id>_tb", fillcolor="#ffe082"];
a3 [label="rg_a_<id>_tt", fillcolor="#ffe082"];
a4 [label="rg_a_<id>_opt", fillcolor="#fff3e0"];
RAB -> a1; RAB -> a2 [label=" якщо підсумки залишків", fontsize=7];
RAB -> a3 [label=" якщо підсумки оборотів", fontsize=7]; RAB -> a4;

t1 [label="rg_a_<id>", fillcolor="#ffecb3"];
t2 [label="rg_a_<id>_tt", fillcolor="#ffe082"];
t3 [label="rg_a_<id>_ag1..agN", fillcolor="#ffd54f"];
t4 [label="rg_a_<id>_opt", fillcolor="#fff3e0"];
RAT -> t1; RAT -> t2; RAT -> t3 [label=" агрегати", fontsize=7]; RAT -> t4;

b1 [label="rg_b_<id>", fillcolor="#f8bbd0"];
b2 [label="rg_b_<id>_tb0 .. _tbK", fillcolor="#f48fb1"];
b3 [label="rg_b_<id>_tt0 .. _ttK", fillcolor="#f48fb1"];
b4 [label="rg_b_<id>_tc", fillcolor="#f48fb1"];
b5 [label="rg_b_<id>_opt", fillcolor="#fce4ec"];
RB -> b1; RB -> b2 [label=" K = МаксКількістьСубконто", fontsize=7]; RB -> b3; RB -> b4; RB -> b5;

c1 [label="rg_c_<id>", fillcolor="#d1c4e9"];
c2 [label="rg_c_<id>_ap", fillcolor="#b39ddb"];
c3 [label="rg_c_<id>_rc1..rcM", fillcolor="#b39ddb"];
RC -> c1; RC -> c2 [label=" фактичні періоди", fontsize=7]; RC -> c3 [label=" перерахунки", fontsize=7];

{ rank=same; RI; RAB; RAT; RB; RC; }
}
</graphviz>

Оцінка: для РБ з <code>МаксКількістьСубконто = 3</code> генерується '''10 фізичних таблиць''' на один регістр.

= 9. ER-моделі =

== 9.1. ER-модель метаданих (репозиторій) ==

<uml>
@startuml
skinparam defaultFontName "DejaVu Sans"
hide circle
skinparam linetype ortho
skinparam shadowing false

entity "md_type" as T {
* id : smallint <<PK>>
--
* kind : varchar(20)
* name : varchar(80)
table_name : varchar(63)
}

entity "md_register" as R {
* id : smallint <<PK,FK→md_type>>
--
* name : varchar(80) <<U>>
* kind : varchar(12)
* write_mode : varchar(24)
* periodicity : varchar(24)
accumulation_kind : varchar(10)
enable_bal_totals : boolean
enable_tno_totals : boolean
tno_totals_period : varchar(6)
split_totals : boolean
chart_of_accounts_id : smallint <<FK>>
correspondence : boolean
max_extdim_count : smallint
calc_types_plan_id : smallint <<FK>>
use_action_period : boolean
base_period_mode : varchar(24)
schedule_register_id : smallint <<FK>>
* physical_table : varchar(63)
* struct_version : int
}

entity "md_register_field" as F {
* register_id : smallint <<PK,FK>>
* id : smallint <<PK>>
--
* name : varchar(80) <<U>>
* role : Dimension|Resource|Attribute
* data_type_expr : text
is_composite : boolean
index_mode : varchar(28)
is_master : boolean
is_balance : boolean
is_base_dimension : boolean
accounting_flag : varchar(80)
* column_prefix : varchar(8)
}

entity "md_register_recorder" as RR {
* register_id : smallint <<PK,FK>>
* doc_type_id : smallint <<PK,FK>>
}

entity "md_register_aggregate" as AG {
* register_id : smallint <<PK,FK>>
* id : smallint <<PK>>
--
* name : varchar(80)
* periodicity : Day|Month|Quarter|Year
is_realtime : boolean
actual_upto : timestamp
}

entity "md_register_aggregate_dim" as AGD {
* register_id : smallint <<PK,FK>>
* aggregate_id : smallint <<PK,FK>>
* field_id : smallint <<PK,FK>>
}

entity "md_register_recalc" as RC {
* register_id : smallint <<PK,FK>>
* id : smallint <<PK>>
--
* name : varchar(80)
* physical_table : varchar(63)
}

entity "md_register_recalc_dim" as RCD {
* register_id : smallint <<PK,FK>>
* recalc_id : smallint <<PK,FK>>
* name : varchar(80) <<PK>>
--
* reg_field_id : smallint <<FK>>
}

T ||--o| R : "є регістром"
T ||--o{ RR : "тип документа"
R ||--|{ F : "має поля"
R ||--o{ RR : "реєстратори"
R ||--o{ AG : "агрегати"
AG ||--|{ AGD : "склад вимірювань"
F ||--o{ AGD : "вимірювання"
R ||--o{ RC : "перерахунки"
RC ||--|{ RCD : "вимірювання перерахунку"
F ||--o{ RCD : "відповідає"
R }o--o| T : "план рахунків"
R }o--o| T : "план видів розрахунку"
R }o--o| R : "графік часу"
@enduml
</uml>

== 9.2. ER-модель: регістр накопичення (вид «Залишки») ==

<uml>
@startuml
skinparam defaultFontName "DejaVu Sans"
hide circle
skinparam linetype ortho
skinparam shadowing false

entity "doc_0002\n«ПрихіднаНакладна»" as D1 {
* ref : uuid <<PK>>
--
number : varchar
date : timestamp
posted : boolean
}
entity "doc_0003\n«ВидатковаНакладна»" as D2 {
* ref : uuid <<PK>>
--
number : varchar
date : timestamp
posted : boolean
}
entity "cat_0001\n«Номенклатура»" as C1 {
* ref : uuid <<PK>>
--
code, name
}
entity "cat_0004\n«Склади»" as C2 {
* ref : uuid <<PK>>
--
code, name
}

entity "rg_a_0012\n«ТовариНаСкладах» (рухи)" as M {
* rec_t : smallint <<PK>>
* rec_r : uuid <<PK>>
* line_no : int <<PK>>
--
* period : timestamp(0)
* active : boolean
* mvt : smallint «0=Прихід,1=Витрата»
* d1_r : uuid «Номенклатура» <<FK>>
* d2_r : uuid «Склад» <<FK>>
* d3_t : smallint «Партія:тип»
* d3_r : uuid «Партія:посилання»
* d4_r : uuid «Характеристика» <<FK>>
* r1 : numeric(15,3) «Кількість»
* r2 : numeric(15,2) «Сума»
a1 : varchar(200) «Коментар»
}

entity "rg_a_0012_tb\nпідсумки залишків" as TB {
* period : timestamp(0) <<PK>>
* d1_r : uuid <<PK>>
* d2_r : uuid <<PK>>
* d3_t : smallint <<PK>>
* d3_r : uuid <<PK>>
* d4_r : uuid <<PK>>
* splitter : smallint <<PK>>
--
* r1 : numeric(20,3) «Кількість (±)»
* r2 : numeric(20,2) «Сума (±)»
}

entity "rg_a_0012_tt\nпідсумки оборотів" as TT {
* period : timestamp(0) <<PK>>
* d1_r : uuid <<PK>>
* d2_r : uuid <<PK>>
* d3_t : smallint <<PK>>
* d3_r : uuid <<PK>>
* d4_r : uuid <<PK>>
* splitter : smallint <<PK>>
--
r1_in, r1_out : numeric(20,3)
r2_in, r2_out : numeric(20,2)
}

entity "rg_a_0012_opt" as OPT {
* id : smallint = 1 <<PK>>
--
* totals_actual_to : timestamp(0)
use_bal_totals : boolean
use_tno_totals : boolean
min_period : timestamp(0)
}

D1 ||..o{ M : "реєстратор\n(поліморфний, без FK)"
D2 ||..o{ M : "реєстратор\n(поліморфний, без FK)"
C1 ||--o{ M : "d1_r"
C2 ||--o{ M : "d2_r"
M }o..|| TB : "агрегується в\n(підтримується платформою)"
M }o..|| TT : "агрегується в"
OPT ||..|| TB : "ТА підсумків"

note bottom of M
PK = (rec_t, rec_r, line_no)
→ усі рухи одного документа
фізично суміжні
Партиціонування: RANGE(period)
end note

note bottom of TB
period = MAXPERIOD ('5999-11-01')
→ рядок «залишок за всі періоди»
end note
@enduml
</uml>

== 9.3. ER-модель: регістр бухгалтерії ==

<uml>
@startuml
skinparam defaultFontName "DejaVu Sans"
hide circle
skinparam linetype ortho
skinparam shadowing false

entity "coa_0005\n«План рахунків»" as A {
* ref : uuid <<PK>>
--
parent_ref : uuid <<FK>>
* code : varchar(20) <<U>>
order_code : varchar(40)
* name : varchar(150)
* acc_type : smallint «Акт/Пас/АП»
off_balance : boolean
ed_count : smallint
fl_qty, fl_cur : boolean
}
entity "coa_0005_ed\n«Види субконто рахунку»" as AE {
* ref : uuid <<PK,FK>>
* line_no : int <<PK>>
--
* ed_type_r : uuid <<FK>>
only_tno : boolean
sum_flag : boolean
}
entity "cvt_0009\n«ПВХ.ВидиСубконто»" as VT {
* ref : uuid <<PK>>
--
code, name
value_type : text
}

entity "rg_b_0020\n«Госпрозрахунковий» (проводки)" as J {
* rec_t : smallint <<PK>>
* rec_r : uuid <<PK>>
* line_no : int <<PK>>
--
* period : timestamp(0)
* active : boolean
* acc_dt_r : uuid <<FK>>
* acc_kt_r : uuid <<FK>>
* d1_r : uuid «Організація (балансове)»
* d2_dt_r : uuid «Підрозділ Дт»
* d2_kt_r : uuid «Підрозділ Кт»
ed_dt1_t/_r .. ed_dt3_t/_r : «субконто Дт»
ed_dt_h : bigint
ed_kt1_t/_r .. ed_kt3_t/_r : «субконто Кт»
ed_kt_h : bigint
* r1 : numeric(20,2) «Сума (балансовий)»
r2_dt, r2_kt : numeric(20,3) «Кількість»
r3_dt, r3_kt : numeric(20,2) «ВалютнаСума»
a1 : varchar(255) «Зміст»
a2_r : uuid «Валюта»
}

entity "rg_b_0020_tb0\nзалишки, рівень 0" as B0 {
* period <<PK>>
* acc_r <<PK>>
* d1_r <<PK>>
* splitter <<PK>>
--
r1, r2, r3 : numeric «знакові»
}
entity "rg_b_0020_tb1..tb3\nзалишки, рівні 1..3" as B1 {
* period <<PK>>
* acc_r <<PK>>
* d1_r <<PK>>
* ed1_t, ed1_r <<PK>>
* (ed2_t, ed2_r) <<PK>>
* (ed3_t, ed3_r) <<PK>>
* splitter <<PK>>
--
r1, r2, r3 : numeric
}
entity "rg_b_0020_tt0..tt3\nобороти за рівнями" as T0 {
* period <<PK>>
* acc_r <<PK>>
* d1_r <<PK>>
* (ed…) <<PK>>
--
r1_dt, r1_kt
r2_dt, r2_kt
r3_dt, r3_kt
}
entity "rg_b_0020_tc\nобороти Дт↔Кт" as TC {
* period <<PK>>
* acc_dt_r <<PK>>
* acc_kt_r <<PK>>
* d1_r <<PK>>
--
r1 : numeric(24,2)
}

A ||--o{ AE : "види субконто"
VT ||--o{ AE : "тип субконто"
A ||--o{ J : "acc_dt_r"
A ||--o{ J : "acc_kt_r"
A ||--o{ B0 : "acc_r"
A ||--o{ B1 : "acc_r"
J }o..|| B0 : "агрегується (Дт: +, Кт: −)"
J }o..|| B1 : "агрегується, якщо ed_count ≥ k"
J }o..|| T0 : "агрегується"
J }o..|| TC : "агрегується"

note right of J
Балансовий ресурс r1 — одне значення,
контроль Σ(Дт) = Σ(Кт) у межах реєстратора.
Небалансові ресурси — пара Дт/Кт.
Субконто — слоти (див. Рішення №2).
end note
@enduml
</uml>

== 9.4. ER-модель: регістр розрахунку ==

<uml>
@startuml
skinparam defaultFontName "DejaVu Sans"
hide circle
skinparam linetype ortho
skinparam shadowing false

entity "pct_0011\n«ПВР.ОсновніНарахування»" as P {
* ref : uuid <<PK>>
--
code, name
use_action_period : boolean
base_dependency : varchar(24)
}
entity "pct_0011_base\n«Базові види розрахунку»" as PB {
* ref <<PK,FK>>
* line_no <<PK>>
--
* base_type_r : uuid <<FK>>
}
entity "pct_0011_displace\n«Витісняючі види розрахунку»" as PD {
* ref <<PK,FK>>
* line_no <<PK>>
--
* displacing_type_r : uuid <<FK>>
}
entity "pct_0011_lead\n«Ведучі види розрахунку»" as PL {
* ref <<PK,FK>>
* line_no <<PK>>
--
* leading_type_r : uuid <<FK>>
}

entity "rg_c_0040\n«Нарахування» (рухи)" as CR {
* rec_t : smallint <<PK>>
* rec_r : uuid <<PK>>
* line_no : int <<PK>>
--
* period : timestamp(0) «період реєстрації»
* active : boolean
* reversal : boolean «Сторно»
* calc_type_r : uuid <<FK>>
* act_begin : timestamp(0)
* act_end : timestamp(0)
base_begin : timestamp(0)
base_end : timestamp(0)
* d1_r : uuid «Співробітник (базове)»
* d2_r : uuid «Підрозділ»
r1 : numeric «Результат»
r2 : numeric «ВідпрацьованоДнів»
r3 : numeric «НормаДнів»
}

entity "rg_c_0040_ap\nфактичні періоди дії" as AP {
* rec_t <<PK,FK>>
* rec_r <<PK,FK>>
* line_no <<PK,FK>>
* interval_no : smallint <<PK>>
--
* calc_type_r : uuid
* d1_r : uuid
* fact_begin : timestamp(0)
* fact_end : timestamp(0)
}

entity "rg_c_0040_rc1\n«ПерерахунокЗаБазою»" as RC {
* rec_t <<PK>>
* rec_r <<PK>>
* calc_type_r <<PK>>
* d1_r <<PK>>
--
src_rec_t, src_rec_r
created_at
}

entity "rg_i_0015\n«ГрафікРоботи» (РВ)" as SCH {
* d1_r : uuid <<PK>> «ВидГрафіка»
* d2_d : timestamp(0) <<PK>> «ДатаГрафіка»
--
r1 : numeric «Значення»
}

entity "doc_0007\n«НарахуванняЗарплати»" as DOC {
* ref : uuid <<PK>>
--
number, date, posted
}

P ||--o{ CR : "calc_type_r"
P ||--o{ PB : "базові"
P ||--o{ PD : "витісняючі"
P ||--o{ PL : "ведучі"
DOC ||..o{ CR : "реєстратор"
CR ||--|{ AP : "1 запис → 0..N\nфактичних інтервалів"
CR }o..o{ RC : "потребує перерахунку"
SCH }o..o{ CR : "ДаніГрафіка\n(віртуальна таблиця)"
CR }o..o{ CR : "БазаРозрахунку\n(self-join через PB\nта базові вимірювання)"
@enduml
</uml>

== 9.5. Зведена концептуальна ER (усі типи) ==

<graphviz>
digraph ER {
rankdir=LR; bgcolor="transparent";
node [shape=record, fontname="DejaVu Sans", fontsize=9, style=filled];
edge [fontname="DejaVu Sans", fontsize=8];

MD [label="{md_register|id (PK)\lname\lkind\lperiodicity\lwrite_mode\l...}", fillcolor="#dbe9ff"];
MDF [label="{md_register_field|register_id (PK,FK)\lid (PK)\lname\lrole\ldata_type\l...}", fillcolor="#dbe9ff"];
MDR [label="{md_register_recorder|register_id (PK,FK)\ldoc_type_id (PK,FK)\l}", fillcolor="#dbe9ff"];

DOC [label="{doc_XXXX (Документ)|ref (PK)\lnumber\ldate\lposted\l}", fillcolor="#fff8e1"];
CAT [label="{cat_XXXX (Довідник)|ref (PK)\lcode\lname\l}", fillcolor="#fff8e1"];
COA [label="{coa_XXXX (План рахунків)|ref (PK)\lcode\lacc_type\led_count\l}", fillcolor="#fff8e1"];
PCT [label="{pct_XXXX (ПВР)|ref (PK)\lcode\l}", fillcolor="#fff8e1"];

RI [label="{rg_i_XXXX (РВ)|period (PK*)\ld1..dN (PK*)\l| rec_t,rec_r,line_no (PK**)\lr1..rM\l}", fillcolor="#e8f5e9"];
RA [label="{rg_a_XXXX (РН)|rec_t, rec_r, line_no (PK)\lperiod\lactive\lmvt\ld1..dN\lr1..rM\l}", fillcolor="#fff3e0"];
RAT [label="{rg_a_XXXX_tb / _tt|period (PK)\ld1..dN (PK)\lsplitter (PK)\lr1..rM\l}", fillcolor="#ffe0b2"];
RB [label="{rg_b_XXXX (РБ)|rec_t, rec_r, line_no (PK)\lperiod, active\lacc_dt_r, acc_kt_r\led_dt1..3, ed_kt1..3\ld1..dN\lr1, r2_dt/r2_kt\l}", fillcolor="#fce4ec"];
RBT [label="{rg_b_XXXX_tb0..tbK\lrg_b_XXXX_tt0..ttK\lrg_b_XXXX_tc|period, acc_r, d1..dN\led1..edK (PK)\lr1..rM\l}", fillcolor="#f8bbd0"];
RC [label="{rg_c_XXXX (РР)|rec_t, rec_r, line_no (PK)\lperiod, active, reversal\lcalc_type_r\lact_begin, act_end\lbase_begin, base_end\ld1..dN, r1..rM\l}", fillcolor="#ede7f6"];
RCA [label="{rg_c_XXXX_ap|rec_t,rec_r,line_no (PK,FK)\linterval_no (PK)\lfact_begin, fact_end\l}", fillcolor="#d1c4e9"];
RCR [label="{rg_c_XXXX_rc1..rcM|rec_t, rec_r (PK)\lcalc_type_r (PK)\ld1..dN (PK)\l}", fillcolor="#d1c4e9"];

MD -> MDF [label="1:N"];
MD -> MDR [label="1:N"];
MDR -> DOC [label="тип"];
MD -> COA [label="0:1 план рахунків", style=dashed];
MD -> PCT [label="0:1 ПВР", style=dashed];

MD -> RI [label="генерує DDL", style=dotted, color=blue];
MD -> RA [label="генерує DDL", style=dotted, color=blue];
MD -> RB [label="генерує DDL", style=dotted, color=blue];
MD -> RC [label="генерує DDL", style=dotted, color=blue];

DOC -> RI [label="реєстратор (поліморф.)", style=dashed];
DOC -> RA [label="реєстратор (поліморф.)", style=dashed];
DOC -> RB [label="реєстратор (поліморф.)", style=dashed];
DOC -> RC [label="реєстратор (поліморф.)", style=dashed];

CAT -> RI [label="FK вимір."];
CAT -> RA [label="FK вимір."];
COA -> RB [label="FK рахунок"];
PCT -> RC [label="FK вид розрах."];

RA -> RAT [label="агрегація (платформа)", color=darkgreen];
RB -> RBT [label="агрегація (платформа)", color=darkgreen];
RC -> RCA [label="витіснення → 1:N", color=purple];
RC -> RCR [label="реєстрація перерахунків", color=purple, style=dashed];

{ rank=same; MD; MDF; MDR; }
{ rank=same; RI; RA; RB; RC; }
}
</graphviz>

'''Легенда:'''
* <code>(PK*)</code> — ключ для незалежного РВ; <code>(PK**)</code> — для підпорядкованого.
* Пунктир «реєстратор» — логічний зв'язок без FK (поліморфне посилання, підтримується платформою).
* Пунктир «генерує DDL» — метадані → фізична схема (не зв'язок даних).

= 10. Ключові алгоритми =

== 10.1. Запис набору записів (режим «Заміщати») ==

<syntaxhighlight lang="python">
def write_record_set(reg: Register, rs: RecordSet, replace: bool = True) -> None:
"""Розділ 7.1, ФТ-01…ФТ-04. Уся операція — в одній транзакції."""
check_rights(reg, Right.INSERT | Right.UPDATE) # ФТ-37
validate(reg, rs) # реєстратор ∈ md_register_recorder;
# deny_empty; для РБ — Σ Дт = Σ Кт
with conn.begin(): # ФТ-03: одна транзакція
old = read_for_update(reg, rs.filter) # SELECT ... FOR UPDATE

# АП-2: дельта рахується набором, один раз; тільки active-записи
delta = aggregate(rs.active_records, sign=+1) + aggregate(old, sign=-1)

if replace: # ФТ-04
conn.execute(delete(tbl).where(*rs.filter.clauses)) # 1 запит
conn.execute(insert(tbl), rs.as_dicts()) # 1 executemany (АП-1)

update_totals(reg, delta) # -> merge_totals(), розділи 10.2, Е.3

if reg.kind is RegisterKind.CALCULATION:
keys = rs.affected_keys | affected_keys(old)
recompute_actual_periods(reg, keys) # розділ 10.4
register_recalculations(reg, [*rs.records, *old]) # розділ 10.5
</syntaxhighlight>

== 10.2. Інкрементальне оновлення підсумків залишків ==

<syntaxhighlight lang="sql">
-- Δ (delta) — тимчасова таблиця: (period_month, d1_r, d2_r, d3_t, d3_r, d4_r, dr1, dr2)
-- де dr = Σ (CASE WHEN mvt = 0 THEN +значення ELSE -значення END)

-- Крок 1. Кумулятивні залишки: рух у місяці M впливає на підсумки всіх періодів > M
-- та на рядок MAXPERIOD.
INSERT INTO rg_a_0012_tb AS t (period, splitter, d1_r, d2_r, d3_t, d3_r, d4_r, r1, r2)
SELECT p.period, :splitter, d.d1_r, d.d2_r, d.d3_t, d.d3_r, d.d4_r, d.dr1, d.dr2
FROM delta d
CROSS JOIN LATERAL (
SELECT period FROM totals_periods
WHERE period > d.period_month
AND period <= (SELECT totals_actual_to FROM rg_a_0012_opt)
UNION ALL SELECT TIMESTAMP '5999-11-01' -- MAXPERIOD
) p
ORDER BY 1,3,4,5,6,7 -- детермінований порядок → без дедлоків
ON CONFLICT (period, d1_r, d2_r, d3_t, d3_r, d4_r, splitter)
DO UPDATE SET r1 = t.r1 + EXCLUDED.r1,
r2 = t.r2 + EXCLUDED.r2;

-- Крок 2. Прибирання нульових рядків (регламентно, не в транзакції проведення)
DELETE FROM rg_a_0012_tb WHERE r1 = 0 AND r2 = 0 AND period <> TIMESTAMP '5999-11-01';
</syntaxhighlight>

{{Note|'''Оптимізація.''' Крок 1 у наведеному вигляді має складність O(кількість_періодів_після_руху). Для рухів «заднім числом» на роки це дорого. '''Проєктне рішення №3:''' підсумки оновлюються тільки для рядка <code>MAXPERIOD</code> і для найближчої межі періоду; повні кумулятивні зрізи перебудовуються регламентним завданням «Перерахунок підсумків» за зміненими місяцями (список змінених місяців накопичується в <code>rg_a_0012_opt.dirty_months</code>). Запити на дату в «брудному» місяці автоматично перемикаються на розрахунок від найближчого чистого зрізу. Остаточний вибір — за результатами НТ-02.}}

== 10.3. Трансляція віртуальної таблиці «Залишки» ==

<syntaxhighlight lang="sql">
-- РегістрНакопичення.ТовариНаСкладах.Залишки(&Період, Склад = &Склад)
WITH boundary AS (
SELECT COALESCE(MAX(period), TIMESTAMP '0001-01-01') AS p
FROM totals_periods
WHERE period <= :Період
AND period <= (SELECT totals_actual_to FROM rg_a_0012_opt)
),
base AS ( -- залишок на межу періоду з підсумків
SELECT t.d1_r, t.d2_r, t.d3_t, t.d3_r, t.d4_r,
SUM(t.r1) AS r1, SUM(t.r2) AS r2
FROM rg_a_0012_tb t, boundary b
WHERE t.period = b.p
AND t.d2_r = :Склад -- push-down параметра ВТ
GROUP BY 1,2,3,4,5
),
tail AS ( -- «живі» рухи після межі й до &Період
SELECT m.d1_r, m.d2_r, m.d3_t, m.d3_r, m.d4_r,
SUM(CASE WHEN m.mvt = 0 THEN m.r1 ELSE -m.r1 END) AS r1,
SUM(CASE WHEN m.mvt = 0 THEN m.r2 ELSE -m.r2 END) AS r2
FROM rg_a_0012 m, boundary b
WHERE m.active
AND m.period > b.p
AND m.period <= :Період
AND m.d2_r = :Склад
GROUP BY 1,2,3,4,5
)
SELECT d1_r AS "Номенклатура", d2_r AS "Склад",
d3_t, d3_r AS "Партія", d4_r AS "Характеристика",
SUM(r1) AS "КількістьЗалишок",
SUM(r2) AS "СумаЗалишок"
FROM (SELECT * FROM base UNION ALL SELECT * FROM tail) u
GROUP BY 1,2,3,4,5
HAVING SUM(r1) <> 0 OR SUM(r2) <> 0; -- нульові залишки не повертаються
</syntaxhighlight>

'''Оптимізація для найчастішого випадку:''' якщо <code>:Період ≥ ТА</code> і в регістрі немає рухів у майбутньому — <code>base</code> читається з рядка <code>MAXPERIOD</code> одним index seek, <code>tail</code> = ∅.

== 10.4. Розрахунок фактичних періодів дії (витіснення) ==

<syntaxhighlight lang="python">
def recompute_actual_periods(reg: Register, keys: set[DimKey]) -> None:
"""Розділ 7.5.1, ФТ-22…ФТ-24. Тут — оркестрація; сам алгоритм — Додаток Е.5."""
tbl = schema.movements(reg)
ap = schema.actual_periods(reg) # rg_c_<id>_ap

# 1. Читання всіх записів зачеплених ключів — ОДИН запит (АП-1)
records = conn.execute(
select(tbl).where(tbl.c.active, dim_key_in(tbl, keys))
).all()

# 2. Перерахунок інтервалів. Гарячий шлях: бюджет ≤ 3 c (АП-4),
# реалізація за Protocol-інтерфейсом (АП-3) — див. Е.5.
# Пріоритет: A витісняється B, якщо B ∈ ПВР[A].ВитісняючіВидиРозрахунку
intervals = displacement_engine.compute(records, displaces=plan.displaces)

# 3. Заміщення фактичних періодів — два запити на весь набір, не на запис
conn.execute(delete(ap).where(record_key_in(ap, intervals.keys())))
conn.execute(insert(ap), [
{"rec_t": k.rec_t, "rec_r": k.rec_r, "line_no": k.line_no,
"interval_no": n, "calc_type_r": k.calc_type, "d1_r": k.base_dim,
"fact_begin": begin, "fact_end": end}
for k, ivs in intervals.items()
for n, (begin, end) in enumerate(ivs) # 1 запис -> 0..N інтервалів
])
</syntaxhighlight>

'''Складність:''' O(|Z|² ) на ключ. Обмеження: якщо <code>|Z| > 500</code> для одного ключа — попередження в журналі та перехід на алгоритм замітання (sweep line) O(|Z| log |Z|).

== 10.5. Реєстрація перерахунків ==

<syntaxhighlight lang="python">
def register_recalculations(reg: Register, changed: Sequence[CalcRecord]) -> None:
"""Розділ 7.5.3, ФТ-26. АП-2: пошук залежних виконує СКБД, а не цикл у Python."""
q = schema.movements(reg).alias("q")
b = schema.calc_plan_base(reg).alias("b") # ТЧ «БазовіВидиРозрахунку» ПВР

for recalc in reg.recalculations:
rc = schema.recalc_table(reg, recalc) # rg_c_<id>_rc<n>
src = values_of(changed).alias("src") # змінені записи як VALUES-таблиця

# інтервальний предикат залежно від режиму базового періоду
if reg.base_period == "ByActionPeriod":
in_base = and_(src.c.act_begin <= q.c.base_end,
src.c.act_end >= q.c.base_begin) # перетин періодів
else: # ByRegistrationPeriod
in_base = src.c.period.between(q.c.base_begin, q.c.base_end)

dependent = (
select(q.c.rec_t, q.c.rec_r, q.c.calc_type_r,
*[q.c[c] for c in recalc.dim_columns],
src.c.rec_t.label("src_rec_t"), src.c.rec_r.label("src_rec_r"))
.select_from(
src.join(b, b.c.base_type_r == src.c.calc_type_r) # z — базовий для q
.join(q, q.c.calc_type_r == b.c.ref))
.where(q.c.active, in_base,
*[q.c[c] == src.c[c] for c in recalc.dim_columns],
tuple_(q.c.rec_t, q.c.rec_r) != tuple_(src.c.rec_t, src.c.rec_r))
.distinct()
)

stmt = pg_insert(rc).from_select(list(rc.columns.keys()), dependent)
conn.execute(stmt.on_conflict_do_nothing()) # 1 запит на перерахунок (АП-1)
</syntaxhighlight>

== 10.6. Зріз останніх ==

<syntaxhighlight lang="sql">
-- РегістрВідомостей.КурсиВалют.ЗрізОстанніх(&Дата, Валюта В (&Список))
SELECT DISTINCT ON (r.d1_r)
r.d1_r AS "Валюта", r.period AS "Період", r.r1 AS "Курс", r.r2 AS "Кратність"
FROM rg_i_0007 r
WHERE r.period <= :Дата
AND r.d1_r = ANY (:Список)
ORDER BY r.d1_r, r.period DESC; -- використовує ix_rg_i_0007_d1 (d1_r, period DESC)
-- Для MS SQL: ROW_NUMBER() OVER (PARTITION BY d1_r ORDER BY period DESC) = 1
-- або OUTER APPLY (SELECT TOP 1 ...) для великих списків.
</syntaxhighlight>

= 11. Нефункціональні вимоги =

== 11.1. Продуктивність ==
Еталонний стенд: 16 vCPU, 128 ГБ RAM, NVMe, PostgreSQL 15, БД 1,5 ТБ.

{| class="wikitable"
! № !! Операція !! Обсяг !! Ціль (P95)
|-
| НФВ-01 || Залишки на поточну дату, відбір за 1 вимірюванням || 1 млрд рухів, 20 млн рядків підсумків || ≤ 200 мс
|-
| НФВ-02 || Залишки на довільну дату в межах ТА || те саме || ≤ 400 мс
|-
| НФВ-03 || Обороти за 12 місяців із групуванням || 1 млрд рухів || ≤ 2 с
|-
| НФВ-04 || Проведення документа зі 100 рядками рухів (3 регістри) || — || ≤ 300 мс
|-
| НФВ-05 || Оборотно-сальдова відомість по всіх рахунках за місяць || 200 млн проводок || ≤ 5 с
|-
| НФВ-06 || Розрахунок ЗП: 10 000 співробітників × 8 видів розрахунку || — || ≤ 10 хв
|-
| НФВ-07 || Зріз останніх по 5 000 елементів вимірювання || 50 млн записів РВ || ≤ 500 мс
|-
| НФВ-08 || Пропускна здатність проведення || — || ≥ 50 док/с (10 паралельних сеансів)
|-
| НФВ-09 || Перерахунок підсумків РН || 1 млрд рухів || ≤ 4 год (у вікні обслуговування)
|}

{{Note|'''Вплив мови ядра.''' Цілі НФВ-01…НФВ-09 сформульовані для архітектури, де обчислює СКБД, а Python-ядро лише формує SQL (принципи АП-1, АП-2). Аналіз частки Python у кожній цілі — розділ 4.4.2: максимум 5 % (НФВ-04), запас на НФВ-06 — ×40. '''Цілі не переглядаються у зв'язку з вибором Python.'''}}

== 11.2. Масштабованість і обсяги ==
{| class="wikitable"
! Параметр !! Значення
|-
| Макс. записів в одному регістрі || 10<sup>10</sup>
|-
| Макс. кількість регістрів у конфігурації || 2 000
|-
| Макс. одночасних сеансів проведення || 200
|-
| Секціонування || Обов'язкове для таблиць > 100 млн записів
|}

== 11.3. Надійність і цілісність ==
* НФВ-10. Рухи та реєстратор змінюються в одній транзакції БД; часткове проведення неможливе.
* НФВ-11. Аварійне завершення сервера не залишає підсумки неузгодженими (гарантується транзакцією).
* НФВ-12. Сервіс перевірки цілісності (ФТ-41) виконується регламентно; розбіжність підсумків = інцидент P1.

== 11.4. Супроводжуваність ==
* НФВ-13. Реструктуризація регістру (додавання ресурсу/реквізиту) для таблиці ≤ 100 млн записів — ≤ 30 хв.
* НФВ-14. Додавання вимірювання вимагає перебудови підсумків; система повинна попереджати про оцінку часу до початку операції.
* НФВ-15. Усі DDL-операції — ідемпотентні та скриптовані (можливість застосувати вручну).

== 11.5. Сумісність ==
* НФВ-16. PostgreSQL 14+ та MS SQL Server 2019+ — обидві платформи з однаковою функціональністю.
* НФВ-17. Генератор DDL ізольований у шар «діалект СКБД».

= 12. Міграція існуючих структур K2 ERP =

== 12.1. Етапи ==
{| class="wikitable"
! № !! Етап !! Результат
|-
| М1 || Інвентаризація || Реєстр наявних «регістроподібних» таблиць K2 з класифікацією за типом-мішенню (РВ/РН/РБ/РР).
|-
| М2 || Мапінг || Для кожної таблиці — метаопис цільового регістру + правила перетворення колонок.
|-
| М3 || Створення регістрів || Генерація метаданих і DDL у тестовому контурі.
|-
| М4 || Перенесення даних || ETL: історичні дані → рухи, з призначенням реєстратора (реальний документ або службовий «ВведенняЗалишків»).
|-
| М5 || Побудова підсумків || Повний перерахунок.
|-
| М6 || Звірка || Порівняння залишків/оборотів «стара система vs нова» на контрольних датах; допуск розбіжності = 0.
|-
| М7 || Перемикання коду || Заміна прямих SQL-звернень на віртуальні таблиці; період паралельної роботи ≥ 1 звітний період.
|-
| М8 || Виведення з експлуатації || Видалення старих таблиць після 2 закритих періодів.
|}

== 12.2. Проблемні випадки ==
{| class="wikitable"
! Випадок !! Рішення
|-
| Історичні записи без документа-джерела || Службовий документ <code>ВведенняЗалишків</code> (один на період/розділ).
|-
| Записи з дублями за ключем (для незалежного РВ) || Дедуплікація з протоколом; конфлікти — на ручний розбір.
|-
| Дробові періоди / некоректні дати (NULL, 1900-01-01) || Нормалізація до MINPERIOD; протокол.
|-
| Прикладний код, що пише в таблиці напряму || Заборона на рівні прав БД після М7; аудит звернень на етапі М3–М6.
|-
| Аналітика, відсутня в цільовій моделі || Перенесення в реквізити (не у вимірювання) або відмова від міграції з обґрунтуванням.
|}

= 13. Приймальні випробування =

== 13.1. Функціональні тести (витяг) ==
{| class="wikitable"
! ID !! Сценарій !! Очікуваний результат
|-
| ФТ-Т-01 || Створити РВ періодичний незалежний, записати 2 записи з однаковим ключем || Другий запис заміщує перший; у таблиці 1 рядок
|-
| ФТ-Т-02 || Провести документ → 5 рухів РН || 5 записів у <code>rg_a_*</code>; підсумки MAXPERIOD змінилися на суму дельти
|-
| ФТ-Т-03 || Скасувати проведення || 0 записів; підсумки повернулися до вихідних значень
|-
| ФТ-Т-04 || Видалити документ-реєстратор || Рухи видалені каскадно; перевірка цілісності — 0 помилок
|-
| ФТ-Т-05 || Записати рух заднім числом (−6 міс.) || Залишки на всі дати після руху коректні (звірка з повним перерахунком)
|-
| ФТ-Т-06 || Установити <code>Активність = Хиба</code> || Запис не впливає на віртуальні таблиці; підсумки скориговані
|-
| ФТ-Т-07 || РБ: провести незбалансовану проводку (Дт ≠ Кт за балансовим ресурсом) || Помилка проведення, транзакція відкочена
|-
| ФТ-Т-08 || РБ: ОСВ по рахунку з 3 субконто || Підсумки за рівнями 0–3 узгоджені між собою (згортка tb3 → tb0)
|-
| ФТ-Т-09 || РР: сценарій «Оклад + Відпустка + Лікарняний» (розд. 7.5.1) || Фактичні періоди дії відповідають еталону; «Оклад» дає 2 інтервали
|-
| ФТ-Т-10 || РР: зміна базового запису || У таблиці перерахунку з'явився запис для залежного документа
|-
| ФТ-Т-11 || Паралельне проведення 2 документів за різними складами || Обидва проходять без очікування (розділення підсумків увімкнено)
|-
| ФТ-Т-12 || Паралельне проведення 2 документів за одним складом і одним товаром з контролем залишків || Один чекає, другий проходить; від'ємного залишку немає
|-
| ФТ-Т-13 || Перерахунок підсумків після хаотичних 10<sup>6</sup> операцій || Підсумки збігаються з повним перерахунком «з нуля» до копійки
|-
| ФТ-Т-14 || Реструктуризація: додати ресурс до РН із 10 млн записів || Дані збережені, підсумки перебудовані, час ≤ НФВ-13
|-
| ФТ-Т-15 || RLS: користувач з обмеженням по організації || Віртуальні таблиці повертають лише дозволені дані
|}

== 13.2. Навантажувальні тести ==
{| class="wikitable"
! ID !! Тест !! Критерій
|-
| НТ-01 || Генерація 1 млрд рухів РН, заміри НФВ-01…НФВ-03 || Досягнення цілей
|-
| НТ-02 || Профіль «90 % рухів поточним періодом, 10 % заднім числом» — порівняння двох стратегій підсумків (розд. 10.2) || Обґрунтований вибір Рішення №3
|-
| НТ-03 || Пікове проведення 50 док/с протягом 1 год || Відсутність дедлоків; P95 ≤ НФВ-04
|-
| НТ-04 || РБ: субконто-слоти vs дочірня таблиця, 200 млн проводок || Обґрунтований вибір Рішення №2
|-
| НТ-05 || Розрахунок ЗП на 10 000 співробітників || НФВ-06
|-
| НТ-06 || Деградація за 24 год безперервної роботи || Приріст часу відгуку ≤ 15 %
|}

= 14. Етапи робіт та оцінка =

{| class="wikitable"
! Етап !! Зміст !! Результат !! Оцінка, чол.-міс. !! Залежності
|-
| '''Е0''' || Обстеження платформи, верифікація припущень П1–П6, ескізний проєкт || Затверджений архітектурний ескіз, уточнене ТЗ || 1,5 || —
|-
| '''Е1''' || Метамодель + репозиторій + генератор DDL + конструктор (базовий) || Створення регістру будь-якого типу з генерацією схеми || 3 || Е0
|-
| '''Е2''' || Регістр відомостей: рантайм, набори записів, зрізи, форми || РВ у продуктиві || 2,5 || Е1
|-
| '''Е3''' || Регістр накопичення: рухи, підсумки, ТА, віртуальні таблиці || РН у продуктиві || 5 || Е2
|-
| '''Е4''' || Механізм проведення документів, блокування, оперативне/неоперативне проведення || Транзакційне проведення || 2,5 || Е3
|-
| '''Е5''' || Розширення мови запитів (віртуальні таблиці, транслятор, push-down) || Запити до ВТ || 3,5 || Е3
|-
| '''Е6''' || Регістр бухгалтерії + план рахунків + субконто + підсумки за рівнями || РБ у продуктиві || 6 || Е4, Е5
|-
| '''Е7''' || Регістр розрахунку + ПВР + витіснення + база + графіки + перерахунки || РР у продуктиві || 6,5 || Е4, Е5
|-
| '''Е8''' || Агрегати, розділення підсумків, порадник агрегатів || Оптимізація || 2,5 || Е3
|-
| '''Е9''' || Права доступу, RLS, аудит, сервіси цілісності || Безпека та адміністрування || 2 || Е6, Е7
|-
| '''Е10''' || Реструктуризація, міграція, інструменти звірки || Інструменти міграції || 2 || Е6, Е7
|-
| '''Е11''' || Навантажувальне тестування, оптимізація, документація, '''профілювання Python + бенчмарки гарячих шляхів''' || Приймальні випробування || 4,5 || усі
|-
| colspan="3" | '''РАЗОМ''' || '''41,5''' ||
|}

{{Note|Оцінка орієнтовна (±40 %) і підлягає уточненню за результатами Е0. Критичний шлях: Е0 → Е1 → Е3 → Е5 → Е6/Е7 → Е11. За командою 6–8 інженерів — орієнтовно 9–11 календарних місяців.}}

'''Мінімальний життєздатний обсяг (MVP)''': Е0–Е5 (РВ + РН + проведення + запити) ≈ '''18 чол.-міс.''' — покриває ~70 % прикладних сценаріїв K2 ERP.

=== 14.1. Вплив вибору Python на оцінку ===

{| class="wikitable"
! Етап !! Було (мова не визначена) !! Стало (Python) !! Δ !! Причина
|-
| Е1 (метамодель, DDL, конструктор) || 4 || '''3''' || '''−1''' || SQLAlchemy Core закриває генерацію DDL і діалекти СКБД; Pydantic v2 — валідацію DSL. Разом ~30 % етапу — готове.
|-
| Е5 (мова запитів, транслятор) || 4 || '''3,5''' || '''−0,5''' || lark (граматика) + SQLAlchemy Core expression language замість власного AST→SQL.
|-
| Е7 (регістр розрахунку) || 6 || '''6,5''' || '''+0,5''' || Ізоляція витіснення за інтерфейсом (АП-3) + резерв на нативну реалізацію.
|-
| Е10 (реструктуризація, міграція) || 2,5 || '''2''' || '''−0,5''' || Alembic покриває автогенерацію <code>ALTER</code>.
|-
| Е11 (навантаження, оптимізація) || 3 || '''4,5''' || '''+1,5''' || Профілювання Python, бенчмарки бюджету АП-4, ймовірні Cython/Rust-модулі, wheels у CI.
|-
| '''РАЗОМ''' || '''41,5''' || '''41,5''' || '''0''' || Економія на інфраструктурному коді компенсує витрати на оптимізацію.
|}

'''Висновок:''' Python — '''нейтральний за трудомісткістю''' для цього проєкту. Він здешевлює те, чого тут багато (метадані, генерація схеми, абстракція діалектів, міграції), і дорожчає те, чого тут мало (гарячі CPU-цикли). Ризик зміщується з «''не встигнемо написати''» на «''не вкладемося в бюджет часу виконання''» — тому бенчмарки гарячих шляхів (АП-4) вводяться в CI '''з етапу Е3''', а не наприкінці.

= 15. Ризики =

{| class="wikitable"
! ID !! Ризик !! Ймов. !! Вплив !! Пом'якшення
|-
| Р1 || У K2 ERP немає власної мови запитів → віртуальні таблиці нікуди вбудовувати || Сер. || '''Крит.''' || Верифікувати на Е0. План «Б»: віртуальні таблиці як параметризовані view/TVF + шар ORM.
|-
| Р2 || Конкуренція за таблицю підсумків на піках проведення || Вис. || Вис. || Розділення підсумків (сплітери), НТ-03, детермінований порядок MERGE.
|-
| Р3 || Рухи «заднім числом» роблять оновлення підсумків O(N періодів) || Вис. || Сер. || Рішення №3 (dirty months + регламентний перерахунок), НТ-02.
|-
| Р4 || «Широка» схема субконто → реструктуризація при зміні ліміту || Сер. || Сер. || Зафіксувати ліміт 5 із запасом; НТ-04; план «Б» — дочірня таблиця.
|-
| Р5 || Механізм витіснення РР — найскладніший і найпомилковіший вузол || Вис. || Вис. || Виділити в окремий модуль з еталонним набором з 50+ тест-кейсів; property-based тестування.
|-
| Р6 || Обсяг Е6+Е7 недооцінено (досвід 1С: це роки розробки) || Вис. || Вис. || MVP-підхід: спершу Е0–Е5, рішення про Е6/Е7 — після ретроспективи.
|-
| Р7 || Різна поведінка PostgreSQL і MS SQL (плани, MERGE, ізоляція) || Сер. || Сер. || Єдиний набір тестів на обох СКБД у CI від Е1.
|-
| Р8 || Міграція історичних даних без реєстраторів || Вис. || Сер. || Службовий документ «ВведенняЗалишків»; етап звірки М6 з нульовим допуском.
|-
| Р9 || Патентні / ліцензійні претензії щодо копіювання механізмів || Низ. || Вис. || Юридична експертиза до Е1: реалізація ''концепцій'' обліку (загальновідомих), а не коду/API; уникати дослівного копіювання найменувань API та документації.
|-
| Р10 || '''Гарячі шляхи''' (витіснення, розрахунок ЗП) на чистому Python не вкладаються в бюджет АП-4 || Сер. || Сер. || Ізоляція за <code>Protocol</code>-інтерфейсом (АП-3) + бенчмарк у CI від Е7; готовність до Cython/Rust; альтернатива для витіснення — <code>daterange</code>+GiST у PostgreSQL.
|-
| Р11 || '''Динамічна типізація в ядрі метаданих''' → помилки типів спливають у рантаймі на продуктиві || Вис. || Сер. || <code>mypy --strict</code> як обов'язковий gate у CI; Pydantic v2 на всіх межах; генерація <code>.pyi</code>-стабів для прикладного коду (ФТ-К-07).
|-
| Р12 || '''GIL''' обмежує вертикальне масштабування сервера застосунків || Сер. || Низ. || АП-5: asyncio для IO + мультипроцесний пул. Розрахунок у 4.4.2 показує запас: 50 док/с ≈ 50 % одного ядра.
|-
| Р13 || '''Нативні розширення''' (Cython/Rust) ускладнюють збірку, кросплатформність і пошук інженерів || Низ. || Низ. || Вводяться тільки за результатами бенчмарку; wheels під усі цільові платформи в CI; питання В13.
|-
| Р14 || '''Виконання прикладного Python-коду''' в процесі сервера = виконання довільного коду з правами сервера (П8) || Вис. || '''Крит.''' || '''Питання В12 до Е0.''' Варіанти: (а) довірена модель — конфігурацію пише лише вендор/партнер; (б) ізоляція процесами + seccomp/AppArmor; (в) обмежений DSL замість повного Python. У 1С вбудована мова існує в т.ч. з цієї причини.
|}

{{Note|'''Ризик Р9 — обов'язково до опрацювання перед стартом.''' ТЗ описує ''функціональні концепції'' (накопичувальний облік, подвійний запис, витіснення періодів дії), що є загальновідомими практиками обліку. Проте пряме відтворення пропрієтарних інтерфейсів, найменувань і структур конкретного вендора потребує окремої правової оцінки. Рекомендується узгодити з юридичною службою власну термінологію та API до початку Е1.}}

= 16. Додатки =

== Додаток А. Матриця відповідності «1С ↔ K2 ERP» ==

{| class="wikitable"
! Об'єкт / поняття 1С !! Пропонований аналог K2 ERP !! Примітка
|-
| РегистрСведений || <code>Регістри.Відомостей.*</code> || Повний паритет
|-
| РегистрНакопления || <code>Регістри.Накопичення.*</code> || Повний паритет
|-
| РегистрБухгалтерии || <code>Регістри.Бухгалтерії.*</code> || Субконто зберігаються інакше (слоти)
|-
| РегистрРасчета || <code>Регістри.Розрахунку.*</code> || Повний паритет
|-
| Регистратор || <code>Реєстратор</code> || —
|-
| ВидДвижения || <code>ВидРуху</code> || —
|-
| Итоги || <code>Підсумки</code> || —
|-
| Точка актуальности итогов || <code>ТА підсумків</code> || —
|-
| Разделение итогов || <code>Розділення підсумків</code> (splitter) || —
|-
| Агрегаты || <code>Агрегати</code> || —
|-
| Субконто / ПланВидовХарактеристик || <code>Субконто</code> / <code>ПланВидівХарактеристик</code> || —
|-
| ПланВидовРасчета || <code>ПланВидівРозрахунку</code> || —
|-
| Перерасчет || <code>Перерахунок</code> || —
|-
| ПериодДействия / Вытеснение || <code>ПеріодДії</code> / <code>Витіснення</code> || —
|-
| Границя послідовності || '''Не реалізується''' || Механізм визнано застарілим; замість нього — перепроведення за списком «брудних» документів
|-
| РегистрыСведений з режимом «ПоПозицииРегистратора» || <code>ПоПозиціїРеєстратора</code> || Реалізується як (period, rec_t, rec_r, line_no) у ключі
|}

== Додаток Б. Альтернатива зберігання субконто (план «Б» до Рішення №2) ==

<syntaxhighlight lang="sql">
-- Дочірня таблиця «ключ-значення» замість слотів
CREATE TABLE rg_b_0020_ed (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
side smallint NOT NULL CHECK (side IN (0,1)), -- 0=Дт, 1=Кт
ed_no smallint NOT NULL, -- порядковий номер субконто рахунка
ed_type_r uuid NOT NULL, -- вид субконто
val_t smallint NOT NULL,
val_r uuid,
val_n numeric(38,10),
val_s varchar(150),
val_d timestamp(0),
PRIMARY KEY (rec_t, rec_r, line_no, side, ed_no),
FOREIGN KEY (rec_t, rec_r, line_no) REFERENCES rg_b_0020 (rec_t, rec_r, line_no) ON DELETE CASCADE
);
CREATE INDEX ix_rg_b_0020_ed_val ON rg_b_0020_ed (ed_type_r, val_t, val_r);
</syntaxhighlight>

{| class="wikitable"
! Критерій !! Слоти (Рішення №2) !! Дочірня таблиця (план «Б»)
|-
| Відбір за 1 субконто || Index seek по колонці || JOIN + семі-з'єднання
|-
| Відбір за 3 субконто || 3 предикати в одному скані || 3 JOIN
|-
| Зміна <code>МаксКількістьСубконто</code> || ALTER TABLE (реструктуризація) || Без змін схеми
|-
| Розмір рядка проводки || +48 байт × 2 (Дт/Кт) || Базовий
|-
| Складність генератора DDL || Вища || Нижча
|-
| '''Рекомендація''' || '''Обрано за замовчуванням''' || Резерв за результатами НТ-04
|}

== Додаток В. Перелік вимог (реєстр трасування) ==

{| class="wikitable sortable"
! ID !! Розділ !! Коротко !! Пріоритет !! Тест
|-
| ФТ-01…ФТ-07 || 7.1 || Набори записів, проведення || Must || ФТ-Т-02…04
|-
| ФТ-08…ФТ-10 || 7.2 || Активність || Must || ФТ-Т-06
|-
| ФТ-11…ФТ-13 || 7.3 || Віртуальні таблиці || Must || ФТ-Т-08, НТ-01
|-
| ФТ-14…ФТ-18 || 7.4 || Підсумки, ТА || Must || ФТ-Т-05, ФТ-Т-13
|-
| ФТ-19…ФТ-21 || 7.4.4 || Агрегати || Should || НТ-01
|-
| ФТ-22…ФТ-30 || 7.5 || Механіка РР || Must (для Е7) || ФТ-Т-09, ФТ-Т-10
|-
| ФТ-31…ФТ-36 || 7.7 || Блокування || Must || ФТ-Т-11, ФТ-Т-12, НТ-03
|-
| ФТ-37…ФТ-39 || 7.8 || Права, RLS || Must || ФТ-Т-15
|-
| ФТ-40…ФТ-42 || 7.9 || Аудит, цілісність || Should || ФТ-Т-04
|-
| ФТ-К-01…06 || 6.8.4 || Конструктор || Should || —
|-
| НФВ-01…НФВ-09 || 11.1 || Продуктивність || Must || НТ-01…НТ-06
|-
| НФВ-10…НФВ-12 || 11.3 || Цілісність || Must || ФТ-Т-13
|-
| НФВ-13…НФВ-17 || 11.4–11.5 || Супровід, сумісність || Should || ФТ-Т-14
|}

== Додаток Г. Відкриті питання ==

{| class="wikitable"
! № !! Питання !! Кому !! Термін
|-
| В1 || Чи існує в K2 ERP мова запитів / транслятор у SQL? (визначає Р1 та обсяг Е5) || Архітектор платформи || До Е0
|-
| В2 || Формат ідентифікації об'єктів: UUID чи сурогатний int? || Архітектор платформи || До Е0
|-
| В3 || Чи потрібна мілісекундна дискретність періоду? || Замовник || До Е1
|-
| В4 || Максимальна кількість субконто: 3 чи 5? || Головний бухгалтер / методолог || До Е6
|-
| В5 || Чи потрібен механізм «Границя послідовності»? (пропонується відмова) || Методолог || До Е3
|-
| В6 || Пріоритет типів регістрів: чи достатньо MVP (РВ + РН) для першого релізу? || Замовник || До Е0
|-
| В7 || Правова оцінка ризику Р9 || Юридична служба || До Е1
|-
| В8 || Цільова СКБД для першої черги: тільки PostgreSQL чи одразу обидві? || Архітектор / ІТ-експлуатація || До Е1
|-
| В9 || '''Міжпланова база розрахунку:''' чи потрібна можливість брати базу з ''іншого'' регістру розрахунку (Утримання ← ОсновніНарахування)? Якщо так — ФТ-25 і <code>md_register</code> потребують розширення полем <code>base_register_id</code> (див. Д.7.2) || Методолог ЗП / архітектор || До Е7
|-
| В10 || Чи прийнятна поведінка підпорядкованого РВ без контролю унікальності за (Період + Вимірювання)? (сумісність із 1С vs. захист від дублів — див. Д.3.2, антипатерн А-6) || Методолог || До Е2
|-
| В11 || '''Конфігуратор:''' web (FastAPI + React) чи desktop (PySide6/Qt)? Макети розділу 6.8 намальовані як desktop || Замовник / UX || До Е1
|-
| В12 || '''Ключове.''' Прикладний код — повноцінний Python чи обмежений DSL? Повний Python у процесі сервера = виконання довільного коду з правами сервера (ризик Р14) + неможливість статично перевірити конфігурацію партнера || Архітектор + служба безпеки || '''До Е0'''
|-
| В13 || Чи допустимі нативні розширення (Cython/Rust) у складі постачання? Якщо ні — потрібен план «Б» для витіснення (SQL на <code>daterange</code>) || ІТ-експлуатація || До Е7
|-
| В14 || Цільова версія: 3.12 чи 3.13? Чи розглядається free-threaded build (PEP 703) як шлях зняття Р12? || Архітектор || До Е1
|-
| В15 || Мова ідентифікаторів прикладного API: кирилиця (<code>rs.new(Номенклатура=…)</code>) чи транслітерація/англійська? Впливає на ФТ-К-07 і читабельність || Замовник / методолог || До Е2
|}

== Додаток Д. Каталог прикладів регістрів ==

Додаток містить прикладні приклади регістрів усіх типів і підвидів. Для кожного наведено: декларацію (DSL), пояснення проєктних рішень, приклад даних у фізичних таблицях і типовий запит. Приклади призначені для: (а) перевірки повноти метамоделі на етапі Е0; (б) формування набору приймальних тестів; (в) навчання прикладних розробників.

=== Д.1. Як обрати тип регістру (дерево рішень) ===

<graphviz>
digraph Choose {
rankdir=TB; bgcolor="transparent";
node [shape=box, style="rounded,filled", fontname="DejaVu Sans", fontsize=9];
edge [fontname="DejaVu Sans", fontsize=8];

q1 [label="Що зберігаємо?", shape=diamond, fillcolor="#ffe0b2"];
q2 [label="Потрібні залишки\n(скільки Є зараз)?", shape=diamond, fillcolor="#ffe0b2"];
q3 [label="Подвійний запис,\nплан рахунків,\nсубконто?", shape=diamond, fillcolor="#ffe0b2"];
q4 [label="Періоди дії,\nвитіснення,\nбаза розрахунку?", shape=diamond, fillcolor="#ffe0b2"];
q5 [label="Значення прив'язане\nдо документа?", shape=diamond, fillcolor="#ffe0b2"];

ri_i [label="РВ незалежний\n(КурсиВалют,\nШтрихкоди)", fillcolor="#e8f5e9"];
ri_s [label="РВ підпорядкований\n(ЦіниНоменклатури,\nКадровіДані)", fillcolor="#e8f5e9"];
ra_b [label="РН «Залишки»\n(ТовариНаСкладах,\nВзаєморозрахунки)", fillcolor="#fff8e1"];
ra_t [label="РН «Обороти»\n(Продажі,\nВитрати)", fillcolor="#fff8e1"];
rb [label="РБ\n(Госпрозрахунковий)", fillcolor="#fce4ec"];
rc [label="РР\n(Нарахування,\nУтримання)", fillcolor="#ede7f6"];

q1 -> q3 [label="облікові проводки"];
q3 -> rb [label="так"];
q3 -> q4 [label="ні"];
q4 -> rc [label="так"];
q4 -> q2 [label="ні"];

q1 -> q2 [label="кількісні/сумові\nрухи"];
q2 -> ra_b [label="так"];
q2 -> ra_t [label="ні,\nлише обороти\nза період"];

q1 -> q5 [label="значення\nатрибута\nв часі"];
q5 -> ri_s [label="так"];
q5 -> ri_i [label="ні"];
}
</graphviz>

'''Контрольні питання при проєктуванні будь-якого регістру:'''
# Чи можна відповісти на всі прикладні питання ''лише'' полями цього регістру, без з'єднання з документами? Якщо ні — бракує реквізиту (не вимірювання!).
# Яка ''кардинальність'' таблиці підсумків = ∏(кількість значень вимірювань) × кількість періодів? Якщо > 10<sup>8</sup> — переглянути склад вимірювань.
# Чи потрібно фільтрувати/групувати за цим полем у звітах? Так → вимірювання. Ні, лише показувати → реквізит.
# Чи підсумовується поле? Так → ресурс. Ні → реквізит або вимірювання.

=== Д.2. Зведений каталог ===

{| class="wikitable sortable"
! № !! Регістр !! Тип !! Підвид / режим !! Вимірювання !! Ресурси !! Розділ
|-
| 1 || КурсиВалют || РВ || Періодичний (день), незалежний || Валюта || Курс, Кратність || Д.3.1
|-
| 2 || ЦіниНоменклатури || РВ || Періодичний (день), підпорядкований || Номенклатура, Характеристика, ТипЦін || Ціна || Д.3.2
|-
| 3 || ШтрихкодиНоменклатури || РВ || Неперіодичний, незалежний || Штрихкод || Номенклатура, Характеристика, Упаковка || Д.3.3
|-
| 4 || ГрафікРоботи || РВ || Неперіодичний, незалежний || ВидГрафіка, ДатаГрафіка || Значення, Годин || Д.3.4
|-
| 5 || КадровіДані || РВ || По позиції реєстратора, підпорядкований || Співробітник || Підрозділ, Посада, Ставка, ВидЗайнятості || Д.3.5
|-
| 6 || НалаштуванняКористувачів || РВ || Неперіодичний, незалежний || Користувач, Налаштування || Значення (складений) || Д.3.6
|-
| 7 || ТовариНаСкладах || РН || Залишки || Номенклатура, Склад, Партія, Характеристика || Кількість, Сума || Д.4.1
|-
| 8 || ВзаєморозрахункиЗКонтрагентами || РН || Залишки || Організація, Контрагент, Договір, Замовлення || Сума, СумаВал || Д.4.2
|-
| 9 || ТовариВРезерві || РН || Залишки || Номенклатура, Склад, Замовлення, Характеристика || Кількість || Д.4.3
|-
| 10 || ГрошовіКоштиБезготівкові || РН || Залишки || Організація, БанківськийРахунок || Сума, СумаВал || Д.4.4
|-
| 11 || Продажі || РН || Обороти (місяць) + агрегати || Номенклатура, Контрагент, Договір, Менеджер, Склад || Кількість, Сума, СумаБезПДВ, Собівартість || Д.5.1
|-
| 12 || ВитратиЗаСтаттями || РН || Обороти (місяць) || Організація, Підрозділ, СтаттяВитрат, Проєкт || Сума || Д.5.2
|-
| 13 || Госпрозрахунковий || РБ || З кореспонденцією || Організація (бал.), Підрозділ (небал.) || Сума (бал.), Кількість, ВалютнаСума || Д.6.1
|-
| 14 || ПодатковийОблік || РБ || Без кореспонденції || Організація, ВидРізниці || Сума || Д.6.2
|-
| 15 || Бюджетування || РБ || З кореспонденцією || Сценарій, ЦФВ, Проєкт || Сума || Д.6.3
|-
| 16 || ОсновніНарахування || РР || Період дії + база за періодом дії || Співробітник (баз.), Підрозділ || Результат, ВідпрацьованоДнів, НормаДнів || Д.7.1
|-
| 17 || Утримання || РР || Без періоду дії, база за періодом реєстрації || Співробітник (баз.), Підрозділ || Результат, БазаОподаткування || Д.7.2
|}

=== Д.3. Регістри відомостей ===

==== Д.3.1. КурсиВалют — періодичний, незалежний ====

'''Задача:''' зберігати історію курсів валют; отримувати курс на будь-яку дату.

<syntaxhighlight lang="yaml">
register:
name: КурсиВалют
kind: Information
synonym: "Курси валют"
periodicity: WithinDay # один курс на валюту на день
writeMode: Independent # курси вводяться вручну/завантажуються з НБУ
dimensions:
- { name: Валюта, type: "Довідник.Валюти", master: true, denyEmpty: true }
resources:
- { name: Курс, type: "Число(15,4)", denyEmpty: true }
- { name: Кратність, type: "Число(10,0)", default: 1 }
</syntaxhighlight>

'''Проєктні рішення:'''
* <code>Independent</code> — курс не породжується документом, він є зовнішнім фактом.
* <code>master: true</code> для Валюти — при видаленні валюти курси видаляються; регістр видно у формі елемента довідника.
* Періодичність <code>WithinDay</code>, а не <code>WithinSecond</code> — повторний запис курсу за той самий день ''замістить'' попередній, а не створить дубль.

'''Дані у таблиці <code>rg_i_0007</code>:'''
{| class="wikitable"
! period !! d1_r (Валюта) !! r1 (Курс) !! r2 (Кратність)
|-
| 2026-07-15 00:00:00 || USD || 41.8200 || 1
|-
| 2026-07-15 00:00:00 || EUR || 45.6100 || 1
|-
| 2026-07-16 00:00:00 || USD || 41.8500 || 1
|-
| 2026-07-17 00:00:00 || USD || 41.9000 || 1
|-
| 2026-07-17 00:00:00 || EUR || 45.7300 || 1
|}

'''Запит (курс на дату документа):'''
<syntaxhighlight lang="sql">
ВИБРАТИ Курси.Курс, Курси.Кратність
З РегістрВідомостей.КурсиВалют.ЗрізОстанніх(&ДатаДокумента, Валюта = &Валюта) ЯК Курси
</syntaxhighlight>

<syntaxhighlight lang="python">
# або через менеджер
курс = Registers.information("КурсиВалют").get_last(doc.Дата, {"Валюта": doc.Валюта})
сума_грн: Decimal = doc.СумаВалюти * курс.Курс / курс.Кратність
</syntaxhighlight>

==== Д.3.2. ЦіниНоменклатури — періодичний, підпорядкований реєстратору ====

'''Задача:''' зберігати історію цін; ціна встановлюється наказом (документом), який можна скасувати.

<syntaxhighlight lang="yaml">
register:
name: ЦіниНоменклатури
kind: Information
synonym: "Ціни номенклатури"
periodicity: WithinDay
writeMode: SubordinateToRecorder # ← ключова відмінність від КурсиВалют
dimensions:
- { name: Номенклатура, type: "Довідник.Номенклатура", master: true, index: true }
- { name: Характеристика, type: "Довідник.ХарактеристикиНоменклатури", nullable: true }
- { name: ТипЦін, type: "Довідник.ТипиЦін", master: true, denyEmpty: true }
resources:
- { name: Ціна, type: "Число(15,2)", denyEmpty: true }
attributes:
- { name: Валюта, type: "Довідник.Валюти" }
- { name: Одиниця, type: "Довідник.ОдиниціВиміру" }
recorders:
- Документ.ВстановленняЦінНоменклатури
</syntaxhighlight>

'''Проєктні рішення:'''
* <code>SubordinateToRecorder</code> — потрібна юридична прив'язка ціни до наказу, можливість скасувати наказ і «відкотити» ціни одним рухом.
* <code>Валюта</code> і <code>Одиниця</code> — '''реквізити''', а не вимірювання: за ними не фільтрують і не будують зрізи, вони визначаються типом цін. ''Помилка новачка'' — зробити Валюту вимірюванням, що подвоїть кількість записів і зламає зріз останніх.
* <code>Характеристика</code> дозволяє порожнє значення — для номенклатури без характеристик.

'''Дані у таблиці <code>rg_i_0010</code>:'''
{| class="wikitable"
! rec_t !! rec_r !! line_no !! period !! active !! d1_r (Номенкл.) !! d2_r (Характ.) !! d3_r (ТипЦін) !! r1 (Ціна) !! a1_r (Валюта)
|-
| 15 || a3f…01 || 1 || 2026-07-01 || true || Кава Lavazza 1кг || ''(порожня)'' || Роздрібна || 480.00 || UAH
|-
| 15 || a3f…01 || 2 || 2026-07-01 || true || Кава Lavazza 1кг || ''(порожня)'' || Оптова || 410.00 || UAH
|-
| 15 || a3f…01 || 3 || 2026-07-01 || true || Чай Ahmad 100г || ''(порожня)'' || Роздрібна || 95.00 || UAH
|-
| 15 || b7c…04 || 1 || 2026-07-15 || true || Кава Lavazza 1кг || ''(порожня)'' || Роздрібна || 495.00 || UAH
|}

{{Note|Зверніть увагу: у підпорядкованому РВ '''немає''' унікальності за (Період + Вимірювання). Два різні документи можуть встановити ціну на ту саму дату — платформа це дозволить, зріз останніх поверне запис із більшим <code>line_no</code> у межах реєстратора з пізнішою позицією. Це '''свідома''' поведінка (сумісність із 1С), але прикладний розробник має контролювати дублі самостійно — див. антипатерн А-6 (Д.10).}}

==== Д.3.3. ШтрихкодиНоменклатури — неперіодичний, незалежний ====

'''Задача:''' за штрихкодом знайти номенклатуру. Класичний приклад «вимірювання = те, ''за чим'' шукаємо; ресурс = те, що ''знаходимо''».

<syntaxhighlight lang="yaml">
register:
name: ШтрихкодиНоменклатури
kind: Information
periodicity: Nonperiodical
writeMode: Independent
dimensions:
- { name: Штрихкод, type: "Рядок(30)", denyEmpty: true } # ← ключ пошуку
resources:
- { name: Номенклатура, type: "Довідник.Номенклатура", denyEmpty: true }
- { name: Характеристика, type: "Довідник.ХарактеристикиНоменклатури", nullable: true }
- { name: Упаковка, type: "Довідник.УпаковкиНоменклатури", nullable: true }
</syntaxhighlight>

<syntaxhighlight lang="sql">
CREATE TABLE rg_i_0011 (
d1_s varchar(30) NOT NULL, -- Штрихкод
r1_r uuid NOT NULL, -- Номенклатура
r2_r uuid NOT NULL, -- Характеристика
r3_r uuid NOT NULL, -- Упаковка
CONSTRAINT pk_rg_i_0011 PRIMARY KEY (d1_s) -- ← унікальність штрихкоду «безкоштовно»
);
CREATE INDEX ix_rg_i_0011_r1 ON rg_i_0011 (r1_r); -- зворотний пошук: штрихкоди товару
</syntaxhighlight>

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

==== Д.3.4. ГрафікРоботи — неперіодичний, незалежний (використовується як графік для РР) ====

<syntaxhighlight lang="yaml">
register:
name: ГрафікРоботи
kind: Information
periodicity: Nonperiodical
writeMode: Independent
dimensions:
- { name: ВидГрафіка, type: "Довідник.ГрафікиРоботи", master: true, denyEmpty: true }
- { name: ДатаГрафіка, type: "Дата", denyEmpty: true } # ← вимірювання типу Дата, не Період!
resources:
- { name: Значення, type: "Число(1,0)" } # 1 = робочий день, 0 = вихідний
- { name: Годин, type: "Число(4,2)" } # тривалість зміни
</syntaxhighlight>

'''Проєктне рішення (важливе):''' <code>ДатаГрафіка</code> — це '''вимірювання''' типу <code>Дата</code>, а не стандартний реквізит <code>Період</code>. Регістр '''неперіодичний'''. Причина: графік описує ''календар'' (кожна дата — окремий факт), а не ''історію зміни значення''. Якби використали періодичність, зріз останніх повертав би «останній робочий день», що безглуздо. Механізм РР (<code>ДаніГрафіка</code>) очікує саме таку структуру.

'''Дані у таблиці <code>rg_i_0015</code>:'''
{| class="wikitable"
! d1_r (ВидГрафіка) !! d2_d (ДатаГрафіка) !! r1 (Значення) !! r2 (Годин)
|-
| П'ятиденка || 2026-07-01 || 1 || 8.00
|-
| П'ятиденка || 2026-07-04 || 0 || 0.00
|-
| П'ятиденка || 2026-07-05 || 0 || 0.00
|-
| П'ятиденка || 2026-07-06 || 1 || 8.00
|-
| Змінний 2/2 || 2026-07-01 || 1 || 12.00
|-
| Змінний 2/2 || 2026-07-03 || 0 || 0.00
|}

==== Д.3.5. КадровіДані — по позиції реєстратора ====

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

<syntaxhighlight lang="yaml">
register:
name: КадровіДані
kind: Information
periodicity: ByRecorderPosition # ← упорядкування за позицією документа, не лише за датою
writeMode: SubordinateToRecorder
dimensions:
- { name: Співробітник, type: "Довідник.Співробітники", master: true, denyEmpty: true }
resources:
- { name: Підрозділ, type: "Довідник.Підрозділи" }
- { name: Посада, type: "Довідник.Посади" }
- { name: Ставка, type: "Число(5,2)" }
- { name: ВидЗайнятості, type: "Перерахування.ВидиЗайнятості" }
- { name: ГрафікРоботи, type: "Довідник.ГрафікиРоботи" }
recorders:
- Документ.ПрийомНаРоботу
- Документ.КадровеПереміщення
- Документ.Звільнення
</syntaxhighlight>

'''Проєктне рішення:''' <code>ByRecorderPosition</code> — коли два накази оформлені однією датою (переміщення + зміна ставки), звичайна періодичність «у межах дня» дала б недетермінований результат зрізу. Позиція реєстратора додає до ключа <code>(rec_t, rec_r, line_no)</code> і впорядковує за моментом часу документа.

'''Фізична схема:'''
<syntaxhighlight lang="sql">
CREATE TABLE rg_i_0016 (
period timestamp(0) NOT NULL,
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
active boolean NOT NULL DEFAULT true,
d1_r uuid NOT NULL, -- Співробітник
r1_r uuid NOT NULL, r2_r uuid NOT NULL,
r3 numeric(5,2) NOT NULL,
r4 smallint NOT NULL, -- Перерахування зберігається як порядковий номер
r5_r uuid NOT NULL,
CONSTRAINT pk_rg_i_0016 PRIMARY KEY (period, rec_t, rec_r, line_no) -- ← Період у ключі ПЕРШИЙ
);
CREATE INDEX ix_rg_i_0016_d1 ON rg_i_0016 (d1_r, period DESC, rec_t, rec_r, line_no DESC)
WHERE active;
</syntaxhighlight>

==== Д.3.6. НалаштуванняКористувачів — складений тип ресурсу ====

<syntaxhighlight lang="yaml">
register:
name: НалаштуванняКористувачів
kind: Information
periodicity: Nonperiodical
writeMode: Independent
dimensions:
- { name: Користувач, type: "Довідник.Користувачі", master: true }
- { name: Налаштування, type: "ПланВидівХарактеристик.НалаштуванняКористувачів", master: true }
resources:
- name: Значення
type: ["Рядок(500)", "Число(15,2)", "Дата", "Булево",
"Довідник.Організації", "Довідник.Склади"] # ← складений тип
</syntaxhighlight>

<syntaxhighlight lang="sql">
CREATE TABLE rg_i_0018 (
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
r1_t smallint NOT NULL, -- код типу значення
r1_b boolean,
r1_n numeric(15,2),
r1_s varchar(500),
r1_d timestamp(0),
r1_r uuid,
CONSTRAINT pk_rg_i_0018 PRIMARY KEY (d1_r, d2_r)
);
</syntaxhighlight>

{| class="wikitable"
! d1_r !! d2_r !! r1_t !! r1_b !! r1_n !! r1_s !! r1_d !! r1_r
|-
| Іваненко || ОсновнаОрганізація || 101 || || || || || ТОВ «Альфа»
|-
| Іваненко || ОсновнийСклад || 104 || || || || || Центральний
|-
| Іваненко || ПоказуватиПідказки || 2 || true || || || ||
|-
| Петренко || КількістьРядківСписку || 3 || || 50 || || ||
|}

=== Д.4. Регістри накопичення, вид «Залишки» ===

==== Д.4.1. ТовариНаСкладах ====

Декларація — розділ 6.7, фізична схема — розділ 8.5, ER — розділ 9.2. Тут — дані.

'''Рухи (<code>rg_a_0012</code>) після проведення трьох документів:'''
{| class="wikitable"
! rec_t !! rec_r !! line_no !! period !! mvt !! d1_r (Номенкл.) !! d2_r (Склад) !! r1 (К-сть) !! r2 (Сума)
|-
| 2 (ПрихНакл) || p1 || 1 || 2026-06-10 || 0 ''Прихід'' || Кава Lavazza || Центральний || 100.000 || 35 000.00
|-
| 2 (ПрихНакл) || p1 || 2 || 2026-06-10 || 0 ''Прихід'' || Чай Ahmad || Центральний || 200.000 || 12 000.00
|-
| 3 (ВидНакл) || v1 || 1 || 2026-07-05 || 1 ''Витрата'' || Кава Lavazza || Центральний || 30.000 || 10 500.00
|-
| 4 (Переміщ) || m1 || 1 || 2026-07-12 || 1 ''Витрата'' || Кава Lavazza || Центральний || 20.000 || 7 000.00
|-
| 4 (Переміщ) || m1 || 2 || 2026-07-12 || 0 ''Прихід'' || Кава Lavazza || Роздрібний || 20.000 || 7 000.00
|}

'''Підсумки залишків (<code>rg_a_0012_tb</code>), ТА = 2026-07-31:'''
{| class="wikitable"
! period !! d1_r !! d2_r !! r1 (К-сть ±) !! r2 (Сума ±) !! Коментар
|-
| 2026-07-01 || Кава Lavazza || Центральний || 100.000 || 35 000.00 || залишок ''на початок'' липня
|-
| 2026-07-01 || Чай Ahmad || Центральний || 200.000 || 12 000.00 ||
|-
| 2026-08-01 || Кава Lavazza || Центральний || 50.000 || 17 500.00 || 100 − 30 − 20
|-
| 2026-08-01 || Кава Lavazza || Роздрібний || 20.000 || 7 000.00 ||
|-
| 2026-08-01 || Чай Ahmad || Центральний || 200.000 || 12 000.00 ||
|-
| '''5999-11-01''' || Кава Lavazza || Центральний || 50.000 || 17 500.00 || '''MAXPERIOD''' — поточний залишок
|-
| '''5999-11-01''' || Кава Lavazza || Роздрібний || 20.000 || 7 000.00 || '''MAXPERIOD'''
|-
| '''5999-11-01''' || Чай Ahmad || Центральний || 200.000 || 12 000.00 || '''MAXPERIOD'''
|}

''(Вимірювання Партія і Характеристика для стислості опущені.)''

==== Д.4.2. ВзаєморозрахункиЗКонтрагентами ====

'''Задача:''' облік дебіторської/кредиторської заборгованості в розрізі договорів і замовлень.

<syntaxhighlight lang="yaml">
register:
name: ВзаєморозрахункиЗКонтрагентами
kind: Accumulation
accumulationKind: Balance
periodicity: WithinSecond
enableBalanceTotals: true
enableTurnoverTotals: true
partitioning: { mode: RangeByPeriod, step: month }
dimensions:
- { name: Організація, type: "Довідник.Організації", denyEmpty: true, index: true }
- { name: Контрагент, type: "Довідник.Контрагенти", master: true, index: true }
- { name: Договір, type: "Довідник.ДоговориКонтрагентів", master: true, index: true }
- { name: Замовлення, type: ["Документ.ЗамовленняПокупця", "Документ.ЗамовленняПостачальнику"],
nullable: true }
resources:
- { name: Сума, type: "Число(15,2)" } # у валюті регламентованого обліку
- { name: СумаВал, type: "Число(15,2)" } # у валюті договору
attributes:
- { name: Коментар, type: "Рядок(200)" }
recorders:
- Документ.ВидатковаНакладна
- Документ.ПрихіднаНакладна
- Документ.ПлатіжнеДоручення
- Документ.КасовийОрдер
- Документ.КоригуванняБоргу
</syntaxhighlight>

'''Угода про знак (обов'язково фіксується в методології!):'''
{| class="wikitable"
! Вид руху !! Сенс !! Приклад документа
|-
| '''Прихід''' || Борг контрагента перед нами '''зростає''' (дебіторка +) || Видаткова накладна
|-
| '''Витрата''' || Борг контрагента перед нами '''зменшується''' (оплата) || Платіжне доручення вхідне
|}
Кредиторська заборгованість = від'ємний залишок. ''Альтернатива'' — два окремих ресурси (СумаДт/СумаКт) або два регістри; обраний варіант — один знаковий ресурс (простіше, менший обсяг підсумків).

'''Приклад даних:'''
{| class="wikitable"
! Документ !! period !! mvt !! Контрагент !! Договір !! r1 (Сума) !! Залишок після
|-
| ВидатковаНакладна №12 || 2026-07-05 || Прихід || ТОВ «Бета» || Основний || 12 000.00 || +12 000 ''(винні нам)''
|-
| ПлатіжнеДоручення №88 || 2026-07-09 || Витрата || ТОВ «Бета» || Основний || 8 000.00 || +4 000
|-
| ПлатіжнеДоручення №91 || 2026-07-16 || Витрата || ТОВ «Бета» || Основний || 6 000.00 || −2 000 ''(передоплата)''
|}

'''Запит (акт звірки):'''
<syntaxhighlight lang="sql">
ВИБРАТИ
Дані.Контрагент, Дані.Договір,
Дані.СумаПочатковийЗалишок, Дані.СумаПрихід,
Дані.СумаВитрата, Дані.СумаКінцевийЗалишок
З РегістрНакопичення.ВзаєморозрахункиЗКонтрагентами.ЗалишкиІОбороти(
&Початок, &Кінець, Авто, Рух,
Організація = &Організація І Контрагент = &Контрагент
) ЯК Дані
</syntaxhighlight>

==== Д.4.3. ТовариВРезерві — регістр «супутник» ====

<syntaxhighlight lang="yaml">
register:
name: ТовариВРезерві
kind: Accumulation
accumulationKind: Balance
periodicity: WithinSecond
dimensions:
- { name: Номенклатура, type: "Довідник.Номенклатура", master: true, index: true }
- { name: Характеристика, type: "Довідник.ХарактеристикиНоменклатури", nullable: true }
- { name: Склад, type: "Довідник.Склади", master: true, index: true }
- { name: Замовлення, type: "Документ.ЗамовленняПокупця", master: true, denyEmpty: true }
resources:
- { name: Кількість, type: "Число(15,3)" }
recorders:
- Документ.ЗамовленняПокупця
- Документ.ВидатковаНакладна
- Документ.ЗакриттяЗамовлень
</syntaxhighlight>

'''Патерн «доступний залишок»''' — з'єднання двох регістрів:
<syntaxhighlight lang="sql">
ВИБРАТИ
ЄСТЬNULL(Зал.Номенклатура, Рез.Номенклатура) ЯК Номенклатура,
ЄСТЬNULL(Зал.Склад, Рез.Склад) ЯК Склад,
ЄСТЬNULL(Зал.КількістьЗалишок, 0) ЯК ВСкладі,
ЄСТЬNULL(Рез.КількістьЗалишок, 0) ЯК ВРезерві,
ЄСТЬNULL(Зал.КількістьЗалишок, 0) - ЄСТЬNULL(Рез.КількістьЗалишок, 0) ЯК Доступно
З РегістрНакопичення.ТовариНаСкладах.Залишки(&Період, Склад = &Склад) ЯК Зал
ПОВНЕ З'ЄДНАННЯ РегістрНакопичення.ТовариВРезерві.Залишки(&Період, Склад = &Склад) ЯК Рез
ЗА Зал.Номенклатура = Рез.Номенклатура І Зал.Склад = Рез.Склад
</syntaxhighlight>

{{Note|Чому окремий регістр, а не ресурс «Резерв» у <code>ТовариНаСкладах</code>? Тому що резерв ведеться в розрізі '''Замовлення''', а залишок — у розрізі '''Партії'''. Додавання Замовлення як вимірювання до <code>ТовариНаСкладах</code> помножило б таблицю підсумків на кардинальність замовлень (сотні тисяч рядків на товар). Це ілюстрація контрольного питання №2 з Д.1.}}

==== Д.4.4. ГрошовіКоштиБезготівкові ====

<syntaxhighlight lang="yaml">
register:
name: ГрошовіКоштиБезготівкові
kind: Accumulation
accumulationKind: Balance
periodicity: WithinDay # достатньо дня: банківська виписка — денна
dimensions:
- { name: Організація, type: "Довідник.Організації", denyEmpty: true }
- { name: БанківськийРахунок, type: "Довідник.БанківськіРахунки", master: true, denyEmpty: true }
resources:
- { name: Сума, type: "Число(15,2)" }
- { name: СумаВал, type: "Число(15,2)" }
recorders: [Документ.ПлатіжнеДоручення, Документ.БанківськаВиписка, Документ.ПереміщенняКоштів]
</syntaxhighlight>

'''Проєктне рішення:''' Валюта — '''не''' вимірювання, тому що вона однозначно визначається банківським рахунком (функціональна залежність). Її додавання як вимірювання створило б надлишковість і ризик неузгоджених даних. Валюта отримується з'єднанням із довідником.

=== Д.5. Регістри накопичення, вид «Обороти» ===

==== Д.5.1. Продажі — з агрегатами ====

<syntaxhighlight lang="yaml">
register:
name: Продажі
kind: Accumulation
accumulationKind: Turnover # ← залишків не буває: «залишок продажів» безглуздий
periodicity: WithinSecond
turnoverTotalsPeriod: Month
aggregatesMode: Aggregates
partitioning: { mode: RangeByPeriod, step: month }
dimensions:
- { name: Номенклатура, type: "Довідник.Номенклатура", index: true }
- { name: Характеристика, type: "Довідник.ХарактеристикиНоменклатури", nullable: true }
- { name: Контрагент, type: "Довідник.Контрагенти", index: true }
- { name: Договір, type: "Довідник.ДоговориКонтрагентів" }
- { name: Менеджер, type: "Довідник.Користувачі", index: true }
- { name: Склад, type: "Довідник.Склади" }
resources:
- { name: Кількість, type: "Число(15,3)" }
- { name: Сума, type: "Число(15,2)" }
- { name: СумаБезПДВ, type: "Число(15,2)" }
- { name: Собівартість, type: "Число(15,2)" }
recorders: [Документ.ВидатковаНакладна, Документ.ПовернненняВідПокупця, Документ.ЗвітПроРоздрібніПродажі]

aggregates:
- name: ПродажіПоМісяцяхІТоварах
periodicity: Month
dimensions: [Номенклатура, Склад]
realtime: true
- name: ПродажіПоМенеджерах
periodicity: Day
dimensions: [Менеджер]
realtime: false # оновлюється регламентно
- name: ПродажіПоКонтрагентах
periodicity: Quarter
dimensions: [Контрагент, Договір]
realtime: false
</syntaxhighlight>

'''Проєктні рішення:'''
* <code>Turnover</code>, а не <code>Balance</code>: немає <code>ВидРуху</code>, немає таблиці залишків → удвічі менше підсумків і немає кумулятивних оновлень. Повернення відображається '''від'ємною''' сумою, а не «витратою».
* 6 вимірювань → таблиця підсумків надто широка для швидких звітів → компенсуємо агрегатами.

'''Ефект агрегатів:'''
{| class="wikitable"
! Звіт !! Без агрегатів (<code>rg_a_0031_tt</code>) !! З агрегатом !! Виграш
|-
| Продажі по товарах за рік || скан 8 млн рядків підсумків || <code>ag1</code>: 40 тис. рядків || ×200
|-
| Рейтинг менеджерів за квартал || скан 8 млн рядків || <code>ag2</code>: 1,8 тис. рядків || ×4000
|-
| Продажі по контрагенту за 3 роки || скан 8 млн рядків || <code>ag3</code>: 60 тис. рядків || ×130
|-
| Продажі по товару + контрагенту || '''агрегат не покриває''' → підсумки || — || —
|}

<syntaxhighlight lang="sql">
CREATE TABLE rg_a_0031_ag1 ( -- Місяць × (Номенклатура, Склад)
period timestamp(0) NOT NULL, d1_r uuid NOT NULL, d6_r uuid NOT NULL,
r1 numeric(20,3) NOT NULL, r2 numeric(20,2) NOT NULL,
r3 numeric(20,2) NOT NULL, r4 numeric(20,2) NOT NULL,
CONSTRAINT pk_rg_a_0031_ag1 PRIMARY KEY (period, d1_r, d6_r)
);
CREATE TABLE rg_a_0031_ag2 ( -- День × (Менеджер)
period timestamp(0) NOT NULL, d5_r uuid NOT NULL,
r1 numeric(20,3) NOT NULL, r2 numeric(20,2) NOT NULL,
r3 numeric(20,2) NOT NULL, r4 numeric(20,2) NOT NULL,
CONSTRAINT pk_rg_a_0031_ag2 PRIMARY KEY (period, d5_r)
);
</syntaxhighlight>

==== Д.5.2. ВитратиЗаСтаттями ====

<syntaxhighlight lang="yaml">
register:
name: ВитратиЗаСтаттями
kind: Accumulation
accumulationKind: Turnover
periodicity: WithinDay
turnoverTotalsPeriod: Month
dimensions:
- { name: Організація, type: "Довідник.Організації", denyEmpty: true }
- { name: Підрозділ, type: "Довідник.Підрозділи", index: true }
- { name: СтаттяВитрат, type: "Довідник.СтаттіВитрат", master: true, denyEmpty: true, index: true }
- { name: Проєкт, type: "Довідник.Проєкти", nullable: true }
resources:
- { name: Сума, type: "Число(15,2)" }
recorders: [Документ.АвансовийЗвіт, Документ.НадходженняПослуг, Документ.НарахуванняЗарплати, Документ.Амортизація]
</syntaxhighlight>

'''Приклад даних (<code>rg_a_0032_tt</code>, підсумки оборотів за місяць):'''
{| class="wikitable"
! period !! Підрозділ !! СтаттяВитрат !! Проєкт !! r1 (Сума)
|-
| 2026-07-01 || Відділ продажів || Оренда || ''(порожній)'' || 45 000.00
|-
| 2026-07-01 || Відділ продажів || ЗП і нарахування || ''(порожній)'' || 320 000.00
|-
| 2026-07-01 || Відділ продажів || Реклама || Запуск «Альфа» || 78 000.00
|-
| 2026-07-01 || ІТ-відділ || ЗП і нарахування || ''(порожній)'' || 410 000.00
|-
| 2026-07-01 || ІТ-відділ || Ліцензії ПЗ || ''(порожній)'' || 62 000.00
|}

=== Д.6. Регістри бухгалтерії ===

==== Д.6.1. Госпрозрахунковий — з кореспонденцією ====

Декларація — розділ 6.7, схема — 8.6, ER — 9.3. Тут — приклад проводок.

'''Господарська операція:''' реалізація товару на 12 000 грн (у т.ч. ПДВ 2 000), собівартість 7 000 грн.

'''Проводки (<code>rg_b_0020</code>, реєстратор = ВидатковаНакладна №12):'''
{| class="wikitable"
! line !! acc_dt !! ed_dt1 !! ed_dt2 !! acc_kt !! ed_kt1 !! ed_kt2 !! r1 (Сума) !! r2_dt !! r2_kt
|-
| 1 || 361 ''Розрах. з покупцями'' || ТОВ «Бета» || Договір №5 || 702 ''Дохід від реалізації'' || Кава Lavazza || ''—'' || 12 000.00 || || 30.000
|-
| 2 || 702 ''Дохід від реалізації'' || Кава Lavazza || ''—'' || 641 ''Розрах. за податками'' || ПДВ || ''—'' || 2 000.00 || ||
|-
| 3 || 902 ''Собівартість реалізації'' || Кава Lavazza || ''—'' || 281 ''Товари на складі'' || Кава Lavazza || Центральний || 7 000.00 || 30.000 || 30.000
|}

'''Контроль:''' Σ(Сума) по Дт = Σ(Сума) по Кт у межах реєстратора → 12 000 + 2 000 + 7 000 = 21 000 з обох боків. ✔

'''Підсумки, рівень 0 (<code>rg_b_0020_tb0</code>), на 5999-11-01:'''
{| class="wikitable"
! acc_r !! d1_r (Організація) !! r1 (Сума ±) !! Інтерпретація
|-
| 281 || ТОВ «Альфа» || +28 000.00 || дебетовий залишок (товари є)
|-
| 361 || ТОВ «Альфа» || +12 000.00 || дебетовий (дебіторка)
|-
| 641 || ТОВ «Альфа» || −2 000.00 || кредитовий (винні бюджету)
|-
| 702 || ТОВ «Альфа» || −10 000.00 || кредитовий (дохід)
|-
| 902 || ТОВ «Альфа» || +7 000.00 || дебетовий (собівартість)
|}

'''Підсумки, рівень 2 (<code>rg_b_0020_tb2</code>) — для рахунку 281 (2 субконто: Номенклатура, Склад):'''
{| class="wikitable"
! acc_r !! ed1_r (Номенклатура) !! ed2_r (Склад) !! r1 (Сума) !! r2 (Кількість)
|-
| 281 || Кава Lavazza || Центральний || 17 500.00 || 50.000
|-
| 281 || Кава Lavazza || Роздрібний || 7 000.00 || 20.000
|-
| 281 || Чай Ahmad || Центральний || 12 000.00 || 200.000
|}
Згортка <code>tb2</code> → <code>tb0</code>: 17 500 + 7 000 + 12 000 = '''36 500'''… ''(різниця з таблицею вище — інші операції; у тесті ФТ-Т-08 перевіряється точна рівність)''.

'''Запит (ОСВ по рахунку):'''
<syntaxhighlight lang="sql">
ВИБРАТИ
Дані.Субконто1 ЯК Номенклатура, Дані.Субконто2 ЯК Склад,
Дані.СумаПочатковийЗалишокДт, Дані.КількістьПочатковийЗалишокДт,
Дані.СумаОборотДт, Дані.СумаОборотКт,
Дані.СумаКінцевийЗалишокДт, Дані.КількістьКінцевийЗалишокДт
З РегістрБухгалтерії.Госпрозрахунковий.ЗалишкиІОбороти(
&Початок, &Кінець, Місяць,
Рахунок = &Рахунок281,
, Організація = &Організація,
,
) ЯК Дані
</syntaxhighlight>

==== Д.6.2. ПодатковийОблік — без кореспонденції ====

'''Задача:''' податковий облік із розділенням на постійні/тимчасові різниці, де подвійний запис не потрібен (кожен факт реєструється окремо по Дт або по Кт).

<syntaxhighlight lang="yaml">
register:
name: ПодатковийОблік
kind: Accounting
chartOfAccounts: ПланРахунків.Податковий
correspondence: false # ← уніграфічний облік
periodicity: WithinSecond
dimensions:
- { name: Організація, type: "Довідник.Організації", balance: true, denyEmpty: true }
- { name: ВидРізниці, type: "Перерахування.ВидиРізниць", balance: true } # БУ|ПУ|ПР|ТР
resources:
- { name: Сума, type: "Число(15,2)", balance: true }
attributes:
- { name: Зміст, type: "Рядок(255)" }
recorders: [Документ.БухгалтерськаОперація, Документ.ВидатковаНакладна, Документ.НадходженняПослуг]
</syntaxhighlight>

'''Проводки (<code>rg_b_0021</code>):'''
{| class="wikitable"
! line !! acc_mvt !! acc_r !! ed1 (Номенкл.) !! d1 (Організація) !! d2 (ВидРізниці) !! r1 (Сума)
|-
| 1 || 0 ''Дебет'' || 902.НУ || Кава Lavazza || ТОВ «Альфа» || ПУ ''податковий'' || 7 000.00
|-
| 2 || 1 ''Кредит'' || 281.НУ || Кава Lavazza || ТОВ «Альфа» || ПУ || 7 000.00
|-
| 3 || 0 ''Дебет'' || 902.НУ || Кава Lavazza || ТОВ «Альфа» || ПР ''постійна різниця'' || 350.00
|-
| 4 || 1 ''Кредит'' || 281.НУ || Кава Lavazza || ТОВ «Альфа» || ПР || 350.00
|}

'''Відмінності від Д.6.1:'''
{| class="wikitable"
! !! З кореспонденцією !! Без кореспонденції
|-
| Один факт = || 1 запис (Дт+Кт) || 2 записи (окремо Дт, окремо Кт)
|-
| Поля рахунків || <code>acc_dt_r</code>, <code>acc_kt_r</code> || <code>acc_r</code> + <code>acc_mvt</code>
|-
| Субконто || 2 набори (Дт, Кт) || 1 набір
|-
| Кількість записів || N || 2N
|-
| Таблиця <code>_tc</code> (кореспонденції) || Є || '''Немає''' — «шахова відомість» неможлива
|-
| Контроль Дт=Кт || У межах реєстратора || Опційно (може бути незбалансовано за задумом)
|-
| Коли обирати || Класичний облік, потрібен аналіз кореспонденцій || Облік без потреби в кореспонденціях, забалансовий, статистичний
|}

==== Д.6.3. Бюджетування ====

<syntaxhighlight lang="yaml">
register:
name: Бюджетування
kind: Accounting
chartOfAccounts: ПланРахунків.Бюджетування
correspondence: true
periodicity: WithinMonth # бюджет — помісячний, до секунди не потрібно
dimensions:
- { name: Сценарій, type: "Довідник.СценаріїБюджетування", balance: true, denyEmpty: true }
- { name: ЦФВ, type: "Довідник.ЦентриФінансовоїВідповідальності", balance: true }
- { name: Проєкт, type: "Довідник.Проєкти", balance: true, nullable: true }
resources:
- { name: Сума, type: "Число(15,2)", balance: true }
recorders: [Документ.БюджетнаОперація, Документ.ВведенняБюджету]
</syntaxhighlight>

'''Проєктне рішення:''' <code>Сценарій</code> — вимірювання, а не окремий регістр на кожен сценарій (План/Факт/Прогноз). Це дозволяє план-фактний аналіз одним запитом. Усі три вимірювання '''балансові''' — бюджетна проводка не змінює сценарій/ЦФВ між дебетом і кредитом.

=== Д.7. Регістри розрахунку ===

==== Д.7.1. ОсновніНарахування — період дії + витіснення ====

'''План видів розрахунку <code>ОсновніНарахування</code>:'''
{| class="wikitable"
! Вид розрахунку !! Період дії !! Витісняючі !! Базові !! Залежність від бази
|-
| Оклад || Так || Відпустка, Лікарняний || — || Не залежить
|-
| Відпустка || Так || Лікарняний || Оклад, Премія || За періодом дії
|-
| Лікарняний || Так || — || Оклад || За періодом дії
|-
| Премія || Ні || — || Оклад || За періодом реєстрації
|}

Декларація регістру — розділ 6.7.

'''Записи (<code>rg_c_0040</code>), період реєстрації = липень 2026:'''
{| class="wikitable"
! line !! calc_type !! period !! act_begin !! act_end !! base_begin !! base_end !! d1 (Співробітник) !! r1 (Результат)
|-
| 1 || Оклад || 2026-07-01 || 2026-07-01 || 2026-07-31 || || || Іваненко || 18 000.00
|-
| 2 || Відпустка || 2026-07-01 || 2026-07-10 || 2026-07-17 || 2026-01-01 || 2026-06-30 || Іваненко || 6 420.00
|-
| 3 || Лікарняний || 2026-07-01 || 2026-07-14 || 2026-07-22 || 2026-01-01 || 2026-06-30 || Іваненко || 5 180.00
|-
| 4 || Оклад || 2026-07-01 || 2026-07-01 || 2026-07-31 || || || Петренко || 22 000.00
|}

'''Фактичні періоди дії (<code>rg_c_0040_ap</code>) — результат витіснення:'''
{| class="wikitable"
! rec/line !! interval_no !! calc_type !! d1 !! fact_begin !! fact_end !! Коментар
|-
| n1 / 1 || 0 || Оклад || Іваненко || 2026-07-01 || 2026-07-09 || до відпустки
|-
| n1 / 1 || 1 || Оклад || Іваненко || 2026-07-23 || 2026-07-31 || після лікарняного
|-
| n1 / 2 || 0 || Відпустка || Іваненко || 2026-07-10 || 2026-07-13 || витіснена лікарняним з 14-го
|-
| n1 / 3 || 0 || Лікарняний || Іваненко || 2026-07-14 || 2026-07-22 || не витісняється нічим
|-
| n1 / 4 || 0 || Оклад || Петренко || 2026-07-01 || 2026-07-31 || витіснення відсутнє
|}

'''Один запис «Оклад» Іваненка → два інтервали''' — ілюстрація зв'язку 1:N у розділі 9.4.

'''Запит (дані графіка для розрахунку окладу):'''
<syntaxhighlight lang="sql">
ВИБРАТИ
Дані.Співробітник, Дані.НомерРядка,
Дані.ЗначенняФактичногоПеріодуДії ЯК ВідпрацьованоДнів,
Дані.ЗначенняПеріодуДії ЯК НормаДнів
З РегістрРозрахунку.ОсновніНарахування.ДаніГрафіка(
ВидРозрахунку = ЗНАЧЕННЯ(ПланВидівРозрахунку.ОсновніНарахування.Оклад)
І Реєстратор = &Реєстратор
) ЯК Дані
</syntaxhighlight>
'''Результат:''' Іваненко — <code>ВідпрацьованоДнів = 13</code> (робочі дні у 01–09 та 23–31), <code>НормаДнів = 23</code> → Оклад = 18 000 × 13 / 23 = '''10 173,91'''.

'''Запит (база для відпустки):'''
<syntaxhighlight lang="sql">
ВИБРАТИ База.Співробітник, База.НомерРядка, База.РезультатБаза ЯК Заробіток
З РегістрРозрахунку.ОсновніНарахування.БазаРозрахунку(
, /* вимірювання бази */
, /* вимірювання основного регістру */
Співробітник, /* розрізи */
ВидРозрахунку = ЗНАЧЕННЯ(ПланВидівРозрахунку.ОсновніНарахування.Відпустка)
) ЯК База
</syntaxhighlight>

==== Д.7.2. Утримання — без періоду дії, база за періодом реєстрації ====

'''План видів розрахунку <code>Утримання</code>:'''
{| class="wikitable"
! Вид розрахунку !! Період дії !! Базові види розрахунку !! Залежність
|-
| ПДФО || Ні || ''(усі з ПВР ОсновніНарахування)'' || За періодом реєстрації
|-
| Військовий збір || Ні || ''(усі з ПВР ОсновніНарахування)'' || За періодом реєстрації
|-
| Аліменти || Ні || Оклад, Премія, Відпустка || За періодом реєстрації
|-
| Профспілковий внесок || Ні || Оклад || За періодом реєстрації
|}

<syntaxhighlight lang="yaml">
register:
name: Утримання
kind: Calculation
calculationTypesPlan: ПланВидівРозрахунку.Утримання
periodicity: Month
actionPeriod: false # ← утримання не має періоду дії
basePeriod: ByRegistrationPeriod # ← база береться за періодом реєстрації
# schedule: не задається — графік не потрібен
dimensions:
- { name: Співробітник, type: "Довідник.Співробітники", baseDimension: true, master: true, denyEmpty: true }
- { name: Підрозділ, type: "Довідник.Підрозділи" }
resources:
- { name: Результат, type: "Число(15,2)" }
- { name: БазаОподаткування, type: "Число(15,2)" }
recalculations:
- name: ПерерахунокУтримань
dimensions:
- { name: Співробітник, registerDimension: Співробітник }
recorders: [Документ.НарахуванняЗарплати]
</syntaxhighlight>

'''Фізична схема (спрощена — немає полів періоду дії):'''
<syntaxhighlight lang="sql">
CREATE TABLE rg_c_0041 (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
period timestamp(0) NOT NULL, -- період реєстрації
active boolean NOT NULL DEFAULT true,
reversal boolean NOT NULL DEFAULT false,
calc_type_r uuid NOT NULL,
base_begin timestamp(0) NOT NULL, -- ← є, бо basePeriod ≠ None
base_end timestamp(0) NOT NULL,
-- act_begin / act_end ВІДСУТНІ (actionPeriod: false)
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
r1 numeric(15,2) NOT NULL DEFAULT 0,
r2 numeric(15,2) NOT NULL DEFAULT 0,
CONSTRAINT pk_rg_c_0041 PRIMARY KEY (rec_t, rec_r, line_no)
);
-- Таблиця rg_c_0041_ap НЕ створюється (немає періоду дії → немає витіснення)
CREATE TABLE rg_c_0041_rc1 ( -- ПерерахунокУтримань
rec_t smallint NOT NULL, rec_r uuid NOT NULL,
calc_type_r uuid NOT NULL, d1_r uuid NOT NULL,
src_rec_t smallint NOT NULL, src_rec_r uuid NOT NULL,
created_at timestamp(0) NOT NULL DEFAULT now(),
CONSTRAINT pk_rg_c_0041_rc1 PRIMARY KEY (rec_t, rec_r, calc_type_r, d1_r)
);
</syntaxhighlight>

{{Note|'''Міжпланова база.''' Базові види розрахунку для ПВР <code>Утримання</code> належать до ''іншого'' ПВР — <code>ОсновніНарахування</code>. Це означає, що віртуальна таблиця <code>БазаРозрахунку</code> регістру <code>Утримання</code> має читати записи регістру <code>ОсновніНарахування</code>. '''Вимога ФТ-25 має бути розширена:''' метамодель повинна дозволяти вказати ''регістр-джерело бази''. Це '''відкрите питання В9''' (див. оновлений Додаток Г) — у 1С механізм працює через відповідність ПВР, а не регістрів, що обмежує сценарії. Пропозиція: додати до <code>md_register</code> поле <code>base_register_id</code>.}}

'''Приклад даних:'''
{| class="wikitable"
! line !! calc_type !! period !! base_begin !! base_end !! Співробітник !! r2 (База) !! r1 (Результат)
|-
| 1 || ПДФО || 2026-07-01 || 2026-07-01 || 2026-07-31 || Іваненко || 21 773.91 || 3 919.30
|-
| 2 || Військовий збір || 2026-07-01 || 2026-07-01 || 2026-07-31 || Іваненко || 21 773.91 || 326.61
|-
| 3 || Аліменти || 2026-07-01 || 2026-07-01 || 2026-07-31 || Іваненко || 17 528.00 || 4 382.00
|}

=== Д.8. Наскрізний приклад: проведення видаткової накладної ===

'''Документ:''' Видаткова накладна №12 від 05.07.2026, ТОВ «Бета», 30 кг кави за 400 грн (12 000 грн з ПДВ), собівартість 7 000 грн.

<graphviz>
digraph Posting {
rankdir=LR; bgcolor="transparent";
node [shape=box, style="rounded,filled", fontname="DejaVu Sans", fontsize=9];

D [label="Документ\nВидаткова накладна №12\n05.07.2026", fillcolor="#fff8e1", shape=note];

R1 [label="РН ТовариНаСкладах\n(Залишки)\nВитрата: 30 кг / 7 000 грн", fillcolor="#fff3e0"];
R2 [label="РН Взаєморозрахунки\n(Залишки)\nПрихід: 12 000 грн", fillcolor="#fff3e0"];
R3 [label="РН Продажі\n(Обороти)\n30 кг / 12 000 / 10 000 / 7 000", fillcolor="#fff3e0"];
R4 [label="РН ТовариВРезерві\n(Залишки)\nВитрата: 30 кг", fillcolor="#fff3e0"];
R5 [label="РБ Госпрозрахунковий\n3 проводки на 21 000", fillcolor="#fce4ec"];

T1 [label="rg_a_0012_tb\nMAXPERIOD: 80 → 50 кг", fillcolor="#ffe0b2", shape=cylinder];
T2 [label="rg_a_0013_tb\nMAXPERIOD: 0 → +12 000", fillcolor="#ffe0b2", shape=cylinder];
T3 [label="rg_a_0031_tt\n2026-07: +30 / +12 000", fillcolor="#ffe0b2", shape=cylinder];
T5 [label="rg_b_0020_tb0/tb2/tt0/tc", fillcolor="#f8bbd0", shape=cylinder];

D -> R1; D -> R2; D -> R3; D -> R4; D -> R5;
R1 -> T1; R2 -> T2; R3 -> T3; R5 -> T5;

label="ОДНА транзакція БД: усі 5 регістрів + підсумки + прапорець Проведений";
labelloc=b; fontname="DejaVu Sans"; fontsize=10;
}
</graphviz>

<syntaxhighlight lang="python">
class ВидатковаНакладна(Document):
"""Проведення по 5 регістрах в одній транзакції. Бюджет Python: <= 15 мс (АП-4)."""

def on_posting(self, ctx: PostingContext) -> None:
# --- 0. Блокування перед контролем залишків ---
with DataLock() as dl:
li = dl.add("РегістрНакопичення.ТовариНаСкладах.Залишки")
li.mode = DataLockMode.EXCLUSIVE
li.data_source = self.Товари.unload("Номенклатура", "Характеристика")
li.use_from_data_source("Номенклатура", "Номенклатура")
li.use_from_data_source("Характеристика", "Характеристика")
li.set_value("Склад", self.Склад)

self._movements_goods() # 1. ТовариНаСкладах
self._movements_ar() # 2. Взаєморозрахунки
self._movements_sales() # 3. Продажі
self._movements_reserve() # 4. ТовариВРезерві
self._movements_accounting() # 5. Госпрозрахунковий

self.movements.ТовариНаСкладах.write_now()
self._control_negative_balances(ctx)

# --- 1. РН ТовариНаСкладах: списання ---
def _movements_goods(self) -> None:
rs = self.movements.ТовариНаСкладах
rs.write = True
rs.clear()
rs.extend(
rs.new(Період=self.Дата,
ВидРуху=AccumulationMovementType.EXPENSE,
Номенклатура=r.Номенклатура, Характеристика=r.Характеристика,
Склад=self.Склад, Партія=r.Партія,
Кількість=r.Кількість, Сума=r.Собівартість)
for r in self.Товари
)

# --- 2. РН Взаєморозрахунки: дебіторка зростає ---
def _movements_ar(self) -> None:
rs = self.movements.ВзаєморозрахункиЗКонтрагентами
rs.write = True
rs.clear()
rs.append(rs.new(
Період=self.Дата,
ВидРуху=AccumulationMovementType.RECEIPT, # Прихід = борг зростає
Організація=self.Організація, Контрагент=self.Контрагент,
Договір=self.Договір, Замовлення=self.ЗамовленняПокупця,
Сума=self.СумаДокумента, СумаВал=self.СумаДокументаВал,
))

# --- 3. РН Продажі: оборот (ВидРуху відсутній!) ---
def _movements_sales(self) -> None:
rs = self.movements.Продажі
rs.write = True
rs.clear()
rs.extend(
rs.new(Період=self.Дата,
Номенклатура=r.Номенклатура, Контрагент=self.Контрагент,
Договір=self.Договір, Менеджер=self.Менеджер, Склад=self.Склад,
Кількість=r.Кількість, Сума=r.Сума,
СумаБезПДВ=r.СумаБезПДВ, Собівартість=r.Собівартість)
for r in self.Товари
)

# --- 4. РН ТовариВРезерві: зняття резерву ---
def _movements_reserve(self) -> None:
if self.ЗамовленняПокупця.is_empty():
return
rs = self.movements.ТовариВРезерві
rs.write = True
rs.clear()
rs.extend(
rs.new(Період=self.Дата, ВидРуху=AccumulationMovementType.EXPENSE,
Номенклатура=r.Номенклатура, Характеристика=r.Характеристика,
Склад=self.Склад, Замовлення=self.ЗамовленняПокупця,
Кількість=r.Кількість)
for r in self.Товари
)

# --- 5. РБ Госпрозрахунковий: 3 проводки на рядок ---
def _movements_accounting(self) -> None:
rs = self.movements.Госпрозрахунковий
rs.write = True
rs.clear()
for r in self.Товари:
e1 = rs.add_accounting_entry( # Дт 361 / Кт 702
Період=self.Дата, Організація=self.Організація,
РахунокДт=Accounts["361"], РахунокКт=Accounts["702"],
Сума=r.Сума, КількістьКт=r.Кількість)
e1.subconto_dt[ВидиСубконто.Контрагенти] = self.Контрагент
e1.subconto_dt[ВидиСубконто.Договори] = self.Договір
e1.subconto_kt[ВидиСубконто.Номенклатура] = r.Номенклатура

e2 = rs.add_accounting_entry( # Дт 702 / Кт 641 (ПДВ)
Період=self.Дата, Організація=self.Організація,
РахунокДт=Accounts["702"], РахунокКт=Accounts["641"],
Сума=r.СумаПДВ)
e2.subconto_dt[ВидиСубконто.Номенклатура] = r.Номенклатура
e2.subconto_kt[ВидиСубконто.ПодаткиІЗбори] = Taxes.ПДВ

e3 = rs.add_accounting_entry( # Дт 902 / Кт 281
Період=self.Дата, Організація=self.Організація,
РахунокДт=Accounts["902"], РахунокКт=Accounts["281"],
Сума=r.Собівартість,
КількістьДт=r.Кількість, КількістьКт=r.Кількість)
e3.subconto_dt[ВидиСубконто.Номенклатура] = r.Номенклатура
e3.subconto_kt[ВидиСубконто.Номенклатура] = r.Номенклатура
e3.subconto_kt[ВидиСубконто.Склади] = self.Склад
</syntaxhighlight>

'''Що відбувається у БД (одна транзакція):'''
{| class="wikitable"
! Крок !! Таблиця !! Операція !! Рядків
|-
| 1 || <code>doc_0003</code> || UPDATE posted = true || 1
|-
| 2 || <code>rg_a_0012</code> (ТовариНаСкладах) || DELETE + INSERT || 1
|-
| 3 || <code>rg_a_0012_tb</code> || MERGE (MAXPERIOD + періоди > 07.2026) || 2
|-
| 4 || <code>rg_a_0013</code> (Взаєморозрахунки) || DELETE + INSERT || 1
|-
| 5 || <code>rg_a_0013_tb</code> || MERGE || 2
|-
| 6 || <code>rg_a_0031</code> (Продажі) || DELETE + INSERT || 1
|-
| 7 || <code>rg_a_0031_tt</code> || MERGE (тільки період 2026-07) || 1
|-
| 8 || <code>rg_a_0031_ag1</code> || MERGE (realtime-агрегат) || 1
|-
| 9 || <code>rg_a_0014</code> (Резерв) || DELETE + INSERT || 1
|-
| 10 || <code>rg_b_0020</code> (проводки) || DELETE + INSERT || 3
|-
| 11 || <code>rg_b_0020_tb0</code> || MERGE || 10
|-
| 12 || <code>rg_b_0020_tb1/tb2</code> || MERGE || 8
|-
| 13 || <code>rg_b_0020_tt0..tt2</code> || MERGE || 12
|-
| 14 || <code>rg_b_0020_tc</code> || MERGE || 3
|-
| colspan="3" | '''Разом''' || '''≈ 47 рядків, 1 COMMIT'''
|}

{{Note|'''Спостереження для НФВ-04.''' Один рядок товару в накладній породжує ~47 модифікацій рядків у 14 таблицях. Для накладної зі 100 рядків це ~2 000–4 000 модифікацій. Саме тут — основне навантаження проведення, і саме тому РБ (кроки 10–14) дає ~70 % вартості транзакції. Це аргумент на користь MVP без РБ (розділ 14) і предмет вимірювання в НТ-03.}}

=== Д.9. Наскрізний приклад: розрахунок зарплати ===

<pre>
КРОК 1. Документ «Нарахування зарплати» за липень 2026, Іваненко.
Записуємо рухи в РР ОсновніНарахування (Результат = 0).

КРОК 2. Платформа автоматично будує фактичні періоди дії (rg_c_0040_ap):
Оклад → [01.07–09.07], [23.07–31.07]
Відпустка → [10.07–13.07]
Лікарняний → [14.07–22.07]

КРОК 3. Розрахунок «первинних» видів (без бази) — Оклад.
Запит до ДаніГрафіка:
НормаДнів = 23 (робочих днів у липні за П'ятиденкою)
ВідпрацьованоДнів = 13 (робочі дні у фактичних періодах дії)
Результат = 18 000 × 13 / 23 = 10 173,91
→ UPDATE rg_c_0040 SET r1 = 10173.91, r2 = 13, r3 = 23 WHERE line_no = 1

КРОК 4. Розрахунок видів із базою — Відпустка, Лікарняний.
Запит до БазаРозрахунку (базовий період 01.01–30.06, база = Оклад+Премія):
Заробіток за 6 міс. = 115 560,00
Календарних днів = 181
Середньоденний = 638,45
Відпустка: 638,45 × 4 дні (10–13.07) = 2 553,80
Лікарняний: 638,45 × 9 днів × 100 % = 5 746,05
→ UPDATE rg_c_0040 SET r1 = ... WHERE line_no IN (2, 3)

КРОК 5. Записуємо рухи в РР Утримання (базовий період = період реєстрації, липень).
База ПДФО = 10 173,91 + 2 553,80 + 5 746,05 = 18 473,76
ПДФО = 18 473,76 × 18 % = 3 325,28
ВЗ = 18 473,76 × 1,5 % = 277,11

КРОК 6. Проведення документа → рухи в:
РН ВитратиЗаСтаттями (Обороти): Стаття «ЗП і нарахування» = 18 473,76
РБ Госпрозрахунковий: Дт 92 / Кт 661 = 18 473,76
Дт 661 / Кт 641.ПДФО = 3 325,28
Дт 661 / Кт 642.ВЗ = 277,11

КРОК 7. Через тиждень бухгалтер змінює Оклад Іваненка за червень (заднім числом).
→ Платформа реєструє в rg_c_0040_rc1 (ПерерахунокЗаБазою):
(Реєстратор = НарахуванняЗП липня, ВидРозрахунку = Відпустка, Співробітник = Іваненко)
(Реєстратор = НарахуванняЗП липня, ВидРозрахунку = Лікарняний, Співробітник = Іваненко)
→ Звіт «Документи до перерахунку» показує липневий документ.
→ Бухгалтер перепроводить → база перераховується → записи перерахунку очищаються.
</pre>

=== Д.10. Антипатерни проєктування регістрів ===

{| class="wikitable"
! ID !! Антипатерн !! Чому погано !! Як правильно
|-
| '''А-1''' || Дата як '''вимірювання''' у РН (замість стандартного <code>Період</code>) || Таблиця підсумків множиться на кількість дат і зростає нескінченно; віртуальні таблиці <code>Залишки</code>/<code>Обороти</code> ігнорують це вимірювання і дають безглузді результати || Використовувати стандартний реквізит <code>Період</code>. Виняток — календарі (Д.3.4), де це РВ, а не РН
|-
| '''А-2''' || РН «Залишки» там, де потрібна лише історія значення || Надлишкові таблиці підсумків, кумулятивні оновлення, вид руху без сенсу || РВ періодичний
|-
| '''А-3''' || РН «Залишки» там, де залишок безглуздий (Продажі, Витрати) || Удвічі більший обсяг підсумків, кумулятивні MERGE на всі майбутні періоди || РН «Обороти» + агрегати (Д.5.1)
|-
| '''А-4''' || Реквізит документа продубльовано у вимірювання «щоб фільтрувати у звіті» || Кардинальність підсумків × N; типовий випадок — Менеджер/Валюта/Коментар || Реквізит регістру + з'єднання з документом у звіті; або окремий регістр «Обороти»
|-
| '''А-5''' || > 8 вимірювань в одному РН || Таблиця підсумків стає '''більшою''' за таблицю рухів; проведення сповільнюється в рази || Розділити на регістри за призначенням; частину аналітики — в «Обороти» з агрегатами
|-
| '''А-6''' || Незалежний РВ «у межах секунди» як журнал подій || Два записи в ту саму секунду → другий '''мовчки замістить''' перший; втрата даних || Підпорядкований РВ (реєстратор у ключі) або додати вимірювання-дискримінатор
|-
| '''А-7''' || Ресурс типу <code>Рядок</code>/<code>Посилання</code> у РН || Підсумовування неможливе; підсумки не побудуються || Реквізит (не агрегується) або вимірювання (якщо це розріз)
|-
| '''А-8''' || Прямий <code>UPDATE</code> таблиці підсумків із прикладного коду || Розсинхронізація підсумків і рухів; діагностика — тижні || Тільки через набори записів. Заборона на рівні прав БД (розділ 12.2)
|-
| '''А-9''' || Один «універсальний» регістр із вимірюванням <code>ВидОбліку</code> (БУ/ПУ/УО) замість трьох || Втричі більша таблиця; конкуренція за блокування між незалежними обліками; неможливо окремо перерахувати підсумки || Окремі регістри. Виняток — РБ <code>ПодатковийОблік</code> (Д.6.2), де ВидРізниці — це справді розріз одного обліку
|-
| '''А-10''' || Функціонально залежне поле як вимірювання (Валюта при БанківськомуРахунку) || Надлишковість; ризик неузгоджених даних; зайвий розмір ключа підсумків || З'єднання з довідником у запиті (Д.4.4)
|-
| '''А-11''' || РБ там, де достатньо РН || Замість 1 таблиці — 10; ~70 % вартості проведення (Д.8); складність субконто без потреби || РН. РБ — лише коли потрібні план рахунків, подвійний запис і кореспонденції
|-
| '''А-12''' || Вимірювання з <code>nullable</code> без потреби || Порожнє посилання — окреме значення ключа; підсумки «розмазуються» на два рядки замість одного || <code>denyEmpty: true</code> скрізь, де порожнє значення не має сенсу
|-
| '''А-13''' || Контроль залишків '''до''' запису рухів || Класична гонитва: два сеанси проходять контроль і обидва списують у мінус || Спершу <code>DataLock</code> → <code>WriteNow()</code> → потім контроль (Д.8, ФТ-Т-12)
|-
| '''А-14''' || <code>periodicity: WithinSecond</code> «про всяк випадок» скрізь || Для РВ — неможливість замістити запис за день; для РН — марна точність, більші індекси || Обирати мінімально достатню: день для цін/курсів/виписок, секунда — для складських рухів
|-
| '''А-15'''<br />''(Python)'' || Запис рухів у циклі: <code>for r in Товари: rs.add(...).write()</code> || Порушення АП-1: 100 round-trip'ів замість 1; проведення 300 мс → ~10 с. Невидиме на тестових даних, катастрофічне на продуктиві. Найчастіша помилка при ORM-мисленні || Наповнити набір повністю (<code>rs.extend(генератор)</code>), записати один раз. Детектор — Додаток Е.7
|-
| '''А-16'''<br />''(Python)'' || Агрегація дельт підсумків у Python (<code>defaultdict</code> + цикл) замість <code>MERGE</code> || Порушення АП-2: дані ганяються в застосунок і назад; на 10<sup>5</sup> рядків — десятки секунд || <code>INSERT … ON CONFLICT DO UPDATE</code> одним запитом (Е.3)
|}

=== Д.11. Чек-лист рев'ю нового регістру ===

<pre>
□ Тип регістру обґрунтований за деревом Д.1
□ Кожне вимірювання використовується у фільтрі АБО групуванні звітів
□ Кожен ресурс має сенс при підсумовуванні
□ Немає полів з антипатернів А-1, А-4, А-7, А-10, А-12
□ Оцінка кардинальності підсумків ≤ 10^8 (калькулятор конструктора, ФТ-К-03)
□ Для вимірювань, де порожнє значення безглузде, стоїть denyEmpty
□ Ведучі (master) вимірювання визначені — інакше «висячі» записи при видаленні об'єктів
□ Склад реєстраторів повний; зайвих типів документів немає
□ Угода про знак / вид руху зафіксована в методологічній документації
□ Періодичність мінімально достатня (А-14)
□ Для РН «Обороти» з >4 вимірюваннями визначено ≥1 агрегат
□ Для РБ: балансові/небалансові вимірювання та ресурси розставлені свідомо
□ Для РР: витісняючі та базові види розрахунку в ПВР заповнені; перерахунки визначені
□ Партиціонування ввімкнене, якщо очікується >100 млн записів
□ Написано тест на проведення + скасування + перерахунок підсумків
</pre>

== Додаток Е. Ескізи реалізації ядра на Python ==

Додаток демонструє, що метамодель розділу 6 і фізична модель розділу 8 реалізовні обраним стеком (розділ 4.3), і фіксує ключові технічні рішення для етапів Е1, Е3, Е5, Е7, Е11. Код — ілюстративний ескіз, а не остаточний API.

=== Е.1. Маніфест регістру як Pydantic-модель (етап Е1) ===

YAML-декларації розділу 6.7 і Додатка Д валідуються цією моделлю. Це '''безпосередньо реалізує ФТ-К-01''' (валідація в реальному часі) і частину контролю антипатернів Д.10.

<syntaxhighlight lang="python">
from __future__ import annotations

import warnings
from enum import StrEnum
from typing import Annotated, Literal, Self

from pydantic import BaseModel, ConfigDict, Field, model_validator

IDENT = r"^[^\W\d]\w{0,79}$" # Unicode-ідентифікатор (кирилиця дозволена), <= 80 симв.

class RegisterKind(StrEnum):
INFORMATION = "Information"
ACCUMULATION = "Accumulation"
ACCOUNTING = "Accounting"
CALCULATION = "Calculation"

class Periodicity(StrEnum):
NONPERIODICAL = "Nonperiodical"
WITHIN_SECOND = "WithinSecond"
WITHIN_DAY = "WithinDay"
WITHIN_MONTH = "WithinMonth"
WITHIN_QUARTER = "WithinQuarter"
WITHIN_YEAR = "WithinYear"
BY_RECORDER_POSITION = "ByRecorderPosition"

class WriteMode(StrEnum):
INDEPENDENT = "Independent"
SUBORDINATE = "SubordinateToRecorder"

class FieldRole(StrEnum):
DIMENSION = "Dimension"
RESOURCE = "Resource"
ATTRIBUTE = "Attribute"

class RegisterField(BaseModel):
model_config = ConfigDict(extra="forbid", frozen=True)

name: Annotated[str, Field(pattern=IDENT)]
role: FieldRole
type: str | list[str] # "Довідник.Номенклатура" | ["Документ.А", "Документ.Б"]
synonym: str | None = None
index: bool = False
master: bool = False # «Ведуче»
deny_empty: bool = False
nullable: bool = False
use_in_totals: bool = True
# РБ
balance: bool = False
accounting_flag: str | None = None
# РР
base_dimension: bool = False

@property
def is_composite(self) -> bool:
return isinstance(self.type, list) and len(self.type) > 1

class Register(BaseModel):
model_config = ConfigDict(extra="forbid")

name: Annotated[str, Field(pattern=IDENT)]
kind: RegisterKind
synonym: str | None = None
periodicity: Periodicity = Periodicity.NONPERIODICAL
write_mode: WriteMode = WriteMode.SUBORDINATE
dimensions: list[RegisterField] = []
resources: list[RegisterField] = []
attributes: list[RegisterField] = []
recorders: list[str] = []
# РН
accumulation_kind: Literal["Balance", "Turnover"] | None = None
enable_balance_totals: bool = True
enable_turnover_totals: bool = False
turnover_totals_period: Literal["Day", "Month"] | None = None
# РБ
chart_of_accounts: str | None = None
correspondence: bool = True
max_extdim_count: Annotated[int, Field(ge=0, le=5)] = 3
# РР
calculation_types_plan: str | None = None
action_period: bool = False
base_period: Literal["None", "ByActionPeriod", "ByRegistrationPeriod"] = "None"

# ---------- крос-полева валідація (розділи 6.2–6.6) ----------
@model_validator(mode="after")
def _validate(self) -> Self:
if self.write_mode is WriteMode.INDEPENDENT and self.kind is not RegisterKind.INFORMATION:
raise ValueError("Незалежний режим запису дозволено лише для регістру відомостей")

if self.kind is RegisterKind.ACCUMULATION:
if self.accumulation_kind is None:
raise ValueError("Для регістру накопичення обов'язковий accumulation_kind")
if self.periodicity is Periodicity.NONPERIODICAL:
raise ValueError("Регістр накопичення не може бути неперіодичним")
if self.accumulation_kind == "Turnover" and self.enable_balance_totals:
raise ValueError("Підсумки залишків несумісні з видом «Обороти»")

if self.kind is RegisterKind.ACCOUNTING and not self.chart_of_accounts:
raise ValueError("Для регістру бухгалтерії обов'язковий chart_of_accounts")

if self.kind is RegisterKind.CALCULATION:
if not self.calculation_types_plan:
raise ValueError("Для регістру розрахунку обов'язковий calculation_types_plan")
if not any(f.base_dimension for f in self.dimensions) and self.base_period != "None":
raise ValueError("Задано base_period, але жодне вимірювання не позначене base_dimension")

# ресурс має бути підсумовуваним (антипатерн А-7)
if self.kind is not RegisterKind.INFORMATION:
for r in self.resources:
if not _is_numeric(r.type):
raise ValueError(f"Ресурс «{r.name}»: тип {r.type} не підсумовується (А-7). "
f"Використайте роль Attribute або Dimension")

# обмеження розділу 6.6
if len(self.dimensions) > 20:
raise ValueError(f"Вимірювань {len(self.dimensions)} > 20 (розділ 6.6)")

# попередження (ФТ-К-01: warnings, а не помилки)
if len(self.dimensions) > 8:
warnings.warn(f"«{self.name}»: {len(self.dimensions)} вимірювань — "
f"ризик розростання таблиці підсумків (антипатерн А-5)")
for d in self.dimensions:
if d.type == "Дата" and self.kind is RegisterKind.ACCUMULATION:
warnings.warn(f"«{self.name}.{d.name}»: Дата як вимірювання РН — антипатерн А-1")
return self
</syntaxhighlight>

'''Що це дає безкоштовно:''' валідацію YAML, JSON Schema для web-конструктора (<code>Register.model_json_schema()</code>), типізовані об'єкти для генератора DDL, детальні повідомлення про помилки з шляхом до поля.

=== Е.2. Генератор DDL на SQLAlchemy Core (етап Е1) ===

<syntaxhighlight lang="python">
from collections.abc import Callable, Sequence

from sqlalchemy import (Boolean, Column, DateTime, Index, Integer, MetaData, Numeric,
PrimaryKeyConstraint, SmallInteger, String, Table, Uuid, text)
from sqlalchemy.types import TypeEngine

PRIMITIVE: dict[str, Callable[[RegisterField], TypeEngine]] = {
"Число": lambda f: Numeric(f.precision, f.scale),
"Рядок": lambda f: String(f.length),
"Дата": lambda f: DateTime(timezone=False),
"Булево": lambda f: Boolean(),
"УНІ": lambda f: Uuid(),
}

def columns_for_field(f: RegisterField, prefix: str) -> list[Column]:
"""Одне поле метаданих -> 1..6 фізичних колонок (розділ 8.2)."""
if f.is_composite: # складений тип: розділ 8.2.2
return [
Column(f"{prefix}_t", SmallInteger, nullable=False),
Column(f"{prefix}_b", Boolean),
Column(f"{prefix}_n", Numeric(38, 10)),
Column(f"{prefix}_s", String(f.max_string_len)),
Column(f"{prefix}_d", DateTime),
Column(f"{prefix}_r", Uuid),
]
if f.is_reference: # просте посилання
return [Column(f"{prefix}_r", Uuid, nullable=f.nullable)]
base = f.base_type
return [Column(prefix, PRIMITIVE[base](f), nullable=f.nullable)]

def build_movement_table(reg: Register, md: MetaData) -> Table:
"""Метаопис -> Table. Розділи 8.4–8.7."""
cols: list[Column] = []

if reg.write_mode is WriteMode.SUBORDINATE:
cols += [
Column("rec_t", SmallInteger, nullable=False),
Column("rec_r", Uuid, nullable=False),
Column("line_no", Integer, nullable=False),
Column("active", Boolean, nullable=False, server_default=text("true")),
]
if reg.periodicity is not Periodicity.NONPERIODICAL:
cols.append(Column("period", DateTime, nullable=False))
if reg.kind is RegisterKind.ACCUMULATION and reg.accumulation_kind == "Balance":
cols.append(Column("mvt", SmallInteger, nullable=False)) # ВидРуху
if reg.kind is RegisterKind.CALCULATION:
cols += [Column("calc_type_r", Uuid, nullable=False),
Column("reversal", Boolean, nullable=False, server_default=text("false"))]
if reg.action_period:
cols += [Column("act_begin", DateTime, nullable=False),
Column("act_end", DateTime, nullable=False)]
if reg.base_period != "None":
cols += [Column("base_begin", DateTime), Column("base_end", DateTime)]

for f in reg.all_fields: # dimensions + resources + attributes
cols += columns_for_field(f, reg.column_prefix(f)) # 'd3', 'r1', 'a2'

t = Table(reg.physical_table, md, *cols,
PrimaryKeyConstraint(*primary_key_columns(reg),
name=f"pk_{reg.physical_table}"),
postgresql_partition_by=partition_clause(reg))

for f in reg.dimensions:
if f.index:
Index(f"ix_{reg.physical_table}_{reg.column_prefix(f)}",
*index_columns(reg, f),
postgresql_where=t.c.active if "active" in t.c else None)
return t
</syntaxhighlight>

'''НФВ-16 / НФВ-17 (дві СКБД, ізольований шар діалекту) — у три рядки:'''

<syntaxhighlight lang="python">
from sqlalchemy.dialects import mssql, postgresql
from sqlalchemy.schema import CreateTable

md = MetaData()
t = build_movement_table(reg_goods, md)

print(CreateTable(t).compile(dialect=postgresql.dialect())) # -> CREATE TABLE rg_a_0012 (...)
print(CreateTable(t).compile(dialect=mssql.dialect())) # -> той самий об'єкт у T-SQL
</syntaxhighlight>

{{Note|'''Це і є головний аргумент на користь Python у цьому проєкті.''' SQLAlchemy Core — фактично готовий «шар діалекту СКБД» (НФВ-17) і модель схеми, які в C#/Delphi довелося б писати самостійно. Разом із Alembic (Е10) і Pydantic (Е.1) це знімає ~1,5 чол.-міс. з етапів Е1 і Е10 (розділ 14.1).}}

'''Реалізація ФТ-К-02''' («Показати SQL» у конструкторі) — той самий виклик <code>CreateTable(t).compile(...)</code>, виведений у UI.

=== Е.3. Інкрементальне оновлення підсумків (етап Е3) ===

Реалізація алгоритму 10.2 з дотриманням АП-1 (один запит на весь набір) і ФТ-34 (детермінований порядок проти дедлоків).

<syntaxhighlight lang="python">
from operator import itemgetter
from collections.abc import Sequence

from sqlalchemy import Connection, Table
from sqlalchemy.dialects.postgresql import insert as pg_insert

def merge_totals(conn: Connection, totals: Table, rows: list[dict],
key: Sequence[str], res: Sequence[str]) -> None:
"""АП-1 + АП-2: одна операція на весь набір дельт; складання виконує СКБД."""
if not rows:
return

rows.sort(key=itemgetter(*key)) # ФТ-34: детермінований порядок -> без дедлоків

stmt = pg_insert(totals).values(rows)
stmt = stmt.on_conflict_do_update(
index_elements=list(key),
set_={r: totals.c[r] + stmt.excluded[r] for r in res}, # r1 = t.r1 + EXCLUDED.r1
)
conn.execute(stmt) # 1 round-trip незалежно від len(rows)
</syntaxhighlight>

'''Для MS SQL''' — той самий інтерфейс, інша реалізація (<code>MERGE ... WHEN MATCHED THEN UPDATE</code>) за діалектним диспетчером. Ізоляція — на рівні функції, прикладний код не знає про діалект.

'''Чому НЕ ORM:''' ORM-варіант (<code>session.merge(obj)</code> у циклі) дав би <code>len(rows)</code> round-trip'ів — пряме порушення АП-1 і зростання НФВ-04 на два порядки. Саме тому ORM заборонений у розділі 4.3.

=== Е.4. Транслятор віртуальних таблиць (етап Е5) ===

<syntaxhighlight lang="python">
from functools import lru_cache

from lark import Lark, Transformer
from sqlalchemy import Select, func, literal, select, union_all

GRAMMAR = r"""
?query : "ВИБРАТИ"i select_list "З"i source [where] [group_by] [order_by]
source : virtual_table | plain_table
virtual_table : REGISTER_PATH "." VT_NAME "(" [vt_args] ")" ["ЯК"i alias]
VT_NAME : "Залишки"i | "Обороти"i | "ЗалишкиІОбороти"i
| "ЗрізОстанніх"i | "ЗрізПерших"i | "ОборотиДтКт"i
| "ДаніГрафіка"i | "ФактичнийПеріодДії"i | "БазаРозрахунку"i
vt_args : (expr | ) ("," (expr | ))* // позиційні, можуть бути порожні
...
"""

class QueryCompiler:
def __init__(self, schema: SchemaRegistry) -> None:
self._parser = Lark(GRAMMAR, parser="lalr", start="query")
self._schema = schema

@lru_cache(maxsize=2048) # АП-4: кеш скомпільованих запитів
def compile(self, text: str, param_signature: tuple[str, ...]) -> Select:
tree = self._parser.parse(text)
return _ToSQLAlchemy(self._schema).transform(tree)

def balances(self, reg: Register, period, conditions: list) -> Select:
"""Реалізація алгоритму 10.3 в термінах SQLAlchemy Core."""
tb = self._schema.totals_balance(reg)
mv = self._schema.movements(reg)
dims = [tb.c[c] for c in self._schema.dimension_columns(reg)]

boundary = (select(func.coalesce(func.max(tb.c.period), MIN_PERIOD))
.where(tb.c.period <= period)
.scalar_subquery())

base = (select(*dims, *[func.sum(tb.c[r]).label(r) for r in reg.resource_columns])
.where(tb.c.period == boundary, *conditions) # ФТ-13: push-down
.group_by(*dims))

signed = lambda c: case((mv.c.mvt == 0, mv.c[c]), else_=-mv.c[c])
tail = (select(*[mv.c[d.name] for d in dims],
*[func.sum(signed(r)).label(r) for r in reg.resource_columns])
.where(mv.c.active, mv.c.period > boundary, mv.c.period <= period, *conditions)
.group_by(*[mv.c[d.name] for d in dims]))

u = union_all(base, tail).subquery()
return (select(*[u.c[d.name] for d in dims],
*[func.sum(u.c[r]).label(f"{r}Залишок") for r in reg.resource_columns])
.group_by(*[u.c[d.name] for d in dims])
.having(or_(*[func.sum(u.c[r]) != 0 for r in reg.resource_columns])))
</syntaxhighlight>

'''Ризик Р1 (немає мови запитів) на Python пом'якшується:''' навіть якщо повноцінна мова запитів не буде реалізована в Е5, <code>QueryCompiler.balances()</code> залишається придатним як програмний API — прикладний код викликає його напряму й отримує <code>Select</code>, який можна далі з'єднувати засобами SQLAlchemy Core. Це '''план «Б»''' для Р1, недоступний у мовах без подібної бібліотеки.

=== Е.5. Витіснення: гарячий шлях за інтерфейсом (етапи Е7, Е11) ===

Реалізація принципу АП-3 на найризикованішому вузлі (Р5 + Р10).

<syntaxhighlight lang="python">
from collections import defaultdict
from collections.abc import Callable, Sequence
from datetime import date, timedelta
from typing import Protocol
from uuid import UUID

Interval = tuple[date, date]
ONE_DAY = timedelta(days=1)

class DisplacementEngine(Protocol):
"""АП-3. Бюджет (АП-4): <= 3 c на 10 тис. ключів × ~10 записів."""

def compute(self,
records: Sequence[CalcRecord],
displaces: Callable[[UUID, UUID], bool]) -> dict[RecordKey, list[Interval]]:
"""Повертає фактичні періоди дії для кожного запису (розділ 10.4)."""
...

def subtract(intervals: list[Interval], cut: Interval) -> list[Interval]:
"""Різниця множин інтервалів. Найгарячіша функція платформи."""
out: list[Interval] = []
cb, ce = cut
for b, e in intervals:
if ce < b or cb > e: # не перетинаються
out.append((b, e))
continue
if b < cb:
out.append((b, cb - ONE_DAY)) # «хвіст» зліва
if e > ce:
out.append((ce + ONE_DAY, e)) # «хвіст» справа
return out

class PyDisplacementEngine:
"""Еталонна реалізація. Заміна на Cython/Rust не змінює виклик (АП-3)."""

def compute(self, records, displaces):
by_key: dict[DimKey, list[CalcRecord]] = defaultdict(list)
for r in records:
if r.active:
by_key[r.dim_key].append(r)

result: dict[RecordKey, list[Interval]] = {}
for Z in by_key.values():
if len(Z) > 500: # розділ 10.4: перехід на sweep-line
result |= SweepLineEngine().compute(Z, displaces)
continue
Z.sort(key=lambda r: (r.priority, r.period, r.line_no))
for z in Z:
intervals = [(z.act_begin, z.act_end)]
for w in Z:
if w is z or not displaces(w.calc_type, z.calc_type):
continue
if not _registration_periods_intersect(w, z):
continue
intervals = subtract(intervals, (w.act_begin, w.act_end))
if not intervals:
break # повністю витіснений
result[z.key] = intervals
return result
</syntaxhighlight>

'''Property-based тести (мітигація Р5 — найпомилковішого вузла):'''

<syntaxhighlight lang="python">
from hypothesis import given
from hypothesis import strategies as st

dates = st.dates(min_value=date(2020, 1, 1), max_value=date(2030, 12, 31))
intervals = st.lists(st.tuples(dates, dates).map(lambda t: tuple(sorted(t))), max_size=20)

@given(ivs=intervals, cut=st.tuples(dates, dates).map(lambda t: tuple(sorted(t))))
def test_subtract_invariants(ivs: list[Interval], cut: Interval) -> None:
out = subtract(ivs, cut)
assert all(b <= e for b, e in out), "некоректні межі"
assert not any(_overlaps(i, cut) for i in out), "витіснений інтервал залишився"
# збереження міри: те, що прибрали, дорівнює перетину з cut
assert _measure(out) + _measure(_intersect_all(ivs, cut)) == _measure(ivs)
</syntaxhighlight>

'''Бенчмарк як блокер приймання (АП-4):'''

<syntaxhighlight lang="python">
@pytest.mark.benchmark(group="displacement")
def test_displacement_budget(benchmark, records_10k_keys) -> None:
"""Вводиться в CI з етапу Е7. Перевищення бюджету -> червоний білд."""
benchmark(PyDisplacementEngine().compute, records_10k_keys, displaces)
assert benchmark.stats.stats.mean < 3.0, (
f"Порушено бюджет АП-4: {benchmark.stats.stats.mean:.2f} c > 3.0 c. "
f"Розгляньте sweep-line, Cython або перенесення у SQL (daterange + GiST)."
)
</syntaxhighlight>

=== Е.6. Генерація <code>.pyi</code>-стабів (ФТ-К-07, етап Е1) ===

'''Проблема:''' поля регістру доступні динамічно (<code>rs.new(Номенклатура=…)</code>), тому <code>mypy</code> не бачить одруків і помилок типів — це і є ризик Р11.

'''Рішення:''' конструктор генерує стаби з метаопису при кожній зміні конфігурації.

<syntaxhighlight lang="python">
# k2/generated/registers/ТовариНаСкладах.pyi -- АВТОЗГЕНЕРОВАНО. Не редагувати.
from datetime import datetime
from decimal import Decimal

from k2.catalogs import Номенклатура, Склади, ХарактеристикиНоменклатури
from k2.documents import ПрихіднаНакладна, ВведенняЗалишків
from k2.registers import AccumulationMovementType, Record, RecordSet

class ТовариНаСкладахRecord(Record):
Період: datetime
ВидРуху: AccumulationMovementType
Номенклатура: Номенклатура
Склад: Склади
Характеристика: ХарактеристикиНоменклатури | None
Партія: ПрихіднаНакладна | ВведенняЗалишків | None # складений тип
Кількість: Decimal
Сума: Decimal
Коментар: str

class ТовариНаСкладахRecordSet(RecordSet[ТовариНаСкладахRecord]):
def new(self, *, Період: datetime, ВидРуху: AccumulationMovementType,
Номенклатура: Номенклатура, Склад: Склади,
Характеристика: ХарактеристикиНоменклатури | None = None,
Партія: ПрихіднаНакладна | ВведенняЗалишків | None = None,
Кількість: Decimal = ..., Сума: Decimal = ...,
Коментар: str = ...) -> ТовариНаСкладахRecord: ...
</syntaxhighlight>

'''Що це ловить у CI ще до запуску:'''
{| class="wikitable"
! Помилка прикладного коду !! Без стабів !! Зі стабами
|-
| <code>rs.new(Номенклатур=x)</code> — одрук у назві поля || Виняток у рантаймі при проведенні на продуктиві || <code>mypy</code>: unexpected keyword argument
|-
| <code>m.Кількість = "багато"</code> || <code>InvalidOperation</code> при записі в БД || <code>mypy</code>: incompatible type <code>str</code>, expected <code>Decimal</code>
|-
| <code>m.Склад = номенклатура</code> — переплутані посилання || FK-помилка або, гірше, тихо неправильні дані || <code>mypy</code>: incompatible type
|-
| Видалили вимірювання з метаданих, код лишився || Виняток при проведенні || Червоний білд одразу після зміни конфігурації
|}

'''Автодоповнення в IDE''' — приємний побічний ефект, який частково компенсує відсутність повноцінного конфігуратора рівня 1С на ранніх етапах.

=== Е.7. Автоматичний детектор порушень АП-1 (етап Е3, CI) ===

Принцип АП-1 марний без механічної перевірки — розробник порушить його ненавмисно.

<syntaxhighlight lang="python">
# tests/architecture/test_ap1_no_row_by_row.py

@pytest.mark.parametrize("scenario", POSTING_SCENARIOS)
def test_roundtrips_do_not_scale_with_rows(db_counter, scenario) -> None:
"""АП-1: кількість звернень до СКБД НЕ залежить від кількості рядків документа."""
with db_counter() as c10:
scenario.build(rows=10).post()
with db_counter() as c100:
scenario.build(rows=100).post()

assert c100.roundtrips <= c10.roundtrips + 2, (
f"{scenario.name}: звернень до БД зросло {c10.roundtrips} -> {c100.roundtrips} "
f"при зростанні рядків у 10 разів. Порушення АП-1 — див. розділ 4.4."
)

class RowByRowGuard:
"""Runtime-запобіжник для dev/staging: виняток при >N однакових запитів у транзакції."""

def __init__(self, threshold: int = 20) -> None:
self._counts: Counter[str] = Counter()
self._threshold = threshold

def before_execute(self, conn, clauseelement, *args) -> None:
fingerprint = _statement_fingerprint(clauseelement) # SQL без літералів
self._counts[fingerprint] += 1
if self._counts[fingerprint] == self._threshold:
raise ArchitectureViolation(
f"Один і той самий запит виконано {self._threshold} разів у межах транзакції.\n"
f"Ймовірне порушення АП-1 («жодного рядка за раз»).\n{fingerprint}"
)
</syntaxhighlight>

'''Це — найдешевша страховка проєкту.''' Порушення АП-1 не видно на тестових даних (10 рядків — усе швидко) і катастрофічне на продуктиві (100 рядків × 5 регістрів). Детектор вводиться '''з етапу Е3''', а не за результатами НТ-03.

=== Е.8. Структура репозиторію ядра ===

<pre>
k2-registers/
├── src/k2/
│ ├── metadata/ # Е.1: Pydantic-моделі, репозиторій, валідація
│ │ ├── models.py # Register, RegisterField, ...
│ │ ├── repository.py # md_* таблиці
│ │ └── validators.py # ФТ-К-01, антипатерни Д.10
│ ├── schema/ # Е.2: генерація DDL
│ │ ├── builder.py # метаопис -> SQLAlchemy Table
│ │ ├── dialects/ # НФВ-17: postgres.py, mssql.py
│ │ └── restructure.py # Е10: Alembic-інтеграція
│ ├── runtime/ # набори записів, проведення, блокування
│ │ ├── recordset.py
│ │ ├── posting.py # розділ 7.1
│ │ ├── totals.py # Е.3: merge_totals
│ │ └── locks.py # ФТ-32
│ ├── query/ # Е.4: lark-граматика + компілятор
│ │ ├── grammar.lark
│ │ ├── compiler.py
│ │ └── virtual/ # balances.py, turnovers.py, slices.py, calc_base.py
│ ├── calculation/ # Е.5: витіснення (гарячий шлях)
│ │ ├── protocols.py # DisplacementEngine
│ │ ├── engine_py.py # еталонна реалізація
│ │ └── engine_native/ # [резерв] Cython/Rust — тільки за результатом бенчмарку
│ ├── codegen/ # Е.6: генерація .pyi-стабів
│ └── diagnostics/ # Е.7: RowByRowGuard, перевірка цілісності (ФТ-41)
├── tests/
│ ├── unit/
│ ├── property/ # hypothesis: інтервальна арифметика (Р5)
│ ├── architecture/ # Е.7: детектор АП-1
│ ├── benchmarks/ # АП-4: бюджети гарячих шляхів (gate у CI)
│ └── integration/ # testcontainers: PostgreSQL + MS SQL (Р7)
└── pyproject.toml # uv, ruff, mypy --strict
</pre>

----
''Кінець документа. Версія 1.2. Підлягає узгодженню з архітектором платформи K2 ERP до затвердження.''

Регістри в K2 ERP

2026-07-17T19:33:15Z

{{DISPLAYTITLE:ТЗ. Підсистема регістрів K2 ERP}}
__TOC__

= 1. Паспорт документа =

{| class="wikitable"
! Атрибут !! Значення
|-
| Назва || Технічне завдання на розробку підсистеми «Регістри» платформи K2 ERP
|-
| Шифр || K2-ERP-TZ-REG-001
|-
| Версія || 1.2 (чернетка на узгодження; мова ядра — Python; +Додатки Д, Е)
|-
| Статус || На розгляді
|-
| Замовник || ''[підрозділ-замовник]''
|-
| Виконавець || ''[команда платформи K2 ERP]''
|-
| Тип документа || Технічне завдання (ГОСТ 34.602 адаптовано)
|-
| Аналог / прототип || Механізм регістрів платформи «1С:Підприємство 8.3»
|-
| Мова розробки || '''Python 3.12+''' (див. розділ 4.3)
|-
| Технологічний стек || SQLAlchemy Core 2.x, Pydantic v2, Alembic, lark, psycopg 3 / pyodbc
|-
| СКБД || PostgreSQL 14+ (основна), MS SQL Server 2019+ (додаткова)
|}

== 1.1. Необхідні розширення MediaWiki ==

{| class="wikitable"
! Розширення !! Теги / шаблони !! Використано в документі !! Постачання
|-
| '''Extension:Diagrams''' || <code><nowiki><graphviz></nowiki></code>, <code><nowiki><uml></nowiki></code> || 4 діаграми GraphViz + 5 діаграм PlantUML || Composer: <code>samwilson/diagrams</code>
|-
| Extension:SyntaxHighlight || <code><nowiki><syntaxhighlight></nowiki></code> || 64 блоки коду (Python, SQL, YAML, lark) || '''Входить до складу MediaWiki''' — окремо встановлювати не потрібно
|-
| <code>Template:Note</code> || <code><nowiki>{{Note|текст}}</nowiki></code> || Примітки та проєктні рішення || Створюється вручну (код нижче)
|}

=== Налаштування ===

<syntaxhighlight lang="php">
// LocalSettings.php — конфігурація ВІКІ, у якій публікується це ТЗ.
// MediaWiki написана на PHP; до мови розробки K2 ERP (Python, розділ 4.3) це не стосується.
wfLoadExtension( 'Diagrams' );

// ОБОВ'ЯЗКОВО. За замовчуванням Diagrams рендерить у PNG; ER-діаграми розділу 9
// містять десятки колонок і в растрі нечитабельні.
$wgDiagramsDefaultFormat = 'svg';

// Варіант А — локальний рендеринг (потрібні бінарники на веб-сервері):
// apt install graphviz plantuml
// Варіант Б — зовнішній сервіс рендерингу (з версії 0.4.0 — опційний):
// $wgDiagramsServiceUrl = 'https://diagrams.example.com/subdir';
</syntaxhighlight>

Шаблон <code>Template:Note</code>, якщо його немає у вікі:
<pre>
<div style="border-left:4px solid #36c; background:#eaf3ff; padding:8px 12px; margin:8px 0;">
'''ⓘ''' {{{1}}}
</div>
</pre>

=== Вимоги до версії та смоук-тест ===

{{Note|'''Мінімальна версія — 1.0.0''' (реліз від 15.03.2026). Саме в ній додано <code>$wgDiagramsDefaultFormat</code>, без якого документ рендериться в PNG і ER-діаграми розділу 9 стають нечитабельними. Автор супроводжує підняття мажорної версії до 1 формулюванням, що проєкт вийшов на стабільність.}}

{{Note|'''Інфобокс на mediawiki.org станом на дату складання ТЗ застарілий''' — показує версію 0.10.0 (2022) і сумісність «MediaWiki ≤ 1.39», тоді як у репозиторії 27 релізів і остання — 1.0.0 від 15.03.2026. '''Джерело істини — GitHub''' (<nowiki>https://github.com/samwilson/diagrams-extension/releases</nowiki>), а не інфобокс вікі-сторінки. Обмеження «≤ 1.39» перевіряти не за сторінкою, а за <code>extension.json</code> актуального релізу.}}

Перед публікацією документа прогнати смоук-тест на цільовій вікі — по одному представнику кожного типу:

{| class="wikitable"
! # !! Що перевіряємо !! Де в документі !! Ознака успіху
|-
| 1 || <code><nowiki><graphviz></nowiki></code>, <code>rankdir</code>, <code>shape=record</code>, кластери || 5.1, 8.8, 9.5, Д.1, Д.8 || Діаграма рендериться, підписи не обрізані
|-
| 2 || <code><nowiki><uml></nowiki></code> + <code>@startuml</code>, <code>entity</code>, <code>skinparam linetype ortho</code> || 9.1–9.4 || ER-модель із колонками та позначками PK/FK
|-
| 3 || '''<code><nowiki><uml></nowiki></code> + <code>@startgantt</code>''' || '''7.5.1''' || Діаграма Ганта. '''Головний ризик:''' якщо розширення обгортає вміст у <code>@startuml</code> автоматично, <code>@startgantt</code> не спрацює
|-
| 4 || <code>$wgDiagramsDefaultFormat = 'svg'</code> || будь-яка || У HTML-коді сторінки <code><img src="…<b>.svg</b>"></code>, а не <code>.png</code>
|-
| 5 || Кирилиця в підписах вузлів || 5.1, 6.1 || Немає «квадратиків» — на сервері є потрібні шрифти
|}

{{Note|'''Щодо п. 3.''' Документ використовує явні роздільники <code>@startuml…@enduml</code> / <code>@startgantt…@endgantt</code> всередині тегів. Це відповідає нормалізованій поведінці PlantUML: розробники вимагають <code>@startXYZ</code> усюди, зокрема з прапорцем <code>-pipe</code>, а можливість опускати роздільник збережена лише як застаріла опція для сумісності зі старими скриптами. '''Перевірити на смоук-тесті''' я не мав змоги — це єдине непідтверджене припущення в розділі. Якщо <code>@startgantt</code> не відрендериться, замінити діаграму 7.5.1 на <code><nowiki><graphviz></nowiki></code> або повернути ASCII-схему з історії правок.}}

=== Альтернативи та запасний варіант ===

{| class="wikitable"
! Варіант !! Оцінка
|-
| '''Extension:Diagrams ≥ 1.0.0''' ''(обрано)'' || Одне розширення на всі формати документа; не зберігає рендери як файли вікі; є дві реалізації сервісу рендерингу — PHP (Symfony) та '''Python''' (остання узгоджується зі стеком проєкту, розділ 4.3).
|-
| Extension:GraphViz + Extension:PlantUML окремо || '''Не рекомендується.''' Extension:GraphViz за даними трекера Wikimedia не супроводжується й потребує правок для роботи з актуальними версіями MediaWiki. Два розширення замість одного.
|-
| Mermaid (<code><nowiki><mermaid></nowiki></code> у складі Diagrams або Extension:Mermaid) || Рендериться на клієнті, не потребує бінарників на сервері. Але <code>erDiagram</code> Mermaid суттєво менш виразний за <code>entity</code> PlantUML: ER-моделі розділу 9 містять типи, ознаки PK/FK та коментарі до полів — це не переноситься без втрат. Придатний для простих схем (5.1, Д.1).
|-
| Без розширень || Блоки діаграм відображатимуться як вихідний текст. '''Документ втрачає 9 із 12 схем''' — на відміну від версій ≤ 1.2, ASCII-дублів більше немає (див. нижче).
|}

=== Що навмисно залишено ASCII-схемами ===

Після переходу на Diagrams дублювання «діаграма + ASCII» прибрано: воно розходилося при правках. Але 8 блоків <code><nowiki><pre></nowiki></code> залишено свідомо — для них Diagrams не дає виграшу:

{| class="wikitable"
! Розділ !! Блок !! Чому не діаграма
|-
| 6.8.1–6.8.3 || Макети конструктора || PlantUML має <code>@startsalt</code> для wireframe'ів, але ASCII тут '''комунікує краще''': він явно читається як ескіз і не створює хибного враження затвердженого дизайну. Salt додає рендер-ризик без користі.
|-
| 7.4.1 || Timeline підсумків і ТА || Схема несе формулу («Залишок = Підсумок(P) + Σ рухів») поряд із віссю часу. Gantt це не передає, а <code>@startuml</code> timing — надмірність.
|-
| Д.9 || Наскрізний розрахунок ЗП || Це покроковий наратив із числами, а не структура. Діаграма не додасть змісту.
|-
| Д.11, Е.8 || Чек-лист і дерево репозиторію || Список і файлове дерево. <code><nowiki><pre></nowiki></code> — рівно те, що треба.
|}

= 2. Терміни, визначення та скорочення =

{| class="wikitable"
! Термін !! Визначення
|-
| '''Регістр''' || Об'єкт метаданих, призначений для зберігання та накопичення структурованої облікової інформації у вигляді записів фіксованої структури, з механізмами агрегації, зрізів і транзакційного зв'язку з документами-реєстраторами.
|-
| '''РВ''' || Регістр відомостей (аналог «Регистр сведений»).
|-
| '''РН''' || Регістр накопичення (аналог «Регистр накопления»).
|-
| '''РБ''' || Регістр бухгалтерії (аналог «Регистр бухгалтерии»).
|-
| '''РР''' || Регістр розрахунку (аналог «Регистр расчёта»).
|-
| '''Вимірювання''' (Dimension) || Поле регістру, що визначає розріз аналітики; входить у ключ запису/підсумку.
|-
| '''Ресурс''' (Resource) || Поле регістру, значення якого підсумовується (для РН/РБ/РР) або зберігається як значення (для РВ).
|-
| '''Реквізит''' (Attribute) || Довідкове поле запису, що не бере участі в ключі та не агрегується.
|-
| '''Реєстратор''' (Recorder) || Документ, який породив набір записів регістру та володіє ним.
|-
| '''Рухи''' (Movements) || Записи регістру, підпорядковані конкретному реєстратору.
|-
| '''Набір записів''' (RecordSet) || Прикладний об'єкт для читання/запису групи записів регістру за заданим відбором.
|-
| '''Підсумки''' (Totals) || Попередньо розраховані агрегати (залишки/обороти), що зберігаються в окремих таблицях.
|-
| '''ТА''' || Точка актуальності підсумків — момент часу, до якого підсумки розраховані.
|-
| '''Зріз останніх''' (SliceLast) || Вибірка останніх за періодом записів РВ у розрізі кожної комбінації вимірювань.
|-
| '''Субконто''' (ExtDimension, ED) || Додатковий розріз аналітики бухгалтерського рахунку.
|-
| '''ПВР''' || План видів розрахунку.
|-
| '''Витіснення''' || Механізм РР: запис із вищим пріоритетом скорочує фактичний період дії запису з нижчим.
|-
| '''Перерахунок''' (Recalculation) || Підпорядкований РР об'єкт, що реєструє записи, які потребують повторного розрахунку.
|-
| '''Віртуальна таблиця''' || Обчислювана таблиця в мові запитів, що не має фізичного відповідника (Залишки, Обороти, ЗрізОстанніх тощо).
|}

= 3. Призначення, цілі та підстава розробки =

== 3.1. Підстава ==
Поточна модель K2 ERP не має уніфікованого декларативного механізму накопичувального обліку. Регістроподібні структури реалізуються ''ad hoc'' — окремими таблицями та процедурами під кожну прикладну задачу, що спричиняє:
* дублювання коду розрахунку залишків та оборотів;
* відсутність гарантованої узгодженості «документ ↔ рухи»;
* деградацію продуктивності на великих обсягах (повний перерахунок з початку обліку);
* високу вартість введення нової аналітики (зміна схеми БД + правка десятків процедур).

== 3.2. Мета ==
Створити в K2 ERP підсистему '''декларативно описуваних регістрів''' чотирьох типів, функціонально еквівалентну механізму регістрів «1С:Підприємство 8.3», з автоматичною генерацією схеми БД, підтримкою підсумків, віртуальних таблиць у мові запитів і транзакційного проведення документів.

== 3.3. Цілі проєкту (вимірювані) ==
{| class="wikitable"
! № !! Ціль !! Критерій досягнення
|-
| Ц1 || Декларативне визначення регістру || Новий регістр з 5 вимірюваннями та 3 ресурсами створюється в конструкторі без написання коду; DDL генерується автоматично.
|-
| Ц2 || Автоматична агрегація || Залишки/обороти доступні запитом без ручних процедур перерахунку.
|-
| Ц3 || Продуктивність || Отримання залишків на дату за таблицею 1 млрд рухів — ≤ 200 мс (P95) на еталонному стенді.
|-
| Ц4 || Цілісність || Неможливість існування рухів без активного реєстратора (100 % сценаріїв у тесті цілісності).
|-
| Ц5 || Міграція || Перенесення ≥ 90 % наявних «регістроподібних» структур K2 на новий механізм без втрати даних.
|}

== 3.4. Що НЕ входить до обсягу (Out of scope) ==
* Механізм розподілених інформаційних баз / реплікації рухів (окреме ТЗ).
* Візуальний конструктор звітів поверх регістрів (окреме ТЗ, залежність).
* OLAP-куби та зовнішні аналітичні вітрини.
* Автоматичне перенесення прикладного коду замовника (тільки дані + мапінг).

= 4. Припущення та обмеження щодо платформи K2 ERP =

{{Note|Розділ фіксує припущення, які '''обов'язково''' підлягають верифікації з архітектором платформи до затвердження ТЗ. Місця, що потребують уточнення, позначені як ''[уточнити]''.}}

== 4.1. Припущення щодо платформи ==

{| class="wikitable"
! № !! Припущення !! Наслідок для ТЗ
|-
| П1 || K2 ERP має підсистему метаданих із власним репозиторієм об'єктів (документи, довідники, перерахування) і механізмом версіонування конфігурації. || Регістр вбудовується як новий '''рід''' об'єкта метаданих у наявний репозиторій (розділ 6).
|-
| П2 || Об'єкти-документи мають унікальний ідентифікатор посилання (GUID/UUID) та проведення як окрему операцію. || Реєстратор адресується парою «код типу + UUID» (розділ 8.2).
|-
| П3 || Платформа має власну мову запитів або транслятор у SQL. || Віртуальні таблиці реалізуються на рівні транслятора (розділ 7.6). Якщо мови запитів немає — потрібен окремий етап Е0 (розділ 14).
|-
| П4 || Цільова СКБД підтримує <code>MERGE</code>/<code>INSERT ... ON CONFLICT</code>, віконні функції, часткові та покривні індекси. || Алгоритми підсумків (розділ 10) використовують ці можливості.
|-
| П5 || Прикладний код виконується на сервері застосунків із керованими транзакціями. || Проведення документа — одна транзакція БД (розділ 7.1).
|-
| П6 || Максимальна довжина ідентифікатора об'єкта БД — 63 символи (PostgreSQL). || Фізичні імена таблиць будуються за сурогатним числовим кодом, а не за іменем регістру (розділ 8.1).
|-
| П7 || Ядро платформи розробляється на '''Python 3.12+'''; допускаються C-розширення (binary-драйвери) та, за потреби, власні нативні модулі. || Визначає стек (4.3) і архітектурні принципи АП-1…АП-6 (4.4). ''[верифікувати: greenfield чи є наявний Python-код K2]''
|-
| П8 || Прикладний (конфігураційний) код пишеться '''також на Python''' і виконується в тому самому процесі. || Породжує питання ізоляції та безпеки виконання довільного коду — '''відкрите питання В12'''. Якщо припущення хибне (потрібна вбудована мова) — обсяг Е1 зростає на ~2 чол.-міс.
|}

== 4.2. Обмеження ==

* О1. Зміна складу вимірювань/ресурсів існуючого регістру — операція реструктуризації з простоєм; онлайн-міграція не гарантується для таблиць > 100 млн записів.
* О2. Підсистема не гарантує коректність прикладної логіки проведення — лише цілісність механізму.
* О3. Мінімальна дискретність періоду — 1 секунда (тип <code>timestamp(0)</code>) ''[уточнити: чи потрібна мілісекундна]''.

== 4.3. Технологічний стек ==

{| class="wikitable"
! Шар !! Технологія !! Обґрунтування вибору
|-
| Мова ядра || '''Python 3.12+''' (цільова 3.12; щодо 3.13 — див. В14) || Рішення замовника. Наслідки — розділ 4.4.
|-
| Статична типізація || <code>mypy --strict</code> як gate у CI || Ядро метаданих у динамічній мові без статичної перевірки — неприйнятний ризик (Р11).
|-
| Опис і валідація метаданих || '''Pydantic v2''' || Маніфест регістру (розділ 6.7) стає типізованою моделлю: валідація, крос-полеві правила та JSON Schema для конструктора — «безкоштовно». Покриває ФТ-К-01. Приклад — Е.1.
|-
| Генерація DDL, абстракція діалектів СКБД || '''SQLAlchemy Core 2.x''' (''без ORM'') || Ключовий вибір. <code>MetaData</code>/<code>Table</code>/<code>Column</code> — готова модель схеми; діалекти PostgreSQL і MS SQL із коробки. Прямо закриває НФВ-16, НФВ-17 і знижує ризик Р7. Приклад — Е.2.
|-
| Міграції / реструктуризація || '''Alembic''' || Автогенерація <code>ALTER</code> при зміні складу полів (Е10, НФВ-13, НФВ-15).
|-
| Драйвери || '''psycopg 3''' (binary, pipeline mode) або <code>asyncpg</code>; <code>pyodbc</code> для MS SQL || Pipeline mode критичний для АП-1: пакетна вставка без round-trip на рядок.
|-
| Парсер мови запитів || '''lark''' (LALR) → AST → SQLAlchemy Core || Етап Е5. Дешевше за власний парсер; граматика декларативна. Ескіз — Е.4.
|-
| Гарячі шляхи || '''Cython''' / <code>mypyc</code>; за потреби '''Rust''' (PyO3 + maturin) || Тільки за результатами бенчмарку (АП-3, Р10, В13).
|-
| Сервер застосунків || FastAPI + uvicorn; окремий пул процесів для проведення || —
|-
| Паралелізм || '''Процеси''' + <code>asyncio</code> для IO. '''Потоки — ні''' (GIL) || Принцип АП-5.
|-
| Тестування || pytest, pytest-benchmark, '''hypothesis''' (property-based), testcontainers || Hypothesis обов'язковий для витіснення (Р5): інтервальна арифметика — ідеальний кандидат на property-based тести.
|-
| Профілювання || py-spy, scalene, <code>EXPLAIN (ANALYZE, BUFFERS)</code> || Етап Е11.
|-
| Збірка || uv, ruff, wheels із нативними розширеннями під усі цільові платформи || —
|}

'''Явні заборони:'''
* '''ORM SQLAlchemy не використовується.''' Регістри працюють наборами записів, а не об'єктами; identity map і lazy loading тут шкідливі й провокують порушення АП-1. Використовується '''лише Core'''.
* '''PyPy не розглядається''' — несумісність із binary-драйверами та нативними розширеннями.
* '''Free-threaded build (PEP 703)''' — моніторити, але не закладати в архітектуру (В14).

== 4.4. Наслідки вибору Python: архітектурні принципи ==

Python на CPU-навантаженні повільніший за компільовані мови приблизно в 30–80 разів. Проєктована архітектура цьому '''не суперечить''': основну роботу виконує СКБД, а ядро лише формує SQL. Але це вірно '''тільки за умови''' дотримання наведених принципів — їх порушення робить цілі НФВ недосяжними.

{| class="wikitable"
! ID !! Принцип !! Формулювання
|-
| '''АП-1''' || '''«Жодного рядка за раз»''' || '''Заборонено:''' цикл Python із запитом до БД усередині; вставка рухів по одному; читання підсумків по одному ключу. '''Обов'язково:''' <code>executemany</code> / <code>COPY</code> / pipeline, set-based <code>MERGE</code>, один запит на набір записів. Детектор порушень — Е.7.
|-
| '''АП-2''' || '''Ядро — оркестратор, СКБД — обчислювач''' || Python формує SQL і передає керування. Агрегація, з'єднання, сортування — в СКБД. Виняток — гарячі шляхи АП-4, де це неможливо.
|-
| '''АП-3''' || '''Гарячі шляхи ізольовані за інтерфейсом''' || Кожен кандидат на нативне переписування реалізується за <code>Protocol</code>-інтерфейсом з еталонною Python-реалізацією та бенчмарком у CI. Заміна на Cython/Rust не змінює виклик. Приклад — Е.5.
|-
| '''АП-4''' || '''Бюджет Python-часу зафіксовано''' || Див. 4.4.1. Перевищення бюджету — блокер приймання етапу.
|-
| '''АП-5''' || '''Паралелізм — процесами''' || GIL робить потоки марними для CPU-роботи. Проведення IO-bound → <code>asyncio</code>; масштабування — пулом процесів за кількістю ядер.
|-
| '''АП-6''' || '''Типізація на межах''' || <code>mypy --strict</code> на ядрі; Pydantic v2 на всіх межах. Динамічний доступ до полів регістру компенсується генерацією <code>.pyi</code>-стабів (ФТ-К-07, Е.6).
|}

=== 4.4.1. Бюджет Python-часу на гарячих шляхах (АП-4) ===

{| class="wikitable"
! Шлях !! Розділ !! Обсяг операцій !! Оцінка Python !! Ризик !! Мітигація
|-
| Формування рухів документа (100 рядків × 5 регістрів) || 7.1, Д.8 || ~500 конструювань об'єктів || 2–5 мс || Низький || —
|-
| Серіалізація рухів у пакетну вставку || 7.1 || ~500 кортежів || 1–3 мс || Низький || psycopg 3 pipeline / <code>COPY</code>
|-
| Оновлення підсумків || 10.2 || 1 SQL <code>MERGE</code> на регістр || ≈ 0 мс || Низький || set-based (Е.3)
|-
| Трансляція віртуальної таблиці || 7.3, 10.3 || парсинг + побудова AST || 1–10 мс || Середній || LRU-кеш скомпільованих запитів за хешем (текст + сигнатура параметрів)
|-
| '''Витіснення періодів дії''' || 10.4 || O(\|Z\|²) на ключ; 10 тис. ключів × ~10 записів ≈ 10<sup>6</sup> інтервальних операцій || '''1–3 с''' || '''Високий''' || Sweep-line O(n log n); ізоляція за АП-3; кандидат №1 на Cython/Rust; альтернатива — перенести в SQL на <code>daterange</code> + GiST (PostgreSQL)
|-
| '''Розрахунок ЗП''' || Д.9 || 80 тис. записів × формула || '''4–15 с''' || '''Високий''' || Заборона per-record запитів (АП-1); векторизація; кандидат №2 на нативний код
|-
| Реєстрація перерахунків || 10.5 || 1 SQL <code>INSERT … SELECT</code> || ≈ 0 мс || Низький || set-based
|-
| Генерація DDL, реструктуризація || 8, Е.2 || холодний шлях, разова операція || — || Низький || —
|}

=== 4.4.2. Висновок щодо НФВ ===

{| class="wikitable"
! НФВ !! Ціль !! Частка Python !! Вердикт
|-
| НФВ-01…03 (залишки, обороти) || 200 мс – 2 с || < 1 % (робота в СКБД) || '''Не залежить від мови ядра'''
|-
| НФВ-04 (проведення 100 рядків) || 300 мс || 5–15 мс ≈ '''5 %''' || Досяжно за дотримання АП-1
|-
| НФВ-05 (ОСВ) || 5 с || < 1 % || Не залежить від мови ядра
|-
| НФВ-06 (ЗП на 10 тис. осіб) || 10 хв || 4–15 с ≈ '''2,5 %''' || Досяжно; '''запас ×40'''
|-
| НФВ-07 (зріз останніх) || 500 мс || < 1 % || Не залежить від мови ядра
|-
| НФВ-08 (50 док/с) || — || 50 × 10 мс = 0,5 с CPU/с ≈ '''50 % одного ядра''' || Досяжно; пул процесів (АП-5)
|-
| НФВ-09 (перерахунок підсумків) || 4 год || < 1 % || Не залежить від мови ядра
|}

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

= 5. Класифікація регістрів =

== 5.1. Дерево типів ==

<graphviz>
digraph Registers {
rankdir=TB;
bgcolor="transparent";
node [shape=box, style="rounded,filled", fillcolor="#f5f5f5", fontname="Helvetica", fontsize=10];
edge [fontname="Helvetica", fontsize=8];

R [label="РЕГІСТР\n(абстрактний об'єкт метаданих)", fillcolor="#dbe9ff"];

RI [label="Регістр відомостей\n(РВ / Information)", fillcolor="#e8f5e9"];
RA [label="Регістр накопичення\n(РН / Accumulation)", fillcolor="#fff8e1"];
RB [label="Регістр бухгалтерії\n(РБ / Accounting)", fillcolor="#fce4ec"];
RC [label="Регістр розрахунку\n(РР / Calculation)", fillcolor="#ede7f6"];

R -> RI; R -> RA; R -> RB; R -> RC;

RI_np [label="Неперіодичний"];
RI_p [label="Періодичний"];
RI -> RI_np; RI -> RI_p;

RI_i [label="Незалежний\n(режим запису)", shape=note, fillcolor="#ffffff"];
RI_s [label="Підпорядкований\nреєстратору", shape=note, fillcolor="#ffffff"];
RI -> RI_i [style=dashed]; RI -> RI_s [style=dashed];

RA_b [label="Вид: Залишки\n(Balance)"];
RA_t [label="Вид: Обороти\n(Turnover)"];
RA -> RA_b; RA -> RA_t;

RB_c [label="З кореспонденцією\n(подвійний запис)"];
RB_n [label="Без кореспонденції\n(уніграфічний)"];
RB -> RB_c; RB -> RB_n;

RC_a [label="З періодом дії\n(+ витіснення)"];
RC_b [label="З базовим періодом\n(+ база розрахунку)"];
RC_g [label="З графіком часу"];
RC -> RC_a; RC -> RC_b; RC -> RC_g;
}
</graphviz>

== 5.2. Порівняльна матриця типів ==

{| class="wikitable"
! Характеристика !! РВ !! РН (Залишки) !! РН (Обороти) !! РБ !! РР
|-
| Ключ запису || Вимірювання (+Період) або Реєстратор+№ || Реєстратор+№ || Реєстратор+№ || Реєстратор+№ || Реєстратор+№
|-
| Незалежний запис || '''Так''' || Ні || Ні || Ні || Ні
|-
| Періодичність || Опційна || Обов'язкова (Період) || Обов'язкова || Обов'язкова || Обов'язкова
|-
| Ресурси підсумовуються || Ні || Так (±) || Так (+) || Так (Дт/Кт) || Так
|-
| Вид руху (Прихід/Витрата) || — || '''Так''' || — || Дт/Кт || —
|-
| Таблиця залишків || — || '''Так''' || — || '''Так''' || —
|-
| Таблиця оборотів || — || Так (опц.) || '''Так''' || Так || —
|-
| Зв'язок із планом рахунків || — || — || — || '''Так''' || —
|-
| Зв'язок із ПВР || — || — || — || — || '''Так'''
|-
| Період дії / витіснення || — || — || — || — || '''Так'''
|-
| Базовий період || — || — || — || — || '''Так'''
|-
| Графік часу || — || — || — || — || '''Так'''
|-
| Субконто || — || — || — || '''Так''' || —
|-
| Перерахунки || — || — || — || — || '''Так'''
|-
| Типові приклади || Курси валют, ціни, кадрова історія, графік роботи || Товари на складах, взаєморозрахунки || Продажі, витрати за статтями || Госпрозрахунковий, управлінський, податковий облік || Нарахування ЗП, утримання
|}

= 6. Метамодель: як регістр задається =

== 6.1. Місце в репозиторії метаданих ==

<graphviz>
digraph ConfigTree {
rankdir=LR; bgcolor="transparent"; ranksep=0.35; nodesep=0.12;
node [shape=box, style="filled,rounded", fontname="Helvetica", fontsize=9, height=0.28];
edge [arrowhead=none, color="#9e9e9e"];

CFG [label="Конфігурація K2 ERP", fillcolor="#cfd8dc"];

C1 [label="Довідники", fillcolor="#eceff1"];
C2 [label="Документи", fillcolor="#eceff1"];
C3 [label="Плани рахунків", fillcolor="#eceff1"];
C4 [label="Плани видів характеристик", fillcolor="#eceff1"];
C5 [label="Плани видів розрахунку", fillcolor="#eceff1"];
REG [label="РЕГІСТРИ", fillcolor="#1976d2", fontcolor="white"];

CFG -> C1; CFG -> C2; CFG -> C3; CFG -> C4; CFG -> C5; CFG -> REG [penwidth=2, color="#1976d2"];

RI [label="Регістри відомостей", fillcolor="#e8f5e9"];
RA [label="Регістри накопичення", fillcolor="#fff8e1"];
RB [label="Регістри бухгалтерії", fillcolor="#fce4ec"];
RC [label="Регістри розрахунку", fillcolor="#ede7f6"];
REG -> RI; REG -> RA; REG -> RB; REG -> RC;

RI1 [label="КурсиВалют", fillcolor="#ffffff"];
RI -> RI1;
RI1d [label="Вимірювання: Валюта", shape=note, fillcolor="#fafafa", fontsize=8];
RI1r [label="Ресурси: Курс, Кратність", shape=note, fillcolor="#fafafa", fontsize=8];
RI1 -> RI1d; RI1 -> RI1r;

RA1 [label="ТовариНаСкладах", fillcolor="#ffffff"];
RA -> RA1;
RA1d [label="Вимірювання:\lНоменклатура\lСклад\lПартія\l", shape=note, fillcolor="#fafafa", fontsize=8];
RA1r [label="Ресурси: Кількість, Сума", shape=note, fillcolor="#fafafa", fontsize=8];
RA1a [label="Реквізити: Коментар", shape=note, fillcolor="#fafafa", fontsize=8];
RA1x [label="Реєстратори:\lПрихіднаНакладна\lВидатковаНакладна\l…\l", shape=note, fillcolor="#fafafa", fontsize=8];
RA1 -> RA1d; RA1 -> RA1r; RA1 -> RA1a; RA1 -> RA1x;

RB1 [label="Госпрозрахунковий", fillcolor="#ffffff"];
RB -> RB1;
RB1d [label="Вимірювання:\lОрганізація (баланс.)\lПідрозділ (небаланс.)\l", shape=note, fillcolor="#fafafa", fontsize=8];
RB1r [label="Ресурси:\lСума (баланс.)\lКількість\lВалютнаСума\l", shape=note, fillcolor="#fafafa", fontsize=8];
RB1 -> RB1d; RB1 -> RB1r;
RB1 -> C3 [style=dotted, color="#c2185b", arrowhead=vee, label="ПланРахунків", fontsize=7];

RC1 [label="Нарахування", fillcolor="#ffffff"];
RC -> RC1;
RC1d [label="Вимірювання:\lСпівробітник (базове)\lПідрозділ\l", shape=note, fillcolor="#fafafa", fontsize=8];
RC1r [label="Ресурси:\lРезультат\lВідпрацьованоДнів\l", shape=note, fillcolor="#fafafa", fontsize=8];
RC1p [label="Перерахунки:\lПерерахунокЗаБазою\l", shape=note, fillcolor="#fafafa", fontsize=8];
RC1 -> RC1d; RC1 -> RC1r; RC1 -> RC1p;
RC1 -> C5 [style=dotted, color="#5e35b1", arrowhead=vee, label="ПВР", fontsize=7];
}
</graphviz>

== 6.2. Загальні властивості будь-якого регістру ==

{| class="wikitable"
! Властивість !! Тип !! Обов'язк. !! Опис / допустимі значення
|-
| <code>Ім'я</code> || Ідентифікатор || Так || Унікальне в межах роду. Латиниця/кирилиця, ≤ 80 симв., без пробілів.
|-
| <code>Синонім</code> || Рядок || Ні || Подання для користувача.
|-
| <code>Коментар</code> || Текст || Ні || —
|-
| <code>ВидРегістру</code> || Перелік || Так || <code>Відомостей</code> / <code>Накопичення</code> / <code>Бухгалтерії</code> / <code>Розрахунку</code>. '''Незмінна після створення.'''
|-
| <code>РежимЗапису</code> || Перелік || Так || <code>Незалежний</code> / <code>ПідпорядкованийРеєстратору</code>. Для РН/РБ/РР — примусово <code>ПідпорядкованийРеєстратору</code>.
|-
| <code>Періодичність</code> || Перелік || Так || <code>Неперіодичний</code>, <code>ВМежахСекунди</code>, <code>ВМежахДня</code>, <code>ВМежахМісяця</code>, <code>ВМежахКварталу</code>, <code>ВМежахРоку</code>, <code>ПоПозиціїРеєстратора</code>.
|-
| <code>Реєстратори</code> || Список посилань на типи документів || Умовно || Обов'язково для РН/РБ/РР та підпорядкованого РВ. Порожній список = регістр непридатний до запису.
|-
| <code>БлокуванняДаних</code> || Перелік || Ні || <code>Автоматичне</code> / <code>Кероване</code> (за замовчуванням <code>Кероване</code>).
|-
| <code>ВключатиДоЗвітів</code> || Булево || Ні || Показувати в універсальному конструкторі звітів.
|-
| <code>ПравоДоступуЗаЗамовчуванням</code> || Перелік || Ні || <code>Заборонено</code> / <code>Читання</code>.
|-
| <code>ВикористовуватиРLS</code> || Булево || Ні || Row-level security (розділ 7.9).
|-
| <code>Партиціонування</code> || Структура || Ні || <code>Немає</code> / <code>ЗаПеріодом(RANGE, крок)</code> / <code>ЗаВимірюванням(HASH, n)</code>.
|}

== 6.3. Поля регістру ==

Кожне поле має:
{| class="wikitable"
! Властивість !! Опис
|-
| <code>Ім'я</code>, <code>Синонім</code> || Ідентифікація.
|-
| <code>Роль</code> || <code>Вимірювання</code> / <code>Ресурс</code> / <code>Реквізит</code>.
|-
| <code>Тип</code> || Примітивний (<code>Число(p,s)</code>, <code>Рядок(n)</code>, <code>Дата</code>, <code>Булево</code>, <code>УНІ</code>), посилальний (<code>Довідник.X</code>, <code>Документ.Y</code>, <code>Перерахування.Z</code>, <code>ПланРахунків.A</code>, <code>ПланВидівХарактеристик.B</code>) або '''складений''' (список типів).
|-
| <code>Індексувати</code> || <code>Не індексувати</code> / <code>Індексувати</code> / <code>ІндексуватиЗДодаткомВимірювань</code>.
|-
| <code>Ведуче</code> (Master) || Тільки для вимірювань. Якщо <code>Істина</code> — записи регістру видаляються разом з об'єктом, на який посилається вимірювання; регістр показується у формі цього об'єкта.
|-
| <code>ОсновнийВідбір</code> || Брати участь у стандартному відборі форми списку.
|-
| <code>ЗаборонитиНезаповненіЗначення</code> || Валідація на запис.
|}

Специфічні прапорці полів по типах регістрів:

{| class="wikitable"
! Прапорець !! Застосовний до !! Опис
|-
| <code>Балансовий</code> || Ресурс/Вимірювання РБ || Ресурс бере участь у контролі рівності Дт=Кт; має єдине значення на запис (а не пару Дт/Кт). Вимірювання балансове — однакове для Дт і Кт.
|-
| <code>Облік</code> (AccountingFlag) || Ресурс РБ || Посилання на ознаку обліку рахунка з ПР; ресурс заповнюється, лише якщо ознака встановлена.
|-
| <code>ОблікСубконто</code> || Ресурс РБ || Посилання на ознаку обліку субконто (напр. кількісний облік у розрізі субконто).
|-
| <code>Базове</code> (BaseDimension) || Вимірювання РР || Використовується для зіставлення записів під час отримання бази розрахунку.
|-
| <code>ВикористовуватиПоточніЗначення</code> || Ресурс/Реквізит РР || —
|}

== 6.4. Специфічні властивості за типами ==

=== 6.4.1. Регістр відомостей ===
{| class="wikitable"
! Властивість !! Значення !! Примітка
|-
| <code>Періодичність</code> || Неперіодичний … ПоПозиціїРеєстратора || Визначає наявність поля <code>Період</code> і його гранулярність.
|-
| <code>РежимЗапису</code> || Незалежний / ПідпорядкованийРеєстратору || У незалежному ключ = (Період) + Вимірювання.
|-
| <code>ОсновнийВідбір</code> || —
|-
| <code>ДозволитиПідсумки</code> || — || У РВ підсумків немає; замість них — зрізи.
|}

'''Ключ унікальності:'''
* Незалежний неперіодичний: <code>UNIQUE(Вимірювання…)</code>
* Незалежний періодичний: <code>UNIQUE(Період, Вимірювання…)</code>
* Підпорядкований: <code>PK(Реєстратор, НомерРядка)</code>, унікальність за вимірюваннями '''не''' контролюється.

=== 6.4.2. Регістр накопичення ===
{| class="wikitable"
! Властивість !! Значення
|-
| <code>ВидРегістру</code> || <code>Залишки</code> / <code>Обороти</code>
|-
| <code>ДозволитиПідсумкиЗалишків</code> || Булево (тільки для виду «Залишки»)
|-
| <code>ДозволитиПідсумкиОборотів</code> || Булево
|-
| <code>ПеріодичністьПідсумківОборотів</code> || <code>День</code> / <code>Місяць</code> (тільки для виду «Обороти»)
|-
| <code>Агрегати</code> || Список визначень агрегатів (тільки для виду «Обороти»), див. 7.4.4
|-
| <code>РежимАгрегатів</code> || <code>Агрегати</code> / <code>Підсумки</code>
|}

=== 6.4.3. Регістр бухгалтерії ===
{| class="wikitable"
! Властивість !! Значення !! Примітка
|-
| <code>ПланРахунків</code> || Посилання на об'єкт «План рахунків» || '''Обов'язково.''' Незмінне після створення.
|-
| <code>Кореспонденція</code> || Булево || <code>Істина</code> → подвійний запис (поля <code>РахунокДт</code>/<code>РахунокКт</code>); <code>Хиба</code> → уніграфічний (<code>Рахунок</code> + <code>ВидРуху</code>).
|-
| <code>ДозволитиРозділенняПідсумків</code> || Булево
|-
| <code>МаксКількістьСубконто</code> || Число (успадковується з ПР) || Ліміт платформи: 5 ''[узгодити; 1С — 3 за замовчуванням, до 5]''
|}

Пов'язаний об'єкт '''План рахунків''' повинен підтримувати:
* ієрархію рахунків, <code>Код</code>, <code>Найменування</code>, <code>Вид</code> (Активний/Пасивний/Активно-пасивний);
* <code>Забалансовий</code> (булево);
* <code>Ознаки обліку</code> (набір булевих реквізитів, напр. «Кількісний», «Валютний»);
* табличну частину <code>ВидиСубконто</code> (ВидСубконто → ПВХ, ''Тільки обороти'', ''Підсумкова сума'', ознаки обліку субконто);
* <code>МаксКількістьСубконто</code>.

=== 6.4.4. Регістр розрахунку ===
{| class="wikitable"
! Властивість !! Значення !! Примітка
|-
| <code>ПланВидівРозрахунку</code> || Посилання || '''Обов'язково.'''
|-
| <code>Періодичність</code> || <code>День</code>/<code>Місяць</code>/<code>Квартал</code>/<code>Рік</code> || Період реєстрації.
|-
| <code>ПеріодДії</code> || Булево || Вмикає поля <code>ПеріодДіїПочаток/Кінець</code>, фактичні періоди дії та витіснення.
|-
| <code>БазовийПеріод</code> || <code>БезБазовогоПеріоду</code> / <code>ЗаПеріодДії</code> / <code>ЗаПеріодРеєстрації</code> || Режим отримання бази.
|-
| <code>Графік</code> || Посилання на РВ || Регістр-графік часу.
|-
| <code>ЗначенняГрафіка</code> || Ресурс регістру-графіка || Напр. «Значення» (1/0 — робочий день) або «Годин».
|-
| <code>ДатаГрафіка</code> || Вимірювання регістру-графіка типу <code>Дата</code> || —
|-
| <code>Перерахунки</code> || Список підпорядкованих об'єктів «Перерахунок» || Див. 7.5.3.
|}

Об'єкт '''Перерахунок''' (підпорядкований РР):
* <code>Ім'я</code>;
* <code>Вимірювання</code> — список, кожне зіставляється з вимірюванням основного РР (<code>ВимірюванняРегістру</code>);
* правило: перерахунок реєструє «об'єкт перерахунку» = (Реєстратор, ВидРозрахунку, Вимірювання…).

'''План видів розрахунку''' повинен підтримувати:
* <code>ВикористовуєПеріодДії</code>;
* табличні частини <code>БазовіВидиРозрахунку</code>, <code>ВитісняючіВидиРозрахунку</code>, <code>ВедучіВидиРозрахунку</code>;
* <code>ЗалежністьВідБази</code>: <code>НеЗалежить</code> / <code>ЗаПеріодДії</code> / <code>ЗаПеріодРеєстрації</code>.

== 6.5. Стандартні реквізити (генеруються автоматично) ==

{| class="wikitable"
! Реквізит !! РВ !! РН !! РБ !! РР !! Тип
|-
| <code>Період</code> || якщо періодичний || + || + || + (період реєстрації) || Дата/час
|-
| <code>Реєстратор</code> || якщо підпорядкований || + || + || + || Складене посилання (ДокументПосилання)
|-
| <code>НомерРядка</code> || якщо підпорядкований || + || + || + || Число(9,0)
|-
| <code>Активність</code> || якщо підпорядкований || + || + || + || Булево
|-
| <code>ВидРуху</code> || — || тільки «Залишки» || — || — || Перелік {Прихід, Витрата}
|-
| <code>Рахунок</code> || — || — || + (без кореспонденції) || — || ПланРахунківПосилання
|-
| <code>РахунокДт</code>, <code>РахунокКт</code> || — || — || + (з кореспонденцією) || — || ПланРахунківПосилання
|-
| <code>ВидРухуРахунку</code> || — || — || + (без кореспонденції) || — || Перелік {Дебет, Кредит}
|-
| <code>Субконто</code> (колекція) || — || — || + || — || Відповідність(ВидСубконто→Значення)
|-
| <code>ВидРозрахунку</code> || — || — || — || + || ПВРПосилання
|-
| <code>ПеріодДіїПочаток</code>, <code>ПеріодДіїКінець</code> || — || — || — || + (якщо ПеріодДії) || Дата
|-
| <code>БазовийПеріодПочаток</code>, <code>БазовийПеріодКінець</code> || — || — || — || + (якщо БазовийПеріод) || Дата
|-
| <code>Сторно</code> || — || — || — || + || Булево
|}

== 6.6. Кількісні обмеження метамоделі ==

{| class="wikitable"
! Параметр !! Ліміт !! Примітка
|-
| Кількість вимірювань || 20 || Понад 8 — попередження конструктора (деградація підсумків)
|-
| Кількість ресурсів || 20 ||
|-
| Кількість реквізитів || 30 ||
|-
| Кількість типів у складеному типі поля || 32 ||
|-
| Кількість реєстраторів || Не обмежено ||
|-
| Максимум субконто на рахунок || 5 ||
|-
| Довжина ключа підсумків || ≤ 900 байт (обмеження індексу MS SQL) || Валідація в конструкторі
|-
| Глибина періодичності підсумків || День / Місяць || Тиждень/Квартал — не підтримуються (обчислюються згортанням)
|}

== 6.7. Декларативний опис (DSL) ==

Регістр зберігається в репозиторії у вигляді XML/YAML-маніфесту. Приклад:

<syntaxhighlight lang="yaml">
# --- Регістр накопичення (вид: Залишки) ---
register:
name: ТовариНаСкладах
kind: Accumulation
accumulationKind: Balance
synonym: "Товари на складах"
periodicity: WithinSecond
writeMode: SubordinateToRecorder
enableBalanceTotals: true
enableTurnoverTotals: true
partitioning: { mode: RangeByPeriod, step: month }

dimensions:
- { name: Номенклатура, type: "Довідник.Номенклатура", master: true, index: true }
- { name: Склад, type: "Довідник.Склади", master: true, index: true }
- { name: Партія, type: ["Документ.ПрихіднаНакладна", "Документ.ВведенняЗалишків"], index: false }
- { name: Характеристика, type: "ПланВидівХарактеристик.Характеристики", nullable: true }

resources:
- { name: Кількість, type: "Число(15,3)" }
- { name: Сума, type: "Число(15,2)" }

attributes:
- { name: Коментар, type: "Рядок(200)" }

recorders:
- Документ.ПрихіднаНакладна
- Документ.ВидатковаНакладна
- Документ.ПереміщенняТоварів
- Документ.Інвентаризація
</syntaxhighlight>

<syntaxhighlight lang="yaml">
# --- Регістр відомостей (періодичний, незалежний) ---
register:
name: КурсиВалют
kind: Information
periodicity: WithinDay
writeMode: Independent
dimensions:
- { name: Валюта, type: "Довідник.Валюти", master: true }
resources:
- { name: Курс, type: "Число(15,4)" }
- { name: Кратність, type: "Число(10,0)", default: 1 }
</syntaxhighlight>

<syntaxhighlight lang="yaml">
# --- Регістр бухгалтерії ---
register:
name: Госпрозрахунковий
kind: Accounting
chartOfAccounts: ПланРахунків.Госпрозрахунковий
correspondence: true
periodicity: WithinSecond
dimensions:
- { name: Організація, type: "Довідник.Організації", balance: true }
- { name: Підрозділ, type: "Довідник.Підрозділи", balance: false }
resources:
- { name: Сума, type: "Число(15,2)", balance: true }
- { name: Кількість, type: "Число(15,3)", balance: false, accountingFlag: Кількісний }
- { name: ВалютнаСума, type: "Число(15,2)", balance: false, accountingFlag: Валютний }
attributes:
- { name: Зміст, type: "Рядок(255)" }
- { name: Валюта, type: "Довідник.Валюти" }
recorders: [Документ.БухгалтерськаОперація, Документ.ПрихіднаНакладна]
</syntaxhighlight>

<syntaxhighlight lang="yaml">
# --- Регістр розрахунку ---
register:
name: Нарахування
kind: Calculation
calculationTypesPlan: ПланВидівРозрахунку.ОсновніНарахування
periodicity: Month
actionPeriod: true
basePeriod: ByActionPeriod
schedule:
register: РегістрВідомостей.ГрафікРоботи
valueResource: Значення
dateDimension: ДатаГрафіка
dimensions:
- { name: Співробітник, type: "Довідник.Співробітники", baseDimension: true, master: true }
- { name: Підрозділ, type: "Довідник.Підрозділи" }
resources:
- { name: Результат, type: "Число(15,2)" }
- { name: ВідпрацьованоДнів, type: "Число(5,0)" }
- { name: НормаДнів, type: "Число(5,0)" }
recalculations:
- name: ПерерахунокЗаБазою
dimensions:
- { name: Співробітник, registerDimension: Співробітник }
recorders: [Документ.НарахуванняЗарплати]
</syntaxhighlight>

{{Note|Розширений каталог із 17 прикладів регістрів усіх типів і підвидів — з деклараціями, даними у фізичних таблицях, запитами, наскрізними сценаріями та антипатернами — див. '''Додаток Д'''.}}

== 6.8. UI конструктора метаданих ==

=== 6.8.1. Загальний макет ===
<pre>
┌─ Конфігуратор K2 ERP ─────────────────────────────────────────────────────────┐
│ Файл Правка Конфігурація Адміністрування Сервіс Довідка │
├──────────────────────┬────────────────────────────────────────────────────────┤
│ Дерево конфігурації │ Регістр накопичення: ТовариНаСкладах │
│ │ ┌──────┬─────────┬──────────┬──────────┬───────────┐ │
│ ▾ Регістри │ │Основ.│Дані │Реєстратор│Форми │Права │ │
│ ▸ відомостей │ └──────┴─────────┴──────────┴──────────┴───────────┘ │
│ ▾ накопичення │ │
│ ▾ ТовариНаСклад. │ Ім'я [ТовариНаСкладах.............] │
│ ▾ Вимірювання │ Синонім [Товари на складах...........] │
│ Номенклат. │ Коментар [.............................] │
│ Склад │ │
│ Партія │ Вид регістру ( ) Обороти (•) Залишки │
│ ▾ Ресурси │ Періодичність [ У межах секунди ▾] │
│ Кількість │ Режим запису [ Підпорядкований реєстратору ▾] │
│ Сума │ │
│ ▸ Реквізити │ ☑ Дозволити підсумки залишків │
│ ▸ Форми │ ☑ Дозволити підсумки оборотів │
│ ▸ Взаєморозрах. │ Періодичність підсумків оборотів [Місяць ▾] │
│ ▸ бухгалтерії │ ☐ Дозволити розділення підсумків │
│ ▸ розрахунку │ │
│ │ Блокування даних [Кероване ▾] │
│ │ Партиціонування [За періодом, крок: місяць ▾] │
│ │ │
│ │ [ Конструктор рухів... ] [ Перевірити ] [ Закрити ] │
├──────────────────────┴────────────────────────────────────────────────────────┤
│ ⚠ Попередження: 4 вимірювання + місячні підсумки → оцінка таблиці підсумків │
│ ~ 12 млн записів/рік. Розгляньте виключення вимірювання «Партія» з підсумків.│
└───────────────────────────────────────────────────────────────────────────────┘
</pre>

=== 6.8.2. Палітра властивостей поля ===
<pre>
┌─ Властивості: Вимірювання «Партія» ────────────────┐
│ Ім'я [Партія...................] │
│ Синонім [Партія...................] │
│ Тип [Складений тип........ [...]]│
│ ├ Документ.ПрихіднаНакладна │
│ └ Документ.ВведенняЗалишків │
│ Індексувати [Не індексувати ▾] │
│ ☐ Ведуче │
│ ☐ Основний відбір │
│ ☐ Заборонити незаповнені значення │
│ ☑ Використовувати в підсумках │
│ Подання │
│ Підказка [Партія товару...........] │
└────────────────────────────────────────────────────┘
</pre>

=== 6.8.3. Вкладка «Реєстратори» ===
<pre>
┌─ ТовариНаСкладах → Реєстратори ────────────────────────────┐
│ ☑ Документ.ПрихіднаНакладна │
│ ☑ Документ.ВидатковаНакладна │
│ ☑ Документ.ПереміщенняТоварів │
│ ☑ Документ.Інвентаризація │
│ ☐ Документ.Замовлення │
│ ☐ Документ.РахунокНаОплату │
│ [Позначити всі] [Зняти]│
│ ───────────────────────────────────────────────────────── │
│ ⓘ Знімання прапорця для документа, що має рухи, вимагає │
│ очищення рухів. Знайдено рухів: 0 │
└────────────────────────────────────────────────────────────┘
</pre>

=== 6.8.4. Вимоги до конструктора ===
* ФТ-К-01. Валідація метаопису в реальному часі з переліком помилок/попереджень.
* ФТ-К-02. Попередній перегляд згенерованого DDL (кнопка «Показати SQL»).
* ФТ-К-03. Калькулятор оцінки обсягу таблиць підсумків (добуток кардинальностей вимірювань × кількість періодів).
* ФТ-К-04. Заборона неприпустимих комбінацій (напр. «Незалежний» + «Регістр накопичення»).
* ФТ-К-05. «Конструктор рухів» — генерація коду формування рухів за табличною частиною документа.
* ФТ-К-06. Порівняння/об'єднання конфігурацій має коректно обробляти об'єкти-регістри.
* ФТ-К-07. '''Генерація <code>.pyi</code>-стабів''' для кожного регістру за метаописом. Прикладний код звертається до полів динамічно (<code>__getattr__</code>), що недоступне для <code>mypy</code>; згенеровані стаби повертають статичну перевірку. Перегенеровуються при кожній зміні метаданих, перевіряються в CI (див. Е.6). ''Вимога специфічна для Python, аналога в 1С не має.''

= 7. Функціональні вимоги =

== 7.1. Набір записів і проведення документа ==

'''ФТ-01.''' Платформа надає прикладний об'єкт <code>НабірЗаписів</code> для кожного регістру з властивостями: <code>Відбір</code>, <code>Записувати</code>, і методами <code>Прочитати()</code>, <code>Записати(Заміщати)</code>, <code>Очистити()</code>, <code>ЗаблокуватиДляЗміни()</code>, <code>Вивантажити()</code>, <code>Завантажити()</code>.

'''ФТ-02.''' Для документа доступна колекція <code>Рухи</code> з наборами записів усіх регістрів, де документ вказано реєстратором.

'''ФТ-03. Сценарій проведення:'''

<uml>
@startuml
skinparam monochrome false
skinparam shadowing false
actor Користувач
participant "Форма\nдокумента" as UI
participant "Об'єкт\nДокумент" as Doc
participant "Менеджер\nпроведення" as PM
participant "Набори\nзаписів" as RS
database "СКБД" as DB

Користувач -> UI: Провести
UI -> Doc: Записати(РежимЗапису.Проведення)
activate Doc
Doc -> PM: НачатьТранзакцию()
PM -> DB: BEGIN
Doc -> Doc: ПередЗаписью()
Doc -> DB: UPDATE doc SET Проведений=1
Doc -> Doc: ОбработкаПроведения(Отказ, Режим)
note right of Doc
Прикладний код:
Рухи.ТовариНаСкладах.Записувати = Істина;
Рух = Рухи.ТовариНаСкладах.Добавить();
Рух.ВидРуху = ВидРухуНакопичення.Витрата;
...
// контроль залишків (оперативне проведення)
end note
Doc -> RS: (формування рухів у пам'яті)
Doc -> PM: ЗаписатьДвижения()
PM -> RS: для кожного НЗ з Записувати=Істина
RS -> DB: DELETE FROM rg_a_0012 WHERE rec_ref = :doc
RS -> DB: INSERT INTO rg_a_0012 (...) VALUES (...)
RS -> PM: ОновитиПідсумки(delta)
PM -> DB: MERGE rg_a_0012_tb (див. розд. 10.2)
Doc -> Doc: ПриЗаписи() / ПослеЗаписи()
alt Відмова = Хиба
PM -> DB: COMMIT
PM --> UI: Успіх
else Відмова = Істина або виключення
PM -> DB: ROLLBACK
PM --> UI: Помилка "Документ не проведено: ..."
end
deactivate Doc
@enduml
</uml>

'''ФТ-04.''' Запис набору записів у режимі <code>Заміщати = Істина</code> (за замовчуванням для рухів) виконує <code>DELETE</code> усіх записів за відбором + <code>INSERT</code> нових — атомарно.

'''ФТ-05.''' Скасування проведення документа: усі набори записів за реєстратором очищуються, підсумки коригуються, документ отримує <code>Проведений = Хиба</code>.

'''ФТ-06.''' Видалення документа-реєстратора (у т.ч. позначеного на видалення) '''зобов'язане''' каскадно видалити всі його рухи в межах однієї транзакції. Реалізація — на рівні платформи (не FK, оскільки посилання поліморфне) + фонова перевірка цілісності (розділ 7.10).

'''ФТ-07.''' Режими проведення:
{| class="wikitable"
! Режим !! Умова !! Поведінка
|-
| '''Оперативне''' || Дата документа = поточна дата, документ у межах «оперативної точки» || Дозволено контроль залишків «на зараз»; дата може перепризначатися на поточну.
|-
| '''Неоперативне''' || Дата в минулому/майбутньому або документ перепроводиться || Контроль залишків виконується на дату документа; можливий негативний залишок за налаштуванням.
|}

== 7.2. Активність записів ==
'''ФТ-08.''' Реквізит <code>Активність = Хиба</code> означає, що запис фізично існує, але '''не''' впливає на підсумки та не потрапляє до віртуальних таблиць.
'''ФТ-09.''' Зміна активності будь-якого запису тягне коригування підсумків.
'''ФТ-10.''' Скасування проведення документа переводить усі його записи в <code>Активність = Хиба</code> '''або''' видаляє їх — залежно від налаштування регістру <code>ПоведінкаПриСкасуванні</code> (<code>Видаляти</code> — за замовчуванням / <code>Деактивувати</code>).

== 7.3. Віртуальні таблиці ==

'''ФТ-11.''' Мова запитів надає для кожного регістру набір віртуальних таблиць. Транслятор перетворює звернення до них на SQL із використанням таблиць підсумків та «живих» рухів після ТА.

{| class="wikitable"
! Регістр !! Віртуальна таблиця !! Параметри !! Повертає
|-
| rowspan="3" | '''РВ''' || <code>ЗрізОстанніх</code> || (Період, Умова) || Останній запис на кожну комбінацію вимірювань з періодом ≤ Період
|-
| <code>ЗрізПерших</code> || (Період, Умова) || Перший запис з періодом ≥ Період
|-
| ''(основна)'' || — || Усі записи
|-
| rowspan="4" | '''РН.Залишки''' || <code>Залишки</code> || (Період, Умова) || Вимірювання + <code><Ресурс>Залишок</code>
|-
| <code>Обороти</code> || (Початок, Кінець, Періодичність, Умова) || <code><Ресурс>Прихід</code>, <code><Ресурс>Витрата</code>, <code><Ресурс>Оборот</code>
|-
| <code>ЗалишкиІОбороти</code> || (Початок, Кінець, Періодичність, МетодДоповнення, Умова) || <code><Р>ПочатковийЗалишок</code>, <code><Р>Прихід</code>, <code><Р>Витрата</code>, <code><Р>Оборот</code>, <code><Р>КінцевийЗалишок</code>
|-
| ''(основна)'' || — || Рухи
|-
| '''РН.Обороти''' || <code>Обороти</code> || (Початок, Кінець, Періодичність, Умова) || <code><Ресурс>Оборот</code>
|-
| rowspan="6" | '''РБ''' || <code>Залишки</code> || (Період, УмоваРахунку, Субконто, Умова) || <code><Р>Залишок</code>, <code><Р>ЗалишокДт</code>, <code><Р>ЗалишокКт</code>
|-
| <code>Обороти</code> || (Початок, Кінець, Періодичність, УмоваРахунку, Субконто, Умова, УмоваКорРахунку, КорСубконто) || <code><Р>Оборот</code>, <code><Р>ОборотДт</code>, <code><Р>ОборотКт</code>
|-
| <code>ЗалишкиІОбороти</code> || (…) || Повний набір
|-
| <code>ОборотиДтКт</code> || (Початок, Кінець, Періодичність, УмоваРахункуДт, СубконтоДт, УмоваРахункуКт, СубконтоКт) || Кореспонденції
|-
| <code>ДвиженияССубконто</code> || (Початок, Кінець, УмоваРахунку, Субконто, Умова) || Рухи з розшифровкою субконто
|-
| <code>Субконто</code> || (Умова, Порядок…) || Значення субконто записів
|-
| rowspan="4" | '''РР''' || <code>ДаніГрафіка</code> || (Умова) || <code>ЗначенняПеріодуДії</code>, <code>ЗначенняПеріодуРеєстрації</code>, <code>ЗначенняБазовогоПеріоду</code>, <code>ЗначенняФактичногоПеріодуДії</code>
|-
| <code>ФактичнийПеріодДії</code> || (Умова) || Записи з фактичними (після витіснення) межами
|-
| <code>БазаРозрахунку</code> || (ВимірюванняБази, ВимірюванняОсновногоРегістру, Розрізи, ВидиРозрахунку, Умова) || Агреговані значення ресурсів базових видів розрахунку
|-
| ''(основна)'' || — || Рухи
|}

'''ФТ-12.''' Приклад запиту:
<syntaxhighlight lang="sql">
ВИБРАТИ
Залишки.Номенклатура,
Залишки.Склад,
Залишки.КількістьЗалишок,
Обороти.КількістьПрихід,
Обороти.КількістьВитрата
З
РегістрНакопичення.ТовариНаСкладах.ЗалишкиІОбороти(
&ПочатокПеріоду,
&КінецьПеріоду,
Місяць,
Рух,
Склад = &Склад
І Номенклатура В ІЄРАРХІЇ (&ГрупаНоменклатури)
) ЯК Залишки
</syntaxhighlight>

'''ФТ-13.''' Параметри віртуальних таблиць '''зобов'язані''' транслюватися у <code>WHERE</code> підзапиту до звернення до підсумків (push-down), а не фільтруватися після агрегації.

== 7.4. Підсумки ==

=== 7.4.1. Модель підсумків залишків ===
Таблиця залишків зберігає '''кумулятивний залишок на початок кожного періоду''' + спеціальний рядок «підсумок за всі періоди» з <code>period = '5999-11-01'</code> (маркер MAXPERIOD).

<pre>
Таблиця підсумків (місячна) ТА
┌────┬────┬────┬────┬────┐ ▼
─────┬────┬────┬───┴────┴────┴────┴────┴────┴────────────────────┬──────────►
│ │ │ 01.10 01.11 01.12 01.01 01.02 15.02 t
│ │ │ ● ● ● ● ●
│ │ │ бал. бал. бал. бал. бал.
└─ «живі» рухи ─┘
(сканування)
Залишок на 10.02 = Підсумок(01.02) + Σ рухів (01.02 … 10.02]
Залишок на 20.02 = Підсумок(01.02) + Σ рухів (01.02 … 20.02] // після ТА — теж
</pre>

'''ФТ-14.''' Регламентна операція «Перерахунок підсумків» перебудовує таблиці підсумків з нуля.
'''ФТ-15.''' Регламентна операція «Встановлення періоду розрахунку підсумків» переносить ТА вперед/назад.
'''ФТ-16.''' При записі рухів раніше ТА підсумки коригуються ''інкрементально'' (див. 10.2), без повного перерахунку.

=== 7.4.2. Розділення підсумків ===
'''ФТ-17.''' За увімкненого <code>ДозволитиРозділенняПідсумків</code> у таблиці підсумків додається колонка <code>splitter smallint</code>. Одночасні транзакції пишуть у різні «сплітери», що усуває конкуренцію за рядок. Читання агрегує по всіх сплітерах. Регламентне завдання зливає сплітери.

=== 7.4.3. Обороти ===
'''ФТ-18.''' Таблиця оборотів зберігає агрегати за календарний період (день або місяць — за налаштуванням), без кумуляції.

=== 7.4.4. Агрегати (тільки РН виду «Обороти») ===
'''ФТ-19.''' Агрегат — додаткова матеріалізована таблиця з підмножиною вимірювань і власною періодичністю (День/Місяць/Квартал/Рік). Оптимізатор запитів обирає найдешевший агрегат, що покриває запит.
'''ФТ-20.''' Режими: <code>Реальний час</code> (оновлюється при записі рухів) / <code>Регламентний</code> (оновлюється завданням; запит враховує рухи після дати актуальності агрегату).
'''ФТ-21.''' «Порадник агрегатів» аналізує статистику запитів і пропонує склад агрегатів (<code>ВизначитиОптимальніАгрегати()</code>).

== 7.5. Механіка регістру розрахунку ==

=== 7.5.1. Витіснення за періодом дії ===
'''ФТ-22.''' Якщо у ПВР для виду розрахунку A вказано B у складі «Витісняючі види розрахунку», то запис виду B скорочує фактичний період дії запису виду A на інтервал перетину.

<uml>
@startgantt
title Витіснення за періодом дії. Період реєстрації: січень 2026
caption Пріоритет витіснення: Лікарняний > Відпустка > Оклад
printscale daily
Project starts 2026-01-01

-- Заявлені періоди дії (rg_c_0040.act_begin / act_end) --
[Оклад] as [O1] starts 2026-01-01 and ends 2026-01-31
[Відпустка] as [V1] starts 2026-01-10 and ends 2026-01-17
[Лікарняний] as [L1] starts 2026-01-14 and ends 2026-01-22
[O1] is colored in #BBDEFB
[V1] is colored in #FFE0B2
[L1] is colored in #F8BBD0

-- Фактичні періоди дії після витіснення (rg_c_0040_ap) --
[Оклад, інтервал 0] as [O2] starts 2026-01-01 and ends 2026-01-09
[Оклад, інтервал 1] as [O3] starts 2026-01-23 and ends 2026-01-31
[Відпустка, інтервал 0] as [V2] starts 2026-01-10 and ends 2026-01-13
[Лікарняний, інтервал 0] as [L2] starts 2026-01-14 and ends 2026-01-22
[O2] is colored in #1976D2
[O3] is colored in #1976D2
[V2] is colored in #F57C00
[L2] is colored in #C2185B
@endgantt
</uml>

{{Note|'''Ключове спостереження.''' Один запис «Оклад» породжує '''два''' фактичні інтервали — саме тому <code>rg_c_0040_ap</code> має власний ключ <code>interval_no</code> і зв'язок 1:N із таблицею рухів (розділ 9.4). «Відпустка» скорочена з 17.01 до 13.01, бо лікарняний має вищий пріоритет.}}

'''ФТ-23.''' Фактичні періоди дії матеріалізуються у службовій таблиці <code>rg_c_<код>_ap</code> під час запису набору записів.
'''ФТ-24.''' Витіснення обчислюється в межах збігу '''усіх''' вимірювань регістру та перетину періодів реєстрації, визначених ПВР.

=== 7.5.2. Базовий період і база розрахунку ===
'''ФТ-25.''' Віртуальна таблиця <code>БазаРозрахунку</code> повертає суму ресурсів записів базових видів розрахунку, зіставлених за базовими вимірюваннями, з урахуванням режиму <code>ЗалежністьВідБази</code>:
* <code>ЗаПеріодДії</code> — беруться записи, чий '''період дії''' перетинається з базовим періодом поточного запису; результат пропорційно розподіляється за часткою перетину (за графіком, якщо заданий);
* <code>ЗаПеріодРеєстрації</code> — беруться записи, чий '''період реєстрації''' потрапляє в базовий період.

=== 7.5.3. Перерахунки ===
'''ФТ-26.''' При записі/зміні/видаленні запису базового виду розрахунку платформа '''автоматично''' формує записи у таблиці перерахунку для всіх залежних записів (за збігом вимірювань перерахунку та потраплянням у базовий період).
'''ФТ-27.''' Прикладний код читає перерахунок як набір записів, перепроводить відповідні документи та очищує оброблені записи.
'''ФТ-28.''' Перерахунок доступний як об'єкт для звіту «Документи до перерахунку».

=== 7.5.4. Графік часу ===
'''ФТ-29.''' Графік — це РВ з обов'язковим вимірюванням типу <code>Дата</code> та числовим ресурсом. Віртуальна таблиця <code>ДаніГрафіка</code> повертає суму значень графіка за відповідний період (дії / реєстрації / базовий / фактичний період дії).
'''ФТ-30.''' Якщо у графіку є додаткові вимірювання (напр. <code>ВидГрафіка</code>), вони зіставляються з однойменними реквізитами/вимірюваннями РР.

== 7.6. Прикладний API ==

<syntaxhighlight lang="python">
from datetime import date
from decimal import Decimal

from k2.registers import AccumulationMovementType, DataLock, DataLockMode, Registers
from k2.documents import Document, PostingContext

# ============ Регістр відомостей: незалежний запис ============
mgr = Registers.information("КурсиВалют")

rm = mgr.create_record_manager()
rm.Період = date(2026, 7, 17)
rm.Валюта = usd
rm.Курс = Decimal("41.85")
rm.Кратність = 1
rm.write(replace=True) # INSERT ... ON CONFLICT DO UPDATE

# зріз останніх
row = mgr.get_last(date.today(), {"Валюта": usd})
курс: Decimal = row.Курс

# АП-1: масове завантаження — ОДИН запит, а не цикл із write() усередині
rs = mgr.create_record_set()
rs.load([{"Період": d, "Валюта": v, "Курс": k, "Кратність": 1}
for d, v, k in nbu_rates]) # 3 000 курсів
rs.write(replace=True) # 1 × executemany, ~40 мс

# ============ Регістр накопичення: рухи документа ============
class ВидатковаНакладна(Document):

def on_posting(self, ctx: PostingContext) -> None:
rs = self.movements.ТовариНаСкладах
rs.write = True # набір буде записано наприкінці транзакції
rs.clear()

# АП-1: набір наповнюється генератором, запис — одним batch
rs.extend(
rs.new(
Період=self.Дата,
ВидРуху=AccumulationMovementType.EXPENSE,
Номенклатура=r.Номенклатура,
Склад=self.Склад,
Партія=r.Партія,
Кількість=r.Кількість,
Сума=r.Сума,
)
for r in self.Товари
)

# керовані блокування перед контролем залишків
with DataLock() as dl: # __enter__ виконує lock()
li = dl.add("РегістрНакопичення.ТовариНаСкладах.Залишки")
li.mode = DataLockMode.EXCLUSIVE
li.data_source = rs.unload("Номенклатура", "Склад")
li.use_from_data_source("Номенклатура", "Номенклатура")
li.use_from_data_source("Склад", "Склад")

rs.write_now() # примусовий запис до контролю
self._control_balances(ctx) # прикладна перевірка від'ємних залишків

# ============ Регістр бухгалтерії ============
def _accounting(self) -> None:
rs = self.movements.Госпрозрахунковий
rs.write = True
for r in self.Товари:
e = rs.add_accounting_entry(
Період=self.Дата,
Організація=self.Організація,
РахунокДт=accounts["281"],
РахунокКт=accounts["631"],
Сума=r.Сума,
КількістьДт=r.Кількість,
)
e.subconto_dt[ВидиСубконто.Номенклатура] = r.Номенклатура
e.subconto_dt[ВидиСубконто.Склади] = self.Склад
e.subconto_kt[ВидиСубконто.Контрагенти] = self.Контрагент

# ============ Регістр розрахунку ============
def _calculation(self) -> None:
rs = self.movements.Нарахування
rs.write = True
rs.append(rs.new(
ВидРозрахунку=calc_types["Оклад"],
Період=self.Дата, # період реєстрації
ПеріодДіїПочаток=date(2026, 7, 1),
ПеріодДіїКінець=date(2026, 7, 31),
БазовийПеріодПочаток=date(2026, 6, 1),
БазовийПеріодКінець=date(2026, 6, 30),
Співробітник=self.Співробітник,
Результат=Decimal(0), # заповниться після розрахунку
))
rs.write_now()

# Отримання даних графіка та бази розрахунку — запитом (розділ 7.3), не циклом.
</syntaxhighlight>

{{Note|'''Про кириличні ідентифікатори.''' Python 3 підтримує Unicode в іменах (PEP 3131), тому <code>rm.Валюта</code> і <code>rs.new(Номенклатура=…)</code> — валідний код; прикладна термінологія зберігається без транслітерації. '''Але''' доступ до полів регістру динамічний, тому <code>mypy</code> його не перевіряє — компенсується генерацією <code>.pyi</code>-стабів (ФТ-К-07, Додаток Е.6). Ключові слова API (<code>write</code>, <code>clear</code>, <code>new</code>) залишаються англійськими; змішування — свідомий компроміс, підлягає узгодженню (В15).}}

{{Note|'''Антипатерн, специфічний для Python (А-15).''' Спокуса написати <code>for r in self.Товари: rs.add(...).write()</code> дає 100 round-trip'ів до СКБД замість одного і збільшує час проведення з 300 мс до ~10 с. Це порушення АП-1 і найчастіша помилка при переході з ORM-мислення. Детектор — Е.7.}}

== 7.7. Блокування та конкурентність ==

{| class="wikitable"
! № !! Вимога
|-
| ФТ-31 || Режим керованих блокувань — за замовчуванням. Рівень ізоляції транзакцій: <code>READ COMMITTED</code> (PostgreSQL) / <code>READ COMMITTED SNAPSHOT</code> (MS SQL).
|-
| ФТ-32 || Об'єкт <code>DataLock</code> дозволяє встановити розділювальне/виняткове блокування на «простір» регістру за значеннями вимірювань (реалізація — <code>pg_advisory_xact_lock</code> за хешем ключа або <code>SELECT ... FOR UPDATE</code> по таблиці підсумків).
|-
| ФТ-33 || Запис рухів документа блокує тільки записи цього реєстратора (PK містить реєстратор першим).
|-
| ФТ-34 || Оновлення підсумків не повинно призводити до дедлоків: усі <code>MERGE</code>-операції в межах транзакції виконуються у детермінованому порядку сортування ключа.
|-
| ФТ-35 || Гарантія: паралельне проведення двох документів з різними наборами вимірювань не конкурує (за увімкненого розділення підсумків).
|-
| ФТ-36 || Таймаут очікування блокування — 20 с (налаштовується); при перевищенні — керована помилка з текстом конфліктного ключа.
|}

== 7.8. Права доступу ==

'''ФТ-37.''' Для регістру визначаються права: <code>Читання</code>, <code>Додавання</code>, <code>Зміна</code>, <code>Видалення</code>, <code>Перегляд</code>, <code>Редагування</code>, <code>ПереглядПідсумків</code>.
'''ФТ-38.''' Обмеження на рівні записів (RLS) задаються шаблоном умови по вимірюваннях; транслюються в <code>WHERE</code> усіх звернень, включно з віртуальними таблицями.
'''ФТ-39.''' ''Ризик:'' RLS на віртуальних таблицях залишків потребує узгодженості з підсумками. Рішення — RLS дозволено тільки по вимірюваннях, що входять до ключа підсумків; конструктор валідує це правило.

== 7.9. Журналювання, аудит, службові сервіси ==

'''ФТ-40.''' Реєстрація в журналі: перерахунок підсумків, зміна ТА, реструктуризація регістру, злиття сплітерів.
'''ФТ-41.''' Службовий сервіс «Перевірка цілісності регістрів»:
* «висячі» рухи (реєстратор не існує або не проведений);
* розбіжність підсумків і сум рухів (контрольний перерахунок у тіньову таблицю з порівнянням);
* некоректні фактичні періоди дії РР;
* для РБ — порушення рівності Дт = Кт за балансовим ресурсом у межах реєстратора.
'''ФТ-42.''' Звіт «Аналіз розміру регістрів»: кількість записів, розмір таблиць та індексів, дата останнього перерахунку підсумків.

= 8. Модель даних (як це виглядає в базі даних) =

== 8.1. Конвенції іменування ==

Фізичні імена '''не''' успадковують прикладні імена (обмеження довжини ідентифікатора, кирилиця, перейменування об'єктів). Ім'я будується за сурогатним кодом об'єкта метаданих <code><id></code> (4-значний hex/dec).

{| class="wikitable"
! Шаблон !! Призначення !! Приклад
|-
| <code>rg_i_<id></code> || Регістр відомостей — основна таблиця || <code>rg_i_0007</code>
|-
| <code>rg_a_<id></code> || Регістр накопичення — рухи || <code>rg_a_0012</code>
|-
| <code>rg_a_<id>_tb</code> || РН — підсумки залишків (Totals Balance) || <code>rg_a_0012_tb</code>
|-
| <code>rg_a_<id>_tt</code> || РН — підсумки оборотів (Totals Turnover) || <code>rg_a_0012_tt</code>
|-
| <code>rg_a_<id>_ag<n></code> || РН — агрегат № n || <code>rg_a_0031_ag1</code>
|-
| <code>rg_b_<id></code> || Регістр бухгалтерії — проводки || <code>rg_b_0020</code>
|-
| <code>rg_b_<id>_ed</code> || РБ — субконто (якщо винесено в дочірню таблицю) || <code>rg_b_0020_ed</code>
|-
| <code>rg_b_<id>_tb<k></code> || РБ — підсумки залишків за рівнем субконто k (0…N) || <code>rg_b_0020_tb2</code>
|-
| <code>rg_b_<id>_tt<k></code> || РБ — підсумки оборотів за рівнем субконто k || <code>rg_b_0020_tt1</code>
|-
| <code>rg_b_<id>_tc</code> || РБ — обороти між рахунками (кореспонденції) || <code>rg_b_0020_tc</code>
|-
| <code>rg_c_<id></code> || Регістр розрахунку — рухи || <code>rg_c_0040</code>
|-
| <code>rg_c_<id>_ap</code> || РР — фактичні періоди дії || <code>rg_c_0040_ap</code>
|-
| <code>rg_c_<id>_rc<m></code> || РР — перерахунок № m || <code>rg_c_0040_rc1</code>
|-
| <code>rg_<*>_<id>_opt</code> || Службова: ТА підсумків, налаштування || <code>rg_a_0012_opt</code>
|-
| <code>md_*</code> || Таблиці метаданих || <code>md_register</code>
|}

Колонки полів: <code>d<n></code> — вимірювання, <code>r<n></code> — ресурс, <code>a<n></code> — реквізит, де <code>n</code> — порядковий номер поля в метаописі (стабільний, не перевикористовується після видалення поля). Мапінг «прикладне ім'я ↔ фізична колонка» зберігається в <code>md_register_field</code>.

== 8.2. Типізація та зберігання значень ==

=== 8.2.1. Примітивні типи ===
{| class="wikitable"
! Тип платформи !! PostgreSQL !! MS SQL
|-
| Число(p,s) || <code>numeric(p,s)</code> || <code>numeric(p,s)</code>
|-
| Рядок(n) || <code>varchar(n)</code> || <code>nvarchar(n)</code>
|-
| Рядок(необмежена) || <code>text</code> || <code>nvarchar(max)</code>
|-
| Дата / ДатаЧас || <code>timestamp(0)</code> || <code>datetime2(0)</code>
|-
| Булево || <code>boolean</code> || <code>bit</code>
|-
| УНІ || <code>uuid</code> || <code>uniqueidentifier</code>
|}

=== 8.2.2. Посилальні типи ===
* '''Простий''' (один тип): одна колонка <code>d<n>_r uuid NOT NULL</code>, зовнішній ключ до таблиці об'єкта. Порожнє посилання = <code>'00000000-0000-0000-0000-000000000000'</code> (а не NULL — щоб зберегти семантику «пустого значення» у ключах підсумків).
* '''Складений''' (кілька типів / примітив + посилання): група колонок:

{| class="wikitable"
! Колонка !! Тип !! Опис
|-
| <code>d<n>_t</code> || <code>smallint</code> || Код типу: 1=Невизначено, 2=Булево, 3=Число, 4=Рядок, 5=Дата, ≥100 = <code>md_type.id</code> посилального типу
|-
| <code>d<n>_b</code> || <code>boolean</code> || Значення, якщо _t=2
|-
| <code>d<n>_n</code> || <code>numeric(38,10)</code> || Значення, якщо _t=3
|-
| <code>d<n>_s</code> || <code>varchar(N)</code> || Значення, якщо _t=4
|-
| <code>d<n>_d</code> || <code>timestamp(0)</code> || Значення, якщо _t=5
|-
| <code>d<n>_r</code> || <code>uuid</code> || Значення, якщо _t≥100
|}

{{Note|'''Проєктне рішення №1.''' Для складених типів обрано «широку» денормалізацію (кілька колонок), а не JSONB/варіант, тому що: (а) колонки індексуються та беруть участь у ключах підсумків; (б) B-tree по <code>(d1_t, d1_r)</code> дає range-scan, JSONB — ні; (в) сумісно з обома цільовими СКБД. Ціна — до 6 колонок на одне складене поле.}}

=== 8.2.3. Реєстратор ===
Завжди складений (будь-який з дозволених документів):
* <code>rec_t smallint NOT NULL</code> — код типу документа (<code>md_type.id</code>);
* <code>rec_r uuid NOT NULL</code> — посилання.

FK неможливий (поліморфізм) → цілісність забезпечується платформою + сервісом перевірки (ФТ-41).

=== 8.2.4. Маркери періодів ===
{| class="wikitable"
! Константа !! Значення !! Використання
|-
| <code>MINPERIOD</code> || <code>0001-01-01 00:00:00</code> || Нижня межа
|-
| <code>MAXPERIOD</code> || <code>5999-11-01 00:00:00</code> || Рядок «підсумок за всі періоди» в таблицях залишків
|}

== 8.3. Таблиці метаданих ==

<syntaxhighlight lang="sql">
-- ============ РЕПОЗИТОРІЙ МЕТАДАНИХ ============

CREATE TABLE md_type ( -- реєстр усіх типів конфігурації
id smallint PRIMARY KEY,
kind varchar(20) NOT NULL, -- Catalog|Document|Enum|ChartOfAccounts|ChartOfCalcTypes|Register|...
name varchar(80) NOT NULL,
table_name varchar(63),
UNIQUE (kind, name)
);

CREATE TABLE md_register (
id smallint PRIMARY KEY, -- = md_type.id
name varchar(80) NOT NULL UNIQUE,
synonym varchar(255),
comment text,
kind varchar(12) NOT NULL
CHECK (kind IN ('Information','Accumulation','Accounting','Calculation')),
-- загальні
write_mode varchar(24) NOT NULL DEFAULT 'SubordinateToRecorder'
CHECK (write_mode IN ('Independent','SubordinateToRecorder')),
periodicity varchar(24) NOT NULL DEFAULT 'Nonperiodical'
CHECK (periodicity IN ('Nonperiodical','WithinSecond','WithinDay','WithinMonth',
'WithinQuarter','WithinYear','ByRecorderPosition')),
lock_mode varchar(12) NOT NULL DEFAULT 'Managed',
use_rls boolean NOT NULL DEFAULT false,
partition_mode varchar(20) NOT NULL DEFAULT 'None',
partition_step varchar(10),
-- РН
accumulation_kind varchar(10) CHECK (accumulation_kind IN ('Balance','Turnover')),
enable_bal_totals boolean NOT NULL DEFAULT true,
enable_tno_totals boolean NOT NULL DEFAULT false,
tno_totals_period varchar(6) CHECK (tno_totals_period IN ('Day','Month')),
split_totals boolean NOT NULL DEFAULT false,
split_count smallint NOT NULL DEFAULT 1,
aggregates_mode varchar(10),
-- РБ
chart_of_accounts_id smallint REFERENCES md_type(id),
correspondence boolean NOT NULL DEFAULT true,
max_extdim_count smallint NOT NULL DEFAULT 3,
-- РР
calc_types_plan_id smallint REFERENCES md_type(id),
use_action_period boolean NOT NULL DEFAULT false,
base_period_mode varchar(24)
CHECK (base_period_mode IN ('None','ByActionPeriod','ByRegistrationPeriod')),
schedule_register_id smallint REFERENCES md_register(id),
schedule_value_field smallint,
schedule_date_field smallint,
-- службове
physical_table varchar(63) NOT NULL,
struct_version int NOT NULL DEFAULT 1,
CONSTRAINT chk_kind_props CHECK (
(kind = 'Accumulation' AND accumulation_kind IS NOT NULL) OR
(kind = 'Accounting' AND chart_of_accounts_id IS NOT NULL) OR
(kind = 'Calculation' AND calc_types_plan_id IS NOT NULL) OR
(kind = 'Information')
)
);

CREATE TABLE md_register_field (
id smallint NOT NULL, -- порядковий номер поля (стабільний)
register_id smallint NOT NULL REFERENCES md_register(id) ON DELETE CASCADE,
name varchar(80) NOT NULL,
synonym varchar(255),
role varchar(12) NOT NULL CHECK (role IN ('Dimension','Resource','Attribute')),
data_type_expr text NOT NULL, -- серіалізований опис типу (може бути складеним)
is_composite boolean NOT NULL DEFAULT false,
precision_ smallint,
scale_ smallint,
length_ int,
index_mode varchar(28) NOT NULL DEFAULT 'None'
CHECK (index_mode IN ('None','Index','IndexWithAddDimensions')),
is_master boolean NOT NULL DEFAULT false, -- «Ведуче»
in_default_filter boolean NOT NULL DEFAULT false,
deny_empty boolean NOT NULL DEFAULT false,
use_in_totals boolean NOT NULL DEFAULT true,
-- РБ
is_balance boolean NOT NULL DEFAULT false,
accounting_flag varchar(80),
extdim_flag varchar(80),
-- РР
is_base_dimension boolean NOT NULL DEFAULT false,
-- фізика
column_prefix varchar(8) NOT NULL, -- 'd3','r1','a2'
PRIMARY KEY (register_id, id),
UNIQUE (register_id, name)
);

CREATE TABLE md_register_recorder (
register_id smallint NOT NULL REFERENCES md_register(id) ON DELETE CASCADE,
doc_type_id smallint NOT NULL REFERENCES md_type(id),
PRIMARY KEY (register_id, doc_type_id)
);

CREATE TABLE md_register_aggregate (
id smallint NOT NULL,
register_id smallint NOT NULL REFERENCES md_register(id) ON DELETE CASCADE,
name varchar(80) NOT NULL,
periodicity varchar(8) NOT NULL CHECK (periodicity IN ('Day','Month','Quarter','Year')),
use_mode varchar(12) NOT NULL DEFAULT 'Auto',
is_realtime boolean NOT NULL DEFAULT false,
actual_upto timestamp(0),
physical_table varchar(63) NOT NULL,
PRIMARY KEY (register_id, id)
);
CREATE TABLE md_register_aggregate_dim (
register_id smallint NOT NULL,
aggregate_id smallint NOT NULL,
field_id smallint NOT NULL,
PRIMARY KEY (register_id, aggregate_id, field_id),
FOREIGN KEY (register_id, aggregate_id) REFERENCES md_register_aggregate(register_id, id) ON DELETE CASCADE
);

CREATE TABLE md_register_recalc (
id smallint NOT NULL,
register_id smallint NOT NULL REFERENCES md_register(id) ON DELETE CASCADE,
name varchar(80) NOT NULL,
physical_table varchar(63) NOT NULL,
PRIMARY KEY (register_id, id)
);
CREATE TABLE md_register_recalc_dim (
register_id smallint NOT NULL,
recalc_id smallint NOT NULL,
name varchar(80) NOT NULL,
reg_field_id smallint NOT NULL, -- вимірювання основного регістру
column_prefix varchar(8) NOT NULL,
PRIMARY KEY (register_id, recalc_id, name),
FOREIGN KEY (register_id, recalc_id) REFERENCES md_register_recalc(register_id, id) ON DELETE CASCADE
);
</syntaxhighlight>

== 8.4. Регістр відомостей ==

=== 8.4.1. Незалежний періодичний (приклад: КурсиВалют) ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_i_0007 (
period timestamp(0) NOT NULL, -- Період (усічений до дня: WithinDay)
d1_r uuid NOT NULL, -- Вимірювання «Валюта»
r1 numeric(15,4) NOT NULL, -- Ресурс «Курс»
r2 numeric(10,0) NOT NULL DEFAULT 1, -- Ресурс «Кратність»
CONSTRAINT pk_rg_i_0007 PRIMARY KEY (period, d1_r)
);
-- Індекс для зрізу останніх у розрізі вимірювання
CREATE INDEX ix_rg_i_0007_d1 ON rg_i_0007 (d1_r, period DESC) INCLUDE (r1, r2);
ALTER TABLE rg_i_0007 ADD CONSTRAINT fk_rg_i_0007_d1
FOREIGN KEY (d1_r) REFERENCES cat_0003(ref); -- Довідник.Валюти
</syntaxhighlight>

=== 8.4.2. Підпорядкований реєстратору ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_i_0008 (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
period timestamp(0) NOT NULL,
active boolean NOT NULL DEFAULT true,
d1_r uuid NOT NULL,
r1 numeric(15,2) NOT NULL,
CONSTRAINT pk_rg_i_0008 PRIMARY KEY (rec_t, rec_r, line_no)
);
CREATE INDEX ix_rg_i_0008_period ON rg_i_0008 (period, rec_t, rec_r, line_no);
CREATE INDEX ix_rg_i_0008_d1 ON rg_i_0008 (d1_r, period) WHERE active;
</syntaxhighlight>

=== 8.4.3. Незалежний неперіодичний ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_i_0009 (
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
r1 varchar(200),
CONSTRAINT pk_rg_i_0009 PRIMARY KEY (d1_r, d2_r)
);
</syntaxhighlight>

== 8.5. Регістр накопичення ==

=== 8.5.1. Таблиця рухів ===
<syntaxhighlight lang="sql">
-- ТовариНаСкладах: dims = Номенклатура(d1), Склад(d2), Партія(d3, складений), Характеристика(d4)
-- res = Кількість(r1), Сума(r2); attr = Коментар(a1)
CREATE TABLE rg_a_0012 (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
period timestamp(0) NOT NULL,
active boolean NOT NULL DEFAULT true,
mvt smallint NOT NULL CHECK (mvt IN (0,1)), -- 0=Прихід, 1=Витрата
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
d3_t smallint NOT NULL, -- складене вимірювання «Партія»
d3_r uuid NOT NULL,
d4_r uuid NOT NULL,
r1 numeric(15,3) NOT NULL DEFAULT 0,
r2 numeric(15,2) NOT NULL DEFAULT 0,
a1 varchar(200),
CONSTRAINT pk_rg_a_0012 PRIMARY KEY (rec_t, rec_r, line_no)
) PARTITION BY RANGE (period);

CREATE TABLE rg_a_0012_p2026m07 PARTITION OF rg_a_0012
FOR VALUES FROM ('2026-07-01') TO ('2026-08-01');
-- ... інші секції створюються регламентним завданням

CREATE INDEX ix_rg_a_0012_period ON rg_a_0012 (period, rec_t, rec_r, line_no);
CREATE INDEX ix_rg_a_0012_d1 ON rg_a_0012 (d1_r, period, d2_r) WHERE active; -- Номенклатура (Індексувати з дод. вимірюваннями)
CREATE INDEX ix_rg_a_0012_d2 ON rg_a_0012 (d2_r, period, d1_r) WHERE active; -- Склад
</syntaxhighlight>

=== 8.5.2. Таблиця підсумків залишків ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_a_0012_tb (
period timestamp(0) NOT NULL, -- початок місяця; MAXPERIOD = підсумок за всі періоди
splitter smallint NOT NULL DEFAULT 0,
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
d3_t smallint NOT NULL,
d3_r uuid NOT NULL,
d4_r uuid NOT NULL,
r1 numeric(20,3) NOT NULL, -- Кількість, знаковий залишок
r2 numeric(20,2) NOT NULL, -- Сума
CONSTRAINT pk_rg_a_0012_tb PRIMARY KEY (period, d1_r, d2_r, d3_t, d3_r, d4_r, splitter)
);
-- покривний індекс для типового відбору «залишки по складу»
CREATE INDEX ix_rg_a_0012_tb_d2 ON rg_a_0012_tb (d2_r, period, d1_r) INCLUDE (r1, r2);
</syntaxhighlight>

'''Семантика:''' рядок з <code>period = P</code> містить залишок '''на початок''' періоду P. Рядок з <code>period = MAXPERIOD</code> — поточний залишок за всі періоди (використовується для запитів «залишки на зараз», найчастіший кейс).

=== 8.5.3. Таблиця підсумків оборотів ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_a_0012_tt (
period timestamp(0) NOT NULL, -- початок періоду агрегації (день/місяць)
splitter smallint NOT NULL DEFAULT 0,
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
d3_t smallint NOT NULL,
d3_r uuid NOT NULL,
d4_r uuid NOT NULL,
r1_in numeric(20,3) NOT NULL DEFAULT 0, -- Кількість Прихід
r1_out numeric(20,3) NOT NULL DEFAULT 0, -- Кількість Витрата
r2_in numeric(20,2) NOT NULL DEFAULT 0,
r2_out numeric(20,2) NOT NULL DEFAULT 0,
CONSTRAINT pk_rg_a_0012_tt PRIMARY KEY (period, d1_r, d2_r, d3_t, d3_r, d4_r, splitter)
);
</syntaxhighlight>

=== 8.5.4. Службова таблиця налаштувань ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_a_0012_opt (
id smallint PRIMARY KEY DEFAULT 1 CHECK (id = 1),
totals_actual_to timestamp(0) NOT NULL, -- ТА: підсумки розраховані до
use_bal_totals boolean NOT NULL DEFAULT true,
use_tno_totals boolean NOT NULL DEFAULT true,
min_period timestamp(0), -- період першого руху
last_recalc_at timestamp(0),
split_merge_at timestamp(0)
);
</syntaxhighlight>

=== 8.5.5. Агрегат (для РН виду «Обороти») ===
<syntaxhighlight lang="sql">
-- Агрегат «Продажі за місяцями по номенклатурі та складу» (без Партії, без Характеристики)
CREATE TABLE rg_a_0031_ag1 (
period timestamp(0) NOT NULL,
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
r1 numeric(20,3) NOT NULL,
r2 numeric(20,2) NOT NULL,
CONSTRAINT pk_rg_a_0031_ag1 PRIMARY KEY (period, d1_r, d2_r)
);
</syntaxhighlight>

== 8.6. Регістр бухгалтерії ==

=== 8.6.1. План рахунків (супутні таблиці) ===
<syntaxhighlight lang="sql">
CREATE TABLE coa_0005 ( -- ПланРахунків.Госпрозрахунковий
ref uuid PRIMARY KEY,
parent_ref uuid REFERENCES coa_0005(ref),
code varchar(20) NOT NULL,
order_code varchar(40) NOT NULL, -- впорядкований код для ієрархічних запитів
name varchar(150) NOT NULL,
acc_type smallint NOT NULL, -- 0=Активний,1=Пасивний,2=Активно-пасивний
off_balance boolean NOT NULL DEFAULT false,
ed_count smallint NOT NULL DEFAULT 0, -- фактична кількість субконто
fl_qty boolean NOT NULL DEFAULT false, -- ознака обліку «Кількісний»
fl_cur boolean NOT NULL DEFAULT false, -- ознака обліку «Валютний»
marked_del boolean NOT NULL DEFAULT false
);
CREATE UNIQUE INDEX ux_coa_0005_code ON coa_0005 (code);

CREATE TABLE coa_0005_ed ( -- ТЧ «ВидиСубконто»
ref uuid NOT NULL REFERENCES coa_0005(ref) ON DELETE CASCADE,
line_no int NOT NULL,
ed_type_r uuid NOT NULL, -- ПланВидівХарактеристик.ВидиСубконто
only_tno boolean NOT NULL DEFAULT false, -- «Тільки обороти»
sum_flag boolean NOT NULL DEFAULT true, -- «Підсумкова сума»
fl_qty boolean NOT NULL DEFAULT false, -- ознака обліку субконто «Кількісний»
PRIMARY KEY (ref, line_no)
);
</syntaxhighlight>

=== 8.6.2. Таблиця проводок (з кореспонденцією) ===
<syntaxhighlight lang="sql">
-- Госпрозрахунковий: dims = Організація(d1, балансове), Підрозділ(d2, небалансове)
-- res = Сума(r1, балансовий), Кількість(r2, небалансовий), ВалютнаСума(r3, небалансовий)
-- attr = Зміст(a1), Валюта(a2); max_extdim_count = 3
CREATE TABLE rg_b_0020 (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
period timestamp(0) NOT NULL,
active boolean NOT NULL DEFAULT true,

acc_dt_r uuid NOT NULL REFERENCES coa_0005(ref),
acc_kt_r uuid NOT NULL REFERENCES coa_0005(ref),

-- балансове вимірювання: одне значення на проводку
d1_r uuid NOT NULL,
-- небалансове вимірювання: окремо для Дт і Кт
d2_dt_r uuid NOT NULL,
d2_kt_r uuid NOT NULL,

-- субконто Дт (3 слоти, складений тип: ПВХ-значення)
ed_dt1_t smallint, ed_dt1_r uuid,
ed_dt2_t smallint, ed_dt2_r uuid,
ed_dt3_t smallint, ed_dt3_r uuid,
ed_dt_h bigint NOT NULL DEFAULT 0, -- хеш набору субконто Дт (для JOIN з підсумками)
-- субконто Кт
ed_kt1_t smallint, ed_kt1_r uuid,
ed_kt2_t smallint, ed_kt2_r uuid,
ed_kt3_t smallint, ed_kt3_r uuid,
ed_kt_h bigint NOT NULL DEFAULT 0,

-- балансовий ресурс: одне значення
r1 numeric(20,2) NOT NULL DEFAULT 0, -- Сума
-- небалансові ресурси: пара Дт/Кт
r2_dt numeric(20,3) NOT NULL DEFAULT 0, -- Кількість Дт
r2_kt numeric(20,3) NOT NULL DEFAULT 0, -- Кількість Кт
r3_dt numeric(20,2) NOT NULL DEFAULT 0, -- ВалютнаСума Дт
r3_kt numeric(20,2) NOT NULL DEFAULT 0,

a1 varchar(255),
a2_r uuid,
CONSTRAINT pk_rg_b_0020 PRIMARY KEY (rec_t, rec_r, line_no)
) PARTITION BY RANGE (period);

CREATE INDEX ix_rg_b_0020_period ON rg_b_0020 (period, rec_t, rec_r, line_no);
CREATE INDEX ix_rg_b_0020_acc_dt ON rg_b_0020 (acc_dt_r, period) WHERE active;
CREATE INDEX ix_rg_b_0020_acc_kt ON rg_b_0020 (acc_kt_r, period) WHERE active;
CREATE INDEX ix_rg_b_0020_ed_dt ON rg_b_0020 (ed_dt1_t, ed_dt1_r, period) WHERE active;
</syntaxhighlight>

{{Note|'''Проєктне рішення №2.''' Субконто зберігаються '''слотами в основній таблиці''', а не в дочірній таблиці «ключ-значення». Обґрунтування: (а) віртуальні таблиці <code>Залишки</code>/<code>Обороти</code> з відбором за субконто перетворюються на предикат по колонці замість <code>N</code> самоз'єднань; (б) кількість субконто жорстко обмежена (≤5) — «широка» таблиця прийнятна; (в) 1С використовує гібрид (<code>_AccRgED</code>), що дає складніші плани. '''Ціна:''' зміна <code>МаксКількістьСубконто</code> = реструктуризація таблиці. Альтернатива (дочірня таблиця <code>rg_b_0020_ed</code>) описана в Додатку Б і зберігається як план «Б» за результатами навантажувального тесту НТ-04.}}

=== 8.6.3. Таблиця проводок (без кореспонденції) ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_b_0021 (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
period timestamp(0) NOT NULL,
active boolean NOT NULL DEFAULT true,
acc_mvt smallint NOT NULL CHECK (acc_mvt IN (0,1)), -- 0=Дебет, 1=Кредит
acc_r uuid NOT NULL REFERENCES coa_0006(ref),
d1_r uuid NOT NULL,
ed1_t smallint, ed1_r uuid,
ed2_t smallint, ed2_r uuid,
ed3_t smallint, ed3_r uuid,
ed_h bigint NOT NULL DEFAULT 0,
r1 numeric(20,2) NOT NULL DEFAULT 0,
CONSTRAINT pk_rg_b_0021 PRIMARY KEY (rec_t, rec_r, line_no)
);
</syntaxhighlight>

=== 8.6.4. Підсумки РБ ===
Підсумки будуються на кількох «рівнях субконто» — щоб запит без відбору за субконто не сканував найдетальнішу таблицю.

<syntaxhighlight lang="sql">
-- Рівень 0: залишки по рахунку + балансові вимірювання (без субконто)
CREATE TABLE rg_b_0020_tb0 (
period timestamp(0) NOT NULL,
splitter smallint NOT NULL DEFAULT 0,
acc_r uuid NOT NULL,
d1_r uuid NOT NULL, -- Організація (балансове)
r1 numeric(24,2) NOT NULL, -- Сума: >0 = дебетовий, <0 = кредитовий залишок
r2 numeric(24,3) NOT NULL, -- Кількість
r3 numeric(24,2) NOT NULL,
CONSTRAINT pk_rg_b_0020_tb0 PRIMARY KEY (period, acc_r, d1_r, splitter)
);

-- Рівень 1..3: залишки з розшифровкою по субконто (тільки для рахунків з ed_count >= k)
CREATE TABLE rg_b_0020_tb1 (
period timestamp(0) NOT NULL, splitter smallint NOT NULL DEFAULT 0,
acc_r uuid NOT NULL, d1_r uuid NOT NULL,
ed1_t smallint NOT NULL, ed1_r uuid NOT NULL,
r1 numeric(24,2) NOT NULL, r2 numeric(24,3) NOT NULL, r3 numeric(24,2) NOT NULL,
CONSTRAINT pk_rg_b_0020_tb1 PRIMARY KEY (period, acc_r, d1_r, ed1_t, ed1_r, splitter)
);
CREATE TABLE rg_b_0020_tb2 (
period timestamp(0) NOT NULL, splitter smallint NOT NULL DEFAULT 0,
acc_r uuid NOT NULL, d1_r uuid NOT NULL,
ed1_t smallint NOT NULL, ed1_r uuid NOT NULL,
ed2_t smallint NOT NULL, ed2_r uuid NOT NULL,
r1 numeric(24,2) NOT NULL, r2 numeric(24,3) NOT NULL, r3 numeric(24,2) NOT NULL,
CONSTRAINT pk_rg_b_0020_tb2 PRIMARY KEY (period, acc_r, d1_r, ed1_t, ed1_r, ed2_t, ed2_r, splitter)
);
-- rg_b_0020_tb3 — аналогічно, 3 субконто

-- Обороти (аналогічні рівні): tt0..tt3
CREATE TABLE rg_b_0020_tt0 (
period timestamp(0) NOT NULL,
splitter smallint NOT NULL DEFAULT 0,
acc_r uuid NOT NULL,
d1_r uuid NOT NULL,
r1_dt numeric(24,2) NOT NULL, r1_kt numeric(24,2) NOT NULL,
r2_dt numeric(24,3) NOT NULL, r2_kt numeric(24,3) NOT NULL,
r3_dt numeric(24,2) NOT NULL, r3_kt numeric(24,2) NOT NULL,
CONSTRAINT pk_rg_b_0020_tt0 PRIMARY KEY (period, acc_r, d1_r, splitter)
);

-- Обороти між рахунками (кореспонденції)
CREATE TABLE rg_b_0020_tc (
period timestamp(0) NOT NULL,
splitter smallint NOT NULL DEFAULT 0,
acc_dt_r uuid NOT NULL,
acc_kt_r uuid NOT NULL,
d1_r uuid NOT NULL,
r1 numeric(24,2) NOT NULL,
CONSTRAINT pk_rg_b_0020_tc PRIMARY KEY (period, acc_dt_r, acc_kt_r, d1_r, splitter)
);
</syntaxhighlight>

'''Правило запису рівнів:''' для проводки з рахунком, що має <code>ed_count = k</code>, оновлюються таблиці <code>tb0 … tbK</code> (k+1 таблиць). Рахунки без субконто оновлюють лише <code>tb0</code>. Субконто з ознакою «Тільки обороти» не потрапляють у <code>tb*</code>, лише в <code>tt*</code>.

== 8.7. Регістр розрахунку ==

<syntaxhighlight lang="sql">
-- Нарахування: dims = Співробітник(d1, базове), Підрозділ(d2)
-- res = Результат(r1), ВідпрацьованоДнів(r2), НормаДнів(r3)
-- attr = Графік(a1)
CREATE TABLE rg_c_0040 (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
period timestamp(0) NOT NULL, -- період реєстрації (початок місяця)
active boolean NOT NULL DEFAULT true,
reversal boolean NOT NULL DEFAULT false, -- Сторно
calc_type_r uuid NOT NULL, -- ВидРозрахунку → pct_0011(ref)
act_begin timestamp(0) NOT NULL, -- ПеріодДіїПочаток
act_end timestamp(0) NOT NULL, -- ПеріодДіїКінець
base_begin timestamp(0), -- БазовийПеріодПочаток
base_end timestamp(0), -- БазовийПеріодКінець
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
r1 numeric(15,2) NOT NULL DEFAULT 0,
r2 numeric(5,0) NOT NULL DEFAULT 0,
r3 numeric(5,0) NOT NULL DEFAULT 0,
a1_r uuid,
CONSTRAINT pk_rg_c_0040 PRIMARY KEY (rec_t, rec_r, line_no),
CONSTRAINT chk_rg_c_0040_act CHECK (act_end >= act_begin)
);
CREATE INDEX ix_rg_c_0040_period ON rg_c_0040 (period, rec_t, rec_r, line_no);
CREATE INDEX ix_rg_c_0040_d1 ON rg_c_0040 (d1_r, period, calc_type_r) WHERE active;
CREATE INDEX ix_rg_c_0040_act ON rg_c_0040 (d1_r, act_begin, act_end) WHERE active;
CREATE INDEX ix_rg_c_0040_base ON rg_c_0040 (d1_r, calc_type_r, base_begin, base_end) WHERE active;

-- Фактичні періоди дії (після витіснення). Один запис → 0..N інтервалів.
CREATE TABLE rg_c_0040_ap (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
interval_no smallint NOT NULL,
calc_type_r uuid NOT NULL,
d1_r uuid NOT NULL, -- денормалізація базового вимірювання для швидкого JOIN
fact_begin timestamp(0) NOT NULL,
fact_end timestamp(0) NOT NULL,
CONSTRAINT pk_rg_c_0040_ap PRIMARY KEY (rec_t, rec_r, line_no, interval_no),
CONSTRAINT fk_rg_c_0040_ap FOREIGN KEY (rec_t, rec_r, line_no)
REFERENCES rg_c_0040 (rec_t, rec_r, line_no) ON DELETE CASCADE
);
CREATE INDEX ix_rg_c_0040_ap_d1 ON rg_c_0040_ap (d1_r, fact_begin, fact_end);

-- Перерахунок «ПерерахунокЗаБазою»
CREATE TABLE rg_c_0040_rc1 (
rec_t smallint NOT NULL, -- реєстратор запису, який треба перерахувати
rec_r uuid NOT NULL,
calc_type_r uuid NOT NULL, -- вид розрахунку, що потребує перерахунку
d1_r uuid NOT NULL, -- вимірювання перерахунку «Співробітник»
src_rec_t smallint NOT NULL, -- реєстратор, що спричинив перерахунок
src_rec_r uuid NOT NULL,
created_at timestamp(0) NOT NULL DEFAULT now(),
CONSTRAINT pk_rg_c_0040_rc1 PRIMARY KEY (rec_t, rec_r, calc_type_r, d1_r)
);
CREATE INDEX ix_rg_c_0040_rc1_src ON rg_c_0040_rc1 (src_rec_t, src_rec_r);
</syntaxhighlight>

== 8.8. Зведення: які таблиці породжує кожен тип регістру ==

<graphviz>
digraph Tables {
rankdir=LR; bgcolor="transparent"; ranksep=0.6; nodesep=0.08;
node [shape=box, style="filled,rounded", fontname="Helvetica", fontsize=9, height=0.26];
edge [color="#9e9e9e", arrowhead=vee];

RI [label="РВ\n(незалежний або\nпідпорядкований)", fillcolor="#e8f5e9"];
RAB [label="РН «Залишки»", fillcolor="#fff8e1"];
RAT [label="РН «Обороти»", fillcolor="#fff8e1"];
RB [label="РБ", fillcolor="#fce4ec"];
RC [label="РР", fillcolor="#ede7f6"];

node [shape=cylinder, style=filled, fontname="Courier", fontsize=8, height=0.22];

i1 [label="rg_i_<id>", fillcolor="#c8e6c9"];
RI -> i1;

a1 [label="rg_a_<id>", fillcolor="#ffecb3"];
a2 [label="rg_a_<id>_tb", fillcolor="#ffe082"];
a3 [label="rg_a_<id>_tt", fillcolor="#ffe082"];
a4 [label="rg_a_<id>_opt", fillcolor="#fff3e0"];
RAB -> a1; RAB -> a2 [label=" якщо підсумки залишків", fontsize=7];
RAB -> a3 [label=" якщо підсумки оборотів", fontsize=7]; RAB -> a4;

t1 [label="rg_a_<id>", fillcolor="#ffecb3"];
t2 [label="rg_a_<id>_tt", fillcolor="#ffe082"];
t3 [label="rg_a_<id>_ag1..agN", fillcolor="#ffd54f"];
t4 [label="rg_a_<id>_opt", fillcolor="#fff3e0"];
RAT -> t1; RAT -> t2; RAT -> t3 [label=" агрегати", fontsize=7]; RAT -> t4;

b1 [label="rg_b_<id>", fillcolor="#f8bbd0"];
b2 [label="rg_b_<id>_tb0 .. _tbK", fillcolor="#f48fb1"];
b3 [label="rg_b_<id>_tt0 .. _ttK", fillcolor="#f48fb1"];
b4 [label="rg_b_<id>_tc", fillcolor="#f48fb1"];
b5 [label="rg_b_<id>_opt", fillcolor="#fce4ec"];
RB -> b1; RB -> b2 [label=" K = МаксКількістьСубконто", fontsize=7]; RB -> b3; RB -> b4; RB -> b5;

c1 [label="rg_c_<id>", fillcolor="#d1c4e9"];
c2 [label="rg_c_<id>_ap", fillcolor="#b39ddb"];
c3 [label="rg_c_<id>_rc1..rcM", fillcolor="#b39ddb"];
RC -> c1; RC -> c2 [label=" фактичні періоди", fontsize=7]; RC -> c3 [label=" перерахунки", fontsize=7];

{ rank=same; RI; RAB; RAT; RB; RC; }
}
</graphviz>

Оцінка: для РБ з <code>МаксКількістьСубконто = 3</code> генерується '''10 фізичних таблиць''' на один регістр.

= 9. ER-моделі =

== 9.1. ER-модель метаданих (репозиторій) ==

<uml>
@startuml
hide circle
skinparam linetype ortho
skinparam shadowing false

entity "md_type" as T {
* id : smallint <<PK>>
--
* kind : varchar(20)
* name : varchar(80)
table_name : varchar(63)
}

entity "md_register" as R {
* id : smallint <<PK,FK→md_type>>
--
* name : varchar(80) <<U>>
* kind : varchar(12)
* write_mode : varchar(24)
* periodicity : varchar(24)
accumulation_kind : varchar(10)
enable_bal_totals : boolean
enable_tno_totals : boolean
tno_totals_period : varchar(6)
split_totals : boolean
chart_of_accounts_id : smallint <<FK>>
correspondence : boolean
max_extdim_count : smallint
calc_types_plan_id : smallint <<FK>>
use_action_period : boolean
base_period_mode : varchar(24)
schedule_register_id : smallint <<FK>>
* physical_table : varchar(63)
* struct_version : int
}

entity "md_register_field" as F {
* register_id : smallint <<PK,FK>>
* id : smallint <<PK>>
--
* name : varchar(80) <<U>>
* role : Dimension|Resource|Attribute
* data_type_expr : text
is_composite : boolean
index_mode : varchar(28)
is_master : boolean
is_balance : boolean
is_base_dimension : boolean
accounting_flag : varchar(80)
* column_prefix : varchar(8)
}

entity "md_register_recorder" as RR {
* register_id : smallint <<PK,FK>>
* doc_type_id : smallint <<PK,FK>>
}

entity "md_register_aggregate" as AG {
* register_id : smallint <<PK,FK>>
* id : smallint <<PK>>
--
* name : varchar(80)
* periodicity : Day|Month|Quarter|Year
is_realtime : boolean
actual_upto : timestamp
}

entity "md_register_aggregate_dim" as AGD {
* register_id : smallint <<PK,FK>>
* aggregate_id : smallint <<PK,FK>>
* field_id : smallint <<PK,FK>>
}

entity "md_register_recalc" as RC {
* register_id : smallint <<PK,FK>>
* id : smallint <<PK>>
--
* name : varchar(80)
* physical_table : varchar(63)
}

entity "md_register_recalc_dim" as RCD {
* register_id : smallint <<PK,FK>>
* recalc_id : smallint <<PK,FK>>
* name : varchar(80) <<PK>>
--
* reg_field_id : smallint <<FK>>
}

T ||--o| R : "є регістром"
T ||--o{ RR : "тип документа"
R ||--|{ F : "має поля"
R ||--o{ RR : "реєстратори"
R ||--o{ AG : "агрегати"
AG ||--|{ AGD : "склад вимірювань"
F ||--o{ AGD : "вимірювання"
R ||--o{ RC : "перерахунки"
RC ||--|{ RCD : "вимірювання перерахунку"
F ||--o{ RCD : "відповідає"
R }o--o| T : "план рахунків"
R }o--o| T : "план видів розрахунку"
R }o--o| R : "графік часу"
@enduml
</uml>

== 9.2. ER-модель: регістр накопичення (вид «Залишки») ==

<uml>
@startuml
hide circle
skinparam linetype ortho
skinparam shadowing false

entity "doc_0002\n«ПрихіднаНакладна»" as D1 {
* ref : uuid <<PK>>
--
number : varchar
date : timestamp
posted : boolean
}
entity "doc_0003\n«ВидатковаНакладна»" as D2 {
* ref : uuid <<PK>>
--
number : varchar
date : timestamp
posted : boolean
}
entity "cat_0001\n«Номенклатура»" as C1 {
* ref : uuid <<PK>>
--
code, name
}
entity "cat_0004\n«Склади»" as C2 {
* ref : uuid <<PK>>
--
code, name
}

entity "rg_a_0012\n«ТовариНаСкладах» (рухи)" as M {
* rec_t : smallint <<PK>>
* rec_r : uuid <<PK>>
* line_no : int <<PK>>
--
* period : timestamp(0)
* active : boolean
* mvt : smallint «0=Прихід,1=Витрата»
* d1_r : uuid «Номенклатура» <<FK>>
* d2_r : uuid «Склад» <<FK>>
* d3_t : smallint «Партія:тип»
* d3_r : uuid «Партія:посилання»
* d4_r : uuid «Характеристика» <<FK>>
* r1 : numeric(15,3) «Кількість»
* r2 : numeric(15,2) «Сума»
a1 : varchar(200) «Коментар»
}

entity "rg_a_0012_tb\nпідсумки залишків" as TB {
* period : timestamp(0) <<PK>>
* d1_r : uuid <<PK>>
* d2_r : uuid <<PK>>
* d3_t : smallint <<PK>>
* d3_r : uuid <<PK>>
* d4_r : uuid <<PK>>
* splitter : smallint <<PK>>
--
* r1 : numeric(20,3) «Кількість (±)»
* r2 : numeric(20,2) «Сума (±)»
}

entity "rg_a_0012_tt\nпідсумки оборотів" as TT {
* period : timestamp(0) <<PK>>
* d1_r : uuid <<PK>>
* d2_r : uuid <<PK>>
* d3_t : smallint <<PK>>
* d3_r : uuid <<PK>>
* d4_r : uuid <<PK>>
* splitter : smallint <<PK>>
--
r1_in, r1_out : numeric(20,3)
r2_in, r2_out : numeric(20,2)
}

entity "rg_a_0012_opt" as OPT {
* id : smallint = 1 <<PK>>
--
* totals_actual_to : timestamp(0)
use_bal_totals : boolean
use_tno_totals : boolean
min_period : timestamp(0)
}

D1 ||..o{ M : "реєстратор\n(поліморфний, без FK)"
D2 ||..o{ M : "реєстратор\n(поліморфний, без FK)"
C1 ||--o{ M : "d1_r"
C2 ||--o{ M : "d2_r"
M }o..|| TB : "агрегується в\n(підтримується платформою)"
M }o..|| TT : "агрегується в"
OPT ||..|| TB : "ТА підсумків"

note bottom of M
PK = (rec_t, rec_r, line_no)
→ усі рухи одного документа
фізично суміжні
Партиціонування: RANGE(period)
end note

note bottom of TB
period = MAXPERIOD ('5999-11-01')
→ рядок «залишок за всі періоди»
end note
@enduml
</uml>

== 9.3. ER-модель: регістр бухгалтерії ==

<uml>
@startuml
hide circle
skinparam linetype ortho
skinparam shadowing false

entity "coa_0005\n«План рахунків»" as A {
* ref : uuid <<PK>>
--
parent_ref : uuid <<FK>>
* code : varchar(20) <<U>>
order_code : varchar(40)
* name : varchar(150)
* acc_type : smallint «Акт/Пас/АП»
off_balance : boolean
ed_count : smallint
fl_qty, fl_cur : boolean
}
entity "coa_0005_ed\n«Види субконто рахунку»" as AE {
* ref : uuid <<PK,FK>>
* line_no : int <<PK>>
--
* ed_type_r : uuid <<FK>>
only_tno : boolean
sum_flag : boolean
}
entity "cvt_0009\n«ПВХ.ВидиСубконто»" as VT {
* ref : uuid <<PK>>
--
code, name
value_type : text
}

entity "rg_b_0020\n«Госпрозрахунковий» (проводки)" as J {
* rec_t : smallint <<PK>>
* rec_r : uuid <<PK>>
* line_no : int <<PK>>
--
* period : timestamp(0)
* active : boolean
* acc_dt_r : uuid <<FK>>
* acc_kt_r : uuid <<FK>>
* d1_r : uuid «Організація (балансове)»
* d2_dt_r : uuid «Підрозділ Дт»
* d2_kt_r : uuid «Підрозділ Кт»
ed_dt1_t/_r .. ed_dt3_t/_r : «субконто Дт»
ed_dt_h : bigint
ed_kt1_t/_r .. ed_kt3_t/_r : «субконто Кт»
ed_kt_h : bigint
* r1 : numeric(20,2) «Сума (балансовий)»
r2_dt, r2_kt : numeric(20,3) «Кількість»
r3_dt, r3_kt : numeric(20,2) «ВалютнаСума»
a1 : varchar(255) «Зміст»
a2_r : uuid «Валюта»
}

entity "rg_b_0020_tb0\nзалишки, рівень 0" as B0 {
* period <<PK>>
* acc_r <<PK>>
* d1_r <<PK>>
* splitter <<PK>>
--
r1, r2, r3 : numeric «знакові»
}
entity "rg_b_0020_tb1..tb3\nзалишки, рівні 1..3" as B1 {
* period <<PK>>
* acc_r <<PK>>
* d1_r <<PK>>
* ed1_t, ed1_r <<PK>>
* (ed2_t, ed2_r) <<PK>>
* (ed3_t, ed3_r) <<PK>>
* splitter <<PK>>
--
r1, r2, r3 : numeric
}
entity "rg_b_0020_tt0..tt3\nобороти за рівнями" as T0 {
* period <<PK>>
* acc_r <<PK>>
* d1_r <<PK>>
* (ed…) <<PK>>
--
r1_dt, r1_kt
r2_dt, r2_kt
r3_dt, r3_kt
}
entity "rg_b_0020_tc\nобороти Дт↔Кт" as TC {
* period <<PK>>
* acc_dt_r <<PK>>
* acc_kt_r <<PK>>
* d1_r <<PK>>
--
r1 : numeric(24,2)
}

A ||--o{ AE : "види субконто"
VT ||--o{ AE : "тип субконто"
A ||--o{ J : "acc_dt_r"
A ||--o{ J : "acc_kt_r"
A ||--o{ B0 : "acc_r"
A ||--o{ B1 : "acc_r"
J }o..|| B0 : "агрегується (Дт: +, Кт: −)"
J }o..|| B1 : "агрегується, якщо ed_count ≥ k"
J }o..|| T0 : "агрегується"
J }o..|| TC : "агрегується"

note right of J
Балансовий ресурс r1 — одне значення,
контроль Σ(Дт) = Σ(Кт) у межах реєстратора.
Небалансові ресурси — пара Дт/Кт.
Субконто — слоти (див. Рішення №2).
end note
@enduml
</uml>

== 9.4. ER-модель: регістр розрахунку ==

<uml>
@startuml
hide circle
skinparam linetype ortho
skinparam shadowing false

entity "pct_0011\n«ПВР.ОсновніНарахування»" as P {
* ref : uuid <<PK>>
--
code, name
use_action_period : boolean
base_dependency : varchar(24)
}
entity "pct_0011_base\n«Базові види розрахунку»" as PB {
* ref <<PK,FK>>
* line_no <<PK>>
--
* base_type_r : uuid <<FK>>
}
entity "pct_0011_displace\n«Витісняючі види розрахунку»" as PD {
* ref <<PK,FK>>
* line_no <<PK>>
--
* displacing_type_r : uuid <<FK>>
}
entity "pct_0011_lead\n«Ведучі види розрахунку»" as PL {
* ref <<PK,FK>>
* line_no <<PK>>
--
* leading_type_r : uuid <<FK>>
}

entity "rg_c_0040\n«Нарахування» (рухи)" as CR {
* rec_t : smallint <<PK>>
* rec_r : uuid <<PK>>
* line_no : int <<PK>>
--
* period : timestamp(0) «період реєстрації»
* active : boolean
* reversal : boolean «Сторно»
* calc_type_r : uuid <<FK>>
* act_begin : timestamp(0)
* act_end : timestamp(0)
base_begin : timestamp(0)
base_end : timestamp(0)
* d1_r : uuid «Співробітник (базове)»
* d2_r : uuid «Підрозділ»
r1 : numeric «Результат»
r2 : numeric «ВідпрацьованоДнів»
r3 : numeric «НормаДнів»
}

entity "rg_c_0040_ap\nфактичні періоди дії" as AP {
* rec_t <<PK,FK>>
* rec_r <<PK,FK>>
* line_no <<PK,FK>>
* interval_no : smallint <<PK>>
--
* calc_type_r : uuid
* d1_r : uuid
* fact_begin : timestamp(0)
* fact_end : timestamp(0)
}

entity "rg_c_0040_rc1\n«ПерерахунокЗаБазою»" as RC {
* rec_t <<PK>>
* rec_r <<PK>>
* calc_type_r <<PK>>
* d1_r <<PK>>
--
src_rec_t, src_rec_r
created_at
}

entity "rg_i_0015\n«ГрафікРоботи» (РВ)" as SCH {
* d1_r : uuid <<PK>> «ВидГрафіка»
* d2_d : timestamp(0) <<PK>> «ДатаГрафіка»
--
r1 : numeric «Значення»
}

entity "doc_0007\n«НарахуванняЗарплати»" as DOC {
* ref : uuid <<PK>>
--
number, date, posted
}

P ||--o{ CR : "calc_type_r"
P ||--o{ PB : "базові"
P ||--o{ PD : "витісняючі"
P ||--o{ PL : "ведучі"
DOC ||..o{ CR : "реєстратор"
CR ||--|{ AP : "1 запис → 0..N\nфактичних інтервалів"
CR }o..o{ RC : "потребує перерахунку"
SCH }o..o{ CR : "ДаніГрафіка\n(віртуальна таблиця)"
CR }o..o{ CR : "БазаРозрахунку\n(self-join через PB\nта базові вимірювання)"
@enduml
</uml>

== 9.5. Зведена концептуальна ER (усі типи) ==

<graphviz>
digraph ER {
rankdir=LR; bgcolor="transparent";
node [shape=record, fontname="Helvetica", fontsize=9, style=filled];
edge [fontname="Helvetica", fontsize=8];

MD [label="{md_register|id (PK)\lname\lkind\lperiodicity\lwrite_mode\l...}", fillcolor="#dbe9ff"];
MDF [label="{md_register_field|register_id (PK,FK)\lid (PK)\lname\lrole\ldata_type\l...}", fillcolor="#dbe9ff"];
MDR [label="{md_register_recorder|register_id (PK,FK)\ldoc_type_id (PK,FK)\l}", fillcolor="#dbe9ff"];

DOC [label="{doc_XXXX (Документ)|ref (PK)\lnumber\ldate\lposted\l}", fillcolor="#fff8e1"];
CAT [label="{cat_XXXX (Довідник)|ref (PK)\lcode\lname\l}", fillcolor="#fff8e1"];
COA [label="{coa_XXXX (План рахунків)|ref (PK)\lcode\lacc_type\led_count\l}", fillcolor="#fff8e1"];
PCT [label="{pct_XXXX (ПВР)|ref (PK)\lcode\l}", fillcolor="#fff8e1"];

RI [label="{rg_i_XXXX (РВ)|period (PK*)\ld1..dN (PK*)\l| rec_t,rec_r,line_no (PK**)\lr1..rM\l}", fillcolor="#e8f5e9"];
RA [label="{rg_a_XXXX (РН)|rec_t, rec_r, line_no (PK)\lperiod\lactive\lmvt\ld1..dN\lr1..rM\l}", fillcolor="#fff3e0"];
RAT [label="{rg_a_XXXX_tb / _tt|period (PK)\ld1..dN (PK)\lsplitter (PK)\lr1..rM\l}", fillcolor="#ffe0b2"];
RB [label="{rg_b_XXXX (РБ)|rec_t, rec_r, line_no (PK)\lperiod, active\lacc_dt_r, acc_kt_r\led_dt1..3, ed_kt1..3\ld1..dN\lr1, r2_dt/r2_kt\l}", fillcolor="#fce4ec"];
RBT [label="{rg_b_XXXX_tb0..tbK\lrg_b_XXXX_tt0..ttK\lrg_b_XXXX_tc|period, acc_r, d1..dN\led1..edK (PK)\lr1..rM\l}", fillcolor="#f8bbd0"];
RC [label="{rg_c_XXXX (РР)|rec_t, rec_r, line_no (PK)\lperiod, active, reversal\lcalc_type_r\lact_begin, act_end\lbase_begin, base_end\ld1..dN, r1..rM\l}", fillcolor="#ede7f6"];
RCA [label="{rg_c_XXXX_ap|rec_t,rec_r,line_no (PK,FK)\linterval_no (PK)\lfact_begin, fact_end\l}", fillcolor="#d1c4e9"];
RCR [label="{rg_c_XXXX_rc1..rcM|rec_t, rec_r (PK)\lcalc_type_r (PK)\ld1..dN (PK)\l}", fillcolor="#d1c4e9"];

MD -> MDF [label="1:N"];
MD -> MDR [label="1:N"];
MDR -> DOC [label="тип"];
MD -> COA [label="0:1 план рахунків", style=dashed];
MD -> PCT [label="0:1 ПВР", style=dashed];

MD -> RI [label="генерує DDL", style=dotted, color=blue];
MD -> RA [label="генерує DDL", style=dotted, color=blue];
MD -> RB [label="генерує DDL", style=dotted, color=blue];
MD -> RC [label="генерує DDL", style=dotted, color=blue];

DOC -> RI [label="реєстратор (поліморф.)", style=dashed];
DOC -> RA [label="реєстратор (поліморф.)", style=dashed];
DOC -> RB [label="реєстратор (поліморф.)", style=dashed];
DOC -> RC [label="реєстратор (поліморф.)", style=dashed];

CAT -> RI [label="FK вимір."];
CAT -> RA [label="FK вимір."];
COA -> RB [label="FK рахунок"];
PCT -> RC [label="FK вид розрах."];

RA -> RAT [label="агрегація (платформа)", color=darkgreen];
RB -> RBT [label="агрегація (платформа)", color=darkgreen];
RC -> RCA [label="витіснення → 1:N", color=purple];
RC -> RCR [label="реєстрація перерахунків", color=purple, style=dashed];

{ rank=same; MD; MDF; MDR; }
{ rank=same; RI; RA; RB; RC; }
}
</graphviz>

'''Легенда:'''
* <code>(PK*)</code> — ключ для незалежного РВ; <code>(PK**)</code> — для підпорядкованого.
* Пунктир «реєстратор» — логічний зв'язок без FK (поліморфне посилання, підтримується платформою).
* Пунктир «генерує DDL» — метадані → фізична схема (не зв'язок даних).

= 10. Ключові алгоритми =

== 10.1. Запис набору записів (режим «Заміщати») ==

<syntaxhighlight lang="python">
def write_record_set(reg: Register, rs: RecordSet, replace: bool = True) -> None:
"""Розділ 7.1, ФТ-01…ФТ-04. Уся операція — в одній транзакції."""
check_rights(reg, Right.INSERT | Right.UPDATE) # ФТ-37
validate(reg, rs) # реєстратор ∈ md_register_recorder;
# deny_empty; для РБ — Σ Дт = Σ Кт
with conn.begin(): # ФТ-03: одна транзакція
old = read_for_update(reg, rs.filter) # SELECT ... FOR UPDATE

# АП-2: дельта рахується набором, один раз; тільки active-записи
delta = aggregate(rs.active_records, sign=+1) + aggregate(old, sign=-1)

if replace: # ФТ-04
conn.execute(delete(tbl).where(*rs.filter.clauses)) # 1 запит
conn.execute(insert(tbl), rs.as_dicts()) # 1 executemany (АП-1)

update_totals(reg, delta) # -> merge_totals(), розділи 10.2, Е.3

if reg.kind is RegisterKind.CALCULATION:
keys = rs.affected_keys | affected_keys(old)
recompute_actual_periods(reg, keys) # розділ 10.4
register_recalculations(reg, [*rs.records, *old]) # розділ 10.5
</syntaxhighlight>

== 10.2. Інкрементальне оновлення підсумків залишків ==

<syntaxhighlight lang="sql">
-- Δ (delta) — тимчасова таблиця: (period_month, d1_r, d2_r, d3_t, d3_r, d4_r, dr1, dr2)
-- де dr = Σ (CASE WHEN mvt = 0 THEN +значення ELSE -значення END)

-- Крок 1. Кумулятивні залишки: рух у місяці M впливає на підсумки всіх періодів > M
-- та на рядок MAXPERIOD.
INSERT INTO rg_a_0012_tb AS t (period, splitter, d1_r, d2_r, d3_t, d3_r, d4_r, r1, r2)
SELECT p.period, :splitter, d.d1_r, d.d2_r, d.d3_t, d.d3_r, d.d4_r, d.dr1, d.dr2
FROM delta d
CROSS JOIN LATERAL (
SELECT period FROM totals_periods
WHERE period > d.period_month
AND period <= (SELECT totals_actual_to FROM rg_a_0012_opt)
UNION ALL SELECT TIMESTAMP '5999-11-01' -- MAXPERIOD
) p
ORDER BY 1,3,4,5,6,7 -- детермінований порядок → без дедлоків
ON CONFLICT (period, d1_r, d2_r, d3_t, d3_r, d4_r, splitter)
DO UPDATE SET r1 = t.r1 + EXCLUDED.r1,
r2 = t.r2 + EXCLUDED.r2;

-- Крок 2. Прибирання нульових рядків (регламентно, не в транзакції проведення)
DELETE FROM rg_a_0012_tb WHERE r1 = 0 AND r2 = 0 AND period <> TIMESTAMP '5999-11-01';
</syntaxhighlight>

{{Note|'''Оптимізація.''' Крок 1 у наведеному вигляді має складність O(кількість_періодів_після_руху). Для рухів «заднім числом» на роки це дорого. '''Проєктне рішення №3:''' підсумки оновлюються тільки для рядка <code>MAXPERIOD</code> і для найближчої межі періоду; повні кумулятивні зрізи перебудовуються регламентним завданням «Перерахунок підсумків» за зміненими місяцями (список змінених місяців накопичується в <code>rg_a_0012_opt.dirty_months</code>). Запити на дату в «брудному» місяці автоматично перемикаються на розрахунок від найближчого чистого зрізу. Остаточний вибір — за результатами НТ-02.}}

== 10.3. Трансляція віртуальної таблиці «Залишки» ==

<syntaxhighlight lang="sql">
-- РегістрНакопичення.ТовариНаСкладах.Залишки(&Період, Склад = &Склад)
WITH boundary AS (
SELECT COALESCE(MAX(period), TIMESTAMP '0001-01-01') AS p
FROM totals_periods
WHERE period <= :Період
AND period <= (SELECT totals_actual_to FROM rg_a_0012_opt)
),
base AS ( -- залишок на межу періоду з підсумків
SELECT t.d1_r, t.d2_r, t.d3_t, t.d3_r, t.d4_r,
SUM(t.r1) AS r1, SUM(t.r2) AS r2
FROM rg_a_0012_tb t, boundary b
WHERE t.period = b.p
AND t.d2_r = :Склад -- push-down параметра ВТ
GROUP BY 1,2,3,4,5
),
tail AS ( -- «живі» рухи після межі й до &Період
SELECT m.d1_r, m.d2_r, m.d3_t, m.d3_r, m.d4_r,
SUM(CASE WHEN m.mvt = 0 THEN m.r1 ELSE -m.r1 END) AS r1,
SUM(CASE WHEN m.mvt = 0 THEN m.r2 ELSE -m.r2 END) AS r2
FROM rg_a_0012 m, boundary b
WHERE m.active
AND m.period > b.p
AND m.period <= :Період
AND m.d2_r = :Склад
GROUP BY 1,2,3,4,5
)
SELECT d1_r AS "Номенклатура", d2_r AS "Склад",
d3_t, d3_r AS "Партія", d4_r AS "Характеристика",
SUM(r1) AS "КількістьЗалишок",
SUM(r2) AS "СумаЗалишок"
FROM (SELECT * FROM base UNION ALL SELECT * FROM tail) u
GROUP BY 1,2,3,4,5
HAVING SUM(r1) <> 0 OR SUM(r2) <> 0; -- нульові залишки не повертаються
</syntaxhighlight>

'''Оптимізація для найчастішого випадку:''' якщо <code>:Період ≥ ТА</code> і в регістрі немає рухів у майбутньому — <code>base</code> читається з рядка <code>MAXPERIOD</code> одним index seek, <code>tail</code> = ∅.

== 10.4. Розрахунок фактичних періодів дії (витіснення) ==

<syntaxhighlight lang="python">
def recompute_actual_periods(reg: Register, keys: set[DimKey]) -> None:
"""Розділ 7.5.1, ФТ-22…ФТ-24. Тут — оркестрація; сам алгоритм — Додаток Е.5."""
tbl = schema.movements(reg)
ap = schema.actual_periods(reg) # rg_c_<id>_ap

# 1. Читання всіх записів зачеплених ключів — ОДИН запит (АП-1)
records = conn.execute(
select(tbl).where(tbl.c.active, dim_key_in(tbl, keys))
).all()

# 2. Перерахунок інтервалів. Гарячий шлях: бюджет ≤ 3 c (АП-4),
# реалізація за Protocol-інтерфейсом (АП-3) — див. Е.5.
# Пріоритет: A витісняється B, якщо B ∈ ПВР[A].ВитісняючіВидиРозрахунку
intervals = displacement_engine.compute(records, displaces=plan.displaces)

# 3. Заміщення фактичних періодів — два запити на весь набір, не на запис
conn.execute(delete(ap).where(record_key_in(ap, intervals.keys())))
conn.execute(insert(ap), [
{"rec_t": k.rec_t, "rec_r": k.rec_r, "line_no": k.line_no,
"interval_no": n, "calc_type_r": k.calc_type, "d1_r": k.base_dim,
"fact_begin": begin, "fact_end": end}
for k, ivs in intervals.items()
for n, (begin, end) in enumerate(ivs) # 1 запис -> 0..N інтервалів
])
</syntaxhighlight>

'''Складність:''' O(|Z|² ) на ключ. Обмеження: якщо <code>|Z| > 500</code> для одного ключа — попередження в журналі та перехід на алгоритм замітання (sweep line) O(|Z| log |Z|).

== 10.5. Реєстрація перерахунків ==

<syntaxhighlight lang="python">
def register_recalculations(reg: Register, changed: Sequence[CalcRecord]) -> None:
"""Розділ 7.5.3, ФТ-26. АП-2: пошук залежних виконує СКБД, а не цикл у Python."""
q = schema.movements(reg).alias("q")
b = schema.calc_plan_base(reg).alias("b") # ТЧ «БазовіВидиРозрахунку» ПВР

for recalc in reg.recalculations:
rc = schema.recalc_table(reg, recalc) # rg_c_<id>_rc<n>
src = values_of(changed).alias("src") # змінені записи як VALUES-таблиця

# інтервальний предикат залежно від режиму базового періоду
if reg.base_period == "ByActionPeriod":
in_base = and_(src.c.act_begin <= q.c.base_end,
src.c.act_end >= q.c.base_begin) # перетин періодів
else: # ByRegistrationPeriod
in_base = src.c.period.between(q.c.base_begin, q.c.base_end)

dependent = (
select(q.c.rec_t, q.c.rec_r, q.c.calc_type_r,
*[q.c[c] for c in recalc.dim_columns],
src.c.rec_t.label("src_rec_t"), src.c.rec_r.label("src_rec_r"))
.select_from(
src.join(b, b.c.base_type_r == src.c.calc_type_r) # z — базовий для q
.join(q, q.c.calc_type_r == b.c.ref))
.where(q.c.active, in_base,
*[q.c[c] == src.c[c] for c in recalc.dim_columns],
tuple_(q.c.rec_t, q.c.rec_r) != tuple_(src.c.rec_t, src.c.rec_r))
.distinct()
)

stmt = pg_insert(rc).from_select(list(rc.columns.keys()), dependent)
conn.execute(stmt.on_conflict_do_nothing()) # 1 запит на перерахунок (АП-1)
</syntaxhighlight>

== 10.6. Зріз останніх ==

<syntaxhighlight lang="sql">
-- РегістрВідомостей.КурсиВалют.ЗрізОстанніх(&Дата, Валюта В (&Список))
SELECT DISTINCT ON (r.d1_r)
r.d1_r AS "Валюта", r.period AS "Період", r.r1 AS "Курс", r.r2 AS "Кратність"
FROM rg_i_0007 r
WHERE r.period <= :Дата
AND r.d1_r = ANY (:Список)
ORDER BY r.d1_r, r.period DESC; -- використовує ix_rg_i_0007_d1 (d1_r, period DESC)
-- Для MS SQL: ROW_NUMBER() OVER (PARTITION BY d1_r ORDER BY period DESC) = 1
-- або OUTER APPLY (SELECT TOP 1 ...) для великих списків.
</syntaxhighlight>

= 11. Нефункціональні вимоги =

== 11.1. Продуктивність ==
Еталонний стенд: 16 vCPU, 128 ГБ RAM, NVMe, PostgreSQL 15, БД 1,5 ТБ.

{| class="wikitable"
! № !! Операція !! Обсяг !! Ціль (P95)
|-
| НФВ-01 || Залишки на поточну дату, відбір за 1 вимірюванням || 1 млрд рухів, 20 млн рядків підсумків || ≤ 200 мс
|-
| НФВ-02 || Залишки на довільну дату в межах ТА || те саме || ≤ 400 мс
|-
| НФВ-03 || Обороти за 12 місяців із групуванням || 1 млрд рухів || ≤ 2 с
|-
| НФВ-04 || Проведення документа зі 100 рядками рухів (3 регістри) || — || ≤ 300 мс
|-
| НФВ-05 || Оборотно-сальдова відомість по всіх рахунках за місяць || 200 млн проводок || ≤ 5 с
|-
| НФВ-06 || Розрахунок ЗП: 10 000 співробітників × 8 видів розрахунку || — || ≤ 10 хв
|-
| НФВ-07 || Зріз останніх по 5 000 елементів вимірювання || 50 млн записів РВ || ≤ 500 мс
|-
| НФВ-08 || Пропускна здатність проведення || — || ≥ 50 док/с (10 паралельних сеансів)
|-
| НФВ-09 || Перерахунок підсумків РН || 1 млрд рухів || ≤ 4 год (у вікні обслуговування)
|}

{{Note|'''Вплив мови ядра.''' Цілі НФВ-01…НФВ-09 сформульовані для архітектури, де обчислює СКБД, а Python-ядро лише формує SQL (принципи АП-1, АП-2). Аналіз частки Python у кожній цілі — розділ 4.4.2: максимум 5 % (НФВ-04), запас на НФВ-06 — ×40. '''Цілі не переглядаються у зв'язку з вибором Python.'''}}

== 11.2. Масштабованість і обсяги ==
{| class="wikitable"
! Параметр !! Значення
|-
| Макс. записів в одному регістрі || 10<sup>10</sup>
|-
| Макс. кількість регістрів у конфігурації || 2 000
|-
| Макс. одночасних сеансів проведення || 200
|-
| Секціонування || Обов'язкове для таблиць > 100 млн записів
|}

== 11.3. Надійність і цілісність ==
* НФВ-10. Рухи та реєстратор змінюються в одній транзакції БД; часткове проведення неможливе.
* НФВ-11. Аварійне завершення сервера не залишає підсумки неузгодженими (гарантується транзакцією).
* НФВ-12. Сервіс перевірки цілісності (ФТ-41) виконується регламентно; розбіжність підсумків = інцидент P1.

== 11.4. Супроводжуваність ==
* НФВ-13. Реструктуризація регістру (додавання ресурсу/реквізиту) для таблиці ≤ 100 млн записів — ≤ 30 хв.
* НФВ-14. Додавання вимірювання вимагає перебудови підсумків; система повинна попереджати про оцінку часу до початку операції.
* НФВ-15. Усі DDL-операції — ідемпотентні та скриптовані (можливість застосувати вручну).

== 11.5. Сумісність ==
* НФВ-16. PostgreSQL 14+ та MS SQL Server 2019+ — обидві платформи з однаковою функціональністю.
* НФВ-17. Генератор DDL ізольований у шар «діалект СКБД».

= 12. Міграція існуючих структур K2 ERP =

== 12.1. Етапи ==
{| class="wikitable"
! № !! Етап !! Результат
|-
| М1 || Інвентаризація || Реєстр наявних «регістроподібних» таблиць K2 з класифікацією за типом-мішенню (РВ/РН/РБ/РР).
|-
| М2 || Мапінг || Для кожної таблиці — метаопис цільового регістру + правила перетворення колонок.
|-
| М3 || Створення регістрів || Генерація метаданих і DDL у тестовому контурі.
|-
| М4 || Перенесення даних || ETL: історичні дані → рухи, з призначенням реєстратора (реальний документ або службовий «ВведенняЗалишків»).
|-
| М5 || Побудова підсумків || Повний перерахунок.
|-
| М6 || Звірка || Порівняння залишків/оборотів «стара система vs нова» на контрольних датах; допуск розбіжності = 0.
|-
| М7 || Перемикання коду || Заміна прямих SQL-звернень на віртуальні таблиці; період паралельної роботи ≥ 1 звітний період.
|-
| М8 || Виведення з експлуатації || Видалення старих таблиць після 2 закритих періодів.
|}

== 12.2. Проблемні випадки ==
{| class="wikitable"
! Випадок !! Рішення
|-
| Історичні записи без документа-джерела || Службовий документ <code>ВведенняЗалишків</code> (один на період/розділ).
|-
| Записи з дублями за ключем (для незалежного РВ) || Дедуплікація з протоколом; конфлікти — на ручний розбір.
|-
| Дробові періоди / некоректні дати (NULL, 1900-01-01) || Нормалізація до MINPERIOD; протокол.
|-
| Прикладний код, що пише в таблиці напряму || Заборона на рівні прав БД після М7; аудит звернень на етапі М3–М6.
|-
| Аналітика, відсутня в цільовій моделі || Перенесення в реквізити (не у вимірювання) або відмова від міграції з обґрунтуванням.
|}

= 13. Приймальні випробування =

== 13.1. Функціональні тести (витяг) ==
{| class="wikitable"
! ID !! Сценарій !! Очікуваний результат
|-
| ФТ-Т-01 || Створити РВ періодичний незалежний, записати 2 записи з однаковим ключем || Другий запис заміщує перший; у таблиці 1 рядок
|-
| ФТ-Т-02 || Провести документ → 5 рухів РН || 5 записів у <code>rg_a_*</code>; підсумки MAXPERIOD змінилися на суму дельти
|-
| ФТ-Т-03 || Скасувати проведення || 0 записів; підсумки повернулися до вихідних значень
|-
| ФТ-Т-04 || Видалити документ-реєстратор || Рухи видалені каскадно; перевірка цілісності — 0 помилок
|-
| ФТ-Т-05 || Записати рух заднім числом (−6 міс.) || Залишки на всі дати після руху коректні (звірка з повним перерахунком)
|-
| ФТ-Т-06 || Установити <code>Активність = Хиба</code> || Запис не впливає на віртуальні таблиці; підсумки скориговані
|-
| ФТ-Т-07 || РБ: провести незбалансовану проводку (Дт ≠ Кт за балансовим ресурсом) || Помилка проведення, транзакція відкочена
|-
| ФТ-Т-08 || РБ: ОСВ по рахунку з 3 субконто || Підсумки за рівнями 0–3 узгоджені між собою (згортка tb3 → tb0)
|-
| ФТ-Т-09 || РР: сценарій «Оклад + Відпустка + Лікарняний» (розд. 7.5.1) || Фактичні періоди дії відповідають еталону; «Оклад» дає 2 інтервали
|-
| ФТ-Т-10 || РР: зміна базового запису || У таблиці перерахунку з'явився запис для залежного документа
|-
| ФТ-Т-11 || Паралельне проведення 2 документів за різними складами || Обидва проходять без очікування (розділення підсумків увімкнено)
|-
| ФТ-Т-12 || Паралельне проведення 2 документів за одним складом і одним товаром з контролем залишків || Один чекає, другий проходить; від'ємного залишку немає
|-
| ФТ-Т-13 || Перерахунок підсумків після хаотичних 10<sup>6</sup> операцій || Підсумки збігаються з повним перерахунком «з нуля» до копійки
|-
| ФТ-Т-14 || Реструктуризація: додати ресурс до РН із 10 млн записів || Дані збережені, підсумки перебудовані, час ≤ НФВ-13
|-
| ФТ-Т-15 || RLS: користувач з обмеженням по організації || Віртуальні таблиці повертають лише дозволені дані
|}

== 13.2. Навантажувальні тести ==
{| class="wikitable"
! ID !! Тест !! Критерій
|-
| НТ-01 || Генерація 1 млрд рухів РН, заміри НФВ-01…НФВ-03 || Досягнення цілей
|-
| НТ-02 || Профіль «90 % рухів поточним періодом, 10 % заднім числом» — порівняння двох стратегій підсумків (розд. 10.2) || Обґрунтований вибір Рішення №3
|-
| НТ-03 || Пікове проведення 50 док/с протягом 1 год || Відсутність дедлоків; P95 ≤ НФВ-04
|-
| НТ-04 || РБ: субконто-слоти vs дочірня таблиця, 200 млн проводок || Обґрунтований вибір Рішення №2
|-
| НТ-05 || Розрахунок ЗП на 10 000 співробітників || НФВ-06
|-
| НТ-06 || Деградація за 24 год безперервної роботи || Приріст часу відгуку ≤ 15 %
|}

= 14. Етапи робіт та оцінка =

{| class="wikitable"
! Етап !! Зміст !! Результат !! Оцінка, чол.-міс. !! Залежності
|-
| '''Е0''' || Обстеження платформи, верифікація припущень П1–П6, ескізний проєкт || Затверджений архітектурний ескіз, уточнене ТЗ || 1,5 || —
|-
| '''Е1''' || Метамодель + репозиторій + генератор DDL + конструктор (базовий) || Створення регістру будь-якого типу з генерацією схеми || 3 || Е0
|-
| '''Е2''' || Регістр відомостей: рантайм, набори записів, зрізи, форми || РВ у продуктиві || 2,5 || Е1
|-
| '''Е3''' || Регістр накопичення: рухи, підсумки, ТА, віртуальні таблиці || РН у продуктиві || 5 || Е2
|-
| '''Е4''' || Механізм проведення документів, блокування, оперативне/неоперативне проведення || Транзакційне проведення || 2,5 || Е3
|-
| '''Е5''' || Розширення мови запитів (віртуальні таблиці, транслятор, push-down) || Запити до ВТ || 3,5 || Е3
|-
| '''Е6''' || Регістр бухгалтерії + план рахунків + субконто + підсумки за рівнями || РБ у продуктиві || 6 || Е4, Е5
|-
| '''Е7''' || Регістр розрахунку + ПВР + витіснення + база + графіки + перерахунки || РР у продуктиві || 6,5 || Е4, Е5
|-
| '''Е8''' || Агрегати, розділення підсумків, порадник агрегатів || Оптимізація || 2,5 || Е3
|-
| '''Е9''' || Права доступу, RLS, аудит, сервіси цілісності || Безпека та адміністрування || 2 || Е6, Е7
|-
| '''Е10''' || Реструктуризація, міграція, інструменти звірки || Інструменти міграції || 2 || Е6, Е7
|-
| '''Е11''' || Навантажувальне тестування, оптимізація, документація, '''профілювання Python + бенчмарки гарячих шляхів''' || Приймальні випробування || 4,5 || усі
|-
| colspan="3" | '''РАЗОМ''' || '''41,5''' ||
|}

{{Note|Оцінка орієнтовна (±40 %) і підлягає уточненню за результатами Е0. Критичний шлях: Е0 → Е1 → Е3 → Е5 → Е6/Е7 → Е11. За командою 6–8 інженерів — орієнтовно 9–11 календарних місяців.}}

'''Мінімальний життєздатний обсяг (MVP)''': Е0–Е5 (РВ + РН + проведення + запити) ≈ '''18 чол.-міс.''' — покриває ~70 % прикладних сценаріїв K2 ERP.

=== 14.1. Вплив вибору Python на оцінку ===

{| class="wikitable"
! Етап !! Було (мова не визначена) !! Стало (Python) !! Δ !! Причина
|-
| Е1 (метамодель, DDL, конструктор) || 4 || '''3''' || '''−1''' || SQLAlchemy Core закриває генерацію DDL і діалекти СКБД; Pydantic v2 — валідацію DSL. Разом ~30 % етапу — готове.
|-
| Е5 (мова запитів, транслятор) || 4 || '''3,5''' || '''−0,5''' || lark (граматика) + SQLAlchemy Core expression language замість власного AST→SQL.
|-
| Е7 (регістр розрахунку) || 6 || '''6,5''' || '''+0,5''' || Ізоляція витіснення за інтерфейсом (АП-3) + резерв на нативну реалізацію.
|-
| Е10 (реструктуризація, міграція) || 2,5 || '''2''' || '''−0,5''' || Alembic покриває автогенерацію <code>ALTER</code>.
|-
| Е11 (навантаження, оптимізація) || 3 || '''4,5''' || '''+1,5''' || Профілювання Python, бенчмарки бюджету АП-4, ймовірні Cython/Rust-модулі, wheels у CI.
|-
| '''РАЗОМ''' || '''41,5''' || '''41,5''' || '''0''' || Економія на інфраструктурному коді компенсує витрати на оптимізацію.
|}

'''Висновок:''' Python — '''нейтральний за трудомісткістю''' для цього проєкту. Він здешевлює те, чого тут багато (метадані, генерація схеми, абстракція діалектів, міграції), і дорожчає те, чого тут мало (гарячі CPU-цикли). Ризик зміщується з «''не встигнемо написати''» на «''не вкладемося в бюджет часу виконання''» — тому бенчмарки гарячих шляхів (АП-4) вводяться в CI '''з етапу Е3''', а не наприкінці.

= 15. Ризики =

{| class="wikitable"
! ID !! Ризик !! Ймов. !! Вплив !! Пом'якшення
|-
| Р1 || У K2 ERP немає власної мови запитів → віртуальні таблиці нікуди вбудовувати || Сер. || '''Крит.''' || Верифікувати на Е0. План «Б»: віртуальні таблиці як параметризовані view/TVF + шар ORM.
|-
| Р2 || Конкуренція за таблицю підсумків на піках проведення || Вис. || Вис. || Розділення підсумків (сплітери), НТ-03, детермінований порядок MERGE.
|-
| Р3 || Рухи «заднім числом» роблять оновлення підсумків O(N періодів) || Вис. || Сер. || Рішення №3 (dirty months + регламентний перерахунок), НТ-02.
|-
| Р4 || «Широка» схема субконто → реструктуризація при зміні ліміту || Сер. || Сер. || Зафіксувати ліміт 5 із запасом; НТ-04; план «Б» — дочірня таблиця.
|-
| Р5 || Механізм витіснення РР — найскладніший і найпомилковіший вузол || Вис. || Вис. || Виділити в окремий модуль з еталонним набором з 50+ тест-кейсів; property-based тестування.
|-
| Р6 || Обсяг Е6+Е7 недооцінено (досвід 1С: це роки розробки) || Вис. || Вис. || MVP-підхід: спершу Е0–Е5, рішення про Е6/Е7 — після ретроспективи.
|-
| Р7 || Різна поведінка PostgreSQL і MS SQL (плани, MERGE, ізоляція) || Сер. || Сер. || Єдиний набір тестів на обох СКБД у CI від Е1.
|-
| Р8 || Міграція історичних даних без реєстраторів || Вис. || Сер. || Службовий документ «ВведенняЗалишків»; етап звірки М6 з нульовим допуском.
|-
| Р9 || Патентні / ліцензійні претензії щодо копіювання механізмів || Низ. || Вис. || Юридична експертиза до Е1: реалізація ''концепцій'' обліку (загальновідомих), а не коду/API; уникати дослівного копіювання найменувань API та документації.
|-
| Р10 || '''Гарячі шляхи''' (витіснення, розрахунок ЗП) на чистому Python не вкладаються в бюджет АП-4 || Сер. || Сер. || Ізоляція за <code>Protocol</code>-інтерфейсом (АП-3) + бенчмарк у CI від Е7; готовність до Cython/Rust; альтернатива для витіснення — <code>daterange</code>+GiST у PostgreSQL.
|-
| Р11 || '''Динамічна типізація в ядрі метаданих''' → помилки типів спливають у рантаймі на продуктиві || Вис. || Сер. || <code>mypy --strict</code> як обов'язковий gate у CI; Pydantic v2 на всіх межах; генерація <code>.pyi</code>-стабів для прикладного коду (ФТ-К-07).
|-
| Р12 || '''GIL''' обмежує вертикальне масштабування сервера застосунків || Сер. || Низ. || АП-5: asyncio для IO + мультипроцесний пул. Розрахунок у 4.4.2 показує запас: 50 док/с ≈ 50 % одного ядра.
|-
| Р13 || '''Нативні розширення''' (Cython/Rust) ускладнюють збірку, кросплатформність і пошук інженерів || Низ. || Низ. || Вводяться тільки за результатами бенчмарку; wheels під усі цільові платформи в CI; питання В13.
|-
| Р14 || '''Виконання прикладного Python-коду''' в процесі сервера = виконання довільного коду з правами сервера (П8) || Вис. || '''Крит.''' || '''Питання В12 до Е0.''' Варіанти: (а) довірена модель — конфігурацію пише лише вендор/партнер; (б) ізоляція процесами + seccomp/AppArmor; (в) обмежений DSL замість повного Python. У 1С вбудована мова існує в т.ч. з цієї причини.
|}

{{Note|'''Ризик Р9 — обов'язково до опрацювання перед стартом.''' ТЗ описує ''функціональні концепції'' (накопичувальний облік, подвійний запис, витіснення періодів дії), що є загальновідомими практиками обліку. Проте пряме відтворення пропрієтарних інтерфейсів, найменувань і структур конкретного вендора потребує окремої правової оцінки. Рекомендується узгодити з юридичною службою власну термінологію та API до початку Е1.}}

= 16. Додатки =

== Додаток А. Матриця відповідності «1С ↔ K2 ERP» ==

{| class="wikitable"
! Об'єкт / поняття 1С !! Пропонований аналог K2 ERP !! Примітка
|-
| РегистрСведений || <code>Регістри.Відомостей.*</code> || Повний паритет
|-
| РегистрНакопления || <code>Регістри.Накопичення.*</code> || Повний паритет
|-
| РегистрБухгалтерии || <code>Регістри.Бухгалтерії.*</code> || Субконто зберігаються інакше (слоти)
|-
| РегистрРасчета || <code>Регістри.Розрахунку.*</code> || Повний паритет
|-
| Регистратор || <code>Реєстратор</code> || —
|-
| ВидДвижения || <code>ВидРуху</code> || —
|-
| Итоги || <code>Підсумки</code> || —
|-
| Точка актуальности итогов || <code>ТА підсумків</code> || —
|-
| Разделение итогов || <code>Розділення підсумків</code> (splitter) || —
|-
| Агрегаты || <code>Агрегати</code> || —
|-
| Субконто / ПланВидовХарактеристик || <code>Субконто</code> / <code>ПланВидівХарактеристик</code> || —
|-
| ПланВидовРасчета || <code>ПланВидівРозрахунку</code> || —
|-
| Перерасчет || <code>Перерахунок</code> || —
|-
| ПериодДействия / Вытеснение || <code>ПеріодДії</code> / <code>Витіснення</code> || —
|-
| Границя послідовності || '''Не реалізується''' || Механізм визнано застарілим; замість нього — перепроведення за списком «брудних» документів
|-
| РегистрыСведений з режимом «ПоПозицииРегистратора» || <code>ПоПозиціїРеєстратора</code> || Реалізується як (period, rec_t, rec_r, line_no) у ключі
|}

== Додаток Б. Альтернатива зберігання субконто (план «Б» до Рішення №2) ==

<syntaxhighlight lang="sql">
-- Дочірня таблиця «ключ-значення» замість слотів
CREATE TABLE rg_b_0020_ed (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
side smallint NOT NULL CHECK (side IN (0,1)), -- 0=Дт, 1=Кт
ed_no smallint NOT NULL, -- порядковий номер субконто рахунка
ed_type_r uuid NOT NULL, -- вид субконто
val_t smallint NOT NULL,
val_r uuid,
val_n numeric(38,10),
val_s varchar(150),
val_d timestamp(0),
PRIMARY KEY (rec_t, rec_r, line_no, side, ed_no),
FOREIGN KEY (rec_t, rec_r, line_no) REFERENCES rg_b_0020 (rec_t, rec_r, line_no) ON DELETE CASCADE
);
CREATE INDEX ix_rg_b_0020_ed_val ON rg_b_0020_ed (ed_type_r, val_t, val_r);
</syntaxhighlight>

{| class="wikitable"
! Критерій !! Слоти (Рішення №2) !! Дочірня таблиця (план «Б»)
|-
| Відбір за 1 субконто || Index seek по колонці || JOIN + семі-з'єднання
|-
| Відбір за 3 субконто || 3 предикати в одному скані || 3 JOIN
|-
| Зміна <code>МаксКількістьСубконто</code> || ALTER TABLE (реструктуризація) || Без змін схеми
|-
| Розмір рядка проводки || +48 байт × 2 (Дт/Кт) || Базовий
|-
| Складність генератора DDL || Вища || Нижча
|-
| '''Рекомендація''' || '''Обрано за замовчуванням''' || Резерв за результатами НТ-04
|}

== Додаток В. Перелік вимог (реєстр трасування) ==

{| class="wikitable sortable"
! ID !! Розділ !! Коротко !! Пріоритет !! Тест
|-
| ФТ-01…ФТ-07 || 7.1 || Набори записів, проведення || Must || ФТ-Т-02…04
|-
| ФТ-08…ФТ-10 || 7.2 || Активність || Must || ФТ-Т-06
|-
| ФТ-11…ФТ-13 || 7.3 || Віртуальні таблиці || Must || ФТ-Т-08, НТ-01
|-
| ФТ-14…ФТ-18 || 7.4 || Підсумки, ТА || Must || ФТ-Т-05, ФТ-Т-13
|-
| ФТ-19…ФТ-21 || 7.4.4 || Агрегати || Should || НТ-01
|-
| ФТ-22…ФТ-30 || 7.5 || Механіка РР || Must (для Е7) || ФТ-Т-09, ФТ-Т-10
|-
| ФТ-31…ФТ-36 || 7.7 || Блокування || Must || ФТ-Т-11, ФТ-Т-12, НТ-03
|-
| ФТ-37…ФТ-39 || 7.8 || Права, RLS || Must || ФТ-Т-15
|-
| ФТ-40…ФТ-42 || 7.9 || Аудит, цілісність || Should || ФТ-Т-04
|-
| ФТ-К-01…06 || 6.8.4 || Конструктор || Should || —
|-
| НФВ-01…НФВ-09 || 11.1 || Продуктивність || Must || НТ-01…НТ-06
|-
| НФВ-10…НФВ-12 || 11.3 || Цілісність || Must || ФТ-Т-13
|-
| НФВ-13…НФВ-17 || 11.4–11.5 || Супровід, сумісність || Should || ФТ-Т-14
|}

== Додаток Г. Відкриті питання ==

{| class="wikitable"
! № !! Питання !! Кому !! Термін
|-
| В1 || Чи існує в K2 ERP мова запитів / транслятор у SQL? (визначає Р1 та обсяг Е5) || Архітектор платформи || До Е0
|-
| В2 || Формат ідентифікації об'єктів: UUID чи сурогатний int? || Архітектор платформи || До Е0
|-
| В3 || Чи потрібна мілісекундна дискретність періоду? || Замовник || До Е1
|-
| В4 || Максимальна кількість субконто: 3 чи 5? || Головний бухгалтер / методолог || До Е6
|-
| В5 || Чи потрібен механізм «Границя послідовності»? (пропонується відмова) || Методолог || До Е3
|-
| В6 || Пріоритет типів регістрів: чи достатньо MVP (РВ + РН) для першого релізу? || Замовник || До Е0
|-
| В7 || Правова оцінка ризику Р9 || Юридична служба || До Е1
|-
| В8 || Цільова СКБД для першої черги: тільки PostgreSQL чи одразу обидві? || Архітектор / ІТ-експлуатація || До Е1
|-
| В9 || '''Міжпланова база розрахунку:''' чи потрібна можливість брати базу з ''іншого'' регістру розрахунку (Утримання ← ОсновніНарахування)? Якщо так — ФТ-25 і <code>md_register</code> потребують розширення полем <code>base_register_id</code> (див. Д.7.2) || Методолог ЗП / архітектор || До Е7
|-
| В10 || Чи прийнятна поведінка підпорядкованого РВ без контролю унікальності за (Період + Вимірювання)? (сумісність із 1С vs. захист від дублів — див. Д.3.2, антипатерн А-6) || Методолог || До Е2
|-
| В11 || '''Конфігуратор:''' web (FastAPI + React) чи desktop (PySide6/Qt)? Макети розділу 6.8 намальовані як desktop || Замовник / UX || До Е1
|-
| В12 || '''Ключове.''' Прикладний код — повноцінний Python чи обмежений DSL? Повний Python у процесі сервера = виконання довільного коду з правами сервера (ризик Р14) + неможливість статично перевірити конфігурацію партнера || Архітектор + служба безпеки || '''До Е0'''
|-
| В13 || Чи допустимі нативні розширення (Cython/Rust) у складі постачання? Якщо ні — потрібен план «Б» для витіснення (SQL на <code>daterange</code>) || ІТ-експлуатація || До Е7
|-
| В14 || Цільова версія: 3.12 чи 3.13? Чи розглядається free-threaded build (PEP 703) як шлях зняття Р12? || Архітектор || До Е1
|-
| В15 || Мова ідентифікаторів прикладного API: кирилиця (<code>rs.new(Номенклатура=…)</code>) чи транслітерація/англійська? Впливає на ФТ-К-07 і читабельність || Замовник / методолог || До Е2
|}

== Додаток Д. Каталог прикладів регістрів ==

Додаток містить прикладні приклади регістрів усіх типів і підвидів. Для кожного наведено: декларацію (DSL), пояснення проєктних рішень, приклад даних у фізичних таблицях і типовий запит. Приклади призначені для: (а) перевірки повноти метамоделі на етапі Е0; (б) формування набору приймальних тестів; (в) навчання прикладних розробників.

=== Д.1. Як обрати тип регістру (дерево рішень) ===

<graphviz>
digraph Choose {
rankdir=TB; bgcolor="transparent";
node [shape=box, style="rounded,filled", fontname="Helvetica", fontsize=9];
edge [fontname="Helvetica", fontsize=8];

q1 [label="Що зберігаємо?", shape=diamond, fillcolor="#ffe0b2"];
q2 [label="Потрібні залишки\n(скільки Є зараз)?", shape=diamond, fillcolor="#ffe0b2"];
q3 [label="Подвійний запис,\nплан рахунків,\nсубконто?", shape=diamond, fillcolor="#ffe0b2"];
q4 [label="Періоди дії,\nвитіснення,\nбаза розрахунку?", shape=diamond, fillcolor="#ffe0b2"];
q5 [label="Значення прив'язане\nдо документа?", shape=diamond, fillcolor="#ffe0b2"];

ri_i [label="РВ незалежний\n(КурсиВалют,\nШтрихкоди)", fillcolor="#e8f5e9"];
ri_s [label="РВ підпорядкований\n(ЦіниНоменклатури,\nКадровіДані)", fillcolor="#e8f5e9"];
ra_b [label="РН «Залишки»\n(ТовариНаСкладах,\nВзаєморозрахунки)", fillcolor="#fff8e1"];
ra_t [label="РН «Обороти»\n(Продажі,\nВитрати)", fillcolor="#fff8e1"];
rb [label="РБ\n(Госпрозрахунковий)", fillcolor="#fce4ec"];
rc [label="РР\n(Нарахування,\nУтримання)", fillcolor="#ede7f6"];

q1 -> q3 [label="облікові проводки"];
q3 -> rb [label="так"];
q3 -> q4 [label="ні"];
q4 -> rc [label="так"];
q4 -> q2 [label="ні"];

q1 -> q2 [label="кількісні/сумові\nрухи"];
q2 -> ra_b [label="так"];
q2 -> ra_t [label="ні,\nлише обороти\nза період"];

q1 -> q5 [label="значення\nатрибута\nв часі"];
q5 -> ri_s [label="так"];
q5 -> ri_i [label="ні"];
}
</graphviz>

'''Контрольні питання при проєктуванні будь-якого регістру:'''
# Чи можна відповісти на всі прикладні питання ''лише'' полями цього регістру, без з'єднання з документами? Якщо ні — бракує реквізиту (не вимірювання!).
# Яка ''кардинальність'' таблиці підсумків = ∏(кількість значень вимірювань) × кількість періодів? Якщо > 10<sup>8</sup> — переглянути склад вимірювань.
# Чи потрібно фільтрувати/групувати за цим полем у звітах? Так → вимірювання. Ні, лише показувати → реквізит.
# Чи підсумовується поле? Так → ресурс. Ні → реквізит або вимірювання.

=== Д.2. Зведений каталог ===

{| class="wikitable sortable"
! № !! Регістр !! Тип !! Підвид / режим !! Вимірювання !! Ресурси !! Розділ
|-
| 1 || КурсиВалют || РВ || Періодичний (день), незалежний || Валюта || Курс, Кратність || Д.3.1
|-
| 2 || ЦіниНоменклатури || РВ || Періодичний (день), підпорядкований || Номенклатура, Характеристика, ТипЦін || Ціна || Д.3.2
|-
| 3 || ШтрихкодиНоменклатури || РВ || Неперіодичний, незалежний || Штрихкод || Номенклатура, Характеристика, Упаковка || Д.3.3
|-
| 4 || ГрафікРоботи || РВ || Неперіодичний, незалежний || ВидГрафіка, ДатаГрафіка || Значення, Годин || Д.3.4
|-
| 5 || КадровіДані || РВ || По позиції реєстратора, підпорядкований || Співробітник || Підрозділ, Посада, Ставка, ВидЗайнятості || Д.3.5
|-
| 6 || НалаштуванняКористувачів || РВ || Неперіодичний, незалежний || Користувач, Налаштування || Значення (складений) || Д.3.6
|-
| 7 || ТовариНаСкладах || РН || Залишки || Номенклатура, Склад, Партія, Характеристика || Кількість, Сума || Д.4.1
|-
| 8 || ВзаєморозрахункиЗКонтрагентами || РН || Залишки || Організація, Контрагент, Договір, Замовлення || Сума, СумаВал || Д.4.2
|-
| 9 || ТовариВРезерві || РН || Залишки || Номенклатура, Склад, Замовлення, Характеристика || Кількість || Д.4.3
|-
| 10 || ГрошовіКоштиБезготівкові || РН || Залишки || Організація, БанківськийРахунок || Сума, СумаВал || Д.4.4
|-
| 11 || Продажі || РН || Обороти (місяць) + агрегати || Номенклатура, Контрагент, Договір, Менеджер, Склад || Кількість, Сума, СумаБезПДВ, Собівартість || Д.5.1
|-
| 12 || ВитратиЗаСтаттями || РН || Обороти (місяць) || Організація, Підрозділ, СтаттяВитрат, Проєкт || Сума || Д.5.2
|-
| 13 || Госпрозрахунковий || РБ || З кореспонденцією || Організація (бал.), Підрозділ (небал.) || Сума (бал.), Кількість, ВалютнаСума || Д.6.1
|-
| 14 || ПодатковийОблік || РБ || Без кореспонденції || Організація, ВидРізниці || Сума || Д.6.2
|-
| 15 || Бюджетування || РБ || З кореспонденцією || Сценарій, ЦФВ, Проєкт || Сума || Д.6.3
|-
| 16 || ОсновніНарахування || РР || Період дії + база за періодом дії || Співробітник (баз.), Підрозділ || Результат, ВідпрацьованоДнів, НормаДнів || Д.7.1
|-
| 17 || Утримання || РР || Без періоду дії, база за періодом реєстрації || Співробітник (баз.), Підрозділ || Результат, БазаОподаткування || Д.7.2
|}

=== Д.3. Регістри відомостей ===

==== Д.3.1. КурсиВалют — періодичний, незалежний ====

'''Задача:''' зберігати історію курсів валют; отримувати курс на будь-яку дату.

<syntaxhighlight lang="yaml">
register:
name: КурсиВалют
kind: Information
synonym: "Курси валют"
periodicity: WithinDay # один курс на валюту на день
writeMode: Independent # курси вводяться вручну/завантажуються з НБУ
dimensions:
- { name: Валюта, type: "Довідник.Валюти", master: true, denyEmpty: true }
resources:
- { name: Курс, type: "Число(15,4)", denyEmpty: true }
- { name: Кратність, type: "Число(10,0)", default: 1 }
</syntaxhighlight>

'''Проєктні рішення:'''
* <code>Independent</code> — курс не породжується документом, він є зовнішнім фактом.
* <code>master: true</code> для Валюти — при видаленні валюти курси видаляються; регістр видно у формі елемента довідника.
* Періодичність <code>WithinDay</code>, а не <code>WithinSecond</code> — повторний запис курсу за той самий день ''замістить'' попередній, а не створить дубль.

'''Дані у таблиці <code>rg_i_0007</code>:'''
{| class="wikitable"
! period !! d1_r (Валюта) !! r1 (Курс) !! r2 (Кратність)
|-
| 2026-07-15 00:00:00 || USD || 41.8200 || 1
|-
| 2026-07-15 00:00:00 || EUR || 45.6100 || 1
|-
| 2026-07-16 00:00:00 || USD || 41.8500 || 1
|-
| 2026-07-17 00:00:00 || USD || 41.9000 || 1
|-
| 2026-07-17 00:00:00 || EUR || 45.7300 || 1
|}

'''Запит (курс на дату документа):'''
<syntaxhighlight lang="sql">
ВИБРАТИ Курси.Курс, Курси.Кратність
З РегістрВідомостей.КурсиВалют.ЗрізОстанніх(&ДатаДокумента, Валюта = &Валюта) ЯК Курси
</syntaxhighlight>

<syntaxhighlight lang="python">
# або через менеджер
курс = Registers.information("КурсиВалют").get_last(doc.Дата, {"Валюта": doc.Валюта})
сума_грн: Decimal = doc.СумаВалюти * курс.Курс / курс.Кратність
</syntaxhighlight>

==== Д.3.2. ЦіниНоменклатури — періодичний, підпорядкований реєстратору ====

'''Задача:''' зберігати історію цін; ціна встановлюється наказом (документом), який можна скасувати.

<syntaxhighlight lang="yaml">
register:
name: ЦіниНоменклатури
kind: Information
synonym: "Ціни номенклатури"
periodicity: WithinDay
writeMode: SubordinateToRecorder # ← ключова відмінність від КурсиВалют
dimensions:
- { name: Номенклатура, type: "Довідник.Номенклатура", master: true, index: true }
- { name: Характеристика, type: "Довідник.ХарактеристикиНоменклатури", nullable: true }
- { name: ТипЦін, type: "Довідник.ТипиЦін", master: true, denyEmpty: true }
resources:
- { name: Ціна, type: "Число(15,2)", denyEmpty: true }
attributes:
- { name: Валюта, type: "Довідник.Валюти" }
- { name: Одиниця, type: "Довідник.ОдиниціВиміру" }
recorders:
- Документ.ВстановленняЦінНоменклатури
</syntaxhighlight>

'''Проєктні рішення:'''
* <code>SubordinateToRecorder</code> — потрібна юридична прив'язка ціни до наказу, можливість скасувати наказ і «відкотити» ціни одним рухом.
* <code>Валюта</code> і <code>Одиниця</code> — '''реквізити''', а не вимірювання: за ними не фільтрують і не будують зрізи, вони визначаються типом цін. ''Помилка новачка'' — зробити Валюту вимірюванням, що подвоїть кількість записів і зламає зріз останніх.
* <code>Характеристика</code> дозволяє порожнє значення — для номенклатури без характеристик.

'''Дані у таблиці <code>rg_i_0010</code>:'''
{| class="wikitable"
! rec_t !! rec_r !! line_no !! period !! active !! d1_r (Номенкл.) !! d2_r (Характ.) !! d3_r (ТипЦін) !! r1 (Ціна) !! a1_r (Валюта)
|-
| 15 || a3f…01 || 1 || 2026-07-01 || true || Кава Lavazza 1кг || ''(порожня)'' || Роздрібна || 480.00 || UAH
|-
| 15 || a3f…01 || 2 || 2026-07-01 || true || Кава Lavazza 1кг || ''(порожня)'' || Оптова || 410.00 || UAH
|-
| 15 || a3f…01 || 3 || 2026-07-01 || true || Чай Ahmad 100г || ''(порожня)'' || Роздрібна || 95.00 || UAH
|-
| 15 || b7c…04 || 1 || 2026-07-15 || true || Кава Lavazza 1кг || ''(порожня)'' || Роздрібна || 495.00 || UAH
|}

{{Note|Зверніть увагу: у підпорядкованому РВ '''немає''' унікальності за (Період + Вимірювання). Два різні документи можуть встановити ціну на ту саму дату — платформа це дозволить, зріз останніх поверне запис із більшим <code>line_no</code> у межах реєстратора з пізнішою позицією. Це '''свідома''' поведінка (сумісність із 1С), але прикладний розробник має контролювати дублі самостійно — див. антипатерн А-6 (Д.10).}}

==== Д.3.3. ШтрихкодиНоменклатури — неперіодичний, незалежний ====

'''Задача:''' за штрихкодом знайти номенклатуру. Класичний приклад «вимірювання = те, ''за чим'' шукаємо; ресурс = те, що ''знаходимо''».

<syntaxhighlight lang="yaml">
register:
name: ШтрихкодиНоменклатури
kind: Information
periodicity: Nonperiodical
writeMode: Independent
dimensions:
- { name: Штрихкод, type: "Рядок(30)", denyEmpty: true } # ← ключ пошуку
resources:
- { name: Номенклатура, type: "Довідник.Номенклатура", denyEmpty: true }
- { name: Характеристика, type: "Довідник.ХарактеристикиНоменклатури", nullable: true }
- { name: Упаковка, type: "Довідник.УпаковкиНоменклатури", nullable: true }
</syntaxhighlight>

<syntaxhighlight lang="sql">
CREATE TABLE rg_i_0011 (
d1_s varchar(30) NOT NULL, -- Штрихкод
r1_r uuid NOT NULL, -- Номенклатура
r2_r uuid NOT NULL, -- Характеристика
r3_r uuid NOT NULL, -- Упаковка
CONSTRAINT pk_rg_i_0011 PRIMARY KEY (d1_s) -- ← унікальність штрихкоду «безкоштовно»
);
CREATE INDEX ix_rg_i_0011_r1 ON rg_i_0011 (r1_r); -- зворотний пошук: штрихкоди товару
</syntaxhighlight>

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

==== Д.3.4. ГрафікРоботи — неперіодичний, незалежний (використовується як графік для РР) ====

<syntaxhighlight lang="yaml">
register:
name: ГрафікРоботи
kind: Information
periodicity: Nonperiodical
writeMode: Independent
dimensions:
- { name: ВидГрафіка, type: "Довідник.ГрафікиРоботи", master: true, denyEmpty: true }
- { name: ДатаГрафіка, type: "Дата", denyEmpty: true } # ← вимірювання типу Дата, не Період!
resources:
- { name: Значення, type: "Число(1,0)" } # 1 = робочий день, 0 = вихідний
- { name: Годин, type: "Число(4,2)" } # тривалість зміни
</syntaxhighlight>

'''Проєктне рішення (важливе):''' <code>ДатаГрафіка</code> — це '''вимірювання''' типу <code>Дата</code>, а не стандартний реквізит <code>Період</code>. Регістр '''неперіодичний'''. Причина: графік описує ''календар'' (кожна дата — окремий факт), а не ''історію зміни значення''. Якби використали періодичність, зріз останніх повертав би «останній робочий день», що безглуздо. Механізм РР (<code>ДаніГрафіка</code>) очікує саме таку структуру.

'''Дані у таблиці <code>rg_i_0015</code>:'''
{| class="wikitable"
! d1_r (ВидГрафіка) !! d2_d (ДатаГрафіка) !! r1 (Значення) !! r2 (Годин)
|-
| П'ятиденка || 2026-07-01 || 1 || 8.00
|-
| П'ятиденка || 2026-07-04 || 0 || 0.00
|-
| П'ятиденка || 2026-07-05 || 0 || 0.00
|-
| П'ятиденка || 2026-07-06 || 1 || 8.00
|-
| Змінний 2/2 || 2026-07-01 || 1 || 12.00
|-
| Змінний 2/2 || 2026-07-03 || 0 || 0.00
|}

==== Д.3.5. КадровіДані — по позиції реєстратора ====

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

<syntaxhighlight lang="yaml">
register:
name: КадровіДані
kind: Information
periodicity: ByRecorderPosition # ← упорядкування за позицією документа, не лише за датою
writeMode: SubordinateToRecorder
dimensions:
- { name: Співробітник, type: "Довідник.Співробітники", master: true, denyEmpty: true }
resources:
- { name: Підрозділ, type: "Довідник.Підрозділи" }
- { name: Посада, type: "Довідник.Посади" }
- { name: Ставка, type: "Число(5,2)" }
- { name: ВидЗайнятості, type: "Перерахування.ВидиЗайнятості" }
- { name: ГрафікРоботи, type: "Довідник.ГрафікиРоботи" }
recorders:
- Документ.ПрийомНаРоботу
- Документ.КадровеПереміщення
- Документ.Звільнення
</syntaxhighlight>

'''Проєктне рішення:''' <code>ByRecorderPosition</code> — коли два накази оформлені однією датою (переміщення + зміна ставки), звичайна періодичність «у межах дня» дала б недетермінований результат зрізу. Позиція реєстратора додає до ключа <code>(rec_t, rec_r, line_no)</code> і впорядковує за моментом часу документа.

'''Фізична схема:'''
<syntaxhighlight lang="sql">
CREATE TABLE rg_i_0016 (
period timestamp(0) NOT NULL,
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
active boolean NOT NULL DEFAULT true,
d1_r uuid NOT NULL, -- Співробітник
r1_r uuid NOT NULL, r2_r uuid NOT NULL,
r3 numeric(5,2) NOT NULL,
r4 smallint NOT NULL, -- Перерахування зберігається як порядковий номер
r5_r uuid NOT NULL,
CONSTRAINT pk_rg_i_0016 PRIMARY KEY (period, rec_t, rec_r, line_no) -- ← Період у ключі ПЕРШИЙ
);
CREATE INDEX ix_rg_i_0016_d1 ON rg_i_0016 (d1_r, period DESC, rec_t, rec_r, line_no DESC)
WHERE active;
</syntaxhighlight>

==== Д.3.6. НалаштуванняКористувачів — складений тип ресурсу ====

<syntaxhighlight lang="yaml">
register:
name: НалаштуванняКористувачів
kind: Information
periodicity: Nonperiodical
writeMode: Independent
dimensions:
- { name: Користувач, type: "Довідник.Користувачі", master: true }
- { name: Налаштування, type: "ПланВидівХарактеристик.НалаштуванняКористувачів", master: true }
resources:
- name: Значення
type: ["Рядок(500)", "Число(15,2)", "Дата", "Булево",
"Довідник.Організації", "Довідник.Склади"] # ← складений тип
</syntaxhighlight>

<syntaxhighlight lang="sql">
CREATE TABLE rg_i_0018 (
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
r1_t smallint NOT NULL, -- код типу значення
r1_b boolean,
r1_n numeric(15,2),
r1_s varchar(500),
r1_d timestamp(0),
r1_r uuid,
CONSTRAINT pk_rg_i_0018 PRIMARY KEY (d1_r, d2_r)
);
</syntaxhighlight>

{| class="wikitable"
! d1_r !! d2_r !! r1_t !! r1_b !! r1_n !! r1_s !! r1_d !! r1_r
|-
| Іваненко || ОсновнаОрганізація || 101 || || || || || ТОВ «Альфа»
|-
| Іваненко || ОсновнийСклад || 104 || || || || || Центральний
|-
| Іваненко || ПоказуватиПідказки || 2 || true || || || ||
|-
| Петренко || КількістьРядківСписку || 3 || || 50 || || ||
|}

=== Д.4. Регістри накопичення, вид «Залишки» ===

==== Д.4.1. ТовариНаСкладах ====

Декларація — розділ 6.7, фізична схема — розділ 8.5, ER — розділ 9.2. Тут — дані.

'''Рухи (<code>rg_a_0012</code>) після проведення трьох документів:'''
{| class="wikitable"
! rec_t !! rec_r !! line_no !! period !! mvt !! d1_r (Номенкл.) !! d2_r (Склад) !! r1 (К-сть) !! r2 (Сума)
|-
| 2 (ПрихНакл) || p1 || 1 || 2026-06-10 || 0 ''Прихід'' || Кава Lavazza || Центральний || 100.000 || 35 000.00
|-
| 2 (ПрихНакл) || p1 || 2 || 2026-06-10 || 0 ''Прихід'' || Чай Ahmad || Центральний || 200.000 || 12 000.00
|-
| 3 (ВидНакл) || v1 || 1 || 2026-07-05 || 1 ''Витрата'' || Кава Lavazza || Центральний || 30.000 || 10 500.00
|-
| 4 (Переміщ) || m1 || 1 || 2026-07-12 || 1 ''Витрата'' || Кава Lavazza || Центральний || 20.000 || 7 000.00
|-
| 4 (Переміщ) || m1 || 2 || 2026-07-12 || 0 ''Прихід'' || Кава Lavazza || Роздрібний || 20.000 || 7 000.00
|}

'''Підсумки залишків (<code>rg_a_0012_tb</code>), ТА = 2026-07-31:'''
{| class="wikitable"
! period !! d1_r !! d2_r !! r1 (К-сть ±) !! r2 (Сума ±) !! Коментар
|-
| 2026-07-01 || Кава Lavazza || Центральний || 100.000 || 35 000.00 || залишок ''на початок'' липня
|-
| 2026-07-01 || Чай Ahmad || Центральний || 200.000 || 12 000.00 ||
|-
| 2026-08-01 || Кава Lavazza || Центральний || 50.000 || 17 500.00 || 100 − 30 − 20
|-
| 2026-08-01 || Кава Lavazza || Роздрібний || 20.000 || 7 000.00 ||
|-
| 2026-08-01 || Чай Ahmad || Центральний || 200.000 || 12 000.00 ||
|-
| '''5999-11-01''' || Кава Lavazza || Центральний || 50.000 || 17 500.00 || '''MAXPERIOD''' — поточний залишок
|-
| '''5999-11-01''' || Кава Lavazza || Роздрібний || 20.000 || 7 000.00 || '''MAXPERIOD'''
|-
| '''5999-11-01''' || Чай Ahmad || Центральний || 200.000 || 12 000.00 || '''MAXPERIOD'''
|}

''(Вимірювання Партія і Характеристика для стислості опущені.)''

==== Д.4.2. ВзаєморозрахункиЗКонтрагентами ====

'''Задача:''' облік дебіторської/кредиторської заборгованості в розрізі договорів і замовлень.

<syntaxhighlight lang="yaml">
register:
name: ВзаєморозрахункиЗКонтрагентами
kind: Accumulation
accumulationKind: Balance
periodicity: WithinSecond
enableBalanceTotals: true
enableTurnoverTotals: true
partitioning: { mode: RangeByPeriod, step: month }
dimensions:
- { name: Організація, type: "Довідник.Організації", denyEmpty: true, index: true }
- { name: Контрагент, type: "Довідник.Контрагенти", master: true, index: true }
- { name: Договір, type: "Довідник.ДоговориКонтрагентів", master: true, index: true }
- { name: Замовлення, type: ["Документ.ЗамовленняПокупця", "Документ.ЗамовленняПостачальнику"],
nullable: true }
resources:
- { name: Сума, type: "Число(15,2)" } # у валюті регламентованого обліку
- { name: СумаВал, type: "Число(15,2)" } # у валюті договору
attributes:
- { name: Коментар, type: "Рядок(200)" }
recorders:
- Документ.ВидатковаНакладна
- Документ.ПрихіднаНакладна
- Документ.ПлатіжнеДоручення
- Документ.КасовийОрдер
- Документ.КоригуванняБоргу
</syntaxhighlight>

'''Угода про знак (обов'язково фіксується в методології!):'''
{| class="wikitable"
! Вид руху !! Сенс !! Приклад документа
|-
| '''Прихід''' || Борг контрагента перед нами '''зростає''' (дебіторка +) || Видаткова накладна
|-
| '''Витрата''' || Борг контрагента перед нами '''зменшується''' (оплата) || Платіжне доручення вхідне
|}
Кредиторська заборгованість = від'ємний залишок. ''Альтернатива'' — два окремих ресурси (СумаДт/СумаКт) або два регістри; обраний варіант — один знаковий ресурс (простіше, менший обсяг підсумків).

'''Приклад даних:'''
{| class="wikitable"
! Документ !! period !! mvt !! Контрагент !! Договір !! r1 (Сума) !! Залишок після
|-
| ВидатковаНакладна №12 || 2026-07-05 || Прихід || ТОВ «Бета» || Основний || 12 000.00 || +12 000 ''(винні нам)''
|-
| ПлатіжнеДоручення №88 || 2026-07-09 || Витрата || ТОВ «Бета» || Основний || 8 000.00 || +4 000
|-
| ПлатіжнеДоручення №91 || 2026-07-16 || Витрата || ТОВ «Бета» || Основний || 6 000.00 || −2 000 ''(передоплата)''
|}

'''Запит (акт звірки):'''
<syntaxhighlight lang="sql">
ВИБРАТИ
Дані.Контрагент, Дані.Договір,
Дані.СумаПочатковийЗалишок, Дані.СумаПрихід,
Дані.СумаВитрата, Дані.СумаКінцевийЗалишок
З РегістрНакопичення.ВзаєморозрахункиЗКонтрагентами.ЗалишкиІОбороти(
&Початок, &Кінець, Авто, Рух,
Організація = &Організація І Контрагент = &Контрагент
) ЯК Дані
</syntaxhighlight>

==== Д.4.3. ТовариВРезерві — регістр «супутник» ====

<syntaxhighlight lang="yaml">
register:
name: ТовариВРезерві
kind: Accumulation
accumulationKind: Balance
periodicity: WithinSecond
dimensions:
- { name: Номенклатура, type: "Довідник.Номенклатура", master: true, index: true }
- { name: Характеристика, type: "Довідник.ХарактеристикиНоменклатури", nullable: true }
- { name: Склад, type: "Довідник.Склади", master: true, index: true }
- { name: Замовлення, type: "Документ.ЗамовленняПокупця", master: true, denyEmpty: true }
resources:
- { name: Кількість, type: "Число(15,3)" }
recorders:
- Документ.ЗамовленняПокупця
- Документ.ВидатковаНакладна
- Документ.ЗакриттяЗамовлень
</syntaxhighlight>

'''Патерн «доступний залишок»''' — з'єднання двох регістрів:
<syntaxhighlight lang="sql">
ВИБРАТИ
ЄСТЬNULL(Зал.Номенклатура, Рез.Номенклатура) ЯК Номенклатура,
ЄСТЬNULL(Зал.Склад, Рез.Склад) ЯК Склад,
ЄСТЬNULL(Зал.КількістьЗалишок, 0) ЯК ВСкладі,
ЄСТЬNULL(Рез.КількістьЗалишок, 0) ЯК ВРезерві,
ЄСТЬNULL(Зал.КількістьЗалишок, 0) - ЄСТЬNULL(Рез.КількістьЗалишок, 0) ЯК Доступно
З РегістрНакопичення.ТовариНаСкладах.Залишки(&Період, Склад = &Склад) ЯК Зал
ПОВНЕ З'ЄДНАННЯ РегістрНакопичення.ТовариВРезерві.Залишки(&Період, Склад = &Склад) ЯК Рез
ЗА Зал.Номенклатура = Рез.Номенклатура І Зал.Склад = Рез.Склад
</syntaxhighlight>

{{Note|Чому окремий регістр, а не ресурс «Резерв» у <code>ТовариНаСкладах</code>? Тому що резерв ведеться в розрізі '''Замовлення''', а залишок — у розрізі '''Партії'''. Додавання Замовлення як вимірювання до <code>ТовариНаСкладах</code> помножило б таблицю підсумків на кардинальність замовлень (сотні тисяч рядків на товар). Це ілюстрація контрольного питання №2 з Д.1.}}

==== Д.4.4. ГрошовіКоштиБезготівкові ====

<syntaxhighlight lang="yaml">
register:
name: ГрошовіКоштиБезготівкові
kind: Accumulation
accumulationKind: Balance
periodicity: WithinDay # достатньо дня: банківська виписка — денна
dimensions:
- { name: Організація, type: "Довідник.Організації", denyEmpty: true }
- { name: БанківськийРахунок, type: "Довідник.БанківськіРахунки", master: true, denyEmpty: true }
resources:
- { name: Сума, type: "Число(15,2)" }
- { name: СумаВал, type: "Число(15,2)" }
recorders: [Документ.ПлатіжнеДоручення, Документ.БанківськаВиписка, Документ.ПереміщенняКоштів]
</syntaxhighlight>

'''Проєктне рішення:''' Валюта — '''не''' вимірювання, тому що вона однозначно визначається банківським рахунком (функціональна залежність). Її додавання як вимірювання створило б надлишковість і ризик неузгоджених даних. Валюта отримується з'єднанням із довідником.

=== Д.5. Регістри накопичення, вид «Обороти» ===

==== Д.5.1. Продажі — з агрегатами ====

<syntaxhighlight lang="yaml">
register:
name: Продажі
kind: Accumulation
accumulationKind: Turnover # ← залишків не буває: «залишок продажів» безглуздий
periodicity: WithinSecond
turnoverTotalsPeriod: Month
aggregatesMode: Aggregates
partitioning: { mode: RangeByPeriod, step: month }
dimensions:
- { name: Номенклатура, type: "Довідник.Номенклатура", index: true }
- { name: Характеристика, type: "Довідник.ХарактеристикиНоменклатури", nullable: true }
- { name: Контрагент, type: "Довідник.Контрагенти", index: true }
- { name: Договір, type: "Довідник.ДоговориКонтрагентів" }
- { name: Менеджер, type: "Довідник.Користувачі", index: true }
- { name: Склад, type: "Довідник.Склади" }
resources:
- { name: Кількість, type: "Число(15,3)" }
- { name: Сума, type: "Число(15,2)" }
- { name: СумаБезПДВ, type: "Число(15,2)" }
- { name: Собівартість, type: "Число(15,2)" }
recorders: [Документ.ВидатковаНакладна, Документ.ПовернненняВідПокупця, Документ.ЗвітПроРоздрібніПродажі]

aggregates:
- name: ПродажіПоМісяцяхІТоварах
periodicity: Month
dimensions: [Номенклатура, Склад]
realtime: true
- name: ПродажіПоМенеджерах
periodicity: Day
dimensions: [Менеджер]
realtime: false # оновлюється регламентно
- name: ПродажіПоКонтрагентах
periodicity: Quarter
dimensions: [Контрагент, Договір]
realtime: false
</syntaxhighlight>

'''Проєктні рішення:'''
* <code>Turnover</code>, а не <code>Balance</code>: немає <code>ВидРуху</code>, немає таблиці залишків → удвічі менше підсумків і немає кумулятивних оновлень. Повернення відображається '''від'ємною''' сумою, а не «витратою».
* 6 вимірювань → таблиця підсумків надто широка для швидких звітів → компенсуємо агрегатами.

'''Ефект агрегатів:'''
{| class="wikitable"
! Звіт !! Без агрегатів (<code>rg_a_0031_tt</code>) !! З агрегатом !! Виграш
|-
| Продажі по товарах за рік || скан 8 млн рядків підсумків || <code>ag1</code>: 40 тис. рядків || ×200
|-
| Рейтинг менеджерів за квартал || скан 8 млн рядків || <code>ag2</code>: 1,8 тис. рядків || ×4000
|-
| Продажі по контрагенту за 3 роки || скан 8 млн рядків || <code>ag3</code>: 60 тис. рядків || ×130
|-
| Продажі по товару + контрагенту || '''агрегат не покриває''' → підсумки || — || —
|}

<syntaxhighlight lang="sql">
CREATE TABLE rg_a_0031_ag1 ( -- Місяць × (Номенклатура, Склад)
period timestamp(0) NOT NULL, d1_r uuid NOT NULL, d6_r uuid NOT NULL,
r1 numeric(20,3) NOT NULL, r2 numeric(20,2) NOT NULL,
r3 numeric(20,2) NOT NULL, r4 numeric(20,2) NOT NULL,
CONSTRAINT pk_rg_a_0031_ag1 PRIMARY KEY (period, d1_r, d6_r)
);
CREATE TABLE rg_a_0031_ag2 ( -- День × (Менеджер)
period timestamp(0) NOT NULL, d5_r uuid NOT NULL,
r1 numeric(20,3) NOT NULL, r2 numeric(20,2) NOT NULL,
r3 numeric(20,2) NOT NULL, r4 numeric(20,2) NOT NULL,
CONSTRAINT pk_rg_a_0031_ag2 PRIMARY KEY (period, d5_r)
);
</syntaxhighlight>

==== Д.5.2. ВитратиЗаСтаттями ====

<syntaxhighlight lang="yaml">
register:
name: ВитратиЗаСтаттями
kind: Accumulation
accumulationKind: Turnover
periodicity: WithinDay
turnoverTotalsPeriod: Month
dimensions:
- { name: Організація, type: "Довідник.Організації", denyEmpty: true }
- { name: Підрозділ, type: "Довідник.Підрозділи", index: true }
- { name: СтаттяВитрат, type: "Довідник.СтаттіВитрат", master: true, denyEmpty: true, index: true }
- { name: Проєкт, type: "Довідник.Проєкти", nullable: true }
resources:
- { name: Сума, type: "Число(15,2)" }
recorders: [Документ.АвансовийЗвіт, Документ.НадходженняПослуг, Документ.НарахуванняЗарплати, Документ.Амортизація]
</syntaxhighlight>

'''Приклад даних (<code>rg_a_0032_tt</code>, підсумки оборотів за місяць):'''
{| class="wikitable"
! period !! Підрозділ !! СтаттяВитрат !! Проєкт !! r1 (Сума)
|-
| 2026-07-01 || Відділ продажів || Оренда || ''(порожній)'' || 45 000.00
|-
| 2026-07-01 || Відділ продажів || ЗП і нарахування || ''(порожній)'' || 320 000.00
|-
| 2026-07-01 || Відділ продажів || Реклама || Запуск «Альфа» || 78 000.00
|-
| 2026-07-01 || ІТ-відділ || ЗП і нарахування || ''(порожній)'' || 410 000.00
|-
| 2026-07-01 || ІТ-відділ || Ліцензії ПЗ || ''(порожній)'' || 62 000.00
|}

=== Д.6. Регістри бухгалтерії ===

==== Д.6.1. Госпрозрахунковий — з кореспонденцією ====

Декларація — розділ 6.7, схема — 8.6, ER — 9.3. Тут — приклад проводок.

'''Господарська операція:''' реалізація товару на 12 000 грн (у т.ч. ПДВ 2 000), собівартість 7 000 грн.

'''Проводки (<code>rg_b_0020</code>, реєстратор = ВидатковаНакладна №12):'''
{| class="wikitable"
! line !! acc_dt !! ed_dt1 !! ed_dt2 !! acc_kt !! ed_kt1 !! ed_kt2 !! r1 (Сума) !! r2_dt !! r2_kt
|-
| 1 || 361 ''Розрах. з покупцями'' || ТОВ «Бета» || Договір №5 || 702 ''Дохід від реалізації'' || Кава Lavazza || ''—'' || 12 000.00 || || 30.000
|-
| 2 || 702 ''Дохід від реалізації'' || Кава Lavazza || ''—'' || 641 ''Розрах. за податками'' || ПДВ || ''—'' || 2 000.00 || ||
|-
| 3 || 902 ''Собівартість реалізації'' || Кава Lavazza || ''—'' || 281 ''Товари на складі'' || Кава Lavazza || Центральний || 7 000.00 || 30.000 || 30.000
|}

'''Контроль:''' Σ(Сума) по Дт = Σ(Сума) по Кт у межах реєстратора → 12 000 + 2 000 + 7 000 = 21 000 з обох боків. ✔

'''Підсумки, рівень 0 (<code>rg_b_0020_tb0</code>), на 5999-11-01:'''
{| class="wikitable"
! acc_r !! d1_r (Організація) !! r1 (Сума ±) !! Інтерпретація
|-
| 281 || ТОВ «Альфа» || +28 000.00 || дебетовий залишок (товари є)
|-
| 361 || ТОВ «Альфа» || +12 000.00 || дебетовий (дебіторка)
|-
| 641 || ТОВ «Альфа» || −2 000.00 || кредитовий (винні бюджету)
|-
| 702 || ТОВ «Альфа» || −10 000.00 || кредитовий (дохід)
|-
| 902 || ТОВ «Альфа» || +7 000.00 || дебетовий (собівартість)
|}

'''Підсумки, рівень 2 (<code>rg_b_0020_tb2</code>) — для рахунку 281 (2 субконто: Номенклатура, Склад):'''
{| class="wikitable"
! acc_r !! ed1_r (Номенклатура) !! ed2_r (Склад) !! r1 (Сума) !! r2 (Кількість)
|-
| 281 || Кава Lavazza || Центральний || 17 500.00 || 50.000
|-
| 281 || Кава Lavazza || Роздрібний || 7 000.00 || 20.000
|-
| 281 || Чай Ahmad || Центральний || 12 000.00 || 200.000
|}
Згортка <code>tb2</code> → <code>tb0</code>: 17 500 + 7 000 + 12 000 = '''36 500'''… ''(різниця з таблицею вище — інші операції; у тесті ФТ-Т-08 перевіряється точна рівність)''.

'''Запит (ОСВ по рахунку):'''
<syntaxhighlight lang="sql">
ВИБРАТИ
Дані.Субконто1 ЯК Номенклатура, Дані.Субконто2 ЯК Склад,
Дані.СумаПочатковийЗалишокДт, Дані.КількістьПочатковийЗалишокДт,
Дані.СумаОборотДт, Дані.СумаОборотКт,
Дані.СумаКінцевийЗалишокДт, Дані.КількістьКінцевийЗалишокДт
З РегістрБухгалтерії.Госпрозрахунковий.ЗалишкиІОбороти(
&Початок, &Кінець, Місяць,
Рахунок = &Рахунок281,
, Організація = &Організація,
,
) ЯК Дані
</syntaxhighlight>

==== Д.6.2. ПодатковийОблік — без кореспонденції ====

'''Задача:''' податковий облік із розділенням на постійні/тимчасові різниці, де подвійний запис не потрібен (кожен факт реєструється окремо по Дт або по Кт).

<syntaxhighlight lang="yaml">
register:
name: ПодатковийОблік
kind: Accounting
chartOfAccounts: ПланРахунків.Податковий
correspondence: false # ← уніграфічний облік
periodicity: WithinSecond
dimensions:
- { name: Організація, type: "Довідник.Організації", balance: true, denyEmpty: true }
- { name: ВидРізниці, type: "Перерахування.ВидиРізниць", balance: true } # БУ|ПУ|ПР|ТР
resources:
- { name: Сума, type: "Число(15,2)", balance: true }
attributes:
- { name: Зміст, type: "Рядок(255)" }
recorders: [Документ.БухгалтерськаОперація, Документ.ВидатковаНакладна, Документ.НадходженняПослуг]
</syntaxhighlight>

'''Проводки (<code>rg_b_0021</code>):'''
{| class="wikitable"
! line !! acc_mvt !! acc_r !! ed1 (Номенкл.) !! d1 (Організація) !! d2 (ВидРізниці) !! r1 (Сума)
|-
| 1 || 0 ''Дебет'' || 902.НУ || Кава Lavazza || ТОВ «Альфа» || ПУ ''податковий'' || 7 000.00
|-
| 2 || 1 ''Кредит'' || 281.НУ || Кава Lavazza || ТОВ «Альфа» || ПУ || 7 000.00
|-
| 3 || 0 ''Дебет'' || 902.НУ || Кава Lavazza || ТОВ «Альфа» || ПР ''постійна різниця'' || 350.00
|-
| 4 || 1 ''Кредит'' || 281.НУ || Кава Lavazza || ТОВ «Альфа» || ПР || 350.00
|}

'''Відмінності від Д.6.1:'''
{| class="wikitable"
! !! З кореспонденцією !! Без кореспонденції
|-
| Один факт = || 1 запис (Дт+Кт) || 2 записи (окремо Дт, окремо Кт)
|-
| Поля рахунків || <code>acc_dt_r</code>, <code>acc_kt_r</code> || <code>acc_r</code> + <code>acc_mvt</code>
|-
| Субконто || 2 набори (Дт, Кт) || 1 набір
|-
| Кількість записів || N || 2N
|-
| Таблиця <code>_tc</code> (кореспонденції) || Є || '''Немає''' — «шахова відомість» неможлива
|-
| Контроль Дт=Кт || У межах реєстратора || Опційно (може бути незбалансовано за задумом)
|-
| Коли обирати || Класичний облік, потрібен аналіз кореспонденцій || Облік без потреби в кореспонденціях, забалансовий, статистичний
|}

==== Д.6.3. Бюджетування ====

<syntaxhighlight lang="yaml">
register:
name: Бюджетування
kind: Accounting
chartOfAccounts: ПланРахунків.Бюджетування
correspondence: true
periodicity: WithinMonth # бюджет — помісячний, до секунди не потрібно
dimensions:
- { name: Сценарій, type: "Довідник.СценаріїБюджетування", balance: true, denyEmpty: true }
- { name: ЦФВ, type: "Довідник.ЦентриФінансовоїВідповідальності", balance: true }
- { name: Проєкт, type: "Довідник.Проєкти", balance: true, nullable: true }
resources:
- { name: Сума, type: "Число(15,2)", balance: true }
recorders: [Документ.БюджетнаОперація, Документ.ВведенняБюджету]
</syntaxhighlight>

'''Проєктне рішення:''' <code>Сценарій</code> — вимірювання, а не окремий регістр на кожен сценарій (План/Факт/Прогноз). Це дозволяє план-фактний аналіз одним запитом. Усі три вимірювання '''балансові''' — бюджетна проводка не змінює сценарій/ЦФВ між дебетом і кредитом.

=== Д.7. Регістри розрахунку ===

==== Д.7.1. ОсновніНарахування — період дії + витіснення ====

'''План видів розрахунку <code>ОсновніНарахування</code>:'''
{| class="wikitable"
! Вид розрахунку !! Період дії !! Витісняючі !! Базові !! Залежність від бази
|-
| Оклад || Так || Відпустка, Лікарняний || — || Не залежить
|-
| Відпустка || Так || Лікарняний || Оклад, Премія || За періодом дії
|-
| Лікарняний || Так || — || Оклад || За періодом дії
|-
| Премія || Ні || — || Оклад || За періодом реєстрації
|}

Декларація регістру — розділ 6.7.

'''Записи (<code>rg_c_0040</code>), період реєстрації = липень 2026:'''
{| class="wikitable"
! line !! calc_type !! period !! act_begin !! act_end !! base_begin !! base_end !! d1 (Співробітник) !! r1 (Результат)
|-
| 1 || Оклад || 2026-07-01 || 2026-07-01 || 2026-07-31 || || || Іваненко || 18 000.00
|-
| 2 || Відпустка || 2026-07-01 || 2026-07-10 || 2026-07-17 || 2026-01-01 || 2026-06-30 || Іваненко || 6 420.00
|-
| 3 || Лікарняний || 2026-07-01 || 2026-07-14 || 2026-07-22 || 2026-01-01 || 2026-06-30 || Іваненко || 5 180.00
|-
| 4 || Оклад || 2026-07-01 || 2026-07-01 || 2026-07-31 || || || Петренко || 22 000.00
|}

'''Фактичні періоди дії (<code>rg_c_0040_ap</code>) — результат витіснення:'''
{| class="wikitable"
! rec/line !! interval_no !! calc_type !! d1 !! fact_begin !! fact_end !! Коментар
|-
| n1 / 1 || 0 || Оклад || Іваненко || 2026-07-01 || 2026-07-09 || до відпустки
|-
| n1 / 1 || 1 || Оклад || Іваненко || 2026-07-23 || 2026-07-31 || після лікарняного
|-
| n1 / 2 || 0 || Відпустка || Іваненко || 2026-07-10 || 2026-07-13 || витіснена лікарняним з 14-го
|-
| n1 / 3 || 0 || Лікарняний || Іваненко || 2026-07-14 || 2026-07-22 || не витісняється нічим
|-
| n1 / 4 || 0 || Оклад || Петренко || 2026-07-01 || 2026-07-31 || витіснення відсутнє
|}

'''Один запис «Оклад» Іваненка → два інтервали''' — ілюстрація зв'язку 1:N у розділі 9.4.

'''Запит (дані графіка для розрахунку окладу):'''
<syntaxhighlight lang="sql">
ВИБРАТИ
Дані.Співробітник, Дані.НомерРядка,
Дані.ЗначенняФактичногоПеріодуДії ЯК ВідпрацьованоДнів,
Дані.ЗначенняПеріодуДії ЯК НормаДнів
З РегістрРозрахунку.ОсновніНарахування.ДаніГрафіка(
ВидРозрахунку = ЗНАЧЕННЯ(ПланВидівРозрахунку.ОсновніНарахування.Оклад)
І Реєстратор = &Реєстратор
) ЯК Дані
</syntaxhighlight>
'''Результат:''' Іваненко — <code>ВідпрацьованоДнів = 13</code> (робочі дні у 01–09 та 23–31), <code>НормаДнів = 23</code> → Оклад = 18 000 × 13 / 23 = '''10 173,91'''.

'''Запит (база для відпустки):'''
<syntaxhighlight lang="sql">
ВИБРАТИ База.Співробітник, База.НомерРядка, База.РезультатБаза ЯК Заробіток
З РегістрРозрахунку.ОсновніНарахування.БазаРозрахунку(
, /* вимірювання бази */
, /* вимірювання основного регістру */
Співробітник, /* розрізи */
ВидРозрахунку = ЗНАЧЕННЯ(ПланВидівРозрахунку.ОсновніНарахування.Відпустка)
) ЯК База
</syntaxhighlight>

==== Д.7.2. Утримання — без періоду дії, база за періодом реєстрації ====

'''План видів розрахунку <code>Утримання</code>:'''
{| class="wikitable"
! Вид розрахунку !! Період дії !! Базові види розрахунку !! Залежність
|-
| ПДФО || Ні || ''(усі з ПВР ОсновніНарахування)'' || За періодом реєстрації
|-
| Військовий збір || Ні || ''(усі з ПВР ОсновніНарахування)'' || За періодом реєстрації
|-
| Аліменти || Ні || Оклад, Премія, Відпустка || За періодом реєстрації
|-
| Профспілковий внесок || Ні || Оклад || За періодом реєстрації
|}

<syntaxhighlight lang="yaml">
register:
name: Утримання
kind: Calculation
calculationTypesPlan: ПланВидівРозрахунку.Утримання
periodicity: Month
actionPeriod: false # ← утримання не має періоду дії
basePeriod: ByRegistrationPeriod # ← база береться за періодом реєстрації
# schedule: не задається — графік не потрібен
dimensions:
- { name: Співробітник, type: "Довідник.Співробітники", baseDimension: true, master: true, denyEmpty: true }
- { name: Підрозділ, type: "Довідник.Підрозділи" }
resources:
- { name: Результат, type: "Число(15,2)" }
- { name: БазаОподаткування, type: "Число(15,2)" }
recalculations:
- name: ПерерахунокУтримань
dimensions:
- { name: Співробітник, registerDimension: Співробітник }
recorders: [Документ.НарахуванняЗарплати]
</syntaxhighlight>

'''Фізична схема (спрощена — немає полів періоду дії):'''
<syntaxhighlight lang="sql">
CREATE TABLE rg_c_0041 (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
period timestamp(0) NOT NULL, -- період реєстрації
active boolean NOT NULL DEFAULT true,
reversal boolean NOT NULL DEFAULT false,
calc_type_r uuid NOT NULL,
base_begin timestamp(0) NOT NULL, -- ← є, бо basePeriod ≠ None
base_end timestamp(0) NOT NULL,
-- act_begin / act_end ВІДСУТНІ (actionPeriod: false)
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
r1 numeric(15,2) NOT NULL DEFAULT 0,
r2 numeric(15,2) NOT NULL DEFAULT 0,
CONSTRAINT pk_rg_c_0041 PRIMARY KEY (rec_t, rec_r, line_no)
);
-- Таблиця rg_c_0041_ap НЕ створюється (немає періоду дії → немає витіснення)
CREATE TABLE rg_c_0041_rc1 ( -- ПерерахунокУтримань
rec_t smallint NOT NULL, rec_r uuid NOT NULL,
calc_type_r uuid NOT NULL, d1_r uuid NOT NULL,
src_rec_t smallint NOT NULL, src_rec_r uuid NOT NULL,
created_at timestamp(0) NOT NULL DEFAULT now(),
CONSTRAINT pk_rg_c_0041_rc1 PRIMARY KEY (rec_t, rec_r, calc_type_r, d1_r)
);
</syntaxhighlight>

{{Note|'''Міжпланова база.''' Базові види розрахунку для ПВР <code>Утримання</code> належать до ''іншого'' ПВР — <code>ОсновніНарахування</code>. Це означає, що віртуальна таблиця <code>БазаРозрахунку</code> регістру <code>Утримання</code> має читати записи регістру <code>ОсновніНарахування</code>. '''Вимога ФТ-25 має бути розширена:''' метамодель повинна дозволяти вказати ''регістр-джерело бази''. Це '''відкрите питання В9''' (див. оновлений Додаток Г) — у 1С механізм працює через відповідність ПВР, а не регістрів, що обмежує сценарії. Пропозиція: додати до <code>md_register</code> поле <code>base_register_id</code>.}}

'''Приклад даних:'''
{| class="wikitable"
! line !! calc_type !! period !! base_begin !! base_end !! Співробітник !! r2 (База) !! r1 (Результат)
|-
| 1 || ПДФО || 2026-07-01 || 2026-07-01 || 2026-07-31 || Іваненко || 21 773.91 || 3 919.30
|-
| 2 || Військовий збір || 2026-07-01 || 2026-07-01 || 2026-07-31 || Іваненко || 21 773.91 || 326.61
|-
| 3 || Аліменти || 2026-07-01 || 2026-07-01 || 2026-07-31 || Іваненко || 17 528.00 || 4 382.00
|}

=== Д.8. Наскрізний приклад: проведення видаткової накладної ===

'''Документ:''' Видаткова накладна №12 від 05.07.2026, ТОВ «Бета», 30 кг кави за 400 грн (12 000 грн з ПДВ), собівартість 7 000 грн.

<graphviz>
digraph Posting {
rankdir=LR; bgcolor="transparent";
node [shape=box, style="rounded,filled", fontname="Helvetica", fontsize=9];

D [label="Документ\nВидаткова накладна №12\n05.07.2026", fillcolor="#fff8e1", shape=note];

R1 [label="РН ТовариНаСкладах\n(Залишки)\nВитрата: 30 кг / 7 000 грн", fillcolor="#fff3e0"];
R2 [label="РН Взаєморозрахунки\n(Залишки)\nПрихід: 12 000 грн", fillcolor="#fff3e0"];
R3 [label="РН Продажі\n(Обороти)\n30 кг / 12 000 / 10 000 / 7 000", fillcolor="#fff3e0"];
R4 [label="РН ТовариВРезерві\n(Залишки)\nВитрата: 30 кг", fillcolor="#fff3e0"];
R5 [label="РБ Госпрозрахунковий\n3 проводки на 21 000", fillcolor="#fce4ec"];

T1 [label="rg_a_0012_tb\nMAXPERIOD: 80 → 50 кг", fillcolor="#ffe0b2", shape=cylinder];
T2 [label="rg_a_0013_tb\nMAXPERIOD: 0 → +12 000", fillcolor="#ffe0b2", shape=cylinder];
T3 [label="rg_a_0031_tt\n2026-07: +30 / +12 000", fillcolor="#ffe0b2", shape=cylinder];
T5 [label="rg_b_0020_tb0/tb2/tt0/tc", fillcolor="#f8bbd0", shape=cylinder];

D -> R1; D -> R2; D -> R3; D -> R4; D -> R5;
R1 -> T1; R2 -> T2; R3 -> T3; R5 -> T5;

label="ОДНА транзакція БД: усі 5 регістрів + підсумки + прапорець Проведений";
labelloc=b; fontname="Helvetica"; fontsize=10;
}
</graphviz>

<syntaxhighlight lang="python">
class ВидатковаНакладна(Document):
"""Проведення по 5 регістрах в одній транзакції. Бюджет Python: <= 15 мс (АП-4)."""

def on_posting(self, ctx: PostingContext) -> None:
# --- 0. Блокування перед контролем залишків ---
with DataLock() as dl:
li = dl.add("РегістрНакопичення.ТовариНаСкладах.Залишки")
li.mode = DataLockMode.EXCLUSIVE
li.data_source = self.Товари.unload("Номенклатура", "Характеристика")
li.use_from_data_source("Номенклатура", "Номенклатура")
li.use_from_data_source("Характеристика", "Характеристика")
li.set_value("Склад", self.Склад)

self._movements_goods() # 1. ТовариНаСкладах
self._movements_ar() # 2. Взаєморозрахунки
self._movements_sales() # 3. Продажі
self._movements_reserve() # 4. ТовариВРезерві
self._movements_accounting() # 5. Госпрозрахунковий

self.movements.ТовариНаСкладах.write_now()
self._control_negative_balances(ctx)

# --- 1. РН ТовариНаСкладах: списання ---
def _movements_goods(self) -> None:
rs = self.movements.ТовариНаСкладах
rs.write = True
rs.clear()
rs.extend(
rs.new(Період=self.Дата,
ВидРуху=AccumulationMovementType.EXPENSE,
Номенклатура=r.Номенклатура, Характеристика=r.Характеристика,
Склад=self.Склад, Партія=r.Партія,
Кількість=r.Кількість, Сума=r.Собівартість)
for r in self.Товари
)

# --- 2. РН Взаєморозрахунки: дебіторка зростає ---
def _movements_ar(self) -> None:
rs = self.movements.ВзаєморозрахункиЗКонтрагентами
rs.write = True
rs.clear()
rs.append(rs.new(
Період=self.Дата,
ВидРуху=AccumulationMovementType.RECEIPT, # Прихід = борг зростає
Організація=self.Організація, Контрагент=self.Контрагент,
Договір=self.Договір, Замовлення=self.ЗамовленняПокупця,
Сума=self.СумаДокумента, СумаВал=self.СумаДокументаВал,
))

# --- 3. РН Продажі: оборот (ВидРуху відсутній!) ---
def _movements_sales(self) -> None:
rs = self.movements.Продажі
rs.write = True
rs.clear()
rs.extend(
rs.new(Період=self.Дата,
Номенклатура=r.Номенклатура, Контрагент=self.Контрагент,
Договір=self.Договір, Менеджер=self.Менеджер, Склад=self.Склад,
Кількість=r.Кількість, Сума=r.Сума,
СумаБезПДВ=r.СумаБезПДВ, Собівартість=r.Собівартість)
for r in self.Товари
)

# --- 4. РН ТовариВРезерві: зняття резерву ---
def _movements_reserve(self) -> None:
if self.ЗамовленняПокупця.is_empty():
return
rs = self.movements.ТовариВРезерві
rs.write = True
rs.clear()
rs.extend(
rs.new(Період=self.Дата, ВидРуху=AccumulationMovementType.EXPENSE,
Номенклатура=r.Номенклатура, Характеристика=r.Характеристика,
Склад=self.Склад, Замовлення=self.ЗамовленняПокупця,
Кількість=r.Кількість)
for r in self.Товари
)

# --- 5. РБ Госпрозрахунковий: 3 проводки на рядок ---
def _movements_accounting(self) -> None:
rs = self.movements.Госпрозрахунковий
rs.write = True
rs.clear()
for r in self.Товари:
e1 = rs.add_accounting_entry( # Дт 361 / Кт 702
Період=self.Дата, Організація=self.Організація,
РахунокДт=Accounts["361"], РахунокКт=Accounts["702"],
Сума=r.Сума, КількістьКт=r.Кількість)
e1.subconto_dt[ВидиСубконто.Контрагенти] = self.Контрагент
e1.subconto_dt[ВидиСубконто.Договори] = self.Договір
e1.subconto_kt[ВидиСубконто.Номенклатура] = r.Номенклатура

e2 = rs.add_accounting_entry( # Дт 702 / Кт 641 (ПДВ)
Період=self.Дата, Організація=self.Організація,
РахунокДт=Accounts["702"], РахунокКт=Accounts["641"],
Сума=r.СумаПДВ)
e2.subconto_dt[ВидиСубконто.Номенклатура] = r.Номенклатура
e2.subconto_kt[ВидиСубконто.ПодаткиІЗбори] = Taxes.ПДВ

e3 = rs.add_accounting_entry( # Дт 902 / Кт 281
Період=self.Дата, Організація=self.Організація,
РахунокДт=Accounts["902"], РахунокКт=Accounts["281"],
Сума=r.Собівартість,
КількістьДт=r.Кількість, КількістьКт=r.Кількість)
e3.subconto_dt[ВидиСубконто.Номенклатура] = r.Номенклатура
e3.subconto_kt[ВидиСубконто.Номенклатура] = r.Номенклатура
e3.subconto_kt[ВидиСубконто.Склади] = self.Склад
</syntaxhighlight>

'''Що відбувається у БД (одна транзакція):'''
{| class="wikitable"
! Крок !! Таблиця !! Операція !! Рядків
|-
| 1 || <code>doc_0003</code> || UPDATE posted = true || 1
|-
| 2 || <code>rg_a_0012</code> (ТовариНаСкладах) || DELETE + INSERT || 1
|-
| 3 || <code>rg_a_0012_tb</code> || MERGE (MAXPERIOD + періоди > 07.2026) || 2
|-
| 4 || <code>rg_a_0013</code> (Взаєморозрахунки) || DELETE + INSERT || 1
|-
| 5 || <code>rg_a_0013_tb</code> || MERGE || 2
|-
| 6 || <code>rg_a_0031</code> (Продажі) || DELETE + INSERT || 1
|-
| 7 || <code>rg_a_0031_tt</code> || MERGE (тільки період 2026-07) || 1
|-
| 8 || <code>rg_a_0031_ag1</code> || MERGE (realtime-агрегат) || 1
|-
| 9 || <code>rg_a_0014</code> (Резерв) || DELETE + INSERT || 1
|-
| 10 || <code>rg_b_0020</code> (проводки) || DELETE + INSERT || 3
|-
| 11 || <code>rg_b_0020_tb0</code> || MERGE || 10
|-
| 12 || <code>rg_b_0020_tb1/tb2</code> || MERGE || 8
|-
| 13 || <code>rg_b_0020_tt0..tt2</code> || MERGE || 12
|-
| 14 || <code>rg_b_0020_tc</code> || MERGE || 3
|-
| colspan="3" | '''Разом''' || '''≈ 47 рядків, 1 COMMIT'''
|}

{{Note|'''Спостереження для НФВ-04.''' Один рядок товару в накладній породжує ~47 модифікацій рядків у 14 таблицях. Для накладної зі 100 рядків це ~2 000–4 000 модифікацій. Саме тут — основне навантаження проведення, і саме тому РБ (кроки 10–14) дає ~70 % вартості транзакції. Це аргумент на користь MVP без РБ (розділ 14) і предмет вимірювання в НТ-03.}}

=== Д.9. Наскрізний приклад: розрахунок зарплати ===

<pre>
КРОК 1. Документ «Нарахування зарплати» за липень 2026, Іваненко.
Записуємо рухи в РР ОсновніНарахування (Результат = 0).

КРОК 2. Платформа автоматично будує фактичні періоди дії (rg_c_0040_ap):
Оклад → [01.07–09.07], [23.07–31.07]
Відпустка → [10.07–13.07]
Лікарняний → [14.07–22.07]

КРОК 3. Розрахунок «первинних» видів (без бази) — Оклад.
Запит до ДаніГрафіка:
НормаДнів = 23 (робочих днів у липні за П'ятиденкою)
ВідпрацьованоДнів = 13 (робочі дні у фактичних періодах дії)
Результат = 18 000 × 13 / 23 = 10 173,91
→ UPDATE rg_c_0040 SET r1 = 10173.91, r2 = 13, r3 = 23 WHERE line_no = 1

КРОК 4. Розрахунок видів із базою — Відпустка, Лікарняний.
Запит до БазаРозрахунку (базовий період 01.01–30.06, база = Оклад+Премія):
Заробіток за 6 міс. = 115 560,00
Календарних днів = 181
Середньоденний = 638,45
Відпустка: 638,45 × 4 дні (10–13.07) = 2 553,80
Лікарняний: 638,45 × 9 днів × 100 % = 5 746,05
→ UPDATE rg_c_0040 SET r1 = ... WHERE line_no IN (2, 3)

КРОК 5. Записуємо рухи в РР Утримання (базовий період = період реєстрації, липень).
База ПДФО = 10 173,91 + 2 553,80 + 5 746,05 = 18 473,76
ПДФО = 18 473,76 × 18 % = 3 325,28
ВЗ = 18 473,76 × 1,5 % = 277,11

КРОК 6. Проведення документа → рухи в:
РН ВитратиЗаСтаттями (Обороти): Стаття «ЗП і нарахування» = 18 473,76
РБ Госпрозрахунковий: Дт 92 / Кт 661 = 18 473,76
Дт 661 / Кт 641.ПДФО = 3 325,28
Дт 661 / Кт 642.ВЗ = 277,11

КРОК 7. Через тиждень бухгалтер змінює Оклад Іваненка за червень (заднім числом).
→ Платформа реєструє в rg_c_0040_rc1 (ПерерахунокЗаБазою):
(Реєстратор = НарахуванняЗП липня, ВидРозрахунку = Відпустка, Співробітник = Іваненко)
(Реєстратор = НарахуванняЗП липня, ВидРозрахунку = Лікарняний, Співробітник = Іваненко)
→ Звіт «Документи до перерахунку» показує липневий документ.
→ Бухгалтер перепроводить → база перераховується → записи перерахунку очищаються.
</pre>

=== Д.10. Антипатерни проєктування регістрів ===

{| class="wikitable"
! ID !! Антипатерн !! Чому погано !! Як правильно
|-
| '''А-1''' || Дата як '''вимірювання''' у РН (замість стандартного <code>Період</code>) || Таблиця підсумків множиться на кількість дат і зростає нескінченно; віртуальні таблиці <code>Залишки</code>/<code>Обороти</code> ігнорують це вимірювання і дають безглузді результати || Використовувати стандартний реквізит <code>Період</code>. Виняток — календарі (Д.3.4), де це РВ, а не РН
|-
| '''А-2''' || РН «Залишки» там, де потрібна лише історія значення || Надлишкові таблиці підсумків, кумулятивні оновлення, вид руху без сенсу || РВ періодичний
|-
| '''А-3''' || РН «Залишки» там, де залишок безглуздий (Продажі, Витрати) || Удвічі більший обсяг підсумків, кумулятивні MERGE на всі майбутні періоди || РН «Обороти» + агрегати (Д.5.1)
|-
| '''А-4''' || Реквізит документа продубльовано у вимірювання «щоб фільтрувати у звіті» || Кардинальність підсумків × N; типовий випадок — Менеджер/Валюта/Коментар || Реквізит регістру + з'єднання з документом у звіті; або окремий регістр «Обороти»
|-
| '''А-5''' || > 8 вимірювань в одному РН || Таблиця підсумків стає '''більшою''' за таблицю рухів; проведення сповільнюється в рази || Розділити на регістри за призначенням; частину аналітики — в «Обороти» з агрегатами
|-
| '''А-6''' || Незалежний РВ «у межах секунди» як журнал подій || Два записи в ту саму секунду → другий '''мовчки замістить''' перший; втрата даних || Підпорядкований РВ (реєстратор у ключі) або додати вимірювання-дискримінатор
|-
| '''А-7''' || Ресурс типу <code>Рядок</code>/<code>Посилання</code> у РН || Підсумовування неможливе; підсумки не побудуються || Реквізит (не агрегується) або вимірювання (якщо це розріз)
|-
| '''А-8''' || Прямий <code>UPDATE</code> таблиці підсумків із прикладного коду || Розсинхронізація підсумків і рухів; діагностика — тижні || Тільки через набори записів. Заборона на рівні прав БД (розділ 12.2)
|-
| '''А-9''' || Один «універсальний» регістр із вимірюванням <code>ВидОбліку</code> (БУ/ПУ/УО) замість трьох || Втричі більша таблиця; конкуренція за блокування між незалежними обліками; неможливо окремо перерахувати підсумки || Окремі регістри. Виняток — РБ <code>ПодатковийОблік</code> (Д.6.2), де ВидРізниці — це справді розріз одного обліку
|-
| '''А-10''' || Функціонально залежне поле як вимірювання (Валюта при БанківськомуРахунку) || Надлишковість; ризик неузгоджених даних; зайвий розмір ключа підсумків || З'єднання з довідником у запиті (Д.4.4)
|-
| '''А-11''' || РБ там, де достатньо РН || Замість 1 таблиці — 10; ~70 % вартості проведення (Д.8); складність субконто без потреби || РН. РБ — лише коли потрібні план рахунків, подвійний запис і кореспонденції
|-
| '''А-12''' || Вимірювання з <code>nullable</code> без потреби || Порожнє посилання — окреме значення ключа; підсумки «розмазуються» на два рядки замість одного || <code>denyEmpty: true</code> скрізь, де порожнє значення не має сенсу
|-
| '''А-13''' || Контроль залишків '''до''' запису рухів || Класична гонитва: два сеанси проходять контроль і обидва списують у мінус || Спершу <code>DataLock</code> → <code>WriteNow()</code> → потім контроль (Д.8, ФТ-Т-12)
|-
| '''А-14''' || <code>periodicity: WithinSecond</code> «про всяк випадок» скрізь || Для РВ — неможливість замістити запис за день; для РН — марна точність, більші індекси || Обирати мінімально достатню: день для цін/курсів/виписок, секунда — для складських рухів
|-
| '''А-15'''<br />''(Python)'' || Запис рухів у циклі: <code>for r in Товари: rs.add(...).write()</code> || Порушення АП-1: 100 round-trip'ів замість 1; проведення 300 мс → ~10 с. Невидиме на тестових даних, катастрофічне на продуктиві. Найчастіша помилка при ORM-мисленні || Наповнити набір повністю (<code>rs.extend(генератор)</code>), записати один раз. Детектор — Додаток Е.7
|-
| '''А-16'''<br />''(Python)'' || Агрегація дельт підсумків у Python (<code>defaultdict</code> + цикл) замість <code>MERGE</code> || Порушення АП-2: дані ганяються в застосунок і назад; на 10<sup>5</sup> рядків — десятки секунд || <code>INSERT … ON CONFLICT DO UPDATE</code> одним запитом (Е.3)
|}

=== Д.11. Чек-лист рев'ю нового регістру ===

<pre>
□ Тип регістру обґрунтований за деревом Д.1
□ Кожне вимірювання використовується у фільтрі АБО групуванні звітів
□ Кожен ресурс має сенс при підсумовуванні
□ Немає полів з антипатернів А-1, А-4, А-7, А-10, А-12
□ Оцінка кардинальності підсумків ≤ 10^8 (калькулятор конструктора, ФТ-К-03)
□ Для вимірювань, де порожнє значення безглузде, стоїть denyEmpty
□ Ведучі (master) вимірювання визначені — інакше «висячі» записи при видаленні об'єктів
□ Склад реєстраторів повний; зайвих типів документів немає
□ Угода про знак / вид руху зафіксована в методологічній документації
□ Періодичність мінімально достатня (А-14)
□ Для РН «Обороти» з >4 вимірюваннями визначено ≥1 агрегат
□ Для РБ: балансові/небалансові вимірювання та ресурси розставлені свідомо
□ Для РР: витісняючі та базові види розрахунку в ПВР заповнені; перерахунки визначені
□ Партиціонування ввімкнене, якщо очікується >100 млн записів
□ Написано тест на проведення + скасування + перерахунок підсумків
</pre>

== Додаток Е. Ескізи реалізації ядра на Python ==

Додаток демонструє, що метамодель розділу 6 і фізична модель розділу 8 реалізовні обраним стеком (розділ 4.3), і фіксує ключові технічні рішення для етапів Е1, Е3, Е5, Е7, Е11. Код — ілюстративний ескіз, а не остаточний API.

=== Е.1. Маніфест регістру як Pydantic-модель (етап Е1) ===

YAML-декларації розділу 6.7 і Додатка Д валідуються цією моделлю. Це '''безпосередньо реалізує ФТ-К-01''' (валідація в реальному часі) і частину контролю антипатернів Д.10.

<syntaxhighlight lang="python">
from __future__ import annotations

import warnings
from enum import StrEnum
from typing import Annotated, Literal, Self

from pydantic import BaseModel, ConfigDict, Field, model_validator

IDENT = r"^[^\W\d]\w{0,79}$" # Unicode-ідентифікатор (кирилиця дозволена), <= 80 симв.

class RegisterKind(StrEnum):
INFORMATION = "Information"
ACCUMULATION = "Accumulation"
ACCOUNTING = "Accounting"
CALCULATION = "Calculation"

class Periodicity(StrEnum):
NONPERIODICAL = "Nonperiodical"
WITHIN_SECOND = "WithinSecond"
WITHIN_DAY = "WithinDay"
WITHIN_MONTH = "WithinMonth"
WITHIN_QUARTER = "WithinQuarter"
WITHIN_YEAR = "WithinYear"
BY_RECORDER_POSITION = "ByRecorderPosition"

class WriteMode(StrEnum):
INDEPENDENT = "Independent"
SUBORDINATE = "SubordinateToRecorder"

class FieldRole(StrEnum):
DIMENSION = "Dimension"
RESOURCE = "Resource"
ATTRIBUTE = "Attribute"

class RegisterField(BaseModel):
model_config = ConfigDict(extra="forbid", frozen=True)

name: Annotated[str, Field(pattern=IDENT)]
role: FieldRole
type: str | list[str] # "Довідник.Номенклатура" | ["Документ.А", "Документ.Б"]
synonym: str | None = None
index: bool = False
master: bool = False # «Ведуче»
deny_empty: bool = False
nullable: bool = False
use_in_totals: bool = True
# РБ
balance: bool = False
accounting_flag: str | None = None
# РР
base_dimension: bool = False

@property
def is_composite(self) -> bool:
return isinstance(self.type, list) and len(self.type) > 1

class Register(BaseModel):
model_config = ConfigDict(extra="forbid")

name: Annotated[str, Field(pattern=IDENT)]
kind: RegisterKind
synonym: str | None = None
periodicity: Periodicity = Periodicity.NONPERIODICAL
write_mode: WriteMode = WriteMode.SUBORDINATE
dimensions: list[RegisterField] = []
resources: list[RegisterField] = []
attributes: list[RegisterField] = []
recorders: list[str] = []
# РН
accumulation_kind: Literal["Balance", "Turnover"] | None = None
enable_balance_totals: bool = True
enable_turnover_totals: bool = False
turnover_totals_period: Literal["Day", "Month"] | None = None
# РБ
chart_of_accounts: str | None = None
correspondence: bool = True
max_extdim_count: Annotated[int, Field(ge=0, le=5)] = 3
# РР
calculation_types_plan: str | None = None
action_period: bool = False
base_period: Literal["None", "ByActionPeriod", "ByRegistrationPeriod"] = "None"

# ---------- крос-полева валідація (розділи 6.2–6.6) ----------
@model_validator(mode="after")
def _validate(self) -> Self:
if self.write_mode is WriteMode.INDEPENDENT and self.kind is not RegisterKind.INFORMATION:
raise ValueError("Незалежний режим запису дозволено лише для регістру відомостей")

if self.kind is RegisterKind.ACCUMULATION:
if self.accumulation_kind is None:
raise ValueError("Для регістру накопичення обов'язковий accumulation_kind")
if self.periodicity is Periodicity.NONPERIODICAL:
raise ValueError("Регістр накопичення не може бути неперіодичним")
if self.accumulation_kind == "Turnover" and self.enable_balance_totals:
raise ValueError("Підсумки залишків несумісні з видом «Обороти»")

if self.kind is RegisterKind.ACCOUNTING and not self.chart_of_accounts:
raise ValueError("Для регістру бухгалтерії обов'язковий chart_of_accounts")

if self.kind is RegisterKind.CALCULATION:
if not self.calculation_types_plan:
raise ValueError("Для регістру розрахунку обов'язковий calculation_types_plan")
if not any(f.base_dimension for f in self.dimensions) and self.base_period != "None":
raise ValueError("Задано base_period, але жодне вимірювання не позначене base_dimension")

# ресурс має бути підсумовуваним (антипатерн А-7)
if self.kind is not RegisterKind.INFORMATION:
for r in self.resources:
if not _is_numeric(r.type):
raise ValueError(f"Ресурс «{r.name}»: тип {r.type} не підсумовується (А-7). "
f"Використайте роль Attribute або Dimension")

# обмеження розділу 6.6
if len(self.dimensions) > 20:
raise ValueError(f"Вимірювань {len(self.dimensions)} > 20 (розділ 6.6)")

# попередження (ФТ-К-01: warnings, а не помилки)
if len(self.dimensions) > 8:
warnings.warn(f"«{self.name}»: {len(self.dimensions)} вимірювань — "
f"ризик розростання таблиці підсумків (антипатерн А-5)")
for d in self.dimensions:
if d.type == "Дата" and self.kind is RegisterKind.ACCUMULATION:
warnings.warn(f"«{self.name}.{d.name}»: Дата як вимірювання РН — антипатерн А-1")
return self
</syntaxhighlight>

'''Що це дає безкоштовно:''' валідацію YAML, JSON Schema для web-конструктора (<code>Register.model_json_schema()</code>), типізовані об'єкти для генератора DDL, детальні повідомлення про помилки з шляхом до поля.

=== Е.2. Генератор DDL на SQLAlchemy Core (етап Е1) ===

<syntaxhighlight lang="python">
from collections.abc import Callable, Sequence

from sqlalchemy import (Boolean, Column, DateTime, Index, Integer, MetaData, Numeric,
PrimaryKeyConstraint, SmallInteger, String, Table, Uuid, text)
from sqlalchemy.types import TypeEngine

PRIMITIVE: dict[str, Callable[[RegisterField], TypeEngine]] = {
"Число": lambda f: Numeric(f.precision, f.scale),
"Рядок": lambda f: String(f.length),
"Дата": lambda f: DateTime(timezone=False),
"Булево": lambda f: Boolean(),
"УНІ": lambda f: Uuid(),
}

def columns_for_field(f: RegisterField, prefix: str) -> list[Column]:
"""Одне поле метаданих -> 1..6 фізичних колонок (розділ 8.2)."""
if f.is_composite: # складений тип: розділ 8.2.2
return [
Column(f"{prefix}_t", SmallInteger, nullable=False),
Column(f"{prefix}_b", Boolean),
Column(f"{prefix}_n", Numeric(38, 10)),
Column(f"{prefix}_s", String(f.max_string_len)),
Column(f"{prefix}_d", DateTime),
Column(f"{prefix}_r", Uuid),
]
if f.is_reference: # просте посилання
return [Column(f"{prefix}_r", Uuid, nullable=f.nullable)]
base = f.base_type
return [Column(prefix, PRIMITIVE[base](f), nullable=f.nullable)]

def build_movement_table(reg: Register, md: MetaData) -> Table:
"""Метаопис -> Table. Розділи 8.4–8.7."""
cols: list[Column] = []

if reg.write_mode is WriteMode.SUBORDINATE:
cols += [
Column("rec_t", SmallInteger, nullable=False),
Column("rec_r", Uuid, nullable=False),
Column("line_no", Integer, nullable=False),
Column("active", Boolean, nullable=False, server_default=text("true")),
]
if reg.periodicity is not Periodicity.NONPERIODICAL:
cols.append(Column("period", DateTime, nullable=False))
if reg.kind is RegisterKind.ACCUMULATION and reg.accumulation_kind == "Balance":
cols.append(Column("mvt", SmallInteger, nullable=False)) # ВидРуху
if reg.kind is RegisterKind.CALCULATION:
cols += [Column("calc_type_r", Uuid, nullable=False),
Column("reversal", Boolean, nullable=False, server_default=text("false"))]
if reg.action_period:
cols += [Column("act_begin", DateTime, nullable=False),
Column("act_end", DateTime, nullable=False)]
if reg.base_period != "None":
cols += [Column("base_begin", DateTime), Column("base_end", DateTime)]

for f in reg.all_fields: # dimensions + resources + attributes
cols += columns_for_field(f, reg.column_prefix(f)) # 'd3', 'r1', 'a2'

t = Table(reg.physical_table, md, *cols,
PrimaryKeyConstraint(*primary_key_columns(reg),
name=f"pk_{reg.physical_table}"),
postgresql_partition_by=partition_clause(reg))

for f in reg.dimensions:
if f.index:
Index(f"ix_{reg.physical_table}_{reg.column_prefix(f)}",
*index_columns(reg, f),
postgresql_where=t.c.active if "active" in t.c else None)
return t
</syntaxhighlight>

'''НФВ-16 / НФВ-17 (дві СКБД, ізольований шар діалекту) — у три рядки:'''

<syntaxhighlight lang="python">
from sqlalchemy.dialects import mssql, postgresql
from sqlalchemy.schema import CreateTable

md = MetaData()
t = build_movement_table(reg_goods, md)

print(CreateTable(t).compile(dialect=postgresql.dialect())) # -> CREATE TABLE rg_a_0012 (...)
print(CreateTable(t).compile(dialect=mssql.dialect())) # -> той самий об'єкт у T-SQL
</syntaxhighlight>

{{Note|'''Це і є головний аргумент на користь Python у цьому проєкті.''' SQLAlchemy Core — фактично готовий «шар діалекту СКБД» (НФВ-17) і модель схеми, які в C#/Delphi довелося б писати самостійно. Разом із Alembic (Е10) і Pydantic (Е.1) це знімає ~1,5 чол.-міс. з етапів Е1 і Е10 (розділ 14.1).}}

'''Реалізація ФТ-К-02''' («Показати SQL» у конструкторі) — той самий виклик <code>CreateTable(t).compile(...)</code>, виведений у UI.

=== Е.3. Інкрементальне оновлення підсумків (етап Е3) ===

Реалізація алгоритму 10.2 з дотриманням АП-1 (один запит на весь набір) і ФТ-34 (детермінований порядок проти дедлоків).

<syntaxhighlight lang="python">
from operator import itemgetter
from collections.abc import Sequence

from sqlalchemy import Connection, Table
from sqlalchemy.dialects.postgresql import insert as pg_insert

def merge_totals(conn: Connection, totals: Table, rows: list[dict],
key: Sequence[str], res: Sequence[str]) -> None:
"""АП-1 + АП-2: одна операція на весь набір дельт; складання виконує СКБД."""
if not rows:
return

rows.sort(key=itemgetter(*key)) # ФТ-34: детермінований порядок -> без дедлоків

stmt = pg_insert(totals).values(rows)
stmt = stmt.on_conflict_do_update(
index_elements=list(key),
set_={r: totals.c[r] + stmt.excluded[r] for r in res}, # r1 = t.r1 + EXCLUDED.r1
)
conn.execute(stmt) # 1 round-trip незалежно від len(rows)
</syntaxhighlight>

'''Для MS SQL''' — той самий інтерфейс, інша реалізація (<code>MERGE ... WHEN MATCHED THEN UPDATE</code>) за діалектним диспетчером. Ізоляція — на рівні функції, прикладний код не знає про діалект.

'''Чому НЕ ORM:''' ORM-варіант (<code>session.merge(obj)</code> у циклі) дав би <code>len(rows)</code> round-trip'ів — пряме порушення АП-1 і зростання НФВ-04 на два порядки. Саме тому ORM заборонений у розділі 4.3.

=== Е.4. Транслятор віртуальних таблиць (етап Е5) ===

<syntaxhighlight lang="python">
from functools import lru_cache

from lark import Lark, Transformer
from sqlalchemy import Select, func, literal, select, union_all

GRAMMAR = r"""
?query : "ВИБРАТИ"i select_list "З"i source [where] [group_by] [order_by]
source : virtual_table | plain_table
virtual_table : REGISTER_PATH "." VT_NAME "(" [vt_args] ")" ["ЯК"i alias]
VT_NAME : "Залишки"i | "Обороти"i | "ЗалишкиІОбороти"i
| "ЗрізОстанніх"i | "ЗрізПерших"i | "ОборотиДтКт"i
| "ДаніГрафіка"i | "ФактичнийПеріодДії"i | "БазаРозрахунку"i
vt_args : (expr | ) ("," (expr | ))* // позиційні, можуть бути порожні
...
"""

class QueryCompiler:
def __init__(self, schema: SchemaRegistry) -> None:
self._parser = Lark(GRAMMAR, parser="lalr", start="query")
self._schema = schema

@lru_cache(maxsize=2048) # АП-4: кеш скомпільованих запитів
def compile(self, text: str, param_signature: tuple[str, ...]) -> Select:
tree = self._parser.parse(text)
return _ToSQLAlchemy(self._schema).transform(tree)

def balances(self, reg: Register, period, conditions: list) -> Select:
"""Реалізація алгоритму 10.3 в термінах SQLAlchemy Core."""
tb = self._schema.totals_balance(reg)
mv = self._schema.movements(reg)
dims = [tb.c[c] for c in self._schema.dimension_columns(reg)]

boundary = (select(func.coalesce(func.max(tb.c.period), MIN_PERIOD))
.where(tb.c.period <= period)
.scalar_subquery())

base = (select(*dims, *[func.sum(tb.c[r]).label(r) for r in reg.resource_columns])
.where(tb.c.period == boundary, *conditions) # ФТ-13: push-down
.group_by(*dims))

signed = lambda c: case((mv.c.mvt == 0, mv.c[c]), else_=-mv.c[c])
tail = (select(*[mv.c[d.name] for d in dims],
*[func.sum(signed(r)).label(r) for r in reg.resource_columns])
.where(mv.c.active, mv.c.period > boundary, mv.c.period <= period, *conditions)
.group_by(*[mv.c[d.name] for d in dims]))

u = union_all(base, tail).subquery()
return (select(*[u.c[d.name] for d in dims],
*[func.sum(u.c[r]).label(f"{r}Залишок") for r in reg.resource_columns])
.group_by(*[u.c[d.name] for d in dims])
.having(or_(*[func.sum(u.c[r]) != 0 for r in reg.resource_columns])))
</syntaxhighlight>

'''Ризик Р1 (немає мови запитів) на Python пом'якшується:''' навіть якщо повноцінна мова запитів не буде реалізована в Е5, <code>QueryCompiler.balances()</code> залишається придатним як програмний API — прикладний код викликає його напряму й отримує <code>Select</code>, який можна далі з'єднувати засобами SQLAlchemy Core. Це '''план «Б»''' для Р1, недоступний у мовах без подібної бібліотеки.

=== Е.5. Витіснення: гарячий шлях за інтерфейсом (етапи Е7, Е11) ===

Реалізація принципу АП-3 на найризикованішому вузлі (Р5 + Р10).

<syntaxhighlight lang="python">
from collections import defaultdict
from collections.abc import Callable, Sequence
from datetime import date, timedelta
from typing import Protocol
from uuid import UUID

Interval = tuple[date, date]
ONE_DAY = timedelta(days=1)

class DisplacementEngine(Protocol):
"""АП-3. Бюджет (АП-4): <= 3 c на 10 тис. ключів × ~10 записів."""

def compute(self,
records: Sequence[CalcRecord],
displaces: Callable[[UUID, UUID], bool]) -> dict[RecordKey, list[Interval]]:
"""Повертає фактичні періоди дії для кожного запису (розділ 10.4)."""
...

def subtract(intervals: list[Interval], cut: Interval) -> list[Interval]:
"""Різниця множин інтервалів. Найгарячіша функція платформи."""
out: list[Interval] = []
cb, ce = cut
for b, e in intervals:
if ce < b or cb > e: # не перетинаються
out.append((b, e))
continue
if b < cb:
out.append((b, cb - ONE_DAY)) # «хвіст» зліва
if e > ce:
out.append((ce + ONE_DAY, e)) # «хвіст» справа
return out

class PyDisplacementEngine:
"""Еталонна реалізація. Заміна на Cython/Rust не змінює виклик (АП-3)."""

def compute(self, records, displaces):
by_key: dict[DimKey, list[CalcRecord]] = defaultdict(list)
for r in records:
if r.active:
by_key[r.dim_key].append(r)

result: dict[RecordKey, list[Interval]] = {}
for Z in by_key.values():
if len(Z) > 500: # розділ 10.4: перехід на sweep-line
result |= SweepLineEngine().compute(Z, displaces)
continue
Z.sort(key=lambda r: (r.priority, r.period, r.line_no))
for z in Z:
intervals = [(z.act_begin, z.act_end)]
for w in Z:
if w is z or not displaces(w.calc_type, z.calc_type):
continue
if not _registration_periods_intersect(w, z):
continue
intervals = subtract(intervals, (w.act_begin, w.act_end))
if not intervals:
break # повністю витіснений
result[z.key] = intervals
return result
</syntaxhighlight>

'''Property-based тести (мітигація Р5 — найпомилковішого вузла):'''

<syntaxhighlight lang="python">
from hypothesis import given
from hypothesis import strategies as st

dates = st.dates(min_value=date(2020, 1, 1), max_value=date(2030, 12, 31))
intervals = st.lists(st.tuples(dates, dates).map(lambda t: tuple(sorted(t))), max_size=20)

@given(ivs=intervals, cut=st.tuples(dates, dates).map(lambda t: tuple(sorted(t))))
def test_subtract_invariants(ivs: list[Interval], cut: Interval) -> None:
out = subtract(ivs, cut)
assert all(b <= e for b, e in out), "некоректні межі"
assert not any(_overlaps(i, cut) for i in out), "витіснений інтервал залишився"
# збереження міри: те, що прибрали, дорівнює перетину з cut
assert _measure(out) + _measure(_intersect_all(ivs, cut)) == _measure(ivs)
</syntaxhighlight>

'''Бенчмарк як блокер приймання (АП-4):'''

<syntaxhighlight lang="python">
@pytest.mark.benchmark(group="displacement")
def test_displacement_budget(benchmark, records_10k_keys) -> None:
"""Вводиться в CI з етапу Е7. Перевищення бюджету -> червоний білд."""
benchmark(PyDisplacementEngine().compute, records_10k_keys, displaces)
assert benchmark.stats.stats.mean < 3.0, (
f"Порушено бюджет АП-4: {benchmark.stats.stats.mean:.2f} c > 3.0 c. "
f"Розгляньте sweep-line, Cython або перенесення у SQL (daterange + GiST)."
)
</syntaxhighlight>

=== Е.6. Генерація <code>.pyi</code>-стабів (ФТ-К-07, етап Е1) ===

'''Проблема:''' поля регістру доступні динамічно (<code>rs.new(Номенклатура=…)</code>), тому <code>mypy</code> не бачить одруків і помилок типів — це і є ризик Р11.

'''Рішення:''' конструктор генерує стаби з метаопису при кожній зміні конфігурації.

<syntaxhighlight lang="python">
# k2/generated/registers/ТовариНаСкладах.pyi -- АВТОЗГЕНЕРОВАНО. Не редагувати.
from datetime import datetime
from decimal import Decimal

from k2.catalogs import Номенклатура, Склади, ХарактеристикиНоменклатури
from k2.documents import ПрихіднаНакладна, ВведенняЗалишків
from k2.registers import AccumulationMovementType, Record, RecordSet

class ТовариНаСкладахRecord(Record):
Період: datetime
ВидРуху: AccumulationMovementType
Номенклатура: Номенклатура
Склад: Склади
Характеристика: ХарактеристикиНоменклатури | None
Партія: ПрихіднаНакладна | ВведенняЗалишків | None # складений тип
Кількість: Decimal
Сума: Decimal
Коментар: str

class ТовариНаСкладахRecordSet(RecordSet[ТовариНаСкладахRecord]):
def new(self, *, Період: datetime, ВидРуху: AccumulationMovementType,
Номенклатура: Номенклатура, Склад: Склади,
Характеристика: ХарактеристикиНоменклатури | None = None,
Партія: ПрихіднаНакладна | ВведенняЗалишків | None = None,
Кількість: Decimal = ..., Сума: Decimal = ...,
Коментар: str = ...) -> ТовариНаСкладахRecord: ...
</syntaxhighlight>

'''Що це ловить у CI ще до запуску:'''
{| class="wikitable"
! Помилка прикладного коду !! Без стабів !! Зі стабами
|-
| <code>rs.new(Номенклатур=x)</code> — одрук у назві поля || Виняток у рантаймі при проведенні на продуктиві || <code>mypy</code>: unexpected keyword argument
|-
| <code>m.Кількість = "багато"</code> || <code>InvalidOperation</code> при записі в БД || <code>mypy</code>: incompatible type <code>str</code>, expected <code>Decimal</code>
|-
| <code>m.Склад = номенклатура</code> — переплутані посилання || FK-помилка або, гірше, тихо неправильні дані || <code>mypy</code>: incompatible type
|-
| Видалили вимірювання з метаданих, код лишився || Виняток при проведенні || Червоний білд одразу після зміни конфігурації
|}

'''Автодоповнення в IDE''' — приємний побічний ефект, який частково компенсує відсутність повноцінного конфігуратора рівня 1С на ранніх етапах.

=== Е.7. Автоматичний детектор порушень АП-1 (етап Е3, CI) ===

Принцип АП-1 марний без механічної перевірки — розробник порушить його ненавмисно.

<syntaxhighlight lang="python">
# tests/architecture/test_ap1_no_row_by_row.py

@pytest.mark.parametrize("scenario", POSTING_SCENARIOS)
def test_roundtrips_do_not_scale_with_rows(db_counter, scenario) -> None:
"""АП-1: кількість звернень до СКБД НЕ залежить від кількості рядків документа."""
with db_counter() as c10:
scenario.build(rows=10).post()
with db_counter() as c100:
scenario.build(rows=100).post()

assert c100.roundtrips <= c10.roundtrips + 2, (
f"{scenario.name}: звернень до БД зросло {c10.roundtrips} -> {c100.roundtrips} "
f"при зростанні рядків у 10 разів. Порушення АП-1 — див. розділ 4.4."
)

class RowByRowGuard:
"""Runtime-запобіжник для dev/staging: виняток при >N однакових запитів у транзакції."""

def __init__(self, threshold: int = 20) -> None:
self._counts: Counter[str] = Counter()
self._threshold = threshold

def before_execute(self, conn, clauseelement, *args) -> None:
fingerprint = _statement_fingerprint(clauseelement) # SQL без літералів
self._counts[fingerprint] += 1
if self._counts[fingerprint] == self._threshold:
raise ArchitectureViolation(
f"Один і той самий запит виконано {self._threshold} разів у межах транзакції.\n"
f"Ймовірне порушення АП-1 («жодного рядка за раз»).\n{fingerprint}"
)
</syntaxhighlight>

'''Це — найдешевша страховка проєкту.''' Порушення АП-1 не видно на тестових даних (10 рядків — усе швидко) і катастрофічне на продуктиві (100 рядків × 5 регістрів). Детектор вводиться '''з етапу Е3''', а не за результатами НТ-03.

=== Е.8. Структура репозиторію ядра ===

<pre>
k2-registers/
├── src/k2/
│ ├── metadata/ # Е.1: Pydantic-моделі, репозиторій, валідація
│ │ ├── models.py # Register, RegisterField, ...
│ │ ├── repository.py # md_* таблиці
│ │ └── validators.py # ФТ-К-01, антипатерни Д.10
│ ├── schema/ # Е.2: генерація DDL
│ │ ├── builder.py # метаопис -> SQLAlchemy Table
│ │ ├── dialects/ # НФВ-17: postgres.py, mssql.py
│ │ └── restructure.py # Е10: Alembic-інтеграція
│ ├── runtime/ # набори записів, проведення, блокування
│ │ ├── recordset.py
│ │ ├── posting.py # розділ 7.1
│ │ ├── totals.py # Е.3: merge_totals
│ │ └── locks.py # ФТ-32
│ ├── query/ # Е.4: lark-граматика + компілятор
│ │ ├── grammar.lark
│ │ ├── compiler.py
│ │ └── virtual/ # balances.py, turnovers.py, slices.py, calc_base.py
│ ├── calculation/ # Е.5: витіснення (гарячий шлях)
│ │ ├── protocols.py # DisplacementEngine
│ │ ├── engine_py.py # еталонна реалізація
│ │ └── engine_native/ # [резерв] Cython/Rust — тільки за результатом бенчмарку
│ ├── codegen/ # Е.6: генерація .pyi-стабів
│ └── diagnostics/ # Е.7: RowByRowGuard, перевірка цілісності (ФТ-41)
├── tests/
│ ├── unit/
│ ├── property/ # hypothesis: інтервальна арифметика (Р5)
│ ├── architecture/ # Е.7: детектор АП-1
│ ├── benchmarks/ # АП-4: бюджети гарячих шляхів (gate у CI)
│ └── integration/ # testcontainers: PostgreSQL + MS SQL (Р7)
└── pyproject.toml # uv, ruff, mypy --strict
</pre>

----
''Кінець документа. Версія 1.2. Підлягає узгодженню з архітектором платформи K2 ERP до затвердження.''

Регістри в K2 ERP

2026-07-17T19:27:49Z

{{DISPLAYTITLE:ТЗ. Підсистема регістрів K2 ERP}}
__TOC__

= 1. Паспорт документа =

{| class="wikitable"
! Атрибут !! Значення
|-
| Назва || Технічне завдання на розробку підсистеми «Регістри» платформи K2 ERP
|-
| Шифр || K2-ERP-TZ-REG-001
|-
| Версія || 1.2 (чернетка на узгодження; мова ядра — Python; +Додатки Д, Е)
|-
| Статус || На розгляді
|-
| Замовник || ''[підрозділ-замовник]''
|-
| Виконавець || ''[команда платформи K2 ERP]''
|-
| Тип документа || Технічне завдання (ГОСТ 34.602 адаптовано)
|-
| Аналог / прототип || Механізм регістрів платформи «1С:Підприємство 8.3»
|-
| Мова розробки || '''Python 3.12+''' (див. розділ 4.3)
|-
| Технологічний стек || SQLAlchemy Core 2.x, Pydantic v2, Alembic, lark, psycopg 3 / pyodbc
|-
| СКБД || PostgreSQL 14+ (основна), MS SQL Server 2019+ (додаткова)
|}

== 1.1. Необхідні розширення MediaWiki ==

{| class="wikitable"
! Розширення !! Теги / шаблони !! Використано в документі !! Постачання
|-
| '''Extension:Diagrams''' || <code><nowiki><graphviz></nowiki></code>, <code><nowiki><uml></nowiki></code> || 4 діаграми GraphViz + 5 діаграм PlantUML || Composer: <code>samwilson/diagrams</code>
|-
| Extension:SyntaxHighlight || <code><nowiki><syntaxhighlight></nowiki></code> || 64 блоки коду (Python, SQL, YAML, lark) || '''Входить до складу MediaWiki''' — окремо встановлювати не потрібно
|-
| <code>Template:Note</code> || <code><nowiki>{{Note|текст}}</nowiki></code> || Примітки та проєктні рішення || Створюється вручну (код нижче)
|}

=== Налаштування ===

<syntaxhighlight lang="php">
// LocalSettings.php — конфігурація ВІКІ, у якій публікується це ТЗ.
// MediaWiki написана на PHP; до мови розробки K2 ERP (Python, розділ 4.3) це не стосується.
wfLoadExtension( 'Diagrams' );

// ОБОВ'ЯЗКОВО. За замовчуванням Diagrams рендерить у PNG; ER-діаграми розділу 9
// містять десятки колонок і в растрі нечитабельні.
$wgDiagramsDefaultFormat = 'svg';

// Варіант А — локальний рендеринг (потрібні бінарники на веб-сервері):
// apt install graphviz plantuml
// Варіант Б — зовнішній сервіс рендерингу (з версії 0.4.0 — опційний):
// $wgDiagramsServiceUrl = 'https://diagrams.example.com/subdir';
</syntaxhighlight>

Шаблон <code>Template:Note</code>, якщо його немає у вікі:
<pre>
<div style="border-left:4px solid #36c; background:#eaf3ff; padding:8px 12px; margin:8px 0;">
'''ⓘ''' {{{1}}}
</div>
</pre>

=== Застереження щодо Extension:Diagrams ===

{{Note|'''Перевірити до затвердження документа.''' Станом на дату складання ТЗ офіційна сторінка розширення вказує: статус — '''beta''', остання версія '''0.10.0 від 12.06.2022''', задекларована сумісність '''MediaWiki 1.34–1.39'''. Політика розширення — «master зберігає зворотну сумісність», тож на новіших версіях (1.43 LTS і далі) воно, найімовірніше, працює, але це '''не підтверджено''' і підлягає перевірці на цільовій корпоративній вікі. Актуальний стан — <nowiki>https://www.mediawiki.org/wiki/Extension:Diagrams</nowiki>.}}

{{Note|'''Тег PlantUML називається <code><nowiki><uml></nowiki></code>''', а не <code><nowiki><plantuml></nowiki></code> (як в окремому Extension:PlantUML). Розмітка документа використовує саме <code><nowiki><uml></nowiki></code>.}}

=== Альтернативи та запасний варіант ===

{| class="wikitable"
! Варіант !! Оцінка
|-
| '''Extension:Diagrams''' ''(обрано)'' || Одне розширення на обидва формати; не зберігає рендери як файли вікі; є дві реалізації сервісу рендерингу — PHP (Symfony) та '''Python''' (остання узгоджується зі стеком проєкту, розділ 4.3). Мінус — beta-статус і питання сумісності вище.
|-
| Extension:GraphViz + Extension:PlantUML окремо || '''Не рекомендується.''' Extension:GraphViz за даними трекера Wikimedia не підтримується й потребує правок для роботи з актуальними версіями MediaWiki. Два розширення замість одного.
|-
| Mermaid (<code><nowiki><mermaid></nowiki></code> у Diagrams або Extension:Mermaid) || Рендериться на клієнті, не потребує бінарників. Але <code>erDiagram</code> Mermaid суттєво менш виразний за <code>entity</code> PlantUML: ER-моделі розділу 9 містять типи, ознаки PK/FK та коментарі до полів — це не переноситься без втрат. Придатний як запасний варіант для простих схем (5.1, Д.1).
|-
| Без розширень || Блоки діаграм відображатимуться як вихідний текст. Документ залишається читабельним: ключові механізми продубльовані ASCII-схемами (розділи 6.1, 7.4.1, 7.5.1, 8.8, Д.9, Е.8).
|}

= 2. Терміни, визначення та скорочення =

{| class="wikitable"
! Термін !! Визначення
|-
| '''Регістр''' || Об'єкт метаданих, призначений для зберігання та накопичення структурованої облікової інформації у вигляді записів фіксованої структури, з механізмами агрегації, зрізів і транзакційного зв'язку з документами-реєстраторами.
|-
| '''РВ''' || Регістр відомостей (аналог «Регистр сведений»).
|-
| '''РН''' || Регістр накопичення (аналог «Регистр накопления»).
|-
| '''РБ''' || Регістр бухгалтерії (аналог «Регистр бухгалтерии»).
|-
| '''РР''' || Регістр розрахунку (аналог «Регистр расчёта»).
|-
| '''Вимірювання''' (Dimension) || Поле регістру, що визначає розріз аналітики; входить у ключ запису/підсумку.
|-
| '''Ресурс''' (Resource) || Поле регістру, значення якого підсумовується (для РН/РБ/РР) або зберігається як значення (для РВ).
|-
| '''Реквізит''' (Attribute) || Довідкове поле запису, що не бере участі в ключі та не агрегується.
|-
| '''Реєстратор''' (Recorder) || Документ, який породив набір записів регістру та володіє ним.
|-
| '''Рухи''' (Movements) || Записи регістру, підпорядковані конкретному реєстратору.
|-
| '''Набір записів''' (RecordSet) || Прикладний об'єкт для читання/запису групи записів регістру за заданим відбором.
|-
| '''Підсумки''' (Totals) || Попередньо розраховані агрегати (залишки/обороти), що зберігаються в окремих таблицях.
|-
| '''ТА''' || Точка актуальності підсумків — момент часу, до якого підсумки розраховані.
|-
| '''Зріз останніх''' (SliceLast) || Вибірка останніх за періодом записів РВ у розрізі кожної комбінації вимірювань.
|-
| '''Субконто''' (ExtDimension, ED) || Додатковий розріз аналітики бухгалтерського рахунку.
|-
| '''ПВР''' || План видів розрахунку.
|-
| '''Витіснення''' || Механізм РР: запис із вищим пріоритетом скорочує фактичний період дії запису з нижчим.
|-
| '''Перерахунок''' (Recalculation) || Підпорядкований РР об'єкт, що реєструє записи, які потребують повторного розрахунку.
|-
| '''Віртуальна таблиця''' || Обчислювана таблиця в мові запитів, що не має фізичного відповідника (Залишки, Обороти, ЗрізОстанніх тощо).
|}

= 3. Призначення, цілі та підстава розробки =

== 3.1. Підстава ==
Поточна модель K2 ERP не має уніфікованого декларативного механізму накопичувального обліку. Регістроподібні структури реалізуються ''ad hoc'' — окремими таблицями та процедурами під кожну прикладну задачу, що спричиняє:
* дублювання коду розрахунку залишків та оборотів;
* відсутність гарантованої узгодженості «документ ↔ рухи»;
* деградацію продуктивності на великих обсягах (повний перерахунок з початку обліку);
* високу вартість введення нової аналітики (зміна схеми БД + правка десятків процедур).

== 3.2. Мета ==
Створити в K2 ERP підсистему '''декларативно описуваних регістрів''' чотирьох типів, функціонально еквівалентну механізму регістрів «1С:Підприємство 8.3», з автоматичною генерацією схеми БД, підтримкою підсумків, віртуальних таблиць у мові запитів і транзакційного проведення документів.

== 3.3. Цілі проєкту (вимірювані) ==
{| class="wikitable"
! № !! Ціль !! Критерій досягнення
|-
| Ц1 || Декларативне визначення регістру || Новий регістр з 5 вимірюваннями та 3 ресурсами створюється в конструкторі без написання коду; DDL генерується автоматично.
|-
| Ц2 || Автоматична агрегація || Залишки/обороти доступні запитом без ручних процедур перерахунку.
|-
| Ц3 || Продуктивність || Отримання залишків на дату за таблицею 1 млрд рухів — ≤ 200 мс (P95) на еталонному стенді.
|-
| Ц4 || Цілісність || Неможливість існування рухів без активного реєстратора (100 % сценаріїв у тесті цілісності).
|-
| Ц5 || Міграція || Перенесення ≥ 90 % наявних «регістроподібних» структур K2 на новий механізм без втрати даних.
|}

== 3.4. Що НЕ входить до обсягу (Out of scope) ==
* Механізм розподілених інформаційних баз / реплікації рухів (окреме ТЗ).
* Візуальний конструктор звітів поверх регістрів (окреме ТЗ, залежність).
* OLAP-куби та зовнішні аналітичні вітрини.
* Автоматичне перенесення прикладного коду замовника (тільки дані + мапінг).

= 4. Припущення та обмеження щодо платформи K2 ERP =

{{Note|Розділ фіксує припущення, які '''обов'язково''' підлягають верифікації з архітектором платформи до затвердження ТЗ. Місця, що потребують уточнення, позначені як ''[уточнити]''.}}

== 4.1. Припущення щодо платформи ==

{| class="wikitable"
! № !! Припущення !! Наслідок для ТЗ
|-
| П1 || K2 ERP має підсистему метаданих із власним репозиторієм об'єктів (документи, довідники, перерахування) і механізмом версіонування конфігурації. || Регістр вбудовується як новий '''рід''' об'єкта метаданих у наявний репозиторій (розділ 6).
|-
| П2 || Об'єкти-документи мають унікальний ідентифікатор посилання (GUID/UUID) та проведення як окрему операцію. || Реєстратор адресується парою «код типу + UUID» (розділ 8.2).
|-
| П3 || Платформа має власну мову запитів або транслятор у SQL. || Віртуальні таблиці реалізуються на рівні транслятора (розділ 7.6). Якщо мови запитів немає — потрібен окремий етап Е0 (розділ 14).
|-
| П4 || Цільова СКБД підтримує <code>MERGE</code>/<code>INSERT ... ON CONFLICT</code>, віконні функції, часткові та покривні індекси. || Алгоритми підсумків (розділ 10) використовують ці можливості.
|-
| П5 || Прикладний код виконується на сервері застосунків із керованими транзакціями. || Проведення документа — одна транзакція БД (розділ 7.1).
|-
| П6 || Максимальна довжина ідентифікатора об'єкта БД — 63 символи (PostgreSQL). || Фізичні імена таблиць будуються за сурогатним числовим кодом, а не за іменем регістру (розділ 8.1).
|-
| П7 || Ядро платформи розробляється на '''Python 3.12+'''; допускаються C-розширення (binary-драйвери) та, за потреби, власні нативні модулі. || Визначає стек (4.3) і архітектурні принципи АП-1…АП-6 (4.4). ''[верифікувати: greenfield чи є наявний Python-код K2]''
|-
| П8 || Прикладний (конфігураційний) код пишеться '''також на Python''' і виконується в тому самому процесі. || Породжує питання ізоляції та безпеки виконання довільного коду — '''відкрите питання В12'''. Якщо припущення хибне (потрібна вбудована мова) — обсяг Е1 зростає на ~2 чол.-міс.
|}

== 4.2. Обмеження ==

* О1. Зміна складу вимірювань/ресурсів існуючого регістру — операція реструктуризації з простоєм; онлайн-міграція не гарантується для таблиць > 100 млн записів.
* О2. Підсистема не гарантує коректність прикладної логіки проведення — лише цілісність механізму.
* О3. Мінімальна дискретність періоду — 1 секунда (тип <code>timestamp(0)</code>) ''[уточнити: чи потрібна мілісекундна]''.

== 4.3. Технологічний стек ==

{| class="wikitable"
! Шар !! Технологія !! Обґрунтування вибору
|-
| Мова ядра || '''Python 3.12+''' (цільова 3.12; щодо 3.13 — див. В14) || Рішення замовника. Наслідки — розділ 4.4.
|-
| Статична типізація || <code>mypy --strict</code> як gate у CI || Ядро метаданих у динамічній мові без статичної перевірки — неприйнятний ризик (Р11).
|-
| Опис і валідація метаданих || '''Pydantic v2''' || Маніфест регістру (розділ 6.7) стає типізованою моделлю: валідація, крос-полеві правила та JSON Schema для конструктора — «безкоштовно». Покриває ФТ-К-01. Приклад — Е.1.
|-
| Генерація DDL, абстракція діалектів СКБД || '''SQLAlchemy Core 2.x''' (''без ORM'') || Ключовий вибір. <code>MetaData</code>/<code>Table</code>/<code>Column</code> — готова модель схеми; діалекти PostgreSQL і MS SQL із коробки. Прямо закриває НФВ-16, НФВ-17 і знижує ризик Р7. Приклад — Е.2.
|-
| Міграції / реструктуризація || '''Alembic''' || Автогенерація <code>ALTER</code> при зміні складу полів (Е10, НФВ-13, НФВ-15).
|-
| Драйвери || '''psycopg 3''' (binary, pipeline mode) або <code>asyncpg</code>; <code>pyodbc</code> для MS SQL || Pipeline mode критичний для АП-1: пакетна вставка без round-trip на рядок.
|-
| Парсер мови запитів || '''lark''' (LALR) → AST → SQLAlchemy Core || Етап Е5. Дешевше за власний парсер; граматика декларативна. Ескіз — Е.4.
|-
| Гарячі шляхи || '''Cython''' / <code>mypyc</code>; за потреби '''Rust''' (PyO3 + maturin) || Тільки за результатами бенчмарку (АП-3, Р10, В13).
|-
| Сервер застосунків || FastAPI + uvicorn; окремий пул процесів для проведення || —
|-
| Паралелізм || '''Процеси''' + <code>asyncio</code> для IO. '''Потоки — ні''' (GIL) || Принцип АП-5.
|-
| Тестування || pytest, pytest-benchmark, '''hypothesis''' (property-based), testcontainers || Hypothesis обов'язковий для витіснення (Р5): інтервальна арифметика — ідеальний кандидат на property-based тести.
|-
| Профілювання || py-spy, scalene, <code>EXPLAIN (ANALYZE, BUFFERS)</code> || Етап Е11.
|-
| Збірка || uv, ruff, wheels із нативними розширеннями під усі цільові платформи || —
|}

'''Явні заборони:'''
* '''ORM SQLAlchemy не використовується.''' Регістри працюють наборами записів, а не об'єктами; identity map і lazy loading тут шкідливі й провокують порушення АП-1. Використовується '''лише Core'''.
* '''PyPy не розглядається''' — несумісність із binary-драйверами та нативними розширеннями.
* '''Free-threaded build (PEP 703)''' — моніторити, але не закладати в архітектуру (В14).

== 4.4. Наслідки вибору Python: архітектурні принципи ==

Python на CPU-навантаженні повільніший за компільовані мови приблизно в 30–80 разів. Проєктована архітектура цьому '''не суперечить''': основну роботу виконує СКБД, а ядро лише формує SQL. Але це вірно '''тільки за умови''' дотримання наведених принципів — їх порушення робить цілі НФВ недосяжними.

{| class="wikitable"
! ID !! Принцип !! Формулювання
|-
| '''АП-1''' || '''«Жодного рядка за раз»''' || '''Заборонено:''' цикл Python із запитом до БД усередині; вставка рухів по одному; читання підсумків по одному ключу. '''Обов'язково:''' <code>executemany</code> / <code>COPY</code> / pipeline, set-based <code>MERGE</code>, один запит на набір записів. Детектор порушень — Е.7.
|-
| '''АП-2''' || '''Ядро — оркестратор, СКБД — обчислювач''' || Python формує SQL і передає керування. Агрегація, з'єднання, сортування — в СКБД. Виняток — гарячі шляхи АП-4, де це неможливо.
|-
| '''АП-3''' || '''Гарячі шляхи ізольовані за інтерфейсом''' || Кожен кандидат на нативне переписування реалізується за <code>Protocol</code>-інтерфейсом з еталонною Python-реалізацією та бенчмарком у CI. Заміна на Cython/Rust не змінює виклик. Приклад — Е.5.
|-
| '''АП-4''' || '''Бюджет Python-часу зафіксовано''' || Див. 4.4.1. Перевищення бюджету — блокер приймання етапу.
|-
| '''АП-5''' || '''Паралелізм — процесами''' || GIL робить потоки марними для CPU-роботи. Проведення IO-bound → <code>asyncio</code>; масштабування — пулом процесів за кількістю ядер.
|-
| '''АП-6''' || '''Типізація на межах''' || <code>mypy --strict</code> на ядрі; Pydantic v2 на всіх межах. Динамічний доступ до полів регістру компенсується генерацією <code>.pyi</code>-стабів (ФТ-К-07, Е.6).
|}

=== 4.4.1. Бюджет Python-часу на гарячих шляхах (АП-4) ===

{| class="wikitable"
! Шлях !! Розділ !! Обсяг операцій !! Оцінка Python !! Ризик !! Мітигація
|-
| Формування рухів документа (100 рядків × 5 регістрів) || 7.1, Д.8 || ~500 конструювань об'єктів || 2–5 мс || Низький || —
|-
| Серіалізація рухів у пакетну вставку || 7.1 || ~500 кортежів || 1–3 мс || Низький || psycopg 3 pipeline / <code>COPY</code>
|-
| Оновлення підсумків || 10.2 || 1 SQL <code>MERGE</code> на регістр || ≈ 0 мс || Низький || set-based (Е.3)
|-
| Трансляція віртуальної таблиці || 7.3, 10.3 || парсинг + побудова AST || 1–10 мс || Середній || LRU-кеш скомпільованих запитів за хешем (текст + сигнатура параметрів)
|-
| '''Витіснення періодів дії''' || 10.4 || O(\|Z\|²) на ключ; 10 тис. ключів × ~10 записів ≈ 10<sup>6</sup> інтервальних операцій || '''1–3 с''' || '''Високий''' || Sweep-line O(n log n); ізоляція за АП-3; кандидат №1 на Cython/Rust; альтернатива — перенести в SQL на <code>daterange</code> + GiST (PostgreSQL)
|-
| '''Розрахунок ЗП''' || Д.9 || 80 тис. записів × формула || '''4–15 с''' || '''Високий''' || Заборона per-record запитів (АП-1); векторизація; кандидат №2 на нативний код
|-
| Реєстрація перерахунків || 10.5 || 1 SQL <code>INSERT … SELECT</code> || ≈ 0 мс || Низький || set-based
|-
| Генерація DDL, реструктуризація || 8, Е.2 || холодний шлях, разова операція || — || Низький || —
|}

=== 4.4.2. Висновок щодо НФВ ===

{| class="wikitable"
! НФВ !! Ціль !! Частка Python !! Вердикт
|-
| НФВ-01…03 (залишки, обороти) || 200 мс – 2 с || < 1 % (робота в СКБД) || '''Не залежить від мови ядра'''
|-
| НФВ-04 (проведення 100 рядків) || 300 мс || 5–15 мс ≈ '''5 %''' || Досяжно за дотримання АП-1
|-
| НФВ-05 (ОСВ) || 5 с || < 1 % || Не залежить від мови ядра
|-
| НФВ-06 (ЗП на 10 тис. осіб) || 10 хв || 4–15 с ≈ '''2,5 %''' || Досяжно; '''запас ×40'''
|-
| НФВ-07 (зріз останніх) || 500 мс || < 1 % || Не залежить від мови ядра
|-
| НФВ-08 (50 док/с) || — || 50 × 10 мс = 0,5 с CPU/с ≈ '''50 % одного ядра''' || Досяжно; пул процесів (АП-5)
|-
| НФВ-09 (перерахунок підсумків) || 4 год || < 1 % || Не залежить від мови ядра
|}

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

= 5. Класифікація регістрів =

== 5.1. Дерево типів ==

<graphviz>
digraph Registers {
rankdir=TB;
bgcolor="transparent";
node [shape=box, style="rounded,filled", fillcolor="#f5f5f5", fontname="Helvetica", fontsize=10];
edge [fontname="Helvetica", fontsize=8];

R [label="РЕГІСТР\n(абстрактний об'єкт метаданих)", fillcolor="#dbe9ff"];

RI [label="Регістр відомостей\n(РВ / Information)", fillcolor="#e8f5e9"];
RA [label="Регістр накопичення\n(РН / Accumulation)", fillcolor="#fff8e1"];
RB [label="Регістр бухгалтерії\n(РБ / Accounting)", fillcolor="#fce4ec"];
RC [label="Регістр розрахунку\n(РР / Calculation)", fillcolor="#ede7f6"];

R -> RI; R -> RA; R -> RB; R -> RC;

RI_np [label="Неперіодичний"];
RI_p [label="Періодичний"];
RI -> RI_np; RI -> RI_p;

RI_i [label="Незалежний\n(режим запису)", shape=note, fillcolor="#ffffff"];
RI_s [label="Підпорядкований\nреєстратору", shape=note, fillcolor="#ffffff"];
RI -> RI_i [style=dashed]; RI -> RI_s [style=dashed];

RA_b [label="Вид: Залишки\n(Balance)"];
RA_t [label="Вид: Обороти\n(Turnover)"];
RA -> RA_b; RA -> RA_t;

RB_c [label="З кореспонденцією\n(подвійний запис)"];
RB_n [label="Без кореспонденції\n(уніграфічний)"];
RB -> RB_c; RB -> RB_n;

RC_a [label="З періодом дії\n(+ витіснення)"];
RC_b [label="З базовим періодом\n(+ база розрахунку)"];
RC_g [label="З графіком часу"];
RC -> RC_a; RC -> RC_b; RC -> RC_g;
}
</graphviz>

== 5.2. Порівняльна матриця типів ==

{| class="wikitable"
! Характеристика !! РВ !! РН (Залишки) !! РН (Обороти) !! РБ !! РР
|-
| Ключ запису || Вимірювання (+Період) або Реєстратор+№ || Реєстратор+№ || Реєстратор+№ || Реєстратор+№ || Реєстратор+№
|-
| Незалежний запис || '''Так''' || Ні || Ні || Ні || Ні
|-
| Періодичність || Опційна || Обов'язкова (Період) || Обов'язкова || Обов'язкова || Обов'язкова
|-
| Ресурси підсумовуються || Ні || Так (±) || Так (+) || Так (Дт/Кт) || Так
|-
| Вид руху (Прихід/Витрата) || — || '''Так''' || — || Дт/Кт || —
|-
| Таблиця залишків || — || '''Так''' || — || '''Так''' || —
|-
| Таблиця оборотів || — || Так (опц.) || '''Так''' || Так || —
|-
| Зв'язок із планом рахунків || — || — || — || '''Так''' || —
|-
| Зв'язок із ПВР || — || — || — || — || '''Так'''
|-
| Період дії / витіснення || — || — || — || — || '''Так'''
|-
| Базовий період || — || — || — || — || '''Так'''
|-
| Графік часу || — || — || — || — || '''Так'''
|-
| Субконто || — || — || — || '''Так''' || —
|-
| Перерахунки || — || — || — || — || '''Так'''
|-
| Типові приклади || Курси валют, ціни, кадрова історія, графік роботи || Товари на складах, взаєморозрахунки || Продажі, витрати за статтями || Госпрозрахунковий, управлінський, податковий облік || Нарахування ЗП, утримання
|}

= 6. Метамодель: як регістр задається =

== 6.1. Місце в репозиторії метаданих ==

<pre>
Конфігурація K2 ERP
├── Довідники
├── Документи
├── Плани рахунків ← використовується РБ
├── Плани видів характеристик ← використовується як тип субконто / вимірювання
├── Плани видів розрахунку ← використовується РР
└── Регістри ◄── НОВИЙ РОЗДІЛ
├── Регістри відомостей
│ └── КурсиВалют
│ ├── Вимірювання → Валюта
│ ├── Ресурси → Курс, Кратність
│ ├── Реквізити →
│ └── Форми → ФормаСписку, ФормаЗапису
├── Регістри накопичення
│ └── ТовариНаСкладах
│ ├── Вимірювання → Номенклатура, Склад, Партія
│ ├── Ресурси → Кількість, Сума
│ ├── Реквізити → Коментар
│ └── Реєстратори → [ПрихіднаНакладна, ВидатковаНакладна, ...]
├── Регістри бухгалтерії
│ └── Госпрозрахунковий
│ ├── Вимірювання → Організація, Підрозділ(небаланс.)
│ ├── Ресурси → Сума(баланс.), Кількість(небаланс.), ВалютнаСума
│ ├── Реквізити → Зміст, № журналу
│ └── Реєстратори → [...]
└── Регістри розрахунку
└── Нарахування
├── Вимірювання → Співробітник(баз.), Підрозділ
├── Ресурси → Результат, ВідпрацьованоДнів
├── Реквізити → Графік
├── Перерахунки → ПерерахунокЗаБазою
└── Реєстратори → [НарахуванняЗП]
</pre>

== 6.2. Загальні властивості будь-якого регістру ==

{| class="wikitable"
! Властивість !! Тип !! Обов'язк. !! Опис / допустимі значення
|-
| <code>Ім'я</code> || Ідентифікатор || Так || Унікальне в межах роду. Латиниця/кирилиця, ≤ 80 симв., без пробілів.
|-
| <code>Синонім</code> || Рядок || Ні || Подання для користувача.
|-
| <code>Коментар</code> || Текст || Ні || —
|-
| <code>ВидРегістру</code> || Перелік || Так || <code>Відомостей</code> / <code>Накопичення</code> / <code>Бухгалтерії</code> / <code>Розрахунку</code>. '''Незмінна після створення.'''
|-
| <code>РежимЗапису</code> || Перелік || Так || <code>Незалежний</code> / <code>ПідпорядкованийРеєстратору</code>. Для РН/РБ/РР — примусово <code>ПідпорядкованийРеєстратору</code>.
|-
| <code>Періодичність</code> || Перелік || Так || <code>Неперіодичний</code>, <code>ВМежахСекунди</code>, <code>ВМежахДня</code>, <code>ВМежахМісяця</code>, <code>ВМежахКварталу</code>, <code>ВМежахРоку</code>, <code>ПоПозиціїРеєстратора</code>.
|-
| <code>Реєстратори</code> || Список посилань на типи документів || Умовно || Обов'язково для РН/РБ/РР та підпорядкованого РВ. Порожній список = регістр непридатний до запису.
|-
| <code>БлокуванняДаних</code> || Перелік || Ні || <code>Автоматичне</code> / <code>Кероване</code> (за замовчуванням <code>Кероване</code>).
|-
| <code>ВключатиДоЗвітів</code> || Булево || Ні || Показувати в універсальному конструкторі звітів.
|-
| <code>ПравоДоступуЗаЗамовчуванням</code> || Перелік || Ні || <code>Заборонено</code> / <code>Читання</code>.
|-
| <code>ВикористовуватиРLS</code> || Булево || Ні || Row-level security (розділ 7.9).
|-
| <code>Партиціонування</code> || Структура || Ні || <code>Немає</code> / <code>ЗаПеріодом(RANGE, крок)</code> / <code>ЗаВимірюванням(HASH, n)</code>.
|}

== 6.3. Поля регістру ==

Кожне поле має:
{| class="wikitable"
! Властивість !! Опис
|-
| <code>Ім'я</code>, <code>Синонім</code> || Ідентифікація.
|-
| <code>Роль</code> || <code>Вимірювання</code> / <code>Ресурс</code> / <code>Реквізит</code>.
|-
| <code>Тип</code> || Примітивний (<code>Число(p,s)</code>, <code>Рядок(n)</code>, <code>Дата</code>, <code>Булево</code>, <code>УНІ</code>), посилальний (<code>Довідник.X</code>, <code>Документ.Y</code>, <code>Перерахування.Z</code>, <code>ПланРахунків.A</code>, <code>ПланВидівХарактеристик.B</code>) або '''складений''' (список типів).
|-
| <code>Індексувати</code> || <code>Не індексувати</code> / <code>Індексувати</code> / <code>ІндексуватиЗДодаткомВимірювань</code>.
|-
| <code>Ведуче</code> (Master) || Тільки для вимірювань. Якщо <code>Істина</code> — записи регістру видаляються разом з об'єктом, на який посилається вимірювання; регістр показується у формі цього об'єкта.
|-
| <code>ОсновнийВідбір</code> || Брати участь у стандартному відборі форми списку.
|-
| <code>ЗаборонитиНезаповненіЗначення</code> || Валідація на запис.
|}

Специфічні прапорці полів по типах регістрів:

{| class="wikitable"
! Прапорець !! Застосовний до !! Опис
|-
| <code>Балансовий</code> || Ресурс/Вимірювання РБ || Ресурс бере участь у контролі рівності Дт=Кт; має єдине значення на запис (а не пару Дт/Кт). Вимірювання балансове — однакове для Дт і Кт.
|-
| <code>Облік</code> (AccountingFlag) || Ресурс РБ || Посилання на ознаку обліку рахунка з ПР; ресурс заповнюється, лише якщо ознака встановлена.
|-
| <code>ОблікСубконто</code> || Ресурс РБ || Посилання на ознаку обліку субконто (напр. кількісний облік у розрізі субконто).
|-
| <code>Базове</code> (BaseDimension) || Вимірювання РР || Використовується для зіставлення записів під час отримання бази розрахунку.
|-
| <code>ВикористовуватиПоточніЗначення</code> || Ресурс/Реквізит РР || —
|}

== 6.4. Специфічні властивості за типами ==

=== 6.4.1. Регістр відомостей ===
{| class="wikitable"
! Властивість !! Значення !! Примітка
|-
| <code>Періодичність</code> || Неперіодичний … ПоПозиціїРеєстратора || Визначає наявність поля <code>Період</code> і його гранулярність.
|-
| <code>РежимЗапису</code> || Незалежний / ПідпорядкованийРеєстратору || У незалежному ключ = (Період) + Вимірювання.
|-
| <code>ОсновнийВідбір</code> || —
|-
| <code>ДозволитиПідсумки</code> || — || У РВ підсумків немає; замість них — зрізи.
|}

'''Ключ унікальності:'''
* Незалежний неперіодичний: <code>UNIQUE(Вимірювання…)</code>
* Незалежний періодичний: <code>UNIQUE(Період, Вимірювання…)</code>
* Підпорядкований: <code>PK(Реєстратор, НомерРядка)</code>, унікальність за вимірюваннями '''не''' контролюється.

=== 6.4.2. Регістр накопичення ===
{| class="wikitable"
! Властивість !! Значення
|-
| <code>ВидРегістру</code> || <code>Залишки</code> / <code>Обороти</code>
|-
| <code>ДозволитиПідсумкиЗалишків</code> || Булево (тільки для виду «Залишки»)
|-
| <code>ДозволитиПідсумкиОборотів</code> || Булево
|-
| <code>ПеріодичністьПідсумківОборотів</code> || <code>День</code> / <code>Місяць</code> (тільки для виду «Обороти»)
|-
| <code>Агрегати</code> || Список визначень агрегатів (тільки для виду «Обороти»), див. 7.4.4
|-
| <code>РежимАгрегатів</code> || <code>Агрегати</code> / <code>Підсумки</code>
|}

=== 6.4.3. Регістр бухгалтерії ===
{| class="wikitable"
! Властивість !! Значення !! Примітка
|-
| <code>ПланРахунків</code> || Посилання на об'єкт «План рахунків» || '''Обов'язково.''' Незмінне після створення.
|-
| <code>Кореспонденція</code> || Булево || <code>Істина</code> → подвійний запис (поля <code>РахунокДт</code>/<code>РахунокКт</code>); <code>Хиба</code> → уніграфічний (<code>Рахунок</code> + <code>ВидРуху</code>).
|-
| <code>ДозволитиРозділенняПідсумків</code> || Булево
|-
| <code>МаксКількістьСубконто</code> || Число (успадковується з ПР) || Ліміт платформи: 5 ''[узгодити; 1С — 3 за замовчуванням, до 5]''
|}

Пов'язаний об'єкт '''План рахунків''' повинен підтримувати:
* ієрархію рахунків, <code>Код</code>, <code>Найменування</code>, <code>Вид</code> (Активний/Пасивний/Активно-пасивний);
* <code>Забалансовий</code> (булево);
* <code>Ознаки обліку</code> (набір булевих реквізитів, напр. «Кількісний», «Валютний»);
* табличну частину <code>ВидиСубконто</code> (ВидСубконто → ПВХ, ''Тільки обороти'', ''Підсумкова сума'', ознаки обліку субконто);
* <code>МаксКількістьСубконто</code>.

=== 6.4.4. Регістр розрахунку ===
{| class="wikitable"
! Властивість !! Значення !! Примітка
|-
| <code>ПланВидівРозрахунку</code> || Посилання || '''Обов'язково.'''
|-
| <code>Періодичність</code> || <code>День</code>/<code>Місяць</code>/<code>Квартал</code>/<code>Рік</code> || Період реєстрації.
|-
| <code>ПеріодДії</code> || Булево || Вмикає поля <code>ПеріодДіїПочаток/Кінець</code>, фактичні періоди дії та витіснення.
|-
| <code>БазовийПеріод</code> || <code>БезБазовогоПеріоду</code> / <code>ЗаПеріодДії</code> / <code>ЗаПеріодРеєстрації</code> || Режим отримання бази.
|-
| <code>Графік</code> || Посилання на РВ || Регістр-графік часу.
|-
| <code>ЗначенняГрафіка</code> || Ресурс регістру-графіка || Напр. «Значення» (1/0 — робочий день) або «Годин».
|-
| <code>ДатаГрафіка</code> || Вимірювання регістру-графіка типу <code>Дата</code> || —
|-
| <code>Перерахунки</code> || Список підпорядкованих об'єктів «Перерахунок» || Див. 7.5.3.
|}

Об'єкт '''Перерахунок''' (підпорядкований РР):
* <code>Ім'я</code>;
* <code>Вимірювання</code> — список, кожне зіставляється з вимірюванням основного РР (<code>ВимірюванняРегістру</code>);
* правило: перерахунок реєструє «об'єкт перерахунку» = (Реєстратор, ВидРозрахунку, Вимірювання…).

'''План видів розрахунку''' повинен підтримувати:
* <code>ВикористовуєПеріодДії</code>;
* табличні частини <code>БазовіВидиРозрахунку</code>, <code>ВитісняючіВидиРозрахунку</code>, <code>ВедучіВидиРозрахунку</code>;
* <code>ЗалежністьВідБази</code>: <code>НеЗалежить</code> / <code>ЗаПеріодДії</code> / <code>ЗаПеріодРеєстрації</code>.

== 6.5. Стандартні реквізити (генеруються автоматично) ==

{| class="wikitable"
! Реквізит !! РВ !! РН !! РБ !! РР !! Тип
|-
| <code>Період</code> || якщо періодичний || + || + || + (період реєстрації) || Дата/час
|-
| <code>Реєстратор</code> || якщо підпорядкований || + || + || + || Складене посилання (ДокументПосилання)
|-
| <code>НомерРядка</code> || якщо підпорядкований || + || + || + || Число(9,0)
|-
| <code>Активність</code> || якщо підпорядкований || + || + || + || Булево
|-
| <code>ВидРуху</code> || — || тільки «Залишки» || — || — || Перелік {Прихід, Витрата}
|-
| <code>Рахунок</code> || — || — || + (без кореспонденції) || — || ПланРахунківПосилання
|-
| <code>РахунокДт</code>, <code>РахунокКт</code> || — || — || + (з кореспонденцією) || — || ПланРахунківПосилання
|-
| <code>ВидРухуРахунку</code> || — || — || + (без кореспонденції) || — || Перелік {Дебет, Кредит}
|-
| <code>Субконто</code> (колекція) || — || — || + || — || Відповідність(ВидСубконто→Значення)
|-
| <code>ВидРозрахунку</code> || — || — || — || + || ПВРПосилання
|-
| <code>ПеріодДіїПочаток</code>, <code>ПеріодДіїКінець</code> || — || — || — || + (якщо ПеріодДії) || Дата
|-
| <code>БазовийПеріодПочаток</code>, <code>БазовийПеріодКінець</code> || — || — || — || + (якщо БазовийПеріод) || Дата
|-
| <code>Сторно</code> || — || — || — || + || Булево
|}

== 6.6. Кількісні обмеження метамоделі ==

{| class="wikitable"
! Параметр !! Ліміт !! Примітка
|-
| Кількість вимірювань || 20 || Понад 8 — попередження конструктора (деградація підсумків)
|-
| Кількість ресурсів || 20 ||
|-
| Кількість реквізитів || 30 ||
|-
| Кількість типів у складеному типі поля || 32 ||
|-
| Кількість реєстраторів || Не обмежено ||
|-
| Максимум субконто на рахунок || 5 ||
|-
| Довжина ключа підсумків || ≤ 900 байт (обмеження індексу MS SQL) || Валідація в конструкторі
|-
| Глибина періодичності підсумків || День / Місяць || Тиждень/Квартал — не підтримуються (обчислюються згортанням)
|}

== 6.7. Декларативний опис (DSL) ==

Регістр зберігається в репозиторії у вигляді XML/YAML-маніфесту. Приклад:

<syntaxhighlight lang="yaml">
# --- Регістр накопичення (вид: Залишки) ---
register:
name: ТовариНаСкладах
kind: Accumulation
accumulationKind: Balance
synonym: "Товари на складах"
periodicity: WithinSecond
writeMode: SubordinateToRecorder
enableBalanceTotals: true
enableTurnoverTotals: true
partitioning: { mode: RangeByPeriod, step: month }

dimensions:
- { name: Номенклатура, type: "Довідник.Номенклатура", master: true, index: true }
- { name: Склад, type: "Довідник.Склади", master: true, index: true }
- { name: Партія, type: ["Документ.ПрихіднаНакладна", "Документ.ВведенняЗалишків"], index: false }
- { name: Характеристика, type: "ПланВидівХарактеристик.Характеристики", nullable: true }

resources:
- { name: Кількість, type: "Число(15,3)" }
- { name: Сума, type: "Число(15,2)" }

attributes:
- { name: Коментар, type: "Рядок(200)" }

recorders:
- Документ.ПрихіднаНакладна
- Документ.ВидатковаНакладна
- Документ.ПереміщенняТоварів
- Документ.Інвентаризація
</syntaxhighlight>

<syntaxhighlight lang="yaml">
# --- Регістр відомостей (періодичний, незалежний) ---
register:
name: КурсиВалют
kind: Information
periodicity: WithinDay
writeMode: Independent
dimensions:
- { name: Валюта, type: "Довідник.Валюти", master: true }
resources:
- { name: Курс, type: "Число(15,4)" }
- { name: Кратність, type: "Число(10,0)", default: 1 }
</syntaxhighlight>

<syntaxhighlight lang="yaml">
# --- Регістр бухгалтерії ---
register:
name: Госпрозрахунковий
kind: Accounting
chartOfAccounts: ПланРахунків.Госпрозрахунковий
correspondence: true
periodicity: WithinSecond
dimensions:
- { name: Організація, type: "Довідник.Організації", balance: true }
- { name: Підрозділ, type: "Довідник.Підрозділи", balance: false }
resources:
- { name: Сума, type: "Число(15,2)", balance: true }
- { name: Кількість, type: "Число(15,3)", balance: false, accountingFlag: Кількісний }
- { name: ВалютнаСума, type: "Число(15,2)", balance: false, accountingFlag: Валютний }
attributes:
- { name: Зміст, type: "Рядок(255)" }
- { name: Валюта, type: "Довідник.Валюти" }
recorders: [Документ.БухгалтерськаОперація, Документ.ПрихіднаНакладна]
</syntaxhighlight>

<syntaxhighlight lang="yaml">
# --- Регістр розрахунку ---
register:
name: Нарахування
kind: Calculation
calculationTypesPlan: ПланВидівРозрахунку.ОсновніНарахування
periodicity: Month
actionPeriod: true
basePeriod: ByActionPeriod
schedule:
register: РегістрВідомостей.ГрафікРоботи
valueResource: Значення
dateDimension: ДатаГрафіка
dimensions:
- { name: Співробітник, type: "Довідник.Співробітники", baseDimension: true, master: true }
- { name: Підрозділ, type: "Довідник.Підрозділи" }
resources:
- { name: Результат, type: "Число(15,2)" }
- { name: ВідпрацьованоДнів, type: "Число(5,0)" }
- { name: НормаДнів, type: "Число(5,0)" }
recalculations:
- name: ПерерахунокЗаБазою
dimensions:
- { name: Співробітник, registerDimension: Співробітник }
recorders: [Документ.НарахуванняЗарплати]
</syntaxhighlight>

{{Note|Розширений каталог із 17 прикладів регістрів усіх типів і підвидів — з деклараціями, даними у фізичних таблицях, запитами, наскрізними сценаріями та антипатернами — див. '''Додаток Д'''.}}

== 6.8. UI конструктора метаданих ==

=== 6.8.1. Загальний макет ===
<pre>
┌─ Конфігуратор K2 ERP ─────────────────────────────────────────────────────────┐
│ Файл Правка Конфігурація Адміністрування Сервіс Довідка │
├──────────────────────┬────────────────────────────────────────────────────────┤
│ Дерево конфігурації │ Регістр накопичення: ТовариНаСкладах │
│ │ ┌──────┬─────────┬──────────┬──────────┬───────────┐ │
│ ▾ Регістри │ │Основ.│Дані │Реєстратор│Форми │Права │ │
│ ▸ відомостей │ └──────┴─────────┴──────────┴──────────┴───────────┘ │
│ ▾ накопичення │ │
│ ▾ ТовариНаСклад. │ Ім'я [ТовариНаСкладах.............] │
│ ▾ Вимірювання │ Синонім [Товари на складах...........] │
│ Номенклат. │ Коментар [.............................] │
│ Склад │ │
│ Партія │ Вид регістру ( ) Обороти (•) Залишки │
│ ▾ Ресурси │ Періодичність [ У межах секунди ▾] │
│ Кількість │ Режим запису [ Підпорядкований реєстратору ▾] │
│ Сума │ │
│ ▸ Реквізити │ ☑ Дозволити підсумки залишків │
│ ▸ Форми │ ☑ Дозволити підсумки оборотів │
│ ▸ Взаєморозрах. │ Періодичність підсумків оборотів [Місяць ▾] │
│ ▸ бухгалтерії │ ☐ Дозволити розділення підсумків │
│ ▸ розрахунку │ │
│ │ Блокування даних [Кероване ▾] │
│ │ Партиціонування [За періодом, крок: місяць ▾] │
│ │ │
│ │ [ Конструктор рухів... ] [ Перевірити ] [ Закрити ] │
├──────────────────────┴────────────────────────────────────────────────────────┤
│ ⚠ Попередження: 4 вимірювання + місячні підсумки → оцінка таблиці підсумків │
│ ~ 12 млн записів/рік. Розгляньте виключення вимірювання «Партія» з підсумків.│
└───────────────────────────────────────────────────────────────────────────────┘
</pre>

=== 6.8.2. Палітра властивостей поля ===
<pre>
┌─ Властивості: Вимірювання «Партія» ────────────────┐
│ Ім'я [Партія...................] │
│ Синонім [Партія...................] │
│ Тип [Складений тип........ [...]]│
│ ├ Документ.ПрихіднаНакладна │
│ └ Документ.ВведенняЗалишків │
│ Індексувати [Не індексувати ▾] │
│ ☐ Ведуче │
│ ☐ Основний відбір │
│ ☐ Заборонити незаповнені значення │
│ ☑ Використовувати в підсумках │
│ Подання │
│ Підказка [Партія товару...........] │
└────────────────────────────────────────────────────┘
</pre>

=== 6.8.3. Вкладка «Реєстратори» ===
<pre>
┌─ ТовариНаСкладах → Реєстратори ────────────────────────────┐
│ ☑ Документ.ПрихіднаНакладна │
│ ☑ Документ.ВидатковаНакладна │
│ ☑ Документ.ПереміщенняТоварів │
│ ☑ Документ.Інвентаризація │
│ ☐ Документ.Замовлення │
│ ☐ Документ.РахунокНаОплату │
│ [Позначити всі] [Зняти]│
│ ───────────────────────────────────────────────────────── │
│ ⓘ Знімання прапорця для документа, що має рухи, вимагає │
│ очищення рухів. Знайдено рухів: 0 │
└────────────────────────────────────────────────────────────┘
</pre>

=== 6.8.4. Вимоги до конструктора ===
* ФТ-К-01. Валідація метаопису в реальному часі з переліком помилок/попереджень.
* ФТ-К-02. Попередній перегляд згенерованого DDL (кнопка «Показати SQL»).
* ФТ-К-03. Калькулятор оцінки обсягу таблиць підсумків (добуток кардинальностей вимірювань × кількість періодів).
* ФТ-К-04. Заборона неприпустимих комбінацій (напр. «Незалежний» + «Регістр накопичення»).
* ФТ-К-05. «Конструктор рухів» — генерація коду формування рухів за табличною частиною документа.
* ФТ-К-06. Порівняння/об'єднання конфігурацій має коректно обробляти об'єкти-регістри.
* ФТ-К-07. '''Генерація <code>.pyi</code>-стабів''' для кожного регістру за метаописом. Прикладний код звертається до полів динамічно (<code>__getattr__</code>), що недоступне для <code>mypy</code>; згенеровані стаби повертають статичну перевірку. Перегенеровуються при кожній зміні метаданих, перевіряються в CI (див. Е.6). ''Вимога специфічна для Python, аналога в 1С не має.''

= 7. Функціональні вимоги =

== 7.1. Набір записів і проведення документа ==

'''ФТ-01.''' Платформа надає прикладний об'єкт <code>НабірЗаписів</code> для кожного регістру з властивостями: <code>Відбір</code>, <code>Записувати</code>, і методами <code>Прочитати()</code>, <code>Записати(Заміщати)</code>, <code>Очистити()</code>, <code>ЗаблокуватиДляЗміни()</code>, <code>Вивантажити()</code>, <code>Завантажити()</code>.

'''ФТ-02.''' Для документа доступна колекція <code>Рухи</code> з наборами записів усіх регістрів, де документ вказано реєстратором.

'''ФТ-03. Сценарій проведення:'''

<uml>
@startuml
skinparam monochrome false
skinparam shadowing false
actor Користувач
participant "Форма\nдокумента" as UI
participant "Об'єкт\nДокумент" as Doc
participant "Менеджер\nпроведення" as PM
participant "Набори\nзаписів" as RS
database "СКБД" as DB

Користувач -> UI: Провести
UI -> Doc: Записати(РежимЗапису.Проведення)
activate Doc
Doc -> PM: НачатьТранзакцию()
PM -> DB: BEGIN
Doc -> Doc: ПередЗаписью()
Doc -> DB: UPDATE doc SET Проведений=1
Doc -> Doc: ОбработкаПроведения(Отказ, Режим)
note right of Doc
Прикладний код:
Рухи.ТовариНаСкладах.Записувати = Істина;
Рух = Рухи.ТовариНаСкладах.Добавить();
Рух.ВидРуху = ВидРухуНакопичення.Витрата;
...
// контроль залишків (оперативне проведення)
end note
Doc -> RS: (формування рухів у пам'яті)
Doc -> PM: ЗаписатьДвижения()
PM -> RS: для кожного НЗ з Записувати=Істина
RS -> DB: DELETE FROM rg_a_0012 WHERE rec_ref = :doc
RS -> DB: INSERT INTO rg_a_0012 (...) VALUES (...)
RS -> PM: ОновитиПідсумки(delta)
PM -> DB: MERGE rg_a_0012_tb (див. розд. 10.2)
Doc -> Doc: ПриЗаписи() / ПослеЗаписи()
alt Відмова = Хиба
PM -> DB: COMMIT
PM --> UI: Успіх
else Відмова = Істина або виключення
PM -> DB: ROLLBACK
PM --> UI: Помилка "Документ не проведено: ..."
end
deactivate Doc
@enduml
</uml>

'''ФТ-04.''' Запис набору записів у режимі <code>Заміщати = Істина</code> (за замовчуванням для рухів) виконує <code>DELETE</code> усіх записів за відбором + <code>INSERT</code> нових — атомарно.

'''ФТ-05.''' Скасування проведення документа: усі набори записів за реєстратором очищуються, підсумки коригуються, документ отримує <code>Проведений = Хиба</code>.

'''ФТ-06.''' Видалення документа-реєстратора (у т.ч. позначеного на видалення) '''зобов'язане''' каскадно видалити всі його рухи в межах однієї транзакції. Реалізація — на рівні платформи (не FK, оскільки посилання поліморфне) + фонова перевірка цілісності (розділ 7.10).

'''ФТ-07.''' Режими проведення:
{| class="wikitable"
! Режим !! Умова !! Поведінка
|-
| '''Оперативне''' || Дата документа = поточна дата, документ у межах «оперативної точки» || Дозволено контроль залишків «на зараз»; дата може перепризначатися на поточну.
|-
| '''Неоперативне''' || Дата в минулому/майбутньому або документ перепроводиться || Контроль залишків виконується на дату документа; можливий негативний залишок за налаштуванням.
|}

== 7.2. Активність записів ==
'''ФТ-08.''' Реквізит <code>Активність = Хиба</code> означає, що запис фізично існує, але '''не''' впливає на підсумки та не потрапляє до віртуальних таблиць.
'''ФТ-09.''' Зміна активності будь-якого запису тягне коригування підсумків.
'''ФТ-10.''' Скасування проведення документа переводить усі його записи в <code>Активність = Хиба</code> '''або''' видаляє їх — залежно від налаштування регістру <code>ПоведінкаПриСкасуванні</code> (<code>Видаляти</code> — за замовчуванням / <code>Деактивувати</code>).

== 7.3. Віртуальні таблиці ==

'''ФТ-11.''' Мова запитів надає для кожного регістру набір віртуальних таблиць. Транслятор перетворює звернення до них на SQL із використанням таблиць підсумків та «живих» рухів після ТА.

{| class="wikitable"
! Регістр !! Віртуальна таблиця !! Параметри !! Повертає
|-
| rowspan="3" | '''РВ''' || <code>ЗрізОстанніх</code> || (Період, Умова) || Останній запис на кожну комбінацію вимірювань з періодом ≤ Період
|-
| <code>ЗрізПерших</code> || (Період, Умова) || Перший запис з періодом ≥ Період
|-
| ''(основна)'' || — || Усі записи
|-
| rowspan="4" | '''РН.Залишки''' || <code>Залишки</code> || (Період, Умова) || Вимірювання + <code><Ресурс>Залишок</code>
|-
| <code>Обороти</code> || (Початок, Кінець, Періодичність, Умова) || <code><Ресурс>Прихід</code>, <code><Ресурс>Витрата</code>, <code><Ресурс>Оборот</code>
|-
| <code>ЗалишкиІОбороти</code> || (Початок, Кінець, Періодичність, МетодДоповнення, Умова) || <code><Р>ПочатковийЗалишок</code>, <code><Р>Прихід</code>, <code><Р>Витрата</code>, <code><Р>Оборот</code>, <code><Р>КінцевийЗалишок</code>
|-
| ''(основна)'' || — || Рухи
|-
| '''РН.Обороти''' || <code>Обороти</code> || (Початок, Кінець, Періодичність, Умова) || <code><Ресурс>Оборот</code>
|-
| rowspan="6" | '''РБ''' || <code>Залишки</code> || (Період, УмоваРахунку, Субконто, Умова) || <code><Р>Залишок</code>, <code><Р>ЗалишокДт</code>, <code><Р>ЗалишокКт</code>
|-
| <code>Обороти</code> || (Початок, Кінець, Періодичність, УмоваРахунку, Субконто, Умова, УмоваКорРахунку, КорСубконто) || <code><Р>Оборот</code>, <code><Р>ОборотДт</code>, <code><Р>ОборотКт</code>
|-
| <code>ЗалишкиІОбороти</code> || (…) || Повний набір
|-
| <code>ОборотиДтКт</code> || (Початок, Кінець, Періодичність, УмоваРахункуДт, СубконтоДт, УмоваРахункуКт, СубконтоКт) || Кореспонденції
|-
| <code>ДвиженияССубконто</code> || (Початок, Кінець, УмоваРахунку, Субконто, Умова) || Рухи з розшифровкою субконто
|-
| <code>Субконто</code> || (Умова, Порядок…) || Значення субконто записів
|-
| rowspan="4" | '''РР''' || <code>ДаніГрафіка</code> || (Умова) || <code>ЗначенняПеріодуДії</code>, <code>ЗначенняПеріодуРеєстрації</code>, <code>ЗначенняБазовогоПеріоду</code>, <code>ЗначенняФактичногоПеріодуДії</code>
|-
| <code>ФактичнийПеріодДії</code> || (Умова) || Записи з фактичними (після витіснення) межами
|-
| <code>БазаРозрахунку</code> || (ВимірюванняБази, ВимірюванняОсновногоРегістру, Розрізи, ВидиРозрахунку, Умова) || Агреговані значення ресурсів базових видів розрахунку
|-
| ''(основна)'' || — || Рухи
|}

'''ФТ-12.''' Приклад запиту:
<syntaxhighlight lang="sql">
ВИБРАТИ
Залишки.Номенклатура,
Залишки.Склад,
Залишки.КількістьЗалишок,
Обороти.КількістьПрихід,
Обороти.КількістьВитрата
З
РегістрНакопичення.ТовариНаСкладах.ЗалишкиІОбороти(
&ПочатокПеріоду,
&КінецьПеріоду,
Місяць,
Рух,
Склад = &Склад
І Номенклатура В ІЄРАРХІЇ (&ГрупаНоменклатури)
) ЯК Залишки
</syntaxhighlight>

'''ФТ-13.''' Параметри віртуальних таблиць '''зобов'язані''' транслюватися у <code>WHERE</code> підзапиту до звернення до підсумків (push-down), а не фільтруватися після агрегації.

== 7.4. Підсумки ==

=== 7.4.1. Модель підсумків залишків ===
Таблиця залишків зберігає '''кумулятивний залишок на початок кожного періоду''' + спеціальний рядок «підсумок за всі періоди» з <code>period = '5999-11-01'</code> (маркер MAXPERIOD).

<pre>
Таблиця підсумків (місячна) ТА
┌────┬────┬────┬────┬────┐ ▼
─────┬────┬────┬───┴────┴────┴────┴────┴────┴────────────────────┬──────────►
│ │ │ 01.10 01.11 01.12 01.01 01.02 15.02 t
│ │ │ ● ● ● ● ●
│ │ │ бал. бал. бал. бал. бал.
└─ «живі» рухи ─┘
(сканування)
Залишок на 10.02 = Підсумок(01.02) + Σ рухів (01.02 … 10.02]
Залишок на 20.02 = Підсумок(01.02) + Σ рухів (01.02 … 20.02] // після ТА — теж
</pre>

'''ФТ-14.''' Регламентна операція «Перерахунок підсумків» перебудовує таблиці підсумків з нуля.
'''ФТ-15.''' Регламентна операція «Встановлення періоду розрахунку підсумків» переносить ТА вперед/назад.
'''ФТ-16.''' При записі рухів раніше ТА підсумки коригуються ''інкрементально'' (див. 10.2), без повного перерахунку.

=== 7.4.2. Розділення підсумків ===
'''ФТ-17.''' За увімкненого <code>ДозволитиРозділенняПідсумків</code> у таблиці підсумків додається колонка <code>splitter smallint</code>. Одночасні транзакції пишуть у різні «сплітери», що усуває конкуренцію за рядок. Читання агрегує по всіх сплітерах. Регламентне завдання зливає сплітери.

=== 7.4.3. Обороти ===
'''ФТ-18.''' Таблиця оборотів зберігає агрегати за календарний період (день або місяць — за налаштуванням), без кумуляції.

=== 7.4.4. Агрегати (тільки РН виду «Обороти») ===
'''ФТ-19.''' Агрегат — додаткова матеріалізована таблиця з підмножиною вимірювань і власною періодичністю (День/Місяць/Квартал/Рік). Оптимізатор запитів обирає найдешевший агрегат, що покриває запит.
'''ФТ-20.''' Режими: <code>Реальний час</code> (оновлюється при записі рухів) / <code>Регламентний</code> (оновлюється завданням; запит враховує рухи після дати актуальності агрегату).
'''ФТ-21.''' «Порадник агрегатів» аналізує статистику запитів і пропонує склад агрегатів (<code>ВизначитиОптимальніАгрегати()</code>).

== 7.5. Механіка регістру розрахунку ==

=== 7.5.1. Витіснення за періодом дії ===
'''ФТ-22.''' Якщо у ПВР для виду розрахунку A вказано B у складі «Витісняючі види розрахунку», то запис виду B скорочує фактичний період дії запису виду A на інтервал перетину.

<pre>
Період реєстрації: Січень 2026. Пріоритет витіснення: Лікарняний > Відпустка > Оклад

Заявлені періоди дії:
Оклад 01.01 ├══════════════════════════════════════════════┤ 31.01
Відпустка 10.01 ├════════════┤ 17.01
Лікарняний 14.01 ├════════════┤ 22.01

Фактичні періоди дії (rg_c_XXXX_ap):
Оклад 01.01 ├═══════┤ 09.01 23.01 ├════════════┤ 31.01
Відпустка 10.01 ├═══┤ 13.01
Лікарняний 14.01 ├════════════┤ 22.01

⇒ у таблиці фактичних періодів «Оклад» породжує ДВА інтервали (запис — один).
</pre>

'''ФТ-23.''' Фактичні періоди дії матеріалізуються у службовій таблиці <code>rg_c_<код>_ap</code> під час запису набору записів.
'''ФТ-24.''' Витіснення обчислюється в межах збігу '''усіх''' вимірювань регістру та перетину періодів реєстрації, визначених ПВР.

=== 7.5.2. Базовий період і база розрахунку ===
'''ФТ-25.''' Віртуальна таблиця <code>БазаРозрахунку</code> повертає суму ресурсів записів базових видів розрахунку, зіставлених за базовими вимірюваннями, з урахуванням режиму <code>ЗалежністьВідБази</code>:
* <code>ЗаПеріодДії</code> — беруться записи, чий '''період дії''' перетинається з базовим періодом поточного запису; результат пропорційно розподіляється за часткою перетину (за графіком, якщо заданий);
* <code>ЗаПеріодРеєстрації</code> — беруться записи, чий '''період реєстрації''' потрапляє в базовий період.

=== 7.5.3. Перерахунки ===
'''ФТ-26.''' При записі/зміні/видаленні запису базового виду розрахунку платформа '''автоматично''' формує записи у таблиці перерахунку для всіх залежних записів (за збігом вимірювань перерахунку та потраплянням у базовий період).
'''ФТ-27.''' Прикладний код читає перерахунок як набір записів, перепроводить відповідні документи та очищує оброблені записи.
'''ФТ-28.''' Перерахунок доступний як об'єкт для звіту «Документи до перерахунку».

=== 7.5.4. Графік часу ===
'''ФТ-29.''' Графік — це РВ з обов'язковим вимірюванням типу <code>Дата</code> та числовим ресурсом. Віртуальна таблиця <code>ДаніГрафіка</code> повертає суму значень графіка за відповідний період (дії / реєстрації / базовий / фактичний період дії).
'''ФТ-30.''' Якщо у графіку є додаткові вимірювання (напр. <code>ВидГрафіка</code>), вони зіставляються з однойменними реквізитами/вимірюваннями РР.

== 7.6. Прикладний API ==

<syntaxhighlight lang="python">
from datetime import date
from decimal import Decimal

from k2.registers import AccumulationMovementType, DataLock, DataLockMode, Registers
from k2.documents import Document, PostingContext

# ============ Регістр відомостей: незалежний запис ============
mgr = Registers.information("КурсиВалют")

rm = mgr.create_record_manager()
rm.Період = date(2026, 7, 17)
rm.Валюта = usd
rm.Курс = Decimal("41.85")
rm.Кратність = 1
rm.write(replace=True) # INSERT ... ON CONFLICT DO UPDATE

# зріз останніх
row = mgr.get_last(date.today(), {"Валюта": usd})
курс: Decimal = row.Курс

# АП-1: масове завантаження — ОДИН запит, а не цикл із write() усередині
rs = mgr.create_record_set()
rs.load([{"Період": d, "Валюта": v, "Курс": k, "Кратність": 1}
for d, v, k in nbu_rates]) # 3 000 курсів
rs.write(replace=True) # 1 × executemany, ~40 мс

# ============ Регістр накопичення: рухи документа ============
class ВидатковаНакладна(Document):

def on_posting(self, ctx: PostingContext) -> None:
rs = self.movements.ТовариНаСкладах
rs.write = True # набір буде записано наприкінці транзакції
rs.clear()

# АП-1: набір наповнюється генератором, запис — одним batch
rs.extend(
rs.new(
Період=self.Дата,
ВидРуху=AccumulationMovementType.EXPENSE,
Номенклатура=r.Номенклатура,
Склад=self.Склад,
Партія=r.Партія,
Кількість=r.Кількість,
Сума=r.Сума,
)
for r in self.Товари
)

# керовані блокування перед контролем залишків
with DataLock() as dl: # __enter__ виконує lock()
li = dl.add("РегістрНакопичення.ТовариНаСкладах.Залишки")
li.mode = DataLockMode.EXCLUSIVE
li.data_source = rs.unload("Номенклатура", "Склад")
li.use_from_data_source("Номенклатура", "Номенклатура")
li.use_from_data_source("Склад", "Склад")

rs.write_now() # примусовий запис до контролю
self._control_balances(ctx) # прикладна перевірка від'ємних залишків

# ============ Регістр бухгалтерії ============
def _accounting(self) -> None:
rs = self.movements.Госпрозрахунковий
rs.write = True
for r in self.Товари:
e = rs.add_accounting_entry(
Період=self.Дата,
Організація=self.Організація,
РахунокДт=accounts["281"],
РахунокКт=accounts["631"],
Сума=r.Сума,
КількістьДт=r.Кількість,
)
e.subconto_dt[ВидиСубконто.Номенклатура] = r.Номенклатура
e.subconto_dt[ВидиСубконто.Склади] = self.Склад
e.subconto_kt[ВидиСубконто.Контрагенти] = self.Контрагент

# ============ Регістр розрахунку ============
def _calculation(self) -> None:
rs = self.movements.Нарахування
rs.write = True
rs.append(rs.new(
ВидРозрахунку=calc_types["Оклад"],
Період=self.Дата, # період реєстрації
ПеріодДіїПочаток=date(2026, 7, 1),
ПеріодДіїКінець=date(2026, 7, 31),
БазовийПеріодПочаток=date(2026, 6, 1),
БазовийПеріодКінець=date(2026, 6, 30),
Співробітник=self.Співробітник,
Результат=Decimal(0), # заповниться після розрахунку
))
rs.write_now()

# Отримання даних графіка та бази розрахунку — запитом (розділ 7.3), не циклом.
</syntaxhighlight>

{{Note|'''Про кириличні ідентифікатори.''' Python 3 підтримує Unicode в іменах (PEP 3131), тому <code>rm.Валюта</code> і <code>rs.new(Номенклатура=…)</code> — валідний код; прикладна термінологія зберігається без транслітерації. '''Але''' доступ до полів регістру динамічний, тому <code>mypy</code> його не перевіряє — компенсується генерацією <code>.pyi</code>-стабів (ФТ-К-07, Додаток Е.6). Ключові слова API (<code>write</code>, <code>clear</code>, <code>new</code>) залишаються англійськими; змішування — свідомий компроміс, підлягає узгодженню (В15).}}

{{Note|'''Антипатерн, специфічний для Python (А-15).''' Спокуса написати <code>for r in self.Товари: rs.add(...).write()</code> дає 100 round-trip'ів до СКБД замість одного і збільшує час проведення з 300 мс до ~10 с. Це порушення АП-1 і найчастіша помилка при переході з ORM-мислення. Детектор — Е.7.}}

== 7.7. Блокування та конкурентність ==

{| class="wikitable"
! № !! Вимога
|-
| ФТ-31 || Режим керованих блокувань — за замовчуванням. Рівень ізоляції транзакцій: <code>READ COMMITTED</code> (PostgreSQL) / <code>READ COMMITTED SNAPSHOT</code> (MS SQL).
|-
| ФТ-32 || Об'єкт <code>DataLock</code> дозволяє встановити розділювальне/виняткове блокування на «простір» регістру за значеннями вимірювань (реалізація — <code>pg_advisory_xact_lock</code> за хешем ключа або <code>SELECT ... FOR UPDATE</code> по таблиці підсумків).
|-
| ФТ-33 || Запис рухів документа блокує тільки записи цього реєстратора (PK містить реєстратор першим).
|-
| ФТ-34 || Оновлення підсумків не повинно призводити до дедлоків: усі <code>MERGE</code>-операції в межах транзакції виконуються у детермінованому порядку сортування ключа.
|-
| ФТ-35 || Гарантія: паралельне проведення двох документів з різними наборами вимірювань не конкурує (за увімкненого розділення підсумків).
|-
| ФТ-36 || Таймаут очікування блокування — 20 с (налаштовується); при перевищенні — керована помилка з текстом конфліктного ключа.
|}

== 7.8. Права доступу ==

'''ФТ-37.''' Для регістру визначаються права: <code>Читання</code>, <code>Додавання</code>, <code>Зміна</code>, <code>Видалення</code>, <code>Перегляд</code>, <code>Редагування</code>, <code>ПереглядПідсумків</code>.
'''ФТ-38.''' Обмеження на рівні записів (RLS) задаються шаблоном умови по вимірюваннях; транслюються в <code>WHERE</code> усіх звернень, включно з віртуальними таблицями.
'''ФТ-39.''' ''Ризик:'' RLS на віртуальних таблицях залишків потребує узгодженості з підсумками. Рішення — RLS дозволено тільки по вимірюваннях, що входять до ключа підсумків; конструктор валідує це правило.

== 7.9. Журналювання, аудит, службові сервіси ==

'''ФТ-40.''' Реєстрація в журналі: перерахунок підсумків, зміна ТА, реструктуризація регістру, злиття сплітерів.
'''ФТ-41.''' Службовий сервіс «Перевірка цілісності регістрів»:
* «висячі» рухи (реєстратор не існує або не проведений);
* розбіжність підсумків і сум рухів (контрольний перерахунок у тіньову таблицю з порівнянням);
* некоректні фактичні періоди дії РР;
* для РБ — порушення рівності Дт = Кт за балансовим ресурсом у межах реєстратора.
'''ФТ-42.''' Звіт «Аналіз розміру регістрів»: кількість записів, розмір таблиць та індексів, дата останнього перерахунку підсумків.

= 8. Модель даних (як це виглядає в базі даних) =

== 8.1. Конвенції іменування ==

Фізичні імена '''не''' успадковують прикладні імена (обмеження довжини ідентифікатора, кирилиця, перейменування об'єктів). Ім'я будується за сурогатним кодом об'єкта метаданих <code><id></code> (4-значний hex/dec).

{| class="wikitable"
! Шаблон !! Призначення !! Приклад
|-
| <code>rg_i_<id></code> || Регістр відомостей — основна таблиця || <code>rg_i_0007</code>
|-
| <code>rg_a_<id></code> || Регістр накопичення — рухи || <code>rg_a_0012</code>
|-
| <code>rg_a_<id>_tb</code> || РН — підсумки залишків (Totals Balance) || <code>rg_a_0012_tb</code>
|-
| <code>rg_a_<id>_tt</code> || РН — підсумки оборотів (Totals Turnover) || <code>rg_a_0012_tt</code>
|-
| <code>rg_a_<id>_ag<n></code> || РН — агрегат № n || <code>rg_a_0031_ag1</code>
|-
| <code>rg_b_<id></code> || Регістр бухгалтерії — проводки || <code>rg_b_0020</code>
|-
| <code>rg_b_<id>_ed</code> || РБ — субконто (якщо винесено в дочірню таблицю) || <code>rg_b_0020_ed</code>
|-
| <code>rg_b_<id>_tb<k></code> || РБ — підсумки залишків за рівнем субконто k (0…N) || <code>rg_b_0020_tb2</code>
|-
| <code>rg_b_<id>_tt<k></code> || РБ — підсумки оборотів за рівнем субконто k || <code>rg_b_0020_tt1</code>
|-
| <code>rg_b_<id>_tc</code> || РБ — обороти між рахунками (кореспонденції) || <code>rg_b_0020_tc</code>
|-
| <code>rg_c_<id></code> || Регістр розрахунку — рухи || <code>rg_c_0040</code>
|-
| <code>rg_c_<id>_ap</code> || РР — фактичні періоди дії || <code>rg_c_0040_ap</code>
|-
| <code>rg_c_<id>_rc<m></code> || РР — перерахунок № m || <code>rg_c_0040_rc1</code>
|-
| <code>rg_<*>_<id>_opt</code> || Службова: ТА підсумків, налаштування || <code>rg_a_0012_opt</code>
|-
| <code>md_*</code> || Таблиці метаданих || <code>md_register</code>
|}

Колонки полів: <code>d<n></code> — вимірювання, <code>r<n></code> — ресурс, <code>a<n></code> — реквізит, де <code>n</code> — порядковий номер поля в метаописі (стабільний, не перевикористовується після видалення поля). Мапінг «прикладне ім'я ↔ фізична колонка» зберігається в <code>md_register_field</code>.

== 8.2. Типізація та зберігання значень ==

=== 8.2.1. Примітивні типи ===
{| class="wikitable"
! Тип платформи !! PostgreSQL !! MS SQL
|-
| Число(p,s) || <code>numeric(p,s)</code> || <code>numeric(p,s)</code>
|-
| Рядок(n) || <code>varchar(n)</code> || <code>nvarchar(n)</code>
|-
| Рядок(необмежена) || <code>text</code> || <code>nvarchar(max)</code>
|-
| Дата / ДатаЧас || <code>timestamp(0)</code> || <code>datetime2(0)</code>
|-
| Булево || <code>boolean</code> || <code>bit</code>
|-
| УНІ || <code>uuid</code> || <code>uniqueidentifier</code>
|}

=== 8.2.2. Посилальні типи ===
* '''Простий''' (один тип): одна колонка <code>d<n>_r uuid NOT NULL</code>, зовнішній ключ до таблиці об'єкта. Порожнє посилання = <code>'00000000-0000-0000-0000-000000000000'</code> (а не NULL — щоб зберегти семантику «пустого значення» у ключах підсумків).
* '''Складений''' (кілька типів / примітив + посилання): група колонок:

{| class="wikitable"
! Колонка !! Тип !! Опис
|-
| <code>d<n>_t</code> || <code>smallint</code> || Код типу: 1=Невизначено, 2=Булево, 3=Число, 4=Рядок, 5=Дата, ≥100 = <code>md_type.id</code> посилального типу
|-
| <code>d<n>_b</code> || <code>boolean</code> || Значення, якщо _t=2
|-
| <code>d<n>_n</code> || <code>numeric(38,10)</code> || Значення, якщо _t=3
|-
| <code>d<n>_s</code> || <code>varchar(N)</code> || Значення, якщо _t=4
|-
| <code>d<n>_d</code> || <code>timestamp(0)</code> || Значення, якщо _t=5
|-
| <code>d<n>_r</code> || <code>uuid</code> || Значення, якщо _t≥100
|}

{{Note|'''Проєктне рішення №1.''' Для складених типів обрано «широку» денормалізацію (кілька колонок), а не JSONB/варіант, тому що: (а) колонки індексуються та беруть участь у ключах підсумків; (б) B-tree по <code>(d1_t, d1_r)</code> дає range-scan, JSONB — ні; (в) сумісно з обома цільовими СКБД. Ціна — до 6 колонок на одне складене поле.}}

=== 8.2.3. Реєстратор ===
Завжди складений (будь-який з дозволених документів):
* <code>rec_t smallint NOT NULL</code> — код типу документа (<code>md_type.id</code>);
* <code>rec_r uuid NOT NULL</code> — посилання.

FK неможливий (поліморфізм) → цілісність забезпечується платформою + сервісом перевірки (ФТ-41).

=== 8.2.4. Маркери періодів ===
{| class="wikitable"
! Константа !! Значення !! Використання
|-
| <code>MINPERIOD</code> || <code>0001-01-01 00:00:00</code> || Нижня межа
|-
| <code>MAXPERIOD</code> || <code>5999-11-01 00:00:00</code> || Рядок «підсумок за всі періоди» в таблицях залишків
|}

== 8.3. Таблиці метаданих ==

<syntaxhighlight lang="sql">
-- ============ РЕПОЗИТОРІЙ МЕТАДАНИХ ============

CREATE TABLE md_type ( -- реєстр усіх типів конфігурації
id smallint PRIMARY KEY,
kind varchar(20) NOT NULL, -- Catalog|Document|Enum|ChartOfAccounts|ChartOfCalcTypes|Register|...
name varchar(80) NOT NULL,
table_name varchar(63),
UNIQUE (kind, name)
);

CREATE TABLE md_register (
id smallint PRIMARY KEY, -- = md_type.id
name varchar(80) NOT NULL UNIQUE,
synonym varchar(255),
comment text,
kind varchar(12) NOT NULL
CHECK (kind IN ('Information','Accumulation','Accounting','Calculation')),
-- загальні
write_mode varchar(24) NOT NULL DEFAULT 'SubordinateToRecorder'
CHECK (write_mode IN ('Independent','SubordinateToRecorder')),
periodicity varchar(24) NOT NULL DEFAULT 'Nonperiodical'
CHECK (periodicity IN ('Nonperiodical','WithinSecond','WithinDay','WithinMonth',
'WithinQuarter','WithinYear','ByRecorderPosition')),
lock_mode varchar(12) NOT NULL DEFAULT 'Managed',
use_rls boolean NOT NULL DEFAULT false,
partition_mode varchar(20) NOT NULL DEFAULT 'None',
partition_step varchar(10),
-- РН
accumulation_kind varchar(10) CHECK (accumulation_kind IN ('Balance','Turnover')),
enable_bal_totals boolean NOT NULL DEFAULT true,
enable_tno_totals boolean NOT NULL DEFAULT false,
tno_totals_period varchar(6) CHECK (tno_totals_period IN ('Day','Month')),
split_totals boolean NOT NULL DEFAULT false,
split_count smallint NOT NULL DEFAULT 1,
aggregates_mode varchar(10),
-- РБ
chart_of_accounts_id smallint REFERENCES md_type(id),
correspondence boolean NOT NULL DEFAULT true,
max_extdim_count smallint NOT NULL DEFAULT 3,
-- РР
calc_types_plan_id smallint REFERENCES md_type(id),
use_action_period boolean NOT NULL DEFAULT false,
base_period_mode varchar(24)
CHECK (base_period_mode IN ('None','ByActionPeriod','ByRegistrationPeriod')),
schedule_register_id smallint REFERENCES md_register(id),
schedule_value_field smallint,
schedule_date_field smallint,
-- службове
physical_table varchar(63) NOT NULL,
struct_version int NOT NULL DEFAULT 1,
CONSTRAINT chk_kind_props CHECK (
(kind = 'Accumulation' AND accumulation_kind IS NOT NULL) OR
(kind = 'Accounting' AND chart_of_accounts_id IS NOT NULL) OR
(kind = 'Calculation' AND calc_types_plan_id IS NOT NULL) OR
(kind = 'Information')
)
);

CREATE TABLE md_register_field (
id smallint NOT NULL, -- порядковий номер поля (стабільний)
register_id smallint NOT NULL REFERENCES md_register(id) ON DELETE CASCADE,
name varchar(80) NOT NULL,
synonym varchar(255),
role varchar(12) NOT NULL CHECK (role IN ('Dimension','Resource','Attribute')),
data_type_expr text NOT NULL, -- серіалізований опис типу (може бути складеним)
is_composite boolean NOT NULL DEFAULT false,
precision_ smallint,
scale_ smallint,
length_ int,
index_mode varchar(28) NOT NULL DEFAULT 'None'
CHECK (index_mode IN ('None','Index','IndexWithAddDimensions')),
is_master boolean NOT NULL DEFAULT false, -- «Ведуче»
in_default_filter boolean NOT NULL DEFAULT false,
deny_empty boolean NOT NULL DEFAULT false,
use_in_totals boolean NOT NULL DEFAULT true,
-- РБ
is_balance boolean NOT NULL DEFAULT false,
accounting_flag varchar(80),
extdim_flag varchar(80),
-- РР
is_base_dimension boolean NOT NULL DEFAULT false,
-- фізика
column_prefix varchar(8) NOT NULL, -- 'd3','r1','a2'
PRIMARY KEY (register_id, id),
UNIQUE (register_id, name)
);

CREATE TABLE md_register_recorder (
register_id smallint NOT NULL REFERENCES md_register(id) ON DELETE CASCADE,
doc_type_id smallint NOT NULL REFERENCES md_type(id),
PRIMARY KEY (register_id, doc_type_id)
);

CREATE TABLE md_register_aggregate (
id smallint NOT NULL,
register_id smallint NOT NULL REFERENCES md_register(id) ON DELETE CASCADE,
name varchar(80) NOT NULL,
periodicity varchar(8) NOT NULL CHECK (periodicity IN ('Day','Month','Quarter','Year')),
use_mode varchar(12) NOT NULL DEFAULT 'Auto',
is_realtime boolean NOT NULL DEFAULT false,
actual_upto timestamp(0),
physical_table varchar(63) NOT NULL,
PRIMARY KEY (register_id, id)
);
CREATE TABLE md_register_aggregate_dim (
register_id smallint NOT NULL,
aggregate_id smallint NOT NULL,
field_id smallint NOT NULL,
PRIMARY KEY (register_id, aggregate_id, field_id),
FOREIGN KEY (register_id, aggregate_id) REFERENCES md_register_aggregate(register_id, id) ON DELETE CASCADE
);

CREATE TABLE md_register_recalc (
id smallint NOT NULL,
register_id smallint NOT NULL REFERENCES md_register(id) ON DELETE CASCADE,
name varchar(80) NOT NULL,
physical_table varchar(63) NOT NULL,
PRIMARY KEY (register_id, id)
);
CREATE TABLE md_register_recalc_dim (
register_id smallint NOT NULL,
recalc_id smallint NOT NULL,
name varchar(80) NOT NULL,
reg_field_id smallint NOT NULL, -- вимірювання основного регістру
column_prefix varchar(8) NOT NULL,
PRIMARY KEY (register_id, recalc_id, name),
FOREIGN KEY (register_id, recalc_id) REFERENCES md_register_recalc(register_id, id) ON DELETE CASCADE
);
</syntaxhighlight>

== 8.4. Регістр відомостей ==

=== 8.4.1. Незалежний періодичний (приклад: КурсиВалют) ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_i_0007 (
period timestamp(0) NOT NULL, -- Період (усічений до дня: WithinDay)
d1_r uuid NOT NULL, -- Вимірювання «Валюта»
r1 numeric(15,4) NOT NULL, -- Ресурс «Курс»
r2 numeric(10,0) NOT NULL DEFAULT 1, -- Ресурс «Кратність»
CONSTRAINT pk_rg_i_0007 PRIMARY KEY (period, d1_r)
);
-- Індекс для зрізу останніх у розрізі вимірювання
CREATE INDEX ix_rg_i_0007_d1 ON rg_i_0007 (d1_r, period DESC) INCLUDE (r1, r2);
ALTER TABLE rg_i_0007 ADD CONSTRAINT fk_rg_i_0007_d1
FOREIGN KEY (d1_r) REFERENCES cat_0003(ref); -- Довідник.Валюти
</syntaxhighlight>

=== 8.4.2. Підпорядкований реєстратору ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_i_0008 (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
period timestamp(0) NOT NULL,
active boolean NOT NULL DEFAULT true,
d1_r uuid NOT NULL,
r1 numeric(15,2) NOT NULL,
CONSTRAINT pk_rg_i_0008 PRIMARY KEY (rec_t, rec_r, line_no)
);
CREATE INDEX ix_rg_i_0008_period ON rg_i_0008 (period, rec_t, rec_r, line_no);
CREATE INDEX ix_rg_i_0008_d1 ON rg_i_0008 (d1_r, period) WHERE active;
</syntaxhighlight>

=== 8.4.3. Незалежний неперіодичний ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_i_0009 (
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
r1 varchar(200),
CONSTRAINT pk_rg_i_0009 PRIMARY KEY (d1_r, d2_r)
);
</syntaxhighlight>

== 8.5. Регістр накопичення ==

=== 8.5.1. Таблиця рухів ===
<syntaxhighlight lang="sql">
-- ТовариНаСкладах: dims = Номенклатура(d1), Склад(d2), Партія(d3, складений), Характеристика(d4)
-- res = Кількість(r1), Сума(r2); attr = Коментар(a1)
CREATE TABLE rg_a_0012 (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
period timestamp(0) NOT NULL,
active boolean NOT NULL DEFAULT true,
mvt smallint NOT NULL CHECK (mvt IN (0,1)), -- 0=Прихід, 1=Витрата
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
d3_t smallint NOT NULL, -- складене вимірювання «Партія»
d3_r uuid NOT NULL,
d4_r uuid NOT NULL,
r1 numeric(15,3) NOT NULL DEFAULT 0,
r2 numeric(15,2) NOT NULL DEFAULT 0,
a1 varchar(200),
CONSTRAINT pk_rg_a_0012 PRIMARY KEY (rec_t, rec_r, line_no)
) PARTITION BY RANGE (period);

CREATE TABLE rg_a_0012_p2026m07 PARTITION OF rg_a_0012
FOR VALUES FROM ('2026-07-01') TO ('2026-08-01');
-- ... інші секції створюються регламентним завданням

CREATE INDEX ix_rg_a_0012_period ON rg_a_0012 (period, rec_t, rec_r, line_no);
CREATE INDEX ix_rg_a_0012_d1 ON rg_a_0012 (d1_r, period, d2_r) WHERE active; -- Номенклатура (Індексувати з дод. вимірюваннями)
CREATE INDEX ix_rg_a_0012_d2 ON rg_a_0012 (d2_r, period, d1_r) WHERE active; -- Склад
</syntaxhighlight>

=== 8.5.2. Таблиця підсумків залишків ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_a_0012_tb (
period timestamp(0) NOT NULL, -- початок місяця; MAXPERIOD = підсумок за всі періоди
splitter smallint NOT NULL DEFAULT 0,
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
d3_t smallint NOT NULL,
d3_r uuid NOT NULL,
d4_r uuid NOT NULL,
r1 numeric(20,3) NOT NULL, -- Кількість, знаковий залишок
r2 numeric(20,2) NOT NULL, -- Сума
CONSTRAINT pk_rg_a_0012_tb PRIMARY KEY (period, d1_r, d2_r, d3_t, d3_r, d4_r, splitter)
);
-- покривний індекс для типового відбору «залишки по складу»
CREATE INDEX ix_rg_a_0012_tb_d2 ON rg_a_0012_tb (d2_r, period, d1_r) INCLUDE (r1, r2);
</syntaxhighlight>

'''Семантика:''' рядок з <code>period = P</code> містить залишок '''на початок''' періоду P. Рядок з <code>period = MAXPERIOD</code> — поточний залишок за всі періоди (використовується для запитів «залишки на зараз», найчастіший кейс).

=== 8.5.3. Таблиця підсумків оборотів ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_a_0012_tt (
period timestamp(0) NOT NULL, -- початок періоду агрегації (день/місяць)
splitter smallint NOT NULL DEFAULT 0,
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
d3_t smallint NOT NULL,
d3_r uuid NOT NULL,
d4_r uuid NOT NULL,
r1_in numeric(20,3) NOT NULL DEFAULT 0, -- Кількість Прихід
r1_out numeric(20,3) NOT NULL DEFAULT 0, -- Кількість Витрата
r2_in numeric(20,2) NOT NULL DEFAULT 0,
r2_out numeric(20,2) NOT NULL DEFAULT 0,
CONSTRAINT pk_rg_a_0012_tt PRIMARY KEY (period, d1_r, d2_r, d3_t, d3_r, d4_r, splitter)
);
</syntaxhighlight>

=== 8.5.4. Службова таблиця налаштувань ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_a_0012_opt (
id smallint PRIMARY KEY DEFAULT 1 CHECK (id = 1),
totals_actual_to timestamp(0) NOT NULL, -- ТА: підсумки розраховані до
use_bal_totals boolean NOT NULL DEFAULT true,
use_tno_totals boolean NOT NULL DEFAULT true,
min_period timestamp(0), -- період першого руху
last_recalc_at timestamp(0),
split_merge_at timestamp(0)
);
</syntaxhighlight>

=== 8.5.5. Агрегат (для РН виду «Обороти») ===
<syntaxhighlight lang="sql">
-- Агрегат «Продажі за місяцями по номенклатурі та складу» (без Партії, без Характеристики)
CREATE TABLE rg_a_0031_ag1 (
period timestamp(0) NOT NULL,
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
r1 numeric(20,3) NOT NULL,
r2 numeric(20,2) NOT NULL,
CONSTRAINT pk_rg_a_0031_ag1 PRIMARY KEY (period, d1_r, d2_r)
);
</syntaxhighlight>

== 8.6. Регістр бухгалтерії ==

=== 8.6.1. План рахунків (супутні таблиці) ===
<syntaxhighlight lang="sql">
CREATE TABLE coa_0005 ( -- ПланРахунків.Госпрозрахунковий
ref uuid PRIMARY KEY,
parent_ref uuid REFERENCES coa_0005(ref),
code varchar(20) NOT NULL,
order_code varchar(40) NOT NULL, -- впорядкований код для ієрархічних запитів
name varchar(150) NOT NULL,
acc_type smallint NOT NULL, -- 0=Активний,1=Пасивний,2=Активно-пасивний
off_balance boolean NOT NULL DEFAULT false,
ed_count smallint NOT NULL DEFAULT 0, -- фактична кількість субконто
fl_qty boolean NOT NULL DEFAULT false, -- ознака обліку «Кількісний»
fl_cur boolean NOT NULL DEFAULT false, -- ознака обліку «Валютний»
marked_del boolean NOT NULL DEFAULT false
);
CREATE UNIQUE INDEX ux_coa_0005_code ON coa_0005 (code);

CREATE TABLE coa_0005_ed ( -- ТЧ «ВидиСубконто»
ref uuid NOT NULL REFERENCES coa_0005(ref) ON DELETE CASCADE,
line_no int NOT NULL,
ed_type_r uuid NOT NULL, -- ПланВидівХарактеристик.ВидиСубконто
only_tno boolean NOT NULL DEFAULT false, -- «Тільки обороти»
sum_flag boolean NOT NULL DEFAULT true, -- «Підсумкова сума»
fl_qty boolean NOT NULL DEFAULT false, -- ознака обліку субконто «Кількісний»
PRIMARY KEY (ref, line_no)
);
</syntaxhighlight>

=== 8.6.2. Таблиця проводок (з кореспонденцією) ===
<syntaxhighlight lang="sql">
-- Госпрозрахунковий: dims = Організація(d1, балансове), Підрозділ(d2, небалансове)
-- res = Сума(r1, балансовий), Кількість(r2, небалансовий), ВалютнаСума(r3, небалансовий)
-- attr = Зміст(a1), Валюта(a2); max_extdim_count = 3
CREATE TABLE rg_b_0020 (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
period timestamp(0) NOT NULL,
active boolean NOT NULL DEFAULT true,

acc_dt_r uuid NOT NULL REFERENCES coa_0005(ref),
acc_kt_r uuid NOT NULL REFERENCES coa_0005(ref),

-- балансове вимірювання: одне значення на проводку
d1_r uuid NOT NULL,
-- небалансове вимірювання: окремо для Дт і Кт
d2_dt_r uuid NOT NULL,
d2_kt_r uuid NOT NULL,

-- субконто Дт (3 слоти, складений тип: ПВХ-значення)
ed_dt1_t smallint, ed_dt1_r uuid,
ed_dt2_t smallint, ed_dt2_r uuid,
ed_dt3_t smallint, ed_dt3_r uuid,
ed_dt_h bigint NOT NULL DEFAULT 0, -- хеш набору субконто Дт (для JOIN з підсумками)
-- субконто Кт
ed_kt1_t smallint, ed_kt1_r uuid,
ed_kt2_t smallint, ed_kt2_r uuid,
ed_kt3_t smallint, ed_kt3_r uuid,
ed_kt_h bigint NOT NULL DEFAULT 0,

-- балансовий ресурс: одне значення
r1 numeric(20,2) NOT NULL DEFAULT 0, -- Сума
-- небалансові ресурси: пара Дт/Кт
r2_dt numeric(20,3) NOT NULL DEFAULT 0, -- Кількість Дт
r2_kt numeric(20,3) NOT NULL DEFAULT 0, -- Кількість Кт
r3_dt numeric(20,2) NOT NULL DEFAULT 0, -- ВалютнаСума Дт
r3_kt numeric(20,2) NOT NULL DEFAULT 0,

a1 varchar(255),
a2_r uuid,
CONSTRAINT pk_rg_b_0020 PRIMARY KEY (rec_t, rec_r, line_no)
) PARTITION BY RANGE (period);

CREATE INDEX ix_rg_b_0020_period ON rg_b_0020 (period, rec_t, rec_r, line_no);
CREATE INDEX ix_rg_b_0020_acc_dt ON rg_b_0020 (acc_dt_r, period) WHERE active;
CREATE INDEX ix_rg_b_0020_acc_kt ON rg_b_0020 (acc_kt_r, period) WHERE active;
CREATE INDEX ix_rg_b_0020_ed_dt ON rg_b_0020 (ed_dt1_t, ed_dt1_r, period) WHERE active;
</syntaxhighlight>

{{Note|'''Проєктне рішення №2.''' Субконто зберігаються '''слотами в основній таблиці''', а не в дочірній таблиці «ключ-значення». Обґрунтування: (а) віртуальні таблиці <code>Залишки</code>/<code>Обороти</code> з відбором за субконто перетворюються на предикат по колонці замість <code>N</code> самоз'єднань; (б) кількість субконто жорстко обмежена (≤5) — «широка» таблиця прийнятна; (в) 1С використовує гібрид (<code>_AccRgED</code>), що дає складніші плани. '''Ціна:''' зміна <code>МаксКількістьСубконто</code> = реструктуризація таблиці. Альтернатива (дочірня таблиця <code>rg_b_0020_ed</code>) описана в Додатку Б і зберігається як план «Б» за результатами навантажувального тесту НТ-04.}}

=== 8.6.3. Таблиця проводок (без кореспонденції) ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_b_0021 (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
period timestamp(0) NOT NULL,
active boolean NOT NULL DEFAULT true,
acc_mvt smallint NOT NULL CHECK (acc_mvt IN (0,1)), -- 0=Дебет, 1=Кредит
acc_r uuid NOT NULL REFERENCES coa_0006(ref),
d1_r uuid NOT NULL,
ed1_t smallint, ed1_r uuid,
ed2_t smallint, ed2_r uuid,
ed3_t smallint, ed3_r uuid,
ed_h bigint NOT NULL DEFAULT 0,
r1 numeric(20,2) NOT NULL DEFAULT 0,
CONSTRAINT pk_rg_b_0021 PRIMARY KEY (rec_t, rec_r, line_no)
);
</syntaxhighlight>

=== 8.6.4. Підсумки РБ ===
Підсумки будуються на кількох «рівнях субконто» — щоб запит без відбору за субконто не сканував найдетальнішу таблицю.

<syntaxhighlight lang="sql">
-- Рівень 0: залишки по рахунку + балансові вимірювання (без субконто)
CREATE TABLE rg_b_0020_tb0 (
period timestamp(0) NOT NULL,
splitter smallint NOT NULL DEFAULT 0,
acc_r uuid NOT NULL,
d1_r uuid NOT NULL, -- Організація (балансове)
r1 numeric(24,2) NOT NULL, -- Сума: >0 = дебетовий, <0 = кредитовий залишок
r2 numeric(24,3) NOT NULL, -- Кількість
r3 numeric(24,2) NOT NULL,
CONSTRAINT pk_rg_b_0020_tb0 PRIMARY KEY (period, acc_r, d1_r, splitter)
);

-- Рівень 1..3: залишки з розшифровкою по субконто (тільки для рахунків з ed_count >= k)
CREATE TABLE rg_b_0020_tb1 (
period timestamp(0) NOT NULL, splitter smallint NOT NULL DEFAULT 0,
acc_r uuid NOT NULL, d1_r uuid NOT NULL,
ed1_t smallint NOT NULL, ed1_r uuid NOT NULL,
r1 numeric(24,2) NOT NULL, r2 numeric(24,3) NOT NULL, r3 numeric(24,2) NOT NULL,
CONSTRAINT pk_rg_b_0020_tb1 PRIMARY KEY (period, acc_r, d1_r, ed1_t, ed1_r, splitter)
);
CREATE TABLE rg_b_0020_tb2 (
period timestamp(0) NOT NULL, splitter smallint NOT NULL DEFAULT 0,
acc_r uuid NOT NULL, d1_r uuid NOT NULL,
ed1_t smallint NOT NULL, ed1_r uuid NOT NULL,
ed2_t smallint NOT NULL, ed2_r uuid NOT NULL,
r1 numeric(24,2) NOT NULL, r2 numeric(24,3) NOT NULL, r3 numeric(24,2) NOT NULL,
CONSTRAINT pk_rg_b_0020_tb2 PRIMARY KEY (period, acc_r, d1_r, ed1_t, ed1_r, ed2_t, ed2_r, splitter)
);
-- rg_b_0020_tb3 — аналогічно, 3 субконто

-- Обороти (аналогічні рівні): tt0..tt3
CREATE TABLE rg_b_0020_tt0 (
period timestamp(0) NOT NULL,
splitter smallint NOT NULL DEFAULT 0,
acc_r uuid NOT NULL,
d1_r uuid NOT NULL,
r1_dt numeric(24,2) NOT NULL, r1_kt numeric(24,2) NOT NULL,
r2_dt numeric(24,3) NOT NULL, r2_kt numeric(24,3) NOT NULL,
r3_dt numeric(24,2) NOT NULL, r3_kt numeric(24,2) NOT NULL,
CONSTRAINT pk_rg_b_0020_tt0 PRIMARY KEY (period, acc_r, d1_r, splitter)
);

-- Обороти між рахунками (кореспонденції)
CREATE TABLE rg_b_0020_tc (
period timestamp(0) NOT NULL,
splitter smallint NOT NULL DEFAULT 0,
acc_dt_r uuid NOT NULL,
acc_kt_r uuid NOT NULL,
d1_r uuid NOT NULL,
r1 numeric(24,2) NOT NULL,
CONSTRAINT pk_rg_b_0020_tc PRIMARY KEY (period, acc_dt_r, acc_kt_r, d1_r, splitter)
);
</syntaxhighlight>

'''Правило запису рівнів:''' для проводки з рахунком, що має <code>ed_count = k</code>, оновлюються таблиці <code>tb0 … tbK</code> (k+1 таблиць). Рахунки без субконто оновлюють лише <code>tb0</code>. Субконто з ознакою «Тільки обороти» не потрапляють у <code>tb*</code>, лише в <code>tt*</code>.

== 8.7. Регістр розрахунку ==

<syntaxhighlight lang="sql">
-- Нарахування: dims = Співробітник(d1, базове), Підрозділ(d2)
-- res = Результат(r1), ВідпрацьованоДнів(r2), НормаДнів(r3)
-- attr = Графік(a1)
CREATE TABLE rg_c_0040 (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
period timestamp(0) NOT NULL, -- період реєстрації (початок місяця)
active boolean NOT NULL DEFAULT true,
reversal boolean NOT NULL DEFAULT false, -- Сторно
calc_type_r uuid NOT NULL, -- ВидРозрахунку → pct_0011(ref)
act_begin timestamp(0) NOT NULL, -- ПеріодДіїПочаток
act_end timestamp(0) NOT NULL, -- ПеріодДіїКінець
base_begin timestamp(0), -- БазовийПеріодПочаток
base_end timestamp(0), -- БазовийПеріодКінець
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
r1 numeric(15,2) NOT NULL DEFAULT 0,
r2 numeric(5,0) NOT NULL DEFAULT 0,
r3 numeric(5,0) NOT NULL DEFAULT 0,
a1_r uuid,
CONSTRAINT pk_rg_c_0040 PRIMARY KEY (rec_t, rec_r, line_no),
CONSTRAINT chk_rg_c_0040_act CHECK (act_end >= act_begin)
);
CREATE INDEX ix_rg_c_0040_period ON rg_c_0040 (period, rec_t, rec_r, line_no);
CREATE INDEX ix_rg_c_0040_d1 ON rg_c_0040 (d1_r, period, calc_type_r) WHERE active;
CREATE INDEX ix_rg_c_0040_act ON rg_c_0040 (d1_r, act_begin, act_end) WHERE active;
CREATE INDEX ix_rg_c_0040_base ON rg_c_0040 (d1_r, calc_type_r, base_begin, base_end) WHERE active;

-- Фактичні періоди дії (після витіснення). Один запис → 0..N інтервалів.
CREATE TABLE rg_c_0040_ap (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
interval_no smallint NOT NULL,
calc_type_r uuid NOT NULL,
d1_r uuid NOT NULL, -- денормалізація базового вимірювання для швидкого JOIN
fact_begin timestamp(0) NOT NULL,
fact_end timestamp(0) NOT NULL,
CONSTRAINT pk_rg_c_0040_ap PRIMARY KEY (rec_t, rec_r, line_no, interval_no),
CONSTRAINT fk_rg_c_0040_ap FOREIGN KEY (rec_t, rec_r, line_no)
REFERENCES rg_c_0040 (rec_t, rec_r, line_no) ON DELETE CASCADE
);
CREATE INDEX ix_rg_c_0040_ap_d1 ON rg_c_0040_ap (d1_r, fact_begin, fact_end);

-- Перерахунок «ПерерахунокЗаБазою»
CREATE TABLE rg_c_0040_rc1 (
rec_t smallint NOT NULL, -- реєстратор запису, який треба перерахувати
rec_r uuid NOT NULL,
calc_type_r uuid NOT NULL, -- вид розрахунку, що потребує перерахунку
d1_r uuid NOT NULL, -- вимірювання перерахунку «Співробітник»
src_rec_t smallint NOT NULL, -- реєстратор, що спричинив перерахунок
src_rec_r uuid NOT NULL,
created_at timestamp(0) NOT NULL DEFAULT now(),
CONSTRAINT pk_rg_c_0040_rc1 PRIMARY KEY (rec_t, rec_r, calc_type_r, d1_r)
);
CREATE INDEX ix_rg_c_0040_rc1_src ON rg_c_0040_rc1 (src_rec_t, src_rec_r);
</syntaxhighlight>

== 8.8. Зведення: які таблиці породжує кожен тип регістру ==

<pre>
РВ (незалежний) → rg_i_<id>
РВ (підпорядкований) → rg_i_<id>

РН (Залишки) → rg_a_<id>
rg_a_<id>_tb (якщо ДозволитиПідсумкиЗалишків)
rg_a_<id>_tt (якщо ДозволитиПідсумкиОборотів)
rg_a_<id>_opt

РН (Обороти) → rg_a_<id>
rg_a_<id>_tt
rg_a_<id>_ag1..agN (агрегати)
rg_a_<id>_opt

РБ → rg_b_<id>
rg_b_<id>_tb0 .. _tbK (K = МаксКількістьСубконто)
rg_b_<id>_tt0 .. _ttK
rg_b_<id>_tc
rg_b_<id>_opt

РР → rg_c_<id>
rg_c_<id>_ap
rg_c_<id>_rc1 .. _rcM (перерахунки)
</pre>

Оцінка: для РБ з <code>МаксКількістьСубконто = 3</code> генерується '''10 фізичних таблиць''' на один регістр.

= 9. ER-моделі =

== 9.1. ER-модель метаданих (репозиторій) ==

<uml>
@startuml
hide circle
skinparam linetype ortho
skinparam shadowing false

entity "md_type" as T {
* id : smallint <<PK>>
--
* kind : varchar(20)
* name : varchar(80)
table_name : varchar(63)
}

entity "md_register" as R {
* id : smallint <<PK,FK→md_type>>
--
* name : varchar(80) <<U>>
* kind : varchar(12)
* write_mode : varchar(24)
* periodicity : varchar(24)
accumulation_kind : varchar(10)
enable_bal_totals : boolean
enable_tno_totals : boolean
tno_totals_period : varchar(6)
split_totals : boolean
chart_of_accounts_id : smallint <<FK>>
correspondence : boolean
max_extdim_count : smallint
calc_types_plan_id : smallint <<FK>>
use_action_period : boolean
base_period_mode : varchar(24)
schedule_register_id : smallint <<FK>>
* physical_table : varchar(63)
* struct_version : int
}

entity "md_register_field" as F {
* register_id : smallint <<PK,FK>>
* id : smallint <<PK>>
--
* name : varchar(80) <<U>>
* role : Dimension|Resource|Attribute
* data_type_expr : text
is_composite : boolean
index_mode : varchar(28)
is_master : boolean
is_balance : boolean
is_base_dimension : boolean
accounting_flag : varchar(80)
* column_prefix : varchar(8)
}

entity "md_register_recorder" as RR {
* register_id : smallint <<PK,FK>>
* doc_type_id : smallint <<PK,FK>>
}

entity "md_register_aggregate" as AG {
* register_id : smallint <<PK,FK>>
* id : smallint <<PK>>
--
* name : varchar(80)
* periodicity : Day|Month|Quarter|Year
is_realtime : boolean
actual_upto : timestamp
}

entity "md_register_aggregate_dim" as AGD {
* register_id : smallint <<PK,FK>>
* aggregate_id : smallint <<PK,FK>>
* field_id : smallint <<PK,FK>>
}

entity "md_register_recalc" as RC {
* register_id : smallint <<PK,FK>>
* id : smallint <<PK>>
--
* name : varchar(80)
* physical_table : varchar(63)
}

entity "md_register_recalc_dim" as RCD {
* register_id : smallint <<PK,FK>>
* recalc_id : smallint <<PK,FK>>
* name : varchar(80) <<PK>>
--
* reg_field_id : smallint <<FK>>
}

T ||--o| R : "є регістром"
T ||--o{ RR : "тип документа"
R ||--|{ F : "має поля"
R ||--o{ RR : "реєстратори"
R ||--o{ AG : "агрегати"
AG ||--|{ AGD : "склад вимірювань"
F ||--o{ AGD : "вимірювання"
R ||--o{ RC : "перерахунки"
RC ||--|{ RCD : "вимірювання перерахунку"
F ||--o{ RCD : "відповідає"
R }o--o| T : "план рахунків"
R }o--o| T : "план видів розрахунку"
R }o--o| R : "графік часу"
@enduml
</uml>

== 9.2. ER-модель: регістр накопичення (вид «Залишки») ==

<uml>
@startuml
hide circle
skinparam linetype ortho
skinparam shadowing false

entity "doc_0002\n«ПрихіднаНакладна»" as D1 {
* ref : uuid <<PK>>
--
number : varchar
date : timestamp
posted : boolean
}
entity "doc_0003\n«ВидатковаНакладна»" as D2 {
* ref : uuid <<PK>>
--
number : varchar
date : timestamp
posted : boolean
}
entity "cat_0001\n«Номенклатура»" as C1 {
* ref : uuid <<PK>>
--
code, name
}
entity "cat_0004\n«Склади»" as C2 {
* ref : uuid <<PK>>
--
code, name
}

entity "rg_a_0012\n«ТовариНаСкладах» (рухи)" as M {
* rec_t : smallint <<PK>>
* rec_r : uuid <<PK>>
* line_no : int <<PK>>
--
* period : timestamp(0)
* active : boolean
* mvt : smallint «0=Прихід,1=Витрата»
* d1_r : uuid «Номенклатура» <<FK>>
* d2_r : uuid «Склад» <<FK>>
* d3_t : smallint «Партія:тип»
* d3_r : uuid «Партія:посилання»
* d4_r : uuid «Характеристика» <<FK>>
* r1 : numeric(15,3) «Кількість»
* r2 : numeric(15,2) «Сума»
a1 : varchar(200) «Коментар»
}

entity "rg_a_0012_tb\nпідсумки залишків" as TB {
* period : timestamp(0) <<PK>>
* d1_r : uuid <<PK>>
* d2_r : uuid <<PK>>
* d3_t : smallint <<PK>>
* d3_r : uuid <<PK>>
* d4_r : uuid <<PK>>
* splitter : smallint <<PK>>
--
* r1 : numeric(20,3) «Кількість (±)»
* r2 : numeric(20,2) «Сума (±)»
}

entity "rg_a_0012_tt\nпідсумки оборотів" as TT {
* period : timestamp(0) <<PK>>
* d1_r : uuid <<PK>>
* d2_r : uuid <<PK>>
* d3_t : smallint <<PK>>
* d3_r : uuid <<PK>>
* d4_r : uuid <<PK>>
* splitter : smallint <<PK>>
--
r1_in, r1_out : numeric(20,3)
r2_in, r2_out : numeric(20,2)
}

entity "rg_a_0012_opt" as OPT {
* id : smallint = 1 <<PK>>
--
* totals_actual_to : timestamp(0)
use_bal_totals : boolean
use_tno_totals : boolean
min_period : timestamp(0)
}

D1 ||..o{ M : "реєстратор\n(поліморфний, без FK)"
D2 ||..o{ M : "реєстратор\n(поліморфний, без FK)"
C1 ||--o{ M : "d1_r"
C2 ||--o{ M : "d2_r"
M }o..|| TB : "агрегується в\n(підтримується платформою)"
M }o..|| TT : "агрегується в"
OPT ||..|| TB : "ТА підсумків"

note bottom of M
PK = (rec_t, rec_r, line_no)
→ усі рухи одного документа
фізично суміжні
Партиціонування: RANGE(period)
end note

note bottom of TB
period = MAXPERIOD ('5999-11-01')
→ рядок «залишок за всі періоди»
end note
@enduml
</uml>

== 9.3. ER-модель: регістр бухгалтерії ==

<uml>
@startuml
hide circle
skinparam linetype ortho
skinparam shadowing false

entity "coa_0005\n«План рахунків»" as A {
* ref : uuid <<PK>>
--
parent_ref : uuid <<FK>>
* code : varchar(20) <<U>>
order_code : varchar(40)
* name : varchar(150)
* acc_type : smallint «Акт/Пас/АП»
off_balance : boolean
ed_count : smallint
fl_qty, fl_cur : boolean
}
entity "coa_0005_ed\n«Види субконто рахунку»" as AE {
* ref : uuid <<PK,FK>>
* line_no : int <<PK>>
--
* ed_type_r : uuid <<FK>>
only_tno : boolean
sum_flag : boolean
}
entity "cvt_0009\n«ПВХ.ВидиСубконто»" as VT {
* ref : uuid <<PK>>
--
code, name
value_type : text
}

entity "rg_b_0020\n«Госпрозрахунковий» (проводки)" as J {
* rec_t : smallint <<PK>>
* rec_r : uuid <<PK>>
* line_no : int <<PK>>
--
* period : timestamp(0)
* active : boolean
* acc_dt_r : uuid <<FK>>
* acc_kt_r : uuid <<FK>>
* d1_r : uuid «Організація (балансове)»
* d2_dt_r : uuid «Підрозділ Дт»
* d2_kt_r : uuid «Підрозділ Кт»
ed_dt1_t/_r .. ed_dt3_t/_r : «субконто Дт»
ed_dt_h : bigint
ed_kt1_t/_r .. ed_kt3_t/_r : «субконто Кт»
ed_kt_h : bigint
* r1 : numeric(20,2) «Сума (балансовий)»
r2_dt, r2_kt : numeric(20,3) «Кількість»
r3_dt, r3_kt : numeric(20,2) «ВалютнаСума»
a1 : varchar(255) «Зміст»
a2_r : uuid «Валюта»
}

entity "rg_b_0020_tb0\nзалишки, рівень 0" as B0 {
* period <<PK>>
* acc_r <<PK>>
* d1_r <<PK>>
* splitter <<PK>>
--
r1, r2, r3 : numeric «знакові»
}
entity "rg_b_0020_tb1..tb3\nзалишки, рівні 1..3" as B1 {
* period <<PK>>
* acc_r <<PK>>
* d1_r <<PK>>
* ed1_t, ed1_r <<PK>>
* (ed2_t, ed2_r) <<PK>>
* (ed3_t, ed3_r) <<PK>>
* splitter <<PK>>
--
r1, r2, r3 : numeric
}
entity "rg_b_0020_tt0..tt3\nобороти за рівнями" as T0 {
* period <<PK>>
* acc_r <<PK>>
* d1_r <<PK>>
* (ed…) <<PK>>
--
r1_dt, r1_kt
r2_dt, r2_kt
r3_dt, r3_kt
}
entity "rg_b_0020_tc\nобороти Дт↔Кт" as TC {
* period <<PK>>
* acc_dt_r <<PK>>
* acc_kt_r <<PK>>
* d1_r <<PK>>
--
r1 : numeric(24,2)
}

A ||--o{ AE : "види субконто"
VT ||--o{ AE : "тип субконто"
A ||--o{ J : "acc_dt_r"
A ||--o{ J : "acc_kt_r"
A ||--o{ B0 : "acc_r"
A ||--o{ B1 : "acc_r"
J }o..|| B0 : "агрегується (Дт: +, Кт: −)"
J }o..|| B1 : "агрегується, якщо ed_count ≥ k"
J }o..|| T0 : "агрегується"
J }o..|| TC : "агрегується"

note right of J
Балансовий ресурс r1 — одне значення,
контроль Σ(Дт) = Σ(Кт) у межах реєстратора.
Небалансові ресурси — пара Дт/Кт.
Субконто — слоти (див. Рішення №2).
end note
@enduml
</uml>

== 9.4. ER-модель: регістр розрахунку ==

<uml>
@startuml
hide circle
skinparam linetype ortho
skinparam shadowing false

entity "pct_0011\n«ПВР.ОсновніНарахування»" as P {
* ref : uuid <<PK>>
--
code, name
use_action_period : boolean
base_dependency : varchar(24)
}
entity "pct_0011_base\n«Базові види розрахунку»" as PB {
* ref <<PK,FK>>
* line_no <<PK>>
--
* base_type_r : uuid <<FK>>
}
entity "pct_0011_displace\n«Витісняючі види розрахунку»" as PD {
* ref <<PK,FK>>
* line_no <<PK>>
--
* displacing_type_r : uuid <<FK>>
}
entity "pct_0011_lead\n«Ведучі види розрахунку»" as PL {
* ref <<PK,FK>>
* line_no <<PK>>
--
* leading_type_r : uuid <<FK>>
}

entity "rg_c_0040\n«Нарахування» (рухи)" as CR {
* rec_t : smallint <<PK>>
* rec_r : uuid <<PK>>
* line_no : int <<PK>>
--
* period : timestamp(0) «період реєстрації»
* active : boolean
* reversal : boolean «Сторно»
* calc_type_r : uuid <<FK>>
* act_begin : timestamp(0)
* act_end : timestamp(0)
base_begin : timestamp(0)
base_end : timestamp(0)
* d1_r : uuid «Співробітник (базове)»
* d2_r : uuid «Підрозділ»
r1 : numeric «Результат»
r2 : numeric «ВідпрацьованоДнів»
r3 : numeric «НормаДнів»
}

entity "rg_c_0040_ap\nфактичні періоди дії" as AP {
* rec_t <<PK,FK>>
* rec_r <<PK,FK>>
* line_no <<PK,FK>>
* interval_no : smallint <<PK>>
--
* calc_type_r : uuid
* d1_r : uuid
* fact_begin : timestamp(0)
* fact_end : timestamp(0)
}

entity "rg_c_0040_rc1\n«ПерерахунокЗаБазою»" as RC {
* rec_t <<PK>>
* rec_r <<PK>>
* calc_type_r <<PK>>
* d1_r <<PK>>
--
src_rec_t, src_rec_r
created_at
}

entity "rg_i_0015\n«ГрафікРоботи» (РВ)" as SCH {
* d1_r : uuid <<PK>> «ВидГрафіка»
* d2_d : timestamp(0) <<PK>> «ДатаГрафіка»
--
r1 : numeric «Значення»
}

entity "doc_0007\n«НарахуванняЗарплати»" as DOC {
* ref : uuid <<PK>>
--
number, date, posted
}

P ||--o{ CR : "calc_type_r"
P ||--o{ PB : "базові"
P ||--o{ PD : "витісняючі"
P ||--o{ PL : "ведучі"
DOC ||..o{ CR : "реєстратор"
CR ||--|{ AP : "1 запис → 0..N\nфактичних інтервалів"
CR }o..o{ RC : "потребує перерахунку"
SCH }o..o{ CR : "ДаніГрафіка\n(віртуальна таблиця)"
CR }o..o{ CR : "БазаРозрахунку\n(self-join через PB\nта базові вимірювання)"
@enduml
</uml>

== 9.5. Зведена концептуальна ER (усі типи) ==

<graphviz>
digraph ER {
rankdir=LR; bgcolor="transparent";
node [shape=record, fontname="Helvetica", fontsize=9, style=filled];
edge [fontname="Helvetica", fontsize=8];

MD [label="{md_register|id (PK)\lname\lkind\lperiodicity\lwrite_mode\l...}", fillcolor="#dbe9ff"];
MDF [label="{md_register_field|register_id (PK,FK)\lid (PK)\lname\lrole\ldata_type\l...}", fillcolor="#dbe9ff"];
MDR [label="{md_register_recorder|register_id (PK,FK)\ldoc_type_id (PK,FK)\l}", fillcolor="#dbe9ff"];

DOC [label="{doc_XXXX (Документ)|ref (PK)\lnumber\ldate\lposted\l}", fillcolor="#fff8e1"];
CAT [label="{cat_XXXX (Довідник)|ref (PK)\lcode\lname\l}", fillcolor="#fff8e1"];
COA [label="{coa_XXXX (План рахунків)|ref (PK)\lcode\lacc_type\led_count\l}", fillcolor="#fff8e1"];
PCT [label="{pct_XXXX (ПВР)|ref (PK)\lcode\l}", fillcolor="#fff8e1"];

RI [label="{rg_i_XXXX (РВ)|period (PK*)\ld1..dN (PK*)\l| rec_t,rec_r,line_no (PK**)\lr1..rM\l}", fillcolor="#e8f5e9"];
RA [label="{rg_a_XXXX (РН)|rec_t, rec_r, line_no (PK)\lperiod\lactive\lmvt\ld1..dN\lr1..rM\l}", fillcolor="#fff3e0"];
RAT [label="{rg_a_XXXX_tb / _tt|period (PK)\ld1..dN (PK)\lsplitter (PK)\lr1..rM\l}", fillcolor="#ffe0b2"];
RB [label="{rg_b_XXXX (РБ)|rec_t, rec_r, line_no (PK)\lperiod, active\lacc_dt_r, acc_kt_r\led_dt1..3, ed_kt1..3\ld1..dN\lr1, r2_dt/r2_kt\l}", fillcolor="#fce4ec"];
RBT [label="{rg_b_XXXX_tb0..tbK\lrg_b_XXXX_tt0..ttK\lrg_b_XXXX_tc|period, acc_r, d1..dN\led1..edK (PK)\lr1..rM\l}", fillcolor="#f8bbd0"];
RC [label="{rg_c_XXXX (РР)|rec_t, rec_r, line_no (PK)\lperiod, active, reversal\lcalc_type_r\lact_begin, act_end\lbase_begin, base_end\ld1..dN, r1..rM\l}", fillcolor="#ede7f6"];
RCA [label="{rg_c_XXXX_ap|rec_t,rec_r,line_no (PK,FK)\linterval_no (PK)\lfact_begin, fact_end\l}", fillcolor="#d1c4e9"];
RCR [label="{rg_c_XXXX_rc1..rcM|rec_t, rec_r (PK)\lcalc_type_r (PK)\ld1..dN (PK)\l}", fillcolor="#d1c4e9"];

MD -> MDF [label="1:N"];
MD -> MDR [label="1:N"];
MDR -> DOC [label="тип"];
MD -> COA [label="0:1 план рахунків", style=dashed];
MD -> PCT [label="0:1 ПВР", style=dashed];

MD -> RI [label="генерує DDL", style=dotted, color=blue];
MD -> RA [label="генерує DDL", style=dotted, color=blue];
MD -> RB [label="генерує DDL", style=dotted, color=blue];
MD -> RC [label="генерує DDL", style=dotted, color=blue];

DOC -> RI [label="реєстратор (поліморф.)", style=dashed];
DOC -> RA [label="реєстратор (поліморф.)", style=dashed];
DOC -> RB [label="реєстратор (поліморф.)", style=dashed];
DOC -> RC [label="реєстратор (поліморф.)", style=dashed];

CAT -> RI [label="FK вимір."];
CAT -> RA [label="FK вимір."];
COA -> RB [label="FK рахунок"];
PCT -> RC [label="FK вид розрах."];

RA -> RAT [label="агрегація (платформа)", color=darkgreen];
RB -> RBT [label="агрегація (платформа)", color=darkgreen];
RC -> RCA [label="витіснення → 1:N", color=purple];
RC -> RCR [label="реєстрація перерахунків", color=purple, style=dashed];

{ rank=same; MD; MDF; MDR; }
{ rank=same; RI; RA; RB; RC; }
}
</graphviz>

'''Легенда:'''
* <code>(PK*)</code> — ключ для незалежного РВ; <code>(PK**)</code> — для підпорядкованого.
* Пунктир «реєстратор» — логічний зв'язок без FK (поліморфне посилання, підтримується платформою).
* Пунктир «генерує DDL» — метадані → фізична схема (не зв'язок даних).

= 10. Ключові алгоритми =

== 10.1. Запис набору записів (режим «Заміщати») ==

<syntaxhighlight lang="python">
def write_record_set(reg: Register, rs: RecordSet, replace: bool = True) -> None:
"""Розділ 7.1, ФТ-01…ФТ-04. Уся операція — в одній транзакції."""
check_rights(reg, Right.INSERT | Right.UPDATE) # ФТ-37
validate(reg, rs) # реєстратор ∈ md_register_recorder;
# deny_empty; для РБ — Σ Дт = Σ Кт
with conn.begin(): # ФТ-03: одна транзакція
old = read_for_update(reg, rs.filter) # SELECT ... FOR UPDATE

# АП-2: дельта рахується набором, один раз; тільки active-записи
delta = aggregate(rs.active_records, sign=+1) + aggregate(old, sign=-1)

if replace: # ФТ-04
conn.execute(delete(tbl).where(*rs.filter.clauses)) # 1 запит
conn.execute(insert(tbl), rs.as_dicts()) # 1 executemany (АП-1)

update_totals(reg, delta) # -> merge_totals(), розділи 10.2, Е.3

if reg.kind is RegisterKind.CALCULATION:
keys = rs.affected_keys | affected_keys(old)
recompute_actual_periods(reg, keys) # розділ 10.4
register_recalculations(reg, [*rs.records, *old]) # розділ 10.5
</syntaxhighlight>

== 10.2. Інкрементальне оновлення підсумків залишків ==

<syntaxhighlight lang="sql">
-- Δ (delta) — тимчасова таблиця: (period_month, d1_r, d2_r, d3_t, d3_r, d4_r, dr1, dr2)
-- де dr = Σ (CASE WHEN mvt = 0 THEN +значення ELSE -значення END)

-- Крок 1. Кумулятивні залишки: рух у місяці M впливає на підсумки всіх періодів > M
-- та на рядок MAXPERIOD.
INSERT INTO rg_a_0012_tb AS t (period, splitter, d1_r, d2_r, d3_t, d3_r, d4_r, r1, r2)
SELECT p.period, :splitter, d.d1_r, d.d2_r, d.d3_t, d.d3_r, d.d4_r, d.dr1, d.dr2
FROM delta d
CROSS JOIN LATERAL (
SELECT period FROM totals_periods
WHERE period > d.period_month
AND period <= (SELECT totals_actual_to FROM rg_a_0012_opt)
UNION ALL SELECT TIMESTAMP '5999-11-01' -- MAXPERIOD
) p
ORDER BY 1,3,4,5,6,7 -- детермінований порядок → без дедлоків
ON CONFLICT (period, d1_r, d2_r, d3_t, d3_r, d4_r, splitter)
DO UPDATE SET r1 = t.r1 + EXCLUDED.r1,
r2 = t.r2 + EXCLUDED.r2;

-- Крок 2. Прибирання нульових рядків (регламентно, не в транзакції проведення)
DELETE FROM rg_a_0012_tb WHERE r1 = 0 AND r2 = 0 AND period <> TIMESTAMP '5999-11-01';
</syntaxhighlight>

{{Note|'''Оптимізація.''' Крок 1 у наведеному вигляді має складність O(кількість_періодів_після_руху). Для рухів «заднім числом» на роки це дорого. '''Проєктне рішення №3:''' підсумки оновлюються тільки для рядка <code>MAXPERIOD</code> і для найближчої межі періоду; повні кумулятивні зрізи перебудовуються регламентним завданням «Перерахунок підсумків» за зміненими місяцями (список змінених місяців накопичується в <code>rg_a_0012_opt.dirty_months</code>). Запити на дату в «брудному» місяці автоматично перемикаються на розрахунок від найближчого чистого зрізу. Остаточний вибір — за результатами НТ-02.}}

== 10.3. Трансляція віртуальної таблиці «Залишки» ==

<syntaxhighlight lang="sql">
-- РегістрНакопичення.ТовариНаСкладах.Залишки(&Період, Склад = &Склад)
WITH boundary AS (
SELECT COALESCE(MAX(period), TIMESTAMP '0001-01-01') AS p
FROM totals_periods
WHERE period <= :Період
AND period <= (SELECT totals_actual_to FROM rg_a_0012_opt)
),
base AS ( -- залишок на межу періоду з підсумків
SELECT t.d1_r, t.d2_r, t.d3_t, t.d3_r, t.d4_r,
SUM(t.r1) AS r1, SUM(t.r2) AS r2
FROM rg_a_0012_tb t, boundary b
WHERE t.period = b.p
AND t.d2_r = :Склад -- push-down параметра ВТ
GROUP BY 1,2,3,4,5
),
tail AS ( -- «живі» рухи після межі й до &Період
SELECT m.d1_r, m.d2_r, m.d3_t, m.d3_r, m.d4_r,
SUM(CASE WHEN m.mvt = 0 THEN m.r1 ELSE -m.r1 END) AS r1,
SUM(CASE WHEN m.mvt = 0 THEN m.r2 ELSE -m.r2 END) AS r2
FROM rg_a_0012 m, boundary b
WHERE m.active
AND m.period > b.p
AND m.period <= :Період
AND m.d2_r = :Склад
GROUP BY 1,2,3,4,5
)
SELECT d1_r AS "Номенклатура", d2_r AS "Склад",
d3_t, d3_r AS "Партія", d4_r AS "Характеристика",
SUM(r1) AS "КількістьЗалишок",
SUM(r2) AS "СумаЗалишок"
FROM (SELECT * FROM base UNION ALL SELECT * FROM tail) u
GROUP BY 1,2,3,4,5
HAVING SUM(r1) <> 0 OR SUM(r2) <> 0; -- нульові залишки не повертаються
</syntaxhighlight>

'''Оптимізація для найчастішого випадку:''' якщо <code>:Період ≥ ТА</code> і в регістрі немає рухів у майбутньому — <code>base</code> читається з рядка <code>MAXPERIOD</code> одним index seek, <code>tail</code> = ∅.

== 10.4. Розрахунок фактичних періодів дії (витіснення) ==

<syntaxhighlight lang="python">
def recompute_actual_periods(reg: Register, keys: set[DimKey]) -> None:
"""Розділ 7.5.1, ФТ-22…ФТ-24. Тут — оркестрація; сам алгоритм — Додаток Е.5."""
tbl = schema.movements(reg)
ap = schema.actual_periods(reg) # rg_c_<id>_ap

# 1. Читання всіх записів зачеплених ключів — ОДИН запит (АП-1)
records = conn.execute(
select(tbl).where(tbl.c.active, dim_key_in(tbl, keys))
).all()

# 2. Перерахунок інтервалів. Гарячий шлях: бюджет ≤ 3 c (АП-4),
# реалізація за Protocol-інтерфейсом (АП-3) — див. Е.5.
# Пріоритет: A витісняється B, якщо B ∈ ПВР[A].ВитісняючіВидиРозрахунку
intervals = displacement_engine.compute(records, displaces=plan.displaces)

# 3. Заміщення фактичних періодів — два запити на весь набір, не на запис
conn.execute(delete(ap).where(record_key_in(ap, intervals.keys())))
conn.execute(insert(ap), [
{"rec_t": k.rec_t, "rec_r": k.rec_r, "line_no": k.line_no,
"interval_no": n, "calc_type_r": k.calc_type, "d1_r": k.base_dim,
"fact_begin": begin, "fact_end": end}
for k, ivs in intervals.items()
for n, (begin, end) in enumerate(ivs) # 1 запис -> 0..N інтервалів
])
</syntaxhighlight>

'''Складність:''' O(|Z|² ) на ключ. Обмеження: якщо <code>|Z| > 500</code> для одного ключа — попередження в журналі та перехід на алгоритм замітання (sweep line) O(|Z| log |Z|).

== 10.5. Реєстрація перерахунків ==

<syntaxhighlight lang="python">
def register_recalculations(reg: Register, changed: Sequence[CalcRecord]) -> None:
"""Розділ 7.5.3, ФТ-26. АП-2: пошук залежних виконує СКБД, а не цикл у Python."""
q = schema.movements(reg).alias("q")
b = schema.calc_plan_base(reg).alias("b") # ТЧ «БазовіВидиРозрахунку» ПВР

for recalc in reg.recalculations:
rc = schema.recalc_table(reg, recalc) # rg_c_<id>_rc<n>
src = values_of(changed).alias("src") # змінені записи як VALUES-таблиця

# інтервальний предикат залежно від режиму базового періоду
if reg.base_period == "ByActionPeriod":
in_base = and_(src.c.act_begin <= q.c.base_end,
src.c.act_end >= q.c.base_begin) # перетин періодів
else: # ByRegistrationPeriod
in_base = src.c.period.between(q.c.base_begin, q.c.base_end)

dependent = (
select(q.c.rec_t, q.c.rec_r, q.c.calc_type_r,
*[q.c[c] for c in recalc.dim_columns],
src.c.rec_t.label("src_rec_t"), src.c.rec_r.label("src_rec_r"))
.select_from(
src.join(b, b.c.base_type_r == src.c.calc_type_r) # z — базовий для q
.join(q, q.c.calc_type_r == b.c.ref))
.where(q.c.active, in_base,
*[q.c[c] == src.c[c] for c in recalc.dim_columns],
tuple_(q.c.rec_t, q.c.rec_r) != tuple_(src.c.rec_t, src.c.rec_r))
.distinct()
)

stmt = pg_insert(rc).from_select(list(rc.columns.keys()), dependent)
conn.execute(stmt.on_conflict_do_nothing()) # 1 запит на перерахунок (АП-1)
</syntaxhighlight>

== 10.6. Зріз останніх ==

<syntaxhighlight lang="sql">
-- РегістрВідомостей.КурсиВалют.ЗрізОстанніх(&Дата, Валюта В (&Список))
SELECT DISTINCT ON (r.d1_r)
r.d1_r AS "Валюта", r.period AS "Період", r.r1 AS "Курс", r.r2 AS "Кратність"
FROM rg_i_0007 r
WHERE r.period <= :Дата
AND r.d1_r = ANY (:Список)
ORDER BY r.d1_r, r.period DESC; -- використовує ix_rg_i_0007_d1 (d1_r, period DESC)
-- Для MS SQL: ROW_NUMBER() OVER (PARTITION BY d1_r ORDER BY period DESC) = 1
-- або OUTER APPLY (SELECT TOP 1 ...) для великих списків.
</syntaxhighlight>

= 11. Нефункціональні вимоги =

== 11.1. Продуктивність ==
Еталонний стенд: 16 vCPU, 128 ГБ RAM, NVMe, PostgreSQL 15, БД 1,5 ТБ.

{| class="wikitable"
! № !! Операція !! Обсяг !! Ціль (P95)
|-
| НФВ-01 || Залишки на поточну дату, відбір за 1 вимірюванням || 1 млрд рухів, 20 млн рядків підсумків || ≤ 200 мс
|-
| НФВ-02 || Залишки на довільну дату в межах ТА || те саме || ≤ 400 мс
|-
| НФВ-03 || Обороти за 12 місяців із групуванням || 1 млрд рухів || ≤ 2 с
|-
| НФВ-04 || Проведення документа зі 100 рядками рухів (3 регістри) || — || ≤ 300 мс
|-
| НФВ-05 || Оборотно-сальдова відомість по всіх рахунках за місяць || 200 млн проводок || ≤ 5 с
|-
| НФВ-06 || Розрахунок ЗП: 10 000 співробітників × 8 видів розрахунку || — || ≤ 10 хв
|-
| НФВ-07 || Зріз останніх по 5 000 елементів вимірювання || 50 млн записів РВ || ≤ 500 мс
|-
| НФВ-08 || Пропускна здатність проведення || — || ≥ 50 док/с (10 паралельних сеансів)
|-
| НФВ-09 || Перерахунок підсумків РН || 1 млрд рухів || ≤ 4 год (у вікні обслуговування)
|}

{{Note|'''Вплив мови ядра.''' Цілі НФВ-01…НФВ-09 сформульовані для архітектури, де обчислює СКБД, а Python-ядро лише формує SQL (принципи АП-1, АП-2). Аналіз частки Python у кожній цілі — розділ 4.4.2: максимум 5 % (НФВ-04), запас на НФВ-06 — ×40. '''Цілі не переглядаються у зв'язку з вибором Python.'''}}

== 11.2. Масштабованість і обсяги ==
{| class="wikitable"
! Параметр !! Значення
|-
| Макс. записів в одному регістрі || 10<sup>10</sup>
|-
| Макс. кількість регістрів у конфігурації || 2 000
|-
| Макс. одночасних сеансів проведення || 200
|-
| Секціонування || Обов'язкове для таблиць > 100 млн записів
|}

== 11.3. Надійність і цілісність ==
* НФВ-10. Рухи та реєстратор змінюються в одній транзакції БД; часткове проведення неможливе.
* НФВ-11. Аварійне завершення сервера не залишає підсумки неузгодженими (гарантується транзакцією).
* НФВ-12. Сервіс перевірки цілісності (ФТ-41) виконується регламентно; розбіжність підсумків = інцидент P1.

== 11.4. Супроводжуваність ==
* НФВ-13. Реструктуризація регістру (додавання ресурсу/реквізиту) для таблиці ≤ 100 млн записів — ≤ 30 хв.
* НФВ-14. Додавання вимірювання вимагає перебудови підсумків; система повинна попереджати про оцінку часу до початку операції.
* НФВ-15. Усі DDL-операції — ідемпотентні та скриптовані (можливість застосувати вручну).

== 11.5. Сумісність ==
* НФВ-16. PostgreSQL 14+ та MS SQL Server 2019+ — обидві платформи з однаковою функціональністю.
* НФВ-17. Генератор DDL ізольований у шар «діалект СКБД».

= 12. Міграція існуючих структур K2 ERP =

== 12.1. Етапи ==
{| class="wikitable"
! № !! Етап !! Результат
|-
| М1 || Інвентаризація || Реєстр наявних «регістроподібних» таблиць K2 з класифікацією за типом-мішенню (РВ/РН/РБ/РР).
|-
| М2 || Мапінг || Для кожної таблиці — метаопис цільового регістру + правила перетворення колонок.
|-
| М3 || Створення регістрів || Генерація метаданих і DDL у тестовому контурі.
|-
| М4 || Перенесення даних || ETL: історичні дані → рухи, з призначенням реєстратора (реальний документ або службовий «ВведенняЗалишків»).
|-
| М5 || Побудова підсумків || Повний перерахунок.
|-
| М6 || Звірка || Порівняння залишків/оборотів «стара система vs нова» на контрольних датах; допуск розбіжності = 0.
|-
| М7 || Перемикання коду || Заміна прямих SQL-звернень на віртуальні таблиці; період паралельної роботи ≥ 1 звітний період.
|-
| М8 || Виведення з експлуатації || Видалення старих таблиць після 2 закритих періодів.
|}

== 12.2. Проблемні випадки ==
{| class="wikitable"
! Випадок !! Рішення
|-
| Історичні записи без документа-джерела || Службовий документ <code>ВведенняЗалишків</code> (один на період/розділ).
|-
| Записи з дублями за ключем (для незалежного РВ) || Дедуплікація з протоколом; конфлікти — на ручний розбір.
|-
| Дробові періоди / некоректні дати (NULL, 1900-01-01) || Нормалізація до MINPERIOD; протокол.
|-
| Прикладний код, що пише в таблиці напряму || Заборона на рівні прав БД після М7; аудит звернень на етапі М3–М6.
|-
| Аналітика, відсутня в цільовій моделі || Перенесення в реквізити (не у вимірювання) або відмова від міграції з обґрунтуванням.
|}

= 13. Приймальні випробування =

== 13.1. Функціональні тести (витяг) ==
{| class="wikitable"
! ID !! Сценарій !! Очікуваний результат
|-
| ФТ-Т-01 || Створити РВ періодичний незалежний, записати 2 записи з однаковим ключем || Другий запис заміщує перший; у таблиці 1 рядок
|-
| ФТ-Т-02 || Провести документ → 5 рухів РН || 5 записів у <code>rg_a_*</code>; підсумки MAXPERIOD змінилися на суму дельти
|-
| ФТ-Т-03 || Скасувати проведення || 0 записів; підсумки повернулися до вихідних значень
|-
| ФТ-Т-04 || Видалити документ-реєстратор || Рухи видалені каскадно; перевірка цілісності — 0 помилок
|-
| ФТ-Т-05 || Записати рух заднім числом (−6 міс.) || Залишки на всі дати після руху коректні (звірка з повним перерахунком)
|-
| ФТ-Т-06 || Установити <code>Активність = Хиба</code> || Запис не впливає на віртуальні таблиці; підсумки скориговані
|-
| ФТ-Т-07 || РБ: провести незбалансовану проводку (Дт ≠ Кт за балансовим ресурсом) || Помилка проведення, транзакція відкочена
|-
| ФТ-Т-08 || РБ: ОСВ по рахунку з 3 субконто || Підсумки за рівнями 0–3 узгоджені між собою (згортка tb3 → tb0)
|-
| ФТ-Т-09 || РР: сценарій «Оклад + Відпустка + Лікарняний» (розд. 7.5.1) || Фактичні періоди дії відповідають еталону; «Оклад» дає 2 інтервали
|-
| ФТ-Т-10 || РР: зміна базового запису || У таблиці перерахунку з'явився запис для залежного документа
|-
| ФТ-Т-11 || Паралельне проведення 2 документів за різними складами || Обидва проходять без очікування (розділення підсумків увімкнено)
|-
| ФТ-Т-12 || Паралельне проведення 2 документів за одним складом і одним товаром з контролем залишків || Один чекає, другий проходить; від'ємного залишку немає
|-
| ФТ-Т-13 || Перерахунок підсумків після хаотичних 10<sup>6</sup> операцій || Підсумки збігаються з повним перерахунком «з нуля» до копійки
|-
| ФТ-Т-14 || Реструктуризація: додати ресурс до РН із 10 млн записів || Дані збережені, підсумки перебудовані, час ≤ НФВ-13
|-
| ФТ-Т-15 || RLS: користувач з обмеженням по організації || Віртуальні таблиці повертають лише дозволені дані
|}

== 13.2. Навантажувальні тести ==
{| class="wikitable"
! ID !! Тест !! Критерій
|-
| НТ-01 || Генерація 1 млрд рухів РН, заміри НФВ-01…НФВ-03 || Досягнення цілей
|-
| НТ-02 || Профіль «90 % рухів поточним періодом, 10 % заднім числом» — порівняння двох стратегій підсумків (розд. 10.2) || Обґрунтований вибір Рішення №3
|-
| НТ-03 || Пікове проведення 50 док/с протягом 1 год || Відсутність дедлоків; P95 ≤ НФВ-04
|-
| НТ-04 || РБ: субконто-слоти vs дочірня таблиця, 200 млн проводок || Обґрунтований вибір Рішення №2
|-
| НТ-05 || Розрахунок ЗП на 10 000 співробітників || НФВ-06
|-
| НТ-06 || Деградація за 24 год безперервної роботи || Приріст часу відгуку ≤ 15 %
|}

= 14. Етапи робіт та оцінка =

{| class="wikitable"
! Етап !! Зміст !! Результат !! Оцінка, чол.-міс. !! Залежності
|-
| '''Е0''' || Обстеження платформи, верифікація припущень П1–П6, ескізний проєкт || Затверджений архітектурний ескіз, уточнене ТЗ || 1,5 || —
|-
| '''Е1''' || Метамодель + репозиторій + генератор DDL + конструктор (базовий) || Створення регістру будь-якого типу з генерацією схеми || 3 || Е0
|-
| '''Е2''' || Регістр відомостей: рантайм, набори записів, зрізи, форми || РВ у продуктиві || 2,5 || Е1
|-
| '''Е3''' || Регістр накопичення: рухи, підсумки, ТА, віртуальні таблиці || РН у продуктиві || 5 || Е2
|-
| '''Е4''' || Механізм проведення документів, блокування, оперативне/неоперативне проведення || Транзакційне проведення || 2,5 || Е3
|-
| '''Е5''' || Розширення мови запитів (віртуальні таблиці, транслятор, push-down) || Запити до ВТ || 3,5 || Е3
|-
| '''Е6''' || Регістр бухгалтерії + план рахунків + субконто + підсумки за рівнями || РБ у продуктиві || 6 || Е4, Е5
|-
| '''Е7''' || Регістр розрахунку + ПВР + витіснення + база + графіки + перерахунки || РР у продуктиві || 6,5 || Е4, Е5
|-
| '''Е8''' || Агрегати, розділення підсумків, порадник агрегатів || Оптимізація || 2,5 || Е3
|-
| '''Е9''' || Права доступу, RLS, аудит, сервіси цілісності || Безпека та адміністрування || 2 || Е6, Е7
|-
| '''Е10''' || Реструктуризація, міграція, інструменти звірки || Інструменти міграції || 2 || Е6, Е7
|-
| '''Е11''' || Навантажувальне тестування, оптимізація, документація, '''профілювання Python + бенчмарки гарячих шляхів''' || Приймальні випробування || 4,5 || усі
|-
| colspan="3" | '''РАЗОМ''' || '''41,5''' ||
|}

{{Note|Оцінка орієнтовна (±40 %) і підлягає уточненню за результатами Е0. Критичний шлях: Е0 → Е1 → Е3 → Е5 → Е6/Е7 → Е11. За командою 6–8 інженерів — орієнтовно 9–11 календарних місяців.}}

'''Мінімальний життєздатний обсяг (MVP)''': Е0–Е5 (РВ + РН + проведення + запити) ≈ '''18 чол.-міс.''' — покриває ~70 % прикладних сценаріїв K2 ERP.

=== 14.1. Вплив вибору Python на оцінку ===

{| class="wikitable"
! Етап !! Було (мова не визначена) !! Стало (Python) !! Δ !! Причина
|-
| Е1 (метамодель, DDL, конструктор) || 4 || '''3''' || '''−1''' || SQLAlchemy Core закриває генерацію DDL і діалекти СКБД; Pydantic v2 — валідацію DSL. Разом ~30 % етапу — готове.
|-
| Е5 (мова запитів, транслятор) || 4 || '''3,5''' || '''−0,5''' || lark (граматика) + SQLAlchemy Core expression language замість власного AST→SQL.
|-
| Е7 (регістр розрахунку) || 6 || '''6,5''' || '''+0,5''' || Ізоляція витіснення за інтерфейсом (АП-3) + резерв на нативну реалізацію.
|-
| Е10 (реструктуризація, міграція) || 2,5 || '''2''' || '''−0,5''' || Alembic покриває автогенерацію <code>ALTER</code>.
|-
| Е11 (навантаження, оптимізація) || 3 || '''4,5''' || '''+1,5''' || Профілювання Python, бенчмарки бюджету АП-4, ймовірні Cython/Rust-модулі, wheels у CI.
|-
| '''РАЗОМ''' || '''41,5''' || '''41,5''' || '''0''' || Економія на інфраструктурному коді компенсує витрати на оптимізацію.
|}

'''Висновок:''' Python — '''нейтральний за трудомісткістю''' для цього проєкту. Він здешевлює те, чого тут багато (метадані, генерація схеми, абстракція діалектів, міграції), і дорожчає те, чого тут мало (гарячі CPU-цикли). Ризик зміщується з «''не встигнемо написати''» на «''не вкладемося в бюджет часу виконання''» — тому бенчмарки гарячих шляхів (АП-4) вводяться в CI '''з етапу Е3''', а не наприкінці.

= 15. Ризики =

{| class="wikitable"
! ID !! Ризик !! Ймов. !! Вплив !! Пом'якшення
|-
| Р1 || У K2 ERP немає власної мови запитів → віртуальні таблиці нікуди вбудовувати || Сер. || '''Крит.''' || Верифікувати на Е0. План «Б»: віртуальні таблиці як параметризовані view/TVF + шар ORM.
|-
| Р2 || Конкуренція за таблицю підсумків на піках проведення || Вис. || Вис. || Розділення підсумків (сплітери), НТ-03, детермінований порядок MERGE.
|-
| Р3 || Рухи «заднім числом» роблять оновлення підсумків O(N періодів) || Вис. || Сер. || Рішення №3 (dirty months + регламентний перерахунок), НТ-02.
|-
| Р4 || «Широка» схема субконто → реструктуризація при зміні ліміту || Сер. || Сер. || Зафіксувати ліміт 5 із запасом; НТ-04; план «Б» — дочірня таблиця.
|-
| Р5 || Механізм витіснення РР — найскладніший і найпомилковіший вузол || Вис. || Вис. || Виділити в окремий модуль з еталонним набором з 50+ тест-кейсів; property-based тестування.
|-
| Р6 || Обсяг Е6+Е7 недооцінено (досвід 1С: це роки розробки) || Вис. || Вис. || MVP-підхід: спершу Е0–Е5, рішення про Е6/Е7 — після ретроспективи.
|-
| Р7 || Різна поведінка PostgreSQL і MS SQL (плани, MERGE, ізоляція) || Сер. || Сер. || Єдиний набір тестів на обох СКБД у CI від Е1.
|-
| Р8 || Міграція історичних даних без реєстраторів || Вис. || Сер. || Службовий документ «ВведенняЗалишків»; етап звірки М6 з нульовим допуском.
|-
| Р9 || Патентні / ліцензійні претензії щодо копіювання механізмів || Низ. || Вис. || Юридична експертиза до Е1: реалізація ''концепцій'' обліку (загальновідомих), а не коду/API; уникати дослівного копіювання найменувань API та документації.
|-
| Р10 || '''Гарячі шляхи''' (витіснення, розрахунок ЗП) на чистому Python не вкладаються в бюджет АП-4 || Сер. || Сер. || Ізоляція за <code>Protocol</code>-інтерфейсом (АП-3) + бенчмарк у CI від Е7; готовність до Cython/Rust; альтернатива для витіснення — <code>daterange</code>+GiST у PostgreSQL.
|-
| Р11 || '''Динамічна типізація в ядрі метаданих''' → помилки типів спливають у рантаймі на продуктиві || Вис. || Сер. || <code>mypy --strict</code> як обов'язковий gate у CI; Pydantic v2 на всіх межах; генерація <code>.pyi</code>-стабів для прикладного коду (ФТ-К-07).
|-
| Р12 || '''GIL''' обмежує вертикальне масштабування сервера застосунків || Сер. || Низ. || АП-5: asyncio для IO + мультипроцесний пул. Розрахунок у 4.4.2 показує запас: 50 док/с ≈ 50 % одного ядра.
|-
| Р13 || '''Нативні розширення''' (Cython/Rust) ускладнюють збірку, кросплатформність і пошук інженерів || Низ. || Низ. || Вводяться тільки за результатами бенчмарку; wheels під усі цільові платформи в CI; питання В13.
|-
| Р14 || '''Виконання прикладного Python-коду''' в процесі сервера = виконання довільного коду з правами сервера (П8) || Вис. || '''Крит.''' || '''Питання В12 до Е0.''' Варіанти: (а) довірена модель — конфігурацію пише лише вендор/партнер; (б) ізоляція процесами + seccomp/AppArmor; (в) обмежений DSL замість повного Python. У 1С вбудована мова існує в т.ч. з цієї причини.
|}

{{Note|'''Ризик Р9 — обов'язково до опрацювання перед стартом.''' ТЗ описує ''функціональні концепції'' (накопичувальний облік, подвійний запис, витіснення періодів дії), що є загальновідомими практиками обліку. Проте пряме відтворення пропрієтарних інтерфейсів, найменувань і структур конкретного вендора потребує окремої правової оцінки. Рекомендується узгодити з юридичною службою власну термінологію та API до початку Е1.}}

= 16. Додатки =

== Додаток А. Матриця відповідності «1С ↔ K2 ERP» ==

{| class="wikitable"
! Об'єкт / поняття 1С !! Пропонований аналог K2 ERP !! Примітка
|-
| РегистрСведений || <code>Регістри.Відомостей.*</code> || Повний паритет
|-
| РегистрНакопления || <code>Регістри.Накопичення.*</code> || Повний паритет
|-
| РегистрБухгалтерии || <code>Регістри.Бухгалтерії.*</code> || Субконто зберігаються інакше (слоти)
|-
| РегистрРасчета || <code>Регістри.Розрахунку.*</code> || Повний паритет
|-
| Регистратор || <code>Реєстратор</code> || —
|-
| ВидДвижения || <code>ВидРуху</code> || —
|-
| Итоги || <code>Підсумки</code> || —
|-
| Точка актуальности итогов || <code>ТА підсумків</code> || —
|-
| Разделение итогов || <code>Розділення підсумків</code> (splitter) || —
|-
| Агрегаты || <code>Агрегати</code> || —
|-
| Субконто / ПланВидовХарактеристик || <code>Субконто</code> / <code>ПланВидівХарактеристик</code> || —
|-
| ПланВидовРасчета || <code>ПланВидівРозрахунку</code> || —
|-
| Перерасчет || <code>Перерахунок</code> || —
|-
| ПериодДействия / Вытеснение || <code>ПеріодДії</code> / <code>Витіснення</code> || —
|-
| Границя послідовності || '''Не реалізується''' || Механізм визнано застарілим; замість нього — перепроведення за списком «брудних» документів
|-
| РегистрыСведений з режимом «ПоПозицииРегистратора» || <code>ПоПозиціїРеєстратора</code> || Реалізується як (period, rec_t, rec_r, line_no) у ключі
|}

== Додаток Б. Альтернатива зберігання субконто (план «Б» до Рішення №2) ==

<syntaxhighlight lang="sql">
-- Дочірня таблиця «ключ-значення» замість слотів
CREATE TABLE rg_b_0020_ed (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
side smallint NOT NULL CHECK (side IN (0,1)), -- 0=Дт, 1=Кт
ed_no smallint NOT NULL, -- порядковий номер субконто рахунка
ed_type_r uuid NOT NULL, -- вид субконто
val_t smallint NOT NULL,
val_r uuid,
val_n numeric(38,10),
val_s varchar(150),
val_d timestamp(0),
PRIMARY KEY (rec_t, rec_r, line_no, side, ed_no),
FOREIGN KEY (rec_t, rec_r, line_no) REFERENCES rg_b_0020 (rec_t, rec_r, line_no) ON DELETE CASCADE
);
CREATE INDEX ix_rg_b_0020_ed_val ON rg_b_0020_ed (ed_type_r, val_t, val_r);
</syntaxhighlight>

{| class="wikitable"
! Критерій !! Слоти (Рішення №2) !! Дочірня таблиця (план «Б»)
|-
| Відбір за 1 субконто || Index seek по колонці || JOIN + семі-з'єднання
|-
| Відбір за 3 субконто || 3 предикати в одному скані || 3 JOIN
|-
| Зміна <code>МаксКількістьСубконто</code> || ALTER TABLE (реструктуризація) || Без змін схеми
|-
| Розмір рядка проводки || +48 байт × 2 (Дт/Кт) || Базовий
|-
| Складність генератора DDL || Вища || Нижча
|-
| '''Рекомендація''' || '''Обрано за замовчуванням''' || Резерв за результатами НТ-04
|}

== Додаток В. Перелік вимог (реєстр трасування) ==

{| class="wikitable sortable"
! ID !! Розділ !! Коротко !! Пріоритет !! Тест
|-
| ФТ-01…ФТ-07 || 7.1 || Набори записів, проведення || Must || ФТ-Т-02…04
|-
| ФТ-08…ФТ-10 || 7.2 || Активність || Must || ФТ-Т-06
|-
| ФТ-11…ФТ-13 || 7.3 || Віртуальні таблиці || Must || ФТ-Т-08, НТ-01
|-
| ФТ-14…ФТ-18 || 7.4 || Підсумки, ТА || Must || ФТ-Т-05, ФТ-Т-13
|-
| ФТ-19…ФТ-21 || 7.4.4 || Агрегати || Should || НТ-01
|-
| ФТ-22…ФТ-30 || 7.5 || Механіка РР || Must (для Е7) || ФТ-Т-09, ФТ-Т-10
|-
| ФТ-31…ФТ-36 || 7.7 || Блокування || Must || ФТ-Т-11, ФТ-Т-12, НТ-03
|-
| ФТ-37…ФТ-39 || 7.8 || Права, RLS || Must || ФТ-Т-15
|-
| ФТ-40…ФТ-42 || 7.9 || Аудит, цілісність || Should || ФТ-Т-04
|-
| ФТ-К-01…06 || 6.8.4 || Конструктор || Should || —
|-
| НФВ-01…НФВ-09 || 11.1 || Продуктивність || Must || НТ-01…НТ-06
|-
| НФВ-10…НФВ-12 || 11.3 || Цілісність || Must || ФТ-Т-13
|-
| НФВ-13…НФВ-17 || 11.4–11.5 || Супровід, сумісність || Should || ФТ-Т-14
|}

== Додаток Г. Відкриті питання ==

{| class="wikitable"
! № !! Питання !! Кому !! Термін
|-
| В1 || Чи існує в K2 ERP мова запитів / транслятор у SQL? (визначає Р1 та обсяг Е5) || Архітектор платформи || До Е0
|-
| В2 || Формат ідентифікації об'єктів: UUID чи сурогатний int? || Архітектор платформи || До Е0
|-
| В3 || Чи потрібна мілісекундна дискретність періоду? || Замовник || До Е1
|-
| В4 || Максимальна кількість субконто: 3 чи 5? || Головний бухгалтер / методолог || До Е6
|-
| В5 || Чи потрібен механізм «Границя послідовності»? (пропонується відмова) || Методолог || До Е3
|-
| В6 || Пріоритет типів регістрів: чи достатньо MVP (РВ + РН) для першого релізу? || Замовник || До Е0
|-
| В7 || Правова оцінка ризику Р9 || Юридична служба || До Е1
|-
| В8 || Цільова СКБД для першої черги: тільки PostgreSQL чи одразу обидві? || Архітектор / ІТ-експлуатація || До Е1
|-
| В9 || '''Міжпланова база розрахунку:''' чи потрібна можливість брати базу з ''іншого'' регістру розрахунку (Утримання ← ОсновніНарахування)? Якщо так — ФТ-25 і <code>md_register</code> потребують розширення полем <code>base_register_id</code> (див. Д.7.2) || Методолог ЗП / архітектор || До Е7
|-
| В10 || Чи прийнятна поведінка підпорядкованого РВ без контролю унікальності за (Період + Вимірювання)? (сумісність із 1С vs. захист від дублів — див. Д.3.2, антипатерн А-6) || Методолог || До Е2
|-
| В11 || '''Конфігуратор:''' web (FastAPI + React) чи desktop (PySide6/Qt)? Макети розділу 6.8 намальовані як desktop || Замовник / UX || До Е1
|-
| В12 || '''Ключове.''' Прикладний код — повноцінний Python чи обмежений DSL? Повний Python у процесі сервера = виконання довільного коду з правами сервера (ризик Р14) + неможливість статично перевірити конфігурацію партнера || Архітектор + служба безпеки || '''До Е0'''
|-
| В13 || Чи допустимі нативні розширення (Cython/Rust) у складі постачання? Якщо ні — потрібен план «Б» для витіснення (SQL на <code>daterange</code>) || ІТ-експлуатація || До Е7
|-
| В14 || Цільова версія: 3.12 чи 3.13? Чи розглядається free-threaded build (PEP 703) як шлях зняття Р12? || Архітектор || До Е1
|-
| В15 || Мова ідентифікаторів прикладного API: кирилиця (<code>rs.new(Номенклатура=…)</code>) чи транслітерація/англійська? Впливає на ФТ-К-07 і читабельність || Замовник / методолог || До Е2
|}

== Додаток Д. Каталог прикладів регістрів ==

Додаток містить прикладні приклади регістрів усіх типів і підвидів. Для кожного наведено: декларацію (DSL), пояснення проєктних рішень, приклад даних у фізичних таблицях і типовий запит. Приклади призначені для: (а) перевірки повноти метамоделі на етапі Е0; (б) формування набору приймальних тестів; (в) навчання прикладних розробників.

=== Д.1. Як обрати тип регістру (дерево рішень) ===

<graphviz>
digraph Choose {
rankdir=TB; bgcolor="transparent";
node [shape=box, style="rounded,filled", fontname="Helvetica", fontsize=9];
edge [fontname="Helvetica", fontsize=8];

q1 [label="Що зберігаємо?", shape=diamond, fillcolor="#ffe0b2"];
q2 [label="Потрібні залишки\n(скільки Є зараз)?", shape=diamond, fillcolor="#ffe0b2"];
q3 [label="Подвійний запис,\nплан рахунків,\nсубконто?", shape=diamond, fillcolor="#ffe0b2"];
q4 [label="Періоди дії,\nвитіснення,\nбаза розрахунку?", shape=diamond, fillcolor="#ffe0b2"];
q5 [label="Значення прив'язане\nдо документа?", shape=diamond, fillcolor="#ffe0b2"];

ri_i [label="РВ незалежний\n(КурсиВалют,\nШтрихкоди)", fillcolor="#e8f5e9"];
ri_s [label="РВ підпорядкований\n(ЦіниНоменклатури,\nКадровіДані)", fillcolor="#e8f5e9"];
ra_b [label="РН «Залишки»\n(ТовариНаСкладах,\nВзаєморозрахунки)", fillcolor="#fff8e1"];
ra_t [label="РН «Обороти»\n(Продажі,\nВитрати)", fillcolor="#fff8e1"];
rb [label="РБ\n(Госпрозрахунковий)", fillcolor="#fce4ec"];
rc [label="РР\n(Нарахування,\nУтримання)", fillcolor="#ede7f6"];

q1 -> q3 [label="облікові проводки"];
q3 -> rb [label="так"];
q3 -> q4 [label="ні"];
q4 -> rc [label="так"];
q4 -> q2 [label="ні"];

q1 -> q2 [label="кількісні/сумові\nрухи"];
q2 -> ra_b [label="так"];
q2 -> ra_t [label="ні,\nлише обороти\nза період"];

q1 -> q5 [label="значення\nатрибута\nв часі"];
q5 -> ri_s [label="так"];
q5 -> ri_i [label="ні"];
}
</graphviz>

'''Контрольні питання при проєктуванні будь-якого регістру:'''
# Чи можна відповісти на всі прикладні питання ''лише'' полями цього регістру, без з'єднання з документами? Якщо ні — бракує реквізиту (не вимірювання!).
# Яка ''кардинальність'' таблиці підсумків = ∏(кількість значень вимірювань) × кількість періодів? Якщо > 10<sup>8</sup> — переглянути склад вимірювань.
# Чи потрібно фільтрувати/групувати за цим полем у звітах? Так → вимірювання. Ні, лише показувати → реквізит.
# Чи підсумовується поле? Так → ресурс. Ні → реквізит або вимірювання.

=== Д.2. Зведений каталог ===

{| class="wikitable sortable"
! № !! Регістр !! Тип !! Підвид / режим !! Вимірювання !! Ресурси !! Розділ
|-
| 1 || КурсиВалют || РВ || Періодичний (день), незалежний || Валюта || Курс, Кратність || Д.3.1
|-
| 2 || ЦіниНоменклатури || РВ || Періодичний (день), підпорядкований || Номенклатура, Характеристика, ТипЦін || Ціна || Д.3.2
|-
| 3 || ШтрихкодиНоменклатури || РВ || Неперіодичний, незалежний || Штрихкод || Номенклатура, Характеристика, Упаковка || Д.3.3
|-
| 4 || ГрафікРоботи || РВ || Неперіодичний, незалежний || ВидГрафіка, ДатаГрафіка || Значення, Годин || Д.3.4
|-
| 5 || КадровіДані || РВ || По позиції реєстратора, підпорядкований || Співробітник || Підрозділ, Посада, Ставка, ВидЗайнятості || Д.3.5
|-
| 6 || НалаштуванняКористувачів || РВ || Неперіодичний, незалежний || Користувач, Налаштування || Значення (складений) || Д.3.6
|-
| 7 || ТовариНаСкладах || РН || Залишки || Номенклатура, Склад, Партія, Характеристика || Кількість, Сума || Д.4.1
|-
| 8 || ВзаєморозрахункиЗКонтрагентами || РН || Залишки || Організація, Контрагент, Договір, Замовлення || Сума, СумаВал || Д.4.2
|-
| 9 || ТовариВРезерві || РН || Залишки || Номенклатура, Склад, Замовлення, Характеристика || Кількість || Д.4.3
|-
| 10 || ГрошовіКоштиБезготівкові || РН || Залишки || Організація, БанківськийРахунок || Сума, СумаВал || Д.4.4
|-
| 11 || Продажі || РН || Обороти (місяць) + агрегати || Номенклатура, Контрагент, Договір, Менеджер, Склад || Кількість, Сума, СумаБезПДВ, Собівартість || Д.5.1
|-
| 12 || ВитратиЗаСтаттями || РН || Обороти (місяць) || Організація, Підрозділ, СтаттяВитрат, Проєкт || Сума || Д.5.2
|-
| 13 || Госпрозрахунковий || РБ || З кореспонденцією || Організація (бал.), Підрозділ (небал.) || Сума (бал.), Кількість, ВалютнаСума || Д.6.1
|-
| 14 || ПодатковийОблік || РБ || Без кореспонденції || Організація, ВидРізниці || Сума || Д.6.2
|-
| 15 || Бюджетування || РБ || З кореспонденцією || Сценарій, ЦФВ, Проєкт || Сума || Д.6.3
|-
| 16 || ОсновніНарахування || РР || Період дії + база за періодом дії || Співробітник (баз.), Підрозділ || Результат, ВідпрацьованоДнів, НормаДнів || Д.7.1
|-
| 17 || Утримання || РР || Без періоду дії, база за періодом реєстрації || Співробітник (баз.), Підрозділ || Результат, БазаОподаткування || Д.7.2
|}

=== Д.3. Регістри відомостей ===

==== Д.3.1. КурсиВалют — періодичний, незалежний ====

'''Задача:''' зберігати історію курсів валют; отримувати курс на будь-яку дату.

<syntaxhighlight lang="yaml">
register:
name: КурсиВалют
kind: Information
synonym: "Курси валют"
periodicity: WithinDay # один курс на валюту на день
writeMode: Independent # курси вводяться вручну/завантажуються з НБУ
dimensions:
- { name: Валюта, type: "Довідник.Валюти", master: true, denyEmpty: true }
resources:
- { name: Курс, type: "Число(15,4)", denyEmpty: true }
- { name: Кратність, type: "Число(10,0)", default: 1 }
</syntaxhighlight>

'''Проєктні рішення:'''
* <code>Independent</code> — курс не породжується документом, він є зовнішнім фактом.
* <code>master: true</code> для Валюти — при видаленні валюти курси видаляються; регістр видно у формі елемента довідника.
* Періодичність <code>WithinDay</code>, а не <code>WithinSecond</code> — повторний запис курсу за той самий день ''замістить'' попередній, а не створить дубль.

'''Дані у таблиці <code>rg_i_0007</code>:'''
{| class="wikitable"
! period !! d1_r (Валюта) !! r1 (Курс) !! r2 (Кратність)
|-
| 2026-07-15 00:00:00 || USD || 41.8200 || 1
|-
| 2026-07-15 00:00:00 || EUR || 45.6100 || 1
|-
| 2026-07-16 00:00:00 || USD || 41.8500 || 1
|-
| 2026-07-17 00:00:00 || USD || 41.9000 || 1
|-
| 2026-07-17 00:00:00 || EUR || 45.7300 || 1
|}

'''Запит (курс на дату документа):'''
<syntaxhighlight lang="sql">
ВИБРАТИ Курси.Курс, Курси.Кратність
З РегістрВідомостей.КурсиВалют.ЗрізОстанніх(&ДатаДокумента, Валюта = &Валюта) ЯК Курси
</syntaxhighlight>

<syntaxhighlight lang="python">
# або через менеджер
курс = Registers.information("КурсиВалют").get_last(doc.Дата, {"Валюта": doc.Валюта})
сума_грн: Decimal = doc.СумаВалюти * курс.Курс / курс.Кратність
</syntaxhighlight>

==== Д.3.2. ЦіниНоменклатури — періодичний, підпорядкований реєстратору ====

'''Задача:''' зберігати історію цін; ціна встановлюється наказом (документом), який можна скасувати.

<syntaxhighlight lang="yaml">
register:
name: ЦіниНоменклатури
kind: Information
synonym: "Ціни номенклатури"
periodicity: WithinDay
writeMode: SubordinateToRecorder # ← ключова відмінність від КурсиВалют
dimensions:
- { name: Номенклатура, type: "Довідник.Номенклатура", master: true, index: true }
- { name: Характеристика, type: "Довідник.ХарактеристикиНоменклатури", nullable: true }
- { name: ТипЦін, type: "Довідник.ТипиЦін", master: true, denyEmpty: true }
resources:
- { name: Ціна, type: "Число(15,2)", denyEmpty: true }
attributes:
- { name: Валюта, type: "Довідник.Валюти" }
- { name: Одиниця, type: "Довідник.ОдиниціВиміру" }
recorders:
- Документ.ВстановленняЦінНоменклатури
</syntaxhighlight>

'''Проєктні рішення:'''
* <code>SubordinateToRecorder</code> — потрібна юридична прив'язка ціни до наказу, можливість скасувати наказ і «відкотити» ціни одним рухом.
* <code>Валюта</code> і <code>Одиниця</code> — '''реквізити''', а не вимірювання: за ними не фільтрують і не будують зрізи, вони визначаються типом цін. ''Помилка новачка'' — зробити Валюту вимірюванням, що подвоїть кількість записів і зламає зріз останніх.
* <code>Характеристика</code> дозволяє порожнє значення — для номенклатури без характеристик.

'''Дані у таблиці <code>rg_i_0010</code>:'''
{| class="wikitable"
! rec_t !! rec_r !! line_no !! period !! active !! d1_r (Номенкл.) !! d2_r (Характ.) !! d3_r (ТипЦін) !! r1 (Ціна) !! a1_r (Валюта)
|-
| 15 || a3f…01 || 1 || 2026-07-01 || true || Кава Lavazza 1кг || ''(порожня)'' || Роздрібна || 480.00 || UAH
|-
| 15 || a3f…01 || 2 || 2026-07-01 || true || Кава Lavazza 1кг || ''(порожня)'' || Оптова || 410.00 || UAH
|-
| 15 || a3f…01 || 3 || 2026-07-01 || true || Чай Ahmad 100г || ''(порожня)'' || Роздрібна || 95.00 || UAH
|-
| 15 || b7c…04 || 1 || 2026-07-15 || true || Кава Lavazza 1кг || ''(порожня)'' || Роздрібна || 495.00 || UAH
|}

{{Note|Зверніть увагу: у підпорядкованому РВ '''немає''' унікальності за (Період + Вимірювання). Два різні документи можуть встановити ціну на ту саму дату — платформа це дозволить, зріз останніх поверне запис із більшим <code>line_no</code> у межах реєстратора з пізнішою позицією. Це '''свідома''' поведінка (сумісність із 1С), але прикладний розробник має контролювати дублі самостійно — див. антипатерн А-6 (Д.10).}}

==== Д.3.3. ШтрихкодиНоменклатури — неперіодичний, незалежний ====

'''Задача:''' за штрихкодом знайти номенклатуру. Класичний приклад «вимірювання = те, ''за чим'' шукаємо; ресурс = те, що ''знаходимо''».

<syntaxhighlight lang="yaml">
register:
name: ШтрихкодиНоменклатури
kind: Information
periodicity: Nonperiodical
writeMode: Independent
dimensions:
- { name: Штрихкод, type: "Рядок(30)", denyEmpty: true } # ← ключ пошуку
resources:
- { name: Номенклатура, type: "Довідник.Номенклатура", denyEmpty: true }
- { name: Характеристика, type: "Довідник.ХарактеристикиНоменклатури", nullable: true }
- { name: Упаковка, type: "Довідник.УпаковкиНоменклатури", nullable: true }
</syntaxhighlight>

<syntaxhighlight lang="sql">
CREATE TABLE rg_i_0011 (
d1_s varchar(30) NOT NULL, -- Штрихкод
r1_r uuid NOT NULL, -- Номенклатура
r2_r uuid NOT NULL, -- Характеристика
r3_r uuid NOT NULL, -- Упаковка
CONSTRAINT pk_rg_i_0011 PRIMARY KEY (d1_s) -- ← унікальність штрихкоду «безкоштовно»
);
CREATE INDEX ix_rg_i_0011_r1 ON rg_i_0011 (r1_r); -- зворотний пошук: штрихкоди товару
</syntaxhighlight>

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

==== Д.3.4. ГрафікРоботи — неперіодичний, незалежний (використовується як графік для РР) ====

<syntaxhighlight lang="yaml">
register:
name: ГрафікРоботи
kind: Information
periodicity: Nonperiodical
writeMode: Independent
dimensions:
- { name: ВидГрафіка, type: "Довідник.ГрафікиРоботи", master: true, denyEmpty: true }
- { name: ДатаГрафіка, type: "Дата", denyEmpty: true } # ← вимірювання типу Дата, не Період!
resources:
- { name: Значення, type: "Число(1,0)" } # 1 = робочий день, 0 = вихідний
- { name: Годин, type: "Число(4,2)" } # тривалість зміни
</syntaxhighlight>

'''Проєктне рішення (важливе):''' <code>ДатаГрафіка</code> — це '''вимірювання''' типу <code>Дата</code>, а не стандартний реквізит <code>Період</code>. Регістр '''неперіодичний'''. Причина: графік описує ''календар'' (кожна дата — окремий факт), а не ''історію зміни значення''. Якби використали періодичність, зріз останніх повертав би «останній робочий день», що безглуздо. Механізм РР (<code>ДаніГрафіка</code>) очікує саме таку структуру.

'''Дані у таблиці <code>rg_i_0015</code>:'''
{| class="wikitable"
! d1_r (ВидГрафіка) !! d2_d (ДатаГрафіка) !! r1 (Значення) !! r2 (Годин)
|-
| П'ятиденка || 2026-07-01 || 1 || 8.00
|-
| П'ятиденка || 2026-07-04 || 0 || 0.00
|-
| П'ятиденка || 2026-07-05 || 0 || 0.00
|-
| П'ятиденка || 2026-07-06 || 1 || 8.00
|-
| Змінний 2/2 || 2026-07-01 || 1 || 12.00
|-
| Змінний 2/2 || 2026-07-03 || 0 || 0.00
|}

==== Д.3.5. КадровіДані — по позиції реєстратора ====

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

<syntaxhighlight lang="yaml">
register:
name: КадровіДані
kind: Information
periodicity: ByRecorderPosition # ← упорядкування за позицією документа, не лише за датою
writeMode: SubordinateToRecorder
dimensions:
- { name: Співробітник, type: "Довідник.Співробітники", master: true, denyEmpty: true }
resources:
- { name: Підрозділ, type: "Довідник.Підрозділи" }
- { name: Посада, type: "Довідник.Посади" }
- { name: Ставка, type: "Число(5,2)" }
- { name: ВидЗайнятості, type: "Перерахування.ВидиЗайнятості" }
- { name: ГрафікРоботи, type: "Довідник.ГрафікиРоботи" }
recorders:
- Документ.ПрийомНаРоботу
- Документ.КадровеПереміщення
- Документ.Звільнення
</syntaxhighlight>

'''Проєктне рішення:''' <code>ByRecorderPosition</code> — коли два накази оформлені однією датою (переміщення + зміна ставки), звичайна періодичність «у межах дня» дала б недетермінований результат зрізу. Позиція реєстратора додає до ключа <code>(rec_t, rec_r, line_no)</code> і впорядковує за моментом часу документа.

'''Фізична схема:'''
<syntaxhighlight lang="sql">
CREATE TABLE rg_i_0016 (
period timestamp(0) NOT NULL,
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
active boolean NOT NULL DEFAULT true,
d1_r uuid NOT NULL, -- Співробітник
r1_r uuid NOT NULL, r2_r uuid NOT NULL,
r3 numeric(5,2) NOT NULL,
r4 smallint NOT NULL, -- Перерахування зберігається як порядковий номер
r5_r uuid NOT NULL,
CONSTRAINT pk_rg_i_0016 PRIMARY KEY (period, rec_t, rec_r, line_no) -- ← Період у ключі ПЕРШИЙ
);
CREATE INDEX ix_rg_i_0016_d1 ON rg_i_0016 (d1_r, period DESC, rec_t, rec_r, line_no DESC)
WHERE active;
</syntaxhighlight>

==== Д.3.6. НалаштуванняКористувачів — складений тип ресурсу ====

<syntaxhighlight lang="yaml">
register:
name: НалаштуванняКористувачів
kind: Information
periodicity: Nonperiodical
writeMode: Independent
dimensions:
- { name: Користувач, type: "Довідник.Користувачі", master: true }
- { name: Налаштування, type: "ПланВидівХарактеристик.НалаштуванняКористувачів", master: true }
resources:
- name: Значення
type: ["Рядок(500)", "Число(15,2)", "Дата", "Булево",
"Довідник.Організації", "Довідник.Склади"] # ← складений тип
</syntaxhighlight>

<syntaxhighlight lang="sql">
CREATE TABLE rg_i_0018 (
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
r1_t smallint NOT NULL, -- код типу значення
r1_b boolean,
r1_n numeric(15,2),
r1_s varchar(500),
r1_d timestamp(0),
r1_r uuid,
CONSTRAINT pk_rg_i_0018 PRIMARY KEY (d1_r, d2_r)
);
</syntaxhighlight>

{| class="wikitable"
! d1_r !! d2_r !! r1_t !! r1_b !! r1_n !! r1_s !! r1_d !! r1_r
|-
| Іваненко || ОсновнаОрганізація || 101 || || || || || ТОВ «Альфа»
|-
| Іваненко || ОсновнийСклад || 104 || || || || || Центральний
|-
| Іваненко || ПоказуватиПідказки || 2 || true || || || ||
|-
| Петренко || КількістьРядківСписку || 3 || || 50 || || ||
|}

=== Д.4. Регістри накопичення, вид «Залишки» ===

==== Д.4.1. ТовариНаСкладах ====

Декларація — розділ 6.7, фізична схема — розділ 8.5, ER — розділ 9.2. Тут — дані.

'''Рухи (<code>rg_a_0012</code>) після проведення трьох документів:'''
{| class="wikitable"
! rec_t !! rec_r !! line_no !! period !! mvt !! d1_r (Номенкл.) !! d2_r (Склад) !! r1 (К-сть) !! r2 (Сума)
|-
| 2 (ПрихНакл) || p1 || 1 || 2026-06-10 || 0 ''Прихід'' || Кава Lavazza || Центральний || 100.000 || 35 000.00
|-
| 2 (ПрихНакл) || p1 || 2 || 2026-06-10 || 0 ''Прихід'' || Чай Ahmad || Центральний || 200.000 || 12 000.00
|-
| 3 (ВидНакл) || v1 || 1 || 2026-07-05 || 1 ''Витрата'' || Кава Lavazza || Центральний || 30.000 || 10 500.00
|-
| 4 (Переміщ) || m1 || 1 || 2026-07-12 || 1 ''Витрата'' || Кава Lavazza || Центральний || 20.000 || 7 000.00
|-
| 4 (Переміщ) || m1 || 2 || 2026-07-12 || 0 ''Прихід'' || Кава Lavazza || Роздрібний || 20.000 || 7 000.00
|}

'''Підсумки залишків (<code>rg_a_0012_tb</code>), ТА = 2026-07-31:'''
{| class="wikitable"
! period !! d1_r !! d2_r !! r1 (К-сть ±) !! r2 (Сума ±) !! Коментар
|-
| 2026-07-01 || Кава Lavazza || Центральний || 100.000 || 35 000.00 || залишок ''на початок'' липня
|-
| 2026-07-01 || Чай Ahmad || Центральний || 200.000 || 12 000.00 ||
|-
| 2026-08-01 || Кава Lavazza || Центральний || 50.000 || 17 500.00 || 100 − 30 − 20
|-
| 2026-08-01 || Кава Lavazza || Роздрібний || 20.000 || 7 000.00 ||
|-
| 2026-08-01 || Чай Ahmad || Центральний || 200.000 || 12 000.00 ||
|-
| '''5999-11-01''' || Кава Lavazza || Центральний || 50.000 || 17 500.00 || '''MAXPERIOD''' — поточний залишок
|-
| '''5999-11-01''' || Кава Lavazza || Роздрібний || 20.000 || 7 000.00 || '''MAXPERIOD'''
|-
| '''5999-11-01''' || Чай Ahmad || Центральний || 200.000 || 12 000.00 || '''MAXPERIOD'''
|}

''(Вимірювання Партія і Характеристика для стислості опущені.)''

==== Д.4.2. ВзаєморозрахункиЗКонтрагентами ====

'''Задача:''' облік дебіторської/кредиторської заборгованості в розрізі договорів і замовлень.

<syntaxhighlight lang="yaml">
register:
name: ВзаєморозрахункиЗКонтрагентами
kind: Accumulation
accumulationKind: Balance
periodicity: WithinSecond
enableBalanceTotals: true
enableTurnoverTotals: true
partitioning: { mode: RangeByPeriod, step: month }
dimensions:
- { name: Організація, type: "Довідник.Організації", denyEmpty: true, index: true }
- { name: Контрагент, type: "Довідник.Контрагенти", master: true, index: true }
- { name: Договір, type: "Довідник.ДоговориКонтрагентів", master: true, index: true }
- { name: Замовлення, type: ["Документ.ЗамовленняПокупця", "Документ.ЗамовленняПостачальнику"],
nullable: true }
resources:
- { name: Сума, type: "Число(15,2)" } # у валюті регламентованого обліку
- { name: СумаВал, type: "Число(15,2)" } # у валюті договору
attributes:
- { name: Коментар, type: "Рядок(200)" }
recorders:
- Документ.ВидатковаНакладна
- Документ.ПрихіднаНакладна
- Документ.ПлатіжнеДоручення
- Документ.КасовийОрдер
- Документ.КоригуванняБоргу
</syntaxhighlight>

'''Угода про знак (обов'язково фіксується в методології!):'''
{| class="wikitable"
! Вид руху !! Сенс !! Приклад документа
|-
| '''Прихід''' || Борг контрагента перед нами '''зростає''' (дебіторка +) || Видаткова накладна
|-
| '''Витрата''' || Борг контрагента перед нами '''зменшується''' (оплата) || Платіжне доручення вхідне
|}
Кредиторська заборгованість = від'ємний залишок. ''Альтернатива'' — два окремих ресурси (СумаДт/СумаКт) або два регістри; обраний варіант — один знаковий ресурс (простіше, менший обсяг підсумків).

'''Приклад даних:'''
{| class="wikitable"
! Документ !! period !! mvt !! Контрагент !! Договір !! r1 (Сума) !! Залишок після
|-
| ВидатковаНакладна №12 || 2026-07-05 || Прихід || ТОВ «Бета» || Основний || 12 000.00 || +12 000 ''(винні нам)''
|-
| ПлатіжнеДоручення №88 || 2026-07-09 || Витрата || ТОВ «Бета» || Основний || 8 000.00 || +4 000
|-
| ПлатіжнеДоручення №91 || 2026-07-16 || Витрата || ТОВ «Бета» || Основний || 6 000.00 || −2 000 ''(передоплата)''
|}

'''Запит (акт звірки):'''
<syntaxhighlight lang="sql">
ВИБРАТИ
Дані.Контрагент, Дані.Договір,
Дані.СумаПочатковийЗалишок, Дані.СумаПрихід,
Дані.СумаВитрата, Дані.СумаКінцевийЗалишок
З РегістрНакопичення.ВзаєморозрахункиЗКонтрагентами.ЗалишкиІОбороти(
&Початок, &Кінець, Авто, Рух,
Організація = &Організація І Контрагент = &Контрагент
) ЯК Дані
</syntaxhighlight>

==== Д.4.3. ТовариВРезерві — регістр «супутник» ====

<syntaxhighlight lang="yaml">
register:
name: ТовариВРезерві
kind: Accumulation
accumulationKind: Balance
periodicity: WithinSecond
dimensions:
- { name: Номенклатура, type: "Довідник.Номенклатура", master: true, index: true }
- { name: Характеристика, type: "Довідник.ХарактеристикиНоменклатури", nullable: true }
- { name: Склад, type: "Довідник.Склади", master: true, index: true }
- { name: Замовлення, type: "Документ.ЗамовленняПокупця", master: true, denyEmpty: true }
resources:
- { name: Кількість, type: "Число(15,3)" }
recorders:
- Документ.ЗамовленняПокупця
- Документ.ВидатковаНакладна
- Документ.ЗакриттяЗамовлень
</syntaxhighlight>

'''Патерн «доступний залишок»''' — з'єднання двох регістрів:
<syntaxhighlight lang="sql">
ВИБРАТИ
ЄСТЬNULL(Зал.Номенклатура, Рез.Номенклатура) ЯК Номенклатура,
ЄСТЬNULL(Зал.Склад, Рез.Склад) ЯК Склад,
ЄСТЬNULL(Зал.КількістьЗалишок, 0) ЯК ВСкладі,
ЄСТЬNULL(Рез.КількістьЗалишок, 0) ЯК ВРезерві,
ЄСТЬNULL(Зал.КількістьЗалишок, 0) - ЄСТЬNULL(Рез.КількістьЗалишок, 0) ЯК Доступно
З РегістрНакопичення.ТовариНаСкладах.Залишки(&Період, Склад = &Склад) ЯК Зал
ПОВНЕ З'ЄДНАННЯ РегістрНакопичення.ТовариВРезерві.Залишки(&Період, Склад = &Склад) ЯК Рез
ЗА Зал.Номенклатура = Рез.Номенклатура І Зал.Склад = Рез.Склад
</syntaxhighlight>

{{Note|Чому окремий регістр, а не ресурс «Резерв» у <code>ТовариНаСкладах</code>? Тому що резерв ведеться в розрізі '''Замовлення''', а залишок — у розрізі '''Партії'''. Додавання Замовлення як вимірювання до <code>ТовариНаСкладах</code> помножило б таблицю підсумків на кардинальність замовлень (сотні тисяч рядків на товар). Це ілюстрація контрольного питання №2 з Д.1.}}

==== Д.4.4. ГрошовіКоштиБезготівкові ====

<syntaxhighlight lang="yaml">
register:
name: ГрошовіКоштиБезготівкові
kind: Accumulation
accumulationKind: Balance
periodicity: WithinDay # достатньо дня: банківська виписка — денна
dimensions:
- { name: Організація, type: "Довідник.Організації", denyEmpty: true }
- { name: БанківськийРахунок, type: "Довідник.БанківськіРахунки", master: true, denyEmpty: true }
resources:
- { name: Сума, type: "Число(15,2)" }
- { name: СумаВал, type: "Число(15,2)" }
recorders: [Документ.ПлатіжнеДоручення, Документ.БанківськаВиписка, Документ.ПереміщенняКоштів]
</syntaxhighlight>

'''Проєктне рішення:''' Валюта — '''не''' вимірювання, тому що вона однозначно визначається банківським рахунком (функціональна залежність). Її додавання як вимірювання створило б надлишковість і ризик неузгоджених даних. Валюта отримується з'єднанням із довідником.

=== Д.5. Регістри накопичення, вид «Обороти» ===

==== Д.5.1. Продажі — з агрегатами ====

<syntaxhighlight lang="yaml">
register:
name: Продажі
kind: Accumulation
accumulationKind: Turnover # ← залишків не буває: «залишок продажів» безглуздий
periodicity: WithinSecond
turnoverTotalsPeriod: Month
aggregatesMode: Aggregates
partitioning: { mode: RangeByPeriod, step: month }
dimensions:
- { name: Номенклатура, type: "Довідник.Номенклатура", index: true }
- { name: Характеристика, type: "Довідник.ХарактеристикиНоменклатури", nullable: true }
- { name: Контрагент, type: "Довідник.Контрагенти", index: true }
- { name: Договір, type: "Довідник.ДоговориКонтрагентів" }
- { name: Менеджер, type: "Довідник.Користувачі", index: true }
- { name: Склад, type: "Довідник.Склади" }
resources:
- { name: Кількість, type: "Число(15,3)" }
- { name: Сума, type: "Число(15,2)" }
- { name: СумаБезПДВ, type: "Число(15,2)" }
- { name: Собівартість, type: "Число(15,2)" }
recorders: [Документ.ВидатковаНакладна, Документ.ПовернненняВідПокупця, Документ.ЗвітПроРоздрібніПродажі]

aggregates:
- name: ПродажіПоМісяцяхІТоварах
periodicity: Month
dimensions: [Номенклатура, Склад]
realtime: true
- name: ПродажіПоМенеджерах
periodicity: Day
dimensions: [Менеджер]
realtime: false # оновлюється регламентно
- name: ПродажіПоКонтрагентах
periodicity: Quarter
dimensions: [Контрагент, Договір]
realtime: false
</syntaxhighlight>

'''Проєктні рішення:'''
* <code>Turnover</code>, а не <code>Balance</code>: немає <code>ВидРуху</code>, немає таблиці залишків → удвічі менше підсумків і немає кумулятивних оновлень. Повернення відображається '''від'ємною''' сумою, а не «витратою».
* 6 вимірювань → таблиця підсумків надто широка для швидких звітів → компенсуємо агрегатами.

'''Ефект агрегатів:'''
{| class="wikitable"
! Звіт !! Без агрегатів (<code>rg_a_0031_tt</code>) !! З агрегатом !! Виграш
|-
| Продажі по товарах за рік || скан 8 млн рядків підсумків || <code>ag1</code>: 40 тис. рядків || ×200
|-
| Рейтинг менеджерів за квартал || скан 8 млн рядків || <code>ag2</code>: 1,8 тис. рядків || ×4000
|-
| Продажі по контрагенту за 3 роки || скан 8 млн рядків || <code>ag3</code>: 60 тис. рядків || ×130
|-
| Продажі по товару + контрагенту || '''агрегат не покриває''' → підсумки || — || —
|}

<syntaxhighlight lang="sql">
CREATE TABLE rg_a_0031_ag1 ( -- Місяць × (Номенклатура, Склад)
period timestamp(0) NOT NULL, d1_r uuid NOT NULL, d6_r uuid NOT NULL,
r1 numeric(20,3) NOT NULL, r2 numeric(20,2) NOT NULL,
r3 numeric(20,2) NOT NULL, r4 numeric(20,2) NOT NULL,
CONSTRAINT pk_rg_a_0031_ag1 PRIMARY KEY (period, d1_r, d6_r)
);
CREATE TABLE rg_a_0031_ag2 ( -- День × (Менеджер)
period timestamp(0) NOT NULL, d5_r uuid NOT NULL,
r1 numeric(20,3) NOT NULL, r2 numeric(20,2) NOT NULL,
r3 numeric(20,2) NOT NULL, r4 numeric(20,2) NOT NULL,
CONSTRAINT pk_rg_a_0031_ag2 PRIMARY KEY (period, d5_r)
);
</syntaxhighlight>

==== Д.5.2. ВитратиЗаСтаттями ====

<syntaxhighlight lang="yaml">
register:
name: ВитратиЗаСтаттями
kind: Accumulation
accumulationKind: Turnover
periodicity: WithinDay
turnoverTotalsPeriod: Month
dimensions:
- { name: Організація, type: "Довідник.Організації", denyEmpty: true }
- { name: Підрозділ, type: "Довідник.Підрозділи", index: true }
- { name: СтаттяВитрат, type: "Довідник.СтаттіВитрат", master: true, denyEmpty: true, index: true }
- { name: Проєкт, type: "Довідник.Проєкти", nullable: true }
resources:
- { name: Сума, type: "Число(15,2)" }
recorders: [Документ.АвансовийЗвіт, Документ.НадходженняПослуг, Документ.НарахуванняЗарплати, Документ.Амортизація]
</syntaxhighlight>

'''Приклад даних (<code>rg_a_0032_tt</code>, підсумки оборотів за місяць):'''
{| class="wikitable"
! period !! Підрозділ !! СтаттяВитрат !! Проєкт !! r1 (Сума)
|-
| 2026-07-01 || Відділ продажів || Оренда || ''(порожній)'' || 45 000.00
|-
| 2026-07-01 || Відділ продажів || ЗП і нарахування || ''(порожній)'' || 320 000.00
|-
| 2026-07-01 || Відділ продажів || Реклама || Запуск «Альфа» || 78 000.00
|-
| 2026-07-01 || ІТ-відділ || ЗП і нарахування || ''(порожній)'' || 410 000.00
|-
| 2026-07-01 || ІТ-відділ || Ліцензії ПЗ || ''(порожній)'' || 62 000.00
|}

=== Д.6. Регістри бухгалтерії ===

==== Д.6.1. Госпрозрахунковий — з кореспонденцією ====

Декларація — розділ 6.7, схема — 8.6, ER — 9.3. Тут — приклад проводок.

'''Господарська операція:''' реалізація товару на 12 000 грн (у т.ч. ПДВ 2 000), собівартість 7 000 грн.

'''Проводки (<code>rg_b_0020</code>, реєстратор = ВидатковаНакладна №12):'''
{| class="wikitable"
! line !! acc_dt !! ed_dt1 !! ed_dt2 !! acc_kt !! ed_kt1 !! ed_kt2 !! r1 (Сума) !! r2_dt !! r2_kt
|-
| 1 || 361 ''Розрах. з покупцями'' || ТОВ «Бета» || Договір №5 || 702 ''Дохід від реалізації'' || Кава Lavazza || ''—'' || 12 000.00 || || 30.000
|-
| 2 || 702 ''Дохід від реалізації'' || Кава Lavazza || ''—'' || 641 ''Розрах. за податками'' || ПДВ || ''—'' || 2 000.00 || ||
|-
| 3 || 902 ''Собівартість реалізації'' || Кава Lavazza || ''—'' || 281 ''Товари на складі'' || Кава Lavazza || Центральний || 7 000.00 || 30.000 || 30.000
|}

'''Контроль:''' Σ(Сума) по Дт = Σ(Сума) по Кт у межах реєстратора → 12 000 + 2 000 + 7 000 = 21 000 з обох боків. ✔

'''Підсумки, рівень 0 (<code>rg_b_0020_tb0</code>), на 5999-11-01:'''
{| class="wikitable"
! acc_r !! d1_r (Організація) !! r1 (Сума ±) !! Інтерпретація
|-
| 281 || ТОВ «Альфа» || +28 000.00 || дебетовий залишок (товари є)
|-
| 361 || ТОВ «Альфа» || +12 000.00 || дебетовий (дебіторка)
|-
| 641 || ТОВ «Альфа» || −2 000.00 || кредитовий (винні бюджету)
|-
| 702 || ТОВ «Альфа» || −10 000.00 || кредитовий (дохід)
|-
| 902 || ТОВ «Альфа» || +7 000.00 || дебетовий (собівартість)
|}

'''Підсумки, рівень 2 (<code>rg_b_0020_tb2</code>) — для рахунку 281 (2 субконто: Номенклатура, Склад):'''
{| class="wikitable"
! acc_r !! ed1_r (Номенклатура) !! ed2_r (Склад) !! r1 (Сума) !! r2 (Кількість)
|-
| 281 || Кава Lavazza || Центральний || 17 500.00 || 50.000
|-
| 281 || Кава Lavazza || Роздрібний || 7 000.00 || 20.000
|-
| 281 || Чай Ahmad || Центральний || 12 000.00 || 200.000
|}
Згортка <code>tb2</code> → <code>tb0</code>: 17 500 + 7 000 + 12 000 = '''36 500'''… ''(різниця з таблицею вище — інші операції; у тесті ФТ-Т-08 перевіряється точна рівність)''.

'''Запит (ОСВ по рахунку):'''
<syntaxhighlight lang="sql">
ВИБРАТИ
Дані.Субконто1 ЯК Номенклатура, Дані.Субконто2 ЯК Склад,
Дані.СумаПочатковийЗалишокДт, Дані.КількістьПочатковийЗалишокДт,
Дані.СумаОборотДт, Дані.СумаОборотКт,
Дані.СумаКінцевийЗалишокДт, Дані.КількістьКінцевийЗалишокДт
З РегістрБухгалтерії.Госпрозрахунковий.ЗалишкиІОбороти(
&Початок, &Кінець, Місяць,
Рахунок = &Рахунок281,
, Організація = &Організація,
,
) ЯК Дані
</syntaxhighlight>

==== Д.6.2. ПодатковийОблік — без кореспонденції ====

'''Задача:''' податковий облік із розділенням на постійні/тимчасові різниці, де подвійний запис не потрібен (кожен факт реєструється окремо по Дт або по Кт).

<syntaxhighlight lang="yaml">
register:
name: ПодатковийОблік
kind: Accounting
chartOfAccounts: ПланРахунків.Податковий
correspondence: false # ← уніграфічний облік
periodicity: WithinSecond
dimensions:
- { name: Організація, type: "Довідник.Організації", balance: true, denyEmpty: true }
- { name: ВидРізниці, type: "Перерахування.ВидиРізниць", balance: true } # БУ|ПУ|ПР|ТР
resources:
- { name: Сума, type: "Число(15,2)", balance: true }
attributes:
- { name: Зміст, type: "Рядок(255)" }
recorders: [Документ.БухгалтерськаОперація, Документ.ВидатковаНакладна, Документ.НадходженняПослуг]
</syntaxhighlight>

'''Проводки (<code>rg_b_0021</code>):'''
{| class="wikitable"
! line !! acc_mvt !! acc_r !! ed1 (Номенкл.) !! d1 (Організація) !! d2 (ВидРізниці) !! r1 (Сума)
|-
| 1 || 0 ''Дебет'' || 902.НУ || Кава Lavazza || ТОВ «Альфа» || ПУ ''податковий'' || 7 000.00
|-
| 2 || 1 ''Кредит'' || 281.НУ || Кава Lavazza || ТОВ «Альфа» || ПУ || 7 000.00
|-
| 3 || 0 ''Дебет'' || 902.НУ || Кава Lavazza || ТОВ «Альфа» || ПР ''постійна різниця'' || 350.00
|-
| 4 || 1 ''Кредит'' || 281.НУ || Кава Lavazza || ТОВ «Альфа» || ПР || 350.00
|}

'''Відмінності від Д.6.1:'''
{| class="wikitable"
! !! З кореспонденцією !! Без кореспонденції
|-
| Один факт = || 1 запис (Дт+Кт) || 2 записи (окремо Дт, окремо Кт)
|-
| Поля рахунків || <code>acc_dt_r</code>, <code>acc_kt_r</code> || <code>acc_r</code> + <code>acc_mvt</code>
|-
| Субконто || 2 набори (Дт, Кт) || 1 набір
|-
| Кількість записів || N || 2N
|-
| Таблиця <code>_tc</code> (кореспонденції) || Є || '''Немає''' — «шахова відомість» неможлива
|-
| Контроль Дт=Кт || У межах реєстратора || Опційно (може бути незбалансовано за задумом)
|-
| Коли обирати || Класичний облік, потрібен аналіз кореспонденцій || Облік без потреби в кореспонденціях, забалансовий, статистичний
|}

==== Д.6.3. Бюджетування ====

<syntaxhighlight lang="yaml">
register:
name: Бюджетування
kind: Accounting
chartOfAccounts: ПланРахунків.Бюджетування
correspondence: true
periodicity: WithinMonth # бюджет — помісячний, до секунди не потрібно
dimensions:
- { name: Сценарій, type: "Довідник.СценаріїБюджетування", balance: true, denyEmpty: true }
- { name: ЦФВ, type: "Довідник.ЦентриФінансовоїВідповідальності", balance: true }
- { name: Проєкт, type: "Довідник.Проєкти", balance: true, nullable: true }
resources:
- { name: Сума, type: "Число(15,2)", balance: true }
recorders: [Документ.БюджетнаОперація, Документ.ВведенняБюджету]
</syntaxhighlight>

'''Проєктне рішення:''' <code>Сценарій</code> — вимірювання, а не окремий регістр на кожен сценарій (План/Факт/Прогноз). Це дозволяє план-фактний аналіз одним запитом. Усі три вимірювання '''балансові''' — бюджетна проводка не змінює сценарій/ЦФВ між дебетом і кредитом.

=== Д.7. Регістри розрахунку ===

==== Д.7.1. ОсновніНарахування — період дії + витіснення ====

'''План видів розрахунку <code>ОсновніНарахування</code>:'''
{| class="wikitable"
! Вид розрахунку !! Період дії !! Витісняючі !! Базові !! Залежність від бази
|-
| Оклад || Так || Відпустка, Лікарняний || — || Не залежить
|-
| Відпустка || Так || Лікарняний || Оклад, Премія || За періодом дії
|-
| Лікарняний || Так || — || Оклад || За періодом дії
|-
| Премія || Ні || — || Оклад || За періодом реєстрації
|}

Декларація регістру — розділ 6.7.

'''Записи (<code>rg_c_0040</code>), період реєстрації = липень 2026:'''
{| class="wikitable"
! line !! calc_type !! period !! act_begin !! act_end !! base_begin !! base_end !! d1 (Співробітник) !! r1 (Результат)
|-
| 1 || Оклад || 2026-07-01 || 2026-07-01 || 2026-07-31 || || || Іваненко || 18 000.00
|-
| 2 || Відпустка || 2026-07-01 || 2026-07-10 || 2026-07-17 || 2026-01-01 || 2026-06-30 || Іваненко || 6 420.00
|-
| 3 || Лікарняний || 2026-07-01 || 2026-07-14 || 2026-07-22 || 2026-01-01 || 2026-06-30 || Іваненко || 5 180.00
|-
| 4 || Оклад || 2026-07-01 || 2026-07-01 || 2026-07-31 || || || Петренко || 22 000.00
|}

'''Фактичні періоди дії (<code>rg_c_0040_ap</code>) — результат витіснення:'''
{| class="wikitable"
! rec/line !! interval_no !! calc_type !! d1 !! fact_begin !! fact_end !! Коментар
|-
| n1 / 1 || 0 || Оклад || Іваненко || 2026-07-01 || 2026-07-09 || до відпустки
|-
| n1 / 1 || 1 || Оклад || Іваненко || 2026-07-23 || 2026-07-31 || після лікарняного
|-
| n1 / 2 || 0 || Відпустка || Іваненко || 2026-07-10 || 2026-07-13 || витіснена лікарняним з 14-го
|-
| n1 / 3 || 0 || Лікарняний || Іваненко || 2026-07-14 || 2026-07-22 || не витісняється нічим
|-
| n1 / 4 || 0 || Оклад || Петренко || 2026-07-01 || 2026-07-31 || витіснення відсутнє
|}

'''Один запис «Оклад» Іваненка → два інтервали''' — ілюстрація зв'язку 1:N у розділі 9.4.

'''Запит (дані графіка для розрахунку окладу):'''
<syntaxhighlight lang="sql">
ВИБРАТИ
Дані.Співробітник, Дані.НомерРядка,
Дані.ЗначенняФактичногоПеріодуДії ЯК ВідпрацьованоДнів,
Дані.ЗначенняПеріодуДії ЯК НормаДнів
З РегістрРозрахунку.ОсновніНарахування.ДаніГрафіка(
ВидРозрахунку = ЗНАЧЕННЯ(ПланВидівРозрахунку.ОсновніНарахування.Оклад)
І Реєстратор = &Реєстратор
) ЯК Дані
</syntaxhighlight>
'''Результат:''' Іваненко — <code>ВідпрацьованоДнів = 13</code> (робочі дні у 01–09 та 23–31), <code>НормаДнів = 23</code> → Оклад = 18 000 × 13 / 23 = '''10 173,91'''.

'''Запит (база для відпустки):'''
<syntaxhighlight lang="sql">
ВИБРАТИ База.Співробітник, База.НомерРядка, База.РезультатБаза ЯК Заробіток
З РегістрРозрахунку.ОсновніНарахування.БазаРозрахунку(
, /* вимірювання бази */
, /* вимірювання основного регістру */
Співробітник, /* розрізи */
ВидРозрахунку = ЗНАЧЕННЯ(ПланВидівРозрахунку.ОсновніНарахування.Відпустка)
) ЯК База
</syntaxhighlight>

==== Д.7.2. Утримання — без періоду дії, база за періодом реєстрації ====

'''План видів розрахунку <code>Утримання</code>:'''
{| class="wikitable"
! Вид розрахунку !! Період дії !! Базові види розрахунку !! Залежність
|-
| ПДФО || Ні || ''(усі з ПВР ОсновніНарахування)'' || За періодом реєстрації
|-
| Військовий збір || Ні || ''(усі з ПВР ОсновніНарахування)'' || За періодом реєстрації
|-
| Аліменти || Ні || Оклад, Премія, Відпустка || За періодом реєстрації
|-
| Профспілковий внесок || Ні || Оклад || За періодом реєстрації
|}

<syntaxhighlight lang="yaml">
register:
name: Утримання
kind: Calculation
calculationTypesPlan: ПланВидівРозрахунку.Утримання
periodicity: Month
actionPeriod: false # ← утримання не має періоду дії
basePeriod: ByRegistrationPeriod # ← база береться за періодом реєстрації
# schedule: не задається — графік не потрібен
dimensions:
- { name: Співробітник, type: "Довідник.Співробітники", baseDimension: true, master: true, denyEmpty: true }
- { name: Підрозділ, type: "Довідник.Підрозділи" }
resources:
- { name: Результат, type: "Число(15,2)" }
- { name: БазаОподаткування, type: "Число(15,2)" }
recalculations:
- name: ПерерахунокУтримань
dimensions:
- { name: Співробітник, registerDimension: Співробітник }
recorders: [Документ.НарахуванняЗарплати]
</syntaxhighlight>

'''Фізична схема (спрощена — немає полів періоду дії):'''
<syntaxhighlight lang="sql">
CREATE TABLE rg_c_0041 (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
period timestamp(0) NOT NULL, -- період реєстрації
active boolean NOT NULL DEFAULT true,
reversal boolean NOT NULL DEFAULT false,
calc_type_r uuid NOT NULL,
base_begin timestamp(0) NOT NULL, -- ← є, бо basePeriod ≠ None
base_end timestamp(0) NOT NULL,
-- act_begin / act_end ВІДСУТНІ (actionPeriod: false)
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
r1 numeric(15,2) NOT NULL DEFAULT 0,
r2 numeric(15,2) NOT NULL DEFAULT 0,
CONSTRAINT pk_rg_c_0041 PRIMARY KEY (rec_t, rec_r, line_no)
);
-- Таблиця rg_c_0041_ap НЕ створюється (немає періоду дії → немає витіснення)
CREATE TABLE rg_c_0041_rc1 ( -- ПерерахунокУтримань
rec_t smallint NOT NULL, rec_r uuid NOT NULL,
calc_type_r uuid NOT NULL, d1_r uuid NOT NULL,
src_rec_t smallint NOT NULL, src_rec_r uuid NOT NULL,
created_at timestamp(0) NOT NULL DEFAULT now(),
CONSTRAINT pk_rg_c_0041_rc1 PRIMARY KEY (rec_t, rec_r, calc_type_r, d1_r)
);
</syntaxhighlight>

{{Note|'''Міжпланова база.''' Базові види розрахунку для ПВР <code>Утримання</code> належать до ''іншого'' ПВР — <code>ОсновніНарахування</code>. Це означає, що віртуальна таблиця <code>БазаРозрахунку</code> регістру <code>Утримання</code> має читати записи регістру <code>ОсновніНарахування</code>. '''Вимога ФТ-25 має бути розширена:''' метамодель повинна дозволяти вказати ''регістр-джерело бази''. Це '''відкрите питання В9''' (див. оновлений Додаток Г) — у 1С механізм працює через відповідність ПВР, а не регістрів, що обмежує сценарії. Пропозиція: додати до <code>md_register</code> поле <code>base_register_id</code>.}}

'''Приклад даних:'''
{| class="wikitable"
! line !! calc_type !! period !! base_begin !! base_end !! Співробітник !! r2 (База) !! r1 (Результат)
|-
| 1 || ПДФО || 2026-07-01 || 2026-07-01 || 2026-07-31 || Іваненко || 21 773.91 || 3 919.30
|-
| 2 || Військовий збір || 2026-07-01 || 2026-07-01 || 2026-07-31 || Іваненко || 21 773.91 || 326.61
|-
| 3 || Аліменти || 2026-07-01 || 2026-07-01 || 2026-07-31 || Іваненко || 17 528.00 || 4 382.00
|}

=== Д.8. Наскрізний приклад: проведення видаткової накладної ===

'''Документ:''' Видаткова накладна №12 від 05.07.2026, ТОВ «Бета», 30 кг кави за 400 грн (12 000 грн з ПДВ), собівартість 7 000 грн.

<graphviz>
digraph Posting {
rankdir=LR; bgcolor="transparent";
node [shape=box, style="rounded,filled", fontname="Helvetica", fontsize=9];

D [label="Документ\nВидаткова накладна №12\n05.07.2026", fillcolor="#fff8e1", shape=note];

R1 [label="РН ТовариНаСкладах\n(Залишки)\nВитрата: 30 кг / 7 000 грн", fillcolor="#fff3e0"];
R2 [label="РН Взаєморозрахунки\n(Залишки)\nПрихід: 12 000 грн", fillcolor="#fff3e0"];
R3 [label="РН Продажі\n(Обороти)\n30 кг / 12 000 / 10 000 / 7 000", fillcolor="#fff3e0"];
R4 [label="РН ТовариВРезерві\n(Залишки)\nВитрата: 30 кг", fillcolor="#fff3e0"];
R5 [label="РБ Госпрозрахунковий\n3 проводки на 21 000", fillcolor="#fce4ec"];

T1 [label="rg_a_0012_tb\nMAXPERIOD: 80 → 50 кг", fillcolor="#ffe0b2", shape=cylinder];
T2 [label="rg_a_0013_tb\nMAXPERIOD: 0 → +12 000", fillcolor="#ffe0b2", shape=cylinder];
T3 [label="rg_a_0031_tt\n2026-07: +30 / +12 000", fillcolor="#ffe0b2", shape=cylinder];
T5 [label="rg_b_0020_tb0/tb2/tt0/tc", fillcolor="#f8bbd0", shape=cylinder];

D -> R1; D -> R2; D -> R3; D -> R4; D -> R5;
R1 -> T1; R2 -> T2; R3 -> T3; R5 -> T5;

label="ОДНА транзакція БД: усі 5 регістрів + підсумки + прапорець Проведений";
labelloc=b; fontname="Helvetica"; fontsize=10;
}
</graphviz>

<syntaxhighlight lang="python">
class ВидатковаНакладна(Document):
"""Проведення по 5 регістрах в одній транзакції. Бюджет Python: <= 15 мс (АП-4)."""

def on_posting(self, ctx: PostingContext) -> None:
# --- 0. Блокування перед контролем залишків ---
with DataLock() as dl:
li = dl.add("РегістрНакопичення.ТовариНаСкладах.Залишки")
li.mode = DataLockMode.EXCLUSIVE
li.data_source = self.Товари.unload("Номенклатура", "Характеристика")
li.use_from_data_source("Номенклатура", "Номенклатура")
li.use_from_data_source("Характеристика", "Характеристика")
li.set_value("Склад", self.Склад)

self._movements_goods() # 1. ТовариНаСкладах
self._movements_ar() # 2. Взаєморозрахунки
self._movements_sales() # 3. Продажі
self._movements_reserve() # 4. ТовариВРезерві
self._movements_accounting() # 5. Госпрозрахунковий

self.movements.ТовариНаСкладах.write_now()
self._control_negative_balances(ctx)

# --- 1. РН ТовариНаСкладах: списання ---
def _movements_goods(self) -> None:
rs = self.movements.ТовариНаСкладах
rs.write = True
rs.clear()
rs.extend(
rs.new(Період=self.Дата,
ВидРуху=AccumulationMovementType.EXPENSE,
Номенклатура=r.Номенклатура, Характеристика=r.Характеристика,
Склад=self.Склад, Партія=r.Партія,
Кількість=r.Кількість, Сума=r.Собівартість)
for r in self.Товари
)

# --- 2. РН Взаєморозрахунки: дебіторка зростає ---
def _movements_ar(self) -> None:
rs = self.movements.ВзаєморозрахункиЗКонтрагентами
rs.write = True
rs.clear()
rs.append(rs.new(
Період=self.Дата,
ВидРуху=AccumulationMovementType.RECEIPT, # Прихід = борг зростає
Організація=self.Організація, Контрагент=self.Контрагент,
Договір=self.Договір, Замовлення=self.ЗамовленняПокупця,
Сума=self.СумаДокумента, СумаВал=self.СумаДокументаВал,
))

# --- 3. РН Продажі: оборот (ВидРуху відсутній!) ---
def _movements_sales(self) -> None:
rs = self.movements.Продажі
rs.write = True
rs.clear()
rs.extend(
rs.new(Період=self.Дата,
Номенклатура=r.Номенклатура, Контрагент=self.Контрагент,
Договір=self.Договір, Менеджер=self.Менеджер, Склад=self.Склад,
Кількість=r.Кількість, Сума=r.Сума,
СумаБезПДВ=r.СумаБезПДВ, Собівартість=r.Собівартість)
for r in self.Товари
)

# --- 4. РН ТовариВРезерві: зняття резерву ---
def _movements_reserve(self) -> None:
if self.ЗамовленняПокупця.is_empty():
return
rs = self.movements.ТовариВРезерві
rs.write = True
rs.clear()
rs.extend(
rs.new(Період=self.Дата, ВидРуху=AccumulationMovementType.EXPENSE,
Номенклатура=r.Номенклатура, Характеристика=r.Характеристика,
Склад=self.Склад, Замовлення=self.ЗамовленняПокупця,
Кількість=r.Кількість)
for r in self.Товари
)

# --- 5. РБ Госпрозрахунковий: 3 проводки на рядок ---
def _movements_accounting(self) -> None:
rs = self.movements.Госпрозрахунковий
rs.write = True
rs.clear()
for r in self.Товари:
e1 = rs.add_accounting_entry( # Дт 361 / Кт 702
Період=self.Дата, Організація=self.Організація,
РахунокДт=Accounts["361"], РахунокКт=Accounts["702"],
Сума=r.Сума, КількістьКт=r.Кількість)
e1.subconto_dt[ВидиСубконто.Контрагенти] = self.Контрагент
e1.subconto_dt[ВидиСубконто.Договори] = self.Договір
e1.subconto_kt[ВидиСубконто.Номенклатура] = r.Номенклатура

e2 = rs.add_accounting_entry( # Дт 702 / Кт 641 (ПДВ)
Період=self.Дата, Організація=self.Організація,
РахунокДт=Accounts["702"], РахунокКт=Accounts["641"],
Сума=r.СумаПДВ)
e2.subconto_dt[ВидиСубконто.Номенклатура] = r.Номенклатура
e2.subconto_kt[ВидиСубконто.ПодаткиІЗбори] = Taxes.ПДВ

e3 = rs.add_accounting_entry( # Дт 902 / Кт 281
Період=self.Дата, Організація=self.Організація,
РахунокДт=Accounts["902"], РахунокКт=Accounts["281"],
Сума=r.Собівартість,
КількістьДт=r.Кількість, КількістьКт=r.Кількість)
e3.subconto_dt[ВидиСубконто.Номенклатура] = r.Номенклатура
e3.subconto_kt[ВидиСубконто.Номенклатура] = r.Номенклатура
e3.subconto_kt[ВидиСубконто.Склади] = self.Склад
</syntaxhighlight>

'''Що відбувається у БД (одна транзакція):'''
{| class="wikitable"
! Крок !! Таблиця !! Операція !! Рядків
|-
| 1 || <code>doc_0003</code> || UPDATE posted = true || 1
|-
| 2 || <code>rg_a_0012</code> (ТовариНаСкладах) || DELETE + INSERT || 1
|-
| 3 || <code>rg_a_0012_tb</code> || MERGE (MAXPERIOD + періоди > 07.2026) || 2
|-
| 4 || <code>rg_a_0013</code> (Взаєморозрахунки) || DELETE + INSERT || 1
|-
| 5 || <code>rg_a_0013_tb</code> || MERGE || 2
|-
| 6 || <code>rg_a_0031</code> (Продажі) || DELETE + INSERT || 1
|-
| 7 || <code>rg_a_0031_tt</code> || MERGE (тільки період 2026-07) || 1
|-
| 8 || <code>rg_a_0031_ag1</code> || MERGE (realtime-агрегат) || 1
|-
| 9 || <code>rg_a_0014</code> (Резерв) || DELETE + INSERT || 1
|-
| 10 || <code>rg_b_0020</code> (проводки) || DELETE + INSERT || 3
|-
| 11 || <code>rg_b_0020_tb0</code> || MERGE || 10
|-
| 12 || <code>rg_b_0020_tb1/tb2</code> || MERGE || 8
|-
| 13 || <code>rg_b_0020_tt0..tt2</code> || MERGE || 12
|-
| 14 || <code>rg_b_0020_tc</code> || MERGE || 3
|-
| colspan="3" | '''Разом''' || '''≈ 47 рядків, 1 COMMIT'''
|}

{{Note|'''Спостереження для НФВ-04.''' Один рядок товару в накладній породжує ~47 модифікацій рядків у 14 таблицях. Для накладної зі 100 рядків це ~2 000–4 000 модифікацій. Саме тут — основне навантаження проведення, і саме тому РБ (кроки 10–14) дає ~70 % вартості транзакції. Це аргумент на користь MVP без РБ (розділ 14) і предмет вимірювання в НТ-03.}}

=== Д.9. Наскрізний приклад: розрахунок зарплати ===

<pre>
КРОК 1. Документ «Нарахування зарплати» за липень 2026, Іваненко.
Записуємо рухи в РР ОсновніНарахування (Результат = 0).

КРОК 2. Платформа автоматично будує фактичні періоди дії (rg_c_0040_ap):
Оклад → [01.07–09.07], [23.07–31.07]
Відпустка → [10.07–13.07]
Лікарняний → [14.07–22.07]

КРОК 3. Розрахунок «первинних» видів (без бази) — Оклад.
Запит до ДаніГрафіка:
НормаДнів = 23 (робочих днів у липні за П'ятиденкою)
ВідпрацьованоДнів = 13 (робочі дні у фактичних періодах дії)
Результат = 18 000 × 13 / 23 = 10 173,91
→ UPDATE rg_c_0040 SET r1 = 10173.91, r2 = 13, r3 = 23 WHERE line_no = 1

КРОК 4. Розрахунок видів із базою — Відпустка, Лікарняний.
Запит до БазаРозрахунку (базовий період 01.01–30.06, база = Оклад+Премія):
Заробіток за 6 міс. = 115 560,00
Календарних днів = 181
Середньоденний = 638,45
Відпустка: 638,45 × 4 дні (10–13.07) = 2 553,80
Лікарняний: 638,45 × 9 днів × 100 % = 5 746,05
→ UPDATE rg_c_0040 SET r1 = ... WHERE line_no IN (2, 3)

КРОК 5. Записуємо рухи в РР Утримання (базовий період = період реєстрації, липень).
База ПДФО = 10 173,91 + 2 553,80 + 5 746,05 = 18 473,76
ПДФО = 18 473,76 × 18 % = 3 325,28
ВЗ = 18 473,76 × 1,5 % = 277,11

КРОК 6. Проведення документа → рухи в:
РН ВитратиЗаСтаттями (Обороти): Стаття «ЗП і нарахування» = 18 473,76
РБ Госпрозрахунковий: Дт 92 / Кт 661 = 18 473,76
Дт 661 / Кт 641.ПДФО = 3 325,28
Дт 661 / Кт 642.ВЗ = 277,11

КРОК 7. Через тиждень бухгалтер змінює Оклад Іваненка за червень (заднім числом).
→ Платформа реєструє в rg_c_0040_rc1 (ПерерахунокЗаБазою):
(Реєстратор = НарахуванняЗП липня, ВидРозрахунку = Відпустка, Співробітник = Іваненко)
(Реєстратор = НарахуванняЗП липня, ВидРозрахунку = Лікарняний, Співробітник = Іваненко)
→ Звіт «Документи до перерахунку» показує липневий документ.
→ Бухгалтер перепроводить → база перераховується → записи перерахунку очищаються.
</pre>

=== Д.10. Антипатерни проєктування регістрів ===

{| class="wikitable"
! ID !! Антипатерн !! Чому погано !! Як правильно
|-
| '''А-1''' || Дата як '''вимірювання''' у РН (замість стандартного <code>Період</code>) || Таблиця підсумків множиться на кількість дат і зростає нескінченно; віртуальні таблиці <code>Залишки</code>/<code>Обороти</code> ігнорують це вимірювання і дають безглузді результати || Використовувати стандартний реквізит <code>Період</code>. Виняток — календарі (Д.3.4), де це РВ, а не РН
|-
| '''А-2''' || РН «Залишки» там, де потрібна лише історія значення || Надлишкові таблиці підсумків, кумулятивні оновлення, вид руху без сенсу || РВ періодичний
|-
| '''А-3''' || РН «Залишки» там, де залишок безглуздий (Продажі, Витрати) || Удвічі більший обсяг підсумків, кумулятивні MERGE на всі майбутні періоди || РН «Обороти» + агрегати (Д.5.1)
|-
| '''А-4''' || Реквізит документа продубльовано у вимірювання «щоб фільтрувати у звіті» || Кардинальність підсумків × N; типовий випадок — Менеджер/Валюта/Коментар || Реквізит регістру + з'єднання з документом у звіті; або окремий регістр «Обороти»
|-
| '''А-5''' || > 8 вимірювань в одному РН || Таблиця підсумків стає '''більшою''' за таблицю рухів; проведення сповільнюється в рази || Розділити на регістри за призначенням; частину аналітики — в «Обороти» з агрегатами
|-
| '''А-6''' || Незалежний РВ «у межах секунди» як журнал подій || Два записи в ту саму секунду → другий '''мовчки замістить''' перший; втрата даних || Підпорядкований РВ (реєстратор у ключі) або додати вимірювання-дискримінатор
|-
| '''А-7''' || Ресурс типу <code>Рядок</code>/<code>Посилання</code> у РН || Підсумовування неможливе; підсумки не побудуються || Реквізит (не агрегується) або вимірювання (якщо це розріз)
|-
| '''А-8''' || Прямий <code>UPDATE</code> таблиці підсумків із прикладного коду || Розсинхронізація підсумків і рухів; діагностика — тижні || Тільки через набори записів. Заборона на рівні прав БД (розділ 12.2)
|-
| '''А-9''' || Один «універсальний» регістр із вимірюванням <code>ВидОбліку</code> (БУ/ПУ/УО) замість трьох || Втричі більша таблиця; конкуренція за блокування між незалежними обліками; неможливо окремо перерахувати підсумки || Окремі регістри. Виняток — РБ <code>ПодатковийОблік</code> (Д.6.2), де ВидРізниці — це справді розріз одного обліку
|-
| '''А-10''' || Функціонально залежне поле як вимірювання (Валюта при БанківськомуРахунку) || Надлишковість; ризик неузгоджених даних; зайвий розмір ключа підсумків || З'єднання з довідником у запиті (Д.4.4)
|-
| '''А-11''' || РБ там, де достатньо РН || Замість 1 таблиці — 10; ~70 % вартості проведення (Д.8); складність субконто без потреби || РН. РБ — лише коли потрібні план рахунків, подвійний запис і кореспонденції
|-
| '''А-12''' || Вимірювання з <code>nullable</code> без потреби || Порожнє посилання — окреме значення ключа; підсумки «розмазуються» на два рядки замість одного || <code>denyEmpty: true</code> скрізь, де порожнє значення не має сенсу
|-
| '''А-13''' || Контроль залишків '''до''' запису рухів || Класична гонитва: два сеанси проходять контроль і обидва списують у мінус || Спершу <code>DataLock</code> → <code>WriteNow()</code> → потім контроль (Д.8, ФТ-Т-12)
|-
| '''А-14''' || <code>periodicity: WithinSecond</code> «про всяк випадок» скрізь || Для РВ — неможливість замістити запис за день; для РН — марна точність, більші індекси || Обирати мінімально достатню: день для цін/курсів/виписок, секунда — для складських рухів
|-
| '''А-15'''<br />''(Python)'' || Запис рухів у циклі: <code>for r in Товари: rs.add(...).write()</code> || Порушення АП-1: 100 round-trip'ів замість 1; проведення 300 мс → ~10 с. Невидиме на тестових даних, катастрофічне на продуктиві. Найчастіша помилка при ORM-мисленні || Наповнити набір повністю (<code>rs.extend(генератор)</code>), записати один раз. Детектор — Додаток Е.7
|-
| '''А-16'''<br />''(Python)'' || Агрегація дельт підсумків у Python (<code>defaultdict</code> + цикл) замість <code>MERGE</code> || Порушення АП-2: дані ганяються в застосунок і назад; на 10<sup>5</sup> рядків — десятки секунд || <code>INSERT … ON CONFLICT DO UPDATE</code> одним запитом (Е.3)
|}

=== Д.11. Чек-лист рев'ю нового регістру ===

<pre>
□ Тип регістру обґрунтований за деревом Д.1
□ Кожне вимірювання використовується у фільтрі АБО групуванні звітів
□ Кожен ресурс має сенс при підсумовуванні
□ Немає полів з антипатернів А-1, А-4, А-7, А-10, А-12
□ Оцінка кардинальності підсумків ≤ 10^8 (калькулятор конструктора, ФТ-К-03)
□ Для вимірювань, де порожнє значення безглузде, стоїть denyEmpty
□ Ведучі (master) вимірювання визначені — інакше «висячі» записи при видаленні об'єктів
□ Склад реєстраторів повний; зайвих типів документів немає
□ Угода про знак / вид руху зафіксована в методологічній документації
□ Періодичність мінімально достатня (А-14)
□ Для РН «Обороти» з >4 вимірюваннями визначено ≥1 агрегат
□ Для РБ: балансові/небалансові вимірювання та ресурси розставлені свідомо
□ Для РР: витісняючі та базові види розрахунку в ПВР заповнені; перерахунки визначені
□ Партиціонування ввімкнене, якщо очікується >100 млн записів
□ Написано тест на проведення + скасування + перерахунок підсумків
</pre>

== Додаток Е. Ескізи реалізації ядра на Python ==

Додаток демонструє, що метамодель розділу 6 і фізична модель розділу 8 реалізовні обраним стеком (розділ 4.3), і фіксує ключові технічні рішення для етапів Е1, Е3, Е5, Е7, Е11. Код — ілюстративний ескіз, а не остаточний API.

=== Е.1. Маніфест регістру як Pydantic-модель (етап Е1) ===

YAML-декларації розділу 6.7 і Додатка Д валідуються цією моделлю. Це '''безпосередньо реалізує ФТ-К-01''' (валідація в реальному часі) і частину контролю антипатернів Д.10.

<syntaxhighlight lang="python">
from __future__ import annotations

import warnings
from enum import StrEnum
from typing import Annotated, Literal, Self

from pydantic import BaseModel, ConfigDict, Field, model_validator

IDENT = r"^[^\W\d]\w{0,79}$" # Unicode-ідентифікатор (кирилиця дозволена), <= 80 симв.

class RegisterKind(StrEnum):
INFORMATION = "Information"
ACCUMULATION = "Accumulation"
ACCOUNTING = "Accounting"
CALCULATION = "Calculation"

class Periodicity(StrEnum):
NONPERIODICAL = "Nonperiodical"
WITHIN_SECOND = "WithinSecond"
WITHIN_DAY = "WithinDay"
WITHIN_MONTH = "WithinMonth"
WITHIN_QUARTER = "WithinQuarter"
WITHIN_YEAR = "WithinYear"
BY_RECORDER_POSITION = "ByRecorderPosition"

class WriteMode(StrEnum):
INDEPENDENT = "Independent"
SUBORDINATE = "SubordinateToRecorder"

class FieldRole(StrEnum):
DIMENSION = "Dimension"
RESOURCE = "Resource"
ATTRIBUTE = "Attribute"

class RegisterField(BaseModel):
model_config = ConfigDict(extra="forbid", frozen=True)

name: Annotated[str, Field(pattern=IDENT)]
role: FieldRole
type: str | list[str] # "Довідник.Номенклатура" | ["Документ.А", "Документ.Б"]
synonym: str | None = None
index: bool = False
master: bool = False # «Ведуче»
deny_empty: bool = False
nullable: bool = False
use_in_totals: bool = True
# РБ
balance: bool = False
accounting_flag: str | None = None
# РР
base_dimension: bool = False

@property
def is_composite(self) -> bool:
return isinstance(self.type, list) and len(self.type) > 1

class Register(BaseModel):
model_config = ConfigDict(extra="forbid")

name: Annotated[str, Field(pattern=IDENT)]
kind: RegisterKind
synonym: str | None = None
periodicity: Periodicity = Periodicity.NONPERIODICAL
write_mode: WriteMode = WriteMode.SUBORDINATE
dimensions: list[RegisterField] = []
resources: list[RegisterField] = []
attributes: list[RegisterField] = []
recorders: list[str] = []
# РН
accumulation_kind: Literal["Balance", "Turnover"] | None = None
enable_balance_totals: bool = True
enable_turnover_totals: bool = False
turnover_totals_period: Literal["Day", "Month"] | None = None
# РБ
chart_of_accounts: str | None = None
correspondence: bool = True
max_extdim_count: Annotated[int, Field(ge=0, le=5)] = 3
# РР
calculation_types_plan: str | None = None
action_period: bool = False
base_period: Literal["None", "ByActionPeriod", "ByRegistrationPeriod"] = "None"

# ---------- крос-полева валідація (розділи 6.2–6.6) ----------
@model_validator(mode="after")
def _validate(self) -> Self:
if self.write_mode is WriteMode.INDEPENDENT and self.kind is not RegisterKind.INFORMATION:
raise ValueError("Незалежний режим запису дозволено лише для регістру відомостей")

if self.kind is RegisterKind.ACCUMULATION:
if self.accumulation_kind is None:
raise ValueError("Для регістру накопичення обов'язковий accumulation_kind")
if self.periodicity is Periodicity.NONPERIODICAL:
raise ValueError("Регістр накопичення не може бути неперіодичним")
if self.accumulation_kind == "Turnover" and self.enable_balance_totals:
raise ValueError("Підсумки залишків несумісні з видом «Обороти»")

if self.kind is RegisterKind.ACCOUNTING and not self.chart_of_accounts:
raise ValueError("Для регістру бухгалтерії обов'язковий chart_of_accounts")

if self.kind is RegisterKind.CALCULATION:
if not self.calculation_types_plan:
raise ValueError("Для регістру розрахунку обов'язковий calculation_types_plan")
if not any(f.base_dimension for f in self.dimensions) and self.base_period != "None":
raise ValueError("Задано base_period, але жодне вимірювання не позначене base_dimension")

# ресурс має бути підсумовуваним (антипатерн А-7)
if self.kind is not RegisterKind.INFORMATION:
for r in self.resources:
if not _is_numeric(r.type):
raise ValueError(f"Ресурс «{r.name}»: тип {r.type} не підсумовується (А-7). "
f"Використайте роль Attribute або Dimension")

# обмеження розділу 6.6
if len(self.dimensions) > 20:
raise ValueError(f"Вимірювань {len(self.dimensions)} > 20 (розділ 6.6)")

# попередження (ФТ-К-01: warnings, а не помилки)
if len(self.dimensions) > 8:
warnings.warn(f"«{self.name}»: {len(self.dimensions)} вимірювань — "
f"ризик розростання таблиці підсумків (антипатерн А-5)")
for d in self.dimensions:
if d.type == "Дата" and self.kind is RegisterKind.ACCUMULATION:
warnings.warn(f"«{self.name}.{d.name}»: Дата як вимірювання РН — антипатерн А-1")
return self
</syntaxhighlight>

'''Що це дає безкоштовно:''' валідацію YAML, JSON Schema для web-конструктора (<code>Register.model_json_schema()</code>), типізовані об'єкти для генератора DDL, детальні повідомлення про помилки з шляхом до поля.

=== Е.2. Генератор DDL на SQLAlchemy Core (етап Е1) ===

<syntaxhighlight lang="python">
from collections.abc import Callable, Sequence

from sqlalchemy import (Boolean, Column, DateTime, Index, Integer, MetaData, Numeric,
PrimaryKeyConstraint, SmallInteger, String, Table, Uuid, text)
from sqlalchemy.types import TypeEngine

PRIMITIVE: dict[str, Callable[[RegisterField], TypeEngine]] = {
"Число": lambda f: Numeric(f.precision, f.scale),
"Рядок": lambda f: String(f.length),
"Дата": lambda f: DateTime(timezone=False),
"Булево": lambda f: Boolean(),
"УНІ": lambda f: Uuid(),
}

def columns_for_field(f: RegisterField, prefix: str) -> list[Column]:
"""Одне поле метаданих -> 1..6 фізичних колонок (розділ 8.2)."""
if f.is_composite: # складений тип: розділ 8.2.2
return [
Column(f"{prefix}_t", SmallInteger, nullable=False),
Column(f"{prefix}_b", Boolean),
Column(f"{prefix}_n", Numeric(38, 10)),
Column(f"{prefix}_s", String(f.max_string_len)),
Column(f"{prefix}_d", DateTime),
Column(f"{prefix}_r", Uuid),
]
if f.is_reference: # просте посилання
return [Column(f"{prefix}_r", Uuid, nullable=f.nullable)]
base = f.base_type
return [Column(prefix, PRIMITIVE[base](f), nullable=f.nullable)]

def build_movement_table(reg: Register, md: MetaData) -> Table:
"""Метаопис -> Table. Розділи 8.4–8.7."""
cols: list[Column] = []

if reg.write_mode is WriteMode.SUBORDINATE:
cols += [
Column("rec_t", SmallInteger, nullable=False),
Column("rec_r", Uuid, nullable=False),
Column("line_no", Integer, nullable=False),
Column("active", Boolean, nullable=False, server_default=text("true")),
]
if reg.periodicity is not Periodicity.NONPERIODICAL:
cols.append(Column("period", DateTime, nullable=False))
if reg.kind is RegisterKind.ACCUMULATION and reg.accumulation_kind == "Balance":
cols.append(Column("mvt", SmallInteger, nullable=False)) # ВидРуху
if reg.kind is RegisterKind.CALCULATION:
cols += [Column("calc_type_r", Uuid, nullable=False),
Column("reversal", Boolean, nullable=False, server_default=text("false"))]
if reg.action_period:
cols += [Column("act_begin", DateTime, nullable=False),
Column("act_end", DateTime, nullable=False)]
if reg.base_period != "None":
cols += [Column("base_begin", DateTime), Column("base_end", DateTime)]

for f in reg.all_fields: # dimensions + resources + attributes
cols += columns_for_field(f, reg.column_prefix(f)) # 'd3', 'r1', 'a2'

t = Table(reg.physical_table, md, *cols,
PrimaryKeyConstraint(*primary_key_columns(reg),
name=f"pk_{reg.physical_table}"),
postgresql_partition_by=partition_clause(reg))

for f in reg.dimensions:
if f.index:
Index(f"ix_{reg.physical_table}_{reg.column_prefix(f)}",
*index_columns(reg, f),
postgresql_where=t.c.active if "active" in t.c else None)
return t
</syntaxhighlight>

'''НФВ-16 / НФВ-17 (дві СКБД, ізольований шар діалекту) — у три рядки:'''

<syntaxhighlight lang="python">
from sqlalchemy.dialects import mssql, postgresql
from sqlalchemy.schema import CreateTable

md = MetaData()
t = build_movement_table(reg_goods, md)

print(CreateTable(t).compile(dialect=postgresql.dialect())) # -> CREATE TABLE rg_a_0012 (...)
print(CreateTable(t).compile(dialect=mssql.dialect())) # -> той самий об'єкт у T-SQL
</syntaxhighlight>

{{Note|'''Це і є головний аргумент на користь Python у цьому проєкті.''' SQLAlchemy Core — фактично готовий «шар діалекту СКБД» (НФВ-17) і модель схеми, які в C#/Delphi довелося б писати самостійно. Разом із Alembic (Е10) і Pydantic (Е.1) це знімає ~1,5 чол.-міс. з етапів Е1 і Е10 (розділ 14.1).}}

'''Реалізація ФТ-К-02''' («Показати SQL» у конструкторі) — той самий виклик <code>CreateTable(t).compile(...)</code>, виведений у UI.

=== Е.3. Інкрементальне оновлення підсумків (етап Е3) ===

Реалізація алгоритму 10.2 з дотриманням АП-1 (один запит на весь набір) і ФТ-34 (детермінований порядок проти дедлоків).

<syntaxhighlight lang="python">
from operator import itemgetter
from collections.abc import Sequence

from sqlalchemy import Connection, Table
from sqlalchemy.dialects.postgresql import insert as pg_insert

def merge_totals(conn: Connection, totals: Table, rows: list[dict],
key: Sequence[str], res: Sequence[str]) -> None:
"""АП-1 + АП-2: одна операція на весь набір дельт; складання виконує СКБД."""
if not rows:
return

rows.sort(key=itemgetter(*key)) # ФТ-34: детермінований порядок -> без дедлоків

stmt = pg_insert(totals).values(rows)
stmt = stmt.on_conflict_do_update(
index_elements=list(key),
set_={r: totals.c[r] + stmt.excluded[r] for r in res}, # r1 = t.r1 + EXCLUDED.r1
)
conn.execute(stmt) # 1 round-trip незалежно від len(rows)
</syntaxhighlight>

'''Для MS SQL''' — той самий інтерфейс, інша реалізація (<code>MERGE ... WHEN MATCHED THEN UPDATE</code>) за діалектним диспетчером. Ізоляція — на рівні функції, прикладний код не знає про діалект.

'''Чому НЕ ORM:''' ORM-варіант (<code>session.merge(obj)</code> у циклі) дав би <code>len(rows)</code> round-trip'ів — пряме порушення АП-1 і зростання НФВ-04 на два порядки. Саме тому ORM заборонений у розділі 4.3.

=== Е.4. Транслятор віртуальних таблиць (етап Е5) ===

<syntaxhighlight lang="python">
from functools import lru_cache

from lark import Lark, Transformer
from sqlalchemy import Select, func, literal, select, union_all

GRAMMAR = r"""
?query : "ВИБРАТИ"i select_list "З"i source [where] [group_by] [order_by]
source : virtual_table | plain_table
virtual_table : REGISTER_PATH "." VT_NAME "(" [vt_args] ")" ["ЯК"i alias]
VT_NAME : "Залишки"i | "Обороти"i | "ЗалишкиІОбороти"i
| "ЗрізОстанніх"i | "ЗрізПерших"i | "ОборотиДтКт"i
| "ДаніГрафіка"i | "ФактичнийПеріодДії"i | "БазаРозрахунку"i
vt_args : (expr | ) ("," (expr | ))* // позиційні, можуть бути порожні
...
"""

class QueryCompiler:
def __init__(self, schema: SchemaRegistry) -> None:
self._parser = Lark(GRAMMAR, parser="lalr", start="query")
self._schema = schema

@lru_cache(maxsize=2048) # АП-4: кеш скомпільованих запитів
def compile(self, text: str, param_signature: tuple[str, ...]) -> Select:
tree = self._parser.parse(text)
return _ToSQLAlchemy(self._schema).transform(tree)

def balances(self, reg: Register, period, conditions: list) -> Select:
"""Реалізація алгоритму 10.3 в термінах SQLAlchemy Core."""
tb = self._schema.totals_balance(reg)
mv = self._schema.movements(reg)
dims = [tb.c[c] for c in self._schema.dimension_columns(reg)]

boundary = (select(func.coalesce(func.max(tb.c.period), MIN_PERIOD))
.where(tb.c.period <= period)
.scalar_subquery())

base = (select(*dims, *[func.sum(tb.c[r]).label(r) for r in reg.resource_columns])
.where(tb.c.period == boundary, *conditions) # ФТ-13: push-down
.group_by(*dims))

signed = lambda c: case((mv.c.mvt == 0, mv.c[c]), else_=-mv.c[c])
tail = (select(*[mv.c[d.name] for d in dims],
*[func.sum(signed(r)).label(r) for r in reg.resource_columns])
.where(mv.c.active, mv.c.period > boundary, mv.c.period <= period, *conditions)
.group_by(*[mv.c[d.name] for d in dims]))

u = union_all(base, tail).subquery()
return (select(*[u.c[d.name] for d in dims],
*[func.sum(u.c[r]).label(f"{r}Залишок") for r in reg.resource_columns])
.group_by(*[u.c[d.name] for d in dims])
.having(or_(*[func.sum(u.c[r]) != 0 for r in reg.resource_columns])))
</syntaxhighlight>

'''Ризик Р1 (немає мови запитів) на Python пом'якшується:''' навіть якщо повноцінна мова запитів не буде реалізована в Е5, <code>QueryCompiler.balances()</code> залишається придатним як програмний API — прикладний код викликає його напряму й отримує <code>Select</code>, який можна далі з'єднувати засобами SQLAlchemy Core. Це '''план «Б»''' для Р1, недоступний у мовах без подібної бібліотеки.

=== Е.5. Витіснення: гарячий шлях за інтерфейсом (етапи Е7, Е11) ===

Реалізація принципу АП-3 на найризикованішому вузлі (Р5 + Р10).

<syntaxhighlight lang="python">
from collections import defaultdict
from collections.abc import Callable, Sequence
from datetime import date, timedelta
from typing import Protocol
from uuid import UUID

Interval = tuple[date, date]
ONE_DAY = timedelta(days=1)

class DisplacementEngine(Protocol):
"""АП-3. Бюджет (АП-4): <= 3 c на 10 тис. ключів × ~10 записів."""

def compute(self,
records: Sequence[CalcRecord],
displaces: Callable[[UUID, UUID], bool]) -> dict[RecordKey, list[Interval]]:
"""Повертає фактичні періоди дії для кожного запису (розділ 10.4)."""
...

def subtract(intervals: list[Interval], cut: Interval) -> list[Interval]:
"""Різниця множин інтервалів. Найгарячіша функція платформи."""
out: list[Interval] = []
cb, ce = cut
for b, e in intervals:
if ce < b or cb > e: # не перетинаються
out.append((b, e))
continue
if b < cb:
out.append((b, cb - ONE_DAY)) # «хвіст» зліва
if e > ce:
out.append((ce + ONE_DAY, e)) # «хвіст» справа
return out

class PyDisplacementEngine:
"""Еталонна реалізація. Заміна на Cython/Rust не змінює виклик (АП-3)."""

def compute(self, records, displaces):
by_key: dict[DimKey, list[CalcRecord]] = defaultdict(list)
for r in records:
if r.active:
by_key[r.dim_key].append(r)

result: dict[RecordKey, list[Interval]] = {}
for Z in by_key.values():
if len(Z) > 500: # розділ 10.4: перехід на sweep-line
result |= SweepLineEngine().compute(Z, displaces)
continue
Z.sort(key=lambda r: (r.priority, r.period, r.line_no))
for z in Z:
intervals = [(z.act_begin, z.act_end)]
for w in Z:
if w is z or not displaces(w.calc_type, z.calc_type):
continue
if not _registration_periods_intersect(w, z):
continue
intervals = subtract(intervals, (w.act_begin, w.act_end))
if not intervals:
break # повністю витіснений
result[z.key] = intervals
return result
</syntaxhighlight>

'''Property-based тести (мітигація Р5 — найпомилковішого вузла):'''

<syntaxhighlight lang="python">
from hypothesis import given
from hypothesis import strategies as st

dates = st.dates(min_value=date(2020, 1, 1), max_value=date(2030, 12, 31))
intervals = st.lists(st.tuples(dates, dates).map(lambda t: tuple(sorted(t))), max_size=20)

@given(ivs=intervals, cut=st.tuples(dates, dates).map(lambda t: tuple(sorted(t))))
def test_subtract_invariants(ivs: list[Interval], cut: Interval) -> None:
out = subtract(ivs, cut)
assert all(b <= e for b, e in out), "некоректні межі"
assert not any(_overlaps(i, cut) for i in out), "витіснений інтервал залишився"
# збереження міри: те, що прибрали, дорівнює перетину з cut
assert _measure(out) + _measure(_intersect_all(ivs, cut)) == _measure(ivs)
</syntaxhighlight>

'''Бенчмарк як блокер приймання (АП-4):'''

<syntaxhighlight lang="python">
@pytest.mark.benchmark(group="displacement")
def test_displacement_budget(benchmark, records_10k_keys) -> None:
"""Вводиться в CI з етапу Е7. Перевищення бюджету -> червоний білд."""
benchmark(PyDisplacementEngine().compute, records_10k_keys, displaces)
assert benchmark.stats.stats.mean < 3.0, (
f"Порушено бюджет АП-4: {benchmark.stats.stats.mean:.2f} c > 3.0 c. "
f"Розгляньте sweep-line, Cython або перенесення у SQL (daterange + GiST)."
)
</syntaxhighlight>

=== Е.6. Генерація <code>.pyi</code>-стабів (ФТ-К-07, етап Е1) ===

'''Проблема:''' поля регістру доступні динамічно (<code>rs.new(Номенклатура=…)</code>), тому <code>mypy</code> не бачить одруків і помилок типів — це і є ризик Р11.

'''Рішення:''' конструктор генерує стаби з метаопису при кожній зміні конфігурації.

<syntaxhighlight lang="python">
# k2/generated/registers/ТовариНаСкладах.pyi -- АВТОЗГЕНЕРОВАНО. Не редагувати.
from datetime import datetime
from decimal import Decimal

from k2.catalogs import Номенклатура, Склади, ХарактеристикиНоменклатури
from k2.documents import ПрихіднаНакладна, ВведенняЗалишків
from k2.registers import AccumulationMovementType, Record, RecordSet

class ТовариНаСкладахRecord(Record):
Період: datetime
ВидРуху: AccumulationMovementType
Номенклатура: Номенклатура
Склад: Склади
Характеристика: ХарактеристикиНоменклатури | None
Партія: ПрихіднаНакладна | ВведенняЗалишків | None # складений тип
Кількість: Decimal
Сума: Decimal
Коментар: str

class ТовариНаСкладахRecordSet(RecordSet[ТовариНаСкладахRecord]):
def new(self, *, Період: datetime, ВидРуху: AccumulationMovementType,
Номенклатура: Номенклатура, Склад: Склади,
Характеристика: ХарактеристикиНоменклатури | None = None,
Партія: ПрихіднаНакладна | ВведенняЗалишків | None = None,
Кількість: Decimal = ..., Сума: Decimal = ...,
Коментар: str = ...) -> ТовариНаСкладахRecord: ...
</syntaxhighlight>

'''Що це ловить у CI ще до запуску:'''
{| class="wikitable"
! Помилка прикладного коду !! Без стабів !! Зі стабами
|-
| <code>rs.new(Номенклатур=x)</code> — одрук у назві поля || Виняток у рантаймі при проведенні на продуктиві || <code>mypy</code>: unexpected keyword argument
|-
| <code>m.Кількість = "багато"</code> || <code>InvalidOperation</code> при записі в БД || <code>mypy</code>: incompatible type <code>str</code>, expected <code>Decimal</code>
|-
| <code>m.Склад = номенклатура</code> — переплутані посилання || FK-помилка або, гірше, тихо неправильні дані || <code>mypy</code>: incompatible type
|-
| Видалили вимірювання з метаданих, код лишився || Виняток при проведенні || Червоний білд одразу після зміни конфігурації
|}

'''Автодоповнення в IDE''' — приємний побічний ефект, який частково компенсує відсутність повноцінного конфігуратора рівня 1С на ранніх етапах.

=== Е.7. Автоматичний детектор порушень АП-1 (етап Е3, CI) ===

Принцип АП-1 марний без механічної перевірки — розробник порушить його ненавмисно.

<syntaxhighlight lang="python">
# tests/architecture/test_ap1_no_row_by_row.py

@pytest.mark.parametrize("scenario", POSTING_SCENARIOS)
def test_roundtrips_do_not_scale_with_rows(db_counter, scenario) -> None:
"""АП-1: кількість звернень до СКБД НЕ залежить від кількості рядків документа."""
with db_counter() as c10:
scenario.build(rows=10).post()
with db_counter() as c100:
scenario.build(rows=100).post()

assert c100.roundtrips <= c10.roundtrips + 2, (
f"{scenario.name}: звернень до БД зросло {c10.roundtrips} -> {c100.roundtrips} "
f"при зростанні рядків у 10 разів. Порушення АП-1 — див. розділ 4.4."
)

class RowByRowGuard:
"""Runtime-запобіжник для dev/staging: виняток при >N однакових запитів у транзакції."""

def __init__(self, threshold: int = 20) -> None:
self._counts: Counter[str] = Counter()
self._threshold = threshold

def before_execute(self, conn, clauseelement, *args) -> None:
fingerprint = _statement_fingerprint(clauseelement) # SQL без літералів
self._counts[fingerprint] += 1
if self._counts[fingerprint] == self._threshold:
raise ArchitectureViolation(
f"Один і той самий запит виконано {self._threshold} разів у межах транзакції.\n"
f"Ймовірне порушення АП-1 («жодного рядка за раз»).\n{fingerprint}"
)
</syntaxhighlight>

'''Це — найдешевша страховка проєкту.''' Порушення АП-1 не видно на тестових даних (10 рядків — усе швидко) і катастрофічне на продуктиві (100 рядків × 5 регістрів). Детектор вводиться '''з етапу Е3''', а не за результатами НТ-03.

=== Е.8. Структура репозиторію ядра ===

<pre>
k2-registers/
├── src/k2/
│ ├── metadata/ # Е.1: Pydantic-моделі, репозиторій, валідація
│ │ ├── models.py # Register, RegisterField, ...
│ │ ├── repository.py # md_* таблиці
│ │ └── validators.py # ФТ-К-01, антипатерни Д.10
│ ├── schema/ # Е.2: генерація DDL
│ │ ├── builder.py # метаопис -> SQLAlchemy Table
│ │ ├── dialects/ # НФВ-17: postgres.py, mssql.py
│ │ └── restructure.py # Е10: Alembic-інтеграція
│ ├── runtime/ # набори записів, проведення, блокування
│ │ ├── recordset.py
│ │ ├── posting.py # розділ 7.1
│ │ ├── totals.py # Е.3: merge_totals
│ │ └── locks.py # ФТ-32
│ ├── query/ # Е.4: lark-граматика + компілятор
│ │ ├── grammar.lark
│ │ ├── compiler.py
│ │ └── virtual/ # balances.py, turnovers.py, slices.py, calc_base.py
│ ├── calculation/ # Е.5: витіснення (гарячий шлях)
│ │ ├── protocols.py # DisplacementEngine
│ │ ├── engine_py.py # еталонна реалізація
│ │ └── engine_native/ # [резерв] Cython/Rust — тільки за результатом бенчмарку
│ ├── codegen/ # Е.6: генерація .pyi-стабів
│ └── diagnostics/ # Е.7: RowByRowGuard, перевірка цілісності (ФТ-41)
├── tests/
│ ├── unit/
│ ├── property/ # hypothesis: інтервальна арифметика (Р5)
│ ├── architecture/ # Е.7: детектор АП-1
│ ├── benchmarks/ # АП-4: бюджети гарячих шляхів (gate у CI)
│ └── integration/ # testcontainers: PostgreSQL + MS SQL (Р7)
└── pyproject.toml # uv, ruff, mypy --strict
</pre>

----
''Кінець документа. Версія 1.2. Підлягає узгодженню з архітектором платформи K2 ERP до затвердження.''

Регістри в K2 ERP

2026-07-17T19:04:46Z

{{DISPLAYTITLE:ТЗ. Підсистема регістрів K2 ERP}}
__TOC__

= 1. Паспорт документа =

{| class="wikitable"
! Атрибут !! Значення
|-
| Назва || Технічне завдання на розробку підсистеми «Регістри» платформи K2 ERP
|-
| Шифр || K2-ERP-TZ-REG-001
|-
| Версія || 1.1 (чернетка на узгодження; +Додаток Д «Каталог прикладів»)
|-
| Статус || На розгляді
|-
| Замовник || ''[підрозділ-замовник]''
|-
| Виконавець || ''[команда платформи K2 ERP]''
|-
| Тип документа || Технічне завдання (ГОСТ 34.602 адаптовано)
|-
| Аналог / прототип || Механізм регістрів платформи «1С:Підприємство 8.3»
|-
| Мова розробки || ''[уточнити: C#/.NET | Delphi | Java]''
|-
| СКБД || PostgreSQL 14+ (основна), MS SQL Server 2019+ (додаткова)
|}

== 1.1. Необхідні розширення MediaWiki для перегляду ==

Документ використовує теги діаграм. Для коректного рендерингу потрібні:
* <code>Extension:GraphViz</code> — тег <code><nowiki><graphviz></nowiki></code>
* <code>Extension:PlantUML</code> — тег <code><nowiki><plantuml></nowiki></code>
* <code>Extension:SyntaxHighlight_GeSHi</code> — тег <code><nowiki><syntaxhighlight></nowiki></code>

Також використовується шаблон <code><nowiki>{{Note|текст}}</nowiki></code>. Якщо його немає у вашій вікі — створіть сторінку <code>Template:Note</code> з вмістом:
<pre>
<div style="border-left:4px solid #36c; background:#eaf3ff; padding:8px 12px; margin:8px 0;">
'''ⓘ''' {{{1}}}
</div>
</pre>

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

= 2. Терміни, визначення та скорочення =

{| class="wikitable"
! Термін !! Визначення
|-
| '''Регістр''' || Об'єкт метаданих, призначений для зберігання та накопичення структурованої облікової інформації у вигляді записів фіксованої структури, з механізмами агрегації, зрізів і транзакційного зв'язку з документами-реєстраторами.
|-
| '''РВ''' || Регістр відомостей (аналог «Регистр сведений»).
|-
| '''РН''' || Регістр накопичення (аналог «Регистр накопления»).
|-
| '''РБ''' || Регістр бухгалтерії (аналог «Регистр бухгалтерии»).
|-
| '''РР''' || Регістр розрахунку (аналог «Регистр расчёта»).
|-
| '''Вимірювання''' (Dimension) || Поле регістру, що визначає розріз аналітики; входить у ключ запису/підсумку.
|-
| '''Ресурс''' (Resource) || Поле регістру, значення якого підсумовується (для РН/РБ/РР) або зберігається як значення (для РВ).
|-
| '''Реквізит''' (Attribute) || Довідкове поле запису, що не бере участі в ключі та не агрегується.
|-
| '''Реєстратор''' (Recorder) || Документ, який породив набір записів регістру та володіє ним.
|-
| '''Рухи''' (Movements) || Записи регістру, підпорядковані конкретному реєстратору.
|-
| '''Набір записів''' (RecordSet) || Прикладний об'єкт для читання/запису групи записів регістру за заданим відбором.
|-
| '''Підсумки''' (Totals) || Попередньо розраховані агрегати (залишки/обороти), що зберігаються в окремих таблицях.
|-
| '''ТА''' || Точка актуальності підсумків — момент часу, до якого підсумки розраховані.
|-
| '''Зріз останніх''' (SliceLast) || Вибірка останніх за періодом записів РВ у розрізі кожної комбінації вимірювань.
|-
| '''Субконто''' (ExtDimension, ED) || Додатковий розріз аналітики бухгалтерського рахунку.
|-
| '''ПВР''' || План видів розрахунку.
|-
| '''Витіснення''' || Механізм РР: запис із вищим пріоритетом скорочує фактичний період дії запису з нижчим.
|-
| '''Перерахунок''' (Recalculation) || Підпорядкований РР об'єкт, що реєструє записи, які потребують повторного розрахунку.
|-
| '''Віртуальна таблиця''' || Обчислювана таблиця в мові запитів, що не має фізичного відповідника (Залишки, Обороти, ЗрізОстанніх тощо).
|}

= 3. Призначення, цілі та підстава розробки =

== 3.1. Підстава ==
Поточна модель K2 ERP не має уніфікованого декларативного механізму накопичувального обліку. Регістроподібні структури реалізуються ''ad hoc'' — окремими таблицями та процедурами під кожну прикладну задачу, що спричиняє:
* дублювання коду розрахунку залишків та оборотів;
* відсутність гарантованої узгодженості «документ ↔ рухи»;
* деградацію продуктивності на великих обсягах (повний перерахунок з початку обліку);
* високу вартість введення нової аналітики (зміна схеми БД + правка десятків процедур).

== 3.2. Мета ==
Створити в K2 ERP підсистему '''декларативно описуваних регістрів''' чотирьох типів, функціонально еквівалентну механізму регістрів «1С:Підприємство 8.3», з автоматичною генерацією схеми БД, підтримкою підсумків, віртуальних таблиць у мові запитів і транзакційного проведення документів.

== 3.3. Цілі проєкту (вимірювані) ==
{| class="wikitable"
! № !! Ціль !! Критерій досягнення
|-
| Ц1 || Декларативне визначення регістру || Новий регістр з 5 вимірюваннями та 3 ресурсами створюється в конструкторі без написання коду; DDL генерується автоматично.
|-
| Ц2 || Автоматична агрегація || Залишки/обороти доступні запитом без ручних процедур перерахунку.
|-
| Ц3 || Продуктивність || Отримання залишків на дату за таблицею 1 млрд рухів — ≤ 200 мс (P95) на еталонному стенді.
|-
| Ц4 || Цілісність || Неможливість існування рухів без активного реєстратора (100 % сценаріїв у тесті цілісності).
|-
| Ц5 || Міграція || Перенесення ≥ 90 % наявних «регістроподібних» структур K2 на новий механізм без втрати даних.
|}

== 3.4. Що НЕ входить до обсягу (Out of scope) ==
* Механізм розподілених інформаційних баз / реплікації рухів (окреме ТЗ).
* Візуальний конструктор звітів поверх регістрів (окреме ТЗ, залежність).
* OLAP-куби та зовнішні аналітичні вітрини.
* Автоматичне перенесення прикладного коду замовника (тільки дані + мапінг).

= 4. Припущення та обмеження щодо платформи K2 ERP =

{{Note|Розділ фіксує припущення, які '''обов'язково''' підлягають верифікації з архітектором платформи до затвердження ТЗ. Місця, що потребують уточнення, позначені як ''[уточнити]''.}}

{| class="wikitable"
! № !! Припущення !! Наслідок для ТЗ
|-
| П1 || K2 ERP має підсистему метаданих із власним репозиторієм об'єктів (документи, довідники, перерахування) і механізмом версіонування конфігурації. || Регістр вбудовується як новий '''рід''' об'єкта метаданих у наявний репозиторій (розділ 6).
|-
| П2 || Об'єкти-документи мають унікальний ідентифікатор посилання (GUID/UUID) та проведення як окрему операцію. || Реєстратор адресується парою «код типу + UUID» (розділ 8.2).
|-
| П3 || Платформа має власну мову запитів або транслятор у SQL. || Віртуальні таблиці реалізуються на рівні транслятора (розділ 7.6). Якщо мови запитів немає — потрібен окремий етап Е0 (розділ 14).
|-
| П4 || Цільова СКБД підтримує <code>MERGE</code>/<code>INSERT ... ON CONFLICT</code>, віконні функції, часткові та покривні індекси. || Алгоритми підсумків (розділ 10) використовують ці можливості.
|-
| П5 || Прикладний код виконується на сервері застосунків із керованими транзакціями. || Проведення документа — одна транзакція БД (розділ 7.1).
|-
| П6 || Максимальна довжина ідентифікатора об'єкта БД — 63 символи (PostgreSQL). || Фізичні імена таблиць будуються за сурогатним числовим кодом, а не за іменем регістру (розділ 8.1).
|}

'''Обмеження:'''
* О1. Зміна складу вимірювань/ресурсів існуючого регістру — операція реструктуризації з простоєм; онлайн-міграція не гарантується для таблиць > 100 млн записів.
* О2. Підсистема не гарантує коректність прикладної логіки проведення — лише цілісність механізму.
* О3. Мінімальна дискретність періоду — 1 секунда (тип <code>timestamp(0)</code>) ''[уточнити: чи потрібна мілісекундна]''.

= 5. Класифікація регістрів =

== 5.1. Дерево типів ==

<graphviz>
digraph Registers {
rankdir=TB;
bgcolor="transparent";
node [shape=box, style="rounded,filled", fillcolor="#f5f5f5", fontname="Helvetica", fontsize=10];
edge [fontname="Helvetica", fontsize=8];

R [label="РЕГІСТР\n(абстрактний об'єкт метаданих)", fillcolor="#dbe9ff"];

RI [label="Регістр відомостей\n(РВ / Information)", fillcolor="#e8f5e9"];
RA [label="Регістр накопичення\n(РН / Accumulation)", fillcolor="#fff8e1"];
RB [label="Регістр бухгалтерії\n(РБ / Accounting)", fillcolor="#fce4ec"];
RC [label="Регістр розрахунку\n(РР / Calculation)", fillcolor="#ede7f6"];

R -> RI; R -> RA; R -> RB; R -> RC;

RI_np [label="Неперіодичний"];
RI_p [label="Періодичний"];
RI -> RI_np; RI -> RI_p;

RI_i [label="Незалежний\n(режим запису)", shape=note, fillcolor="#ffffff"];
RI_s [label="Підпорядкований\nреєстратору", shape=note, fillcolor="#ffffff"];
RI -> RI_i [style=dashed]; RI -> RI_s [style=dashed];

RA_b [label="Вид: Залишки\n(Balance)"];
RA_t [label="Вид: Обороти\n(Turnover)"];
RA -> RA_b; RA -> RA_t;

RB_c [label="З кореспонденцією\n(подвійний запис)"];
RB_n [label="Без кореспонденції\n(уніграфічний)"];
RB -> RB_c; RB -> RB_n;

RC_a [label="З періодом дії\n(+ витіснення)"];
RC_b [label="З базовим періодом\n(+ база розрахунку)"];
RC_g [label="З графіком часу"];
RC -> RC_a; RC -> RC_b; RC -> RC_g;
}
</graphviz>

== 5.2. Порівняльна матриця типів ==

{| class="wikitable"
! Характеристика !! РВ !! РН (Залишки) !! РН (Обороти) !! РБ !! РР
|-
| Ключ запису || Вимірювання (+Період) або Реєстратор+№ || Реєстратор+№ || Реєстратор+№ || Реєстратор+№ || Реєстратор+№
|-
| Незалежний запис || '''Так''' || Ні || Ні || Ні || Ні
|-
| Періодичність || Опційна || Обов'язкова (Період) || Обов'язкова || Обов'язкова || Обов'язкова
|-
| Ресурси підсумовуються || Ні || Так (±) || Так (+) || Так (Дт/Кт) || Так
|-
| Вид руху (Прихід/Витрата) || — || '''Так''' || — || Дт/Кт || —
|-
| Таблиця залишків || — || '''Так''' || — || '''Так''' || —
|-
| Таблиця оборотів || — || Так (опц.) || '''Так''' || Так || —
|-
| Зв'язок із планом рахунків || — || — || — || '''Так''' || —
|-
| Зв'язок із ПВР || — || — || — || — || '''Так'''
|-
| Період дії / витіснення || — || — || — || — || '''Так'''
|-
| Базовий період || — || — || — || — || '''Так'''
|-
| Графік часу || — || — || — || — || '''Так'''
|-
| Субконто || — || — || — || '''Так''' || —
|-
| Перерахунки || — || — || — || — || '''Так'''
|-
| Типові приклади || Курси валют, ціни, кадрова історія, графік роботи || Товари на складах, взаєморозрахунки || Продажі, витрати за статтями || Госпрозрахунковий, управлінський, податковий облік || Нарахування ЗП, утримання
|}

= 6. Метамодель: як регістр задається =

== 6.1. Місце в репозиторії метаданих ==

<pre>
Конфігурація K2 ERP
├── Довідники
├── Документи
├── Плани рахунків ← використовується РБ
├── Плани видів характеристик ← використовується як тип субконто / вимірювання
├── Плани видів розрахунку ← використовується РР
└── Регістри ◄── НОВИЙ РОЗДІЛ
├── Регістри відомостей
│ └── КурсиВалют
│ ├── Вимірювання → Валюта
│ ├── Ресурси → Курс, Кратність
│ ├── Реквізити →
│ └── Форми → ФормаСписку, ФормаЗапису
├── Регістри накопичення
│ └── ТовариНаСкладах
│ ├── Вимірювання → Номенклатура, Склад, Партія
│ ├── Ресурси → Кількість, Сума
│ ├── Реквізити → Коментар
│ └── Реєстратори → [ПрихіднаНакладна, ВидатковаНакладна, ...]
├── Регістри бухгалтерії
│ └── Госпрозрахунковий
│ ├── Вимірювання → Організація, Підрозділ(небаланс.)
│ ├── Ресурси → Сума(баланс.), Кількість(небаланс.), ВалютнаСума
│ ├── Реквізити → Зміст, № журналу
│ └── Реєстратори → [...]
└── Регістри розрахунку
└── Нарахування
├── Вимірювання → Співробітник(баз.), Підрозділ
├── Ресурси → Результат, ВідпрацьованоДнів
├── Реквізити → Графік
├── Перерахунки → ПерерахунокЗаБазою
└── Реєстратори → [НарахуванняЗП]
</pre>

== 6.2. Загальні властивості будь-якого регістру ==

{| class="wikitable"
! Властивість !! Тип !! Обов'язк. !! Опис / допустимі значення
|-
| <code>Ім'я</code> || Ідентифікатор || Так || Унікальне в межах роду. Латиниця/кирилиця, ≤ 80 симв., без пробілів.
|-
| <code>Синонім</code> || Рядок || Ні || Подання для користувача.
|-
| <code>Коментар</code> || Текст || Ні || —
|-
| <code>ВидРегістру</code> || Перелік || Так || <code>Відомостей</code> / <code>Накопичення</code> / <code>Бухгалтерії</code> / <code>Розрахунку</code>. '''Незмінна після створення.'''
|-
| <code>РежимЗапису</code> || Перелік || Так || <code>Незалежний</code> / <code>ПідпорядкованийРеєстратору</code>. Для РН/РБ/РР — примусово <code>ПідпорядкованийРеєстратору</code>.
|-
| <code>Періодичність</code> || Перелік || Так || <code>Неперіодичний</code>, <code>ВМежахСекунди</code>, <code>ВМежахДня</code>, <code>ВМежахМісяця</code>, <code>ВМежахКварталу</code>, <code>ВМежахРоку</code>, <code>ПоПозиціїРеєстратора</code>.
|-
| <code>Реєстратори</code> || Список посилань на типи документів || Умовно || Обов'язково для РН/РБ/РР та підпорядкованого РВ. Порожній список = регістр непридатний до запису.
|-
| <code>БлокуванняДаних</code> || Перелік || Ні || <code>Автоматичне</code> / <code>Кероване</code> (за замовчуванням <code>Кероване</code>).
|-
| <code>ВключатиДоЗвітів</code> || Булево || Ні || Показувати в універсальному конструкторі звітів.
|-
| <code>ПравоДоступуЗаЗамовчуванням</code> || Перелік || Ні || <code>Заборонено</code> / <code>Читання</code>.
|-
| <code>ВикористовуватиРLS</code> || Булево || Ні || Row-level security (розділ 7.9).
|-
| <code>Партиціонування</code> || Структура || Ні || <code>Немає</code> / <code>ЗаПеріодом(RANGE, крок)</code> / <code>ЗаВимірюванням(HASH, n)</code>.
|}

== 6.3. Поля регістру ==

Кожне поле має:
{| class="wikitable"
! Властивість !! Опис
|-
| <code>Ім'я</code>, <code>Синонім</code> || Ідентифікація.
|-
| <code>Роль</code> || <code>Вимірювання</code> / <code>Ресурс</code> / <code>Реквізит</code>.
|-
| <code>Тип</code> || Примітивний (<code>Число(p,s)</code>, <code>Рядок(n)</code>, <code>Дата</code>, <code>Булево</code>, <code>УНІ</code>), посилальний (<code>Довідник.X</code>, <code>Документ.Y</code>, <code>Перерахування.Z</code>, <code>ПланРахунків.A</code>, <code>ПланВидівХарактеристик.B</code>) або '''складений''' (список типів).
|-
| <code>Індексувати</code> || <code>Не індексувати</code> / <code>Індексувати</code> / <code>ІндексуватиЗДодаткомВимірювань</code>.
|-
| <code>Ведуче</code> (Master) || Тільки для вимірювань. Якщо <code>Істина</code> — записи регістру видаляються разом з об'єктом, на який посилається вимірювання; регістр показується у формі цього об'єкта.
|-
| <code>ОсновнийВідбір</code> || Брати участь у стандартному відборі форми списку.
|-
| <code>ЗаборонитиНезаповненіЗначення</code> || Валідація на запис.
|}

Специфічні прапорці полів по типах регістрів:

{| class="wikitable"
! Прапорець !! Застосовний до !! Опис
|-
| <code>Балансовий</code> || Ресурс/Вимірювання РБ || Ресурс бере участь у контролі рівності Дт=Кт; має єдине значення на запис (а не пару Дт/Кт). Вимірювання балансове — однакове для Дт і Кт.
|-
| <code>Облік</code> (AccountingFlag) || Ресурс РБ || Посилання на ознаку обліку рахунка з ПР; ресурс заповнюється, лише якщо ознака встановлена.
|-
| <code>ОблікСубконто</code> || Ресурс РБ || Посилання на ознаку обліку субконто (напр. кількісний облік у розрізі субконто).
|-
| <code>Базове</code> (BaseDimension) || Вимірювання РР || Використовується для зіставлення записів під час отримання бази розрахунку.
|-
| <code>ВикористовуватиПоточніЗначення</code> || Ресурс/Реквізит РР || —
|}

== 6.4. Специфічні властивості за типами ==

=== 6.4.1. Регістр відомостей ===
{| class="wikitable"
! Властивість !! Значення !! Примітка
|-
| <code>Періодичність</code> || Неперіодичний … ПоПозиціїРеєстратора || Визначає наявність поля <code>Період</code> і його гранулярність.
|-
| <code>РежимЗапису</code> || Незалежний / ПідпорядкованийРеєстратору || У незалежному ключ = (Період) + Вимірювання.
|-
| <code>ОсновнийВідбір</code> || —
|-
| <code>ДозволитиПідсумки</code> || — || У РВ підсумків немає; замість них — зрізи.
|}

'''Ключ унікальності:'''
* Незалежний неперіодичний: <code>UNIQUE(Вимірювання…)</code>
* Незалежний періодичний: <code>UNIQUE(Період, Вимірювання…)</code>
* Підпорядкований: <code>PK(Реєстратор, НомерРядка)</code>, унікальність за вимірюваннями '''не''' контролюється.

=== 6.4.2. Регістр накопичення ===
{| class="wikitable"
! Властивість !! Значення
|-
| <code>ВидРегістру</code> || <code>Залишки</code> / <code>Обороти</code>
|-
| <code>ДозволитиПідсумкиЗалишків</code> || Булево (тільки для виду «Залишки»)
|-
| <code>ДозволитиПідсумкиОборотів</code> || Булево
|-
| <code>ПеріодичністьПідсумківОборотів</code> || <code>День</code> / <code>Місяць</code> (тільки для виду «Обороти»)
|-
| <code>Агрегати</code> || Список визначень агрегатів (тільки для виду «Обороти»), див. 7.4.4
|-
| <code>РежимАгрегатів</code> || <code>Агрегати</code> / <code>Підсумки</code>
|}

=== 6.4.3. Регістр бухгалтерії ===
{| class="wikitable"
! Властивість !! Значення !! Примітка
|-
| <code>ПланРахунків</code> || Посилання на об'єкт «План рахунків» || '''Обов'язково.''' Незмінне після створення.
|-
| <code>Кореспонденція</code> || Булево || <code>Істина</code> → подвійний запис (поля <code>РахунокДт</code>/<code>РахунокКт</code>); <code>Хиба</code> → уніграфічний (<code>Рахунок</code> + <code>ВидРуху</code>).
|-
| <code>ДозволитиРозділенняПідсумків</code> || Булево
|-
| <code>МаксКількістьСубконто</code> || Число (успадковується з ПР) || Ліміт платформи: 5 ''[узгодити; 1С — 3 за замовчуванням, до 5]''
|}

Пов'язаний об'єкт '''План рахунків''' повинен підтримувати:
* ієрархію рахунків, <code>Код</code>, <code>Найменування</code>, <code>Вид</code> (Активний/Пасивний/Активно-пасивний);
* <code>Забалансовий</code> (булево);
* <code>Ознаки обліку</code> (набір булевих реквізитів, напр. «Кількісний», «Валютний»);
* табличну частину <code>ВидиСубконто</code> (ВидСубконто → ПВХ, ''Тільки обороти'', ''Підсумкова сума'', ознаки обліку субконто);
* <code>МаксКількістьСубконто</code>.

=== 6.4.4. Регістр розрахунку ===
{| class="wikitable"
! Властивість !! Значення !! Примітка
|-
| <code>ПланВидівРозрахунку</code> || Посилання || '''Обов'язково.'''
|-
| <code>Періодичність</code> || <code>День</code>/<code>Місяць</code>/<code>Квартал</code>/<code>Рік</code> || Період реєстрації.
|-
| <code>ПеріодДії</code> || Булево || Вмикає поля <code>ПеріодДіїПочаток/Кінець</code>, фактичні періоди дії та витіснення.
|-
| <code>БазовийПеріод</code> || <code>БезБазовогоПеріоду</code> / <code>ЗаПеріодДії</code> / <code>ЗаПеріодРеєстрації</code> || Режим отримання бази.
|-
| <code>Графік</code> || Посилання на РВ || Регістр-графік часу.
|-
| <code>ЗначенняГрафіка</code> || Ресурс регістру-графіка || Напр. «Значення» (1/0 — робочий день) або «Годин».
|-
| <code>ДатаГрафіка</code> || Вимірювання регістру-графіка типу <code>Дата</code> || —
|-
| <code>Перерахунки</code> || Список підпорядкованих об'єктів «Перерахунок» || Див. 7.5.3.
|}

Об'єкт '''Перерахунок''' (підпорядкований РР):
* <code>Ім'я</code>;
* <code>Вимірювання</code> — список, кожне зіставляється з вимірюванням основного РР (<code>ВимірюванняРегістру</code>);
* правило: перерахунок реєструє «об'єкт перерахунку» = (Реєстратор, ВидРозрахунку, Вимірювання…).

'''План видів розрахунку''' повинен підтримувати:
* <code>ВикористовуєПеріодДії</code>;
* табличні частини <code>БазовіВидиРозрахунку</code>, <code>ВитісняючіВидиРозрахунку</code>, <code>ВедучіВидиРозрахунку</code>;
* <code>ЗалежністьВідБази</code>: <code>НеЗалежить</code> / <code>ЗаПеріодДії</code> / <code>ЗаПеріодРеєстрації</code>.

== 6.5. Стандартні реквізити (генеруються автоматично) ==

{| class="wikitable"
! Реквізит !! РВ !! РН !! РБ !! РР !! Тип
|-
| <code>Період</code> || якщо періодичний || + || + || + (період реєстрації) || Дата/час
|-
| <code>Реєстратор</code> || якщо підпорядкований || + || + || + || Складене посилання (ДокументПосилання)
|-
| <code>НомерРядка</code> || якщо підпорядкований || + || + || + || Число(9,0)
|-
| <code>Активність</code> || якщо підпорядкований || + || + || + || Булево
|-
| <code>ВидРуху</code> || — || тільки «Залишки» || — || — || Перелік {Прихід, Витрата}
|-
| <code>Рахунок</code> || — || — || + (без кореспонденції) || — || ПланРахунківПосилання
|-
| <code>РахунокДт</code>, <code>РахунокКт</code> || — || — || + (з кореспонденцією) || — || ПланРахунківПосилання
|-
| <code>ВидРухуРахунку</code> || — || — || + (без кореспонденції) || — || Перелік {Дебет, Кредит}
|-
| <code>Субконто</code> (колекція) || — || — || + || — || Відповідність(ВидСубконто→Значення)
|-
| <code>ВидРозрахунку</code> || — || — || — || + || ПВРПосилання
|-
| <code>ПеріодДіїПочаток</code>, <code>ПеріодДіїКінець</code> || — || — || — || + (якщо ПеріодДії) || Дата
|-
| <code>БазовийПеріодПочаток</code>, <code>БазовийПеріодКінець</code> || — || — || — || + (якщо БазовийПеріод) || Дата
|-
| <code>Сторно</code> || — || — || — || + || Булево
|}

== 6.6. Кількісні обмеження метамоделі ==

{| class="wikitable"
! Параметр !! Ліміт !! Примітка
|-
| Кількість вимірювань || 20 || Понад 8 — попередження конструктора (деградація підсумків)
|-
| Кількість ресурсів || 20 ||
|-
| Кількість реквізитів || 30 ||
|-
| Кількість типів у складеному типі поля || 32 ||
|-
| Кількість реєстраторів || Не обмежено ||
|-
| Максимум субконто на рахунок || 5 ||
|-
| Довжина ключа підсумків || ≤ 900 байт (обмеження індексу MS SQL) || Валідація в конструкторі
|-
| Глибина періодичності підсумків || День / Місяць || Тиждень/Квартал — не підтримуються (обчислюються згортанням)
|}

== 6.7. Декларативний опис (DSL) ==

Регістр зберігається в репозиторії у вигляді XML/YAML-маніфесту. Приклад:

<syntaxhighlight lang="yaml">
# --- Регістр накопичення (вид: Залишки) ---
register:
name: ТовариНаСкладах
kind: Accumulation
accumulationKind: Balance
synonym: "Товари на складах"
periodicity: WithinSecond
writeMode: SubordinateToRecorder
enableBalanceTotals: true
enableTurnoverTotals: true
partitioning: { mode: RangeByPeriod, step: month }

dimensions:
- { name: Номенклатура, type: "Довідник.Номенклатура", master: true, index: true }
- { name: Склад, type: "Довідник.Склади", master: true, index: true }
- { name: Партія, type: ["Документ.ПрихіднаНакладна", "Документ.ВведенняЗалишків"], index: false }
- { name: Характеристика, type: "ПланВидівХарактеристик.Характеристики", nullable: true }

resources:
- { name: Кількість, type: "Число(15,3)" }
- { name: Сума, type: "Число(15,2)" }

attributes:
- { name: Коментар, type: "Рядок(200)" }

recorders:
- Документ.ПрихіднаНакладна
- Документ.ВидатковаНакладна
- Документ.ПереміщенняТоварів
- Документ.Інвентаризація
</syntaxhighlight>

<syntaxhighlight lang="yaml">
# --- Регістр відомостей (періодичний, незалежний) ---
register:
name: КурсиВалют
kind: Information
periodicity: WithinDay
writeMode: Independent
dimensions:
- { name: Валюта, type: "Довідник.Валюти", master: true }
resources:
- { name: Курс, type: "Число(15,4)" }
- { name: Кратність, type: "Число(10,0)", default: 1 }
</syntaxhighlight>

<syntaxhighlight lang="yaml">
# --- Регістр бухгалтерії ---
register:
name: Госпрозрахунковий
kind: Accounting
chartOfAccounts: ПланРахунків.Госпрозрахунковий
correspondence: true
periodicity: WithinSecond
dimensions:
- { name: Організація, type: "Довідник.Організації", balance: true }
- { name: Підрозділ, type: "Довідник.Підрозділи", balance: false }
resources:
- { name: Сума, type: "Число(15,2)", balance: true }
- { name: Кількість, type: "Число(15,3)", balance: false, accountingFlag: Кількісний }
- { name: ВалютнаСума, type: "Число(15,2)", balance: false, accountingFlag: Валютний }
attributes:
- { name: Зміст, type: "Рядок(255)" }
- { name: Валюта, type: "Довідник.Валюти" }
recorders: [Документ.БухгалтерськаОперація, Документ.ПрихіднаНакладна]
</syntaxhighlight>

<syntaxhighlight lang="yaml">
# --- Регістр розрахунку ---
register:
name: Нарахування
kind: Calculation
calculationTypesPlan: ПланВидівРозрахунку.ОсновніНарахування
periodicity: Month
actionPeriod: true
basePeriod: ByActionPeriod
schedule:
register: РегістрВідомостей.ГрафікРоботи
valueResource: Значення
dateDimension: ДатаГрафіка
dimensions:
- { name: Співробітник, type: "Довідник.Співробітники", baseDimension: true, master: true }
- { name: Підрозділ, type: "Довідник.Підрозділи" }
resources:
- { name: Результат, type: "Число(15,2)" }
- { name: ВідпрацьованоДнів, type: "Число(5,0)" }
- { name: НормаДнів, type: "Число(5,0)" }
recalculations:
- name: ПерерахунокЗаБазою
dimensions:
- { name: Співробітник, registerDimension: Співробітник }
recorders: [Документ.НарахуванняЗарплати]
</syntaxhighlight>

{{Note|Розширений каталог із 17 прикладів регістрів усіх типів і підвидів — з деклараціями, даними у фізичних таблицях, запитами, наскрізними сценаріями та антипатернами — див. '''Додаток Д'''.}}

== 6.8. UI конструктора метаданих ==

=== 6.8.1. Загальний макет ===
<pre>
┌─ Конфігуратор K2 ERP ─────────────────────────────────────────────────────────┐
│ Файл Правка Конфігурація Адміністрування Сервіс Довідка │
├──────────────────────┬────────────────────────────────────────────────────────┤
│ Дерево конфігурації │ Регістр накопичення: ТовариНаСкладах │
│ │ ┌──────┬─────────┬──────────┬──────────┬───────────┐ │
│ ▾ Регістри │ │Основ.│Дані │Реєстратор│Форми │Права │ │
│ ▸ відомостей │ └──────┴─────────┴──────────┴──────────┴───────────┘ │
│ ▾ накопичення │ │
│ ▾ ТовариНаСклад. │ Ім'я [ТовариНаСкладах.............] │
│ ▾ Вимірювання │ Синонім [Товари на складах...........] │
│ Номенклат. │ Коментар [.............................] │
│ Склад │ │
│ Партія │ Вид регістру ( ) Обороти (•) Залишки │
│ ▾ Ресурси │ Періодичність [ У межах секунди ▾] │
│ Кількість │ Режим запису [ Підпорядкований реєстратору ▾] │
│ Сума │ │
│ ▸ Реквізити │ ☑ Дозволити підсумки залишків │
│ ▸ Форми │ ☑ Дозволити підсумки оборотів │
│ ▸ Взаєморозрах. │ Періодичність підсумків оборотів [Місяць ▾] │
│ ▸ бухгалтерії │ ☐ Дозволити розділення підсумків │
│ ▸ розрахунку │ │
│ │ Блокування даних [Кероване ▾] │
│ │ Партиціонування [За періодом, крок: місяць ▾] │
│ │ │
│ │ [ Конструктор рухів... ] [ Перевірити ] [ Закрити ] │
├──────────────────────┴────────────────────────────────────────────────────────┤
│ ⚠ Попередження: 4 вимірювання + місячні підсумки → оцінка таблиці підсумків │
│ ~ 12 млн записів/рік. Розгляньте виключення вимірювання «Партія» з підсумків.│
└───────────────────────────────────────────────────────────────────────────────┘
</pre>

=== 6.8.2. Палітра властивостей поля ===
<pre>
┌─ Властивості: Вимірювання «Партія» ────────────────┐
│ Ім'я [Партія...................] │
│ Синонім [Партія...................] │
│ Тип [Складений тип........ [...]]│
│ ├ Документ.ПрихіднаНакладна │
│ └ Документ.ВведенняЗалишків │
│ Індексувати [Не індексувати ▾] │
│ ☐ Ведуче │
│ ☐ Основний відбір │
│ ☐ Заборонити незаповнені значення │
│ ☑ Використовувати в підсумках │
│ Подання │
│ Підказка [Партія товару...........] │
└────────────────────────────────────────────────────┘
</pre>

=== 6.8.3. Вкладка «Реєстратори» ===
<pre>
┌─ ТовариНаСкладах → Реєстратори ────────────────────────────┐
│ ☑ Документ.ПрихіднаНакладна │
│ ☑ Документ.ВидатковаНакладна │
│ ☑ Документ.ПереміщенняТоварів │
│ ☑ Документ.Інвентаризація │
│ ☐ Документ.Замовлення │
│ ☐ Документ.РахунокНаОплату │
│ [Позначити всі] [Зняти]│
│ ───────────────────────────────────────────────────────── │
│ ⓘ Знімання прапорця для документа, що має рухи, вимагає │
│ очищення рухів. Знайдено рухів: 0 │
└────────────────────────────────────────────────────────────┘
</pre>

=== 6.8.4. Вимоги до конструктора ===
* ФТ-К-01. Валідація метаопису в реальному часі з переліком помилок/попереджень.
* ФТ-К-02. Попередній перегляд згенерованого DDL (кнопка «Показати SQL»).
* ФТ-К-03. Калькулятор оцінки обсягу таблиць підсумків (добуток кардинальностей вимірювань × кількість періодів).
* ФТ-К-04. Заборона неприпустимих комбінацій (напр. «Незалежний» + «Регістр накопичення»).
* ФТ-К-05. «Конструктор рухів» — генерація коду формування рухів за табличною частиною документа.
* ФТ-К-06. Порівняння/об'єднання конфігурацій має коректно обробляти об'єкти-регістри.

= 7. Функціональні вимоги =

== 7.1. Набір записів і проведення документа ==

'''ФТ-01.''' Платформа надає прикладний об'єкт <code>НабірЗаписів</code> для кожного регістру з властивостями: <code>Відбір</code>, <code>Записувати</code>, і методами <code>Прочитати()</code>, <code>Записати(Заміщати)</code>, <code>Очистити()</code>, <code>ЗаблокуватиДляЗміни()</code>, <code>Вивантажити()</code>, <code>Завантажити()</code>.

'''ФТ-02.''' Для документа доступна колекція <code>Рухи</code> з наборами записів усіх регістрів, де документ вказано реєстратором.

'''ФТ-03. Сценарій проведення:'''

<plantuml>
@startuml
skinparam monochrome false
skinparam shadowing false
actor Користувач
participant "Форма\nдокумента" as UI
participant "Об'єкт\nДокумент" as Doc
participant "Менеджер\nпроведення" as PM
participant "Набори\nзаписів" as RS
database "СКБД" as DB

Користувач -> UI: Провести
UI -> Doc: Записати(РежимЗапису.Проведення)
activate Doc
Doc -> PM: НачатьТранзакцию()
PM -> DB: BEGIN
Doc -> Doc: ПередЗаписью()
Doc -> DB: UPDATE doc SET Проведений=1
Doc -> Doc: ОбработкаПроведения(Отказ, Режим)
note right of Doc
Прикладний код:
Рухи.ТовариНаСкладах.Записувати = Істина;
Рух = Рухи.ТовариНаСкладах.Добавить();
Рух.ВидРуху = ВидРухуНакопичення.Витрата;
...
// контроль залишків (оперативне проведення)
end note
Doc -> RS: (формування рухів у пам'яті)
Doc -> PM: ЗаписатьДвижения()
PM -> RS: для кожного НЗ з Записувати=Істина
RS -> DB: DELETE FROM rg_a_0012 WHERE rec_ref = :doc
RS -> DB: INSERT INTO rg_a_0012 (...) VALUES (...)
RS -> PM: ОновитиПідсумки(delta)
PM -> DB: MERGE rg_a_0012_tb (див. розд. 10.2)
Doc -> Doc: ПриЗаписи() / ПослеЗаписи()
alt Відмова = Хиба
PM -> DB: COMMIT
PM --> UI: Успіх
else Відмова = Істина або виключення
PM -> DB: ROLLBACK
PM --> UI: Помилка "Документ не проведено: ..."
end
deactivate Doc
@enduml
</plantuml>

'''ФТ-04.''' Запис набору записів у режимі <code>Заміщати = Істина</code> (за замовчуванням для рухів) виконує <code>DELETE</code> усіх записів за відбором + <code>INSERT</code> нових — атомарно.

'''ФТ-05.''' Скасування проведення документа: усі набори записів за реєстратором очищуються, підсумки коригуються, документ отримує <code>Проведений = Хиба</code>.

'''ФТ-06.''' Видалення документа-реєстратора (у т.ч. позначеного на видалення) '''зобов'язане''' каскадно видалити всі його рухи в межах однієї транзакції. Реалізація — на рівні платформи (не FK, оскільки посилання поліморфне) + фонова перевірка цілісності (розділ 7.10).

'''ФТ-07.''' Режими проведення:
{| class="wikitable"
! Режим !! Умова !! Поведінка
|-
| '''Оперативне''' || Дата документа = поточна дата, документ у межах «оперативної точки» || Дозволено контроль залишків «на зараз»; дата може перепризначатися на поточну.
|-
| '''Неоперативне''' || Дата в минулому/майбутньому або документ перепроводиться || Контроль залишків виконується на дату документа; можливий негативний залишок за налаштуванням.
|}

== 7.2. Активність записів ==
'''ФТ-08.''' Реквізит <code>Активність = Хиба</code> означає, що запис фізично існує, але '''не''' впливає на підсумки та не потрапляє до віртуальних таблиць.
'''ФТ-09.''' Зміна активності будь-якого запису тягне коригування підсумків.
'''ФТ-10.''' Скасування проведення документа переводить усі його записи в <code>Активність = Хиба</code> '''або''' видаляє їх — залежно від налаштування регістру <code>ПоведінкаПриСкасуванні</code> (<code>Видаляти</code> — за замовчуванням / <code>Деактивувати</code>).

== 7.3. Віртуальні таблиці ==

'''ФТ-11.''' Мова запитів надає для кожного регістру набір віртуальних таблиць. Транслятор перетворює звернення до них на SQL із використанням таблиць підсумків та «живих» рухів після ТА.

{| class="wikitable"
! Регістр !! Віртуальна таблиця !! Параметри !! Повертає
|-
| rowspan="3" | '''РВ''' || <code>ЗрізОстанніх</code> || (Період, Умова) || Останній запис на кожну комбінацію вимірювань з періодом ≤ Період
|-
| <code>ЗрізПерших</code> || (Період, Умова) || Перший запис з періодом ≥ Період
|-
| ''(основна)'' || — || Усі записи
|-
| rowspan="4" | '''РН.Залишки''' || <code>Залишки</code> || (Період, Умова) || Вимірювання + <code><Ресурс>Залишок</code>
|-
| <code>Обороти</code> || (Початок, Кінець, Періодичність, Умова) || <code><Ресурс>Прихід</code>, <code><Ресурс>Витрата</code>, <code><Ресурс>Оборот</code>
|-
| <code>ЗалишкиІОбороти</code> || (Початок, Кінець, Періодичність, МетодДоповнення, Умова) || <code><Р>ПочатковийЗалишок</code>, <code><Р>Прихід</code>, <code><Р>Витрата</code>, <code><Р>Оборот</code>, <code><Р>КінцевийЗалишок</code>
|-
| ''(основна)'' || — || Рухи
|-
| '''РН.Обороти''' || <code>Обороти</code> || (Початок, Кінець, Періодичність, Умова) || <code><Ресурс>Оборот</code>
|-
| rowspan="6" | '''РБ''' || <code>Залишки</code> || (Період, УмоваРахунку, Субконто, Умова) || <code><Р>Залишок</code>, <code><Р>ЗалишокДт</code>, <code><Р>ЗалишокКт</code>
|-
| <code>Обороти</code> || (Початок, Кінець, Періодичність, УмоваРахунку, Субконто, Умова, УмоваКорРахунку, КорСубконто) || <code><Р>Оборот</code>, <code><Р>ОборотДт</code>, <code><Р>ОборотКт</code>
|-
| <code>ЗалишкиІОбороти</code> || (…) || Повний набір
|-
| <code>ОборотиДтКт</code> || (Початок, Кінець, Періодичність, УмоваРахункуДт, СубконтоДт, УмоваРахункуКт, СубконтоКт) || Кореспонденції
|-
| <code>ДвиженияССубконто</code> || (Початок, Кінець, УмоваРахунку, Субконто, Умова) || Рухи з розшифровкою субконто
|-
| <code>Субконто</code> || (Умова, Порядок…) || Значення субконто записів
|-
| rowspan="4" | '''РР''' || <code>ДаніГрафіка</code> || (Умова) || <code>ЗначенняПеріодуДії</code>, <code>ЗначенняПеріодуРеєстрації</code>, <code>ЗначенняБазовогоПеріоду</code>, <code>ЗначенняФактичногоПеріодуДії</code>
|-
| <code>ФактичнийПеріодДії</code> || (Умова) || Записи з фактичними (після витіснення) межами
|-
| <code>БазаРозрахунку</code> || (ВимірюванняБази, ВимірюванняОсновногоРегістру, Розрізи, ВидиРозрахунку, Умова) || Агреговані значення ресурсів базових видів розрахунку
|-
| ''(основна)'' || — || Рухи
|}

'''ФТ-12.''' Приклад запиту:
<syntaxhighlight lang="sql">
ВИБРАТИ
Залишки.Номенклатура,
Залишки.Склад,
Залишки.КількістьЗалишок,
Обороти.КількістьПрихід,
Обороти.КількістьВитрата
З
РегістрНакопичення.ТовариНаСкладах.ЗалишкиІОбороти(
&ПочатокПеріоду,
&КінецьПеріоду,
Місяць,
Рух,
Склад = &Склад
І Номенклатура В ІЄРАРХІЇ (&ГрупаНоменклатури)
) ЯК Залишки
</syntaxhighlight>

'''ФТ-13.''' Параметри віртуальних таблиць '''зобов'язані''' транслюватися у <code>WHERE</code> підзапиту до звернення до підсумків (push-down), а не фільтруватися після агрегації.

== 7.4. Підсумки ==

=== 7.4.1. Модель підсумків залишків ===
Таблиця залишків зберігає '''кумулятивний залишок на початок кожного періоду''' + спеціальний рядок «підсумок за всі періоди» з <code>period = '5999-11-01'</code> (маркер MAXPERIOD).

<pre>
Таблиця підсумків (місячна) ТА
┌────┬────┬────┬────┬────┐ ▼
─────┬────┬────┬───┴────┴────┴────┴────┴────┴────────────────────┬──────────►
│ │ │ 01.10 01.11 01.12 01.01 01.02 15.02 t
│ │ │ ● ● ● ● ●
│ │ │ бал. бал. бал. бал. бал.
└─ «живі» рухи ─┘
(сканування)
Залишок на 10.02 = Підсумок(01.02) + Σ рухів (01.02 … 10.02]
Залишок на 20.02 = Підсумок(01.02) + Σ рухів (01.02 … 20.02] // після ТА — теж
</pre>

'''ФТ-14.''' Регламентна операція «Перерахунок підсумків» перебудовує таблиці підсумків з нуля.
'''ФТ-15.''' Регламентна операція «Встановлення періоду розрахунку підсумків» переносить ТА вперед/назад.
'''ФТ-16.''' При записі рухів раніше ТА підсумки коригуються ''інкрементально'' (див. 10.2), без повного перерахунку.

=== 7.4.2. Розділення підсумків ===
'''ФТ-17.''' За увімкненого <code>ДозволитиРозділенняПідсумків</code> у таблиці підсумків додається колонка <code>splitter smallint</code>. Одночасні транзакції пишуть у різні «сплітери», що усуває конкуренцію за рядок. Читання агрегує по всіх сплітерах. Регламентне завдання зливає сплітери.

=== 7.4.3. Обороти ===
'''ФТ-18.''' Таблиця оборотів зберігає агрегати за календарний період (день або місяць — за налаштуванням), без кумуляції.

=== 7.4.4. Агрегати (тільки РН виду «Обороти») ===
'''ФТ-19.''' Агрегат — додаткова матеріалізована таблиця з підмножиною вимірювань і власною періодичністю (День/Місяць/Квартал/Рік). Оптимізатор запитів обирає найдешевший агрегат, що покриває запит.
'''ФТ-20.''' Режими: <code>Реальний час</code> (оновлюється при записі рухів) / <code>Регламентний</code> (оновлюється завданням; запит враховує рухи після дати актуальності агрегату).
'''ФТ-21.''' «Порадник агрегатів» аналізує статистику запитів і пропонує склад агрегатів (<code>ВизначитиОптимальніАгрегати()</code>).

== 7.5. Механіка регістру розрахунку ==

=== 7.5.1. Витіснення за періодом дії ===
'''ФТ-22.''' Якщо у ПВР для виду розрахунку A вказано B у складі «Витісняючі види розрахунку», то запис виду B скорочує фактичний період дії запису виду A на інтервал перетину.

<pre>
Період реєстрації: Січень 2026. Пріоритет витіснення: Лікарняний > Відпустка > Оклад

Заявлені періоди дії:
Оклад 01.01 ├══════════════════════════════════════════════┤ 31.01
Відпустка 10.01 ├════════════┤ 17.01
Лікарняний 14.01 ├════════════┤ 22.01

Фактичні періоди дії (rg_c_XXXX_ap):
Оклад 01.01 ├═══════┤ 09.01 23.01 ├════════════┤ 31.01
Відпустка 10.01 ├═══┤ 13.01
Лікарняний 14.01 ├════════════┤ 22.01

⇒ у таблиці фактичних періодів «Оклад» породжує ДВА інтервали (запис — один).
</pre>

'''ФТ-23.''' Фактичні періоди дії матеріалізуються у службовій таблиці <code>rg_c_<код>_ap</code> під час запису набору записів.
'''ФТ-24.''' Витіснення обчислюється в межах збігу '''усіх''' вимірювань регістру та перетину періодів реєстрації, визначених ПВР.

=== 7.5.2. Базовий період і база розрахунку ===
'''ФТ-25.''' Віртуальна таблиця <code>БазаРозрахунку</code> повертає суму ресурсів записів базових видів розрахунку, зіставлених за базовими вимірюваннями, з урахуванням режиму <code>ЗалежністьВідБази</code>:
* <code>ЗаПеріодДії</code> — беруться записи, чий '''період дії''' перетинається з базовим періодом поточного запису; результат пропорційно розподіляється за часткою перетину (за графіком, якщо заданий);
* <code>ЗаПеріодРеєстрації</code> — беруться записи, чий '''період реєстрації''' потрапляє в базовий період.

=== 7.5.3. Перерахунки ===
'''ФТ-26.''' При записі/зміні/видаленні запису базового виду розрахунку платформа '''автоматично''' формує записи у таблиці перерахунку для всіх залежних записів (за збігом вимірювань перерахунку та потраплянням у базовий період).
'''ФТ-27.''' Прикладний код читає перерахунок як набір записів, перепроводить відповідні документи та очищує оброблені записи.
'''ФТ-28.''' Перерахунок доступний як об'єкт для звіту «Документи до перерахунку».

=== 7.5.4. Графік часу ===
'''ФТ-29.''' Графік — це РВ з обов'язковим вимірюванням типу <code>Дата</code> та числовим ресурсом. Віртуальна таблиця <code>ДаніГрафіка</code> повертає суму значень графіка за відповідний період (дії / реєстрації / базовий / фактичний період дії).
'''ФТ-30.''' Якщо у графіку є додаткові вимірювання (напр. <code>ВидГрафіка</code>), вони зіставляються з однойменними реквізитами/вимірюваннями РР.

== 7.6. Прикладний API ==

<syntaxhighlight lang="csharp">
// --- Регістр відомостей: незалежний запис ---
var mgr = Registers.Information["КурсиВалют"];

// точковий запис
var rec = mgr.CreateRecordManager();
rec.Період = new DateTime(2026, 7, 17);
rec.Валюта = usd;
rec.Курс = 41.85m;
rec.Кратність = 1;
rec.Write(replace: true); // INSERT ... ON CONFLICT DO UPDATE

// зріз останніх
var slice = mgr.GetLast(DateTime.Today, new Filter { ["Валюта"] = usd });
decimal курс = slice.Курс;

// --- Регістр накопичення: рухи документа ---
protected override void OnPosting(PostingContext ctx)
{
var rs = Movements["ТовариНаСкладах"];
rs.Write = true; // набір буде записано наприкінці транзакції
rs.Clear();

foreach (var row in this.Товари)
{
var m = rs.Add();
m.Період = this.Дата;
m.MovementType = AccumulationMovementType.Expense; // Витрата
m.Номенклатура = row.Номенклатура;
m.Склад = this.Склад;
m.Партія = row.Партія;
m.Кількість = row.Кількість;
m.Сума = row.Сума;
}

// керовані блокування перед контролем залишків
var lock_ = new DataLock();
var item = lock_.Add("РегістрНакопичення.ТовариНаСкладах.Залишки");
item.Mode = DataLockMode.Exclusive;
item.DataSource = rs.Unload(new[] { "Номенклатура", "Склад" });
item.UseFromDataSource("Номенклатура", "Номенклатура");
item.UseFromDataSource("Склад", "Склад");
lock_.Lock();

rs.WriteNow(); // примусовий запис до контролю
ControlBalances(ctx); // прикладна перевірка на від'ємні залишки
}

// --- Регістр бухгалтерії ---
var rs = Movements["Госпрозрахунковий"];
var m = rs.AddAccountingEntry();
m.Період = this.Дата;
m.РахунокДт = accounts["281"];
m.РахунокКт = accounts["631"];
m.SubcontoDt[ВидиСубконто.Номенклатура] = row.Номенклатура;
m.SubcontoDt[ВидиСубконто.Склади] = this.Склад;
m.SubcontoKt[ВидиСубконто.Контрагенти] = this.Контрагент;
m.Сума = row.Сума;
m.КількістьДт = row.Кількість;

// --- Регістр розрахунку ---
var rs = Movements["Нарахування"];
var m = rs.Add();
m.ВидРозрахунку = calcTypes["Оклад"];
m.Період = this.Дата; // період реєстрації
m.ПеріодДіїПочаток = new DateTime(2026,7,1);
m.ПеріодДіїКінець = new DateTime(2026,7,31);
m.БазовийПеріодПочаток = new DateTime(2026,6,1);
m.БазовийПеріодКінець = new DateTime(2026,6,30);
m.Співробітник = row.Співробітник;
m.Результат = 0; // заповниться після розрахунку
rs.WriteNow();

// отримання даних графіка та бази — запитом
</syntaxhighlight>

== 7.7. Блокування та конкурентність ==

{| class="wikitable"
! № !! Вимога
|-
| ФТ-31 || Режим керованих блокувань — за замовчуванням. Рівень ізоляції транзакцій: <code>READ COMMITTED</code> (PostgreSQL) / <code>READ COMMITTED SNAPSHOT</code> (MS SQL).
|-
| ФТ-32 || Об'єкт <code>DataLock</code> дозволяє встановити розділювальне/виняткове блокування на «простір» регістру за значеннями вимірювань (реалізація — <code>pg_advisory_xact_lock</code> за хешем ключа або <code>SELECT ... FOR UPDATE</code> по таблиці підсумків).
|-
| ФТ-33 || Запис рухів документа блокує тільки записи цього реєстратора (PK містить реєстратор першим).
|-
| ФТ-34 || Оновлення підсумків не повинно призводити до дедлоків: усі <code>MERGE</code>-операції в межах транзакції виконуються у детермінованому порядку сортування ключа.
|-
| ФТ-35 || Гарантія: паралельне проведення двох документів з різними наборами вимірювань не конкурує (за увімкненого розділення підсумків).
|-
| ФТ-36 || Таймаут очікування блокування — 20 с (налаштовується); при перевищенні — керована помилка з текстом конфліктного ключа.
|}

== 7.8. Права доступу ==

'''ФТ-37.''' Для регістру визначаються права: <code>Читання</code>, <code>Додавання</code>, <code>Зміна</code>, <code>Видалення</code>, <code>Перегляд</code>, <code>Редагування</code>, <code>ПереглядПідсумків</code>.
'''ФТ-38.''' Обмеження на рівні записів (RLS) задаються шаблоном умови по вимірюваннях; транслюються в <code>WHERE</code> усіх звернень, включно з віртуальними таблицями.
'''ФТ-39.''' ''Ризик:'' RLS на віртуальних таблицях залишків потребує узгодженості з підсумками. Рішення — RLS дозволено тільки по вимірюваннях, що входять до ключа підсумків; конструктор валідує це правило.

== 7.9. Журналювання, аудит, службові сервіси ==

'''ФТ-40.''' Реєстрація в журналі: перерахунок підсумків, зміна ТА, реструктуризація регістру, злиття сплітерів.
'''ФТ-41.''' Службовий сервіс «Перевірка цілісності регістрів»:
* «висячі» рухи (реєстратор не існує або не проведений);
* розбіжність підсумків і сум рухів (контрольний перерахунок у тіньову таблицю з порівнянням);
* некоректні фактичні періоди дії РР;
* для РБ — порушення рівності Дт = Кт за балансовим ресурсом у межах реєстратора.
'''ФТ-42.''' Звіт «Аналіз розміру регістрів»: кількість записів, розмір таблиць та індексів, дата останнього перерахунку підсумків.

= 8. Модель даних (як це виглядає в базі даних) =

== 8.1. Конвенції іменування ==

Фізичні імена '''не''' успадковують прикладні імена (обмеження довжини ідентифікатора, кирилиця, перейменування об'єктів). Ім'я будується за сурогатним кодом об'єкта метаданих <code><id></code> (4-значний hex/dec).

{| class="wikitable"
! Шаблон !! Призначення !! Приклад
|-
| <code>rg_i_<id></code> || Регістр відомостей — основна таблиця || <code>rg_i_0007</code>
|-
| <code>rg_a_<id></code> || Регістр накопичення — рухи || <code>rg_a_0012</code>
|-
| <code>rg_a_<id>_tb</code> || РН — підсумки залишків (Totals Balance) || <code>rg_a_0012_tb</code>
|-
| <code>rg_a_<id>_tt</code> || РН — підсумки оборотів (Totals Turnover) || <code>rg_a_0012_tt</code>
|-
| <code>rg_a_<id>_ag<n></code> || РН — агрегат № n || <code>rg_a_0031_ag1</code>
|-
| <code>rg_b_<id></code> || Регістр бухгалтерії — проводки || <code>rg_b_0020</code>
|-
| <code>rg_b_<id>_ed</code> || РБ — субконто (якщо винесено в дочірню таблицю) || <code>rg_b_0020_ed</code>
|-
| <code>rg_b_<id>_tb<k></code> || РБ — підсумки залишків за рівнем субконто k (0…N) || <code>rg_b_0020_tb2</code>
|-
| <code>rg_b_<id>_tt<k></code> || РБ — підсумки оборотів за рівнем субконто k || <code>rg_b_0020_tt1</code>
|-
| <code>rg_b_<id>_tc</code> || РБ — обороти між рахунками (кореспонденції) || <code>rg_b_0020_tc</code>
|-
| <code>rg_c_<id></code> || Регістр розрахунку — рухи || <code>rg_c_0040</code>
|-
| <code>rg_c_<id>_ap</code> || РР — фактичні періоди дії || <code>rg_c_0040_ap</code>
|-
| <code>rg_c_<id>_rc<m></code> || РР — перерахунок № m || <code>rg_c_0040_rc1</code>
|-
| <code>rg_<*>_<id>_opt</code> || Службова: ТА підсумків, налаштування || <code>rg_a_0012_opt</code>
|-
| <code>md_*</code> || Таблиці метаданих || <code>md_register</code>
|}

Колонки полів: <code>d<n></code> — вимірювання, <code>r<n></code> — ресурс, <code>a<n></code> — реквізит, де <code>n</code> — порядковий номер поля в метаописі (стабільний, не перевикористовується після видалення поля). Мапінг «прикладне ім'я ↔ фізична колонка» зберігається в <code>md_register_field</code>.

== 8.2. Типізація та зберігання значень ==

=== 8.2.1. Примітивні типи ===
{| class="wikitable"
! Тип платформи !! PostgreSQL !! MS SQL
|-
| Число(p,s) || <code>numeric(p,s)</code> || <code>numeric(p,s)</code>
|-
| Рядок(n) || <code>varchar(n)</code> || <code>nvarchar(n)</code>
|-
| Рядок(необмежена) || <code>text</code> || <code>nvarchar(max)</code>
|-
| Дата / ДатаЧас || <code>timestamp(0)</code> || <code>datetime2(0)</code>
|-
| Булево || <code>boolean</code> || <code>bit</code>
|-
| УНІ || <code>uuid</code> || <code>uniqueidentifier</code>
|}

=== 8.2.2. Посилальні типи ===
* '''Простий''' (один тип): одна колонка <code>d<n>_r uuid NOT NULL</code>, зовнішній ключ до таблиці об'єкта. Порожнє посилання = <code>'00000000-0000-0000-0000-000000000000'</code> (а не NULL — щоб зберегти семантику «пустого значення» у ключах підсумків).
* '''Складений''' (кілька типів / примітив + посилання): група колонок:

{| class="wikitable"
! Колонка !! Тип !! Опис
|-
| <code>d<n>_t</code> || <code>smallint</code> || Код типу: 1=Невизначено, 2=Булево, 3=Число, 4=Рядок, 5=Дата, ≥100 = <code>md_type.id</code> посилального типу
|-
| <code>d<n>_b</code> || <code>boolean</code> || Значення, якщо _t=2
|-
| <code>d<n>_n</code> || <code>numeric(38,10)</code> || Значення, якщо _t=3
|-
| <code>d<n>_s</code> || <code>varchar(N)</code> || Значення, якщо _t=4
|-
| <code>d<n>_d</code> || <code>timestamp(0)</code> || Значення, якщо _t=5
|-
| <code>d<n>_r</code> || <code>uuid</code> || Значення, якщо _t≥100
|}

{{Note|'''Проєктне рішення №1.''' Для складених типів обрано «широку» денормалізацію (кілька колонок), а не JSONB/варіант, тому що: (а) колонки індексуються та беруть участь у ключах підсумків; (б) B-tree по <code>(d1_t, d1_r)</code> дає range-scan, JSONB — ні; (в) сумісно з обома цільовими СКБД. Ціна — до 6 колонок на одне складене поле.}}

=== 8.2.3. Реєстратор ===
Завжди складений (будь-який з дозволених документів):
* <code>rec_t smallint NOT NULL</code> — код типу документа (<code>md_type.id</code>);
* <code>rec_r uuid NOT NULL</code> — посилання.

FK неможливий (поліморфізм) → цілісність забезпечується платформою + сервісом перевірки (ФТ-41).

=== 8.2.4. Маркери періодів ===
{| class="wikitable"
! Константа !! Значення !! Використання
|-
| <code>MINPERIOD</code> || <code>0001-01-01 00:00:00</code> || Нижня межа
|-
| <code>MAXPERIOD</code> || <code>5999-11-01 00:00:00</code> || Рядок «підсумок за всі періоди» в таблицях залишків
|}

== 8.3. Таблиці метаданих ==

<syntaxhighlight lang="sql">
-- ============ РЕПОЗИТОРІЙ МЕТАДАНИХ ============

CREATE TABLE md_type ( -- реєстр усіх типів конфігурації
id smallint PRIMARY KEY,
kind varchar(20) NOT NULL, -- Catalog|Document|Enum|ChartOfAccounts|ChartOfCalcTypes|Register|...
name varchar(80) NOT NULL,
table_name varchar(63),
UNIQUE (kind, name)
);

CREATE TABLE md_register (
id smallint PRIMARY KEY, -- = md_type.id
name varchar(80) NOT NULL UNIQUE,
synonym varchar(255),
comment text,
kind varchar(12) NOT NULL
CHECK (kind IN ('Information','Accumulation','Accounting','Calculation')),
-- загальні
write_mode varchar(24) NOT NULL DEFAULT 'SubordinateToRecorder'
CHECK (write_mode IN ('Independent','SubordinateToRecorder')),
periodicity varchar(24) NOT NULL DEFAULT 'Nonperiodical'
CHECK (periodicity IN ('Nonperiodical','WithinSecond','WithinDay','WithinMonth',
'WithinQuarter','WithinYear','ByRecorderPosition')),
lock_mode varchar(12) NOT NULL DEFAULT 'Managed',
use_rls boolean NOT NULL DEFAULT false,
partition_mode varchar(20) NOT NULL DEFAULT 'None',
partition_step varchar(10),
-- РН
accumulation_kind varchar(10) CHECK (accumulation_kind IN ('Balance','Turnover')),
enable_bal_totals boolean NOT NULL DEFAULT true,
enable_tno_totals boolean NOT NULL DEFAULT false,
tno_totals_period varchar(6) CHECK (tno_totals_period IN ('Day','Month')),
split_totals boolean NOT NULL DEFAULT false,
split_count smallint NOT NULL DEFAULT 1,
aggregates_mode varchar(10),
-- РБ
chart_of_accounts_id smallint REFERENCES md_type(id),
correspondence boolean NOT NULL DEFAULT true,
max_extdim_count smallint NOT NULL DEFAULT 3,
-- РР
calc_types_plan_id smallint REFERENCES md_type(id),
use_action_period boolean NOT NULL DEFAULT false,
base_period_mode varchar(24)
CHECK (base_period_mode IN ('None','ByActionPeriod','ByRegistrationPeriod')),
schedule_register_id smallint REFERENCES md_register(id),
schedule_value_field smallint,
schedule_date_field smallint,
-- службове
physical_table varchar(63) NOT NULL,
struct_version int NOT NULL DEFAULT 1,
CONSTRAINT chk_kind_props CHECK (
(kind = 'Accumulation' AND accumulation_kind IS NOT NULL) OR
(kind = 'Accounting' AND chart_of_accounts_id IS NOT NULL) OR
(kind = 'Calculation' AND calc_types_plan_id IS NOT NULL) OR
(kind = 'Information')
)
);

CREATE TABLE md_register_field (
id smallint NOT NULL, -- порядковий номер поля (стабільний)
register_id smallint NOT NULL REFERENCES md_register(id) ON DELETE CASCADE,
name varchar(80) NOT NULL,
synonym varchar(255),
role varchar(12) NOT NULL CHECK (role IN ('Dimension','Resource','Attribute')),
data_type_expr text NOT NULL, -- серіалізований опис типу (може бути складеним)
is_composite boolean NOT NULL DEFAULT false,
precision_ smallint,
scale_ smallint,
length_ int,
index_mode varchar(28) NOT NULL DEFAULT 'None'
CHECK (index_mode IN ('None','Index','IndexWithAddDimensions')),
is_master boolean NOT NULL DEFAULT false, -- «Ведуче»
in_default_filter boolean NOT NULL DEFAULT false,
deny_empty boolean NOT NULL DEFAULT false,
use_in_totals boolean NOT NULL DEFAULT true,
-- РБ
is_balance boolean NOT NULL DEFAULT false,
accounting_flag varchar(80),
extdim_flag varchar(80),
-- РР
is_base_dimension boolean NOT NULL DEFAULT false,
-- фізика
column_prefix varchar(8) NOT NULL, -- 'd3','r1','a2'
PRIMARY KEY (register_id, id),
UNIQUE (register_id, name)
);

CREATE TABLE md_register_recorder (
register_id smallint NOT NULL REFERENCES md_register(id) ON DELETE CASCADE,
doc_type_id smallint NOT NULL REFERENCES md_type(id),
PRIMARY KEY (register_id, doc_type_id)
);

CREATE TABLE md_register_aggregate (
id smallint NOT NULL,
register_id smallint NOT NULL REFERENCES md_register(id) ON DELETE CASCADE,
name varchar(80) NOT NULL,
periodicity varchar(8) NOT NULL CHECK (periodicity IN ('Day','Month','Quarter','Year')),
use_mode varchar(12) NOT NULL DEFAULT 'Auto',
is_realtime boolean NOT NULL DEFAULT false,
actual_upto timestamp(0),
physical_table varchar(63) NOT NULL,
PRIMARY KEY (register_id, id)
);
CREATE TABLE md_register_aggregate_dim (
register_id smallint NOT NULL,
aggregate_id smallint NOT NULL,
field_id smallint NOT NULL,
PRIMARY KEY (register_id, aggregate_id, field_id),
FOREIGN KEY (register_id, aggregate_id) REFERENCES md_register_aggregate(register_id, id) ON DELETE CASCADE
);

CREATE TABLE md_register_recalc (
id smallint NOT NULL,
register_id smallint NOT NULL REFERENCES md_register(id) ON DELETE CASCADE,
name varchar(80) NOT NULL,
physical_table varchar(63) NOT NULL,
PRIMARY KEY (register_id, id)
);
CREATE TABLE md_register_recalc_dim (
register_id smallint NOT NULL,
recalc_id smallint NOT NULL,
name varchar(80) NOT NULL,
reg_field_id smallint NOT NULL, -- вимірювання основного регістру
column_prefix varchar(8) NOT NULL,
PRIMARY KEY (register_id, recalc_id, name),
FOREIGN KEY (register_id, recalc_id) REFERENCES md_register_recalc(register_id, id) ON DELETE CASCADE
);
</syntaxhighlight>

== 8.4. Регістр відомостей ==

=== 8.4.1. Незалежний періодичний (приклад: КурсиВалют) ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_i_0007 (
period timestamp(0) NOT NULL, -- Період (усічений до дня: WithinDay)
d1_r uuid NOT NULL, -- Вимірювання «Валюта»
r1 numeric(15,4) NOT NULL, -- Ресурс «Курс»
r2 numeric(10,0) NOT NULL DEFAULT 1, -- Ресурс «Кратність»
CONSTRAINT pk_rg_i_0007 PRIMARY KEY (period, d1_r)
);
-- Індекс для зрізу останніх у розрізі вимірювання
CREATE INDEX ix_rg_i_0007_d1 ON rg_i_0007 (d1_r, period DESC) INCLUDE (r1, r2);
ALTER TABLE rg_i_0007 ADD CONSTRAINT fk_rg_i_0007_d1
FOREIGN KEY (d1_r) REFERENCES cat_0003(ref); -- Довідник.Валюти
</syntaxhighlight>

=== 8.4.2. Підпорядкований реєстратору ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_i_0008 (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
period timestamp(0) NOT NULL,
active boolean NOT NULL DEFAULT true,
d1_r uuid NOT NULL,
r1 numeric(15,2) NOT NULL,
CONSTRAINT pk_rg_i_0008 PRIMARY KEY (rec_t, rec_r, line_no)
);
CREATE INDEX ix_rg_i_0008_period ON rg_i_0008 (period, rec_t, rec_r, line_no);
CREATE INDEX ix_rg_i_0008_d1 ON rg_i_0008 (d1_r, period) WHERE active;
</syntaxhighlight>

=== 8.4.3. Незалежний неперіодичний ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_i_0009 (
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
r1 varchar(200),
CONSTRAINT pk_rg_i_0009 PRIMARY KEY (d1_r, d2_r)
);
</syntaxhighlight>

== 8.5. Регістр накопичення ==

=== 8.5.1. Таблиця рухів ===
<syntaxhighlight lang="sql">
-- ТовариНаСкладах: dims = Номенклатура(d1), Склад(d2), Партія(d3, складений), Характеристика(d4)
-- res = Кількість(r1), Сума(r2); attr = Коментар(a1)
CREATE TABLE rg_a_0012 (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
period timestamp(0) NOT NULL,
active boolean NOT NULL DEFAULT true,
mvt smallint NOT NULL CHECK (mvt IN (0,1)), -- 0=Прихід, 1=Витрата
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
d3_t smallint NOT NULL, -- складене вимірювання «Партія»
d3_r uuid NOT NULL,
d4_r uuid NOT NULL,
r1 numeric(15,3) NOT NULL DEFAULT 0,
r2 numeric(15,2) NOT NULL DEFAULT 0,
a1 varchar(200),
CONSTRAINT pk_rg_a_0012 PRIMARY KEY (rec_t, rec_r, line_no)
) PARTITION BY RANGE (period);

CREATE TABLE rg_a_0012_p2026m07 PARTITION OF rg_a_0012
FOR VALUES FROM ('2026-07-01') TO ('2026-08-01');
-- ... інші секції створюються регламентним завданням

CREATE INDEX ix_rg_a_0012_period ON rg_a_0012 (period, rec_t, rec_r, line_no);
CREATE INDEX ix_rg_a_0012_d1 ON rg_a_0012 (d1_r, period, d2_r) WHERE active; -- Номенклатура (Індексувати з дод. вимірюваннями)
CREATE INDEX ix_rg_a_0012_d2 ON rg_a_0012 (d2_r, period, d1_r) WHERE active; -- Склад
</syntaxhighlight>

=== 8.5.2. Таблиця підсумків залишків ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_a_0012_tb (
period timestamp(0) NOT NULL, -- початок місяця; MAXPERIOD = підсумок за всі періоди
splitter smallint NOT NULL DEFAULT 0,
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
d3_t smallint NOT NULL,
d3_r uuid NOT NULL,
d4_r uuid NOT NULL,
r1 numeric(20,3) NOT NULL, -- Кількість, знаковий залишок
r2 numeric(20,2) NOT NULL, -- Сума
CONSTRAINT pk_rg_a_0012_tb PRIMARY KEY (period, d1_r, d2_r, d3_t, d3_r, d4_r, splitter)
);
-- покривний індекс для типового відбору «залишки по складу»
CREATE INDEX ix_rg_a_0012_tb_d2 ON rg_a_0012_tb (d2_r, period, d1_r) INCLUDE (r1, r2);
</syntaxhighlight>

'''Семантика:''' рядок з <code>period = P</code> містить залишок '''на початок''' періоду P. Рядок з <code>period = MAXPERIOD</code> — поточний залишок за всі періоди (використовується для запитів «залишки на зараз», найчастіший кейс).

=== 8.5.3. Таблиця підсумків оборотів ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_a_0012_tt (
period timestamp(0) NOT NULL, -- початок періоду агрегації (день/місяць)
splitter smallint NOT NULL DEFAULT 0,
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
d3_t smallint NOT NULL,
d3_r uuid NOT NULL,
d4_r uuid NOT NULL,
r1_in numeric(20,3) NOT NULL DEFAULT 0, -- Кількість Прихід
r1_out numeric(20,3) NOT NULL DEFAULT 0, -- Кількість Витрата
r2_in numeric(20,2) NOT NULL DEFAULT 0,
r2_out numeric(20,2) NOT NULL DEFAULT 0,
CONSTRAINT pk_rg_a_0012_tt PRIMARY KEY (period, d1_r, d2_r, d3_t, d3_r, d4_r, splitter)
);
</syntaxhighlight>

=== 8.5.4. Службова таблиця налаштувань ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_a_0012_opt (
id smallint PRIMARY KEY DEFAULT 1 CHECK (id = 1),
totals_actual_to timestamp(0) NOT NULL, -- ТА: підсумки розраховані до
use_bal_totals boolean NOT NULL DEFAULT true,
use_tno_totals boolean NOT NULL DEFAULT true,
min_period timestamp(0), -- період першого руху
last_recalc_at timestamp(0),
split_merge_at timestamp(0)
);
</syntaxhighlight>

=== 8.5.5. Агрегат (для РН виду «Обороти») ===
<syntaxhighlight lang="sql">
-- Агрегат «Продажі за місяцями по номенклатурі та складу» (без Партії, без Характеристики)
CREATE TABLE rg_a_0031_ag1 (
period timestamp(0) NOT NULL,
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
r1 numeric(20,3) NOT NULL,
r2 numeric(20,2) NOT NULL,
CONSTRAINT pk_rg_a_0031_ag1 PRIMARY KEY (period, d1_r, d2_r)
);
</syntaxhighlight>

== 8.6. Регістр бухгалтерії ==

=== 8.6.1. План рахунків (супутні таблиці) ===
<syntaxhighlight lang="sql">
CREATE TABLE coa_0005 ( -- ПланРахунків.Госпрозрахунковий
ref uuid PRIMARY KEY,
parent_ref uuid REFERENCES coa_0005(ref),
code varchar(20) NOT NULL,
order_code varchar(40) NOT NULL, -- впорядкований код для ієрархічних запитів
name varchar(150) NOT NULL,
acc_type smallint NOT NULL, -- 0=Активний,1=Пасивний,2=Активно-пасивний
off_balance boolean NOT NULL DEFAULT false,
ed_count smallint NOT NULL DEFAULT 0, -- фактична кількість субконто
fl_qty boolean NOT NULL DEFAULT false, -- ознака обліку «Кількісний»
fl_cur boolean NOT NULL DEFAULT false, -- ознака обліку «Валютний»
marked_del boolean NOT NULL DEFAULT false
);
CREATE UNIQUE INDEX ux_coa_0005_code ON coa_0005 (code);

CREATE TABLE coa_0005_ed ( -- ТЧ «ВидиСубконто»
ref uuid NOT NULL REFERENCES coa_0005(ref) ON DELETE CASCADE,
line_no int NOT NULL,
ed_type_r uuid NOT NULL, -- ПланВидівХарактеристик.ВидиСубконто
only_tno boolean NOT NULL DEFAULT false, -- «Тільки обороти»
sum_flag boolean NOT NULL DEFAULT true, -- «Підсумкова сума»
fl_qty boolean NOT NULL DEFAULT false, -- ознака обліку субконто «Кількісний»
PRIMARY KEY (ref, line_no)
);
</syntaxhighlight>

=== 8.6.2. Таблиця проводок (з кореспонденцією) ===
<syntaxhighlight lang="sql">
-- Госпрозрахунковий: dims = Організація(d1, балансове), Підрозділ(d2, небалансове)
-- res = Сума(r1, балансовий), Кількість(r2, небалансовий), ВалютнаСума(r3, небалансовий)
-- attr = Зміст(a1), Валюта(a2); max_extdim_count = 3
CREATE TABLE rg_b_0020 (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
period timestamp(0) NOT NULL,
active boolean NOT NULL DEFAULT true,

acc_dt_r uuid NOT NULL REFERENCES coa_0005(ref),
acc_kt_r uuid NOT NULL REFERENCES coa_0005(ref),

-- балансове вимірювання: одне значення на проводку
d1_r uuid NOT NULL,
-- небалансове вимірювання: окремо для Дт і Кт
d2_dt_r uuid NOT NULL,
d2_kt_r uuid NOT NULL,

-- субконто Дт (3 слоти, складений тип: ПВХ-значення)
ed_dt1_t smallint, ed_dt1_r uuid,
ed_dt2_t smallint, ed_dt2_r uuid,
ed_dt3_t smallint, ed_dt3_r uuid,
ed_dt_h bigint NOT NULL DEFAULT 0, -- хеш набору субконто Дт (для JOIN з підсумками)
-- субконто Кт
ed_kt1_t smallint, ed_kt1_r uuid,
ed_kt2_t smallint, ed_kt2_r uuid,
ed_kt3_t smallint, ed_kt3_r uuid,
ed_kt_h bigint NOT NULL DEFAULT 0,

-- балансовий ресурс: одне значення
r1 numeric(20,2) NOT NULL DEFAULT 0, -- Сума
-- небалансові ресурси: пара Дт/Кт
r2_dt numeric(20,3) NOT NULL DEFAULT 0, -- Кількість Дт
r2_kt numeric(20,3) NOT NULL DEFAULT 0, -- Кількість Кт
r3_dt numeric(20,2) NOT NULL DEFAULT 0, -- ВалютнаСума Дт
r3_kt numeric(20,2) NOT NULL DEFAULT 0,

a1 varchar(255),
a2_r uuid,
CONSTRAINT pk_rg_b_0020 PRIMARY KEY (rec_t, rec_r, line_no)
) PARTITION BY RANGE (period);

CREATE INDEX ix_rg_b_0020_period ON rg_b_0020 (period, rec_t, rec_r, line_no);
CREATE INDEX ix_rg_b_0020_acc_dt ON rg_b_0020 (acc_dt_r, period) WHERE active;
CREATE INDEX ix_rg_b_0020_acc_kt ON rg_b_0020 (acc_kt_r, period) WHERE active;
CREATE INDEX ix_rg_b_0020_ed_dt ON rg_b_0020 (ed_dt1_t, ed_dt1_r, period) WHERE active;
</syntaxhighlight>

{{Note|'''Проєктне рішення №2.''' Субконто зберігаються '''слотами в основній таблиці''', а не в дочірній таблиці «ключ-значення». Обґрунтування: (а) віртуальні таблиці <code>Залишки</code>/<code>Обороти</code> з відбором за субконто перетворюються на предикат по колонці замість <code>N</code> самоз'єднань; (б) кількість субконто жорстко обмежена (≤5) — «широка» таблиця прийнятна; (в) 1С використовує гібрид (<code>_AccRgED</code>), що дає складніші плани. '''Ціна:''' зміна <code>МаксКількістьСубконто</code> = реструктуризація таблиці. Альтернатива (дочірня таблиця <code>rg_b_0020_ed</code>) описана в Додатку Б і зберігається як план «Б» за результатами навантажувального тесту НТ-04.}}

=== 8.6.3. Таблиця проводок (без кореспонденції) ===
<syntaxhighlight lang="sql">
CREATE TABLE rg_b_0021 (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
period timestamp(0) NOT NULL,
active boolean NOT NULL DEFAULT true,
acc_mvt smallint NOT NULL CHECK (acc_mvt IN (0,1)), -- 0=Дебет, 1=Кредит
acc_r uuid NOT NULL REFERENCES coa_0006(ref),
d1_r uuid NOT NULL,
ed1_t smallint, ed1_r uuid,
ed2_t smallint, ed2_r uuid,
ed3_t smallint, ed3_r uuid,
ed_h bigint NOT NULL DEFAULT 0,
r1 numeric(20,2) NOT NULL DEFAULT 0,
CONSTRAINT pk_rg_b_0021 PRIMARY KEY (rec_t, rec_r, line_no)
);
</syntaxhighlight>

=== 8.6.4. Підсумки РБ ===
Підсумки будуються на кількох «рівнях субконто» — щоб запит без відбору за субконто не сканував найдетальнішу таблицю.

<syntaxhighlight lang="sql">
-- Рівень 0: залишки по рахунку + балансові вимірювання (без субконто)
CREATE TABLE rg_b_0020_tb0 (
period timestamp(0) NOT NULL,
splitter smallint NOT NULL DEFAULT 0,
acc_r uuid NOT NULL,
d1_r uuid NOT NULL, -- Організація (балансове)
r1 numeric(24,2) NOT NULL, -- Сума: >0 = дебетовий, <0 = кредитовий залишок
r2 numeric(24,3) NOT NULL, -- Кількість
r3 numeric(24,2) NOT NULL,
CONSTRAINT pk_rg_b_0020_tb0 PRIMARY KEY (period, acc_r, d1_r, splitter)
);

-- Рівень 1..3: залишки з розшифровкою по субконто (тільки для рахунків з ed_count >= k)
CREATE TABLE rg_b_0020_tb1 (
period timestamp(0) NOT NULL, splitter smallint NOT NULL DEFAULT 0,
acc_r uuid NOT NULL, d1_r uuid NOT NULL,
ed1_t smallint NOT NULL, ed1_r uuid NOT NULL,
r1 numeric(24,2) NOT NULL, r2 numeric(24,3) NOT NULL, r3 numeric(24,2) NOT NULL,
CONSTRAINT pk_rg_b_0020_tb1 PRIMARY KEY (period, acc_r, d1_r, ed1_t, ed1_r, splitter)
);
CREATE TABLE rg_b_0020_tb2 (
period timestamp(0) NOT NULL, splitter smallint NOT NULL DEFAULT 0,
acc_r uuid NOT NULL, d1_r uuid NOT NULL,
ed1_t smallint NOT NULL, ed1_r uuid NOT NULL,
ed2_t smallint NOT NULL, ed2_r uuid NOT NULL,
r1 numeric(24,2) NOT NULL, r2 numeric(24,3) NOT NULL, r3 numeric(24,2) NOT NULL,
CONSTRAINT pk_rg_b_0020_tb2 PRIMARY KEY (period, acc_r, d1_r, ed1_t, ed1_r, ed2_t, ed2_r, splitter)
);
-- rg_b_0020_tb3 — аналогічно, 3 субконто

-- Обороти (аналогічні рівні): tt0..tt3
CREATE TABLE rg_b_0020_tt0 (
period timestamp(0) NOT NULL,
splitter smallint NOT NULL DEFAULT 0,
acc_r uuid NOT NULL,
d1_r uuid NOT NULL,
r1_dt numeric(24,2) NOT NULL, r1_kt numeric(24,2) NOT NULL,
r2_dt numeric(24,3) NOT NULL, r2_kt numeric(24,3) NOT NULL,
r3_dt numeric(24,2) NOT NULL, r3_kt numeric(24,2) NOT NULL,
CONSTRAINT pk_rg_b_0020_tt0 PRIMARY KEY (period, acc_r, d1_r, splitter)
);

-- Обороти між рахунками (кореспонденції)
CREATE TABLE rg_b_0020_tc (
period timestamp(0) NOT NULL,
splitter smallint NOT NULL DEFAULT 0,
acc_dt_r uuid NOT NULL,
acc_kt_r uuid NOT NULL,
d1_r uuid NOT NULL,
r1 numeric(24,2) NOT NULL,
CONSTRAINT pk_rg_b_0020_tc PRIMARY KEY (period, acc_dt_r, acc_kt_r, d1_r, splitter)
);
</syntaxhighlight>

'''Правило запису рівнів:''' для проводки з рахунком, що має <code>ed_count = k</code>, оновлюються таблиці <code>tb0 … tbK</code> (k+1 таблиць). Рахунки без субконто оновлюють лише <code>tb0</code>. Субконто з ознакою «Тільки обороти» не потрапляють у <code>tb*</code>, лише в <code>tt*</code>.

== 8.7. Регістр розрахунку ==

<syntaxhighlight lang="sql">
-- Нарахування: dims = Співробітник(d1, базове), Підрозділ(d2)
-- res = Результат(r1), ВідпрацьованоДнів(r2), НормаДнів(r3)
-- attr = Графік(a1)
CREATE TABLE rg_c_0040 (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
period timestamp(0) NOT NULL, -- період реєстрації (початок місяця)
active boolean NOT NULL DEFAULT true,
reversal boolean NOT NULL DEFAULT false, -- Сторно
calc_type_r uuid NOT NULL, -- ВидРозрахунку → pct_0011(ref)
act_begin timestamp(0) NOT NULL, -- ПеріодДіїПочаток
act_end timestamp(0) NOT NULL, -- ПеріодДіїКінець
base_begin timestamp(0), -- БазовийПеріодПочаток
base_end timestamp(0), -- БазовийПеріодКінець
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
r1 numeric(15,2) NOT NULL DEFAULT 0,
r2 numeric(5,0) NOT NULL DEFAULT 0,
r3 numeric(5,0) NOT NULL DEFAULT 0,
a1_r uuid,
CONSTRAINT pk_rg_c_0040 PRIMARY KEY (rec_t, rec_r, line_no),
CONSTRAINT chk_rg_c_0040_act CHECK (act_end >= act_begin)
);
CREATE INDEX ix_rg_c_0040_period ON rg_c_0040 (period, rec_t, rec_r, line_no);
CREATE INDEX ix_rg_c_0040_d1 ON rg_c_0040 (d1_r, period, calc_type_r) WHERE active;
CREATE INDEX ix_rg_c_0040_act ON rg_c_0040 (d1_r, act_begin, act_end) WHERE active;
CREATE INDEX ix_rg_c_0040_base ON rg_c_0040 (d1_r, calc_type_r, base_begin, base_end) WHERE active;

-- Фактичні періоди дії (після витіснення). Один запис → 0..N інтервалів.
CREATE TABLE rg_c_0040_ap (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
interval_no smallint NOT NULL,
calc_type_r uuid NOT NULL,
d1_r uuid NOT NULL, -- денормалізація базового вимірювання для швидкого JOIN
fact_begin timestamp(0) NOT NULL,
fact_end timestamp(0) NOT NULL,
CONSTRAINT pk_rg_c_0040_ap PRIMARY KEY (rec_t, rec_r, line_no, interval_no),
CONSTRAINT fk_rg_c_0040_ap FOREIGN KEY (rec_t, rec_r, line_no)
REFERENCES rg_c_0040 (rec_t, rec_r, line_no) ON DELETE CASCADE
);
CREATE INDEX ix_rg_c_0040_ap_d1 ON rg_c_0040_ap (d1_r, fact_begin, fact_end);

-- Перерахунок «ПерерахунокЗаБазою»
CREATE TABLE rg_c_0040_rc1 (
rec_t smallint NOT NULL, -- реєстратор запису, який треба перерахувати
rec_r uuid NOT NULL,
calc_type_r uuid NOT NULL, -- вид розрахунку, що потребує перерахунку
d1_r uuid NOT NULL, -- вимірювання перерахунку «Співробітник»
src_rec_t smallint NOT NULL, -- реєстратор, що спричинив перерахунок
src_rec_r uuid NOT NULL,
created_at timestamp(0) NOT NULL DEFAULT now(),
CONSTRAINT pk_rg_c_0040_rc1 PRIMARY KEY (rec_t, rec_r, calc_type_r, d1_r)
);
CREATE INDEX ix_rg_c_0040_rc1_src ON rg_c_0040_rc1 (src_rec_t, src_rec_r);
</syntaxhighlight>

== 8.8. Зведення: які таблиці породжує кожен тип регістру ==

<pre>
РВ (незалежний) → rg_i_<id>
РВ (підпорядкований) → rg_i_<id>

РН (Залишки) → rg_a_<id>
rg_a_<id>_tb (якщо ДозволитиПідсумкиЗалишків)
rg_a_<id>_tt (якщо ДозволитиПідсумкиОборотів)
rg_a_<id>_opt

РН (Обороти) → rg_a_<id>
rg_a_<id>_tt
rg_a_<id>_ag1..agN (агрегати)
rg_a_<id>_opt

РБ → rg_b_<id>
rg_b_<id>_tb0 .. _tbK (K = МаксКількістьСубконто)
rg_b_<id>_tt0 .. _ttK
rg_b_<id>_tc
rg_b_<id>_opt

РР → rg_c_<id>
rg_c_<id>_ap
rg_c_<id>_rc1 .. _rcM (перерахунки)
</pre>

Оцінка: для РБ з <code>МаксКількістьСубконто = 3</code> генерується '''10 фізичних таблиць''' на один регістр.

= 9. ER-моделі =

== 9.1. ER-модель метаданих (репозиторій) ==

<plantuml>
@startuml
hide circle
skinparam linetype ortho
skinparam shadowing false

entity "md_type" as T {
* id : smallint <<PK>>
--
* kind : varchar(20)
* name : varchar(80)
table_name : varchar(63)
}

entity "md_register" as R {
* id : smallint <<PK,FK→md_type>>
--
* name : varchar(80) <<U>>
* kind : varchar(12)
* write_mode : varchar(24)
* periodicity : varchar(24)
accumulation_kind : varchar(10)
enable_bal_totals : boolean
enable_tno_totals : boolean
tno_totals_period : varchar(6)
split_totals : boolean
chart_of_accounts_id : smallint <<FK>>
correspondence : boolean
max_extdim_count : smallint
calc_types_plan_id : smallint <<FK>>
use_action_period : boolean
base_period_mode : varchar(24)
schedule_register_id : smallint <<FK>>
* physical_table : varchar(63)
* struct_version : int
}

entity "md_register_field" as F {
* register_id : smallint <<PK,FK>>
* id : smallint <<PK>>
--
* name : varchar(80) <<U>>
* role : Dimension|Resource|Attribute
* data_type_expr : text
is_composite : boolean
index_mode : varchar(28)
is_master : boolean
is_balance : boolean
is_base_dimension : boolean
accounting_flag : varchar(80)
* column_prefix : varchar(8)
}

entity "md_register_recorder" as RR {
* register_id : smallint <<PK,FK>>
* doc_type_id : smallint <<PK,FK>>
}

entity "md_register_aggregate" as AG {
* register_id : smallint <<PK,FK>>
* id : smallint <<PK>>
--
* name : varchar(80)
* periodicity : Day|Month|Quarter|Year
is_realtime : boolean
actual_upto : timestamp
}

entity "md_register_aggregate_dim" as AGD {
* register_id : smallint <<PK,FK>>
* aggregate_id : smallint <<PK,FK>>
* field_id : smallint <<PK,FK>>
}

entity "md_register_recalc" as RC {
* register_id : smallint <<PK,FK>>
* id : smallint <<PK>>
--
* name : varchar(80)
* physical_table : varchar(63)
}

entity "md_register_recalc_dim" as RCD {
* register_id : smallint <<PK,FK>>
* recalc_id : smallint <<PK,FK>>
* name : varchar(80) <<PK>>
--
* reg_field_id : smallint <<FK>>
}

T ||--o| R : "є регістром"
T ||--o{ RR : "тип документа"
R ||--|{ F : "має поля"
R ||--o{ RR : "реєстратори"
R ||--o{ AG : "агрегати"
AG ||--|{ AGD : "склад вимірювань"
F ||--o{ AGD : "вимірювання"
R ||--o{ RC : "перерахунки"
RC ||--|{ RCD : "вимірювання перерахунку"
F ||--o{ RCD : "відповідає"
R }o--o| T : "план рахунків"
R }o--o| T : "план видів розрахунку"
R }o--o| R : "графік часу"
@enduml
</plantuml>

== 9.2. ER-модель: регістр накопичення (вид «Залишки») ==

<plantuml>
@startuml
hide circle
skinparam linetype ortho
skinparam shadowing false

entity "doc_0002\n«ПрихіднаНакладна»" as D1 {
* ref : uuid <<PK>>
--
number : varchar
date : timestamp
posted : boolean
}
entity "doc_0003\n«ВидатковаНакладна»" as D2 {
* ref : uuid <<PK>>
--
number : varchar
date : timestamp
posted : boolean
}
entity "cat_0001\n«Номенклатура»" as C1 {
* ref : uuid <<PK>>
--
code, name
}
entity "cat_0004\n«Склади»" as C2 {
* ref : uuid <<PK>>
--
code, name
}

entity "rg_a_0012\n«ТовариНаСкладах» (рухи)" as M {
* rec_t : smallint <<PK>>
* rec_r : uuid <<PK>>
* line_no : int <<PK>>
--
* period : timestamp(0)
* active : boolean
* mvt : smallint «0=Прихід,1=Витрата»
* d1_r : uuid «Номенклатура» <<FK>>
* d2_r : uuid «Склад» <<FK>>
* d3_t : smallint «Партія:тип»
* d3_r : uuid «Партія:посилання»
* d4_r : uuid «Характеристика» <<FK>>
* r1 : numeric(15,3) «Кількість»
* r2 : numeric(15,2) «Сума»
a1 : varchar(200) «Коментар»
}

entity "rg_a_0012_tb\nпідсумки залишків" as TB {
* period : timestamp(0) <<PK>>
* d1_r : uuid <<PK>>
* d2_r : uuid <<PK>>
* d3_t : smallint <<PK>>
* d3_r : uuid <<PK>>
* d4_r : uuid <<PK>>
* splitter : smallint <<PK>>
--
* r1 : numeric(20,3) «Кількість (±)»
* r2 : numeric(20,2) «Сума (±)»
}

entity "rg_a_0012_tt\nпідсумки оборотів" as TT {
* period : timestamp(0) <<PK>>
* d1_r : uuid <<PK>>
* d2_r : uuid <<PK>>
* d3_t : smallint <<PK>>
* d3_r : uuid <<PK>>
* d4_r : uuid <<PK>>
* splitter : smallint <<PK>>
--
r1_in, r1_out : numeric(20,3)
r2_in, r2_out : numeric(20,2)
}

entity "rg_a_0012_opt" as OPT {
* id : smallint = 1 <<PK>>
--
* totals_actual_to : timestamp(0)
use_bal_totals : boolean
use_tno_totals : boolean
min_period : timestamp(0)
}

D1 ||..o{ M : "реєстратор\n(поліморфний, без FK)"
D2 ||..o{ M : "реєстратор\n(поліморфний, без FK)"
C1 ||--o{ M : "d1_r"
C2 ||--o{ M : "d2_r"
M }o..|| TB : "агрегується в\n(підтримується платформою)"
M }o..|| TT : "агрегується в"
OPT ||..|| TB : "ТА підсумків"

note bottom of M
PK = (rec_t, rec_r, line_no)
→ усі рухи одного документа
фізично суміжні
Партиціонування: RANGE(period)
end note

note bottom of TB
period = MAXPERIOD ('5999-11-01')
→ рядок «залишок за всі періоди»
end note
@enduml
</plantuml>

== 9.3. ER-модель: регістр бухгалтерії ==

<plantuml>
@startuml
hide circle
skinparam linetype ortho
skinparam shadowing false

entity "coa_0005\n«План рахунків»" as A {
* ref : uuid <<PK>>
--
parent_ref : uuid <<FK>>
* code : varchar(20) <<U>>
order_code : varchar(40)
* name : varchar(150)
* acc_type : smallint «Акт/Пас/АП»
off_balance : boolean
ed_count : smallint
fl_qty, fl_cur : boolean
}
entity "coa_0005_ed\n«Види субконто рахунку»" as AE {
* ref : uuid <<PK,FK>>
* line_no : int <<PK>>
--
* ed_type_r : uuid <<FK>>
only_tno : boolean
sum_flag : boolean
}
entity "cvt_0009\n«ПВХ.ВидиСубконто»" as VT {
* ref : uuid <<PK>>
--
code, name
value_type : text
}

entity "rg_b_0020\n«Госпрозрахунковий» (проводки)" as J {
* rec_t : smallint <<PK>>
* rec_r : uuid <<PK>>
* line_no : int <<PK>>
--
* period : timestamp(0)
* active : boolean
* acc_dt_r : uuid <<FK>>
* acc_kt_r : uuid <<FK>>
* d1_r : uuid «Організація (балансове)»
* d2_dt_r : uuid «Підрозділ Дт»
* d2_kt_r : uuid «Підрозділ Кт»
ed_dt1_t/_r .. ed_dt3_t/_r : «субконто Дт»
ed_dt_h : bigint
ed_kt1_t/_r .. ed_kt3_t/_r : «субконто Кт»
ed_kt_h : bigint
* r1 : numeric(20,2) «Сума (балансовий)»
r2_dt, r2_kt : numeric(20,3) «Кількість»
r3_dt, r3_kt : numeric(20,2) «ВалютнаСума»
a1 : varchar(255) «Зміст»
a2_r : uuid «Валюта»
}

entity "rg_b_0020_tb0\nзалишки, рівень 0" as B0 {
* period <<PK>>
* acc_r <<PK>>
* d1_r <<PK>>
* splitter <<PK>>
--
r1, r2, r3 : numeric «знакові»
}
entity "rg_b_0020_tb1..tb3\nзалишки, рівні 1..3" as B1 {
* period <<PK>>
* acc_r <<PK>>
* d1_r <<PK>>
* ed1_t, ed1_r <<PK>>
* (ed2_t, ed2_r) <<PK>>
* (ed3_t, ed3_r) <<PK>>
* splitter <<PK>>
--
r1, r2, r3 : numeric
}
entity "rg_b_0020_tt0..tt3\nобороти за рівнями" as T0 {
* period <<PK>>
* acc_r <<PK>>
* d1_r <<PK>>
* (ed…) <<PK>>
--
r1_dt, r1_kt
r2_dt, r2_kt
r3_dt, r3_kt
}
entity "rg_b_0020_tc\nобороти Дт↔Кт" as TC {
* period <<PK>>
* acc_dt_r <<PK>>
* acc_kt_r <<PK>>
* d1_r <<PK>>
--
r1 : numeric(24,2)
}

A ||--o{ AE : "види субконто"
VT ||--o{ AE : "тип субконто"
A ||--o{ J : "acc_dt_r"
A ||--o{ J : "acc_kt_r"
A ||--o{ B0 : "acc_r"
A ||--o{ B1 : "acc_r"
J }o..|| B0 : "агрегується (Дт: +, Кт: −)"
J }o..|| B1 : "агрегується, якщо ed_count ≥ k"
J }o..|| T0 : "агрегується"
J }o..|| TC : "агрегується"

note right of J
Балансовий ресурс r1 — одне значення,
контроль Σ(Дт) = Σ(Кт) у межах реєстратора.
Небалансові ресурси — пара Дт/Кт.
Субконто — слоти (див. Рішення №2).
end note
@enduml
</plantuml>

== 9.4. ER-модель: регістр розрахунку ==

<plantuml>
@startuml
hide circle
skinparam linetype ortho
skinparam shadowing false

entity "pct_0011\n«ПВР.ОсновніНарахування»" as P {
* ref : uuid <<PK>>
--
code, name
use_action_period : boolean
base_dependency : varchar(24)
}
entity "pct_0011_base\n«Базові види розрахунку»" as PB {
* ref <<PK,FK>>
* line_no <<PK>>
--
* base_type_r : uuid <<FK>>
}
entity "pct_0011_displace\n«Витісняючі види розрахунку»" as PD {
* ref <<PK,FK>>
* line_no <<PK>>
--
* displacing_type_r : uuid <<FK>>
}
entity "pct_0011_lead\n«Ведучі види розрахунку»" as PL {
* ref <<PK,FK>>
* line_no <<PK>>
--
* leading_type_r : uuid <<FK>>
}

entity "rg_c_0040\n«Нарахування» (рухи)" as CR {
* rec_t : smallint <<PK>>
* rec_r : uuid <<PK>>
* line_no : int <<PK>>
--
* period : timestamp(0) «період реєстрації»
* active : boolean
* reversal : boolean «Сторно»
* calc_type_r : uuid <<FK>>
* act_begin : timestamp(0)
* act_end : timestamp(0)
base_begin : timestamp(0)
base_end : timestamp(0)
* d1_r : uuid «Співробітник (базове)»
* d2_r : uuid «Підрозділ»
r1 : numeric «Результат»
r2 : numeric «ВідпрацьованоДнів»
r3 : numeric «НормаДнів»
}

entity "rg_c_0040_ap\nфактичні періоди дії" as AP {
* rec_t <<PK,FK>>
* rec_r <<PK,FK>>
* line_no <<PK,FK>>
* interval_no : smallint <<PK>>
--
* calc_type_r : uuid
* d1_r : uuid
* fact_begin : timestamp(0)
* fact_end : timestamp(0)
}

entity "rg_c_0040_rc1\n«ПерерахунокЗаБазою»" as RC {
* rec_t <<PK>>
* rec_r <<PK>>
* calc_type_r <<PK>>
* d1_r <<PK>>
--
src_rec_t, src_rec_r
created_at
}

entity "rg_i_0015\n«ГрафікРоботи» (РВ)" as SCH {
* d1_r : uuid <<PK>> «ВидГрафіка»
* d2_d : timestamp(0) <<PK>> «ДатаГрафіка»
--
r1 : numeric «Значення»
}

entity "doc_0007\n«НарахуванняЗарплати»" as DOC {
* ref : uuid <<PK>>
--
number, date, posted
}

P ||--o{ CR : "calc_type_r"
P ||--o{ PB : "базові"
P ||--o{ PD : "витісняючі"
P ||--o{ PL : "ведучі"
DOC ||..o{ CR : "реєстратор"
CR ||--|{ AP : "1 запис → 0..N\nфактичних інтервалів"
CR }o..o{ RC : "потребує перерахунку"
SCH }o..o{ CR : "ДаніГрафіка\n(віртуальна таблиця)"
CR }o..o{ CR : "БазаРозрахунку\n(self-join через PB\nта базові вимірювання)"
@enduml
</plantuml>

== 9.5. Зведена концептуальна ER (усі типи) ==

<graphviz>
digraph ER {
rankdir=LR; bgcolor="transparent";
node [shape=record, fontname="Helvetica", fontsize=9, style=filled];
edge [fontname="Helvetica", fontsize=8];

MD [label="{md_register|id (PK)\lname\lkind\lperiodicity\lwrite_mode\l...}", fillcolor="#dbe9ff"];
MDF [label="{md_register_field|register_id (PK,FK)\lid (PK)\lname\lrole\ldata_type\l...}", fillcolor="#dbe9ff"];
MDR [label="{md_register_recorder|register_id (PK,FK)\ldoc_type_id (PK,FK)\l}", fillcolor="#dbe9ff"];

DOC [label="{doc_XXXX (Документ)|ref (PK)\lnumber\ldate\lposted\l}", fillcolor="#fff8e1"];
CAT [label="{cat_XXXX (Довідник)|ref (PK)\lcode\lname\l}", fillcolor="#fff8e1"];
COA [label="{coa_XXXX (План рахунків)|ref (PK)\lcode\lacc_type\led_count\l}", fillcolor="#fff8e1"];
PCT [label="{pct_XXXX (ПВР)|ref (PK)\lcode\l}", fillcolor="#fff8e1"];

RI [label="{rg_i_XXXX (РВ)|period (PK*)\ld1..dN (PK*)\l| rec_t,rec_r,line_no (PK**)\lr1..rM\l}", fillcolor="#e8f5e9"];
RA [label="{rg_a_XXXX (РН)|rec_t, rec_r, line_no (PK)\lperiod\lactive\lmvt\ld1..dN\lr1..rM\l}", fillcolor="#fff3e0"];
RAT [label="{rg_a_XXXX_tb / _tt|period (PK)\ld1..dN (PK)\lsplitter (PK)\lr1..rM\l}", fillcolor="#ffe0b2"];
RB [label="{rg_b_XXXX (РБ)|rec_t, rec_r, line_no (PK)\lperiod, active\lacc_dt_r, acc_kt_r\led_dt1..3, ed_kt1..3\ld1..dN\lr1, r2_dt/r2_kt\l}", fillcolor="#fce4ec"];
RBT [label="{rg_b_XXXX_tb0..tbK\lrg_b_XXXX_tt0..ttK\lrg_b_XXXX_tc|period, acc_r, d1..dN\led1..edK (PK)\lr1..rM\l}", fillcolor="#f8bbd0"];
RC [label="{rg_c_XXXX (РР)|rec_t, rec_r, line_no (PK)\lperiod, active, reversal\lcalc_type_r\lact_begin, act_end\lbase_begin, base_end\ld1..dN, r1..rM\l}", fillcolor="#ede7f6"];
RCA [label="{rg_c_XXXX_ap|rec_t,rec_r,line_no (PK,FK)\linterval_no (PK)\lfact_begin, fact_end\l}", fillcolor="#d1c4e9"];
RCR [label="{rg_c_XXXX_rc1..rcM|rec_t, rec_r (PK)\lcalc_type_r (PK)\ld1..dN (PK)\l}", fillcolor="#d1c4e9"];

MD -> MDF [label="1:N"];
MD -> MDR [label="1:N"];
MDR -> DOC [label="тип"];
MD -> COA [label="0:1 план рахунків", style=dashed];
MD -> PCT [label="0:1 ПВР", style=dashed];

MD -> RI [label="генерує DDL", style=dotted, color=blue];
MD -> RA [label="генерує DDL", style=dotted, color=blue];
MD -> RB [label="генерує DDL", style=dotted, color=blue];
MD -> RC [label="генерує DDL", style=dotted, color=blue];

DOC -> RI [label="реєстратор (поліморф.)", style=dashed];
DOC -> RA [label="реєстратор (поліморф.)", style=dashed];
DOC -> RB [label="реєстратор (поліморф.)", style=dashed];
DOC -> RC [label="реєстратор (поліморф.)", style=dashed];

CAT -> RI [label="FK вимір."];
CAT -> RA [label="FK вимір."];
COA -> RB [label="FK рахунок"];
PCT -> RC [label="FK вид розрах."];

RA -> RAT [label="агрегація (платформа)", color=darkgreen];
RB -> RBT [label="агрегація (платформа)", color=darkgreen];
RC -> RCA [label="витіснення → 1:N", color=purple];
RC -> RCR [label="реєстрація перерахунків", color=purple, style=dashed];

{ rank=same; MD; MDF; MDR; }
{ rank=same; RI; RA; RB; RC; }
}
</graphviz>

'''Легенда:'''
* <code>(PK*)</code> — ключ для незалежного РВ; <code>(PK**)</code> — для підпорядкованого.
* Пунктир «реєстратор» — логічний зв'язок без FK (поліморфне посилання, підтримується платформою).
* Пунктир «генерує DDL» — метадані → фізична схема (не зв'язок даних).

= 10. Ключові алгоритми =

== 10.1. Запис набору записів (режим «Заміщати») ==

<syntaxhighlight lang="text">
ЗАПИСАТИ_НАБІР(регістр R, відбір S, записи N[]):
1. Перевірити права (Додавання/Зміна)
2. Валідація: тип реєстратора ∈ md_register_recorder;
вимірювання з deny_empty ≠ порожнє;
для РБ — Σ(r1 де балансовий) по Дт = по Кт у межах реєстратора
3. У транзакції:
3.1. СТАРІ := SELECT * FROM rg_x WHERE <відбір S> FOR UPDATE
3.2. Δ := АГРЕГУВАТИ(N, +1) ⊕ АГРЕГУВАТИ(СТАРІ, −1) // тільки active
3.3. DELETE FROM rg_x WHERE <відбір S>
3.4. INSERT INTO rg_x SELECT ... FROM N
3.5. ОНОВИТИ_ПІДСУМКИ(R, Δ) // див. 10.2
3.6. ЯКЩО R.kind = Calculation:
ПЕРЕРАХУВАТИ_ФАКТИЧНІ_ПЕРІОДИ(R, зачеплені вимірювання) // 10.4
ЗАРЕЄСТРУВАТИ_ПЕРЕРАХУНКИ(R, N ∪ СТАРІ) // 10.5
</syntaxhighlight>

== 10.2. Інкрементальне оновлення підсумків залишків ==

<syntaxhighlight lang="sql">
-- Δ (delta) — тимчасова таблиця: (period_month, d1_r, d2_r, d3_t, d3_r, d4_r, dr1, dr2)
-- де dr = Σ (CASE WHEN mvt = 0 THEN +значення ELSE -значення END)

-- Крок 1. Кумулятивні залишки: рух у місяці M впливає на підсумки всіх періодів > M
-- та на рядок MAXPERIOD.
INSERT INTO rg_a_0012_tb AS t (period, splitter, d1_r, d2_r, d3_t, d3_r, d4_r, r1, r2)
SELECT p.period, :splitter, d.d1_r, d.d2_r, d.d3_t, d.d3_r, d.d4_r, d.dr1, d.dr2
FROM delta d
CROSS JOIN LATERAL (
SELECT period FROM totals_periods
WHERE period > d.period_month
AND period <= (SELECT totals_actual_to FROM rg_a_0012_opt)
UNION ALL SELECT TIMESTAMP '5999-11-01' -- MAXPERIOD
) p
ORDER BY 1,3,4,5,6,7 -- детермінований порядок → без дедлоків
ON CONFLICT (period, d1_r, d2_r, d3_t, d3_r, d4_r, splitter)
DO UPDATE SET r1 = t.r1 + EXCLUDED.r1,
r2 = t.r2 + EXCLUDED.r2;

-- Крок 2. Прибирання нульових рядків (регламентно, не в транзакції проведення)
DELETE FROM rg_a_0012_tb WHERE r1 = 0 AND r2 = 0 AND period <> TIMESTAMP '5999-11-01';
</syntaxhighlight>

{{Note|'''Оптимізація.''' Крок 1 у наведеному вигляді має складність O(кількість_періодів_після_руху). Для рухів «заднім числом» на роки це дорого. '''Проєктне рішення №3:''' підсумки оновлюються тільки для рядка <code>MAXPERIOD</code> і для найближчої межі періоду; повні кумулятивні зрізи перебудовуються регламентним завданням «Перерахунок підсумків» за зміненими місяцями (список змінених місяців накопичується в <code>rg_a_0012_opt.dirty_months</code>). Запити на дату в «брудному» місяці автоматично перемикаються на розрахунок від найближчого чистого зрізу. Остаточний вибір — за результатами НТ-02.}}

== 10.3. Трансляція віртуальної таблиці «Залишки» ==

<syntaxhighlight lang="sql">
-- РегістрНакопичення.ТовариНаСкладах.Залишки(&Період, Склад = &Склад)
WITH boundary AS (
SELECT COALESCE(MAX(period), TIMESTAMP '0001-01-01') AS p
FROM totals_periods
WHERE period <= :Період
AND period <= (SELECT totals_actual_to FROM rg_a_0012_opt)
),
base AS ( -- залишок на межу періоду з підсумків
SELECT t.d1_r, t.d2_r, t.d3_t, t.d3_r, t.d4_r,
SUM(t.r1) AS r1, SUM(t.r2) AS r2
FROM rg_a_0012_tb t, boundary b
WHERE t.period = b.p
AND t.d2_r = :Склад -- push-down параметра ВТ
GROUP BY 1,2,3,4,5
),
tail AS ( -- «живі» рухи після межі й до &Період
SELECT m.d1_r, m.d2_r, m.d3_t, m.d3_r, m.d4_r,
SUM(CASE WHEN m.mvt = 0 THEN m.r1 ELSE -m.r1 END) AS r1,
SUM(CASE WHEN m.mvt = 0 THEN m.r2 ELSE -m.r2 END) AS r2
FROM rg_a_0012 m, boundary b
WHERE m.active
AND m.period > b.p
AND m.period <= :Період
AND m.d2_r = :Склад
GROUP BY 1,2,3,4,5
)
SELECT d1_r AS "Номенклатура", d2_r AS "Склад",
d3_t, d3_r AS "Партія", d4_r AS "Характеристика",
SUM(r1) AS "КількістьЗалишок",
SUM(r2) AS "СумаЗалишок"
FROM (SELECT * FROM base UNION ALL SELECT * FROM tail) u
GROUP BY 1,2,3,4,5
HAVING SUM(r1) <> 0 OR SUM(r2) <> 0; -- нульові залишки не повертаються
</syntaxhighlight>

'''Оптимізація для найчастішого випадку:''' якщо <code>:Період ≥ ТА</code> і в регістрі немає рухів у майбутньому — <code>base</code> читається з рядка <code>MAXPERIOD</code> одним index seek, <code>tail</code> = ∅.

== 10.4. Розрахунок фактичних періодів дії (витіснення) ==

<syntaxhighlight lang="text">
ПЕРЕРАХУВАТИ_ФАКТИЧНІ_ПЕРІОДИ(регістр R, множина ключів K):
ДЛЯ кожного ключа k ∈ K: // k = кортеж значень усіх вимірювань R
Z := SELECT * FROM rg_c_X
WHERE вимірювання = k AND active
ORDER BY <пріоритет виду розрахунку за ПВР>, period, line_no
// пріоритет: A витісняється B, якщо B ∈ ПВР[A].ВитісняючіВидиРозрахунку

DELETE FROM rg_c_X_ap WHERE (rec,line) ∈ Z

ДЛЯ кожного запису z ∈ Z (у порядку зростання пріоритету, тобто найслабші — першими):
I := { [z.act_begin, z.act_end] }
ДЛЯ кожного w ∈ Z, де ВидРозрахунку(w) витісняє ВидРозрахунку(z)
І перетинаються періоди реєстрації за правилами ПВР:
I := I \ [w.act_begin, w.act_end] // різниця множин інтервалів
n := 0
ДЛЯ кожного інтервалу i ∈ I (упорядковано):
INSERT INTO rg_c_X_ap
VALUES (z.rec_t, z.rec_r, z.line_no, n, z.calc_type_r, z.d1_r, i.begin, i.end)
n := n + 1
</syntaxhighlight>

'''Складність:''' O(|Z|² ) на ключ. Обмеження: якщо <code>|Z| > 500</code> для одного ключа — попередження в журналі та перехід на алгоритм замітання (sweep line) O(|Z| log |Z|).

== 10.5. Реєстрація перерахунків ==

<syntaxhighlight lang="text">
ЗАРЕЄСТРУВАТИ_ПЕРЕРАХУНКИ(регістр R, змінені записи Z):
ДЛЯ кожного перерахунку P ∈ R.Перерахунки:
ДЛЯ кожного z ∈ Z:
// знайти всі записи, для яких z є базовим
залежні := SELECT DISTINCT rec_t, rec_r, calc_type_r, <вимірювання P>
FROM rg_c_X q
JOIN pct_base b ON b.ref = q.calc_type_r
AND b.base_type_r = z.calc_type_r
WHERE q.active
AND <вимірювання P у q> = <вимірювання P у z>
AND ( (R.base_period_mode = 'ByActionPeriod'
AND [z.act_begin, z.act_end] ∩ [q.base_begin, q.base_end] ≠ ∅)
OR (R.base_period_mode = 'ByRegistrationPeriod'
AND z.period BETWEEN q.base_begin AND q.base_end) )
AND (q.rec_t, q.rec_r) ≠ (z.rec_t, z.rec_r)
INSERT INTO rg_c_X_rc<n> ... ON CONFLICT DO NOTHING
</syntaxhighlight>

== 10.6. Зріз останніх ==

<syntaxhighlight lang="sql">
-- РегістрВідомостей.КурсиВалют.ЗрізОстанніх(&Дата, Валюта В (&Список))
SELECT DISTINCT ON (r.d1_r)
r.d1_r AS "Валюта", r.period AS "Період", r.r1 AS "Курс", r.r2 AS "Кратність"
FROM rg_i_0007 r
WHERE r.period <= :Дата
AND r.d1_r = ANY (:Список)
ORDER BY r.d1_r, r.period DESC; -- використовує ix_rg_i_0007_d1 (d1_r, period DESC)
-- Для MS SQL: ROW_NUMBER() OVER (PARTITION BY d1_r ORDER BY period DESC) = 1
-- або OUTER APPLY (SELECT TOP 1 ...) для великих списків.
</syntaxhighlight>

= 11. Нефункціональні вимоги =

== 11.1. Продуктивність ==
Еталонний стенд: 16 vCPU, 128 ГБ RAM, NVMe, PostgreSQL 15, БД 1,5 ТБ.

{| class="wikitable"
! № !! Операція !! Обсяг !! Ціль (P95)
|-
| НФВ-01 || Залишки на поточну дату, відбір за 1 вимірюванням || 1 млрд рухів, 20 млн рядків підсумків || ≤ 200 мс
|-
| НФВ-02 || Залишки на довільну дату в межах ТА || те саме || ≤ 400 мс
|-
| НФВ-03 || Обороти за 12 місяців із групуванням || 1 млрд рухів || ≤ 2 с
|-
| НФВ-04 || Проведення документа зі 100 рядками рухів (3 регістри) || — || ≤ 300 мс
|-
| НФВ-05 || Оборотно-сальдова відомість по всіх рахунках за місяць || 200 млн проводок || ≤ 5 с
|-
| НФВ-06 || Розрахунок ЗП: 10 000 співробітників × 8 видів розрахунку || — || ≤ 10 хв
|-
| НФВ-07 || Зріз останніх по 5 000 елементів вимірювання || 50 млн записів РВ || ≤ 500 мс
|-
| НФВ-08 || Пропускна здатність проведення || — || ≥ 50 док/с (10 паралельних сеансів)
|-
| НФВ-09 || Перерахунок підсумків РН || 1 млрд рухів || ≤ 4 год (у вікні обслуговування)
|}

== 11.2. Масштабованість і обсяги ==
{| class="wikitable"
! Параметр !! Значення
|-
| Макс. записів в одному регістрі || 10<sup>10</sup>
|-
| Макс. кількість регістрів у конфігурації || 2 000
|-
| Макс. одночасних сеансів проведення || 200
|-
| Секціонування || Обов'язкове для таблиць > 100 млн записів
|}

== 11.3. Надійність і цілісність ==
* НФВ-10. Рухи та реєстратор змінюються в одній транзакції БД; часткове проведення неможливе.
* НФВ-11. Аварійне завершення сервера не залишає підсумки неузгодженими (гарантується транзакцією).
* НФВ-12. Сервіс перевірки цілісності (ФТ-41) виконується регламентно; розбіжність підсумків = інцидент P1.

== 11.4. Супроводжуваність ==
* НФВ-13. Реструктуризація регістру (додавання ресурсу/реквізиту) для таблиці ≤ 100 млн записів — ≤ 30 хв.
* НФВ-14. Додавання вимірювання вимагає перебудови підсумків; система повинна попереджати про оцінку часу до початку операції.
* НФВ-15. Усі DDL-операції — ідемпотентні та скриптовані (можливість застосувати вручну).

== 11.5. Сумісність ==
* НФВ-16. PostgreSQL 14+ та MS SQL Server 2019+ — обидві платформи з однаковою функціональністю.
* НФВ-17. Генератор DDL ізольований у шар «діалект СКБД».

= 12. Міграція існуючих структур K2 ERP =

== 12.1. Етапи ==
{| class="wikitable"
! № !! Етап !! Результат
|-
| М1 || Інвентаризація || Реєстр наявних «регістроподібних» таблиць K2 з класифікацією за типом-мішенню (РВ/РН/РБ/РР).
|-
| М2 || Мапінг || Для кожної таблиці — метаопис цільового регістру + правила перетворення колонок.
|-
| М3 || Створення регістрів || Генерація метаданих і DDL у тестовому контурі.
|-
| М4 || Перенесення даних || ETL: історичні дані → рухи, з призначенням реєстратора (реальний документ або службовий «ВведенняЗалишків»).
|-
| М5 || Побудова підсумків || Повний перерахунок.
|-
| М6 || Звірка || Порівняння залишків/оборотів «стара система vs нова» на контрольних датах; допуск розбіжності = 0.
|-
| М7 || Перемикання коду || Заміна прямих SQL-звернень на віртуальні таблиці; період паралельної роботи ≥ 1 звітний період.
|-
| М8 || Виведення з експлуатації || Видалення старих таблиць після 2 закритих періодів.
|}

== 12.2. Проблемні випадки ==
{| class="wikitable"
! Випадок !! Рішення
|-
| Історичні записи без документа-джерела || Службовий документ <code>ВведенняЗалишків</code> (один на період/розділ).
|-
| Записи з дублями за ключем (для незалежного РВ) || Дедуплікація з протоколом; конфлікти — на ручний розбір.
|-
| Дробові періоди / некоректні дати (NULL, 1900-01-01) || Нормалізація до MINPERIOD; протокол.
|-
| Прикладний код, що пише в таблиці напряму || Заборона на рівні прав БД після М7; аудит звернень на етапі М3–М6.
|-
| Аналітика, відсутня в цільовій моделі || Перенесення в реквізити (не у вимірювання) або відмова від міграції з обґрунтуванням.
|}

= 13. Приймальні випробування =

== 13.1. Функціональні тести (витяг) ==
{| class="wikitable"
! ID !! Сценарій !! Очікуваний результат
|-
| ФТ-Т-01 || Створити РВ періодичний незалежний, записати 2 записи з однаковим ключем || Другий запис заміщує перший; у таблиці 1 рядок
|-
| ФТ-Т-02 || Провести документ → 5 рухів РН || 5 записів у <code>rg_a_*</code>; підсумки MAXPERIOD змінилися на суму дельти
|-
| ФТ-Т-03 || Скасувати проведення || 0 записів; підсумки повернулися до вихідних значень
|-
| ФТ-Т-04 || Видалити документ-реєстратор || Рухи видалені каскадно; перевірка цілісності — 0 помилок
|-
| ФТ-Т-05 || Записати рух заднім числом (−6 міс.) || Залишки на всі дати після руху коректні (звірка з повним перерахунком)
|-
| ФТ-Т-06 || Установити <code>Активність = Хиба</code> || Запис не впливає на віртуальні таблиці; підсумки скориговані
|-
| ФТ-Т-07 || РБ: провести незбалансовану проводку (Дт ≠ Кт за балансовим ресурсом) || Помилка проведення, транзакція відкочена
|-
| ФТ-Т-08 || РБ: ОСВ по рахунку з 3 субконто || Підсумки за рівнями 0–3 узгоджені між собою (згортка tb3 → tb0)
|-
| ФТ-Т-09 || РР: сценарій «Оклад + Відпустка + Лікарняний» (розд. 7.5.1) || Фактичні періоди дії відповідають еталону; «Оклад» дає 2 інтервали
|-
| ФТ-Т-10 || РР: зміна базового запису || У таблиці перерахунку з'явився запис для залежного документа
|-
| ФТ-Т-11 || Паралельне проведення 2 документів за різними складами || Обидва проходять без очікування (розділення підсумків увімкнено)
|-
| ФТ-Т-12 || Паралельне проведення 2 документів за одним складом і одним товаром з контролем залишків || Один чекає, другий проходить; від'ємного залишку немає
|-
| ФТ-Т-13 || Перерахунок підсумків після хаотичних 10<sup>6</sup> операцій || Підсумки збігаються з повним перерахунком «з нуля» до копійки
|-
| ФТ-Т-14 || Реструктуризація: додати ресурс до РН із 10 млн записів || Дані збережені, підсумки перебудовані, час ≤ НФВ-13
|-
| ФТ-Т-15 || RLS: користувач з обмеженням по організації || Віртуальні таблиці повертають лише дозволені дані
|}

== 13.2. Навантажувальні тести ==
{| class="wikitable"
! ID !! Тест !! Критерій
|-
| НТ-01 || Генерація 1 млрд рухів РН, заміри НФВ-01…НФВ-03 || Досягнення цілей
|-
| НТ-02 || Профіль «90 % рухів поточним періодом, 10 % заднім числом» — порівняння двох стратегій підсумків (розд. 10.2) || Обґрунтований вибір Рішення №3
|-
| НТ-03 || Пікове проведення 50 док/с протягом 1 год || Відсутність дедлоків; P95 ≤ НФВ-04
|-
| НТ-04 || РБ: субконто-слоти vs дочірня таблиця, 200 млн проводок || Обґрунтований вибір Рішення №2
|-
| НТ-05 || Розрахунок ЗП на 10 000 співробітників || НФВ-06
|-
| НТ-06 || Деградація за 24 год безперервної роботи || Приріст часу відгуку ≤ 15 %
|}

= 14. Етапи робіт та оцінка =

{| class="wikitable"
! Етап !! Зміст !! Результат !! Оцінка, чол.-міс. !! Залежності
|-
| '''Е0''' || Обстеження платформи, верифікація припущень П1–П6, ескізний проєкт || Затверджений архітектурний ескіз, уточнене ТЗ || 1,5 || —
|-
| '''Е1''' || Метамодель + репозиторій + генератор DDL + конструктор (базовий) || Створення регістру будь-якого типу з генерацією схеми || 4 || Е0
|-
| '''Е2''' || Регістр відомостей: рантайм, набори записів, зрізи, форми || РВ у продуктиві || 2,5 || Е1
|-
| '''Е3''' || Регістр накопичення: рухи, підсумки, ТА, віртуальні таблиці || РН у продуктиві || 5 || Е2
|-
| '''Е4''' || Механізм проведення документів, блокування, оперативне/неоперативне проведення || Транзакційне проведення || 2,5 || Е3
|-
| '''Е5''' || Розширення мови запитів (віртуальні таблиці, транслятор, push-down) || Запити до ВТ || 4 || Е3
|-
| '''Е6''' || Регістр бухгалтерії + план рахунків + субконто + підсумки за рівнями || РБ у продуктиві || 6 || Е4, Е5
|-
| '''Е7''' || Регістр розрахунку + ПВР + витіснення + база + графіки + перерахунки || РР у продуктиві || 6 || Е4, Е5
|-
| '''Е8''' || Агрегати, розділення підсумків, порадник агрегатів || Оптимізація || 2,5 || Е3
|-
| '''Е9''' || Права доступу, RLS, аудит, сервіси цілісності || Безпека та адміністрування || 2 || Е6, Е7
|-
| '''Е10''' || Реструктуризація, міграція, інструменти звірки || Інструменти міграції || 2,5 || Е6, Е7
|-
| '''Е11''' || Навантажувальне тестування, оптимізація, документація || Приймальні випробування || 3 || усі
|-
| colspan="3" | '''РАЗОМ''' || '''41,5''' ||
|}

{{Note|Оцінка орієнтовна (±40 %) і підлягає уточненню за результатами Е0. Критичний шлях: Е0 → Е1 → Е3 → Е5 → Е6/Е7 → Е11. За командою 6–8 інженерів — орієнтовно 9–11 календарних місяців.}}

'''Мінімальний життєздатний обсяг (MVP)''': Е0–Е5 (РВ + РН + проведення + запити) ≈ 19,5 чол.-міс. — покриває ~70 % прикладних сценаріїв K2 ERP.

= 15. Ризики =

{| class="wikitable"
! ID !! Ризик !! Ймов. !! Вплив !! Пом'якшення
|-
| Р1 || У K2 ERP немає власної мови запитів → віртуальні таблиці нікуди вбудовувати || Сер. || '''Крит.''' || Верифікувати на Е0. План «Б»: віртуальні таблиці як параметризовані view/TVF + шар ORM.
|-
| Р2 || Конкуренція за таблицю підсумків на піках проведення || Вис. || Вис. || Розділення підсумків (сплітери), НТ-03, детермінований порядок MERGE.
|-
| Р3 || Рухи «заднім числом» роблять оновлення підсумків O(N періодів) || Вис. || Сер. || Рішення №3 (dirty months + регламентний перерахунок), НТ-02.
|-
| Р4 || «Широка» схема субконто → реструктуризація при зміні ліміту || Сер. || Сер. || Зафіксувати ліміт 5 із запасом; НТ-04; план «Б» — дочірня таблиця.
|-
| Р5 || Механізм витіснення РР — найскладніший і найпомилковіший вузол || Вис. || Вис. || Виділити в окремий модуль з еталонним набором з 50+ тест-кейсів; property-based тестування.
|-
| Р6 || Обсяг Е6+Е7 недооцінено (досвід 1С: це роки розробки) || Вис. || Вис. || MVP-підхід: спершу Е0–Е5, рішення про Е6/Е7 — після ретроспективи.
|-
| Р7 || Різна поведінка PostgreSQL і MS SQL (плани, MERGE, ізоляція) || Сер. || Сер. || Єдиний набір тестів на обох СКБД у CI від Е1.
|-
| Р8 || Міграція історичних даних без реєстраторів || Вис. || Сер. || Службовий документ «ВведенняЗалишків»; етап звірки М6 з нульовим допуском.
|-
| Р9 || Патентні / ліцензійні претензії щодо копіювання механізмів || Низ. || Вис. || Юридична експертиза до Е1: реалізація ''концепцій'' обліку (загальновідомих), а не коду/API; уникати дослівного копіювання найменувань API та документації.
|}

{{Note|'''Ризик Р9 — обов'язково до опрацювання перед стартом.''' ТЗ описує ''функціональні концепції'' (накопичувальний облік, подвійний запис, витіснення періодів дії), що є загальновідомими практиками обліку. Проте пряме відтворення пропрієтарних інтерфейсів, найменувань і структур конкретного вендора потребує окремої правової оцінки. Рекомендується узгодити з юридичною службою власну термінологію та API до початку Е1.}}

= 16. Додатки =

== Додаток А. Матриця відповідності «1С ↔ K2 ERP» ==

{| class="wikitable"
! Об'єкт / поняття 1С !! Пропонований аналог K2 ERP !! Примітка
|-
| РегистрСведений || <code>Регістри.Відомостей.*</code> || Повний паритет
|-
| РегистрНакопления || <code>Регістри.Накопичення.*</code> || Повний паритет
|-
| РегистрБухгалтерии || <code>Регістри.Бухгалтерії.*</code> || Субконто зберігаються інакше (слоти)
|-
| РегистрРасчета || <code>Регістри.Розрахунку.*</code> || Повний паритет
|-
| Регистратор || <code>Реєстратор</code> || —
|-
| ВидДвижения || <code>ВидРуху</code> || —
|-
| Итоги || <code>Підсумки</code> || —
|-
| Точка актуальности итогов || <code>ТА підсумків</code> || —
|-
| Разделение итогов || <code>Розділення підсумків</code> (splitter) || —
|-
| Агрегаты || <code>Агрегати</code> || —
|-
| Субконто / ПланВидовХарактеристик || <code>Субконто</code> / <code>ПланВидівХарактеристик</code> || —
|-
| ПланВидовРасчета || <code>ПланВидівРозрахунку</code> || —
|-
| Перерасчет || <code>Перерахунок</code> || —
|-
| ПериодДействия / Вытеснение || <code>ПеріодДії</code> / <code>Витіснення</code> || —
|-
| Границя послідовності || '''Не реалізується''' || Механізм визнано застарілим; замість нього — перепроведення за списком «брудних» документів
|-
| РегистрыСведений з режимом «ПоПозицииРегистратора» || <code>ПоПозиціїРеєстратора</code> || Реалізується як (period, rec_t, rec_r, line_no) у ключі
|}

== Додаток Б. Альтернатива зберігання субконто (план «Б» до Рішення №2) ==

<syntaxhighlight lang="sql">
-- Дочірня таблиця «ключ-значення» замість слотів
CREATE TABLE rg_b_0020_ed (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
side smallint NOT NULL CHECK (side IN (0,1)), -- 0=Дт, 1=Кт
ed_no smallint NOT NULL, -- порядковий номер субконто рахунка
ed_type_r uuid NOT NULL, -- вид субконто
val_t smallint NOT NULL,
val_r uuid,
val_n numeric(38,10),
val_s varchar(150),
val_d timestamp(0),
PRIMARY KEY (rec_t, rec_r, line_no, side, ed_no),
FOREIGN KEY (rec_t, rec_r, line_no) REFERENCES rg_b_0020 (rec_t, rec_r, line_no) ON DELETE CASCADE
);
CREATE INDEX ix_rg_b_0020_ed_val ON rg_b_0020_ed (ed_type_r, val_t, val_r);
</syntaxhighlight>

{| class="wikitable"
! Критерій !! Слоти (Рішення №2) !! Дочірня таблиця (план «Б»)
|-
| Відбір за 1 субконто || Index seek по колонці || JOIN + семі-з'єднання
|-
| Відбір за 3 субконто || 3 предикати в одному скані || 3 JOIN
|-
| Зміна <code>МаксКількістьСубконто</code> || ALTER TABLE (реструктуризація) || Без змін схеми
|-
| Розмір рядка проводки || +48 байт × 2 (Дт/Кт) || Базовий
|-
| Складність генератора DDL || Вища || Нижча
|-
| '''Рекомендація''' || '''Обрано за замовчуванням''' || Резерв за результатами НТ-04
|}

== Додаток В. Перелік вимог (реєстр трасування) ==

{| class="wikitable sortable"
! ID !! Розділ !! Коротко !! Пріоритет !! Тест
|-
| ФТ-01…ФТ-07 || 7.1 || Набори записів, проведення || Must || ФТ-Т-02…04
|-
| ФТ-08…ФТ-10 || 7.2 || Активність || Must || ФТ-Т-06
|-
| ФТ-11…ФТ-13 || 7.3 || Віртуальні таблиці || Must || ФТ-Т-08, НТ-01
|-
| ФТ-14…ФТ-18 || 7.4 || Підсумки, ТА || Must || ФТ-Т-05, ФТ-Т-13
|-
| ФТ-19…ФТ-21 || 7.4.4 || Агрегати || Should || НТ-01
|-
| ФТ-22…ФТ-30 || 7.5 || Механіка РР || Must (для Е7) || ФТ-Т-09, ФТ-Т-10
|-
| ФТ-31…ФТ-36 || 7.7 || Блокування || Must || ФТ-Т-11, ФТ-Т-12, НТ-03
|-
| ФТ-37…ФТ-39 || 7.8 || Права, RLS || Must || ФТ-Т-15
|-
| ФТ-40…ФТ-42 || 7.9 || Аудит, цілісність || Should || ФТ-Т-04
|-
| ФТ-К-01…06 || 6.8.4 || Конструктор || Should || —
|-
| НФВ-01…НФВ-09 || 11.1 || Продуктивність || Must || НТ-01…НТ-06
|-
| НФВ-10…НФВ-12 || 11.3 || Цілісність || Must || ФТ-Т-13
|-
| НФВ-13…НФВ-17 || 11.4–11.5 || Супровід, сумісність || Should || ФТ-Т-14
|}

== Додаток Г. Відкриті питання ==

{| class="wikitable"
! № !! Питання !! Кому !! Термін
|-
| В1 || Чи існує в K2 ERP мова запитів / транслятор у SQL? (визначає Р1 та обсяг Е5) || Архітектор платформи || До Е0
|-
| В2 || Формат ідентифікації об'єктів: UUID чи сурогатний int? || Архітектор платформи || До Е0
|-
| В3 || Чи потрібна мілісекундна дискретність періоду? || Замовник || До Е1
|-
| В4 || Максимальна кількість субконто: 3 чи 5? || Головний бухгалтер / методолог || До Е6
|-
| В5 || Чи потрібен механізм «Границя послідовності»? (пропонується відмова) || Методолог || До Е3
|-
| В6 || Пріоритет типів регістрів: чи достатньо MVP (РВ + РН) для першого релізу? || Замовник || До Е0
|-
| В7 || Правова оцінка ризику Р9 || Юридична служба || До Е1
|-
| В8 || Цільова СКБД для першої черги: тільки PostgreSQL чи одразу обидві? || Архітектор / ІТ-експлуатація || До Е1
|-
| В9 || '''Міжпланова база розрахунку:''' чи потрібна можливість брати базу з ''іншого'' регістру розрахунку (Утримання ← ОсновніНарахування)? Якщо так — ФТ-25 і <code>md_register</code> потребують розширення полем <code>base_register_id</code> (див. Д.7.2) || Методолог ЗП / архітектор || До Е7
|-
| В10 || Чи прийнятна поведінка підпорядкованого РВ без контролю унікальності за (Період + Вимірювання)? (сумісність із 1С vs. захист від дублів — див. Д.3.2, антипатерн А-6) || Методолог || До Е2
|}

== Додаток Д. Каталог прикладів регістрів ==

Додаток містить прикладні приклади регістрів усіх типів і підвидів. Для кожного наведено: декларацію (DSL), пояснення проєктних рішень, приклад даних у фізичних таблицях і типовий запит. Приклади призначені для: (а) перевірки повноти метамоделі на етапі Е0; (б) формування набору приймальних тестів; (в) навчання прикладних розробників.

=== Д.1. Як обрати тип регістру (дерево рішень) ===

<graphviz>
digraph Choose {
rankdir=TB; bgcolor="transparent";
node [shape=box, style="rounded,filled", fontname="Helvetica", fontsize=9];
edge [fontname="Helvetica", fontsize=8];

q1 [label="Що зберігаємо?", shape=diamond, fillcolor="#ffe0b2"];
q2 [label="Потрібні залишки\n(скільки Є зараз)?", shape=diamond, fillcolor="#ffe0b2"];
q3 [label="Подвійний запис,\nплан рахунків,\nсубконто?", shape=diamond, fillcolor="#ffe0b2"];
q4 [label="Періоди дії,\nвитіснення,\nбаза розрахунку?", shape=diamond, fillcolor="#ffe0b2"];
q5 [label="Значення прив'язане\nдо документа?", shape=diamond, fillcolor="#ffe0b2"];

ri_i [label="РВ незалежний\n(КурсиВалют,\nШтрихкоди)", fillcolor="#e8f5e9"];
ri_s [label="РВ підпорядкований\n(ЦіниНоменклатури,\nКадровіДані)", fillcolor="#e8f5e9"];
ra_b [label="РН «Залишки»\n(ТовариНаСкладах,\nВзаєморозрахунки)", fillcolor="#fff8e1"];
ra_t [label="РН «Обороти»\n(Продажі,\nВитрати)", fillcolor="#fff8e1"];
rb [label="РБ\n(Госпрозрахунковий)", fillcolor="#fce4ec"];
rc [label="РР\n(Нарахування,\nУтримання)", fillcolor="#ede7f6"];

q1 -> q3 [label="облікові проводки"];
q3 -> rb [label="так"];
q3 -> q4 [label="ні"];
q4 -> rc [label="так"];
q4 -> q2 [label="ні"];

q1 -> q2 [label="кількісні/сумові\nрухи"];
q2 -> ra_b [label="так"];
q2 -> ra_t [label="ні,\nлише обороти\nза період"];

q1 -> q5 [label="значення\nатрибута\nв часі"];
q5 -> ri_s [label="так"];
q5 -> ri_i [label="ні"];
}
</graphviz>

'''Контрольні питання при проєктуванні будь-якого регістру:'''
# Чи можна відповісти на всі прикладні питання ''лише'' полями цього регістру, без з'єднання з документами? Якщо ні — бракує реквізиту (не вимірювання!).
# Яка ''кардинальність'' таблиці підсумків = ∏(кількість значень вимірювань) × кількість періодів? Якщо > 10<sup>8</sup> — переглянути склад вимірювань.
# Чи потрібно фільтрувати/групувати за цим полем у звітах? Так → вимірювання. Ні, лише показувати → реквізит.
# Чи підсумовується поле? Так → ресурс. Ні → реквізит або вимірювання.

=== Д.2. Зведений каталог ===

{| class="wikitable sortable"
! № !! Регістр !! Тип !! Підвид / режим !! Вимірювання !! Ресурси !! Розділ
|-
| 1 || КурсиВалют || РВ || Періодичний (день), незалежний || Валюта || Курс, Кратність || Д.3.1
|-
| 2 || ЦіниНоменклатури || РВ || Періодичний (день), підпорядкований || Номенклатура, Характеристика, ТипЦін || Ціна || Д.3.2
|-
| 3 || ШтрихкодиНоменклатури || РВ || Неперіодичний, незалежний || Штрихкод || Номенклатура, Характеристика, Упаковка || Д.3.3
|-
| 4 || ГрафікРоботи || РВ || Неперіодичний, незалежний || ВидГрафіка, ДатаГрафіка || Значення, Годин || Д.3.4
|-
| 5 || КадровіДані || РВ || По позиції реєстратора, підпорядкований || Співробітник || Підрозділ, Посада, Ставка, ВидЗайнятості || Д.3.5
|-
| 6 || НалаштуванняКористувачів || РВ || Неперіодичний, незалежний || Користувач, Налаштування || Значення (складений) || Д.3.6
|-
| 7 || ТовариНаСкладах || РН || Залишки || Номенклатура, Склад, Партія, Характеристика || Кількість, Сума || Д.4.1
|-
| 8 || ВзаєморозрахункиЗКонтрагентами || РН || Залишки || Організація, Контрагент, Договір, Замовлення || Сума, СумаВал || Д.4.2
|-
| 9 || ТовариВРезерві || РН || Залишки || Номенклатура, Склад, Замовлення, Характеристика || Кількість || Д.4.3
|-
| 10 || ГрошовіКоштиБезготівкові || РН || Залишки || Організація, БанківськийРахунок || Сума, СумаВал || Д.4.4
|-
| 11 || Продажі || РН || Обороти (місяць) + агрегати || Номенклатура, Контрагент, Договір, Менеджер, Склад || Кількість, Сума, СумаБезПДВ, Собівартість || Д.5.1
|-
| 12 || ВитратиЗаСтаттями || РН || Обороти (місяць) || Організація, Підрозділ, СтаттяВитрат, Проєкт || Сума || Д.5.2
|-
| 13 || Госпрозрахунковий || РБ || З кореспонденцією || Організація (бал.), Підрозділ (небал.) || Сума (бал.), Кількість, ВалютнаСума || Д.6.1
|-
| 14 || ПодатковийОблік || РБ || Без кореспонденції || Організація, ВидРізниці || Сума || Д.6.2
|-
| 15 || Бюджетування || РБ || З кореспонденцією || Сценарій, ЦФВ, Проєкт || Сума || Д.6.3
|-
| 16 || ОсновніНарахування || РР || Період дії + база за періодом дії || Співробітник (баз.), Підрозділ || Результат, ВідпрацьованоДнів, НормаДнів || Д.7.1
|-
| 17 || Утримання || РР || Без періоду дії, база за періодом реєстрації || Співробітник (баз.), Підрозділ || Результат, БазаОподаткування || Д.7.2
|}

=== Д.3. Регістри відомостей ===

==== Д.3.1. КурсиВалют — періодичний, незалежний ====

'''Задача:''' зберігати історію курсів валют; отримувати курс на будь-яку дату.

<syntaxhighlight lang="yaml">
register:
name: КурсиВалют
kind: Information
synonym: "Курси валют"
periodicity: WithinDay # один курс на валюту на день
writeMode: Independent # курси вводяться вручну/завантажуються з НБУ
dimensions:
- { name: Валюта, type: "Довідник.Валюти", master: true, denyEmpty: true }
resources:
- { name: Курс, type: "Число(15,4)", denyEmpty: true }
- { name: Кратність, type: "Число(10,0)", default: 1 }
</syntaxhighlight>

'''Проєктні рішення:'''
* <code>Independent</code> — курс не породжується документом, він є зовнішнім фактом.
* <code>master: true</code> для Валюти — при видаленні валюти курси видаляються; регістр видно у формі елемента довідника.
* Періодичність <code>WithinDay</code>, а не <code>WithinSecond</code> — повторний запис курсу за той самий день ''замістить'' попередній, а не створить дубль.

'''Дані у таблиці <code>rg_i_0007</code>:'''
{| class="wikitable"
! period !! d1_r (Валюта) !! r1 (Курс) !! r2 (Кратність)
|-
| 2026-07-15 00:00:00 || USD || 41.8200 || 1
|-
| 2026-07-15 00:00:00 || EUR || 45.6100 || 1
|-
| 2026-07-16 00:00:00 || USD || 41.8500 || 1
|-
| 2026-07-17 00:00:00 || USD || 41.9000 || 1
|-
| 2026-07-17 00:00:00 || EUR || 45.7300 || 1
|}

'''Запит (курс на дату документа):'''
<syntaxhighlight lang="sql">
ВИБРАТИ Курси.Курс, Курси.Кратність
З РегістрВідомостей.КурсиВалют.ЗрізОстанніх(&ДатаДокумента, Валюта = &Валюта) ЯК Курси
</syntaxhighlight>

<syntaxhighlight lang="csharp">
// або через менеджер
var курс = Registers.Information["КурсиВалют"]
.GetLast(doc.Дата, new Filter { ["Валюта"] = doc.Валюта });
decimal сумаГрн = doc.СумаВалюти * курс.Курс / курс.Кратність;
</syntaxhighlight>

==== Д.3.2. ЦіниНоменклатури — періодичний, підпорядкований реєстратору ====

'''Задача:''' зберігати історію цін; ціна встановлюється наказом (документом), який можна скасувати.

<syntaxhighlight lang="yaml">
register:
name: ЦіниНоменклатури
kind: Information
synonym: "Ціни номенклатури"
periodicity: WithinDay
writeMode: SubordinateToRecorder # ← ключова відмінність від КурсиВалют
dimensions:
- { name: Номенклатура, type: "Довідник.Номенклатура", master: true, index: true }
- { name: Характеристика, type: "Довідник.ХарактеристикиНоменклатури", nullable: true }
- { name: ТипЦін, type: "Довідник.ТипиЦін", master: true, denyEmpty: true }
resources:
- { name: Ціна, type: "Число(15,2)", denyEmpty: true }
attributes:
- { name: Валюта, type: "Довідник.Валюти" }
- { name: Одиниця, type: "Довідник.ОдиниціВиміру" }
recorders:
- Документ.ВстановленняЦінНоменклатури
</syntaxhighlight>

'''Проєктні рішення:'''
* <code>SubordinateToRecorder</code> — потрібна юридична прив'язка ціни до наказу, можливість скасувати наказ і «відкотити» ціни одним рухом.
* <code>Валюта</code> і <code>Одиниця</code> — '''реквізити''', а не вимірювання: за ними не фільтрують і не будують зрізи, вони визначаються типом цін. ''Помилка новачка'' — зробити Валюту вимірюванням, що подвоїть кількість записів і зламає зріз останніх.
* <code>Характеристика</code> дозволяє порожнє значення — для номенклатури без характеристик.

'''Дані у таблиці <code>rg_i_0010</code>:'''
{| class="wikitable"
! rec_t !! rec_r !! line_no !! period !! active !! d1_r (Номенкл.) !! d2_r (Характ.) !! d3_r (ТипЦін) !! r1 (Ціна) !! a1_r (Валюта)
|-
| 15 || a3f…01 || 1 || 2026-07-01 || true || Кава Lavazza 1кг || ''(порожня)'' || Роздрібна || 480.00 || UAH
|-
| 15 || a3f…01 || 2 || 2026-07-01 || true || Кава Lavazza 1кг || ''(порожня)'' || Оптова || 410.00 || UAH
|-
| 15 || a3f…01 || 3 || 2026-07-01 || true || Чай Ahmad 100г || ''(порожня)'' || Роздрібна || 95.00 || UAH
|-
| 15 || b7c…04 || 1 || 2026-07-15 || true || Кава Lavazza 1кг || ''(порожня)'' || Роздрібна || 495.00 || UAH
|}

{{Note|Зверніть увагу: у підпорядкованому РВ '''немає''' унікальності за (Період + Вимірювання). Два різні документи можуть встановити ціну на ту саму дату — платформа це дозволить, зріз останніх поверне запис із більшим <code>line_no</code> у межах реєстратора з пізнішою позицією. Це '''свідома''' поведінка (сумісність із 1С), але прикладний розробник має контролювати дублі самостійно — див. антипатерн А-6 (Д.10).}}

==== Д.3.3. ШтрихкодиНоменклатури — неперіодичний, незалежний ====

'''Задача:''' за штрихкодом знайти номенклатуру. Класичний приклад «вимірювання = те, ''за чим'' шукаємо; ресурс = те, що ''знаходимо''».

<syntaxhighlight lang="yaml">
register:
name: ШтрихкодиНоменклатури
kind: Information
periodicity: Nonperiodical
writeMode: Independent
dimensions:
- { name: Штрихкод, type: "Рядок(30)", denyEmpty: true } # ← ключ пошуку
resources:
- { name: Номенклатура, type: "Довідник.Номенклатура", denyEmpty: true }
- { name: Характеристика, type: "Довідник.ХарактеристикиНоменклатури", nullable: true }
- { name: Упаковка, type: "Довідник.УпаковкиНоменклатури", nullable: true }
</syntaxhighlight>

<syntaxhighlight lang="sql">
CREATE TABLE rg_i_0011 (
d1_s varchar(30) NOT NULL, -- Штрихкод
r1_r uuid NOT NULL, -- Номенклатура
r2_r uuid NOT NULL, -- Характеристика
r3_r uuid NOT NULL, -- Упаковка
CONSTRAINT pk_rg_i_0011 PRIMARY KEY (d1_s) -- ← унікальність штрихкоду «безкоштовно»
);
CREATE INDEX ix_rg_i_0011_r1 ON rg_i_0011 (r1_r); -- зворотний пошук: штрихкоди товару
</syntaxhighlight>

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

==== Д.3.4. ГрафікРоботи — неперіодичний, незалежний (використовується як графік для РР) ====

<syntaxhighlight lang="yaml">
register:
name: ГрафікРоботи
kind: Information
periodicity: Nonperiodical
writeMode: Independent
dimensions:
- { name: ВидГрафіка, type: "Довідник.ГрафікиРоботи", master: true, denyEmpty: true }
- { name: ДатаГрафіка, type: "Дата", denyEmpty: true } # ← вимірювання типу Дата, не Період!
resources:
- { name: Значення, type: "Число(1,0)" } # 1 = робочий день, 0 = вихідний
- { name: Годин, type: "Число(4,2)" } # тривалість зміни
</syntaxhighlight>

'''Проєктне рішення (важливе):''' <code>ДатаГрафіка</code> — це '''вимірювання''' типу <code>Дата</code>, а не стандартний реквізит <code>Період</code>. Регістр '''неперіодичний'''. Причина: графік описує ''календар'' (кожна дата — окремий факт), а не ''історію зміни значення''. Якби використали періодичність, зріз останніх повертав би «останній робочий день», що безглуздо. Механізм РР (<code>ДаніГрафіка</code>) очікує саме таку структуру.

'''Дані у таблиці <code>rg_i_0015</code>:'''
{| class="wikitable"
! d1_r (ВидГрафіка) !! d2_d (ДатаГрафіка) !! r1 (Значення) !! r2 (Годин)
|-
| П'ятиденка || 2026-07-01 || 1 || 8.00
|-
| П'ятиденка || 2026-07-04 || 0 || 0.00
|-
| П'ятиденка || 2026-07-05 || 0 || 0.00
|-
| П'ятиденка || 2026-07-06 || 1 || 8.00
|-
| Змінний 2/2 || 2026-07-01 || 1 || 12.00
|-
| Змінний 2/2 || 2026-07-03 || 0 || 0.00
|}

==== Д.3.5. КадровіДані — по позиції реєстратора ====

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

<syntaxhighlight lang="yaml">
register:
name: КадровіДані
kind: Information
periodicity: ByRecorderPosition # ← упорядкування за позицією документа, не лише за датою
writeMode: SubordinateToRecorder
dimensions:
- { name: Співробітник, type: "Довідник.Співробітники", master: true, denyEmpty: true }
resources:
- { name: Підрозділ, type: "Довідник.Підрозділи" }
- { name: Посада, type: "Довідник.Посади" }
- { name: Ставка, type: "Число(5,2)" }
- { name: ВидЗайнятості, type: "Перерахування.ВидиЗайнятості" }
- { name: ГрафікРоботи, type: "Довідник.ГрафікиРоботи" }
recorders:
- Документ.ПрийомНаРоботу
- Документ.КадровеПереміщення
- Документ.Звільнення
</syntaxhighlight>

'''Проєктне рішення:''' <code>ByRecorderPosition</code> — коли два накази оформлені однією датою (переміщення + зміна ставки), звичайна періодичність «у межах дня» дала б недетермінований результат зрізу. Позиція реєстратора додає до ключа <code>(rec_t, rec_r, line_no)</code> і впорядковує за моментом часу документа.

'''Фізична схема:'''
<syntaxhighlight lang="sql">
CREATE TABLE rg_i_0016 (
period timestamp(0) NOT NULL,
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
active boolean NOT NULL DEFAULT true,
d1_r uuid NOT NULL, -- Співробітник
r1_r uuid NOT NULL, r2_r uuid NOT NULL,
r3 numeric(5,2) NOT NULL,
r4 smallint NOT NULL, -- Перерахування зберігається як порядковий номер
r5_r uuid NOT NULL,
CONSTRAINT pk_rg_i_0016 PRIMARY KEY (period, rec_t, rec_r, line_no) -- ← Період у ключі ПЕРШИЙ
);
CREATE INDEX ix_rg_i_0016_d1 ON rg_i_0016 (d1_r, period DESC, rec_t, rec_r, line_no DESC)
WHERE active;
</syntaxhighlight>

==== Д.3.6. НалаштуванняКористувачів — складений тип ресурсу ====

<syntaxhighlight lang="yaml">
register:
name: НалаштуванняКористувачів
kind: Information
periodicity: Nonperiodical
writeMode: Independent
dimensions:
- { name: Користувач, type: "Довідник.Користувачі", master: true }
- { name: Налаштування, type: "ПланВидівХарактеристик.НалаштуванняКористувачів", master: true }
resources:
- name: Значення
type: ["Рядок(500)", "Число(15,2)", "Дата", "Булево",
"Довідник.Організації", "Довідник.Склади"] # ← складений тип
</syntaxhighlight>

<syntaxhighlight lang="sql">
CREATE TABLE rg_i_0018 (
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
r1_t smallint NOT NULL, -- код типу значення
r1_b boolean,
r1_n numeric(15,2),
r1_s varchar(500),
r1_d timestamp(0),
r1_r uuid,
CONSTRAINT pk_rg_i_0018 PRIMARY KEY (d1_r, d2_r)
);
</syntaxhighlight>

{| class="wikitable"
! d1_r !! d2_r !! r1_t !! r1_b !! r1_n !! r1_s !! r1_d !! r1_r
|-
| Іваненко || ОсновнаОрганізація || 101 || || || || || ТОВ «Альфа»
|-
| Іваненко || ОсновнийСклад || 104 || || || || || Центральний
|-
| Іваненко || ПоказуватиПідказки || 2 || true || || || ||
|-
| Петренко || КількістьРядківСписку || 3 || || 50 || || ||
|}

=== Д.4. Регістри накопичення, вид «Залишки» ===

==== Д.4.1. ТовариНаСкладах ====

Декларація — розділ 6.7, фізична схема — розділ 8.5, ER — розділ 9.2. Тут — дані.

'''Рухи (<code>rg_a_0012</code>) після проведення трьох документів:'''
{| class="wikitable"
! rec_t !! rec_r !! line_no !! period !! mvt !! d1_r (Номенкл.) !! d2_r (Склад) !! r1 (К-сть) !! r2 (Сума)
|-
| 2 (ПрихНакл) || p1 || 1 || 2026-06-10 || 0 ''Прихід'' || Кава Lavazza || Центральний || 100.000 || 35 000.00
|-
| 2 (ПрихНакл) || p1 || 2 || 2026-06-10 || 0 ''Прихід'' || Чай Ahmad || Центральний || 200.000 || 12 000.00
|-
| 3 (ВидНакл) || v1 || 1 || 2026-07-05 || 1 ''Витрата'' || Кава Lavazza || Центральний || 30.000 || 10 500.00
|-
| 4 (Переміщ) || m1 || 1 || 2026-07-12 || 1 ''Витрата'' || Кава Lavazza || Центральний || 20.000 || 7 000.00
|-
| 4 (Переміщ) || m1 || 2 || 2026-07-12 || 0 ''Прихід'' || Кава Lavazza || Роздрібний || 20.000 || 7 000.00
|}

'''Підсумки залишків (<code>rg_a_0012_tb</code>), ТА = 2026-07-31:'''
{| class="wikitable"
! period !! d1_r !! d2_r !! r1 (К-сть ±) !! r2 (Сума ±) !! Коментар
|-
| 2026-07-01 || Кава Lavazza || Центральний || 100.000 || 35 000.00 || залишок ''на початок'' липня
|-
| 2026-07-01 || Чай Ahmad || Центральний || 200.000 || 12 000.00 ||
|-
| 2026-08-01 || Кава Lavazza || Центральний || 50.000 || 17 500.00 || 100 − 30 − 20
|-
| 2026-08-01 || Кава Lavazza || Роздрібний || 20.000 || 7 000.00 ||
|-
| 2026-08-01 || Чай Ahmad || Центральний || 200.000 || 12 000.00 ||
|-
| '''5999-11-01''' || Кава Lavazza || Центральний || 50.000 || 17 500.00 || '''MAXPERIOD''' — поточний залишок
|-
| '''5999-11-01''' || Кава Lavazza || Роздрібний || 20.000 || 7 000.00 || '''MAXPERIOD'''
|-
| '''5999-11-01''' || Чай Ahmad || Центральний || 200.000 || 12 000.00 || '''MAXPERIOD'''
|}

''(Вимірювання Партія і Характеристика для стислості опущені.)''

==== Д.4.2. ВзаєморозрахункиЗКонтрагентами ====

'''Задача:''' облік дебіторської/кредиторської заборгованості в розрізі договорів і замовлень.

<syntaxhighlight lang="yaml">
register:
name: ВзаєморозрахункиЗКонтрагентами
kind: Accumulation
accumulationKind: Balance
periodicity: WithinSecond
enableBalanceTotals: true
enableTurnoverTotals: true
partitioning: { mode: RangeByPeriod, step: month }
dimensions:
- { name: Організація, type: "Довідник.Організації", denyEmpty: true, index: true }
- { name: Контрагент, type: "Довідник.Контрагенти", master: true, index: true }
- { name: Договір, type: "Довідник.ДоговориКонтрагентів", master: true, index: true }
- { name: Замовлення, type: ["Документ.ЗамовленняПокупця", "Документ.ЗамовленняПостачальнику"],
nullable: true }
resources:
- { name: Сума, type: "Число(15,2)" } # у валюті регламентованого обліку
- { name: СумаВал, type: "Число(15,2)" } # у валюті договору
attributes:
- { name: Коментар, type: "Рядок(200)" }
recorders:
- Документ.ВидатковаНакладна
- Документ.ПрихіднаНакладна
- Документ.ПлатіжнеДоручення
- Документ.КасовийОрдер
- Документ.КоригуванняБоргу
</syntaxhighlight>

'''Угода про знак (обов'язково фіксується в методології!):'''
{| class="wikitable"
! Вид руху !! Сенс !! Приклад документа
|-
| '''Прихід''' || Борг контрагента перед нами '''зростає''' (дебіторка +) || Видаткова накладна
|-
| '''Витрата''' || Борг контрагента перед нами '''зменшується''' (оплата) || Платіжне доручення вхідне
|}
Кредиторська заборгованість = від'ємний залишок. ''Альтернатива'' — два окремих ресурси (СумаДт/СумаКт) або два регістри; обраний варіант — один знаковий ресурс (простіше, менший обсяг підсумків).

'''Приклад даних:'''
{| class="wikitable"
! Документ !! period !! mvt !! Контрагент !! Договір !! r1 (Сума) !! Залишок після
|-
| ВидатковаНакладна №12 || 2026-07-05 || Прихід || ТОВ «Бета» || Основний || 12 000.00 || +12 000 ''(винні нам)''
|-
| ПлатіжнеДоручення №88 || 2026-07-09 || Витрата || ТОВ «Бета» || Основний || 8 000.00 || +4 000
|-
| ПлатіжнеДоручення №91 || 2026-07-16 || Витрата || ТОВ «Бета» || Основний || 6 000.00 || −2 000 ''(передоплата)''
|}

'''Запит (акт звірки):'''
<syntaxhighlight lang="sql">
ВИБРАТИ
Дані.Контрагент, Дані.Договір,
Дані.СумаПочатковийЗалишок, Дані.СумаПрихід,
Дані.СумаВитрата, Дані.СумаКінцевийЗалишок
З РегістрНакопичення.ВзаєморозрахункиЗКонтрагентами.ЗалишкиІОбороти(
&Початок, &Кінець, Авто, Рух,
Організація = &Організація І Контрагент = &Контрагент
) ЯК Дані
</syntaxhighlight>

==== Д.4.3. ТовариВРезерві — регістр «супутник» ====

<syntaxhighlight lang="yaml">
register:
name: ТовариВРезерві
kind: Accumulation
accumulationKind: Balance
periodicity: WithinSecond
dimensions:
- { name: Номенклатура, type: "Довідник.Номенклатура", master: true, index: true }
- { name: Характеристика, type: "Довідник.ХарактеристикиНоменклатури", nullable: true }
- { name: Склад, type: "Довідник.Склади", master: true, index: true }
- { name: Замовлення, type: "Документ.ЗамовленняПокупця", master: true, denyEmpty: true }
resources:
- { name: Кількість, type: "Число(15,3)" }
recorders:
- Документ.ЗамовленняПокупця
- Документ.ВидатковаНакладна
- Документ.ЗакриттяЗамовлень
</syntaxhighlight>

'''Патерн «доступний залишок»''' — з'єднання двох регістрів:
<syntaxhighlight lang="sql">
ВИБРАТИ
ЄСТЬNULL(Зал.Номенклатура, Рез.Номенклатура) ЯК Номенклатура,
ЄСТЬNULL(Зал.Склад, Рез.Склад) ЯК Склад,
ЄСТЬNULL(Зал.КількістьЗалишок, 0) ЯК ВСкладі,
ЄСТЬNULL(Рез.КількістьЗалишок, 0) ЯК ВРезерві,
ЄСТЬNULL(Зал.КількістьЗалишок, 0) - ЄСТЬNULL(Рез.КількістьЗалишок, 0) ЯК Доступно
З РегістрНакопичення.ТовариНаСкладах.Залишки(&Період, Склад = &Склад) ЯК Зал
ПОВНЕ З'ЄДНАННЯ РегістрНакопичення.ТовариВРезерві.Залишки(&Період, Склад = &Склад) ЯК Рез
ЗА Зал.Номенклатура = Рез.Номенклатура І Зал.Склад = Рез.Склад
</syntaxhighlight>

{{Note|Чому окремий регістр, а не ресурс «Резерв» у <code>ТовариНаСкладах</code>? Тому що резерв ведеться в розрізі '''Замовлення''', а залишок — у розрізі '''Партії'''. Додавання Замовлення як вимірювання до <code>ТовариНаСкладах</code> помножило б таблицю підсумків на кардинальність замовлень (сотні тисяч рядків на товар). Це ілюстрація контрольного питання №2 з Д.1.}}

==== Д.4.4. ГрошовіКоштиБезготівкові ====

<syntaxhighlight lang="yaml">
register:
name: ГрошовіКоштиБезготівкові
kind: Accumulation
accumulationKind: Balance
periodicity: WithinDay # достатньо дня: банківська виписка — денна
dimensions:
- { name: Організація, type: "Довідник.Організації", denyEmpty: true }
- { name: БанківськийРахунок, type: "Довідник.БанківськіРахунки", master: true, denyEmpty: true }
resources:
- { name: Сума, type: "Число(15,2)" }
- { name: СумаВал, type: "Число(15,2)" }
recorders: [Документ.ПлатіжнеДоручення, Документ.БанківськаВиписка, Документ.ПереміщенняКоштів]
</syntaxhighlight>

'''Проєктне рішення:''' Валюта — '''не''' вимірювання, тому що вона однозначно визначається банківським рахунком (функціональна залежність). Її додавання як вимірювання створило б надлишковість і ризик неузгоджених даних. Валюта отримується з'єднанням із довідником.

=== Д.5. Регістри накопичення, вид «Обороти» ===

==== Д.5.1. Продажі — з агрегатами ====

<syntaxhighlight lang="yaml">
register:
name: Продажі
kind: Accumulation
accumulationKind: Turnover # ← залишків не буває: «залишок продажів» безглуздий
periodicity: WithinSecond
turnoverTotalsPeriod: Month
aggregatesMode: Aggregates
partitioning: { mode: RangeByPeriod, step: month }
dimensions:
- { name: Номенклатура, type: "Довідник.Номенклатура", index: true }
- { name: Характеристика, type: "Довідник.ХарактеристикиНоменклатури", nullable: true }
- { name: Контрагент, type: "Довідник.Контрагенти", index: true }
- { name: Договір, type: "Довідник.ДоговориКонтрагентів" }
- { name: Менеджер, type: "Довідник.Користувачі", index: true }
- { name: Склад, type: "Довідник.Склади" }
resources:
- { name: Кількість, type: "Число(15,3)" }
- { name: Сума, type: "Число(15,2)" }
- { name: СумаБезПДВ, type: "Число(15,2)" }
- { name: Собівартість, type: "Число(15,2)" }
recorders: [Документ.ВидатковаНакладна, Документ.ПовернненняВідПокупця, Документ.ЗвітПроРоздрібніПродажі]

aggregates:
- name: ПродажіПоМісяцяхІТоварах
periodicity: Month
dimensions: [Номенклатура, Склад]
realtime: true
- name: ПродажіПоМенеджерах
periodicity: Day
dimensions: [Менеджер]
realtime: false # оновлюється регламентно
- name: ПродажіПоКонтрагентах
periodicity: Quarter
dimensions: [Контрагент, Договір]
realtime: false
</syntaxhighlight>

'''Проєктні рішення:'''
* <code>Turnover</code>, а не <code>Balance</code>: немає <code>ВидРуху</code>, немає таблиці залишків → удвічі менше підсумків і немає кумулятивних оновлень. Повернення відображається '''від'ємною''' сумою, а не «витратою».
* 6 вимірювань → таблиця підсумків надто широка для швидких звітів → компенсуємо агрегатами.

'''Ефект агрегатів:'''
{| class="wikitable"
! Звіт !! Без агрегатів (<code>rg_a_0031_tt</code>) !! З агрегатом !! Виграш
|-
| Продажі по товарах за рік || скан 8 млн рядків підсумків || <code>ag1</code>: 40 тис. рядків || ×200
|-
| Рейтинг менеджерів за квартал || скан 8 млн рядків || <code>ag2</code>: 1,8 тис. рядків || ×4000
|-
| Продажі по контрагенту за 3 роки || скан 8 млн рядків || <code>ag3</code>: 60 тис. рядків || ×130
|-
| Продажі по товару + контрагенту || '''агрегат не покриває''' → підсумки || — || —
|}

<syntaxhighlight lang="sql">
CREATE TABLE rg_a_0031_ag1 ( -- Місяць × (Номенклатура, Склад)
period timestamp(0) NOT NULL, d1_r uuid NOT NULL, d6_r uuid NOT NULL,
r1 numeric(20,3) NOT NULL, r2 numeric(20,2) NOT NULL,
r3 numeric(20,2) NOT NULL, r4 numeric(20,2) NOT NULL,
CONSTRAINT pk_rg_a_0031_ag1 PRIMARY KEY (period, d1_r, d6_r)
);
CREATE TABLE rg_a_0031_ag2 ( -- День × (Менеджер)
period timestamp(0) NOT NULL, d5_r uuid NOT NULL,
r1 numeric(20,3) NOT NULL, r2 numeric(20,2) NOT NULL,
r3 numeric(20,2) NOT NULL, r4 numeric(20,2) NOT NULL,
CONSTRAINT pk_rg_a_0031_ag2 PRIMARY KEY (period, d5_r)
);
</syntaxhighlight>

==== Д.5.2. ВитратиЗаСтаттями ====

<syntaxhighlight lang="yaml">
register:
name: ВитратиЗаСтаттями
kind: Accumulation
accumulationKind: Turnover
periodicity: WithinDay
turnoverTotalsPeriod: Month
dimensions:
- { name: Організація, type: "Довідник.Організації", denyEmpty: true }
- { name: Підрозділ, type: "Довідник.Підрозділи", index: true }
- { name: СтаттяВитрат, type: "Довідник.СтаттіВитрат", master: true, denyEmpty: true, index: true }
- { name: Проєкт, type: "Довідник.Проєкти", nullable: true }
resources:
- { name: Сума, type: "Число(15,2)" }
recorders: [Документ.АвансовийЗвіт, Документ.НадходженняПослуг, Документ.НарахуванняЗарплати, Документ.Амортизація]
</syntaxhighlight>

'''Приклад даних (<code>rg_a_0032_tt</code>, підсумки оборотів за місяць):'''
{| class="wikitable"
! period !! Підрозділ !! СтаттяВитрат !! Проєкт !! r1 (Сума)
|-
| 2026-07-01 || Відділ продажів || Оренда || ''(порожній)'' || 45 000.00
|-
| 2026-07-01 || Відділ продажів || ЗП і нарахування || ''(порожній)'' || 320 000.00
|-
| 2026-07-01 || Відділ продажів || Реклама || Запуск «Альфа» || 78 000.00
|-
| 2026-07-01 || ІТ-відділ || ЗП і нарахування || ''(порожній)'' || 410 000.00
|-
| 2026-07-01 || ІТ-відділ || Ліцензії ПЗ || ''(порожній)'' || 62 000.00
|}

=== Д.6. Регістри бухгалтерії ===

==== Д.6.1. Госпрозрахунковий — з кореспонденцією ====

Декларація — розділ 6.7, схема — 8.6, ER — 9.3. Тут — приклад проводок.

'''Господарська операція:''' реалізація товару на 12 000 грн (у т.ч. ПДВ 2 000), собівартість 7 000 грн.

'''Проводки (<code>rg_b_0020</code>, реєстратор = ВидатковаНакладна №12):'''
{| class="wikitable"
! line !! acc_dt !! ed_dt1 !! ed_dt2 !! acc_kt !! ed_kt1 !! ed_kt2 !! r1 (Сума) !! r2_dt !! r2_kt
|-
| 1 || 361 ''Розрах. з покупцями'' || ТОВ «Бета» || Договір №5 || 702 ''Дохід від реалізації'' || Кава Lavazza || ''—'' || 12 000.00 || || 30.000
|-
| 2 || 702 ''Дохід від реалізації'' || Кава Lavazza || ''—'' || 641 ''Розрах. за податками'' || ПДВ || ''—'' || 2 000.00 || ||
|-
| 3 || 902 ''Собівартість реалізації'' || Кава Lavazza || ''—'' || 281 ''Товари на складі'' || Кава Lavazza || Центральний || 7 000.00 || 30.000 || 30.000
|}

'''Контроль:''' Σ(Сума) по Дт = Σ(Сума) по Кт у межах реєстратора → 12 000 + 2 000 + 7 000 = 21 000 з обох боків. ✔

'''Підсумки, рівень 0 (<code>rg_b_0020_tb0</code>), на 5999-11-01:'''
{| class="wikitable"
! acc_r !! d1_r (Організація) !! r1 (Сума ±) !! Інтерпретація
|-
| 281 || ТОВ «Альфа» || +28 000.00 || дебетовий залишок (товари є)
|-
| 361 || ТОВ «Альфа» || +12 000.00 || дебетовий (дебіторка)
|-
| 641 || ТОВ «Альфа» || −2 000.00 || кредитовий (винні бюджету)
|-
| 702 || ТОВ «Альфа» || −10 000.00 || кредитовий (дохід)
|-
| 902 || ТОВ «Альфа» || +7 000.00 || дебетовий (собівартість)
|}

'''Підсумки, рівень 2 (<code>rg_b_0020_tb2</code>) — для рахунку 281 (2 субконто: Номенклатура, Склад):'''
{| class="wikitable"
! acc_r !! ed1_r (Номенклатура) !! ed2_r (Склад) !! r1 (Сума) !! r2 (Кількість)
|-
| 281 || Кава Lavazza || Центральний || 17 500.00 || 50.000
|-
| 281 || Кава Lavazza || Роздрібний || 7 000.00 || 20.000
|-
| 281 || Чай Ahmad || Центральний || 12 000.00 || 200.000
|}
Згортка <code>tb2</code> → <code>tb0</code>: 17 500 + 7 000 + 12 000 = '''36 500'''… ''(різниця з таблицею вище — інші операції; у тесті ФТ-Т-08 перевіряється точна рівність)''.

'''Запит (ОСВ по рахунку):'''
<syntaxhighlight lang="sql">
ВИБРАТИ
Дані.Субконто1 ЯК Номенклатура, Дані.Субконто2 ЯК Склад,
Дані.СумаПочатковийЗалишокДт, Дані.КількістьПочатковийЗалишокДт,
Дані.СумаОборотДт, Дані.СумаОборотКт,
Дані.СумаКінцевийЗалишокДт, Дані.КількістьКінцевийЗалишокДт
З РегістрБухгалтерії.Госпрозрахунковий.ЗалишкиІОбороти(
&Початок, &Кінець, Місяць,
Рахунок = &Рахунок281,
, Організація = &Організація,
,
) ЯК Дані
</syntaxhighlight>

==== Д.6.2. ПодатковийОблік — без кореспонденції ====

'''Задача:''' податковий облік із розділенням на постійні/тимчасові різниці, де подвійний запис не потрібен (кожен факт реєструється окремо по Дт або по Кт).

<syntaxhighlight lang="yaml">
register:
name: ПодатковийОблік
kind: Accounting
chartOfAccounts: ПланРахунків.Податковий
correspondence: false # ← уніграфічний облік
periodicity: WithinSecond
dimensions:
- { name: Організація, type: "Довідник.Організації", balance: true, denyEmpty: true }
- { name: ВидРізниці, type: "Перерахування.ВидиРізниць", balance: true } # БУ|ПУ|ПР|ТР
resources:
- { name: Сума, type: "Число(15,2)", balance: true }
attributes:
- { name: Зміст, type: "Рядок(255)" }
recorders: [Документ.БухгалтерськаОперація, Документ.ВидатковаНакладна, Документ.НадходженняПослуг]
</syntaxhighlight>

'''Проводки (<code>rg_b_0021</code>):'''
{| class="wikitable"
! line !! acc_mvt !! acc_r !! ed1 (Номенкл.) !! d1 (Організація) !! d2 (ВидРізниці) !! r1 (Сума)
|-
| 1 || 0 ''Дебет'' || 902.НУ || Кава Lavazza || ТОВ «Альфа» || ПУ ''податковий'' || 7 000.00
|-
| 2 || 1 ''Кредит'' || 281.НУ || Кава Lavazza || ТОВ «Альфа» || ПУ || 7 000.00
|-
| 3 || 0 ''Дебет'' || 902.НУ || Кава Lavazza || ТОВ «Альфа» || ПР ''постійна різниця'' || 350.00
|-
| 4 || 1 ''Кредит'' || 281.НУ || Кава Lavazza || ТОВ «Альфа» || ПР || 350.00
|}

'''Відмінності від Д.6.1:'''
{| class="wikitable"
! !! З кореспонденцією !! Без кореспонденції
|-
| Один факт = || 1 запис (Дт+Кт) || 2 записи (окремо Дт, окремо Кт)
|-
| Поля рахунків || <code>acc_dt_r</code>, <code>acc_kt_r</code> || <code>acc_r</code> + <code>acc_mvt</code>
|-
| Субконто || 2 набори (Дт, Кт) || 1 набір
|-
| Кількість записів || N || 2N
|-
| Таблиця <code>_tc</code> (кореспонденції) || Є || '''Немає''' — «шахова відомість» неможлива
|-
| Контроль Дт=Кт || У межах реєстратора || Опційно (може бути незбалансовано за задумом)
|-
| Коли обирати || Класичний облік, потрібен аналіз кореспонденцій || Облік без потреби в кореспонденціях, забалансовий, статистичний
|}

==== Д.6.3. Бюджетування ====

<syntaxhighlight lang="yaml">
register:
name: Бюджетування
kind: Accounting
chartOfAccounts: ПланРахунків.Бюджетування
correspondence: true
periodicity: WithinMonth # бюджет — помісячний, до секунди не потрібно
dimensions:
- { name: Сценарій, type: "Довідник.СценаріїБюджетування", balance: true, denyEmpty: true }
- { name: ЦФВ, type: "Довідник.ЦентриФінансовоїВідповідальності", balance: true }
- { name: Проєкт, type: "Довідник.Проєкти", balance: true, nullable: true }
resources:
- { name: Сума, type: "Число(15,2)", balance: true }
recorders: [Документ.БюджетнаОперація, Документ.ВведенняБюджету]
</syntaxhighlight>

'''Проєктне рішення:''' <code>Сценарій</code> — вимірювання, а не окремий регістр на кожен сценарій (План/Факт/Прогноз). Це дозволяє план-фактний аналіз одним запитом. Усі три вимірювання '''балансові''' — бюджетна проводка не змінює сценарій/ЦФВ між дебетом і кредитом.

=== Д.7. Регістри розрахунку ===

==== Д.7.1. ОсновніНарахування — період дії + витіснення ====

'''План видів розрахунку <code>ОсновніНарахування</code>:'''
{| class="wikitable"
! Вид розрахунку !! Період дії !! Витісняючі !! Базові !! Залежність від бази
|-
| Оклад || Так || Відпустка, Лікарняний || — || Не залежить
|-
| Відпустка || Так || Лікарняний || Оклад, Премія || За періодом дії
|-
| Лікарняний || Так || — || Оклад || За періодом дії
|-
| Премія || Ні || — || Оклад || За періодом реєстрації
|}

Декларація регістру — розділ 6.7.

'''Записи (<code>rg_c_0040</code>), період реєстрації = липень 2026:'''
{| class="wikitable"
! line !! calc_type !! period !! act_begin !! act_end !! base_begin !! base_end !! d1 (Співробітник) !! r1 (Результат)
|-
| 1 || Оклад || 2026-07-01 || 2026-07-01 || 2026-07-31 || || || Іваненко || 18 000.00
|-
| 2 || Відпустка || 2026-07-01 || 2026-07-10 || 2026-07-17 || 2026-01-01 || 2026-06-30 || Іваненко || 6 420.00
|-
| 3 || Лікарняний || 2026-07-01 || 2026-07-14 || 2026-07-22 || 2026-01-01 || 2026-06-30 || Іваненко || 5 180.00
|-
| 4 || Оклад || 2026-07-01 || 2026-07-01 || 2026-07-31 || || || Петренко || 22 000.00
|}

'''Фактичні періоди дії (<code>rg_c_0040_ap</code>) — результат витіснення:'''
{| class="wikitable"
! rec/line !! interval_no !! calc_type !! d1 !! fact_begin !! fact_end !! Коментар
|-
| n1 / 1 || 0 || Оклад || Іваненко || 2026-07-01 || 2026-07-09 || до відпустки
|-
| n1 / 1 || 1 || Оклад || Іваненко || 2026-07-23 || 2026-07-31 || після лікарняного
|-
| n1 / 2 || 0 || Відпустка || Іваненко || 2026-07-10 || 2026-07-13 || витіснена лікарняним з 14-го
|-
| n1 / 3 || 0 || Лікарняний || Іваненко || 2026-07-14 || 2026-07-22 || не витісняється нічим
|-
| n1 / 4 || 0 || Оклад || Петренко || 2026-07-01 || 2026-07-31 || витіснення відсутнє
|}

'''Один запис «Оклад» Іваненка → два інтервали''' — ілюстрація зв'язку 1:N у розділі 9.4.

'''Запит (дані графіка для розрахунку окладу):'''
<syntaxhighlight lang="sql">
ВИБРАТИ
Дані.Співробітник, Дані.НомерРядка,
Дані.ЗначенняФактичногоПеріодуДії ЯК ВідпрацьованоДнів,
Дані.ЗначенняПеріодуДії ЯК НормаДнів
З РегістрРозрахунку.ОсновніНарахування.ДаніГрафіка(
ВидРозрахунку = ЗНАЧЕННЯ(ПланВидівРозрахунку.ОсновніНарахування.Оклад)
І Реєстратор = &Реєстратор
) ЯК Дані
</syntaxhighlight>
'''Результат:''' Іваненко — <code>ВідпрацьованоДнів = 13</code> (робочі дні у 01–09 та 23–31), <code>НормаДнів = 23</code> → Оклад = 18 000 × 13 / 23 = '''10 173,91'''.

'''Запит (база для відпустки):'''
<syntaxhighlight lang="sql">
ВИБРАТИ База.Співробітник, База.НомерРядка, База.РезультатБаза ЯК Заробіток
З РегістрРозрахунку.ОсновніНарахування.БазаРозрахунку(
, /* вимірювання бази */
, /* вимірювання основного регістру */
Співробітник, /* розрізи */
ВидРозрахунку = ЗНАЧЕННЯ(ПланВидівРозрахунку.ОсновніНарахування.Відпустка)
) ЯК База
</syntaxhighlight>

==== Д.7.2. Утримання — без періоду дії, база за періодом реєстрації ====

'''План видів розрахунку <code>Утримання</code>:'''
{| class="wikitable"
! Вид розрахунку !! Період дії !! Базові види розрахунку !! Залежність
|-
| ПДФО || Ні || ''(усі з ПВР ОсновніНарахування)'' || За періодом реєстрації
|-
| Військовий збір || Ні || ''(усі з ПВР ОсновніНарахування)'' || За періодом реєстрації
|-
| Аліменти || Ні || Оклад, Премія, Відпустка || За періодом реєстрації
|-
| Профспілковий внесок || Ні || Оклад || За періодом реєстрації
|}

<syntaxhighlight lang="yaml">
register:
name: Утримання
kind: Calculation
calculationTypesPlan: ПланВидівРозрахунку.Утримання
periodicity: Month
actionPeriod: false # ← утримання не має періоду дії
basePeriod: ByRegistrationPeriod # ← база береться за періодом реєстрації
# schedule: не задається — графік не потрібен
dimensions:
- { name: Співробітник, type: "Довідник.Співробітники", baseDimension: true, master: true, denyEmpty: true }
- { name: Підрозділ, type: "Довідник.Підрозділи" }
resources:
- { name: Результат, type: "Число(15,2)" }
- { name: БазаОподаткування, type: "Число(15,2)" }
recalculations:
- name: ПерерахунокУтримань
dimensions:
- { name: Співробітник, registerDimension: Співробітник }
recorders: [Документ.НарахуванняЗарплати]
</syntaxhighlight>

'''Фізична схема (спрощена — немає полів періоду дії):'''
<syntaxhighlight lang="sql">
CREATE TABLE rg_c_0041 (
rec_t smallint NOT NULL,
rec_r uuid NOT NULL,
line_no int NOT NULL,
period timestamp(0) NOT NULL, -- період реєстрації
active boolean NOT NULL DEFAULT true,
reversal boolean NOT NULL DEFAULT false,
calc_type_r uuid NOT NULL,
base_begin timestamp(0) NOT NULL, -- ← є, бо basePeriod ≠ None
base_end timestamp(0) NOT NULL,
-- act_begin / act_end ВІДСУТНІ (actionPeriod: false)
d1_r uuid NOT NULL,
d2_r uuid NOT NULL,
r1 numeric(15,2) NOT NULL DEFAULT 0,
r2 numeric(15,2) NOT NULL DEFAULT 0,
CONSTRAINT pk_rg_c_0041 PRIMARY KEY (rec_t, rec_r, line_no)
);
-- Таблиця rg_c_0041_ap НЕ створюється (немає періоду дії → немає витіснення)
CREATE TABLE rg_c_0041_rc1 ( -- ПерерахунокУтримань
rec_t smallint NOT NULL, rec_r uuid NOT NULL,
calc_type_r uuid NOT NULL, d1_r uuid NOT NULL,
src_rec_t smallint NOT NULL, src_rec_r uuid NOT NULL,
created_at timestamp(0) NOT NULL DEFAULT now(),
CONSTRAINT pk_rg_c_0041_rc1 PRIMARY KEY (rec_t, rec_r, calc_type_r, d1_r)
);
</syntaxhighlight>

{{Note|'''Міжпланова база.''' Базові види розрахунку для ПВР <code>Утримання</code> належать до ''іншого'' ПВР — <code>ОсновніНарахування</code>. Це означає, що віртуальна таблиця <code>БазаРозрахунку</code> регістру <code>Утримання</code> має читати записи регістру <code>ОсновніНарахування</code>. '''Вимога ФТ-25 має бути розширена:''' метамодель повинна дозволяти вказати ''регістр-джерело бази''. Це '''відкрите питання В9''' (див. оновлений Додаток Г) — у 1С механізм працює через відповідність ПВР, а не регістрів, що обмежує сценарії. Пропозиція: додати до <code>md_register</code> поле <code>base_register_id</code>.}}

'''Приклад даних:'''
{| class="wikitable"
! line !! calc_type !! period !! base_begin !! base_end !! Співробітник !! r2 (База) !! r1 (Результат)
|-
| 1 || ПДФО || 2026-07-01 || 2026-07-01 || 2026-07-31 || Іваненко || 21 773.91 || 3 919.30
|-
| 2 || Військовий збір || 2026-07-01 || 2026-07-01 || 2026-07-31 || Іваненко || 21 773.91 || 326.61
|-
| 3 || Аліменти || 2026-07-01 || 2026-07-01 || 2026-07-31 || Іваненко || 17 528.00 || 4 382.00
|}

=== Д.8. Наскрізний приклад: проведення видаткової накладної ===

'''Документ:''' Видаткова накладна №12 від 05.07.2026, ТОВ «Бета», 30 кг кави за 400 грн (12 000 грн з ПДВ), собівартість 7 000 грн.

<graphviz>
digraph Posting {
rankdir=LR; bgcolor="transparent";
node [shape=box, style="rounded,filled", fontname="Helvetica", fontsize=9];

D [label="Документ\nВидаткова накладна №12\n05.07.2026", fillcolor="#fff8e1", shape=note];

R1 [label="РН ТовариНаСкладах\n(Залишки)\nВитрата: 30 кг / 7 000 грн", fillcolor="#fff3e0"];
R2 [label="РН Взаєморозрахунки\n(Залишки)\nПрихід: 12 000 грн", fillcolor="#fff3e0"];
R3 [label="РН Продажі\n(Обороти)\n30 кг / 12 000 / 10 000 / 7 000", fillcolor="#fff3e0"];
R4 [label="РН ТовариВРезерві\n(Залишки)\nВитрата: 30 кг", fillcolor="#fff3e0"];
R5 [label="РБ Госпрозрахунковий\n3 проводки на 21 000", fillcolor="#fce4ec"];

T1 [label="rg_a_0012_tb\nMAXPERIOD: 80 → 50 кг", fillcolor="#ffe0b2", shape=cylinder];
T2 [label="rg_a_0013_tb\nMAXPERIOD: 0 → +12 000", fillcolor="#ffe0b2", shape=cylinder];
T3 [label="rg_a_0031_tt\n2026-07: +30 / +12 000", fillcolor="#ffe0b2", shape=cylinder];
T5 [label="rg_b_0020_tb0/tb2/tt0/tc", fillcolor="#f8bbd0", shape=cylinder];

D -> R1; D -> R2; D -> R3; D -> R4; D -> R5;
R1 -> T1; R2 -> T2; R3 -> T3; R5 -> T5;

label="ОДНА транзакція БД: усі 5 регістрів + підсумки + прапорець Проведений";
labelloc=b; fontname="Helvetica"; fontsize=10;
}
</graphviz>

<syntaxhighlight lang="csharp">
protected override void OnPosting(PostingContext ctx)
{
// --- 0. Блокування перед контролем залишків ---
var dl = new DataLock();
var li = dl.Add("РегістрНакопичення.ТовариНаСкладах.Залишки");
li.Mode = DataLockMode.Exclusive;
li.DataSource = this.Товари.Unload(new[] { "Номенклатура", "Характеристика" });
li.UseFromDataSource("Номенклатура", "Номенклатура");
li.UseFromDataSource("Характеристика", "Характеристика");
li.SetValue("Склад", this.Склад);
dl.Lock();

// --- 1. РН ТовариНаСкладах: списання ---
var rsGoods = Movements["ТовариНаСкладах"]; rsGoods.Write = true; rsGoods.Clear();
foreach (var row in this.Товари) {
var m = rsGoods.Add();
m.Період = this.Дата;
m.MovementType = AccumulationMovementType.Expense;
m.Номенклатура = row.Номенклатура; m.Характеристика = row.Характеристика;
m.Склад = this.Склад; m.Партія = row.Партія;
m.Кількість = row.Кількість; m.Сума = row.Собівартість;
}

// --- 2. РН Взаєморозрахунки: дебіторка зростає ---
var rsAR = Movements["ВзаєморозрахункиЗКонтрагентами"]; rsAR.Write = true; rsAR.Clear();
var ar = rsAR.Add();
ar.Період = this.Дата;
ar.MovementType = AccumulationMovementType.Receipt; // Прихід = борг зростає
ar.Організація = this.Організація; ar.Контрагент = this.Контрагент;
ar.Договір = this.Договір; ar.Замовлення = this.ЗамовленняПокупця;
ar.Сума = this.СумаДокумента; ar.СумаВал = this.СумаДокументаВал;

// --- 3. РН Продажі: оборот (без ВидРуху!) ---
var rsSales = Movements["Продажі"]; rsSales.Write = true; rsSales.Clear();
foreach (var row in this.Товари) {
var s = rsSales.Add();
s.Період = this.Дата;
s.Номенклатура = row.Номенклатура; s.Контрагент = this.Контрагент;
s.Договір = this.Договір; s.Менеджер = this.Менеджер;
s.Склад = this.Склад;
s.Кількість = row.Кількість; s.Сума = row.Сума;
s.СумаБезПДВ = row.СумаБезПДВ; s.Собівартість = row.Собівартість;
}

// --- 4. РН ТовариВРезерві: зняття резерву ---
if (!this.ЗамовленняПокупця.IsEmpty()) { /* ... Витрата ... */ }

// --- 5. РБ Госпрозрахунковий: проводки ---
var rsAcc = Movements["Госпрозрахунковий"]; rsAcc.Write = true; rsAcc.Clear();
foreach (var row in this.Товари) {
var e1 = rsAcc.AddAccountingEntry(); // Дт 361 / Кт 702
e1.Період = this.Дата;
e1.РахунокДт = Accounts["361"]; e1.РахунокКт = Accounts["702"];
e1.SubcontoDt[ВидиСубконто.Контрагенти] = this.Контрагент;
e1.SubcontoDt[ВидиСубконто.Договори] = this.Договір;
e1.SubcontoKt[ВидиСубконто.Номенклатура] = row.Номенклатура;
e1.Організація = this.Організація;
e1.Сума = row.Сума; e1.КількістьКт = row.Кількість;

var e2 = rsAcc.AddAccountingEntry(); // Дт 702 / Кт 641
/* ... ПДВ ... */

var e3 = rsAcc.AddAccountingEntry(); // Дт 902 / Кт 281
/* ... собівартість ... */
}

rsGoods.WriteNow(); // примусовий запис до контролю
ControlNegativeBalances(ctx); // прикладна перевірка
}
</syntaxhighlight>

'''Що відбувається у БД (одна транзакція):'''
{| class="wikitable"
! Крок !! Таблиця !! Операція !! Рядків
|-
| 1 || <code>doc_0003</code> || UPDATE posted = true || 1
|-
| 2 || <code>rg_a_0012</code> (ТовариНаСкладах) || DELETE + INSERT || 1
|-
| 3 || <code>rg_a_0012_tb</code> || MERGE (MAXPERIOD + періоди > 07.2026) || 2
|-
| 4 || <code>rg_a_0013</code> (Взаєморозрахунки) || DELETE + INSERT || 1
|-
| 5 || <code>rg_a_0013_tb</code> || MERGE || 2
|-
| 6 || <code>rg_a_0031</code> (Продажі) || DELETE + INSERT || 1
|-
| 7 || <code>rg_a_0031_tt</code> || MERGE (тільки період 2026-07) || 1
|-
| 8 || <code>rg_a_0031_ag1</code> || MERGE (realtime-агрегат) || 1
|-
| 9 || <code>rg_a_0014</code> (Резерв) || DELETE + INSERT || 1
|-
| 10 || <code>rg_b_0020</code> (проводки) || DELETE + INSERT || 3
|-
| 11 || <code>rg_b_0020_tb0</code> || MERGE || 10
|-
| 12 || <code>rg_b_0020_tb1/tb2</code> || MERGE || 8
|-
| 13 || <code>rg_b_0020_tt0..tt2</code> || MERGE || 12
|-
| 14 || <code>rg_b_0020_tc</code> || MERGE || 3
|-
| colspan="3" | '''Разом''' || '''≈ 47 рядків, 1 COMMIT'''
|}

{{Note|'''Спостереження для НФВ-04.''' Один рядок товару в накладній породжує ~47 модифікацій рядків у 14 таблицях. Для накладної зі 100 рядків це ~2 000–4 000 модифікацій. Саме тут — основне навантаження проведення, і саме тому РБ (кроки 10–14) дає ~70 % вартості транзакції. Це аргумент на користь MVP без РБ (розділ 14) і предмет вимірювання в НТ-03.}}

=== Д.9. Наскрізний приклад: розрахунок зарплати ===

<pre>
КРОК 1. Документ «Нарахування зарплати» за липень 2026, Іваненко.
Записуємо рухи в РР ОсновніНарахування (Результат = 0).

КРОК 2. Платформа автоматично будує фактичні періоди дії (rg_c_0040_ap):
Оклад → [01.07–09.07], [23.07–31.07]
Відпустка → [10.07–13.07]
Лікарняний → [14.07–22.07]

КРОК 3. Розрахунок «первинних» видів (без бази) — Оклад.
Запит до ДаніГрафіка:
НормаДнів = 23 (робочих днів у липні за П'ятиденкою)
ВідпрацьованоДнів = 13 (робочі дні у фактичних періодах дії)
Результат = 18 000 × 13 / 23 = 10 173,91
→ UPDATE rg_c_0040 SET r1 = 10173.91, r2 = 13, r3 = 23 WHERE line_no = 1

КРОК 4. Розрахунок видів із базою — Відпустка, Лікарняний.
Запит до БазаРозрахунку (базовий період 01.01–30.06, база = Оклад+Премія):
Заробіток за 6 міс. = 115 560,00
Календарних днів = 181
Середньоденний = 638,45
Відпустка: 638,45 × 4 дні (10–13.07) = 2 553,80
Лікарняний: 638,45 × 9 днів × 100 % = 5 746,05
→ UPDATE rg_c_0040 SET r1 = ... WHERE line_no IN (2, 3)

КРОК 5. Записуємо рухи в РР Утримання (базовий період = період реєстрації, липень).
База ПДФО = 10 173,91 + 2 553,80 + 5 746,05 = 18 473,76
ПДФО = 18 473,76 × 18 % = 3 325,28
ВЗ = 18 473,76 × 1,5 % = 277,11

КРОК 6. Проведення документа → рухи в:
РН ВитратиЗаСтаттями (Обороти): Стаття «ЗП і нарахування» = 18 473,76
РБ Госпрозрахунковий: Дт 92 / Кт 661 = 18 473,76
Дт 661 / Кт 641.ПДФО = 3 325,28
Дт 661 / Кт 642.ВЗ = 277,11

КРОК 7. Через тиждень бухгалтер змінює Оклад Іваненка за червень (заднім числом).
→ Платформа реєструє в rg_c_0040_rc1 (ПерерахунокЗаБазою):
(Реєстратор = НарахуванняЗП липня, ВидРозрахунку = Відпустка, Співробітник = Іваненко)
(Реєстратор = НарахуванняЗП липня, ВидРозрахунку = Лікарняний, Співробітник = Іваненко)
→ Звіт «Документи до перерахунку» показує липневий документ.
→ Бухгалтер перепроводить → база перераховується → записи перерахунку очищаються.
</pre>

=== Д.10. Антипатерни проєктування регістрів ===

{| class="wikitable"
! ID !! Антипатерн !! Чому погано !! Як правильно
|-
| '''А-1''' || Дата як '''вимірювання''' у РН (замість стандартного <code>Період</code>) || Таблиця підсумків множиться на кількість дат і зростає нескінченно; віртуальні таблиці <code>Залишки</code>/<code>Обороти</code> ігнорують це вимірювання і дають безглузді результати || Використовувати стандартний реквізит <code>Період</code>. Виняток — календарі (Д.3.4), де це РВ, а не РН
|-
| '''А-2''' || РН «Залишки» там, де потрібна лише історія значення || Надлишкові таблиці підсумків, кумулятивні оновлення, вид руху без сенсу || РВ періодичний
|-
| '''А-3''' || РН «Залишки» там, де залишок безглуздий (Продажі, Витрати) || Удвічі більший обсяг підсумків, кумулятивні MERGE на всі майбутні періоди || РН «Обороти» + агрегати (Д.5.1)
|-
| '''А-4''' || Реквізит документа продубльовано у вимірювання «щоб фільтрувати у звіті» || Кардинальність підсумків × N; типовий випадок — Менеджер/Валюта/Коментар || Реквізит регістру + з'єднання з документом у звіті; або окремий регістр «Обороти»
|-
| '''А-5''' || > 8 вимірювань в одному РН || Таблиця підсумків стає '''більшою''' за таблицю рухів; проведення сповільнюється в рази || Розділити на регістри за призначенням; частину аналітики — в «Обороти» з агрегатами
|-
| '''А-6''' || Незалежний РВ «у межах секунди» як журнал подій || Два записи в ту саму секунду → другий '''мовчки замістить''' перший; втрата даних || Підпорядкований РВ (реєстратор у ключі) або додати вимірювання-дискримінатор
|-
| '''А-7''' || Ресурс типу <code>Рядок</code>/<code>Посилання</code> у РН || Підсумовування неможливе; підсумки не побудуються || Реквізит (не агрегується) або вимірювання (якщо це розріз)
|-
| '''А-8''' || Прямий <code>UPDATE</code> таблиці підсумків із прикладного коду || Розсинхронізація підсумків і рухів; діагностика — тижні || Тільки через набори записів. Заборона на рівні прав БД (розділ 12.2)
|-
| '''А-9''' || Один «універсальний» регістр із вимірюванням <code>ВидОбліку</code> (БУ/ПУ/УО) замість трьох || Втричі більша таблиця; конкуренція за блокування між незалежними обліками; неможливо окремо перерахувати підсумки || Окремі регістри. Виняток — РБ <code>ПодатковийОблік</code> (Д.6.2), де ВидРізниці — це справді розріз одного обліку
|-
| '''А-10''' || Функціонально залежне поле як вимірювання (Валюта при БанківськомуРахунку) || Надлишковість; ризик неузгоджених даних; зайвий розмір ключа підсумків || З'єднання з довідником у запиті (Д.4.4)
|-
| '''А-11''' || РБ там, де достатньо РН || Замість 1 таблиці — 10; ~70 % вартості проведення (Д.8); складність субконто без потреби || РН. РБ — лише коли потрібні план рахунків, подвійний запис і кореспонденції
|-
| '''А-12''' || Вимірювання з <code>nullable</code> без потреби || Порожнє посилання — окреме значення ключа; підсумки «розмазуються» на два рядки замість одного || <code>denyEmpty: true</code> скрізь, де порожнє значення не має сенсу
|-
| '''А-13''' || Контроль залишків '''до''' запису рухів || Класична гонитва: два сеанси проходять контроль і обидва списують у мінус || Спершу <code>DataLock</code> → <code>WriteNow()</code> → потім контроль (Д.8, ФТ-Т-12)
|-
| '''А-14''' || <code>periodicity: WithinSecond</code> «про всяк випадок» скрізь || Для РВ — неможливість замістити запис за день; для РН — марна точність, більші індекси || Обирати мінімально достатню: день для цін/курсів/виписок, секунда — для складських рухів
|}

=== Д.11. Чек-лист рев'ю нового регістру ===

<pre>
□ Тип регістру обґрунтований за деревом Д.1
□ Кожне вимірювання використовується у фільтрі АБО групуванні звітів
□ Кожен ресурс має сенс при підсумовуванні
□ Немає полів з антипатернів А-1, А-4, А-7, А-10, А-12
□ Оцінка кардинальності підсумків ≤ 10^8 (калькулятор конструктора, ФТ-К-03)
□ Для вимірювань, де порожнє значення безглузде, стоїть denyEmpty
□ Ведучі (master) вимірювання визначені — інакше «висячі» записи при видаленні об'єктів
□ Склад реєстраторів повний; зайвих типів документів немає
□ Угода про знак / вид руху зафіксована в методологічній документації
□ Періодичність мінімально достатня (А-14)
□ Для РН «Обороти» з >4 вимірюваннями визначено ≥1 агрегат
□ Для РБ: балансові/небалансові вимірювання та ресурси розставлені свідомо
□ Для РР: витісняючі та базові види розрахунку в ПВР заповнені; перерахунки визначені
□ Партиціонування ввімкнене, якщо очікується >100 млн записів
□ Написано тест на проведення + скасування + перерахунок підсумків
</pre>

----
''Кінець документа. Версія 1.1. Підлягає узгодженню з архітектором платформи K2 ERP до затвердження.''

Регістри в K2 ERP

2026-07-17T18:31:01Z

R: Створена сторінка: {{DISPLAYTITLE:ТЗ. Підсистема регістрів K2 ERP}} __TOC__ = 1. Паспорт документа = {| class="wikitable" ! Атрибут !! Значення |- | Назва || Технічне завдання на розробку підсистеми «Регістри» платформи K2 ERP |- | Шифр || K2-ERP-TZ-REG-001 |- | Версія || 1.0 (чернетка на узгодження) |- | Статус || На роз...

Приклади технічного завдання K2 ERP

2026-07-17T17:53:41Z

Виробництво

[[Технічне завдання на облік виробництва в K2 ERP]]

== Аграрний сектор ==
[[Технічне завдання: Облік виробництва аграрної компанії]]

== Ресторан ==
[[Технічне завдання на облік в ресторані]]<br>[[Інтерфейс створення технологічних карт]]

== Зарплата ==
[[Технічне завдання: Облік зарплати]]

== Бухгалтерський та податковий облік ==

=== Зарплата ===
[[Технічне завдання: Облік основних засобів]]

=== Проводки ===
[[Технічне завдання: Бухгалтерські проводки основних операцій]]

== Маркетинг ==
[[Технічне завдання: Афіліантська система]]

== Інструментарій ==
[[Технічне завдання: Редактор ER-моделей K2 ERP]]<br>[[Технічне завдання: Редактор BP-моделей K2 ERP]]

== Подача звітност в ДПС та інші державні органи України ==
[[Технічне завдання: Передача звітності з K2 ERP до Електронного кабінету ДПС]]<br>[[Технічне завдання: передача документів для звітності в податкову через Вчасно для Python]]<br>[[Технічне завдання: передача документів для звітності в податкову через Приват24 для Python]]<br>[[Технічне завдання: передача документів для звітності в податкову через Медок для Python]]<br>[[Технічне завдання: передача документів для звітності в податкову через Птах для Python]]<br>[[Технічне завдання: передача документів для звітності в податкову через Edin для Python]]

[[Приклад подачі звітів ФОП на єдиному податку]]

[[Декларація ФОП]]

[[Звітність компанії на загальній системі оподаткування]]

[[Звітність компанії на особливому режимі Дія-Сіті]]

== Приклади ==
[[Приклад розрахунку зарплати]]

[[Приклад розрахунки податків на загальній системі оподаткування]]

[[Приклад розрахунків подаків компанії на особливому режимі Дія-Сіті]]

[[Приклад розрахунку основних засобів за кілька місяців]]

[[Приклад роботи торгової організації з обліком генераторів у K2 ERP]]

== Обмін з банками ==
[[Технічне завдання: отримання банківських виписок з Приват24 для Python]]

[[Документація та формати банківських виписок різних банків України]]

[[Технічне завдання: Гнучкий модуль імпорту банківських виписок у K2 ERP]]

== Контроль сроків та звітність ==
[[Технічне завдання: контроль сроків подачі звітності підприємствами в Україні]]<br>[[Технічне завдання: види податкових систем та звіти, що подаються]]

== РРО та ПРРО ==
[[Технічне завдання: інтеграція Вчасно каса для Python]]<br>[[Технічне завдання: інтеграція ПРРО Checkbox для Python]]<br>[[Інтеграція РРО в Python]]<br>[[Інтеграція РРО в Python через загальну бібліотеку для різних РРО]]<br>

== Інтеграції в K2 ERP ==
[[Інтеграція з Мурашина логістика в Python]]<br>[[Інтеграція з Новою поштою в Python]]<br>[[Інтеграція з Укрпоштою в Python]]<br>

== Електронний підпис ==
[[Накладення електронного підпису за допомогою Дія в Python]]<br>[[Накладення електронного підпису за допомогою електронного підпису Приват24]]<br>[[Уніфіковане накладання електронного підпису різних сервісних центрів України]]

== Інтеграція з інтернет-магазинами та маркетплейсами ==
[[Інтеграція з Horoshop]]<br>[[Інтеграція з Prom, Rozetka, Hotline]]

== CRM ==
[[Життєвий цикл ліда]]

== Собівартість ==
[[Розрахунок собівартості]]

== Система онлайн-навчання ==
[[Система онлайн-навчання]]

== Документообіг ==
[[Технічне завдання на документообіг]]

[[Технічне завдання VDoc K2 ERP]]

== Комунікації ==
[[Технічне завдання на створення чату в K2 ERP]]

== Технологічна платформа ==
[[Регістри в K2 ERP]]

Налаштування організації (приклад)

2026-07-14T13:07:36Z

[[Файл:Obl pol1.png|центр|міні|600x600пкс]]
[[Файл:Obl pol3.png|центр|міні|600x600пкс]]
[[Файл:Obl pol2.png|центр|міні|600x600пкс]]
[[Файл:Obl pol5.png|центр|міні|600x600пкс]]
[[Файл:Obl pol7.png|центр|міні|600x600пкс]]

'''Налаштування організації для бухгалтерського та податкового обліку''' — це формалізація [[Облікова політика|облікової політики]] підприємства у параметрах [[ERP-система|ERP-системи]]. Нижче наведено перелік реквізитів, політик та параметрів, які необхідно визначити для коректної роботи регламентованого обліку.

__TOC__

== Реквізити та статус організації ==

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

* '''Найменування''' — повне та скорочене
* '''Код''' — ЄДРПОУ (для юросіб) або ІПН / РНОКПП (для ФОП)
* '''Організаційно-правова форма'''
* '''Адреси''' — юридична та фактична, контактні дані
* '''Реєстраційні дані''' в органах ДПС, орган ДПС за місцем обліку
* '''Банківські рахунки''' у форматі IBAN, обслуговуючі банки
* '''Відповідальні особи''' — керівник, головний бухгалтер, касир (підставляються у первинні документи та звітність)
* '''Відокремлені підрозділи''' — за наявності консолідації чи роздільного обліку

== Система оподаткування ==

Визначає всю логіку податкового блоку.

{| class="wikitable"
! Параметр !! Можливі значення
|-
| Система оподаткування || Загальна / спрощена
|-
| Група єдиного податку || 2, 3 (для спрощеної)
|-
| Статус платника ПДВ || Так / ні, дата реєстрації, ІПН платника ПДВ
|-
| Період з податку на прибуток || Квартальний / річний
|-
| Податкові різниці || Застосовуються / не застосовуються
|-
| Особливі статуси || Платник акцизу, рентних платежів, спецрежими
|}

== Облікова політика (бухгалтерський облік) ==

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

=== План рахунків ===
Стандартний за [[НП(С)БО]] або за [[МСФЗ]], з визначенням робочого плану рахунків і субрахунків.

=== Метод оцінки вибуття запасів ===
Один з дозволених методів:
* ідентифікована собівартість;
* середньозважена собівартість (FIFO);
* нормативні затрати;
* ціна продажу.

{{Увага|Критичний параметр — визначає, як списуватимуться товари й матеріали. Зміна після проведення документів дуже болісна.}}

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

=== Межа вартості ОЗ / МНМА ===
Межа розмежування основних засобів та [[МНМА|малоцінних необоротних матеріальних активів]] і метод їхньої амортизації:
* 100 % при введенні в експлуатацію;
* 50 % / 50 %.

=== Собівартість ===
Порядок формування виробничої собівартості: які витрати входять до неї, база розподілу загальновиробничих витрат (ЗВВ), віднесення постійних та змінних ЗВВ.

=== Резерви та забезпечення ===
* резерв сумнівних боргів;
* резерв відпусток;
* забезпечення гарантійних зобов'язань;
* метод розрахунку кожного з них.

=== Курсові різниці ===
Порядок перерахунку монетарних статей; джерело курсу — як правило, офіційний курс [[НБУ]].

== Параметри ПДВ ==

Для організації — платника ПДВ:

* застосовувані ставки: 20 %, 14 %, 7 %, 0 %, звільнення;
* правило '''першої події''' для дати податкових зобов'язань і кредиту;
* порядок реєстрації податкових накладних та розрахунків коригування в [[ЄРПН]];
* облік за напрямками для розподілу ПДВ (оподатковувані / неоподатковувані операції), розрахунок [[ЧВ|частки використання]];
* касовий метод — за наявності відповідних операцій.

== Фінансові періоди та валюта ==

* '''Дата старту''' — початок ведення обліку в системі
* '''Фінансовий рік''' і межі облікових періодів
* '''Закриття періоду''' — механізм заборони змін заднім числом
* '''Функціональна валюта''' — гривня
* '''Завантаження курсів''' — джерело НБУ, автоматичне чи ручне
* '''Валюти взаєморозрахунків''' та валютних рахунків

== Аналітичні розрізи ==

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

* підрозділи, центри витрат / центри відповідальності;
* напрямки діяльності, номенклатурні групи;
* статті витрат і доходів;
* проєкти, замовлення (для позамовного обліку).

== Технічні параметри роботи ERP ==

{| class="wikitable"
! Група !! Що налаштовується
|-
| Нумерація документів || Префікси, періодичність скидання, роздільна для кожної організації
|-
| Округлення || Правила округлення сум і кількостей
|-
| Друковані форми || Первинні та друковані форми під потреби організації
|-
| Права доступу || Ролі користувачів, розмежування за організаціями й підрозділами
|-
| Регламентована звітність || Форми декларацій і фінзвітності, електронна подача
|-
| Початкові залишки || Введення залишків по рахунках і аналітиці на дату старту
|}

== Порядок впровадження ==

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

== Примітки ==

<references />

[[Категорія:Регламентований облік]]
[[Категорія:Налаштування ERP]]
[[Категорія:Облікова політика]]

Налаштування організації (приклад)

2026-07-14T13:07:16Z

[[Файл:Obl pol1.png|центр|міні|600x600пкс]]
[[Файл:Obl pol3.png|центр|міні|600x600пкс]]
[[Файл:Obl pol2.png|центр|міні|600x600пкс]]
[[Файл:Obl pol5.png|центр|міні|600x600пкс]]
[[Файл:Obl pol7.png|центр|міні|600x600пкс]]

'''Налаштування організації для бухгалтерського та податкового обліку''' — це формалізація [[Облікова політика|облікової політики]] підприємства у параметрах [[ERP-система|ERP-системи]]. Нижче наведено перелік реквізитів, політик та параметрів, які необхідно визначити для коректної роботи регламентованого обліку.

__TOC__

== Реквізити та статус організації ==

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

* '''Найменування''' — повне та скорочене
* '''Код''' — ЄДРПОУ (для юросіб) або ІПН / РНОКПП (для ФОП)
* '''Організаційно-правова форма'''
* '''Адреси''' — юридична та фактична, контактні дані
* '''Реєстраційні дані''' в органах ДПС, орган ДПС за місцем обліку
* '''Банківські рахунки''' у форматі IBAN, обслуговуючі банки
* '''Відповідальні особи''' — керівник, головний бухгалтер, касир (підставляються у первинні документи та звітність)
* '''Відокремлені підрозділи''' — за наявності консолідації чи роздільного обліку

== Система оподаткування ==

Визначає всю логіку податкового блоку.

{| class="wikitable"
! Параметр !! Можливі значення
|-
| Система оподаткування || Загальна / спрощена
|-
| Група єдиного податку || 2, 3 (для спрощеної)
|-
| Статус платника ПДВ || Так / ні, дата реєстрації, ІПН платника ПДВ
|-
| Період з податку на прибуток || Квартальний / річний
|-
| Податкові різниці || Застосовуються / не застосовуються
|-
| Особливі статуси || Платник акцизу, рентних платежів, спецрежими
|}

== Облікова політика (бухгалтерський облік) ==

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

=== План рахунків ===
Стандартний за [[НП(С)БО]] або за [[МСФЗ]], з визначенням робочого плану рахунків і субрахунків.

=== Метод оцінки вибуття запасів ===
Один з дозволених методів:
* ідентифікована собівартість;
* середньозважена собівартість (FIFO);
* нормативні затрати;
* ціна продажу.

{{Увага|Критичний параметр — визначає, як списуватимуться товари й матеріали. Зміна після проведення документів дуже болісна.}}

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

=== Межа вартості ОЗ / МНМА ===
Межа розмежування основних засобів та [[МНМА|малоцінних необоротних матеріальних активів]] і метод їхньої амортизації:
* 100 % при введенні в експлуатацію;
* 50 % / 50 %.

=== Собівартість ===
Порядок формування виробничої собівартості: які витрати входять до неї, база розподілу загальновиробничих витрат (ЗВВ), віднесення постійних та змінних ЗВВ.

=== Резерви та забезпечення ===
* резерв сумнівних боргів;
* резерв відпусток;
* забезпечення гарантійних зобов'язань;
* метод розрахунку кожного з них.

=== Курсові різниці ===
Порядок перерахунку монетарних статей; джерело курсу — як правило, офіційний курс [[НБУ]].

== Параметри ПДВ ==

Для організації — платника ПДВ:

* застосовувані ставки: 20 %, 14 %, 7 %, 0 %, звільнення;
* правило '''першої події''' для дати податкових зобов'язань і кредиту;
* порядок реєстрації податкових накладних та розрахунків коригування в [[ЄРПН]];
* облік за напрямками для розподілу ПДВ (оподатковувані / неоподатковувані операції), розрахунок [[ЧВ|частки використання]];
* касовий метод — за наявності відповідних операцій.

== Фінансові періоди та валюта ==

* '''Дата старту''' — початок ведення обліку в системі
* '''Фінансовий рік''' і межі облікових періодів
* '''Закриття періоду''' — механізм заборони змін заднім числом
* '''Функціональна валюта''' — гривня
* '''Завантаження курсів''' — джерело НБУ, автоматичне чи ручне
* '''Валюти взаєморозрахунків''' та валютних рахунків

== Аналітичні розрізи ==

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

* підрозділи, центри витрат / центри відповідальності;
* напрямки діяльності, номенклатурні групи;
* статті витрат і доходів;
* проєкти, замовлення (для позамовного обліку).

== Технічні параметри роботи ERP ==

{| class="wikitable"
! Група !! Що налаштовується
|-
| Нумерація документів || Префікси, періодичність скидання, роздільна для кожної організації
|-
| Округлення || Правила округлення сум і кількостей
|-
| Друковані форми || Первинні та друковані форми під потреби організації
|-
| Права доступу || Ролі користувачів, розмежування за організаціями й підрозділами
|-
| Регламентована звітність || Форми декларацій і фінзвітності, електронна подача
|-
| Початкові залишки || Введення залишків по рахунках і аналітиці на дату старту
|}

== Порядок впровадження ==

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

== Примітки ==

<references />

[[index.php?title=Категорія:Регламентований облік]]
[[index.php?title=Категорія:Налаштування ERP]]
[[index.php?title=Категорія:Облікова політика]]

Налаштування організації (приклад)

2026-07-14T13:02:40Z

<gallery mode="slideshow">
Файл:Index.php?title=Файл:Obl pol6.png|посилання=Файл:Obl_pol6.png
Файл:Index.php?title=Файл:Obl pol7.png|посилання=Файл:Obl_pol7.png
Файл:Index.php?title=Файл:Obl pol4.png|посилання=Файл:Obl_pol4.png
Файл:Index.php?title=Файл:Obl pol5.png|посилання=Файл:Obl_pol5.png
Файл:Index.php?title=Файл:Obl pol2.png|посилання=Файл:Obl_pol2.png
Файл:Index.php?title=Файл:Obl pol3.png|посилання=Файл:Obl_pol3.png
Файл:Index.php?title=Файл:Obl pol1.png|посилання=Файл:Obl_pol1.png
</gallery>'''Налаштування організації для бухгалтерського та податкового обліку''' — це формалізація [[Облікова політика|облікової політики]] підприємства у параметрах [[ERP-система|ERP-системи]]. Нижче наведено перелік реквізитів, політик та параметрів, які необхідно визначити для коректної роботи регламентованого обліку.

__TOC__

== Реквізити та статус організації ==

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

* '''Найменування''' — повне та скорочене
* '''Код''' — ЄДРПОУ (для юросіб) або ІПН / РНОКПП (для ФОП)
* '''Організаційно-правова форма'''
* '''Адреси''' — юридична та фактична, контактні дані
* '''Реєстраційні дані''' в органах ДПС, орган ДПС за місцем обліку
* '''Банківські рахунки''' у форматі IBAN, обслуговуючі банки
* '''Відповідальні особи''' — керівник, головний бухгалтер, касир (підставляються у первинні документи та звітність)
* '''Відокремлені підрозділи''' — за наявності консолідації чи роздільного обліку

== Система оподаткування ==

Визначає всю логіку податкового блоку.

{| class="wikitable"
! Параметр !! Можливі значення
|-
| Система оподаткування || Загальна / спрощена
|-
| Група єдиного податку || 2, 3 (для спрощеної)
|-
| Статус платника ПДВ || Так / ні, дата реєстрації, ІПН платника ПДВ
|-
| Період з податку на прибуток || Квартальний / річний
|-
| Податкові різниці || Застосовуються / не застосовуються
|-
| Особливі статуси || Платник акцизу, рентних платежів, спецрежими
|}

== Облікова політика (бухгалтерський облік) ==

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

=== План рахунків ===
Стандартний за [[НП(С)БО]] або за [[МСФЗ]], з визначенням робочого плану рахунків і субрахунків.

=== Метод оцінки вибуття запасів ===
Один з дозволених методів:
* ідентифікована собівартість;
* середньозважена собівартість (FIFO);
* нормативні затрати;
* ціна продажу.

{{Увага|Критичний параметр — визначає, як списуватимуться товари й матеріали. Зміна після проведення документів дуже болісна.}}

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

=== Межа вартості ОЗ / МНМА ===
Межа розмежування основних засобів та [[МНМА|малоцінних необоротних матеріальних активів]] і метод їхньої амортизації:
* 100 % при введенні в експлуатацію;
* 50 % / 50 %.

=== Собівартість ===
Порядок формування виробничої собівартості: які витрати входять до неї, база розподілу загальновиробничих витрат (ЗВВ), віднесення постійних та змінних ЗВВ.

=== Резерви та забезпечення ===
* резерв сумнівних боргів;
* резерв відпусток;
* забезпечення гарантійних зобов'язань;
* метод розрахунку кожного з них.

=== Курсові різниці ===
Порядок перерахунку монетарних статей; джерело курсу — як правило, офіційний курс [[НБУ]].

== Параметри ПДВ ==

Для організації — платника ПДВ:

* застосовувані ставки: 20 %, 14 %, 7 %, 0 %, звільнення;
* правило '''першої події''' для дати податкових зобов'язань і кредиту;
* порядок реєстрації податкових накладних та розрахунків коригування в [[ЄРПН]];
* облік за напрямками для розподілу ПДВ (оподатковувані / неоподатковувані операції), розрахунок [[ЧВ|частки використання]];
* касовий метод — за наявності відповідних операцій.

== Фінансові періоди та валюта ==

* '''Дата старту''' — початок ведення обліку в системі
* '''Фінансовий рік''' і межі облікових періодів
* '''Закриття періоду''' — механізм заборони змін заднім числом
* '''Функціональна валюта''' — гривня
* '''Завантаження курсів''' — джерело НБУ, автоматичне чи ручне
* '''Валюти взаєморозрахунків''' та валютних рахунків

== Аналітичні розрізи ==

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

* підрозділи, центри витрат / центри відповідальності;
* напрямки діяльності, номенклатурні групи;
* статті витрат і доходів;
* проєкти, замовлення (для позамовного обліку).

== Технічні параметри роботи ERP ==

{| class="wikitable"
! Група !! Що налаштовується
|-
| Нумерація документів || Префікси, періодичність скидання, роздільна для кожної організації
|-
| Округлення || Правила округлення сум і кількостей
|-
| Друковані форми || Первинні та друковані форми під потреби організації
|-
| Права доступу || Ролі користувачів, розмежування за організаціями й підрозділами
|-
| Регламентована звітність || Форми декларацій і фінзвітності, електронна подача
|-
| Початкові залишки || Введення залишків по рахунках і аналітиці на дату старту
|}

== Порядок впровадження ==

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

== Примітки ==

<references />

[[index.php?title=Категорія:Регламентований облік]]
[[index.php?title=Категорія:Налаштування ERP]]
[[index.php?title=Категорія:Облікова політика]]

Налаштування організації (приклад)

2026-07-14T13:01:33Z

<gallery>
Файл:Obl pol6.png
Файл:Obl pol7.png
Файл:Obl pol4.png
Файл:Obl pol5.png
Файл:Obl pol2.png
Файл:Obl pol3.png
Файл:Obl pol1.png
</gallery>'''Налаштування організації для бухгалтерського та податкового обліку''' — це формалізація [[Облікова політика|облікової політики]] підприємства у параметрах [[ERP-система|ERP-системи]]. Нижче наведено перелік реквізитів, політик та параметрів, які необхідно визначити для коректної роботи регламентованого обліку.

__TOC__

== Реквізити та статус організації ==

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

* '''Найменування''' — повне та скорочене
* '''Код''' — ЄДРПОУ (для юросіб) або ІПН / РНОКПП (для ФОП)
* '''Організаційно-правова форма'''
* '''Адреси''' — юридична та фактична, контактні дані
* '''Реєстраційні дані''' в органах ДПС, орган ДПС за місцем обліку
* '''Банківські рахунки''' у форматі IBAN, обслуговуючі банки
* '''Відповідальні особи''' — керівник, головний бухгалтер, касир (підставляються у первинні документи та звітність)
* '''Відокремлені підрозділи''' — за наявності консолідації чи роздільного обліку

== Система оподаткування ==

Визначає всю логіку податкового блоку.

{| class="wikitable"
! Параметр !! Можливі значення
|-
| Система оподаткування || Загальна / спрощена
|-
| Група єдиного податку || 2, 3 (для спрощеної)
|-
| Статус платника ПДВ || Так / ні, дата реєстрації, ІПН платника ПДВ
|-
| Період з податку на прибуток || Квартальний / річний
|-
| Податкові різниці || Застосовуються / не застосовуються
|-
| Особливі статуси || Платник акцизу, рентних платежів, спецрежими
|}

== Облікова політика (бухгалтерський облік) ==

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

=== План рахунків ===
Стандартний за [[НП(С)БО]] або за [[МСФЗ]], з визначенням робочого плану рахунків і субрахунків.

=== Метод оцінки вибуття запасів ===
Один з дозволених методів:
* ідентифікована собівартість;
* середньозважена собівартість (FIFO);
* нормативні затрати;
* ціна продажу.

{{Увага|Критичний параметр — визначає, як списуватимуться товари й матеріали. Зміна після проведення документів дуже болісна.}}

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

=== Межа вартості ОЗ / МНМА ===
Межа розмежування основних засобів та [[МНМА|малоцінних необоротних матеріальних активів]] і метод їхньої амортизації:
* 100 % при введенні в експлуатацію;
* 50 % / 50 %.

=== Собівартість ===
Порядок формування виробничої собівартості: які витрати входять до неї, база розподілу загальновиробничих витрат (ЗВВ), віднесення постійних та змінних ЗВВ.

=== Резерви та забезпечення ===
* резерв сумнівних боргів;
* резерв відпусток;
* забезпечення гарантійних зобов'язань;
* метод розрахунку кожного з них.

=== Курсові різниці ===
Порядок перерахунку монетарних статей; джерело курсу — як правило, офіційний курс [[НБУ]].

== Параметри ПДВ ==

Для організації — платника ПДВ:

* застосовувані ставки: 20 %, 14 %, 7 %, 0 %, звільнення;
* правило '''першої події''' для дати податкових зобов'язань і кредиту;
* порядок реєстрації податкових накладних та розрахунків коригування в [[ЄРПН]];
* облік за напрямками для розподілу ПДВ (оподатковувані / неоподатковувані операції), розрахунок [[ЧВ|частки використання]];
* касовий метод — за наявності відповідних операцій.

== Фінансові періоди та валюта ==

* '''Дата старту''' — початок ведення обліку в системі
* '''Фінансовий рік''' і межі облікових періодів
* '''Закриття періоду''' — механізм заборони змін заднім числом
* '''Функціональна валюта''' — гривня
* '''Завантаження курсів''' — джерело НБУ, автоматичне чи ручне
* '''Валюти взаєморозрахунків''' та валютних рахунків

== Аналітичні розрізи ==

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

* підрозділи, центри витрат / центри відповідальності;
* напрямки діяльності, номенклатурні групи;
* статті витрат і доходів;
* проєкти, замовлення (для позамовного обліку).

== Технічні параметри роботи ERP ==

{| class="wikitable"
! Група !! Що налаштовується
|-
| Нумерація документів || Префікси, періодичність скидання, роздільна для кожної організації
|-
| Округлення || Правила округлення сум і кількостей
|-
| Друковані форми || Первинні та друковані форми під потреби організації
|-
| Права доступу || Ролі користувачів, розмежування за організаціями й підрозділами
|-
| Регламентована звітність || Форми декларацій і фінзвітності, електронна подача
|-
| Початкові залишки || Введення залишків по рахунках і аналітиці на дату старту
|}

== Порядок впровадження ==

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

== Примітки ==

<references />

[[Категорія:Регламентований облік]]
[[Категорія:Налаштування ERP]]
[[Категорія:Облікова політика]]

Налаштування організації (приклад)

2026-07-14T13:01:25Z

<gallery>
Файл:Obl pol6.png
Файл:Obl pol7.png
Файл:Obl pol4.png
Файл:Obl pol5.png
Файл:Obl pol2.png
Файл:Obl pol3.png
Файл:Obl pol1.png
</gallery>'''Налаштування організації для бухгалтерського та податкового обліку''' — це формалізація [[Облікова політика|облікової політики]] підприємства у параметрах [[ERP-система|ERP-системи]]. Нижче наведено перелік реквізитів, політик та параметрів, які необхідно визначити для коректної роботи регламентованого обліку.

__TOC__

== Реквізити та статус організації ==

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

* '''Найменування''' — повне та скорочене
* '''Код''' — ЄДРПОУ (для юросіб) або ІПН / РНОКПП (для ФОП)
* '''Організаційно-правова форма'''
* '''Адреси''' — юридична та фактична, контактні дані
* '''Реєстраційні дані''' в органах ДПС, орган ДПС за місцем обліку
* '''Банківські рахунки''' у форматі IBAN, обслуговуючі банки
* '''Відповідальні особи''' — керівник, головний бухгалтер, касир (підставляються у первинні документи та звітність)
* '''Відокремлені підрозділи''' — за наявності консолідації чи роздільного обліку

== Система оподаткування ==

Визначає всю логіку податкового блоку.

{| class="wikitable"
! Параметр !! Можливі значення
|-
| Система оподаткування || Загальна / спрощена
|-
| Група єдиного податку || 2, 3 (для спрощеної)
|-
| Статус платника ПДВ || Так / ні, дата реєстрації, ІПН платника ПДВ
|-
| Період з податку на прибуток || Квартальний / річний
|-
| Податкові різниці || Застосовуються / не застосовуються
|-
| Особливі статуси || Платник акцизу, рентних платежів, спецрежими
|}

== Облікова політика (бухгалтерський облік) ==

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

=== План рахунків ===
Стандартний за [[НП(С)БО]] або за [[МСФЗ]], з визначенням робочого плану рахунків і субрахунків.

=== Метод оцінки вибуття запасів ===
Один з дозволених методів:
* ідентифікована собівартість;
* середньозважена собівартість (FIFO);
* нормативні затрати;
* ціна продажу.

{{Увага|Критичний параметр — визначає, як списуватимуться товари й матеріали. Зміна після проведення документів дуже болісна.}}

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

=== Межа вартості ОЗ / МНМА ===
Межа розмежування основних засобів та [[МНМА|малоцінних необоротних матеріальних активів]] і метод їхньої амортизації:
* 100 % при введенні в експлуатацію;
* 50 % / 50 %.

=== Собівартість ===
Порядок формування виробничої собівартості: які витрати входять до неї, база розподілу загальновиробничих витрат (ЗВВ), віднесення постійних та змінних ЗВВ.

=== Резерви та забезпечення ===
* резерв сумнівних боргів;
* резерв відпусток;
* забезпечення гарантійних зобов'язань;
* метод розрахунку кожного з них.

=== Курсові різниці ===
Порядок перерахунку монетарних статей; джерело курсу — як правило, офіційний курс [[НБУ]].

== Параметри ПДВ ==

Для організації — платника ПДВ:

* застосовувані ставки: 20 %, 14 %, 7 %, 0 %, звільнення;
* правило '''першої події''' для дати податкових зобов'язань і кредиту;
* порядок реєстрації податкових накладних та розрахунків коригування в [[ЄРПН]];
* облік за напрямками для розподілу ПДВ (оподатковувані / неоподатковувані операції), розрахунок [[ЧВ|частки використання]];
* касовий метод — за наявності відповідних операцій.

== Фінансові періоди та валюта ==

* '''Дата старту''' — початок ведення обліку в системі
* '''Фінансовий рік''' і межі облікових періодів
* '''Закриття періоду''' — механізм заборони змін заднім числом
* '''Функціональна валюта''' — гривня
* '''Завантаження курсів''' — джерело НБУ, автоматичне чи ручне
* '''Валюти взаєморозрахунків''' та валютних рахунків

== Аналітичні розрізи ==

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

* підрозділи, центри витрат / центри відповідальності;
* напрямки діяльності, номенклатурні групи;
* статті витрат і доходів;
* проєкти, замовлення (для позамовного обліку).

== Технічні параметри роботи ERP ==

{| class="wikitable"
! Група !! Що налаштовується
|-
| Нумерація документів || Префікси, періодичність скидання, роздільна для кожної організації
|-
| Округлення || Правила округлення сум і кількостей
|-
| Друковані форми || Первинні та друковані форми під потреби організації
|-
| Права доступу || Ролі користувачів, розмежування за організаціями й підрозділами
|-
| Регламентована звітність || Форми декларацій і фінзвітності, електронна подача
|-
| Початкові залишки || Введення залишків по рахунках і аналітиці на дату старту
|}

== Порядок впровадження ==

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

== Примітки ==

<references />

[[index.php?title=Категорія:Регламентований облік]]
[[index.php?title=Категорія:Налаштування ERP]]
[[index.php?title=Категорія:Облікова політика]]

Файл:Obl pol7.png

2026-07-14T13:00:14Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:Obl pol6.png

2026-07-14T13:00:14Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:Obl pol5.png

2026-07-14T13:00:13Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:Obl pol4.png

2026-07-14T13:00:13Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:Obl pol3.png

2026-07-14T13:00:12Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:Obl pol2.png

2026-07-14T13:00:12Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:Obl pol1.png

2026-07-14T13:00:11Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Налаштування організації (приклад)

2026-07-14T12:55:58Z

R: Створена сторінка: {{Стаття про облік | система = ERP | розділ = Регламентований облік | актуально_на = 2026 }} '''Налаштування організації для бухгалтерського та податкового обліку''' — це формалізація облікової політики підприємства у параметрах [...

{{Стаття про облік
| система = ERP
| розділ = Регламентований облік
| актуально_на = 2026
}}

'''Налаштування організації для бухгалтерського та податкового обліку''' — це формалізація [[облікова політика|облікової політики]] підприємства у параметрах [[ERP-система|ERP-системи]]. Нижче наведено перелік реквізитів, політик та параметрів, які необхідно визначити для коректної роботи регламентованого обліку.

__TOC__

== Реквізити та статус організації ==

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

* '''Найменування''' — повне та скорочене
* '''Код''' — ЄДРПОУ (для юросіб) або ІПН / РНОКПП (для ФОП)
* '''Організаційно-правова форма'''
* '''Адреси''' — юридична та фактична, контактні дані
* '''Реєстраційні дані''' в органах ДПС, орган ДПС за місцем обліку
* '''Банківські рахунки''' у форматі IBAN, обслуговуючі банки
* '''Відповідальні особи''' — керівник, головний бухгалтер, касир (підставляються у первинні документи та звітність)
* '''Відокремлені підрозділи''' — за наявності консолідації чи роздільного обліку

== Система оподаткування ==

Визначає всю логіку податкового блоку.

{| class="wikitable"
! Параметр !! Можливі значення
|-
| Система оподаткування || Загальна / спрощена
|-
| Група єдиного податку || 2, 3 (для спрощеної)
|-
| Статус платника ПДВ || Так / ні, дата реєстрації, ІПН платника ПДВ
|-
| Період з податку на прибуток || Квартальний / річний
|-
| Податкові різниці || Застосовуються / не застосовуються
|-
| Особливі статуси || Платник акцизу, рентних платежів, спецрежими
|}

== Облікова політика (бухгалтерський облік) ==

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

=== План рахунків ===
Стандартний за [[НП(С)БО]] або за [[МСФЗ]], з визначенням робочого плану рахунків і субрахунків.

=== Метод оцінки вибуття запасів ===
Один з дозволених методів:
* ідентифікована собівартість;
* середньозважена собівартість (FIFO);
* нормативні затрати;
* ціна продажу.

{{Увага|Критичний параметр — визначає, як списуватимуться товари й матеріали. Зміна після проведення документів дуже болісна.}}

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

=== Межа вартості ОЗ / МНМА ===
Межа розмежування основних засобів та [[МНМА|малоцінних необоротних матеріальних активів]] і метод їхньої амортизації:
* 100 % при введенні в експлуатацію;
* 50 % / 50 %.

=== Собівартість ===
Порядок формування виробничої собівартості: які витрати входять до неї, база розподілу загальновиробничих витрат (ЗВВ), віднесення постійних та змінних ЗВВ.

=== Резерви та забезпечення ===
* резерв сумнівних боргів;
* резерв відпусток;
* забезпечення гарантійних зобов'язань;
* метод розрахунку кожного з них.

=== Курсові різниці ===
Порядок перерахунку монетарних статей; джерело курсу — як правило, офіційний курс [[НБУ]].

== Параметри ПДВ ==

Для організації — платника ПДВ:

* застосовувані ставки: 20 %, 14 %, 7 %, 0 %, звільнення;
* правило '''першої події''' для дати податкових зобов'язань і кредиту;
* порядок реєстрації податкових накладних та розрахунків коригування в [[ЄРПН]];
* облік за напрямками для розподілу ПДВ (оподатковувані / неоподатковувані операції), розрахунок [[ЧВ|частки використання]];
* касовий метод — за наявності відповідних операцій.

== Фінансові періоди та валюта ==

* '''Дата старту''' — початок ведення обліку в системі
* '''Фінансовий рік''' і межі облікових періодів
* '''Закриття періоду''' — механізм заборони змін заднім числом
* '''Функціональна валюта''' — гривня
* '''Завантаження курсів''' — джерело НБУ, автоматичне чи ручне
* '''Валюти взаєморозрахунків''' та валютних рахунків

== Аналітичні розрізи ==

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

* підрозділи, центри витрат / центри відповідальності;
* напрямки діяльності, номенклатурні групи;
* статті витрат і доходів;
* проєкти, замовлення (для позамовного обліку).

== Технічні параметри роботи ERP ==

{| class="wikitable"
! Група !! Що налаштовується
|-
| Нумерація документів || Префікси, періодичність скидання, роздільна для кожної організації
|-
| Округлення || Правила округлення сум і кількостей
|-
| Друковані форми || Первинні та друковані форми під потреби організації
|-
| Права доступу || Ролі користувачів, розмежування за організаціями й підрозділами
|-
| Регламентована звітність || Форми декларацій і фінзвітності, електронна подача
|-
| Початкові залишки || Введення залишків по рахунках і аналітиці на дату старту
|}

== Порядок впровадження ==

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

== Примітки ==

<references />

[[Категорія:Регламентований облік]]
[[Категорія:Налаштування ERP]]
[[Категорія:Облікова політика]]

Приклади розрахунків

2026-07-14T12:53:54Z

== Основні засоби ==
[[Приклад розрахунків основних засобів, згідно українського законодавства]]

[[Налаштування організації (приклад)]]

Приклад розрахунків основних засобів, згідно українського законодавства

2026-07-14T12:43:49Z

= Амортизація основних засобів: методи та повний помісячний розрахунок =

'''Амортизація''' — це систематичний розподіл вартості необоротного активу, яка амортизується, протягом строку його корисного використання (пп. 14.1.3 ПКУ; п. 4 НП(С)БО 7). Стаття містить нормативну базу, порядок вибору методу та '''повний помісячний розрахунок за всіма п'ятьма методами за весь строк служби (60 місяців)'''.

== Нормативна база ==

Бухгалтерський облік регулює '''НП(С)БО 7 «Основні засоби»''', податковий — '''ст. 138 Податкового кодексу України'''.

* Амортизація нараховується '''щомісячно''', починаючи з місяця, '''наступного за місяцем''', у якому об'єкт став придатним для використання, і припиняється з місяця, наступного за місяцем вибуття (п. 29 НП(С)БО 7).
* НП(С)БО 7 передбачає '''5 методів''' амортизації (п. 26).
* Для податку на прибуток діють '''мінімально допустимі строки''' корисного використання (пп. 138.3.3 ПКУ). Наприклад, '''група 4 (машини та обладнання) — 5 років''' (для ЕОМ у складі групи — 2 роки).
* Якщо бухгалтерський строк '''менший''' за мінімальний податковий — для податку беруть '''податковий мінімум'''; якщо '''дорівнює або більший''' — беруть бухгалтерський.
* Виробничий метод для податкової амортизації '''дозволений з 23.05.2020''' (Закон № 466-IX); при його застосуванні мінімально допустимі строки '''не застосовуються'''.

== Методи амортизації (п. 26 НП(С)БО 7) ==

# '''Прямолінійний''' — рівномірне списання протягом строку служби.
# '''Зменшення залишкової вартості''' — фіксована норма до залишкової вартості; більші суми на початку служби.
# '''Прискореного зменшення залишкової вартості''' — подвоєна прямолінійна норма до залишкової вартості.
# '''Кумулятивний''' — річна сума = вартість, що амортизується × кумулятивний коефіцієнт (сума чисел років).
# '''Виробничий''' — сума прямо залежить від фактичного обсягу продукції (робіт) за місяць.

Для '''малоцінних необоротних матеріальних активів (група 11)''' і '''бібліотечних фондів (група 10)''' дозволені лише '''прямолінійний і виробничий''' методи, або нарахування '''50 % / 50 %''', або '''100 % у першому місяці''' використання (п. 27 НП(С)БО 7).

== Хто обирає метод амортизації та чим керується ==

=== Хто обирає ===

Метод амортизації '''підприємство обирає самостійно''' (п. 28 НП(С)БО 7). На практиці:
* '''Керівник підприємства''' затверджує загальні підходи '''наказом про облікову політику''' (за поданням '''головного бухгалтера''').
* '''Постійно діюча комісія''' при введенні об'єкта в експлуатацію в '''Акті введення в експлуатацію''' визначає для кожного об'єкта '''строк корисного використання''', '''ліквідаційну вартість''' і '''метод амортизації'''.

Метод обирається '''окремо для кожного об'єкта''' (або групи однорідних об'єктів).

=== Головний критерій вибору ===

Основний принцип (п. 28 НП(С)БО 7): метод обирається '''з урахуванням очікуваного способу отримання економічних вигод''' від використання об'єкта:
* вигоди надходять '''рівномірно''' → прямолінійний;
* віддача '''інтенсивніша на початку''' служби → зменшення залишкової, прискореного зменшення або кумулятивний;
* вигоди '''пропорційні обсягу випуску''' → виробничий.

Строк корисного використання визначають самостійно, враховуючи (п. 24 НП(С)БО 7): очікувану потужність і продуктивність, фізичний та моральний знос, правові й інші обмеження, інші чинники.

=== Орієнтири для кожного методу ===

{| class="wikitable"
|+ '''Коли який метод доцільний'''
! style="background:#455A64; color:white;" | Метод
! style="background:#455A64; color:white;" | Коли застосовують
|-
| '''Прямолінійний''' || Вигоди надходять рівномірно; найпростіший і найпоширеніший; '''зближує бухгалтерський і податковий облік'''. Будівлі, меблі, офісне обладнання.
|-
| '''Зменшення залишкової вартості''' || Найбільша віддача '''на початку''' служби, швидке моральне старіння. '''Обов'язково ліквідаційна вартість > 0.'''
|-
| '''Прискореного зменшення''' || Те саме, але простіша норма (подвоєна прямолінійна). Техніка, IT, транспорт.
|-
| '''Кумулятивний''' || Прискорене списання '''без вимоги''' до ліквідаційної вартості; плавніше за метод зменшення залишкової.
|-
| '''Виробничий''' || Знос прямо залежить від '''обсягу'''; '''не має незмінної місячної суми'''.
|}

=== Чинники, що впливають на рішення ===

* '''Очікуваний спосіб отримання вигод''' — головний нормативний критерій.
* '''Характер експлуатації''' (рівномірний / інтенсивний / залежний від обсягу).
* '''Вплив на звітність''' — прискорені методи зменшують прибуток і вартість активів у перші роки.
* '''Податкові наслідки''' — мінімально допустимі строки; виробничий метод дозволяє їх не застосовувати.
* '''Зближення обліків''' — щоб уникнути податкових різниць, часто обирають '''прямолінійний'''.
* '''Простота адміністрування'''.

=== Зміна методу ===

Метод можна '''переглянути''', якщо змінюється очікуваний спосіб отримання вигод (п. 28 НП(С)БО 7). Це '''зміна облікової оцінки''', застосовується '''перспективно''' — з місяця, наступного за місяцем зміни (НП(С)БО 6); перерахунок раніше нарахованої амортизації не робиться.

== Вихідні дані прикладу ==

Обладнання (група 4): первісна вартість '''120 000 грн''', строк '''5 років (60 місяців)''', введено в експлуатацію у '''грудні 2024 р.''' → амортизація з '''січня 2025 р.'''
'''Ліквідаційна вартість:''' 0 грн для всіх методів, окрім методу зменшення залишкової вартості, що '''математично вимагає значення > 0''' — для нього прийнято '''3 750 грн'''.

== Приклад 1. Прямолінійний метод ==

Річна сума = (120 000 − 0) / 5 = '''24 000 грн'''; місячна = '''2 000 грн'''. Проводка щомісяця: '''Дт 92 – Кт 131 = 2 000 грн'''.

{| class="wikitable" style="text-align:right;"
|+ '''Прямолінійний метод — весь строк служби (2025–2029)'''
! style="background:#2E5B9E; color:white;" | Період
! style="background:#2E5B9E; color:white;" | Амортизація за місяць, грн
! style="background:#2E5B9E; color:white;" | Накопичена (Кт 131), грн
! style="background:#2E5B9E; color:white;" | Залишкова вартість, грн
|-
| style="text-align:left;" | січ. 2025 || 2 000 || 2 000 || 118 000
|-
| style="text-align:left;" | лют. 2025 || 2 000 || 4 000 || 116 000
|-
| style="text-align:left;" | бер. 2025 || 2 000 || 6 000 || 114 000
|-
| style="text-align:left;" | кві. 2025 || 2 000 || 8 000 || 112 000
|-
| style="text-align:left;" | тра. 2025 || 2 000 || 10 000 || 110 000
|-
| style="text-align:left;" | чер. 2025 || 2 000 || 12 000 || 108 000
|-
| style="text-align:left;" | лип. 2025 || 2 000 || 14 000 || 106 000
|-
| style="text-align:left;" | сер. 2025 || 2 000 || 16 000 || 104 000
|-
| style="text-align:left;" | вер. 2025 || 2 000 || 18 000 || 102 000
|-
| style="text-align:left;" | жовт. 2025 || 2 000 || 20 000 || 100 000
|-
| style="text-align:left;" | лист. 2025 || 2 000 || 22 000 || 98 000
|-
| style="text-align:left;" | груд. 2025 || 2 000 || 24 000 || 96 000
|- style="background:#DCE6F1; font-weight:bold;"
| style="text-align:left;" | Разом за 2025 рік || 24 000 || 24 000 || 96 000
|-
| style="text-align:left;" | січ. 2026 || 2 000 || 26 000 || 94 000
|-
| style="text-align:left;" | лют. 2026 || 2 000 || 28 000 || 92 000
|-
| style="text-align:left;" | бер. 2026 || 2 000 || 30 000 || 90 000
|-
| style="text-align:left;" | кві. 2026 || 2 000 || 32 000 || 88 000
|-
| style="text-align:left;" | тра. 2026 || 2 000 || 34 000 || 86 000
|-
| style="text-align:left;" | чер. 2026 || 2 000 || 36 000 || 84 000
|-
| style="text-align:left;" | лип. 2026 || 2 000 || 38 000 || 82 000
|-
| style="text-align:left;" | сер. 2026 || 2 000 || 40 000 || 80 000
|-
| style="text-align:left;" | вер. 2026 || 2 000 || 42 000 || 78 000
|-
| style="text-align:left;" | жовт. 2026 || 2 000 || 44 000 || 76 000
|-
| style="text-align:left;" | лист. 2026 || 2 000 || 46 000 || 74 000
|-
| style="text-align:left;" | груд. 2026 || 2 000 || 48 000 || 72 000
|- style="background:#DCE6F1; font-weight:bold;"
| style="text-align:left;" | Разом за 2026 рік || 24 000 || 48 000 || 72 000
|-
| style="text-align:left;" | січ. 2027 || 2 000 || 50 000 || 70 000
|-
| style="text-align:left;" | лют. 2027 || 2 000 || 52 000 || 68 000
|-
| style="text-align:left;" | бер. 2027 || 2 000 || 54 000 || 66 000
|-
| style="text-align:left;" | кві. 2027 || 2 000 || 56 000 || 64 000
|-
| style="text-align:left;" | тра. 2027 || 2 000 || 58 000 || 62 000
|-
| style="text-align:left;" | чер. 2027 || 2 000 || 60 000 || 60 000
|-
| style="text-align:left;" | лип. 2027 || 2 000 || 62 000 || 58 000
|-
| style="text-align:left;" | сер. 2027 || 2 000 || 64 000 || 56 000
|-
| style="text-align:left;" | вер. 2027 || 2 000 || 66 000 || 54 000
|-
| style="text-align:left;" | жовт. 2027 || 2 000 || 68 000 || 52 000
|-
| style="text-align:left;" | лист. 2027 || 2 000 || 70 000 || 50 000
|-
| style="text-align:left;" | груд. 2027 || 2 000 || 72 000 || 48 000
|- style="background:#DCE6F1; font-weight:bold;"
| style="text-align:left;" | Разом за 2027 рік || 24 000 || 72 000 || 48 000
|-
| style="text-align:left;" | січ. 2028 || 2 000 || 74 000 || 46 000
|-
| style="text-align:left;" | лют. 2028 || 2 000 || 76 000 || 44 000
|-
| style="text-align:left;" | бер. 2028 || 2 000 || 78 000 || 42 000
|-
| style="text-align:left;" | кві. 2028 || 2 000 || 80 000 || 40 000
|-
| style="text-align:left;" | тра. 2028 || 2 000 || 82 000 || 38 000
|-
| style="text-align:left;" | чер. 2028 || 2 000 || 84 000 || 36 000
|-
| style="text-align:left;" | лип. 2028 || 2 000 || 86 000 || 34 000
|-
| style="text-align:left;" | сер. 2028 || 2 000 || 88 000 || 32 000
|-
| style="text-align:left;" | вер. 2028 || 2 000 || 90 000 || 30 000
|-
| style="text-align:left;" | жовт. 2028 || 2 000 || 92 000 || 28 000
|-
| style="text-align:left;" | лист. 2028 || 2 000 || 94 000 || 26 000
|-
| style="text-align:left;" | груд. 2028 || 2 000 || 96 000 || 24 000
|- style="background:#DCE6F1; font-weight:bold;"
| style="text-align:left;" | Разом за 2028 рік || 24 000 || 96 000 || 24 000
|-
| style="text-align:left;" | січ. 2029 || 2 000 || 98 000 || 22 000
|-
| style="text-align:left;" | лют. 2029 || 2 000 || 100 000 || 20 000
|-
| style="text-align:left;" | бер. 2029 || 2 000 || 102 000 || 18 000
|-
| style="text-align:left;" | кві. 2029 || 2 000 || 104 000 || 16 000
|-
| style="text-align:left;" | тра. 2029 || 2 000 || 106 000 || 14 000
|-
| style="text-align:left;" | чер. 2029 || 2 000 || 108 000 || 12 000
|-
| style="text-align:left;" | лип. 2029 || 2 000 || 110 000 || 10 000
|-
| style="text-align:left;" | сер. 2029 || 2 000 || 112 000 || 8 000
|-
| style="text-align:left;" | вер. 2029 || 2 000 || 114 000 || 6 000
|-
| style="text-align:left;" | жовт. 2029 || 2 000 || 116 000 || 4 000
|-
| style="text-align:left;" | лист. 2029 || 2 000 || 118 000 || 2 000
|-
| style="text-align:left;" | груд. 2029 || 2 000 || 120 000 || 0
|- style="background:#DCE6F1; font-weight:bold;"
| style="text-align:left;" | Разом за 2029 рік || 24 000 || 120 000 || 0
|- style="background:#DCE6F1; font-weight:bold;"
| style="text-align:left;" | РАЗОМ за 5 років || 120 000 || 120 000 || 0
|}

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

== Приклад 2. Виробничий метод ==

Загальний розрахунковий обсяг продукції — 240 000 од. Ставка = 120 000 / 240 000 = '''0,5 грн/од.''' Проводка: '''Дт 23 – Кт 131'''.

{| class="wikitable" style="text-align:right;"
|+ '''Виробничий метод — приклад повного року (2025)'''
! style="background:#2E7D32; color:white;" | Період
! style="background:#2E7D32; color:white;" | Обсяг, од.
! style="background:#2E7D32; color:white;" | Ставка, грн/од.
! style="background:#2E7D32; color:white;" | Амортизація за місяць, грн
! style="background:#2E7D32; color:white;" | Накопичена, грн
! style="background:#2E7D32; color:white;" | Залишкова вартість, грн
|-
| style="text-align:left;" | січ. 2025 || 1 800 || 0,50 || 900 || 900 || 119 100
|-
| style="text-align:left;" | лют. 2025 || 2 000 || 0,50 || 1 000 || 1 900 || 118 100
|-
| style="text-align:left;" | бер. 2025 || 2 200 || 0,50 || 1 100 || 3 000 || 117 000
|-
| style="text-align:left;" | кві. 2025 || 1 500 || 0,50 || 750 || 3 750 || 116 250
|-
| style="text-align:left;" | тра. 2025 || 2 500 || 0,50 || 1 250 || 5 000 || 115 000
|-
| style="text-align:left;" | чер. 2025 || 3 000 || 0,50 || 1 500 || 6 500 || 113 500
|- style="background:#FFF3CD;"
| style="text-align:left;" | '''лип. 2025 (ремонт)''' || 0 || 0,50 || '''0''' || 6 500 || 113 500
|-
| style="text-align:left;" | сер. 2025 || 2 800 || 0,50 || 1 400 || 7 900 || 112 100
|-
| style="text-align:left;" | вер. 2025 || 2 600 || 0,50 || 1 300 || 9 200 || 110 800
|-
| style="text-align:left;" | жовт. 2025 || 2 400 || 0,50 || 1 200 || 10 400 || 109 600
|-
| style="text-align:left;" | лист. 2025 || 2 000 || 0,50 || 1 000 || 11 400 || 108 600
|-
| style="text-align:left;" | груд. 2025 || 1 700 || 0,50 || 850 || 12 250 || 107 750
|- style="background:#D4EDDA; font-weight:bold;"
| style="text-align:left;" | Разом за 2025 рік || 24 500 || — || 12 250 || 12 250 || 107 750
|}

'''Особливість методу:''' виробничий метод '''не має фіксованого календарного графіка''' — амортизація нараховується пропорційно '''фактичному''' обсягу випуску і триває, доки сумарний обсяг не досягне розрахункових 240 000 од. (тобто доки накопичена амортизація не сягне 120 000 грн). Тому його показано за '''повний рік''' як зразок помісячної механіки; для наступних періодів суми залежать від реального виробництва.

== Приклад 3. Зменшення залишкової вартості ==

Річна норма: На = 1 − ⁵√(3 750 / 120 000) = '''50 %'''. Річна сума = залишкова вартість на початок року × 50 %.

{| class="wikitable" style="text-align:right;"
|+ '''Зменшення залишкової вартості — весь строк служби (норма 50 %)'''
! style="background:#6A1B9A; color:white;" | Період
! style="background:#6A1B9A; color:white;" | Амортизація за місяць, грн
! style="background:#6A1B9A; color:white;" | Накопичена (Кт 131), грн
! style="background:#6A1B9A; color:white;" | Залишкова вартість, грн
|-
| style="text-align:left;" | січ. 2025 || 5 000 || 5 000 || 115 000
|-
| style="text-align:left;" | лют. 2025 || 5 000 || 10 000 || 110 000
|-
| style="text-align:left;" | бер. 2025 || 5 000 || 15 000 || 105 000
|-
| style="text-align:left;" | кві. 2025 || 5 000 || 20 000 || 100 000
|-
| style="text-align:left;" | тра. 2025 || 5 000 || 25 000 || 95 000
|-
| style="text-align:left;" | чер. 2025 || 5 000 || 30 000 || 90 000
|-
| style="text-align:left;" | лип. 2025 || 5 000 || 35 000 || 85 000
|-
| style="text-align:left;" | сер. 2025 || 5 000 || 40 000 || 80 000
|-
| style="text-align:left;" | вер. 2025 || 5 000 || 45 000 || 75 000
|-
| style="text-align:left;" | жовт. 2025 || 5 000 || 50 000 || 70 000
|-
| style="text-align:left;" | лист. 2025 || 5 000 || 55 000 || 65 000
|-
| style="text-align:left;" | груд. 2025 || 5 000 || 60 000 || 60 000
|- style="background:#E1BEE7; font-weight:bold;"
| style="text-align:left;" | Разом за 2025 рік || 60 000 || 60 000 || 60 000
|-
| style="text-align:left;" | січ. 2026 || 2 500 || 62 500 || 57 500
|-
| style="text-align:left;" | лют. 2026 || 2 500 || 65 000 || 55 000
|-
| style="text-align:left;" | бер. 2026 || 2 500 || 67 500 || 52 500
|-
| style="text-align:left;" | кві. 2026 || 2 500 || 70 000 || 50 000
|-
| style="text-align:left;" | тра. 2026 || 2 500 || 72 500 || 47 500
|-
| style="text-align:left;" | чер. 2026 || 2 500 || 75 000 || 45 000
|-
| style="text-align:left;" | лип. 2026 || 2 500 || 77 500 || 42 500
|-
| style="text-align:left;" | сер. 2026 || 2 500 || 80 000 || 40 000
|-
| style="text-align:left;" | вер. 2026 || 2 500 || 82 500 || 37 500
|-
| style="text-align:left;" | жовт. 2026 || 2 500 || 85 000 || 35 000
|-
| style="text-align:left;" | лист. 2026 || 2 500 || 87 500 || 32 500
|-
| style="text-align:left;" | груд. 2026 || 2 500 || 90 000 || 30 000
|- style="background:#E1BEE7; font-weight:bold;"
| style="text-align:left;" | Разом за 2026 рік || 30 000 || 90 000 || 30 000
|-
| style="text-align:left;" | січ. 2027 || 1 250 || 91 250 || 28 750
|-
| style="text-align:left;" | лют. 2027 || 1 250 || 92 500 || 27 500
|-
| style="text-align:left;" | бер. 2027 || 1 250 || 93 750 || 26 250
|-
| style="text-align:left;" | кві. 2027 || 1 250 || 95 000 || 25 000
|-
| style="text-align:left;" | тра. 2027 || 1 250 || 96 250 || 23 750
|-
| style="text-align:left;" | чер. 2027 || 1 250 || 97 500 || 22 500
|-
| style="text-align:left;" | лип. 2027 || 1 250 || 98 750 || 21 250
|-
| style="text-align:left;" | сер. 2027 || 1 250 || 100 000 || 20 000
|-
| style="text-align:left;" | вер. 2027 || 1 250 || 101 250 || 18 750
|-
| style="text-align:left;" | жовт. 2027 || 1 250 || 102 500 || 17 500
|-
| style="text-align:left;" | лист. 2027 || 1 250 || 103 750 || 16 250
|-
| style="text-align:left;" | груд. 2027 || 1 250 || 105 000 || 15 000
|- style="background:#E1BEE7; font-weight:bold;"
| style="text-align:left;" | Разом за 2027 рік || 15 000 || 105 000 || 15 000
|-
| style="text-align:left;" | січ. 2028 || 625 || 105 625 || 14 375
|-
| style="text-align:left;" | лют. 2028 || 625 || 106 250 || 13 750
|-
| style="text-align:left;" | бер. 2028 || 625 || 106 875 || 13 125
|-
| style="text-align:left;" | кві. 2028 || 625 || 107 500 || 12 500
|-
| style="text-align:left;" | тра. 2028 || 625 || 108 125 || 11 875
|-
| style="text-align:left;" | чер. 2028 || 625 || 108 750 || 11 250
|-
| style="text-align:left;" | лип. 2028 || 625 || 109 375 || 10 625
|-
| style="text-align:left;" | сер. 2028 || 625 || 110 000 || 10 000
|-
| style="text-align:left;" | вер. 2028 || 625 || 110 625 || 9 375
|-
| style="text-align:left;" | жовт. 2028 || 625 || 111 250 || 8 750
|-
| style="text-align:left;" | лист. 2028 || 625 || 111 875 || 8 125
|-
| style="text-align:left;" | груд. 2028 || 625 || 112 500 || 7 500
|- style="background:#E1BEE7; font-weight:bold;"
| style="text-align:left;" | Разом за 2028 рік || 7 500 || 112 500 || 7 500
|-
| style="text-align:left;" | січ. 2029 || 312,50 || 112 812,50 || 7 187,50
|-
| style="text-align:left;" | лют. 2029 || 312,50 || 113 125 || 6 875
|-
| style="text-align:left;" | бер. 2029 || 312,50 || 113 437,50 || 6 562,50
|-
| style="text-align:left;" | кві. 2029 || 312,50 || 113 750 || 6 250
|-
| style="text-align:left;" | тра. 2029 || 312,50 || 114 062,50 || 5 937,50
|-
| style="text-align:left;" | чер. 2029 || 312,50 || 114 375 || 5 625
|-
| style="text-align:left;" | лип. 2029 || 312,50 || 114 687,50 || 5 312,50
|-
| style="text-align:left;" | сер. 2029 || 312,50 || 115 000 || 5 000
|-
| style="text-align:left;" | вер. 2029 || 312,50 || 115 312,50 || 4 687,50
|-
| style="text-align:left;" | жовт. 2029 || 312,50 || 115 625 || 4 375
|-
| style="text-align:left;" | лист. 2029 || 312,50 || 115 937,50 || 4 062,50
|-
| style="text-align:left;" | груд. 2029 || 312,50 || 116 250 || 3 750
|- style="background:#E1BEE7; font-weight:bold;"
| style="text-align:left;" | Разом за 2029 рік || 3 750 || 116 250 || 3 750
|- style="background:#E1BEE7; font-weight:bold;"
| style="text-align:left;" | РАЗОМ за 5 років || 116 250 || 116 250 || 3 750 (= ліквідаційна 3 750)
|}

== Приклад 4. Прискореного зменшення залишкової вартості ==

Річна норма = (100 % / 5) × 2 = '''40 %''' (ліквідаційна вартість у нормі не враховується). В '''останній рік''' списується '''весь залишок''' до ліквідаційної вартості, тому місячна сума 2029 р. більша за 2028 р.

{| class="wikitable" style="text-align:right;"
|+ '''Прискореного зменшення залишкової вартості — весь строк (норма 40 %)'''
! style="background:#E65100; color:white;" | Період
! style="background:#E65100; color:white;" | Амортизація за місяць, грн
! style="background:#E65100; color:white;" | Накопичена (Кт 131), грн
! style="background:#E65100; color:white;" | Залишкова вартість, грн
|-
| style="text-align:left;" | січ. 2025 || 4 000 || 4 000 || 116 000
|-
| style="text-align:left;" | лют. 2025 || 4 000 || 8 000 || 112 000
|-
| style="text-align:left;" | бер. 2025 || 4 000 || 12 000 || 108 000
|-
| style="text-align:left;" | кві. 2025 || 4 000 || 16 000 || 104 000
|-
| style="text-align:left;" | тра. 2025 || 4 000 || 20 000 || 100 000
|-
| style="text-align:left;" | чер. 2025 || 4 000 || 24 000 || 96 000
|-
| style="text-align:left;" | лип. 2025 || 4 000 || 28 000 || 92 000
|-
| style="text-align:left;" | сер. 2025 || 4 000 || 32 000 || 88 000
|-
| style="text-align:left;" | вер. 2025 || 4 000 || 36 000 || 84 000
|-
| style="text-align:left;" | жовт. 2025 || 4 000 || 40 000 || 80 000
|-
| style="text-align:left;" | лист. 2025 || 4 000 || 44 000 || 76 000
|-
| style="text-align:left;" | груд. 2025 || 4 000 || 48 000 || 72 000
|- style="background:#FFE0B2; font-weight:bold;"
| style="text-align:left;" | Разом за 2025 рік || 48 000 || 48 000 || 72 000
|-
| style="text-align:left;" | січ. 2026 || 2 400 || 50 400 || 69 600
|-
| style="text-align:left;" | лют. 2026 || 2 400 || 52 800 || 67 200
|-
| style="text-align:left;" | бер. 2026 || 2 400 || 55 200 || 64 800
|-
| style="text-align:left;" | кві. 2026 || 2 400 || 57 600 || 62 400
|-
| style="text-align:left;" | тра. 2026 || 2 400 || 60 000 || 60 000
|-
| style="text-align:left;" | чер. 2026 || 2 400 || 62 400 || 57 600
|-
| style="text-align:left;" | лип. 2026 || 2 400 || 64 800 || 55 200
|-
| style="text-align:left;" | сер. 2026 || 2 400 || 67 200 || 52 800
|-
| style="text-align:left;" | вер. 2026 || 2 400 || 69 600 || 50 400
|-
| style="text-align:left;" | жовт. 2026 || 2 400 || 72 000 || 48 000
|-
| style="text-align:left;" | лист. 2026 || 2 400 || 74 400 || 45 600
|-
| style="text-align:left;" | груд. 2026 || 2 400 || 76 800 || 43 200
|- style="background:#FFE0B2; font-weight:bold;"
| style="text-align:left;" | Разом за 2026 рік || 28 800 || 76 800 || 43 200
|-
| style="text-align:left;" | січ. 2027 || 1 440 || 78 240 || 41 760
|-
| style="text-align:left;" | лют. 2027 || 1 440 || 79 680 || 40 320
|-
| style="text-align:left;" | бер. 2027 || 1 440 || 81 120 || 38 880
|-
| style="text-align:left;" | кві. 2027 || 1 440 || 82 560 || 37 440
|-
| style="text-align:left;" | тра. 2027 || 1 440 || 84 000 || 36 000
|-
| style="text-align:left;" | чер. 2027 || 1 440 || 85 440 || 34 560
|-
| style="text-align:left;" | лип. 2027 || 1 440 || 86 880 || 33 120
|-
| style="text-align:left;" | сер. 2027 || 1 440 || 88 320 || 31 680
|-
| style="text-align:left;" | вер. 2027 || 1 440 || 89 760 || 30 240
|-
| style="text-align:left;" | жовт. 2027 || 1 440 || 91 200 || 28 800
|-
| style="text-align:left;" | лист. 2027 || 1 440 || 92 640 || 27 360
|-
| style="text-align:left;" | груд. 2027 || 1 440 || 94 080 || 25 920
|- style="background:#FFE0B2; font-weight:bold;"
| style="text-align:left;" | Разом за 2027 рік || 17 280 || 94 080 || 25 920
|-
| style="text-align:left;" | січ. 2028 || 864 || 94 944 || 25 056
|-
| style="text-align:left;" | лют. 2028 || 864 || 95 808 || 24 192
|-
| style="text-align:left;" | бер. 2028 || 864 || 96 672 || 23 328
|-
| style="text-align:left;" | кві. 2028 || 864 || 97 536 || 22 464
|-
| style="text-align:left;" | тра. 2028 || 864 || 98 400 || 21 600
|-
| style="text-align:left;" | чер. 2028 || 864 || 99 264 || 20 736
|-
| style="text-align:left;" | лип. 2028 || 864 || 100 128 || 19 872
|-
| style="text-align:left;" | сер. 2028 || 864 || 100 992 || 19 008
|-
| style="text-align:left;" | вер. 2028 || 864 || 101 856 || 18 144
|-
| style="text-align:left;" | жовт. 2028 || 864 || 102 720 || 17 280
|-
| style="text-align:left;" | лист. 2028 || 864 || 103 584 || 16 416
|-
| style="text-align:left;" | груд. 2028 || 864 || 104 448 || 15 552
|- style="background:#FFE0B2; font-weight:bold;"
| style="text-align:left;" | Разом за 2028 рік || 10 368 || 104 448 || 15 552
|-
| style="text-align:left;" | січ. 2029 || 1 296 || 105 744 || 14 256
|-
| style="text-align:left;" | лют. 2029 || 1 296 || 107 040 || 12 960
|-
| style="text-align:left;" | бер. 2029 || 1 296 || 108 336 || 11 664
|-
| style="text-align:left;" | кві. 2029 || 1 296 || 109 632 || 10 368
|-
| style="text-align:left;" | тра. 2029 || 1 296 || 110 928 || 9 072
|-
| style="text-align:left;" | чер. 2029 || 1 296 || 112 224 || 7 776
|-
| style="text-align:left;" | лип. 2029 || 1 296 || 113 520 || 6 480
|-
| style="text-align:left;" | сер. 2029 || 1 296 || 114 816 || 5 184
|-
| style="text-align:left;" | вер. 2029 || 1 296 || 116 112 || 3 888
|-
| style="text-align:left;" | жовт. 2029 || 1 296 || 117 408 || 2 592
|-
| style="text-align:left;" | лист. 2029 || 1 296 || 118 704 || 1 296
|-
| style="text-align:left;" | груд. 2029 || 1 296 || 120 000 || 0
|- style="background:#FFE0B2; font-weight:bold;"
| style="text-align:left;" | Разом за 2029 рік || 15 552 || 120 000 || 0
|- style="background:#FFE0B2; font-weight:bold;"
| style="text-align:left;" | РАЗОМ за 5 років || 120 000 || 120 000 || 0 (= ліквідаційна 0)
|}

== Приклад 5. Кумулятивний метод ==

Сума чисел років = 1+2+3+4+5 = '''15'''. Коефіцієнти за роками: 5/15, 4/15, 3/15, 2/15, 1/15. Вартість, що амортизується = 120 000 грн.

{| class="wikitable" style="text-align:right;"
|+ '''Кумулятивний метод — весь строк служби'''
! style="background:#00695C; color:white;" | Період
! style="background:#00695C; color:white;" | Амортизація за місяць, грн
! style="background:#00695C; color:white;" | Накопичена (Кт 131), грн
! style="background:#00695C; color:white;" | Залишкова вартість, грн
|-
| style="text-align:left;" | січ. 2025 || 3 333,33 || 3 333,33 || 116 666,67
|-
| style="text-align:left;" | лют. 2025 || 3 333,33 || 6 666,66 || 113 333,34
|-
| style="text-align:left;" | бер. 2025 || 3 333,33 || 9 999,99 || 110 000,01
|-
| style="text-align:left;" | кві. 2025 || 3 333,33 || 13 333,32 || 106 666,68
|-
| style="text-align:left;" | тра. 2025 || 3 333,33 || 16 666,65 || 103 333,35
|-
| style="text-align:left;" | чер. 2025 || 3 333,33 || 19 999,98 || 100 000,02
|-
| style="text-align:left;" | лип. 2025 || 3 333,33 || 23 333,31 || 96 666,69
|-
| style="text-align:left;" | сер. 2025 || 3 333,33 || 26 666,64 || 93 333,36
|-
| style="text-align:left;" | вер. 2025 || 3 333,33 || 29 999,97 || 90 000,03
|-
| style="text-align:left;" | жовт. 2025 || 3 333,33 || 33 333,30 || 86 666,70
|-
| style="text-align:left;" | лист. 2025 || 3 333,33 || 36 666,63 || 83 333,37
|-
| style="text-align:left;" | груд. 2025 || 3 333,37 || 40 000 || 80 000
|- style="background:#B2DFDB; font-weight:bold;"
| style="text-align:left;" | Разом за 2025 рік || 40 000 || 40 000 || 80 000
|-
| style="text-align:left;" | січ. 2026 || 2 666,67 || 42 666,67 || 77 333,33
|-
| style="text-align:left;" | лют. 2026 || 2 666,67 || 45 333,34 || 74 666,66
|-
| style="text-align:left;" | бер. 2026 || 2 666,67 || 48 000,01 || 71 999,99
|-
| style="text-align:left;" | кві. 2026 || 2 666,67 || 50 666,68 || 69 333,32
|-
| style="text-align:left;" | тра. 2026 || 2 666,67 || 53 333,35 || 66 666,65
|-
| style="text-align:left;" | чер. 2026 || 2 666,67 || 56 000,02 || 63 999,98
|-
| style="text-align:left;" | лип. 2026 || 2 666,67 || 58 666,69 || 61 333,31
|-
| style="text-align:left;" | сер. 2026 || 2 666,67 || 61 333,36 || 58 666,64
|-
| style="text-align:left;" | вер. 2026 || 2 666,67 || 64 000,03 || 55 999,97
|-
| style="text-align:left;" | жовт. 2026 || 2 666,67 || 66 666,70 || 53 333,30
|-
| style="text-align:left;" | лист. 2026 || 2 666,67 || 69 333,37 || 50 666,63
|-
| style="text-align:left;" | груд. 2026 || 2 666,63 || 72 000 || 48 000
|- style="background:#B2DFDB; font-weight:bold;"
| style="text-align:left;" | Разом за 2026 рік || 32 000 || 72 000 || 48 000
|-
| style="text-align:left;" | січ. 2027 || 2 000 || 74 000 || 46 000
|-
| style="text-align:left;" | лют. 2027 || 2 000 || 76 000 || 44 000
|-
| style="text-align:left;" | бер. 2027 || 2 000 || 78 000 || 42 000
|-
| style="text-align:left;" | кві. 2027 || 2 000 || 80 000 || 40 000
|-
| style="text-align:left;" | тра. 2027 || 2 000 || 82 000 || 38 000
|-
| style="text-align:left;" | чер. 2027 || 2 000 || 84 000 || 36 000
|-
| style="text-align:left;" | лип. 2027 || 2 000 || 86 000 || 34 000
|-
| style="text-align:left;" | сер. 2027 || 2 000 || 88 000 || 32 000
|-
| style="text-align:left;" | вер. 2027 || 2 000 || 90 000 || 30 000
|-
| style="text-align:left;" | жовт. 2027 || 2 000 || 92 000 || 28 000
|-
| style="text-align:left;" | лист. 2027 || 2 000 || 94 000 || 26 000
|-
| style="text-align:left;" | груд. 2027 || 2 000 || 96 000 || 24 000
|- style="background:#B2DFDB; font-weight:bold;"
| style="text-align:left;" | Разом за 2027 рік || 24 000 || 96 000 || 24 000
|-
| style="text-align:left;" | січ. 2028 || 1 333,33 || 97 333,33 || 22 666,67
|-
| style="text-align:left;" | лют. 2028 || 1 333,33 || 98 666,66 || 21 333,34
|-
| style="text-align:left;" | бер. 2028 || 1 333,33 || 99 999,99 || 20 000,01
|-
| style="text-align:left;" | кві. 2028 || 1 333,33 || 101 333,32 || 18 666,68
|-
| style="text-align:left;" | тра. 2028 || 1 333,33 || 102 666,65 || 17 333,35
|-
| style="text-align:left;" | чер. 2028 || 1 333,33 || 103 999,98 || 16 000,02
|-
| style="text-align:left;" | лип. 2028 || 1 333,33 || 105 333,31 || 14 666,69
|-
| style="text-align:left;" | сер. 2028 || 1 333,33 || 106 666,64 || 13 333,36
|-
| style="text-align:left;" | вер. 2028 || 1 333,33 || 107 999,97 || 12 000,03
|-
| style="text-align:left;" | жовт. 2028 || 1 333,33 || 109 333,30 || 10 666,70
|-
| style="text-align:left;" | лист. 2028 || 1 333,33 || 110 666,63 || 9 333,37
|-
| style="text-align:left;" | груд. 2028 || 1 333,37 || 112 000 || 8 000
|- style="background:#B2DFDB; font-weight:bold;"
| style="text-align:left;" | Разом за 2028 рік || 16 000 || 112 000 || 8 000
|-
| style="text-align:left;" | січ. 2029 || 666,67 || 112 666,67 || 7 333,33
|-
| style="text-align:left;" | лют. 2029 || 666,67 || 113 333,34 || 6 666,66
|-
| style="text-align:left;" | бер. 2029 || 666,67 || 114 000,01 || 5 999,99
|-
| style="text-align:left;" | кві. 2029 || 666,67 || 114 666,68 || 5 333,32
|-
| style="text-align:left;" | тра. 2029 || 666,67 || 115 333,35 || 4 666,65
|-
| style="text-align:left;" | чер. 2029 || 666,67 || 116 000,02 || 3 999,98
|-
| style="text-align:left;" | лип. 2029 || 666,67 || 116 666,69 || 3 333,31
|-
| style="text-align:left;" | сер. 2029 || 666,67 || 117 333,36 || 2 666,64
|-
| style="text-align:left;" | вер. 2029 || 666,67 || 118 000,03 || 1 999,97
|-
| style="text-align:left;" | жовт. 2029 || 666,67 || 118 666,70 || 1 333,30
|-
| style="text-align:left;" | лист. 2029 || 666,67 || 119 333,37 || 666,63
|-
| style="text-align:left;" | груд. 2029 || 666,63 || 120 000 || 0
|- style="background:#B2DFDB; font-weight:bold;"
| style="text-align:left;" | Разом за 2029 рік || 8 000 || 120 000 || 0
|- style="background:#B2DFDB; font-weight:bold;"
| style="text-align:left;" | РАЗОМ за 5 років || 120 000 || 120 000 || 0 (= ліквідаційна 0)
|}

== Зведене порівняння методів (річна амортизація) ==

{| class="wikitable" style="text-align:right;"
|+ '''Річна сума амортизації за методами, грн'''
! style="background:#37474F; color:white; text-align:left;" | Метод
! style="background:#37474F; color:white;" | Місяць (рік 1)
! style="background:#37474F; color:white;" | 2025
! style="background:#37474F; color:white;" | 2026
! style="background:#37474F; color:white;" | 2027
! style="background:#37474F; color:white;" | 2028
! style="background:#37474F; color:white;" | 2029
! style="background:#37474F; color:white;" | Разом
|-
| style="text-align:left;" | '''Прямолінійний''' || 2 000,00 || 24 000 || 24 000 || 24 000 || 24 000 || 24 000 || 120 000
|-
| style="text-align:left;" | '''Зменшення залишкової вартості'''* || 5 000,00 || 60 000 || 30 000 || 15 000 || 7 500 || 3 750 || 116 250
|-
| style="text-align:left;" | '''Прискореного зменшення''' || 4 000,00 || 48 000 || 28 800 || 17 280 || 10 368 || 15 552** || 120 000
|-
| style="text-align:left;" | '''Кумулятивний''' || 3 333,33 || 40 000 || 32 000 || 24 000 || 16 000 || 8 000 || 120 000
|-
| style="text-align:left;" | '''Виробничий''' || змінна || colspan="6" style="text-align:center;" | залежить від обсягу випуску щомісяця (усього 120 000 грн за 240 000 од.)
|}
<small>* база амортизації = 116 250 грн (ліквідаційна 3 750 грн).<br>** у 2029 р. списується весь залишок до ліквідаційної вартості (0).</small>

== Бухгалтерські рахунки ==

Нарахування — за кредитом рахунка '''131 «Знос основних засобів»'''; дебет залежить від напряму використання:
* '''Дт 23''' — виробництво;
* '''Дт 91''' — загальновиробничі витрати;
* '''Дт 92''' — адміністративні витрати;
* '''Дт 93''' — витрати на збут;
* '''Дт 949''' — інші витрати операційної діяльності.

== Джерела ==

* Податковий кодекс України, ст. 138, пп. 14.1.3, пп. 138.3.3.
* НП(С)БО 7 «Основні засоби» (наказ Мінфіну від 27.04.2000 № 92), пп. 24, 26, 27, 28, 29.
* НП(С)БО 6 «Виправлення помилок і зміни у фінансових звітах».
* Закон України від 16.01.2020 № 466-IX.

Приклад розрахунків основних засобів, згідно українського законодавства

2026-07-14T11:58:33Z

= Амортизація основних засобів: методи та приклади помісячного розрахунку =

'''Амортизація''' — це систематичний розподіл вартості основного засобу, яка амортизується, протягом строку його корисного використання (пп. 14.1.3 ПКУ; п. 4 НП(С)БО 7). Ця стаття містить нормативну базу, порядок вибору методу нарахування та практичні приклади помісячного розрахунку за рік за всіма п'ятьма методами.

== Нормативна база ==

Бухгалтерський облік регулює '''НП(С)БО 7 «Основні засоби»''', податковий — '''ст. 138 Податкового кодексу України'''.

* Амортизація нараховується '''щомісячно''', починаючи з місяця, '''наступного за місяцем''', у якому об'єкт став придатним для використання, і припиняється з місяця, наступного за місяцем вибуття (п. 29 НП(С)БО 7).
* НП(С)БО 7 передбачає '''5 методів''' амортизації (п. 26).
* Для податку на прибуток діють '''мінімально допустимі строки''' корисного використання (пп. 138.3.3 ПКУ). Наприклад, '''група 4 (машини та обладнання) — 5 років''' (для ЕОМ у складі групи — 2 роки).
* Якщо бухгалтерський строк '''менший''' за мінімальний податковий — для податку беруть '''податковий мінімум'''; якщо '''дорівнює або більший''' — беруть бухгалтерський.
* Виробничий метод для податкової амортизації '''дозволений з 23.05.2020''' (Закон № 466-IX); при його застосуванні мінімально допустимі строки '''не застосовуються'''.

== Методи амортизації ==

Згідно з п. 26 НП(С)БО 7 застосовуються '''п'ять методів''':

# '''Прямолінійний''' — рівномірне списання протягом строку служби.
# '''Зменшення залишкової вартості''' — фіксована норма застосовується до залишкової вартості; більші суми на початку служби.
# '''Прискореного зменшення залишкової вартості''' — подвоєна прямолінійна норма до залишкової вартості.
# '''Кумулятивний''' — річна сума = вартість, що амортизується × кумулятивний коефіцієнт (сума чисел років).
# '''Виробничий''' — сума прямо залежить від фактичного обсягу продукції (робіт) за місяць.

Для '''малоцінних необоротних матеріальних активів (група 11)''' і '''бібліотечних фондів (група 10)''' дозволені лише '''прямолінійний і виробничий''' методи, або нарахування '''50 % / 50 %''', або '''100 % у першому місяці''' використання (п. 27 НП(С)БО 7).

== Хто обирає метод амортизації та чим керується ==

=== Хто обирає ===

Метод амортизації '''підприємство обирає самостійно''' (п. 28 НП(С)БО 7). На практиці:

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

Метод обирається '''окремо для кожного об'єкта''' (або для групи однорідних об'єктів).

=== Головний критерій вибору ===

Основний принцип (п. 28 НП(С)БО 7): метод обирається '''з урахуванням очікуваного способу отримання економічних вигод''' від використання об'єкта.

Тобто ставлять запитання: '''як саме об'єкт приноситиме вигоду?'''
* '''рівномірно''' протягом усього строку → прямолінійний;
* '''інтенсивніше на початку''' (швидко морально застаріває, найбільша віддача в перші роки) → зменшення залишкової, прискореного зменшення або кумулятивний;
* '''пропорційно обсягу випуску / використання''' → виробничий.

Строк корисного використання підприємство теж визначає самостійно, враховуючи (п. 24 НП(С)БО 7): очікувану потужність і продуктивність, фізичний та моральний знос, правові й інші обмеження щодо використання, інші чинники.

=== Орієнтири для кожного методу ===

{| class="wikitable"
|+ '''Коли який метод доцільний'''
! style="background:#455A64; color:white;" | Метод
! style="background:#455A64; color:white;" | Коли застосовують
|-
| '''Прямолінійний''' || Вигоди надходять рівномірно. Найпростіший і найпоширеніший; '''зближує бухгалтерський і податковий облік''' (менше податкових різниць). Будівлі, меблі, офісне обладнання.
|-
| '''Зменшення залишкової вартості''' || Актив дає найбільшу віддачу '''на початку''' служби, швидко морально старіє. '''Обов'язково потрібна ліквідаційна вартість > 0.'''
|-
| '''Прискореного зменшення''' || Те саме, але простіша норма (подвоєна прямолінійна). Техніка, IT-обладнання, транспорт.
|-
| '''Кумулятивний''' || Прискорене списання без вимоги до ліквідаційної вартості; плавніше за метод зменшення залишкової.
|-
| '''Виробничий''' || Знос прямо залежить від '''обсягу''' (верстати з нерівномірним завантаженням, транспорт із прив'язкою до пробігу). '''Не має незмінної місячної суми.'''
|}

=== Чинники, що впливають на рішення ===

* '''Очікуваний спосіб отримання вигод''' — головний нормативний критерій.
* '''Характер експлуатації''' активу (рівномірний / інтенсивний / залежний від обсягу).
* '''Вплив на фінансову звітність''' — прискорені методи зменшують прибуток і вартість активів у перші роки.
* '''Податкові наслідки''' — для платників податку на прибуток, які застосовують різниці за ст. 138 ПКУ, важливі мінімально допустимі строки; виробничий метод дозволяє їх не застосовувати.
* '''Зближення обліків''' — щоб уникнути податкових різниць, часто обирають '''прямолінійний''' метод.
* '''Простота адміністрування'''.

=== Зміна методу ===

Метод можна '''переглянути''', якщо змінюється очікуваний спосіб отримання економічних вигод (п. 28 НП(С)БО 7). Це вважається '''зміною облікової оцінки''' і застосовується '''перспективно''' — з місяця, наступного за місяцем зміни (НП(С)БО 6). Перерахунок раніше нарахованої амортизації не робиться.

== Вихідні дані прикладу ==

Обладнання (група 4): первісна вартість '''120 000 грн''', строк корисного використання '''5 років''', введено в експлуатацію у '''грудні 2024 р.''' → амортизація з '''січня 2025 р.'''

'''Ліквідаційна вартість:''' 0 грн для всіх методів, окрім методу зменшення залишкової вартості, який '''математично вимагає значення > 0''' (інакше норма = 100 %) — для нього прийнято '''3 750 грн'''.

== Приклад 1. Прямолінійний метод ==

Річна сума = (120 000 − 0) / 5 = '''24 000 грн'''; місячна = 24 000 / 12 = '''2 000 грн'''. Проводка щомісяця (адмінобладнання): '''Дт 92 – Кт 131 = 2 000 грн'''.

{| class="wikitable" style="text-align:right;"
|+ '''Прямолінійний метод — 2025 рік'''
! style="background:#2E5B9E; color:white;" | Місяць
! style="background:#2E5B9E; color:white;" | Амортизація за місяць, грн
! style="background:#2E5B9E; color:white;" | Накопичена (Кт 131), грн
! style="background:#2E5B9E; color:white;" | Залишкова вартість, грн
|-
| style="text-align:left;" | Січень || 2 000 || 2 000 || 118 000
|-
| style="text-align:left;" | Лютий || 2 000 || 4 000 || 116 000
|-
| style="text-align:left;" | Березень || 2 000 || 6 000 || 114 000
|-
| style="text-align:left;" | Квітень || 2 000 || 8 000 || 112 000
|-
| style="text-align:left;" | Травень || 2 000 || 10 000 || 110 000
|-
| style="text-align:left;" | Червень || 2 000 || 12 000 || 108 000
|-
| style="text-align:left;" | Липень || 2 000 || 14 000 || 106 000
|-
| style="text-align:left;" | Серпень || 2 000 || 16 000 || 104 000
|-
| style="text-align:left;" | Вересень || 2 000 || 18 000 || 102 000
|-
| style="text-align:left;" | Жовтень || 2 000 || 20 000 || 100 000
|-
| style="text-align:left;" | Листопад || 2 000 || 22 000 || 98 000
|-
| style="text-align:left;" | Грудень || 2 000 || 24 000 || 96 000
|- style="background:#DCE6F1; font-weight:bold;"
| style="text-align:left;" | Разом за рік || 24 000 || — || —
|}

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

== Приклад 2. Виробничий метод ==

Загальний розрахунковий обсяг продукції — 240 000 од. Виробнича ставка = 120 000 / 240 000 = '''0,5 грн/од.''' Проводка: '''Дт 23 – Кт 131'''.

{| class="wikitable" style="text-align:right;"
|+ '''Виробничий метод — 2025 рік'''
! style="background:#2E7D32; color:white;" | Місяць
! style="background:#2E7D32; color:white;" | Обсяг, од.
! style="background:#2E7D32; color:white;" | Ставка, грн/од.
! style="background:#2E7D32; color:white;" | Амортизація за місяць, грн
! style="background:#2E7D32; color:white;" | Накопичена, грн
! style="background:#2E7D32; color:white;" | Залишкова вартість, грн
|-
| style="text-align:left;" | Січень || 1 800 || 0,5 || 900 || 900 || 119 100
|-
| style="text-align:left;" | Лютий || 2 000 || 0,5 || 1 000 || 1 900 || 118 100
|-
| style="text-align:left;" | Березень || 2 200 || 0,5 || 1 100 || 3 000 || 117 000
|-
| style="text-align:left;" | Квітень || 1 500 || 0,5 || 750 || 3 750 || 116 250
|-
| style="text-align:left;" | Травень || 2 500 || 0,5 || 1 250 || 5 000 || 115 000
|-
| style="text-align:left;" | Червень || 3 000 || 0,5 || 1 500 || 6 500 || 113 500
|- style="background:#FFF3CD;"
| style="text-align:left;" | '''Липень (ремонт)''' || 0 || 0,5 ||

Приклад розрахунків основних засобів, згідно українського законодавства

2026-07-14T11:54:48Z

== Нарахування амортизації основних засобів (приклад із помісячним розрахунком) ==

=== Нормативна база ===

Бухгалтерський облік регулює '''НП(С)БО 7 «Основні засоби»''', податковий — '''ст. 138 Податкового кодексу України'''.

* Амортизація нараховується '''щомісячно''', починаючи з місяця, '''наступного за місяцем''', у якому об'єкт став придатним для використання (п. 29 НП(С)БО 7).
* НП(С)БО 7 передбачає '''5 методів''': прямолінійний, зменшення залишкової вартості, прискореного зменшення залишкової вартості, кумулятивний і виробничий.
* Для податку на прибуток діють '''мінімально допустимі строки''' (пп. 138.3.3 ПКУ). Наприклад, '''група 4 (машини та обладнання) — 5 років''' (для ЕОМ у складі групи — 2 роки).
* Якщо бухгалтерський строк менший за мінімальний податковий — для податку беруть '''податковий мінімум'''.
* Виробничий метод для податкової амортизації '''дозволений з 23.05.2020''' (Закон № 466-IX); при його застосуванні мінімально допустимі строки '''не застосовуються'''.

=== Вихідні дані прикладу ===

Обладнання (група 4): первісна вартість '''120 000 грн''', ліквідаційна вартість '''0''', строк корисного використання '''5 років''', введено в експлуатацію у '''грудні 2024 р.''' → амортизація нараховується '''з січня 2025 р.'''

=== Приклад 1. Прямолінійний метод ===

Річна сума = (120 000 − 0) / 5 = '''24 000 грн'''; місячна = 24 000 / 12 = '''2 000 грн'''.

Проводка щомісяця (адмінобладнання): '''Дт 92 – Кт 131 = 2 000 грн'''.

{| class="wikitable" style="text-align:right;"
|+ '''Прямолінійний метод — 2025 рік'''
! style="background:#2E5B9E; color:white;" | Місяць 2025
! style="background:#2E5B9E; color:white;" | Амортизація за місяць, грн
! style="background:#2E5B9E; color:white;" | Накопичена аморт. (Кт 131), грн
! style="background:#2E5B9E; color:white;" | Залишкова вартість, грн
|-
| style="text-align:left;" | Січень || 2 000 || 2 000 || 118 000
|-
| style="text-align:left;" | Лютий || 2 000 || 4 000 || 116 000
|-
| style="text-align:left;" | Березень || 2 000 || 6 000 || 114 000
|-
| style="text-align:left;" | Квітень || 2 000 || 8 000 || 112 000
|-
| style="text-align:left;" | Травень || 2 000 || 10 000 || 110 000
|-
| style="text-align:left;" | Червень || 2 000 || 12 000 || 108 000
|-
| style="text-align:left;" | Липень || 2 000 || 14 000 || 106 000
|-
| style="text-align:left;" | Серпень || 2 000 || 16 000 || 104 000
|-
| style="text-align:left;" | Вересень || 2 000 || 18 000 || 102 000
|-
| style="text-align:left;" | Жовтень || 2 000 || 20 000 || 100 000
|-
| style="text-align:left;" | Листопад || 2 000 || 22 000 || 98 000
|-
| style="text-align:left;" | Грудень || 2 000 || 24 000 || 96 000
|- style="background:#DCE6F1; font-weight:bold;"
| style="text-align:left;" | Разом за рік || 24 000 || — || —
|}

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

=== Приклад 2. Виробничий метод ===

Загальний розрахунковий обсяг продукції — 240 000 од. Виробнича ставка = 120 000 / 240 000 = '''0,5 грн/од.''' Проводка: '''Дт 23 – Кт 131'''.

{| class="wikitable" style="text-align:right;"
|+ '''Виробничий метод — 2025 рік'''
! style="background:#2E7D32; color:white;" | Місяць 2025
! style="background:#2E7D32; color:white;" | Обсяг, од.
! style="background:#2E7D32; color:white;" | Ставка, грн/од.
! style="background:#2E7D32; color:white;" | Амортизація за місяць, грн
! style="background:#2E7D32; color:white;" | Накопичена, грн
! style="background:#2E7D32; color:white;" | Залишкова вартість, грн
|-
| style="text-align:left;" | Січень || 1 800 || 0,5 || 900 || 900 || 119 100
|-
| style="text-align:left;" | Лютий || 2 000 || 0,5 || 1 000 || 1 900 || 118 100
|-
| style="text-align:left;" | Березень || 2 200 || 0,5 || 1 100 || 3 000 || 117 000
|-
| style="text-align:left;" | Квітень || 1 500 || 0,5 || 750 || 3 750 || 116 250
|-
| style="text-align:left;" | Травень || 2 500 || 0,5 || 1 250 || 5 000 || 115 000
|-
| style="text-align:left;" | Червень || 3 000 || 0,5 || 1 500 || 6 500 || 113 500
|- style="background:#FFF3CD;"
| style="text-align:left;" | '''Липень (ремонт)''' || 0 || 0,5 || '''0''' || 6 500 || 113 500
|-
| style="text-align:left;" | Серпень || 2 800 || 0,5 || 1 400 || 7 900 || 112 100
|-
| style="text-align:left;" | Вересень || 2 600 || 0,5 || 1 300 || 9 200 || 110 800
|-
| style="text-align:left;" | Жовтень || 2 400 || 0,5 || 1 200 || 10 400 || 109 600
|-
| style="text-align:left;" | Листопад || 2 000 || 0,5 || 1 000 || 11 400 || 108 600
|-
| style="text-align:left;" | Грудень || 1 700 || 0,5 || 850 || 12 250 || 107 750
|- style="background:#D4EDDA; font-weight:bold;"
| style="text-align:left;" | Разом || 24 500 || — || 12 250 || — || —
|}

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

== Решта методів амортизації (той самий об'єкт) ==

Вихідні дані ті самі: первісна вартість '''120 000 грн''', строк '''5 років''', амортизація з '''січня 2025 р.'''
Примітка: метод зменшення залишкової вартості '''математично вимагає ліквідаційної вартості > 0''' (інакше норма = 100 %), тому для нього прийнято '''ліквідаційну вартість 3 750 грн'''; для інших методів вона = 0.

=== Метод 3. Зменшення залишкової вартості ===

Річна норма: На = 1 − ⁵√(3 750 / 120 000) = '''50 %'''. Річна сума = залишкова вартість на початок року × 50 %.
Рік 1: 120 000 × 50 % = 60 000 грн → місячна = '''5 000 грн'''.

{| class="wikitable" style="text-align:right;"
|+ '''Зменшення залишкової вартості — 1-й рік'''
! style="background:#6A1B9A; color:white;" | Місяць
! style="background:#6A1B9A; color:white;" | Амортизація за місяць, грн
! style="background:#6A1B9A; color:white;" | Накопичена, грн
! style="background:#6A1B9A; color:white;" | Залишкова вартість, грн
|-
| style="text-align:left;" | Січень || 5 000 || 5 000 || 115 000
|-
| style="text-align:left;" | Лютий || 5 000 || 10 000 || 110 000
|-
| style="text-align:left;" | Березень || 5 000 || 15 000 || 105 000
|-
| style="text-align:left;" | Квітень || 5 000 || 20 000 || 100 000
|-
| style="text-align:left;" | Травень || 5 000 || 25 000 || 95 000
|-
| style="text-align:left;" | Червень || 5 000 || 30 000 || 90 000
|-
| style="text-align:left;" | Липень || 5 000 || 35 000 || 85 000
|-
| style="text-align:left;" | Серпень || 5 000 || 40 000 || 80 000
|-
| style="text-align:left;" | Вересень || 5 000 || 45 000 || 75 000
|-
| style="text-align:left;" | Жовтень || 5 000 || 50 000 || 70 000
|-
| style="text-align:left;" | Листопад || 5 000 || 55 000 || 65 000
|-
| style="text-align:left;" | Грудень || 5 000 || 60 000 || 60 000
|- style="background:#E1BEE7; font-weight:bold;"
| style="text-align:left;" | Разом за рік || 60 000 || — || —
|}

=== Метод 4. Прискореного зменшення залишкової вартості ===

Річна норма = (100 % / 5) × 2 = '''40 %''' (ліквідаційна вартість у нормі не враховується).
Рік 1: 120 000 × 40 % = 48 000 грн → місячна = '''4 000 грн'''.

{| class="wikitable" style="text-align:right;"
|+ '''Прискореного зменшення — 1-й рік'''
! style="background:#E65100; color:white;" | Місяць
! style="background:#E65100; color:white;" | Амортизація за місяць, грн
! style="background:#E65100; color:white;" | Накопичена, грн
! style="background:#E65100; color:white;" | Залишкова вартість, грн
|-
| style="text-align:left;" | Січень || 4 000 || 4 000 || 116 000
|-
| style="text-align:left;" | Лютий || 4 000 || 8 000 || 112 000
|-
| style="text-align:left;" | Березень || 4 000 || 12 000 || 108 000
|-
| style="text-align:left;" | Квітень || 4 000 || 16 000 || 104 000
|-
| style="text-align:left;" | Травень || 4 000 || 20 000 || 100 000
|-
| style="text-align:left;" | Червень || 4 000 || 24 000 || 96 000
|-
| style="text-align:left;" | Липень || 4 000 || 28 000 || 92 000
|-
| style="text-align:left;" | Серпень || 4 000 || 32 000 || 88 000
|-
| style="text-align:left;" | Вересень || 4 000 || 36 000 || 84 000
|-
| style="text-align:left;" | Жовтень || 4 000 || 40 000 || 80 000
|-
| style="text-align:left;" | Листопад || 4 000 || 44 000 || 76 000
|-
| style="text-align:left;" | Грудень || 4 000 || 48 000 || 72 000
|- style="background:#FFE0B2; font-weight:bold;"
| style="text-align:left;" | Разом за рік || 48 000 || — || —
|}

=== Метод 5. Кумулятивний ===

Сума чисел років = 1+2+3+4+5 = '''15'''. Кумулятивний коефіцієнт року 1 = 5/15.
Річна сума = 120 000 × 5/15 = 40 000 грн → місячна ≈ '''3 333,33 грн'''.

{| class="wikitable" style="text-align:right;"
|+ '''Кумулятивний — 1-й рік'''
! style="background:#00695C; color:white;" | Місяць
! style="background:#00695C; color:white;" | Амортизація за місяць, грн
! style="background:#00695C; color:white;" | Накопичена, грн
! style="background:#00695C; color:white;" | Залишкова вартість, грн
|-
| style="text-align:left;" | Січень || 3 333,33 || 3 333,33 || 116 666,67
|-
| style="text-align:left;" | Лютий || 3 333,33 || 6 666,67 || 113 333,33
|-
| style="text-align:left;" | Березень || 3 333,33 || 10 000,00 || 110 000,00
|-
| style="text-align:left;" | Квітень || 3 333,33 || 13 333,33 || 106 666,67
|-
| style="text-align:left;" | Травень || 3 333,33 || 16 666,67 || 103 333,33
|-
| style="text-align:left;" | Червень || 3 333,33 || 20 000,00 || 100 000,00
|-
| style="text-align:left;" | Липень || 3 333,33 || 23 333,33 || 96 666,67
|-
| style="text-align:left;" | Серпень || 3 333,33 || 26 666,67 || 93 333,33
|-
| style="text-align:left;" | Вересень || 3 333,33 || 30 000,00 || 90 000,00
|-
| style="text-align:left;" | Жовтень || 3 333,33 || 33 333,33 || 86 666,67
|-
| style="text-align:left;" | Листопад || 3 333,33 || 36 666,67 || 83 333,33
|-
| style="text-align:left;" | Грудень || 3 333,33 || 40 000,00 || 80 000,00
|- style="background:#B2DFDB; font-weight:bold;"
| style="text-align:left;" | Разом за рік || 40 000 || — || —
|}
<small>* грудень враховує заокруглення, тому річна сума точно = 40 000 грн.</small>

== Зведене порівняння методів (річна амортизація за 5 років) ==

{| class="wikitable" style="text-align:right;"
|+ '''Річна сума амортизації за методами, грн'''
! style="background:#37474F; color:white; text-align:left;" | Метод
! style="background:#37474F; color:white;" | Місяць (рік 1)
! style="background:#37474F; color:white;" | Рік 1
! style="background:#37474F; color:white;" | Рік 2
! style="background:#37474F; color:white;" | Рік 3
! style="background:#37474F; color:white;" | Рік 4
! style="background:#37474F; color:white;" | Рік 5
|-
| style="text-align:left;" | '''Прямолінійний''' || 2 000,00 || 24 000 || 24 000 || 24 000 || 24 000 || 24 000
|-
| style="text-align:left;" | '''Зменшення залишкової вартості'''* || 5 000,00 || 60 000 || 30 000 || 15 000 || 7 500 || 3 750
|-
| style="text-align:left;" | '''Прискореного зменшення''' || 4 000,00 || 48 000 || 28 800 || 17 280 || 10 368 || 15 552**
|-
| style="text-align:left;" | '''Кумулятивний''' || 3 333,33 || 40 000 || 32 000 || 24 000 || 16 000 || 8 000
|-
| style="text-align:left;" | '''Виробничий''' || змінна || \multicolumn{5}{c|}{залежить від обсягу випуску щомісяця}
|}
<small>* ліквідаційна вартість 3 750 грн (для решти = 0), тому база амортизації = 116 250 грн.<br>
** у 5-му році списується '''весь залишок''' до ліквідаційної вартості (0), тому сума більша за 4-й рік.</small>

Приклад розрахунків основних засобів, згідно українського законодавства

2026-07-14T11:47:10Z

R: Створена сторінка: == Нарахування амортизації основних засобів (приклад із помісячним розрахунком) == === Нормативна база === Бухгалтерський облік регулює '''НП(С)БО 7 «Основні засоби»''', податковий — '''ст. 138 Податкового кодексу України'''. * Амортизація нараховується '''щоміс...

Приклади розрахунків

2026-07-14T11:47:01Z

== Основні засоби ==
[[Приклад розрахунків основних засобів, згідно українського законодавства]]

Приклади розрахунків

2026-07-14T11:46:18Z

R: Створена сторінка: ыыы

ыыы

Головна сторінка

2026-07-14T11:45:57Z

[[Файл:Wiki k2erp.png|центр|міні|800x800пкс|Wiki K2 ERP]]

== Про систему K2 ERP ==

[[K2 ERP]] — це комплексна система управління підприємством, яка об’єднує фінанси, бухгалтерію, продажі, склад, закупівлі, документообіг, CRM, аналітику та галузеві модулі в єдиному цифровому середовищі. Система допомагає автоматизувати щоденні процеси, зменшити ручну роботу й кількість помилок, контролювати ресурси в реальному часі, швидше обробляти заявки та документи, бачити повну картину бізнесу й приймати точні управлінські рішення на основі актуальних даних. Завдяки модульності, хмарному доступу та гнучкому налаштуванню K2 ERP підходить для компаній різного масштабу й допомагає бізнесу працювати прозоріше, ефективніше та впевнено масштабуватися.

Подробно про систему читайте в статті: [[K2 ERP]]

[[Відмова від 1С та BAS під ключ: перехід неминучий — питання лише в тому, хто встигне зробити його планово]]

[[Чому K2 ERP — реальна альтернатива 1С та BAS? Бо міняти російське ПЗ на “майже те саме” — це вже не стратегія, а бізнесовий мазохізм]]

[[ERP нового покоління: чому власна платформа K2 ERP на Python і TypeScript сильніша за спадщину 1С/BAS та важкі enterprise-рішення]]

[[Короткі відео про роботу в K2 ERP: українська ERP, яку можна побачити в дії]]

[[Ознайомче відео про K2 ERP]]

[[Альтернатива 1С: якою вона повинна бути насправді]]

[[Робимо бізнес разом!]]

[[Не витрачайте роки та гроші на ERP з нуля. Об’єднуймося навколо K2 ERP]]

[[Лавинний розвиток K2 ERP: чому відкрита українська ERP-система розвивається швидше за старий світ 1С/BAS]]

[[Чому K2 ERP йде шляхом швидкої розробки, моделей, конструкторів і об’єднання даних]]

[[Чому K2 ERP розвиває власну систему, а не Odoo, IT-Enterprise чи SAP]]

[[Візитка K2 ERP]]

[[Хто ваш клієнт, K2?]]

[[K2 ERP відкрила безкоштовну хмару для українського бізнесу]]

[[Інструменти розробника K2 ERP]]

[[Програмування зі швидкістю думки]]

[[Чим відрізняється робота в cloud.corp2.eu від власної хмари]]

[[Розробка K2 ERP на замовлення як правильний перехід з 1С та BAS]]

[[Продуктова компанія, інтегратор чи гібридна модель K2 ERP]]

[[Нові можливості K2 ERP: коли система розвивається з параболічною швидкістю (травень 2026)]]

[[Можливості K2 ERP — травень 2026]]

[[Новий модуль «Зарплата та кадри» в K2 ERP: коли зарплата рахується, кадри не губляться, а бухгалтер більше не живе в Excel]]

[[Виробництво без хаосу: як модуль «Виробництво» в K2 ERP веде виріб від специфікації до готової продукції]]

== Вартість K2 ERP ==
[[Платний SaaS-сервіс K2 ERP: окрема ERP-система без купівлі серверної ліцензії]]

== Перехід з 1С та BAS на K2 ERP ==
[[Хакнути структуру 1С: чому “прозорий перехід” з BAS на старих базах — це пастка]]

== Стандартизація ==
[[ISO 9001 Scrum регламент K2 ERP: система якості, тижневі спринти, Zoom-записи, VDoc і Telegram-комунікації|ISO 9001 + Scrum + регламент K2 ERP: система якості, тижневі спринти, Zoom-записи, VDoc і Telegram-комунікації]]

== Акції та пропозиції ==
[[Навчайте студентів працювати з українською ERP-системою K2 ERP — альтернативою 1С та BAS]]

== Вакансії ==
[[Python-програмісти, які хочуть працювати з K2 ERP: не чекайте “колись”. Починайте зараз]]

== Історія про K2 ERP ==
[[Звідки взявся K2® ERP]]

== Сайти K2 ERP ==
[[Ресурси K2 ERP]]

== Комунікація з K2 ERP ==
[[Регламент K2]]

[[Звернення через HelpDesk]]

== Концептуальні підходи та принципи роботи ==
[[Кількість ліцензій BAS проти безліміту K2 ERP]]

[[Концепція передпродажних модулів K2 ERP: як малими внесками перемагати великі системи]]

[[Магія єдиної системи: чому модульний підхід K2 ERP у рази, десятки разів і навіть на порядки ефективніший за 1С/BAS]]

[[AI в K2 ERP: коли облік перестає бути нудним, а бізнес починає дихати на повні груди]]

[[Чи є ризик залежності від одного підрядника при автоматизації бізнесу?]]

[[Другий раз платити за той самий “зоопарк” ніхто не хоче: чому перехід з 1С на K2 ERP — це не про нову кастомізацію, а про нову логіку бізнесу]]

[[Чому “олдскульні” гриди насправді рятують бізнес: краса інтерфейсу не дорівнює силі продукту]]

[[Крос-платформеність: та сама “дрібниця”, на якій великі компанії щороку залишають купу грошей]]

== Пояснення термінів ==

[[Що таке ERP — і чому справжня ERP-система починається там, де закінчується звичка зводити бізнес до бухгалтерії]]

[[Що таке CRM і чому її інтеграція з ERP відкриває нові можливості для бізнесу]]

[[CMS у K2 ERP: сайт компанії, який не просто “висить в інтернеті”, а працює на бізнес]]

[[Інтернет-магазин у K2 ERP: коли онлайн-продажі стають частиною єдиної системи, а не окремим головним болем]]

== Для користувачів ==

[[Початок роботи з K2 ERP]]

[[Звіти в K2 Cloud ERP|Звіти в K2 ERP]]

[[CRM Файли в K2 ERP|CRM + Файли в K2 ERP]]

[[Повне відео демонстрації K2 ERP доступне з оригінальним голосом інтерфейсу та реального показу роботи системи]]

[[Хмара K2 ERP для безкоштовної реальної роботи]]

[[Управлінський облік K2 ERP]]

[[Бухгалтерія K2 ERP]]

[[CRM K2 ERP]]

[[Складський облік K2 ERP (WMS)]]

[[CMS K2 ERP]]

[[Інтернет-магазин K2 ERP]]

[[K2 VDoc]]

[[Галузеві рішення K2 ERP]]

[[Звіти та аналітика K2 ERP]]

[[Поширені питання K2 ERP]]

[[Використання штучного інтелекту в K2 ERP]]

== Для адміністраторів K2 ERP ==

[[Для адміністраторів K2 ERP]]

[[Адміністратор хмари K2 ERP]]

[[Адміністратор гілки K2 ERP]]

[[Адміністратор проєкту K2 ERP]]

[[Користувачі та ролі K2 ERP]]

[[Права доступу K2 ERP]]

[[Налаштування інтерфейсу K2 ERP]]

[[Друковані форми K2 ERP]]

[[Кастомізація звітів K2 ERP]]

[[Контроль і аудит K2 ERP]]

== Для програмістів ==

[[Розгортання системи K2 ERP Python для розробників]]

[[Архітектура K2 ERP]]

[[Встановлення K2 ERP]]

[[Розгортання K2 ERP]]

[[Створення модулів K2 ERP]]

[[База даних K2 ERP]]

[[API K2 ERP]]

[[Інтеграції K2 ERP]]

[[K2 CMS]]

[[Розробка веб-інтерфейсів K2]]

[[Бізнес-процеси K2 ERP]]

[[Права доступу K2 ERP]]

[[Рекомендації для розробників K2]]

[[Класи та команди K2 ERP Python]]

[[Стандарти UI K2 2025]]

== Атестаційні завдання по K2 ERP ==

[[Атестаційні завдання по K2 ERP]]

== K2 ERP PHP ==

[[Практична робота в K2 ERP PHP]]

[[Інструкція по розгортанню K2 ERP PHP]]

[[Класи та команди K2 Cloud ERP PHP]]

== Довідник та модулі системи K2 ERP ==

== Комплексні рішення K2 ERP ==

[[K2 ERP технологічна платформа]]

[[К2 Управлінський облік]]

== Модулі K2 ERP ==

[[K2 Ядро]]

[[K2 CMS]]

[[K2 Інтернет-магазин]]

[[К2 CRM]]

[[К2 WMS]]

[[K2 VDoc (Електронний документообіг)]]

[[К2 Система online-навчання]]

[[К2 Документообіг]]

[[К2 Дошка оголошень]]

[[К2 Портал творів мистецтва]]

[[К2 ТОІР та облік запчастин]]

[[K2 Update]]

[[K2 Фінансовий облік]]

[[K2 Каса]]

[[K2 Ресторан]]

[[K2 Готель]]

[[K2 Модуль Зарплата та кадри]]

[[K2 Модуль Виробництво]]

[[K2 multi-GAAP]]

[[K2 HelpDesk]]

[[K2 Мобільний додаток Android]]

[[K2 Мобільний додаток IOS]]

[[K2 Стоматологічна клініка]]

[[K2 Салон краси]]

[[K2 Бронювання послуг]]

[[K2 Автоперевезення]]

== Інтеграційні модулі K2 ERP ==
[[K2 Модуль Медок]]

[[K2 Модуль Вчасно]]

[[K2 Модуль Птах]]

[[K2 Модуль Мурашина логістика]]

[[K2 Модуль GPS-трекінг]]

[[K2 Модуль Вчасно Каса]]

[[K2 Модуль Ringostat до CRM]]

[[K2 Модуль Нова пошта]]

[[K2 Модуль Укрпошта]]

[[K2 Модуль Телеграм бот до CRM]]

[[K2 Модуль Whatsapp бот до CRM]]

[[K2 Модуль Turbosms до CRM]]

[[K2 Модуль Email до CRM]]

[[K2 Модуль Hurma]]

[[K2 Модуль обмінів з банками]]

[[K2 Модуль Horoshop]]

[[K2 Модуль Rozetka]]

[[K2 Модуль Prom]]

[[K2 Модуль Hotline]]

[[K2 Модуль ДПС]]

[[K2 Модуль Приватбанк]]

[[Модуль Edin]]

[[K2 Модуль Liqpay для інтернет-магазину]]

[[K2 Модуль Wayforpay для інтернет-магазину]]

== Інструментальні модулі K2 ERP ==
[[K2 Конструктор структури бази даних]]

[[K2 Конструктор звітів]]

[[K2 Конструктор BI звітів]]

[[K2 Реплікатор]]

[[IDE в K2 ERP]]

== Десктопні додатки ==
[[K2 Cloud ERP: Десктопний додаток для Linux, Windows та macOS — швидка робота з хмарами без хаосу вкладок]]

[[K2 Desktop — коли потужність розробки перетворюється на зручний інструмент]]

[[K2 Cloud ERP Desktop: один додаток замість десятків вкладок, ярликів і “вічного пошуку потрібного вікна”]]

== Торгове та перефірійне обладнання ==
[[РРО та ПРРО]]

== Модулі на PHP ==
[[Mantis BT K2]]

== Робота в K2 ==
[[Налаштування WireGuard]]

[[Веб-Пошта]]

== Навігація за категоріями ==
Усі статті бази знань автоматично групуються за категоріями:

* [[:Категорія:ERP-системи|ERP-системи]]
* [[:Категорія:Програмне забезпечення, розроблене в Україні|Українське ПЗ]]
* [[:Категорія:Програмне забезпечення для бізнесу|ПЗ для бізнесу]]

== Порівняння систем ==

[[Чим K2 ERP краще за 1С/BAS, Парус/Афіна, Бітрікс, BIMP, A5 та інші ERP]]

[[K2 ERP vs BAS ERP]]

[[K2 ERP vs BAS Управління торгівлею (UT)]]

[[K2 ERP vs Парус-Підприємство]]

[[K2 ERP vs SAP]]

[[K2 ERP vs Microsoft Dynamics 365]]

[[K2 ERP vs Oracle NetSuite]]

[[K2 ERP vs Odoo]]

[[K2 ERP vs Scoro]]

== Партнерство ==
[[Умови партнерства]]

[[Партнери K2 ERP]]

== Кейси K2 ERP ==

[[Кейс: як ми посилили ТОІР транспорту Нової пошти та цифровізували облік ремонтів і деталей для Kamag]]

== Статті по IT ==

[[Скільки реально коштують “дешеві” ліцензії Odoo, Microsoft Dynamics і SAP у порівнянні з K2 ERP]]

[[Україна має виростити власні продуктові IT-компанії. Інакше за нас це зроблять чужі]]

[[Смерть під ковдрою ілюзій: Чому перехід з 1С на BAS у 2026 році — це найдорожчий самообман українського бізнесу]]

[[BAS маскувалась під український продукт. А тепер російський K2 Cloud може маскувати K2 під російський? Дивний маскарад брендів триває]]

[[BAS нема чого запропонувати ринку, крім 1С]]

[[Давайте називати все своїми іменами: 1С, а не BAS. Говоріть завжди 1С, не йдіть на поводу ребрендіга 1С!]]

[[Пастка SaaS-систем]]

[[BAS стає токсичним — чому українському бізнесу час відмовитися від 1С/BAS]]

[[Росія виграє. 12:0 на користь росії]]

[[BAS у вишиванці, або 1С, яка сходила на ребрендинг]]

[[1С нагадує наші технології 20-річної давнини. Ба, це і є технології тих часів]]

[[BAS — це 1С]]

[[1С/BAS та іншому ворожому софту — капут]]

[[Еволюція веде до революції]]

[[Чому українські ERP досі не витіснили 1С та BAS з ринку України за 12 років війни]]

[[1С/BAS: 30 років російського запору в українському бізнесі]]

[[Гібридний трактор Lamborghini і гібридна ERP K2: як українська технологія може змінити ринок автоматизації]]

[[Як російські ERP-системи змінили прапор, але не змінили код]]

[[Кому “заборонено” 1С та BAS?]]

[[BASкетбол з санкціями: як “українська альтернатива 1С” закидає бізнесу рекламні трьохочкові]]

[[BAS, BaaS, BAF — це нова етикетка для старого 1С. Час називати речі своїми іменами]]

[[Як закалявся BAS, або як 1С фарбували на Великдень]]

[[Життя після 1С та BAS: Великий огляд українського ринку ERP-систем та реальних альтернатив у 2026 році]]

[[Відкритий похідний код, Open Source і K2 ERP: коли програмісти відкривають капот, але не віддають ключі від усього автопарку]]

[[Цифрова деокупація та санкції в Україні]]

[[Український бізнес і його токсичні стосунки з 1С/BAS: сміємося, платимо, страждаємо — і далі називаємо це “автоматизацією”]]

[[1С більше не законодавець мод. Тепер тренди створюють українські ERP]]

[[Безкоштовна українська хмара для малого бізнесу: стартуйте сьогодні, зростайте без обмежень]]

[[Не продавати доступ. Продавати свободу: чому майбутнє програмного забезпечення — за відкритими системами з чесною монетизацією]]

[[1С/BAS: софт для країни, де держава не довіряє бізнесу. І саме тому він не потрібен країні, яка хоче бути вільною]]

[[1С/BAS: система, в якій майбутнє давно натиснуло “Вийти без збереження”]]

== Мови програмування, тренди ==
[[Світ у 2025: які мови «правлять балом»]]

== Технічні завдання K2 ERP ==
[[Приклади технічного завдання K2 ERP]]

[[Приклади розрахунків]]

== Акції K2 ERP ==
[[Ловіть шару: передпродажний модуль Бухгалтерії та податкового обліку зараз включає CRM, CMS та інтернет-магазин]]

== Інвестиції в K2 ERP ==
[[Інвестиції в K2 ERP — українську платформу для заміни 1С/BAS та масової автоматизації бізнесу]]

[[Хто працює в K2 ERP]]

== Використання K2 ERP ==
[[K2: платформа, після якої старий софт починає нервово шукати валізу]]

[[Новий модуль K2 ERP для контролю звітності: коли сотні клієнтів, десятки дедлайнів і жодного права на ой, забули]]

[[K2 ERP як український Біткоїн]]

[[Варіанти використання K2 ERP по напрямкам]]

[[ERP продукти]]

[[K2 ERP — українська ERP для виробництва, складу, торгівлі, ФОП, агро, логістики та заміни BAS ERP]]

[[Всі ERP терміни]]

[[Всі бізнес-процеси]]

[[Всі інтеграції]]

[[Всі українські сервіси]]

[[Всі ERP модулі]]

[[BAS / 1С / SAP / Odoo / Dynamics]]

[[Всі 1С конфігурації]]

[[Всі BAS конфігурації]]

[[Всі 1С терміни]]

[[Всі BAS терміни]]

[[Всі отраслеві рішення 1С]]

== CRM ==
[[Варіанти використання K2 ERP CRM по напрямкам]]

[[CRM продукти]]

[[K2 ERP CRM - універсальна CRM для виробництва, складу, торговлі, ФОП, інтернет-магазину та заміни Bitrix24, 1C CRM]]

[[Всі терміни CRM]]

== Інтернет-магази ==
[[Варіанти використання K2 ERP інтернет-магазин по напрямкам]]

[[Продукти інтернет-магазинів]]

[[K2 ERP Інтернет-магазин - універсальний інтернет-магазин для заміни ShopScript та інших російських рішень]]

[[Всі терміни інтернет-магазинів]]

== Санкції та докази ==
[[Поглинути 1С, BAS та інший ворожий софт: чому перенесення залишків — це ще не справжня відмова]]

[[Мені соромно за українські ЗМІ — чому медіа мають писати про український софт, K2 ERP та заміну 1С/BAS]]

[[Лавочка стала закриватись: 215 продуктів ворожого софту заборонено]]

[[Український бізнес інвестує в російське, бо думає, що українське помре]]

[[Схема мережі 1С, побудованої в Україні під виглядом BAS: коли “ми вже не 1С” звучить як “ми просто змінили табличку на дверях”]]

[[Пертнери BAS - партнери росії]]

[[Скільки грошей 1С намагається “збити” з українського бізнесу через листи щастя]]

[[Не продовжуйте ІТС на BAS. Бо BAS — це 1С]]

[[Вали російський бізнес, вали російський софт!]]

[[Програмне забезпечення, яким можна замінити ворожий софт]]

[[Докази, що BAS - це 1С]]

[[Список компаній, що розповсюджують BAS, не дивлячись на санкції січня 2026]]

[[Реєстр ворожого ПЗ і пов'язаних назв]]

[[Компанії, що почали переходити з ворожого софту]]

[[Реєстр компаній, що досі працюють на ворожому софті]]

[[Реєстр сервісів, що підтримують інтеграцію з ворожим софтом]]

== Реформи ==
[[Реформи К2]]

== Wikipedia ==
[[Різні статті]]

== Книги ==
[[Архітектура 1С-підприємства]]

[[Архітектура та розробка ERP-систем]]

Хакнути структуру 1С: чому “прозорий перехід” з BAS на старих базах — це пастка

2026-07-09T20:49:44Z

[[Файл:Заставка 1.png|центр|міні|800x800пкс|Хакнути структуру 1С]]

Коли бізнес говорить про перехід з 1С або BAS на сучасну ERP-систему, часто виникає спокуслива ідея: '''“А давайте нічого не переносити. Просто підключимо нову систему до старої бази 1С/BAS і будемо працювати далі”'''.

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

Але на практиці це приблизно як поставити екран від Tesla в старий “Запорожець” і сказати: тепер у нас електрокар.

'''Не буде електрокара.'''

Бо проблема 1С та BAS не тільки в інтерфейсі. Проблема значно глибше — '''у самій структурі бази даних, типах даних, старих архітектурних рішеннях, конфігураціях, партнерських доробках і технологічному багажі, який тягнеться ще з 90-х років'''.

<div style="border-left: 6px solid #e67e22; background: #fff4e6; padding: 14px 18px; margin: 18px 0; border-radius: 6px;">
'''Головна думка:''' стару базу 1С/BAS можна використовувати як джерело даних для міграції, але не як фундамент для нової ERP-системи.
</div>

== BAS — це не нова архітектура, а стара технологічна лінія 1С ==

1С з’явилась ще у 90-х роках. Спочатку були DOS-версії, потім Windows-версії, далі 1С 7.5, 1С 7.7, потім платформа 8.1, 8.2, 8.3 та наступні версії.

BAS фактично продовжує технологічну лінію 1С 8.3. Змінилася назва, змінилася іконка, змінилася маркетингова обгортка. Але '''фундаментальна спадщина 1С залишилася всередині'''.

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

== 1С 7.7: архітектурна археологія у DBF-файлах ==

У 1С 7.7 дані зберігалися у DBF-файлах. Для свого часу це було нормальним рішенням. Але для сучасної ERP це вже '''технологічна археологія'''.

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

І найцікавіше, що багато компаній досі мають такі бази. Колись почали облік у 1С 7.7, потім звикли, потім накопичили доробки, потім стало страшно переходити, бо можна втратити історію. І так база живе роками.

Це як старий холодильник на дачі: гуде, тече, морозить тільки одну полицю, але '''“викидати шкода, він же ще працює”'''.

== Чому стара структура не може бути фундаментом нової ERP ==

Користувач у 1С бачить меню, довідники, документи, звіти. Для бухгалтера або менеджера цього достатньо. Але для міграції цього замало.

Потрібно розуміти, '''де фізично зберігаються дані''':

* де лежать довідники;
* де лежать документи;
* де шапка документа;
* де табличні частини;
* де регістри;
* де перелічення;
* де службові поля;
* де реальні бізнес-дані, а де технічний шум платформи.

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

Наприклад, у конфігураторі є довідник “Банки”. А фізично в базі це може бути таблиця з технічною назвою типу <code>SC327</code>, а поля можуть називатися <code>SP330</code>, <code>SP2499</code> тощо.

Для людини це незручно. Для міграції це означає, що потрібно будувати карту відповідностей: логічна сутність, фізична таблиця, фізичне поле, тип даних, модель K2 ERP, поле K2 ERP.

<div style="border-left: 6px solid #c0392b; background: #fdecea; padding: 14px 18px; margin: 18px 0; border-radius: 6px;">
'''Важливо:''' якщо нова система просто працює поверх старої бази 1С/BAS, вона успадковує не тільки дані. Вона успадковує старі таблиці, технічні назви, службові поля, дивні типи даних, хеші, регістри, табличні частини, конфігураційні особливості та партнерські доробки.
</div>

Це не модернізація. '''Це технічне заручництво.'''

== Документи в 1С: не один запис, а ціла конструкція ==

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

Наприклад, у накладній є шапка документа і є рядки з товарами. Один документ — багато рядків. На рівні бази даних це зв’язок “один до багатьох”.

Якщо табличних частин кілька, структура стає ще складнішою.

Для міграції це критично. Не можна просто взяти документ як один запис. Потрібно правильно забрати шапку, правильно забрати табличні частини, відновити зв’язки, зберегти порядок рядків, не переплутати службові поля з бізнес-даними.

А тепер уявімо реальну базу клієнта. Партнер колись додав свої поля. Потім інший партнер змінив документ. Потім третій дописав обробку. Потім бухгалтер сказав: “Не чіпайте, бо працює”. І все це живе 10–15 років.

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

'''Це не архітектура. Це технічний вінегрет.'''

== Перелічення: коли значення є, але в базі його не видно ==

Окрема проблема — перелічення.

У нормальній реляційній базі даних такі речі часто зберігаються в окремих таблицях: тип товару, тип операції, статус документа, вид складу. У 1С частина таких значень може жити не як повноцінна таблиця, а як елемент конфігурації.

Наприклад, користувач бачить види ТМЦ: товар, послуга, тара, продукція, матеріал, паливо. Але коли ми витягуємо дані напряму, можемо отримати лише ідентифікатор, а не людське значення.

І тоді виникає питання: де взяти розшифровку? У таблиці? У конфігурації? У модулі? У XML? У голові програміста, який звільнився 12 років тому?

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

== XML підходить не завжди ==

XML-вивантаження може бути зручним для невеликих баз. У ньому можна отримати структуру і дані в одному форматі. Для невеликих систем це може працювати нормально.

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

Для маленьких баз — нормально. Для великих баз — часто боляче.

Якщо база має 500 гігабайт або терабайт, XML може стати валізою без ручки: '''нести важко, кинути шкода'''.

Для великих проєктів ефективніше працювати напряму з базою даних. Але тут дуже важливий нюанс: напряму — '''як із джерелом даних''', а не як із фундаментом нової ERP.

Прямий доступ потрібен, щоб витягнути дані, працювати порціями, переносити дельту, контролювати завантаження. Але нова ERP не повинна вічно жити на старій структурі 1С.

== Фізичні таблиці: абракадабра як спадщина 90-х ==

У старих DBF-базах були обмеження на імена файлів: вісім символів до крапки і три символи після. У такі обмеження неможливо нормально вмістити “Банківські виписки”, “Контрагенти”, “Номенклатура” або “Місця зберігання”.

Тому 1С історично пішла шляхом технічних ідентифікаторів. Таблиці й поля називалися не так, щоб людині було зрозуміло, а так, щоб воно влізло в старі обмеження.

Потім з’явилися SQL-бази, де таких обмежень уже не було. Але традиція абракадабри залишилася.

Це як людині провели водопровід, а вона все одно ходить до криниці з відрами, бо '''“так історично склалося”'''.

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

'''Не треба вірити. Треба дивитися під капот.'''

== BAS виглядає сучасніше, але тягне той самий багаж ==

У 1С 8 і BAS з’явилися товстий клієнт, тонкий клієнт, SQL-бази, сервер додатків, регістри накопичення, регістри відомостей, регістри бухгалтерії, регістри розрахунку.

Зовні це виглядає сучасніше, ніж 1С 7.7. Але на рівні структури ми знову бачимо технічні назви, складні типи даних, binary-значення, хеші, посилання, регістри, службові таблиці, табличні частини.

Коли потрібно будувати реальні SQL-запити до бази 1С/BAS, наприклад для Power BI або аналітики, починається технічний квест: знайти таблицю, знайти поле, розшифрувати тип, привести binary, знайти хеш перелічення, зробити join-и, перерахувати дату, не переплутати регістр і не забути табличну частину.

'''Це не архітектура для майбутнього. Це escape room для програміста.'''

Такі SQL-запити можуть бути великими, складними, повільними. Особливо на базах у сотні гігабайт або терабайти. Сервери можуть лягати від таких запитів, бо структура не призначена для зручної прямої аналітики.

<div style="border-left: 6px solid #2980b9; background: #eaf4ff; padding: 14px 18px; margin: 18px 0; border-radius: 6px;">
'''Практичний висновок:''' пряме підключення до бази 1С/BAS може бути корисним для разового аналізу або міграції. Але будувати на цьому постійну роботу нової ERP — означає перенести старі проблеми в нову систему.
</div>

== Чому 1С/BAS не можуть просто все відрефакторити ==

Логічне питання: чому ці проблеми не виправили за десятиліття?

Відповідь проста: '''глибоко переробити фундамент уже дуже складно'''.

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

Тому старий багаж не прибирали. Його консервували. Потім зверху додавали нові шари. Потім ще нові. Потім це називали розвитком.

Але значна частина такого “розвитку” — це коли старий технічний борг просто прикривають новими меню, новими назвами і новими презентаціями.

'''BAS у цьому сенсі виглядає як сучасна програма, але всередині несе спадщину системи з 90-х років.'''

== Чому “прозорий перехід” — це пастка ==

І тепер головне.

Чому немає сенсу будувати “прозорий перехід” з 1С або BAS на базі існуючих баз даних і конфігурацій?

<div style="border-left: 6px solid #27ae60; background: #ecf9f0; padding: 14px 18px; margin: 18px 0; border-radius: 6px;">
'''Коротко:''' стару базу потрібно розібрати, витягнути з неї дані й перенести їх у нову модель. Але не можна залишати стару структуру як основу майбутньої ERP.
</div>

'''Перше: структура стара.''' Вона тягне спадщину DBF, DOS, FAT16, старих обмежень, технічних ідентифікаторів і рішень 90-х років.

'''Друге: структура погана як фундамент для сучасної ERP.''' Вона може бути джерелом даних, але не архітектурою майбутньої системи.

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

'''Четверте: структура дороблена партнерами.''' Кожна база може бути окремою історією, окремим зоопарком, окремою археологічною пам’яткою.

'''П’яте: самі 1С/BAS не можуть легко це відрефакторити.''' Їхня екосистема побудована на платформі, конфігураціях і партнерських доробках. Зміниш фундамент — посиплються надбудови.

Тому “прозорий перехід” на старій структурі — це не модернізація. '''Це пастка.'''

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

== Правильний підхід: переносити дані, а не стару цвіль ==

Правильний підхід інший.

Стару базу 1С або BAS потрібно використовувати як джерело даних. Її треба розібрати, зрозуміти, розшифрувати структуру, витягнути довідники, документи, залишки, проводки, регістри, аналітику.

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

Тобто ми забираємо з 1С те, що належить бізнесу: '''дані, історію, документи, аналітику'''.

Але ми не забираємо стару архітектурну цвіль.

Бо бізнесу потрібні його дані, а не музей технічного боргу.

Саме для цього створюється K2 ERP. Не як нова обгортка поверх старої російської технологічної спадщини, а як сучасна українська ERP-платформа з нормальною архітектурою, зрозумілими моделями даних, веб-інтерфейсом, API, інтеграціями, CRM, обліком, виробництвом, складами, документообігом та аналітикою.

'''K2 ERP переносить дані в нову архітектуру, а не старий хаос у новий інтерфейс.'''

== Відео: хакнути структуру 1С ==

У відео нижче показано, як виглядає структура 1С/BAS зсередини: старі DBF-файли, конфігуратор, довідники, документи, перелічення, XML, фізичні таблиці, SQL-запити, регістри, товстий і тонкий клієнт.

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

'''А майбутнє українського бізнесу потрібно будувати вже не на 1С і BAS, а на сучасній, зрозумілій і незалежній ERP-платформі.'''

{{#ev:youtube|FRZJ0AaEJ1c|1280|center|Хакнути структуру 1С: чому “прозорий перехід” з BAS на старих базах — це пастка}}