Чи можна змінити придбаний ISV-застосунок, якщо він не зовсім підходить під наш робочий процес?

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

Чи завжди Per-Tenant Extensions коштують дорожче за ISV-застосунки?

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

Per-Tenant Extensions проти ISV-застосунків у Business Central: що обрати?

Q: У чому головна різниця між ISV-застосунком і Per-Tenant Extension у Business Central?

ISV-застосунок — це готове багаторазове рішення, створене незалежним постачальником програмного забезпечення для багатьох клієнтів і розміщене в AppSource, тоді як Per-Tenant Extension (PTE) пишеться на замовлення спеціально для клієнтського середовища однієї організації.

Q: Хто відповідає за оновлення Per-Tenant Extensions, коли Microsoft оновлює Business Central?

Відповідальність за підтримку PTE зрештою лежить на вашій організації. Коли Microsoft випускає великі оновлення платформи, ваша внутрішня ІТ-команда або зовнішній партнер із Business Central мусить протестувати та, за потреби, оновити код PTE, щоб зберегти сумісність.

Q: Як протестувати нове розширення, перш ніж впроваджувати його в робоче середовище Business Central?

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

By Mirko Peters · 2026-08-21

Порівняйте Per-Tenant Extensions (PTE) у Business Central та ISV-застосунки. Дізнайтеся, як обрати правильну стратегію кастомізації для вашого середовища ERP.

Automatically translated with AI from the original post. Read the English original

Cover: Dynamics 365 Business Central Extensions - Simply Explained

Під час кастомізації Dynamics 365 Business Central організації мусять вирішити, чи створювати власне Per-Tenant Extension (PTE), чи придбати готовий ISV-застосунок з AppSource. Цей посібник розбирає витрати, обслуговування, масштабованість і технічні наслідки обох варіантів, щоб ІТ-керівники та особи, що ухвалюють рішення, могли обрати правильну стратегію інтеграції для своїх унікальних робочих процесів.

Головне

ISV-застосунки пропонують готові масштабовані рішення для типових бізнес-процесів, таких як доставка, банківські операції та локалізація податків.
Per-Tenant Extensions (PTE) — це індивідуально написані доповнення, призначені виключно для унікальних робочих процесів однієї організації.
Вибір власного PTE означає, що організація бере на себе повну довгострокову відповідальність за тестування, документацію та сумісність з оновленнями.
Застосунки з AppSource заощаджують час на початкову розробку і часто включають регулярні оновлення та підтримку від незалежних постачальників програмного забезпечення.
Особи, що ухвалюють рішення, завжди мають спершу оцінити ключову бізнес-вимогу, перш ніж виділяти внутрішні ресурси на власну розробку.

Розуміння дилеми кастомізації Business Central

Dynamics 365 Business Central є надійною основою ERP для фінансів, продажів, запасів і управління ланцюгами постачання. Проте стандартний функціонал рідко на сто відсотків відповідає операційним реаліям кожної компанії. Організації неминуче стикаються зі сценаріями, коли стандартні сторінки, поля чи звіти не можуть охопити специфічний робочий процес.

Раніше модифікація ERP-програм означала переписування основного коду застосунку, що створювало величезні проблеми, коли постачальники випускали автоматичні оновлення. Сучасна архітектура Business Central вирішує це через розширення, акуратно відокремлюючи власний код від стандартної основи застосунку. Проте щойно ви вирішили користуватися розширеннями, перед вами постає важливий стратегічний розвилок: купити готовий пакет у незалежного постачальника програмного забезпечення (ISV) чи замовити індивідуальне Per-Tenant Extension (PTE)?

ISV-застосунки: сила готової багаторазовості

ISV-застосунок — це комерційний програмний пакет, створений незалежним постачальником для розв'язання конкретної, поширеної бізнес-проблеми для багатьох клієнтів Business Central. Такі рішення часто знаходять і встановлюють безпосередньо через Microsoft AppSource.

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

Переваги застосунків ISV:

Нижчі початкові витрати на впровадження порівняно з розробкою власного програмного забезпечення з нуля.
Вбудована документація, майстри налаштування та активні канали підтримки від вендора.
Регулярні оновлення сумісності, які випускаються разом із хвилями релізів Microsoft для Business Central.

Недоліки застосунків ISV:

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

Розширення для окремого клієнта: створені з урахуванням унікальних потреб

Розширення для окремого клієнта (PTE) — це ексклюзивний додаток, розроблений спеціально для середовища Business Central однієї організації. Його ніколи не публікують в AppSource для загального використання. PTE призначені для процесів, які справді відмінні від вашої бізнес-моделі та є її власними.

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

Переваги розширень для окремого клієнта:

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

Недоліки розширень для окремого клієнта:

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

Як вибрати правильний шлях для вашої організації

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

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

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

Висновок

Вибір між застосунком ISV і індивідуальним PTE зрештою визначає, як ваша ІТ-команда керуватиме поточним обслуговуванням і майбутніми оновленнями платформи. Розуміючи відмінні переваги та зони відповідальності кожного підходу, ви можете захистити основу Business Central і водночас дати співробітникам саме ті інструменти, які їм потрібні. Щоб глибше дізнатися, як розширення працюють «за лаштунками» і що перевірити перед встановленням, послухайте повний епізод та підпишіться на подкаст, щоб отримувати щоденні експертні думки про екосистему хмарних сервісів Microsoft.

Поширені запитання

У чому головна різниця між застосунком ISV і розширенням для окремого клієнта в Business Central?

Застосунок ISV — це готове багаторазове рішення, створене незалежним постачальником програмного забезпечення для багатьох клієнтів і розміщене в AppSource, тоді як розширення для окремого клієнта (PTE) пишеться спеціально для унікального середовища клієнта однієї організації.

Чи можна змінити придбаний ISV-застосунок, якщо він не повністю відповідає нашому робочому процесу?

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

Хто відповідає за оновлення Per-Tenant Extensions, коли Microsoft оновлює Business Central?

За підтримку PTE зрештою відповідає ваша організація. Коли Microsoft випускає великі оновлення платформи, ваша внутрішня ІТ-команда або зовнішній партнер із Business Central має протестувати код PTE і, за потреби, оновити його, щоб зберегти сумісність.

Чи завжди Per-Tenant Extensions коштують дорожче, ніж ISV-застосунки?

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

Як протестувати нове розширення, перш ніж впроваджувати його в робоче середовище Business Central?

Нові розширення слід завжди розгортати й тестувати в окремому пісочниці Business Central, виконуючи реальні операційні тестові сценарії разом із кінцевими користувачами, перш ніж дозволити коду працювати з даними живої компанії.