Коли бізнес говорить про перехід з 1С або BAS на сучасну ERP-систему, часто виникає спокуслива ідея: “А давайте нічого не переносити. Просто підключимо нову систему до старої бази 1С/BAS і будемо працювати далі”.
На перший погляд це виглядає красиво: швидко, дешево, безболісно. Нібито не потрібно переносити довідники, документи, залишки, проводки, регістри, історію операцій. Нібито достатньо зробити новий інтерфейс, під’єднатися до старої бази — і компанія вже працює в “новій системі”.
Але на практиці це приблизно як поставити екран від Tesla в старий “Запорожець” і сказати: тепер у нас електрокар.
Не буде електрокара.
Бо проблема 1С та BAS не тільки в інтерфейсі. Проблема значно глибше — у самій структурі бази даних, типах даних, старих архітектурних рішеннях, конфігураціях, партнерських доробках і технологічному багажі, який тягнеться ще з 90-х років.
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С ми бачимо логічну структуру: довідники, документи, журнали документів, перелічення, звіти, обробки, плани рахунків, регістри. Але те, що видно в конфігураторі, і те, як це фізично лежить у базі даних, — це різні речі.
Наприклад, у конфігураторі є довідник “Банки”. А фізично в базі це може бути таблиця з технічною назвою типу SC327, а поля можуть називатися SP330, SP2499 тощо.
Для людини це незручно. Для міграції це означає, що потрібно будувати карту відповідностей: логічна сутність, фізична таблиця, фізичне поле, тип даних, модель K2 ERP, поле K2 ERP.
І саме тут стає зрозуміло, чому “прозорий перехід” на старій базі — це пастка.
Якщо нова система просто працює поверх старої бази 1С/BAS, вона успадковує не тільки дані. Вона успадковує старі таблиці, технічні назви, службові поля, дивні типи даних, хеші, перерахунки дат, регістри, табличні частини, конфігураційні особливості та партнерські доробки.
Це не модернізація. Це технічне заручництво.
Документи в 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-запити можуть бути великими, складними, повільними. Особливо на базах у сотні гігабайт або терабайти. Сервери можуть лягати від таких запитів, бо структура не призначена для зручної прямої аналітики.
Чому 1С/BAS не можуть просто все відрефакторити
Логічне питання: чому ці проблеми не виправили за десятиліття?
Відповідь проста: глибоко переробити фундамент уже дуже складно.
1С історично розробляла платформу й інструмент, а прикладні конфігурації масово робили партнери. Кожна конфігурація могла бути змінена під конкретного клієнта. Якщо зараз радикально змінити структуру таблиць, типи даних, принципи зберігання й відповідності, може посипатися величезна кількість конфігурацій, доробок, інтеграцій і партнерських рішень.
Тому старий багаж не прибирали. Його консервували. Потім зверху додавали нові шари. Потім ще нові. Потім це називали розвитком.
Але значна частина такого “розвитку” — це коли старий технічний борг просто прикривають новими меню, новими назвами і новими презентаціями.
BAS у цьому сенсі виглядає як сучасна програма, але всередині несе спадщину системи з 90-х років.
Чому “прозорий перехід” — це пастка
І тепер головне.
Чому немає сенсу будувати “прозорий перехід” з 1С або BAS на базі існуючих баз даних і конфігурацій?
Перше: структура стара. Вона тягне спадщину 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-платформі.