Розширення 1С

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

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

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

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

Важливо про 1С та BAS. В Україні продукти екосистеми 1С і частина продуктів BAS пов’язані з санкційними, юридичними, кібербезпековими та репутаційними ризиками. Держспецзв’язку веде офіційний перелік забороненого до використання програмного забезпечення та комунікаційного обладнання; у переліку згадуються продукти 1С/BAS, зокрема 1C:Підприємство 8 і BAS ERP. Також у матеріалах щодо переліку вказано застосування Указу Президента України №601/2024 для ТОВ «1С». Перед підтримкою, використанням або міграцією таких систем потрібно перевіряти актуальні офіційні обмеження. ([cip.gov.ua](https://cip.gov.ua/ua/statics/perelik-zaboronenogo-do-vikoristannya-programnogo-zabezpechennya-ta-komunikaciinogo-merezhevogo-obladnannya), [president.gov.ua](https://www.president.gov.ua/documents/6012024-52161))

Що таке розширення 1С

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

Розширення може:

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

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

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

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

Вони використовуються для:

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

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

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

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

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

Основні можливості розширень

Через розширення можна реалізувати:

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

Приклад використання розширення

Компанії потрібно додати в документ “Замовлення покупця” поле “Канал продажу”.

Без розширення розробник змінює основну конфігурацію.

Через розширення можна:

Додати реквізит “Канал продажу”.
Додати його на форму документа.
Додати відбір у звіт.
Додати заповнення за замовчуванням.
Додати передачу цього поля в JSON для сайту або CRM.
Не змінювати основну конфігурацію напряму.

Що можна додавати через розширення

Об’єкт	Приклад	Навіщо
Реквізит	Канал продажу	Додаткова аналітика
Команда	Вивантажити в CRM	Інтеграція
Форма	Додаткова вкладка	Зручність користувача
Загальний модуль	Модуль обміну з API	Спільна логіка
Звіт	Продажі по каналах	Аналітика
Обробка	Масове заповнення реквізиту	Сервісна задача
Підписка на подію	Перевірити мінімальну ціну перед проведенням	Контроль бізнес-правила

Реквізити в розширеннях

Розширення може додати новий реквізит до об’єкта.

Наприклад:

“Канал продажу” в замовлення покупця;
“Тип клієнта” в контрагента;
“Відповідальний технолог” у специфікацію;
“Код зовнішньої системи” в номенклатуру;
“Ознака синхронізації” у документ;
“Маркетплейс” у замовлення;
“ID банківської транзакції” у платіж.

Такі реквізити можуть використовуватися у формах, звітах, інтеграціях і перевірках.

Форми в розширеннях

Через розширення можна змінювати форми.

Наприклад:

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

Приклад сценарію:

у форму замовлення додали поле “Джерело ліда”;
менеджер заповнює його при створенні замовлення;
звіт продажів показує суму по джерелах;
інтеграція передає поле в CRM.

Команди в розширеннях

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

Приклади команд:

“Вивантажити на сайт”;
“Перевірити залишки”;
“Створити JSON”;
“Оновити статус оплати”;
“Заповнити ціни”;
“Перерахувати знижки”;
“Відправити в банк”;
“Створити заявку на виробництво”.

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

Модулі розширень

Розширення може містити власні модулі.

Типові варіанти:

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

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

Приклад задачі модуля:

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

Приклад коду в розширенні

Спрощений приклад команди, яка перевіряє заповнення реквізиту:

&НаКлиенте
Процедура ПеревіритиКаналПродажу(Команда)

    Если Не ЗначениеЗаполнено(Объект.КаналПродажу) Тогда
        Сообщить("Не заповнений канал продажу");
    Иначе
        Сообщить("Канал продажу заповнений");
    КонецЕсли;

КонецПроцедуры

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

Підписки на події

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

Наприклад:

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

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

Приклад сценарію:

перед проведенням реалізації перевірити мінімальну ціну;
після запису замовлення відправити дані в CRM;
після проведення оплати оновити статус замовлення;
перед записом контрагента перевірити ЄДРПОУ.

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

Задача: не дозволяти продаж нижче мінімальної ціни.

Розширення може:

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

Спрощена логіка:

Для Каждого Рядок Из Джерело.Товары Цикл

    МінЦіна = ОтриматиМінімальнуЦіну(Рядок.Номенклатура, Джерело.Дата);

    Если Рядок.Цена < МінЦіна Тогда
        Сообщить("Ціна нижче мінімальної: " + Строка(Рядок.Номенклатура));
        Отказ = Истина;
    КонецЕсли;

КонецЦикла;

Розширення і проведення документів

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

Можливі задачі:

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

Але небезпечно:

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

Розширення і регістри

Розширення може читати регістри і в окремих випадках записувати дані.

Регістри можуть бути:

Приклади:

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

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

Розширення і СКД

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

Наприклад:

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

СКД-звіт у розширенні може використовувати типові регістри й додані розширенням поля.

Розширення і інтеграції

Розширення часто використовують для інтеграцій.

Приклади:

обмін із сайтом;
обмін із CRM;
обмін із банком;
передача залишків;
передача цін;
отримання замовлень;
вивантаження рахунків;
передача статусів;
обмін із WMS;
обмін із MES;
підготовка даних для K2 ERP.

Приклад JSON:

{
  "order_number": "WEB-10025",
  "customer": "ТОВ Ромашка",
  "channel": "website",
  "items": [
    {
      "sku": "SKU-001",
      "quantity": 2,
      "price": 1200
    }
  ]
}

Розширення і HTTP-сервіси

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

Сценарії:

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

Для таких інтеграцій потрібно контролювати:

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

Розширення і друковані форми

Розширення може додавати друковані форми.

Приклади:

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

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

Розширення і права доступу

Розширення може додавати нові дані, які теж потрібно захищати.

Наприклад:

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

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

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

Розширення і оновлення 1С/BAS

Одна з головних причин використання розширень — спрощення оновлень.

Але розширення не гарантує безпроблемне оновлення.

Проблеми можуть виникнути, якщо:

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

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

Тестування розширень

Перед встановленням розширення потрібно перевірити:

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

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

Версії розширень

Розширення бажано вести з версіями.

У версії потрібно фіксувати:

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

Приклад:

Версія	Дата	Зміна
1.0	01.05.2026	Додано реквізит “Канал продажу”
1.1	10.05.2026	Додано звіт по каналах
1.2	20.05.2026	Додано вивантаження каналу в CRM

Документування розширень

Для кожного розширення потрібно описати:

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

Без документації розширення через кілька місяців стає “чорною скринькою”.

Типові сценарії використання розширень

Сценарій	Що додається	Приклад
Додаткова аналітика	Реквізит і звіт	Канал продажу
Контроль продажу	Підписка на проведення	Не продавати нижче мінімальної ціни
Інтеграція	Команда, модуль, лог	Вивантажити замовлення в CRM
Друкована форма	Новий макет	Рахунок із QR-кодом
Міграція	Звіт або обробка	Вивантажити залишки в JSON
Аудит	Логування змін	Хто змінив ціну

Приклад: розширення для інтернет-магазину

Задача: передавати замовлення з 1С/BAS на сайт і назад.

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

реквізит “ID сайту” в номенклатурі;
реквізит “ID сайту” в замовленні;
команду “Вивантажити на сайт”;
модуль формування JSON;
журнал помилок обміну;
регламентне завдання;
звіт по статусах обміну.

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

Об’єкт	Нове поле	Для чого
Номенклатура	site_id	Зіставлення з товаром сайту
Замовлення	web_order_id	Зв’язок із замовленням сайту
Замовлення	exchange_status	Контроль обміну

Приклад: розширення для банківської інтеграції

Задача: зберігати ID банківської транзакції.

Розширення може додати:

реквізит “bank_transaction_id”;
реквізит “bank_status”;
звіт по нерозпізнаних платежах;
обробку завантаження JSON-виписки;
лог помилок;
перевірку дублів.

Це допомагає уникнути повторного завантаження одного й того самого платежу.

Приклад: розширення для виробництва

Задача: додати контроль технолога в специфікації.

Розширення може додати:

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

Такий підхід допомагає контролювати виробничі норми.

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

Розширення і зовнішня обробка — не одне й те саме.

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

Для постійної бізнес-логіки часто краще розширення. Для разового експорту або сервісної задачі — зовнішня обробка.

Розширення і зовнішні звіти

Зовнішній звіт 1С зручний для аналітики без зміни конфігурації.

Розширення зручніше, якщо потрібно:

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

Типові помилки розширень 1С

Помилка	Причина	Наслідок
Розширення не працює після оновлення	Типова конфігурація змінила об’єкти	Потрібна адаптація
Документ став повільно проводитися	Важкий код у підписці	Користувачі чекають або база зависає
Дані дублюються	Підписка виконується кілька разів або немає контролю	Дублі записів і рухів
Користувач бачить зайві дані	Не налаштовані права на нові реквізити/звіти	Витік чутливої інформації
Розширення змінює облік непомітно	Немає документації й аудиту	Важко знайти причину розбіжностей
Хардкод у коді	Значення зашиті в модулі	Складно переносити й підтримувати
Немає логування інтеграції	Помилки не зберігаються	Неможливо підтримувати обмін

Помилка: розширення зламалося після оновлення

Причини:

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

Що робити:

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

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

Причини:

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

Поганий приклад: при проведенні кожної реалізації розширення синхронно викликає зовнішній API і чекає відповідь.

Краще:

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

Помилка: розширення дублює записи

Причини:

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

Для інтеграцій потрібно використовувати:

external_id;
GUID;
transaction_id;
унікальний ключ;
журнал обміну;
статус;
контроль повторної обробки.

Розширення і аудит

Потрібно знати:

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

Аудит особливо важливий, якщо розширення впливає на фінанси, склад, зарплату, ПДВ або виробництво.

Розширення і безпека

Розширення може бути небезпечним, якщо:

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

Критично. Розширення — це виконуваний код у вашій обліковій системі. Його не можна підключати без перевірки джерела, коду, прав, логіки і впливу на дані.

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

Практичний чек-лист:

Хто автор розширення.
Для чого воно потрібне.
Які об’єкти змінює.
Які реквізити додає.
Які форми змінює.
Які події перехоплює.
Які регістри читає.
Які регістри записує.
Чи є зовнішні HTTP-запити.
Чи є токени або паролі.
Чи є логування.
Чи є документація.
Чи перевірені права доступу.
Чи протестовано на копії.
Чи є план відкату.

Коли розширення — хороший варіант

Розширення добре підходить, якщо потрібно:

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

Коли розширення — поганий варіант

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

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

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

Розширення і технічний борг

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

Але вони можуть і збільшити його, якщо:

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

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

Розширення і міграція з 1С/BAS

Під час переходу з 1С або BAS у K2 ERP потрібно аналізувати не тільки основну конфігурацію, а й усі розширення.

У розширеннях може бути захована критична логіка:

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

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

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

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

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

Варіанти перенесення логіки розширень у K2 ERP

Логіка в розширенні 1С	Що робити в K2 ERP	Приклад
Додатковий реквізит	Перенести як поле або аналітику	Канал продажу
Перевірка	Реалізувати бізнес-правилом	Заборона продажу нижче мінімальної ціни
Інтеграція	Перепроєктувати через API	Сайт, банк, CRM
Звіт	Перенести в стандартний звіт або Power BI	Продажі по каналах
Друкована форма	Створити шаблон у K2 ERP	Рахунок, акт, етикетка
Тимчасове рішення	Не переносити	Разова обробка 2022 року
Хардкод	Замінити налаштуваннями	Склад, вид ціни, організація

Карта міграції розширення

Елемент розширення 1С	Що означає	Аналог у K2 ERP	Контроль
Реквізит	Додане поле	Custom field / attribute	Тип, обов’язковість, історія
Форма	Зміна інтерфейсу	UI form / layout	Чи потрібне поле користувачам
Команда	Дія користувача	Action / button / workflow	Права і логіка
Підписка на подію	Автоматична логіка	Event handler / business rule	Коли запускається
Загальний модуль	Спільний код	Service logic	Чи потрібна логіка
Звіт	Аналітика	Report / Power BI	Контрольні суми
Інтеграція	Обмін даними	REST API / integration job	Формати, статуси, логи

Контрольні суми при міграції розширень

Для перевірки потрібно звірити:

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

Реплікатор K2 і розширення 1С

Реплікатор K2 може допомогти при аналізі й перенесенні даних із розширень 1С або BAS у K2 ERP.

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

вивантаження даних із доданих реквізитів;
вивантаження службових регістрів;
пошуку зовнішніх ID;
аналізу статусів інтеграцій;
підготовки контрольних сум;
формування JSON для імпорту;
порівняння старої і нової логіки;
підготовки даних для Power BI;
паралельного запуску 1С/BAS і K2 ERP.

Розширення в сучасній ERP-архітектурі

У сучасній ERP логіка, яка в 1С/BAS була реалізована розширеннями, може бути реалізована через:

налаштування;
custom fields;
business rules;
workflow;
webhooks;
REST API;
інтеграційні сервіси;
права доступу;
audit log;
Power BI;
окремі мікросервіси;
low-code механізми.

У K2 ERP такі доробки краще реалізовувати не як хаотичні “латки”, а як контрольовані бізнес-правила, інтеграційні сценарії, звіти, API і права доступу.

Санкції та ризики використання 1С/BAS в Україні

При описі механізмів 1С і BAS в українському контексті потрібно згадувати санкційні та безпекові ризики.

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

Держспецзв’язку веде перелік забороненого до використання програмного забезпечення та комунікаційного обладнання. У переліку згадуються продукти 1С/BAS, зокрема 1C:Підприємство 8 і BAS ERP. У публічних матеріалах до переліку також фігурує Указ Президента України №601/2024 щодо ТОВ «1С». ([cip.gov.ua](https://cip.gov.ua/ua/statics/perelik-zaboronenogo-do-vikoristannya-programnogo-zabezpechennya-ta-komunikaciinogo-merezhevogo-obladnannya), [president.gov.ua](https://www.president.gov.ua/documents/6012024-52161))

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

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

Що таке розширення 1С?

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

Чим розширення краще за зміну типової конфігурації?

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

Чи можна через розширення змінити проведення документа?

Можна додати перевірки, підписки на події або додаткову логіку, але змінювати проведення потрібно дуже обережно, щоб не зламати регістри, залишки, ПДВ або собівартість.

Чому розширення може не працювати після оновлення?

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

Чи безпечно встановлювати розширення з інтернету?

Ні, без перевірки це ризиковано. Розширення — це виконуваний код, який може читати або змінювати дані. Його потрібно перевіряти на копії бази і аналізувати код.

Що важливо при міграції розширень у K2 ERP?

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

Коротко

Питання	Відповідь
Що таке розширення 1С?	Надбудова, яка додає або змінює функціональність без прямої зміни основної конфігурації.
Для чого потрібне?	Для реквізитів, форм, команд, перевірок, звітів, друкованих форм, інтеграцій і службової логіки.
Чим корисне?	Спрощує супровід і оновлення порівняно з прямою зміною типової конфігурації.
Що найчастіше ламається?	Сумісність після оновлень, форми, підписки, важкі запити, права доступу, інтеграції.
Чим небезпечне?	Може змінювати документи, регістри, облік і передавати дані назовні.
Що важливо при міграції?	Проаналізувати всі розширення і перенести корисну бізнес-логіку в K2 ERP або Power BI.

Висновок

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

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

Розширення — це не просто “додаткова кнопка”. Це окремий шар бізнес-логіки, який може впливати на облік, інтеграції, звіти, права і міграцію.

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

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

Див. також

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