BAS ERP 2.5 чи лінійка 2.1: як бухгалтеру прочитати номер релізу і не оновити «не ту» систему

Що показує ІТС станом на 11 вересня 2026 року

Чотири поняття, які не варто змішувати

Як розібрати 2.5.20.1 без хибних висновків

Де бухгалтеру подивитися свою версію

Безпечний порядок перевірки оновлення

Що має перевірити саме бухгалтер

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

Коли проблема не в оновленні, а в знанні конфігурації

Короткий чекліст перед погодженням робіт

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

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

Що показує ІТС станом на 11 вересня 2026 року

Актуальна стрічка ІТС BAS добре демонструє, чому одного номера недостатньо. У ній оприлюднено, зокрема, такі повідомлення:

• 9 вересня — версія 2.5.20.1 для рішення з планування ресурсів підприємства, редакції 2.5, тобто лінійки BAS ERP 2.5;
• 8 вересня — версія 2.1.43.1 для рішення з планування ресурсів підприємства лінійки 2.1;
• 10 вересня — версія 2.1.43.1 для рішення з комплексного управління підприємством;
• 11 вересня — та сама версія 2.1.43.1 для варіанта комплексного управління підприємством із FlyDoc;
• 11 вересня — версія 2.5.20.1 для рішення з комплексного управління підприємством, редакції 2.5.

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

Чотири поняття, які не варто змішувати

Продукт — це конкретне прикладне рішення

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

Редакція — це функціональна гілка продукту

У наведених прикладах перші дві частини номера вказують на гілку редакції: 2.5 у 2.5.20.1 і 2.1 у 2.1.43.1. Перехід між редакціями — не те саме, що встановлення чергового релізу всередині однієї гілки. Він може мати окремі вимоги до проміжної версії, структури даних, розширень, обмінів і перевірок після конвертації.

Реліз — це повний номер конкретної версії конфігурації

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

Платформа — окремий технічний шар

У вікні з інформацією про систему можна побачити ще один номер формату 8.3.x.x. Це версія платформи BAF, на якій працює конфігурація. Вона має власні оновлення й вимоги. Номер платформи не замінює номер конфігурації: база може працювати на придатній платформі, але мати старий реліз прикладного рішення, або навпаки.

Як розібрати 2.5.20.1 без хибних висновків

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

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

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

Де бухгалтеру подивитися свою версію

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

У робочій нотатці мають бути окремі рядки:

• назва конфігурації: як показано програмою, разом із галузевим уточненням або додатковим модулем;
• версія конфігурації: усі чотири частини номера;
• версія платформи: окремий номер 8.3.x.x;
• тип бази: файлова чи клієнт-серверна;
• стан конфігурації: типова, змінена, з розширеннями;
• обміни та сервіси: банк, звітність, електронний документообіг, сайт, складські або галузеві модулі.

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

Безпечний порядок перевірки оновлення

1. Ідентифікуйте базу, яку фактично відкрито

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

2. Зіставте не номер, а повний запис на ІТС

Шукайте точну назву продукту й лише всередині неї — свою редакцію та новіший реліз. Дата новини допомагає зрозуміти актуальність публікації, але не замінює перевірку сумісності. Якщо у заголовку є уточнення на кшталт «редакція 2.5», «+ FlyDoc» або назва галузі, воно є частиною ідентифікатора, а не декоративним підписом.

3. Прочитайте маршрут переходу

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

4. Оцініть доопрацювання та інтеграції

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

5. Підготуйте відновлення до початку робіт

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

6. Спочатку оновіть копію

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

Що має перевірити саме бухгалтер

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

Складіть короткий контрольний набір на основі останнього закритого або майже закритого періоду:

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

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

• Шукати лише останні дві частини. «20.1» і «43.1» не мають практичного сенсу без редакції та продукту.
• Плутати платформу з конфігурацією. Номер 8.3.x.x не відповідає на запитання, який реліз BAS ERP встановлено.
• Вважати однакові номери однаковими пакетами. ІТС показує 2.1.43.1 біля кількох рішень, але назви продуктів різні.
• Пропускати уточнення після назви. Редакція 2.5, «+ FlyDoc» або галузеве призначення впливають на вибір.
• Оновлювати одразу робочу базу. Без перевіреної копії та тестового сценарію економія часу може обернутися простоєм.
• Орієнтуватися на чужу базу. Навіть компанії однієї галузі можуть мати різні редакції, розширення й інтеграції.

Коли проблема не в оновленні, а в знанні конфігурації

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

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

Короткий чекліст перед погодженням робіт

1. З робочої бази скопійовано повну назву конфігурації.
2. Окремо записано версію конфігурації та версію платформи.
3. На ІТС знайдено запис саме для цього продукту й редакції.
4. Перевірено допустимий маршрут від поточного до цільового релізу.
5. Враховано розширення, доопрацювання, обміни та зовнішні сервіси.
6. Створено й перевірено резервну копію.
7. Оновлення пройдено на копії, а критичні облікові сценарії звірено.
8. Узгоджено час простою, відповідальних і спосіб повернення назад.

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