Реліз BAS

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

У практиці BAS слово “реліз” може означати різні речі:

реліз платформи BAF;
реліз прикладної конфігурації BAS;
реліз регламентованої звітності;
реліз зовнішньої обробки;
реліз розширення;
реліз інтеграційного модуля;
реліз галузевого рішення;
реліз оновлення для сервісів або звітності.

ІТС BAS окремо публікує інформацію про вихід нових релізів платформи, конфігурацій, форм регламентованої звітності, зовнішніх звітів та інших оновлень. :contentReference[oaicite:0]{index=0}

Головне. Реліз BAS — це не просто “нова версія”. Це зміна програмного середовища, яка може вплинути на документи, звіти, обробки, права, інтеграції, регламентні завдання, ПДВ, зарплату, банк, обмін із сайтом, Power BI і роботу користувачів.

Проста аналогія. Реліз BAS — це як нова редакція правил і механізмів у системі. Якщо оновити її без перевірки, можна отримати не тільки нові можливості, а й зламані звіти, обробки або інтеграції.

Важливо про 1С, BAS і BAF. В Україні продукти екосистеми 1С і частина продуктів BAS пов’язані з санкційними, юридичними, кібербезпековими та репутаційними ризиками. Держспецзв’язку веде офіційний перелік забороненого до використання програмного забезпечення та комунікаційного обладнання, де згадуються продукти 1С/BAS, зокрема 1C:Підприємство 8, BAS ERP та інші продукти BAS. Указ Президента України №601/2024 ввів у дію рішення РНБО від 2 вересня 2024 року щодо застосування, скасування та внесення змін до санкцій. Перед використанням, підтримкою або міграцією таких систем потрібно перевіряти актуальні офіційні обмеження. :contentReference[oaicite:1]{index=1}

Що таке реліз BAS

Реліз BAS — це опублікована версія програмного компонента BAS/BAF.

Реліз може містити:

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

Приклад:

BAS Бухгалтерія, реліз 2.1.XX.XX
BAS ERP, реліз 2.5.XX.XX
BAF платформа, реліз 8.3.XX.XXXX
Регламентована звітність, реліз за певний період

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

У BAS потрібно розрізняти реліз платформи і реліз конфігурації.

Тип релізу	Що оновлюється	Приклад
Реліз платформи	Технологічне середовище BAF	Клієнт, сервер, механізми виконання, СУБД-зв’язок
Реліз конфігурації	Прикладне рішення BAS	BAS Бухгалтерія, BAS ERP, BAS ЗУП
Реліз звітності	Регламентовані форми	Декларації, звіти, форми подання
Реліз обробки	Окремий службовий файл	Імпорт, експорт, банк, обмін
Реліз розширення	Додаткова функціональність	Доробка клієнта, інтеграція, друкована форма

Реліз платформи BAF

Реліз платформи змінює технологічний рівень, на якому працює BAS.

Він може впливати на:

тонкий клієнт;
товстий клієнт;
web-клієнт;
сервер BAS/BAF;
конфігуратор;
роботу запитів;
продуктивність;
сумісність із СУБД;
роботу розширень;
роботу зовнішніх компонентів;
web-публікацію;
безпеку;
інтеграції;
регламентні завдання.

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

Реліз конфігурації BAS

Реліз конфігурації змінює прикладну бізнес-логіку.

Він може впливати на:

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

Наприклад, реліз BAS Бухгалтерія може змінити податкові механізми, а реліз BAS ERP — вплинути на виробництво, склад, продажі, закупівлі або управлінський облік.

Реліз регламентованої звітності

Реліз регламентованої звітності потрібен для оновлення форм звітів і правил їх заповнення.

Він може включати:

нові форми;
змінені форми;
виправлені формули;
нові контрольні співвідношення;
зміни в електронному форматі;
зміни в реквізитах;
зміни в друкованому вигляді;
виправлення помилок експорту;
підтримку нових періодів.

Такі релізи критичні для бухгалтерії, ПДВ, зарплати, податкової звітності та регламентованих подань.

Реліз зовнішньої обробки

Зовнішня обробка може мати власні версії.

Приклади:

обробка завантаження банку;
обробка імпорту замовлень;
обробка вивантаження залишків;
обробка міграції;
обробка масової зміни цін;
обробка обміну з сайтом;
обробка JSON;
обробка XML;
обробка для Power BI;
службова обробка адміністратора.

Зовнішні обробки потрібно оновлювати обережно, бо вони можуть масово змінювати дані.

Реліз розширення

Розширення може змінювати або доповнювати поведінку конфігурації.

Реліз розширення може містити:

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

Ризик — після оновлення конфігурації старе розширення може перестати працювати або почати конфліктувати з новим релізом BAS.

Номер релізу

Номер релізу допомагає зрозуміти, яка версія встановлена.

Приклад формату:

2.1.32.5
2.5.18.120
8.3.24.XXXX

Зазвичай номер може відображати:

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

У документації до BAS-релізів можуть використовуватися скорочення на кшталт “рел.” або “реліз”. На сторінках ІТС BAS публікуються новини про випуск релізів типових конфігурацій і сервісів. :contentReference[oaicite:2]{index=2}

Changelog релізу

Changelog або опис змін — це перелік того, що змінилося в релізі.

У ньому потрібно шукати:

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

Не можна оновлювати робочу базу, не прочитавши опис релізу.

Для чого потрібні релізи BAS

Релізи потрібні для:

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

Чому релізи BAS небезпечні без тестування

Оновлення може вплинути на:

проведення документів;
закриття місяця;
ПДВ;
зарплату;
банк;
склад;
партії;
собівартість;
виробництво;
регламентовану звітність;
зовнішні обробки;
розширення;
інтеграції;
Power BI;
права доступу;
web-клієнт;
друковані форми.

Тому реліз — це не просто “натиснути оновити”.

Правильний порядок оновлення релізу BAS

Безпечний процес:

Прочитати опис релізу.
Перевірити сумісність платформи.
Зробити backup робочої бази.
Створити тестову копію.
Встановити реліз у тестову базу.
Перевірити типові сценарії.
Перевірити доробки.
Перевірити розширення.
Перевірити зовнішні обробки.
Перевірити інтеграції.
Перевірити звітність.
Перевірити права доступу.
Погодити час оновлення.
Оновити робочу базу.
Виконати контрольну перевірку.
Зафіксувати версію і результат.

Правило. Спочатку тестова база, потім робоча. Реліз BAS не можна встановлювати одразу в робочу базу без backup і перевірки.

Backup перед релізом

Backup перед оновленням обов’язковий.

Потрібно зберегти:

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

Backup має бути перевірений на відновлення.

Погано:

Backup начебто є, але його ніхто ніколи не відновлював.

Краще:

Backup створено → відновлення перевірено → тільки після цього оновлення.

Тестова база для релізу

Тестова база потрібна для перевірки релізу без ризику пошкодити робочі дані.

У тестовій базі перевіряють:

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

Після створення тестової копії потрібно вимкнути реальні інтеграції, щоб вона не обмінювалася з банком, сайтом або EDI як робоча база.

Регресійне тестування після релізу

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

Приклади перевірок:

Блок	Що перевірити
Продажі	Замовлення, рахунок, реалізація, друк, резерв
Закупівлі	Замовлення постачальнику, надходження, повернення
Склад	Переміщення, списання, інвентаризація, залишки
Фінанси	Платежі, банк, ДДС, взаєморозрахунки
Бухгалтерія	Проводки, ОСВ, ПДВ, закриття місяця
Зарплата	Нарахування, утримання, відомості, звіти
Виробництво	Специфікації, списання, випуск, собівартість
Інтеграції	Сайт, банк, WMS, Power BI, API

Контрольні звіти перед і після релізу

Перед оновленням і після нього потрібно порівняти контрольні звіти.

Приклади:

ОСВ;
залишки товарів;
взаєморозрахунки;
залишки грошей;
ПДВ;
зарплатні нарахування;
собівартість;
партії;
виробництво;
ДДС;
управлінський P&L;
активні замовлення;
звіти Power BI;
інтеграційні журнали.

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

Реліз і дороблена конфігурація

Якщо конфігурація дороблена, оновлення складніше.

Проблеми можуть виникнути через:

змінені типові об’єкти;
старий код;
змінені форми;
змінені ролі;
змінені регістри;
дороблені документи;
нестандартні друковані форми;
зовнішні обробки;
обмін із сайтом;
COM-інтеграції;
старі розширення;
неописані зміни.

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

Реліз і розширення

Розширення після релізу потрібно перевіряти окремо.

Можливі проблеми:

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

Потрібен тест кожного критичного розширення.

Реліз і зовнішні обробки

Зовнішні обробки можуть зламатися після оновлення, якщо:

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

Потрібно перевірити:

імпорт;
експорт;
банк;
сайт;
WMS;
CRM;
Power BI;
XML;
JSON;
COM;
HTTP-сервіси.

Реліз і інтеграції

Оновлення може зламати інтеграції.

Типові інтеграції:

банк;
сайт;
CRM;
WMS;
MES;
Power BI;
EDI;
електронний документообіг;
GPS;
паливні картки;
маркетплейси;
зовнішні API;
інші BAS/1С-бази.

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

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

Реліз і банк

Банківські інтеграції треба перевіряти обов’язково.

Після оновлення потрібно перевірити:

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

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

Реліз і ПДВ

ПДВ часто залежить від актуальності релізів.

Потрібно перевірити:

податкові накладні;
розрахунки коригування;
реєстри ПДВ;
декларації;
додатки;
електронні формати;
контрольні співвідношення;
друковані форми;
експорт;
ручні коригування;
права бухгалтерів.

Реліз і зарплата

Для зарплати реліз може бути критичним.

Потрібно перевірити:

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

Реліз і закриття місяця

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

Особливо:

собівартість;
амортизацію;
курсові різниці;
ПДВ;
витрати;
доходи;
виробництво;
партії;
зарплатні витрати;
управлінський облік;
бухгалтерські проводки.

Погано встановити реліз у день закриття місяця без тестування.

Реліз і права доступу

Оновлення може змінити:

ролі;
профілі;
доступ до нових об’єктів;
права на звіти;
права на документи;
права на обробки;
права на регістри;
поведінку RLS;
доступ до нових розділів.

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

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

Реліз і продуктивність

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

Потрібно перевірити:

запуск бази;
відкриття документів;
проведення;
важкі звіти;
закриття місяця;
обмін із сайтом;
банк;
Power BI-вивантаження;
регламентні завдання;
роботу користувачів у піковий час.

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

Реліз і web-клієнт

Якщо використовується web-клієнт, після оновлення потрібно перевірити:

web-публікацію;
HTTPS;
авторизацію;
відкриття основних форм;
друк;
файли;
звіти;
права;
браузери;
reverse proxy;
помилки web-сервера.

Реліз і тонкий клієнт

Після оновлення платформи потрібно перевірити тонкий клієнт.

Типові проблеми:

стара версія клієнта;
неправильний ярлик;
кеш;
несумісність із сервером;
помилки друку;
проблеми запуску;
різні версії на RDP і локальних ПК.

Потрібно оновити робочі місця або централізований RDP-сервер.

Реліз і архівні бази

Архівні бази не завжди потрібно оновлювати.

Якщо BAS-база залишена тільки для читання після переходу в K2 ERP, потрібно вирішити:

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

Архів не має перетворюватися на другу робочу систему.

Типові помилки при встановленні релізу BAS

Помилка	Причина	Наслідок
Оновили робочу базу без backup	Поспіх	Немає шляху відкату
Не перевірили тестову базу	Хотіли швидше	Зламались документи або звіти
Не прочитали опис релізу	Формальний підхід	Пропущені важливі зміни
Не перевірили розширення	Забули про доробки	Помилки в формах і документах
Не перевірили інтеграції	Думали, що не зачепить	Не працює банк, сайт або WMS
Оновили в день закриття місяця	Невдале планування	Ризик зупинки бухгалтерії
Не перевірили права	Забули про ролі	Користувачі бачать зайве або не бачать потрібне

Помилка: реліз поставили без backup

Це найнебезпечніша помилка.

Якщо оновлення зламало базу, а backup немає, компанія може втратити:

робочий час;
документи;
коректність обліку;
можливість швидкого відновлення;
довіру користувачів.

Правильно:

Backup → Тестова база → Оновлення тесту → Перевірка → Оновлення робочої бази

Помилка: не перевірили інтеграції

Після релізу може перестати працювати:

завантаження банку;
обмін із сайтом;
вивантаження залишків;
Power BI;
WMS;
CRM;
EDI;
електронні документи;
XML-обмін;
JSON-обмін;
HTTP-сервіс;
COM-з’єднання.

Тому інтеграції потрібно включити в тест-план.

Помилка: оновили не ту базу

Це трапляється, коли бази названі нечітко.

Погано:

BAS
BAS_new
BAS_copy
BAS_2

Краще:

BAS_ERP_WORK
BAS_ERP_TEST
BAS_ERP_ARCHIVE_2025

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

Помилка: тестова база обмінюється з реальним сайтом

Після копіювання робочої бази в тестову можуть залишитися активними:

регламентні завдання;
обмін із сайтом;
банк;
email;
SMS;
EDI;
API;
Power BI-вивантаження;
обмін із WMS.

Наслідки:

дублікати замовлень;
тестові листи клієнтам;
неправильні статуси на сайті;
хаос у банку;
помилкові API-запити.

Після створення тестової бази інтеграції потрібно вимкнути.

Журнал оновлень BAS

Компанії бажано вести журнал релізів.

Приклад:

Дата	База	Було	Стало	Відповідальний	Результат
15.05.2026	BAS_ERP_TEST	2.5.18.100	2.5.18.120	Адміністратор	Тест пройдено
17.05.2026	BAS_ERP_WORK	2.5.18.100	2.5.18.120	Адміністратор	Успішно

Журнал допомагає зрозуміти, коли і що змінилося.

План відкату релізу

Перед оновленням потрібно мати план відкату.

План має відповідати на питання:

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

Без плану відкату оновлення робочої бази є ризикованим.

Реліз BAS і міграція в K2 ERP

При переході з BAS у K2 ERP потрібно знати релізи старої системи.

Важливо зафіксувати:

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

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

Чому реліз важливий для міграції

Різні релізи BAS можуть мати різні:

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

Тому міграційний інструмент має знати, з яким релізом працює.

Що перевірити перед міграцією

Перед міграцією в K2 ERP потрібно перевірити:

актуальність релізу;
чи є критичні помилки;
чи закриті періоди;
чи проведені документи;
чи працюють контрольні звіти;
чи є backup;
чи є тестова база;
чи описані доробки;
чи відомі зовнішні обробки;
чи відомі інтеграції;
чи потрібно оновлювати BAS перед міграцією;
чи краще мігрувати з поточного стану.

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

Реплікатор K2 і реліз BAS

Реплікатор K2 може допомогти при переході з BAS у K2 ERP.

Він може використовуватися для:

визначення структури старої бази;
аналізу довідників;
аналізу документів;
аналізу регістрів;
вивантаження даних;
формування контрольних сум;
перевірки сумісності;
підготовки міграційних таблиць;
підготовки JSON;
порівняння старої BAS і нової K2 ERP;
контролю після перенесення.

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

Архів BAS після переходу

Після переходу в K2 ERP стару BAS-базу можна залишити як архів.

Потрібно зафіксувати:

реліз платформи;
реліз конфігурації;
дату останнього оновлення;
дату переходу;
backup;
контрольні звіти;
список користувачів;
права;
стан інтеграцій;
статус “тільки для читання”.

Архівну базу не варто оновлювати без потреби.

Реліз BAS і санкційні ризики

Релізи BAS у контексті України потрібно розглядати не лише як технічні оновлення, а і як частину залежності від BAS/BAF/1С-екосистеми.

Ризики:

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

Держспецзв’язку в офіційному переліку забороненого до використання програмного забезпечення та комунікаційного обладнання згадує продукти 1С/BAS, зокрема 1C:Підприємство 8, BAS ERP та інші BAS-продукти. Указ Президента України №601/2024 ввів у дію рішення РНБО від 2 вересня 2024 року щодо санкцій. :contentReference[oaicite:3]{index=3}

Важливо. Якщо компанія продовжує регулярно встановлювати релізи BAS, вона фактично продовжує підтримувати стару BAS/BAF/1С-екосистему. Для українського бізнесу це потрібно оцінювати з погляду комплаєнсу, кібербезпеки, санкцій, вартості підтримки і плану переходу на безпечну ERP-платформу.

Типові питання

Що таке реліз BAS?

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

Чим реліз платформи відрізняється від релізу конфігурації?

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

Чи можна оновлювати BAS одразу в робочій базі?

Ні. Спочатку потрібно зробити backup, створити тестову копію, встановити реліз у тесті, перевірити ключові процеси, інтеграції, звіти, права і тільки після цього оновлювати робочу базу.

Навіщо читати опис релізу?

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

Що найчастіше ламається після релізу?

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

Чи потрібно оновлювати BAS перед міграцією в K2 ERP?

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

Коротко

Питання	Відповідь
Що таке реліз BAS?	Версія платформи, конфігурації, звітності, обробки або розширення.
Що оновлюється?	Документи, звіти, регістри, форми, права, інтеграції, звітність, платформа.
Що обов’язково перед релізом?	Backup, тестова база, опис релізу, тест-план, контрольні звіти.
Основний ризик	Оновлення без тесту може зламати облік, інтеграції або звіти.
Для міграції	Потрібно зафіксувати версію платформи, конфігурації, розширень і обробок.
Альтернатива	Плановий перехід у K2 ERP замість безкінечної підтримки старої BAS-екосистеми.

Висновок

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

Оновлення BAS потрібно виконувати дисципліновано: читати опис релізу, робити backup, тестувати на копії, перевіряти ключові сценарії, порівнювати контрольні звіти, перевіряти інтеграції, права, розширення і тільки після цього оновлювати робочу базу.

Реліз BAS — це не кнопка “оновити”, а контрольований процес зміни облікової системи.

При переході з BAS або 1С у K2 ERP потрібно зафіксувати реліз платформи, реліз конфігурації, розширення, обробки, інтеграції, контрольні звіти і стан бази. Це дозволяє правильно побудувати міграцію, звірити дані, залишити стару BAS-базу як архів і перейти до сучасної ERP-архітектури з API, audit log, Power BI, ролями і контрольованими модулями.

Див. також

Зовнішні посилання