Будь-яка система має межі своєї універсальності. Вона зручна, поки ми працюємо з базовими елементами. Але якщо почати змінювати фундаментальні компоненти, універсальність зникає, а система стає нестабільною і непередбачуваною. Те саме стосується облікових програм, які позиціонуються як «гнучкі» та «кастомізовані». Можливості таких рішень справді широкі, але ядро системи завжди залишається особливою частиною — фундаментом, на якому побудована вся логіка роботи. Втручання в ядро може призвести до збоїв у роботі, падіння продуктивності, проблем із безпекою та втрати сумісності з іншими сервісами й оновленнями.
BAS як «універсальний конструктор»
Платформа BAS позиціонує себе як універсальний конструктор, здатний реалізувати будь-які ідеї. Дійсно, на рівні «чистої бази» можна створити практично будь-яке рішення, обмежене лише можливостями базових інструментів платформи — системою збереження даних, обробкою об’єктів, управлінням прав доступу та формуванням інтерфейсу. Однак цей рівень «абсолютної свободи» накладає на розробника надзвичайно складне завдання — фактично створення системи обліку з нуля. Це трудомісткий і малопродуктивний шлях, яким практично ніхто не користується. Тому переважна більшість обирає готові конфігурації, де вже закладені базові алгоритми, і адаптує їх під потреби клієнта. Для абсолютної більшості розробників межі універсальності BAS фактично визначаються рамками цих конфігурацій. Хоча код системи формально дозволяє глибокі зміни, на практиці це настільки складно — особливо у нових модифікаціях «клонів» 1С — що його можна вважати майже недосяжним.
Незмінність базового алгоритму
Основний алгоритм, закладений у типові конфігурації BAS, залишається стабільним для більшості рішень. Лише одиниці, найкваліфікованіші спеціалісти, створюють оригінальні конфігурації або серйозно змінюють існуючі. Тому твердження, що «на базі BAS можна зробити будь-що», нагадує ідею, що з коробок сірників можна збудувати будинок на березі моря: теоретично можливо, але практично майже ніхто так не робить. Відтак розглянемо ті конфігурації, що реально застосовуються, і алгоритми яких залишаються стабільними.
Межі кастомізації
За винятком невеликої кількості авторських проєктів, універсальний конструктор BAS завжди обмежений рамками обраної конфігурації. Кастомізація можлива лише в межах базових алгоритмів ядра системи. Усі підсистеми конфігурації — від бухгалтерії до складського обліку — спираються на ці алгоритми. Будь-яке втручання в ядро зачіпає тисячі форм, регістрів і модулів. Фундаментальні зміни, наприклад створення альтернативної схеми подвійного запису, практично неможливі: це потребує переписування логіки не лише на рівні конфігурації, а й компонентів системи, фактично створюючи новий продукт.
Архітектурна особливість ERP-конфігурацій BAS
У ERP-конфігураціях BAS рухи по регістрах кількісно-вартісного обліку формуються під час проведення первинних документів. Це забезпечує точність і відтворюваність даних для аналізу будь-якого періоду, що є критично важливим для бухгалтерського обліку. Проте такий підхід не підходить для управлінського обліку в режимі реального часу. Бізнес-процеси часто вимагають відображення операцій ще до появи первинних документів з фактичною вартістю, і система в стандартному вигляді цього не забезпечує.
Облік за плановими цінами
Щоб обійти цю проблему, система застосовує механізм планової собівартості. У випадку, коли первинні документи ще не створені, BAS формує тимчасові проводки, які відображають планову оцінку собівартості: • Дебет «Собівартість продажів (управлінський)» • Кредит «Товари на складі (управлінський)» Після появи фактичних документів система автоматично коригує управлінські записи: різниця між плановими та фактичними цінами відображається додатковими рухами. Таким чином, ордери та тимчасові записи дозволяють бізнесу працювати «ніби в реальному часі». Насправді це лише проміжний шар, що імітує актуальні дані — базовий механізм зв’язку первинних документів і рухів залишається незмінним і потребує подальшого перерахунку.
Компроміс замість рішення
Облік за плановими цінами — це не рішення, а компроміс. Він дозволяє зберегти незмінність базового алгоритму ERP-конфігурацій BAS, але робить облік складнішим і заплутанішим. Бізнес отримує ілюзію гнучкості, там де насправді потрібні радикально інші підходи. У результаті компанії витрачають додатковий час та ресурси на підтримку цих механізмів, а нашарування допоміжних розрахунків робить систему громіздкою та неповороткою навіть у відносно простих складських сценаріях. При цьому такі заходи все одно не гарантують збереження коректної вартості залишків.
Яким має бути сучасне ядро ERP?
На перший погляд, рішення здається простим: розірвати жорсткий зв’язок між первинними документами та рухами в регістрах, дозволивши рознесення проводок у часі. Проте на практиці це призводить до втрати цілісності даних. Ордерна схема на кшталт тієї, що застосовувалася в 1С:УПП, часто ставала причиною втрати вартості залишків на складі та перетворювала пошук партій у бухгалтерії на квест. Результат — рутинна, малоефективна робота, що споживає ресурси, але не додає цінності ані обліку, ані управлінню. Проблема в тому, що створення проводок у реальному часі — єдиний спосіб зберегти цілісність даних у межах базового алгоритму 1С/BAS. Саме тому система змушена використовувати управлінські проводки, щоб утримати коректність даних без радикальних змін архітектури. Справжньою альтернативою є лише фундаментальне переосмислення алгоритму на рівні ядра ERP. Йдеться про новий механізм забезпечення цілісності даних, коли рухи та проводки не виникають одночасно, — інший принцип збереження інформації, прив’язки до документів і формування проводок. Це вимагає створення принципово нового продукту з іншою логікою роботи, здатного забезпечити управління даними в реальному часі. Побудувати його на основі традиційних алгоритмів бухгалтерського обліку неможливо: їхня архітектура несумісна з повноцінним плануванням ресурсів підприємства. Управлінці впевнені, що практичність та універсальність — ключові чесноти 1С/BAS, і заради цього готові навіть чинити всупереч законодавству. Насправді ж ці «переваги» виявляються міражем: здається, що система універсальна і стабільна, а на практиці будь-яка спроба масштабувати або змінити процеси показує крихкість фундаменту.