Що не так з базовим алгоритмом конфігурації BAS ERP

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

Але що, якщо цей фундамент не такий міцний, як здається?

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

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

BAS як «універсальний конструктор»

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

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

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

Незмінність базового алгоритму

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

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

Межі кастомізації

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

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

Архітектурна особливість ERP-конфігурацій BAS

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

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

Облік за плановими цінами

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

• Дебет «Собівартість продажів (управлінський)»
• Кредит «Товари на складі (управлінський)»

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

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

Компроміс замість рішення

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

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

Яким має бути сучасне ядро ERP?

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

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

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

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

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