Як оновити BAS і зберегти власні доопрацювання

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

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

Чому оновлення доопрацьованої конфігурації складніше

У типовій конфігурації зміни постачальника можна встановлювати за стандартною процедурою.

Якщо ж у системі були змінені:

• документи;
• довідники;
• форми;
• модулі;
• звіти;
• обробки;
• регістри;
• друковані форми;
• механізми інтеграції,

потрібно окремо перевірити, чи не змінювалися ці самі об’єкти у новій версії.

Якщо зміни є з обох сторін, виникає конфлікт, який потрібно правильно об’єднати.

З чого почати перед оновленням

Перед будь-якими змінами потрібно зрозуміти поточний стан системи.

Корисно перевірити:

1. поточну версію конфігурації;
2. версію платформи;
3. наявність власних доопрацювань;
4. які об’єкти змінювалися;
5. які зовнішні обробки використовуються;
6. чи є інтеграції з іншими системами;
7. чи є тестова база.

Чим краще відомий поточний стан, тим легше оцінити складність оновлення.

Резервна копія перед оновленням

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

Це базова умова безпечного оновлення.

Резервна копія дозволяє повернути систему до попереднього стану, якщо після змін виникнуть критичні проблеми.

Важливо не просто створити файл резервної копії, а переконатися, що він дійсно придатний для відновлення.

Чому краще спочатку оновити тестову базу

Якщо система використовується щодня, не варто виконувати складне оновлення одразу в робочій базі.

Краще створити копію та перевірити процес на тестовому середовищі.

Це дозволяє:

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

Після успішної перевірки той самий порядок можна застосувати до робочої бази.

Що відбувається з доопрацюваннями

Під час оновлення потрібно визначити, які власні зміни залишити, а які можна замінити новим типовим функціоналом.

Іноді функція, яку раніше доводилося програмувати окремо, вже з’явилася у новій версії BAS.

У такому випадку краще оцінити, чи є сенс підтримувати старе доопрацювання.

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

Конфлікти при оновленні

Конфлікт виникає, коли один і той самий об’єкт змінений і в робочій конфігурації, і в новій версії постачальника.

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

У такій ситуації не можна автоматично залишити тільки одну версію.

Потрібно:

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

Саме цей етап часто займає найбільше часу.

Які доопрацювання потрібно перевіряти особливо уважно

Найбільше уваги потребують зміни, які впливають на основну логіку роботи системи.

Наприклад:

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

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

Перевірка звітів і обробок

Після оновлення потрібно окремо перевірити власні звіти та обробки BAS.

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

Варто перевірити:

• відбори;
• розрахунки;
• джерела даних;
• друковані форми;
• завантаження;
• вивантаження;
• масові операції.

Особливо якщо в новій версії змінилася структура даних.

Інтеграції після оновлення

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

Потрібно переконатися, що:

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

Навіть якщо сама інтеграція не змінювалася, оновлення може вплинути на об’єкти BAS, з якими вона працює.

Що потрібно тестувати після оновлення

Перевірка повинна охоплювати не тільки запуск програми.

Варто пройти основні робочі сценарії.

Наприклад:

• створення документів;
• запис;
• проведення;
• друк;
• формування звітів;
• обмін даними;
• роботу користувачів;
• права доступу;
• фонові або регламентні операції.

Краще перевіряти ті сценарії, які реально використовуються у компанії щодня.

Оновлення та власні зміни у формах

Доопрацювання форм часто здаються простими, але також можуть конфліктувати з новою версією.

Наприклад:

• додаткова кнопка;
• нове поле;
• власна команда;
• автоматичне заповнення;
• перевірка перед записом.

Якщо типова форма була суттєво змінена, потрібно перенести власну логіку в актуальну версію.

Чи можна зменшити складність майбутніх оновлень

Так.

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

Наприклад, у деяких задачах можна використовувати:

• розширення;
• зовнішні звіти;
• зовнішні обробки;
• додаткові механізми без зміни великої кількості типових об’єктів.

Конкретний підхід залежить від конфігурації та задачі.

Чим менше зайвих змін у типовій логіці, тим простіше підтримувати систему.

Коли не варто поспішати з оновленням

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

Перед початком потрібно врахувати:

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

Це особливо важливо для систем, де BAS використовується великою кількістю співробітників.

Як підготувати задачу на оновлення

Для первинної оцінки корисно надати:

1. назву конфігурації;
2. поточну версію;
3. бажану версію оновлення;
4. інформацію про доопрацювання;
5. список критичних робочих процесів;
6. інформацію про інтеграції;
7. приблизний розмір бази;
8. формат роботи — файлова або серверна база.

Якщо є опис виконаних раніше змін, він значно спрощує аналіз.

Що робити після успішного оновлення

Після перевірки бажано зафіксувати:

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

Це допоможе при наступному оновленні.

Основний принцип безпечного оновлення

Оновлення BAS краще розглядати не як одну технічну операцію, а як контрольований процес.

Надійний порядок виглядає так:

1. аналіз;
2. резервна копія;
3. тестова база;
4. оновлення;
5. перенесення доопрацювань;
6. тестування;
7. оновлення робочої бази;
8. контроль після запуску.

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

Детальніше про порядок робіт можна переглянути на сторінці оновлення BAS.