BAF 8.3.23.2301: чи потрібно оновлювати платформу саме вашій фірмі

Що відомо про 8.3.23.2301 станом на 11 вересня 2026 року

Платформа і конфігурація — не одне оновлення

Вправа: складіть паспорт кожної інформаційної бази

П'ять запитань, які визначають реальну потребу

Коли 8.3.23.2301 варто встановлювати, а коли можна зачекати

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

Контрольні сценарії для бухгалтера

Типові помилки, що коштують часу

Коротка картка рішення для керівника

Висновок: оновлюйте не номер, а керований контур

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

Що відомо про 8.3.23.2301 станом на 11 вересня 2026 року

В ІТС BAS 2 вересня 2026 року оприлюднено BAF 8.3.23.2301. В офіційному повідомленні причиною випуску названо виправлення помилки встановлення BAF у macOS 15.4.1 і новіших версіях. Станом на 11 вересня у стрічці релізів ІТС не було повідомлення про новіший випуск платформи.

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

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

Платформа і конфігурація — не одне оновлення

BAF — технологічна платформа. Вона запускає інформаційну базу, виконує вбудовану мову, забезпечує роботу форм, запитів, файлів, клієнтських і серверних процесів. Її версія має вигляд на кшталт 8.3.23.2301.

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

Звідси випливають два правила:

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

Наприклад, бухгалтер очікує нову форму звітності. Якщо вона реалізована в релізі прикладного рішення, встановлення лише BAF 8.3.23.2301 її не додасть. І навпаки: якщо проблема виникає під час інсталяції платформи на новій macOS, оновлення самої конфігурації не виправить інсталятор BAF.

Що показує режим сумісності

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

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

Вправа: складіть паспорт кожної інформаційної бази

Відведіть на інвентаризацію 20–30 хвилин і не починайте інсталяцію, доки таблиця не заповнена. Для кожної робочої та тестової бази зафіксуйте:

1. Версію BAF. Запишіть повний номер із вікна відомостей про програму. Для клієнт-серверної бази окремо уточніть версію серверного кластера.
2. Назву й версію конфігурації. Не обмежуйтеся словом «BAS»: потрібні точна назва рішення, редакція та реліз.
3. Режим сумісності. Перевірте властивість основної конфігурації у конфігураторі. Не вгадуйте її за номером платформи.
4. Підтримку та зміни. Позначте, чи є конфігурація типовою, чи знята з повної підтримки, які об'єкти змінені та хто супроводжує доробки.
5. Розширення. Складіть перелік активних розширень, їхніх версій, призначення та відповідальних. Окремо позначте ті, що змінюють проведення, права, друк або обмін.
6. Клієнти. Запишіть, хто працює через тонкий, товстий або вебклієнт, які версії BAF установлені на робочих місцях, які операційні системи використовуються та чи є доступ через термінальний сервер.
7. Інтеграції. Додайте зовнішню звітність, банк, електронний документообіг, торгове обладнання, фонові завдання, обміни між базами та підключені сервіси.

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

П'ять запитань, які визначають реальну потребу

1. Яку проблему має розв'язати нова платформа?

Сформулюйте очікуваний результат одним реченням: «потрібно встановити BAF на Mac з macOS 15.4.1», «новий реліз нашої конфігурації вимагає цієї платформи» або «постачальник підтвердив виправлення відтворюваної помилки». Формулювання «щоб була найновіша» не дає критерію успіху й не виправдовує ризик простою.

2. Чи є офіційна вимога саме для вашої конфігурації?

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

3. Чи однакові сервер і клієнтські робочі місця?

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

4. Чи є нетипові доробки або розширення?

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

5. Чи підготовлені тест і повернення назад?

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

Коли 8.3.23.2301 варто встановлювати, а коли можна зачекати

Оновлювати найближчим контрольованим вікном доцільно, якщо:

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

Не поспішати лише заради номера розумно, якщо:

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

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

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

1. Зафіксуйте початковий стан. Збережіть паспорт бази, список активних користувачів, версії компонентів і параметри підключення.
2. Прочитайте інформацію про релізи. Окремо — для BAF, конфігурації, розширень і зовнішніх компонентів. Не змішуйте чотири різні джерела змін в одну фразу «оновили BAS».
3. Створіть перевірену резервну копію. Для клієнт-серверного варіанта дотримуйтеся прийнятої у фірмі процедури резервування СУБД та пов'язаних файлів. Переконайтеся, що копію можна відновити.
4. Повторіть базу в тестовому контурі. Тест має бути достатньо схожим на робоче середовище: та сама конфігурація, режим сумісності, розширення, права, важливі інтеграції та типи клієнтів.
5. Оновіть тільки запланований шар. Якщо перевіряєте BAF, не змінюйте одночасно конфігурацію, режим сумісності й розширення. Інакше причину збою буде важко визначити.
6. Виконайте контрольні операції. Відкрийте довідники, створіть копії типових документів, проведіть їх, сформуйте ключові звіти, перевірте друк, права, обміни та регламентні завдання.
7. Порівняйте результат. Важливі не лише відсутність повідомлень про помилки, а й однакові підсумки, проводки, залишки, друковані форми та час виконання звичних операцій.
8. Проведіть пілот. За можливості дайте нове середовище одному досвідченому користувачеві до масового переходу.
9. Оновіть робочий контур у погоджене вікно. Повідомте користувачів, закрийте сеанси, зробіть фінальну копію, виконайте роботи та повторіть скорочений контрольний сценарій.
10. Задокументуйте завершення. Запишіть нові версії, час, результат тестів і відомі зауваження. Це стане початковим станом для наступного рішення.

Контрольні сценарії для бухгалтера

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

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

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

Типові помилки, що коштують часу

• Плутати номер BAF з номером BAS. Через це шукають нову форму звіту в оновленні технологічної платформи або намагаються виправити інсталятор релізом конфігурації.
• Оновлювати все одним заходом. Одночасна зміна платформи, конфігурації, режиму сумісності й розширень позбавляє команду можливості швидко знайти причину відхилення.
• Перевіряти лише запуск. База відкрилася, але помилка може проявитися під час проведення, обміну, друку чи нічного завдання.
• Забути про клієнтів. Сервер оновили, а ноутбук керівника, термінальна ферма або віддалений бухгалтер залишилися поза планом.
• Вважати резервну копію гарантованим поверненням. Неперевірена копія, невідомий час відновлення й відсутність відповідального перетворюють план на надію.
• Проводити роботи перед звітним строком. Навіть корисне оновлення краще перенести у вікно, коли команда має час перевірити результат і, за потреби, відкотитися.

Коротка картка рішення для керівника

Перед погодженням робіт керівникові достатньо отримати від відповідального п'ять чітких відповідей:

1. Яка точна версія BAF і конфігурації працює зараз?
2. Яку конкретну проблему або вимогу закриває 8.3.23.2301?
3. Які бази, клієнти, розширення та інтеграції потрапляють під зміну?
4. Які операції вже перевірено на копії та хто підтвердив результат?
5. Скільки триватиме простій і як команда повернеться до попереднього стану?

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

Висновок: оновлюйте не номер, а керований контур

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

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