Оновлення BAS і платформи BAF без зупинки бухгалтерії: практичний план перевірки

Одне слово «оновлення» — чотири різні зміни

Свіжий реліз — це привід поставити запитання, а не команда до встановлення

Карта сумісності: що записати до початку робіт

Безпечний маршрут оновлення

Хто за що відповідає

Рішення go/no-go: простий протокол без зайвої бюрократії

Як вибрати момент перед звітністю

Типові помилки, які створюють простій

Підсумковий чек-лист перед дозволом

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

Надійний підхід не починається з кнопки «Оновити». Він починається з карти компонентів, контрольних прикладів і домовленості про те, хто має право сказати остаточне «так» для робочої бази. Такий порядок потрібен і великій компанії з окремим ІТ-відділом, і невеликому бізнесу, де базу супроводжує зовнішній спеціаліст.

Одне слово «оновлення» — чотири різні зміни

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

Платформа BAF

Платформа Business Automation Framework — це середовище, у якому запускається інформаційна база. Вона відповідає за виконання прикладного коду, роботу клієнта і сервера, доступ до даних, форми, друк, взаємодію з операційною системою та багато інших базових механізмів. Одна й та сама конфігурація BAS може працювати на різних допустимих версіях платформи, але межі сумісності задаються розробником рішення та умовами експлуатації.

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

Конфігурація BAS

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

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

Розширення і зовнішні доопрацювання

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

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

Підключені сервіси

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

Свіжий реліз — це привід поставити запитання, а не команда до встановлення

2 вересня 2026 року в повідомленні ІТС про випуск BAF 8.3.23.2301 зазначено конкретну причину нової версії: виправлення помилки встановлення Business Automation Framework у macOS 15.4.1 та новіших версіях. Це хороший приклад того, як читати новину про реліз. Потрібно дивитися не тільки на більший номер, а й на проблему, яку він усуває.

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

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

Для кожного релізу корисно пройти короткий фільтр:

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

Карта сумісності: що записати до початку робіт

Найгірший момент для з’ясування складу системи — після невдалого оновлення. До тесту варто скласти короткий паспорт середовища. Це не обов’язково складний документ: для невеликої компанії достатньо таблиці, яку розуміють бухгалтер і фахівець із супроводу.

• назва кожної інформаційної бази, її призначення і відповідальна особа;
• поточні версії платформи BAF і конфігурації BAS;
• файловий або клієнт-серверний режим, версія операційної системи та СУБД, якщо вона використовується;
• перелік розширень із версіями, авторами та бізнес-процесами, яких вони стосуються;
• зовнішні обробки, звіти, друковані форми й завдання за розкладом;
• підключені сервіси та обміни: FREDO, банки, ЕДО, сайт, каси, склад, зарплатні проєкти;
• спосіб резервного копіювання, місце зберігання копії та час останнього перевіреного відновлення;
• версія, до якої планується перехід, причина переходу і документовані вимоги сумісності.

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

Безпечний маршрут оновлення

1. Резервна копія, яку справді можна відновити

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

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

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

2. Випробування на актуальній копії бази

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

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

3. Послідовність компонентів за документованими вимогами

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

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

4. Доробки перевіряють за сценаріями, а не за фактом завантаження

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

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

5. Обміни перевіряють в обидва боки

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

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

6. Контрольний розрахунок зарплати

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

У копії повторюють розрахунок за тим самим періодом і порівнюють із зафіксованим результатом до оновлення:

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

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

7. Звіти формують до кінцевого результату

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

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

8. Права, продуктивність і звичайний робочий день

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

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

Хто за що відповідає

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

Що перевіряє бухгалтер

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

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

Що перевіряє фахівець із супроводу

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

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

Хто дозволяє оновлення робочої бази

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

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

Рішення go/no-go: простий протокол без зайвої бюрократії

Перед робочим запуском команда повинна мати одну сторінку результатів. У ній достатньо зазначити:

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

Рішення «go» можливе, коли критичні сценарії пройдені, відмінності пояснені, копія відновлюється, а команда має час і ресурси на завершення або повернення. «No-go» — це не провал роботи. Це нормальний результат перевірки, якщо є невідтворювана копія, несумісне розширення, неперевірений обмін, незрозуміла розбіжність у зарплаті або занадто коротке вікно до звітності.

Як вибрати момент перед звітністю

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

Добре працює календар із трьома зонами:

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

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

Типові помилки, які створюють простій

• Оновлення «про всяк випадок». Команда не може назвати проблему, яку розв’язує версія, зате бере на себе всі ризики зміни.
• Резервна копія без пробного відновлення. Пошкодження, нестача місця або забутий компонент виявляються тоді, коли робоча база вже недоступна.
• Тест на неактуальній копії. У ній немає нового розширення, поточних налаштувань або документів зі складним сценарієм.
• Перевірка лише під адміністратором. Після запуску звичайні користувачі не можуть записувати документи або відкривати потрібні звіти.
• Оцінка лише старту програми. Конфлікт проявляється під час проведення, закриття місяця, розрахунку зарплати чи повернення квитанції.
• Тестова копія під’єднана до робочих сервісів. З’являються дублікати, небажані відправлення або змішані статуси.
• Немає одного власника рішення. Технічний фахівець і бухгалтер перевіряють свою частину, але ніхто не оцінює сумарний ризик і доступний час.

Підсумковий чек-лист перед дозволом

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

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