Технічне завдання

Метод: POST /api/orders

Приклад ТЗ на міграцію

- Сума боргу збігається з актом звірки.;== Помилка: немає відповідального за вимогу ==

2.; Менеджер створює замовлення покупця в ERP.; # Описані документи.; |-

Для чого?; Формат: JSON - клієнта; - Доступний залишок Головне. Технічне задача — це не “побажання в чаті” і не “зробіть як у нас в голові”.; - Документ розрахунків - дата; K2 ERP має бути основною системою обліку замовлень, залишків, резервів і відвантажень.; Описати бізнес-процес, потрібні інформаційні дані, ролі, документи, правила, звіти і критерії приймання, а не копіювати старий інтерфейс BAS.; - собівартість; == характеристика майбутнього процесу == - Контрагент [[Категорія:JSON]] Мета має бути зрозумілою бізнесу і технічній команді.;[[Категорія:Вимоги]] == Приклад ТЗ на інтеграцію == * створення документа; * зміну документа; * видалення; * проведення; * скасування проведення; * зміну прав; * зміну критичних довідників; * API-запити; * помилки інтеграцій; * масовий імпорт; * зміну цін; * зміну банківських реквізитів.;=== Чим ТЗ відрізняється від опису задачі? === </div> Іноді перед фінальним ТЗ варто зробити прототип.; - Організація } \|- \| Бізнес-вимога \| Навіщо це потрібно бізнесу \| Менеджер має бачити доступний залишок товару перед продажем \|- \| Функціональна вимога \| Що саме має робити платформа \| У замовленні покупця показувати залишок, резерв і доступну кількість \|- \| Нефункціональна вимога \| Як платформа має працювати \| Звіт має відкриватися не довше 5 секунд для 50 000 рядків \|- \| Інтеграційна вимога \| Як платформа обмінюється даними \| Замовлення з сайту передається в ERP через API у форматі JSON \|- \| Вимога до безпеки \| Хто що має змогу бачити або змінювати \| Менеджер бачить тільки своїх клієнтів \|- \| Критерій приймання \| Як перевірити готовність \| При створенні замовлення з товаром без залишку платформа показує попередження \|} Межі проєкту визначають, що входить і що не входить у задачу.; Звіти потрібно описувати не загальними словами, а конкретно.;[[Категорія:K2 Cloud ERP]] інтеграційні функціональні можливості: сайт → K2 ERP Воно сприяє: - товарну групу; Не переносити: Критерії приймання — це конкретні умови, за якими робота вважається виконаною.; Документ '''Добре ТЗ — це коли розробник розуміє, що робити, тестувальник розуміє, що перевіряти, а замовник розуміє, за що він приймає роботу.''' Цей розділ важливий, щоб уникнути конфліктів.; У ТЗ потрібно описувати обмеження.; # Додатки.;[[Категорія:Користувачі K2 ERP]] "price": 1500.00 Потрібно описати, що робити, якщо: - Менеджер джерело даних; цільову систему; які довідники переносяться; які документи переносяться; який період історії потрібен; які залишки переносяться; які поля обов’язкові; правила очищення; правила об’єднання дублікатів; external_id; контрольні звіти; відповідальних за перевірку; план пробної міграції; план фінальної міграції; план відкату.;== Міграція даних ==
T-001	Створити замовлення на товар із достатнім залишком	Замовлення створено, товар зарезервовано
T-002	Створити замовлення на товар без залишку	платформа показує попередження або заборону
T-003	Завантажити замовлення з сайту через API	Замовлення створено в ERP з правильним external_id
T-004	Змінити залишок товару	API передає новий доступний залишок на сайт

- тестових контрагентів;

"edrpou": "12345678"

"counterparty": {

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

ТЗ має змогу бути коротким на 2–3 сторінки або великим документом на десятки сторінок — залежно від масштабу задачі.;== ТЗ для K2 ERP == </syntaxhighlight>

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

Приклад JSON у ТЗ

Обробка помилок

Приклад:

Для чого потрібне ТЗ

</syntaxhighlight> Погано: - контактних осіб;

- Організація

Чи можна починати розробку без ТЗ?

!; Що не входить у задачу?; Критерій

- Сума боргу
- замовник;
Критерії приймання:

Потрібно описати джерело BAS, цільову K2 ERP, довідники, документи, залишки, взаєморозрахунки, external_id, контрольні звіти, правила очищення, пробну міграцію, фінальну міграцію, архів BAS і санкційні обмеження.; # є собою критерії приймання.; Якщо ТЗ стосується міграції, потрібно описати:

Технічне задача — це документ, який описує, що потрібно зробити, які вимоги має виконати платформа, які інформаційні дані використовуються, які ролі мають доступ і як перевірити готовий результат.; !; # є собою розділ “не входить у задачу”.;== характеристика поточного процесу ==
Яку проблему вирішуємо?; - Днів прострочення
Через це клієнти іноді замовляють товар, якого вже немає.; # є собою відповідальні.; |-
| Що це?; ТЗ деталізує вимоги, межі, інформаційні дані, логіку, ролі, інтеграції, помилки, критерії приймання і тестові сценарії.; Статус: На погодженні
<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">

== Типові помилки в технічному завданні ==

== Висновок ==

!; Основні поля
- Період
- складський облік
Переносити:
Чому:
Якщо ТЗ нечітке, договір теж буде слабким для керування очікуваннями.; Фільтри:
<syntaxhighlight lang="text">
Краще:
Приклад для ERP:
== Звіти ==

<syntaxhighlight lang="text">
- валову маржу;
Права доступу потрібно описувати до початку розробки, а не після запуску.; Вимога

Обмеження

Критерії приймання

Отримувач:

;== Хто пише технічне задача ==

Кожна важлива вимога має мати власника.; Роль Звіт “продажі та реалізація по менеджерах” має показувати:

[[Категорія:1С]]

Тестові сценарії

; # Передумови.; # Описано майбутній бізнес-процес.; Метод:

Дата: 15.05.2026

Функціональні вимоги описують, що має робити платформа.; Ініціатива зміни → характеристика зміни → Оцінка впливу → Оцінка строків і вартості → Погодження → Реалізація → Тестування → Приймання - Договір Приклад формулювання:

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

!; Без критеріїв приймання незрозуміло, коли роботу можна вважати завершеною.; |- | Для ERP

| ТЗ має описувати бізнес-логіку, а не тільки екрани.;

Прототип сприяє:

Помилка: не описали “неуспішні” сценарії

== Межі проєкту ==
!; Приклад:

* впровадження ERP;
* впровадження [[K2 ERP]];
* міграції з [[BAS]] або [[1С]];
* створення нового модуля;
* доробки існуючого модуля;
* інтеграції з сайтом;
* інтеграції з банком;
* інтеграції з CRM;
* інтеграції з WMS;
* інтеграції через API;
* інтеграції через JSON або XML;
* створення звіту;
* створення Power BI-дашборду;
* зміни прав доступу;
* автоматизації бізнес-процесу;
* запуску документообігу;
* створення імпорту або експорту;
* розробки мобільного застосунку;
* конфігурація обліку товарів;
* розробки регламентної операції;
* опису вимог до безпеки.; Для кого це робиться?;[[Категорія:Організація в BAS]]

<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
Найкращий варіант — коли ТЗ створюється спільно: бізнес-середовище описує потребу, аналітик формалізує вимоги, технічна команда перевіряє реалізованість, а замовник погоджує результат.; - Статус
[[Категорія:BI]]
- спосіб оплати.; |-
| Для міграції з BAS
| Потрібні контрольні звіти, external_id, очищення даних і план архівації BAS.; Указ Президента України №601/2024 ввів у дію рішення для бізнесу РНБО від 2 вересня 2024 року щодо санкцій.; # є собою межі проєкту.; * перелік інформаційних баз BAS;
* реліз BAS;
* конфігурація BAS;
* організації;
* контрагенти;
* договори;
* номенклатура;
* склади;
* залишки;
* партії;
* серії;
* характеристики;
* взаєморозрахунки;
* банк;
* ПДВ;
* зарплата, якщо переноситься;
* документи;
* регістри;
* зовнішні обробки;
* інтеграції;
* Power BI;
* архів BAS;
* контрольні звіти;
* санкційні обмеження;
* план відмови від BAS.; # реліз документа.; Без ТЗ складно оцінити, реалізувати і прийняти роботу.;

Чек-лист якісного ТЗ

- договори;
{| class="wikitable" style="width:100%;"
Приклади розділів:
!; !; Тип вимоги
== Мета ТЗ ==
[[Категорія:Права доступу в ERP]]

== Audit log ==

- впровадження адресного WMS;

<syntaxhighlight lang="text">

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

[[Категорія:Audit log]]
У ТЗ потрібно вказувати назву і версію.; №
- Дата документа
'''Технічне задача''' — це формалізований характеристика майбутнього результату.; - ЄДРПОУ;
- доробка BAS після дати переходу.; Краще:
K2 ERP.; # Описані формати даних.;{{DISPLAYTITLE:Технічне завдання}}
{{SEO
|title=Технічне завдання — структура ТЗ, вимоги, приклади для ERP, K2 ERP, інтеграцій, міграції з BAS/1С і критерії приймання
|description=Технічне завдання: що це таке, навіщо потрібне, як писати ТЗ для ERP, CRM, WMS, K2 ERP, інтеграцій, міграції з BAS/1С, звітів, Power BI, API, модулів, доробок, які розділи має містити, приклади вимог, критерії приймання і типові помилки.
|keywords=технічне завдання, ТЗ, технічне завдання ERP, ТЗ на ERP, ТЗ на інтеграцію, ТЗ на міграцію даних, ТЗ BAS, ТЗ 1С, ТЗ K2 ERP, функціональні вимоги, нефункціональні вимоги, критерії приймання
}}
- конфігурація Power BI за межами звіту “Залишки”;
[[Категорія:Контрагент BAS]]
__TOC__
'''істотно про [[1С]].; # інформаційні дані та довідники.; При виборі товару платформа показує доступний залишок.; !; Причина
[[Категорія:ERP]]

 },
[[Категорія:Міграція з BAS]]
[[Категорія:Заміна BAS]]
5.; Вимога

{| class="wikitable" style="width:100%;"

== Типові питання ==
Для інтеграцій ТЗ має бути особливо точним.; {| class="wikitable" style="width:100%;"

4.; # Нефункціональні вимоги.; ([Держспецзв’язку](https://cip.gov.ua/ua/statics/perelik-zaboronenogo-do-vikoristannya-programnogo-zabezpechennya-ta-komunikaciinogo-merezhevogo-obladnannya), [Указ Президента України №601/2024](https://www.president.gov.ua/documents/6012024-52009), [Законодавство України](https://zakon.rada.gov.ua/go/601/2024))
- external_id.; # Обмеження.; Потрібно описати:
[[Категорія:Міграція з 1С]]
- контрагентів без руху за останні 5 років і без відкритого боргу;
- кількість замовлень.; Замовник: Відділ логістики

* “Стан старої BAS-бази”;
* “Санкційні обмеження”;
* “План міграції в K2 ERP”;
* “Архівування BAS”;
* “Вимкнення інтеграцій BAS”;
* “Заборона створення нових операцій у BAS після дати переходу”;
* “Контрольні звіти на дату переходу”;
* “Обмеження доступу до архівної BAS-бази”.; Які документи, довідники, звіти або інтеграції потрібні?; Інтернет-магазин.;[[Категорія:ERP впровадження]]

 "external_id": "ORDER-10001",
=== Чи потрібно в ТЗ описувати те, що не входить у задачу? ===
== Що таке технічне задача ==
- відсоток маржі;
У реальній системі важливі не тільки успішні сценарії.; # Інтеграції.; Не входить у ТЗ
K2 ERP є собою основним джерелом залишків.;[[Категорія:BAS]]
У сучасному українському контексті ТЗ на нові доробки BAS має містити оцінку, чи не доцільніше реалізувати задачу вже в K2 ERP або іншій безпечній ERP-платформі.; # є собою обробка помилок.; # Поточний бізнес-процес.;[[Категорія:Тестові сценарії]]
компонент обліку товарів у K2 ERP
== ТЗ для BAS/1С ==
Для ERP-системи істотно описувати audit log.; # є собою тестові сценарії.; !;[[Категорія:Критерії приймання]]
- Повторне замовлення з тим самим external_id не дублюється.;<syntaxhighlight lang="text">

[[Категорія:Договір BAS]]

</div>

ТЗ потрібне для:
- Резерв
 "date": "2026-05-15",
|-
| обліковий облік номенклатури
| Повна WMS-автоматизація з ТСД
|-
| Залишки по складах
| Адресне зберігання по комірках
|-
| Імпорт залишків з BAS
| Повна міграція історії за 10 років
|-
| API передачі залишків на сайт
| розробка програмного забезпечення нового сайту
|-
| Power BI-звіт по залишках
| Фінансовий P&L
|}

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

Назва: інтеграційні функціональні можливості інтернет-магазину з K2 ERP

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

Якщо ТЗ стосується BAS/1С, потрібно бути особливо уважним.; API сайту отримує оновлений доступний залишок протягом 5 хвилин.; Як перевірити, що робота виконана правильно?; - відкриті взаєморозрахунки; Краще: |- | F-001 | платформа має дозволяти створювати картку товару з артикулом, назвою, одиницею виміру і штрихкодом | Must |- | F-002 | платформа має вести залишки товарів у розрізі складів | Must |- | F-003 | платформа має вести залишки в розрізі характеристик | Should |- | F-004 | платформа має передавати доступні залишки на сайт через API | Must |- | F-005 | платформа має забороняти продаж товару з від’ємним доступним залишком | Must |}

Приклади:

!; Передавати замовлення покупців із сайту в K2 ERP і повертати статуси обробки на сайт.; Що має змогу робити

</syntaxhighlight>

Майбутній бізнес-процес описує, як має працювати платформа після реалізації.; Якщо доступний залишок менший за кількість у замовленні, платформа показує попередження.;== Див.; додатково == Все має працювати.;

Якісне ТЗ зменшує ризики, сприяє оцінити роботи, захищає бюджет, скорочує кількість переробок і дає зрозумілий спосіб прийняти результат.; "sku": "SKU-001", !; Критерії приймання:

!; - дублікати;

* [[K2 ERP]]
* [[K2 Cloud ERP]]
* [[Модулі K2 ERP]]
* [[Користувачі K2 ERP]]
* [[Права доступу в ERP]]
* [[Audit log]]
* [[API]]
* [[Інтеграція через JSON]]
* [[Power BI]]
* [[Qlik]]
* [[DBeaver]]
* [[SQL Server Management Studio]]
* [[Реплікатор K2]]
* [[Міграція з BAS]]
* [[Міграція з 1С]]
* [[Заміна BAS]]
* [[BAS]]
* [[BAF]]
* [[1С]]
* [[Інформаційна база BAS]]
* [[Реліз BAS]]
* [[Демо-база BAS]]
* [[Організація в BAS]]
* [[Контрагент BAS]]
* [[Договір BAS]]
* [[Облік товарів]]
* [[Взаєморозрахунки 1С]]
* [[ПДВ 1С]]
* [[Зарплата 1С]]
* [[Кадровий облік 1С]]
* [[Виробництво 1С]]
* [[Закриття місяця 1С]]
* [[HTTP-сервіси 1С]]
* [[XML 1С]]
* [[ERP на власному сервері]]
* [[Хмарна ERP]]
* [[Українське програмне забезпечення]]
* [[Цифрова незалежність]]

Зробити звіт по продажах.; # Описані довідники.; # є собою external_id.; - кількість;

# є собою мета.; | Щоб усі однаково розуміли задачу і могли прийняти результат.; - період;
Приклад:
реліз: 1.3

У ТЗ потрібно пояснити кожне поле: тип, обов’язковість, приклад, правила перевірки.; Окремо варто відзначити [[BAS]] і [[BAF]].''' Якщо технічне задача стосується підтримки, доробки, інтеграції або міграції з [[1С]] / [[BAS]], потрібно враховувати санкційні, юридичні, кібербезпекові і репутаційні ризики.; Приклад правила:
[[Категорія:Реплікатор K2]]
Погано:

Цей розділ захищає проєкт від розширення “по ходу”.; # Тестові сценарії.; # Майбутній бізнес-процес.; # Мета.; Ціль:

- external_id замовлення;
- менеджера;
Якщо власника немає, вимогу складно погодити і прийняти.; Держспецзв’язку веде офіційно затверджений перелік забороненого до використання програмного забезпечення та комунікаційного обладнання, де згадуються продукти 1С/BAS, зокрема 1C:організація 8 і BAS ERP.; |-
| центральний ризик
| Нечітке ТЗ призводить до конфліктів, переробок і невірного результату.; # Логування і audit log.; Вимога

[[Категорія:Міграція даних]]

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

Приклад ТЗ на звіт

форми документа;
списку;
картки довідника;
звіту;
дашборду;
API-схеми;
бізнес-процесу;

маршруту погодження.;

Назва: Міграція довідника контрагентів з BAS у K2 ERP

!; Це один із найважливіших розділів.;== Документи ==
- Помилки логуються.;

Краще:

Функціональні вимоги

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

у BAS має змогу бути багато старих помилок;
частина процесів була ручною;
частина доробок не документована;
користувачі можуть не знати логіку;
стару систему не потрібно копіювати один в один;
K2 ERP має змогу мати кращу архітектуру;
можна перенести хаос у нову систему.; # Описані інтеграції.; - Контрагент

Назва документа.;</syntaxhighlight>

Санкції та ризики BAS/1С у технічному завданні

Приклади: Логування: усі запити і відповіді - Сума - перенесення зарплатної історії; Після підтвердження замовлення товар резервується.; Він сприяє уникнути ситуації, коли замовник очікує більше, ніж реально було погоджено.; № Технічне задача — це основа керованої розробки, впровадження, інтеграції або міграції.; - Статус замовлення повертається на сайт.; Поля: Менеджери перевіряють доступність товару вручну.; Приклади: - Таблична частина товарів Без ТЗ проєкт часто перетворюється на набір усних домовленостей, де кожен учасник розуміє задачу по-своєму.; # Критерії приймання.; Відповідь Нефункціональні вимоги описують якість роботи системи.; "organization": "COMPANY_1",

Структура технічного задача

Приклад: - повна заміна CRM;

Нефункціональні вимоги

- демо-записи.; Він лише сприяє його уточнити.;

Але прототип не замінює ТЗ.; Приклад:

Не входить у межі цього ТЗ:
Під час проєкту вимоги можуть змінюватися.; Помилка

Основні інформаційні дані: Які правила розрахунків?; # Що не входить у задачу.; Версійність важлива, бо ТЗ часто змінюється.; - телефон;

Назва і реліз ТЗ

Автор: Бізнес-аналітик

Проста аналогія. Якщо ERP-проєкт — це будівництво будинку, то технічне задача — це креслення, список кімнат, матеріалів, вимог до електрики, води, дверей, вікон і критеріїв, за якими замовник скаже: “Так, це саме те, що ми замовляли”.; Без версій незрозуміло, яка редакція була погоджена.; # Функціональні вимоги.;

Audit log потрібен для безпеки, розслідування помилок і контролю відповідальності.; Очікуваний результат
<syntaxhighlight lang="text">
<syntaxhighlight lang="text">
!; - складський облік;

інформаційні дані і довідники

;== Коли потрібне технічне задача == Що потрібно зробити?; Power BI показує залишки, резерви і дефіцит.; !; * товар не знайдено; контрагент дублюється; банк повернув помилку; API недоступний; користувач системи не має прав; документ уже існує; інформаційні дані не пройшли валідацію; файл має неправильний формат; міграційний рядок не завантажився.;=== Як писати ТЗ на міграцію з BAS у K2 ERP? === Джерело:	;=== Що таке технічне задача? === Форма “Замовлення покупця”: Мета: - Прострочення більше N днів Тестові сценарії допомагають перевірити результат.; \|} Можна для дуже маленьких задач, але для ERP, інтеграцій, міграції, звітів, прав доступу або бізнес-процесів це ризиковано.; Частота: у момент створення замовлення - розробка програмного забезпечення нового сайту; ] ТЗ фіксує мету робіт, межі проєкту, бізнес-вимоги, функціональні вимоги, нефункціональні вимоги, інформаційні дані, ролі, інтеграції, звіти, алгоритми, критерії приймання, обмеження, відповідальних і очікуваний результат.; # є собою audit log.; Він має пояснювати логіку.; ([Держспецзв’язку](https://cip.gov.ua/ua/statics/perelik-zaboronenogo-do-vikoristannya-programnogo-zabezpechennya-ta-komunikaciinogo-merezhevogo-obladnannya), [Указ Президента України №601/2024](https://www.president.gov.ua/documents/6012024-52009), [Законодавство України](https://zakon.rada.gov.ua/go/601/2024)) - email; Так.; # Бізнес-вимоги.; Макет не обов’язково має бути красивим.;== Бізнес-вимоги і технічні вимоги == Перед описом майбутньої системи потрібно зрозуміти, як бізнес-процес функціонує зараз.; При міграції з BAS/1С у K2 ERP ТЗ має містити окремі розділи: Приклад: - спосіб доставки; Інтеграції Сайт отримує доступний залишок через API кожні 5 хвилин.; це документ, який описує, що саме потрібно розробити, налаштувати, інтегрувати, перенести, автоматизувати або змінити в інформаційній системі виступає ключовою рисою Технічне задача або ТЗ.;== ТЗ на міграцію з BAS у K2 ERP == - статус ПДВ; не переносити історію старше 3 років; не змінювати поточну структуру сайту; не використовувати прямий доступ до production-бази; не створювати документи без external_id; не дозволяти від’ємні залишки; не показувати собівартість менеджерам; не використовувати BAS як робочу систему після запуску K2 ERP; не передавати персональні інформаційні дані без погодження.; Призначення BAS ERP, база BAS_ERP_WORK.; Пріоритет Мета: - кількість активних контрагентів; Якщо замовлення з external_id вже існує, платформа не створює дубль, а повертає код 409 і посилання на існуючий документ.; Хто приймає - Дата оплати за умовами договору Приклад: - список дублікатів за ЄДРПОУ;
обліковий облік залишків	Керівник складу	Логістика
Дебіторка	Фінансовий директор	фінансовий блок
ПДВ	центральний бухгалтер	бухгалтерський обліковий облік
API сайту	CTO	ІТ-відділ
Power BI	Керівник аналітики	BI-команда

Потрібно логувати:

До ТЗ бажано додавати макети:

Контроль:

6.; # Відповідальні.; !; У ТЗ потрібно описати документи, які створює або змінює платформа.; {| class="wikitable" style="width:100%;" Які інформаційні дані використовуємо?;== Технічне задача і прототипування ==

істотно. ТЗ на міграцію з BAS/1С має не тільки описувати, що переносити, а й що припинити використовувати: старі обробки, інтеграції, регламентні задача, активні користувачі, прямий запис у BAS і паралельне ведення обліку у двох системах.;

!; з цієї причини в ТЗ для українського бізнесу потрібно окремо фіксувати план відмови від застарілої BAS/1С-екосистеми, архівацію старої бази, міграцію в безпечну ERP і обмеження доступу до старих систем.; # є собою нефункціональні вимоги.; Держспецзв’язку в офіційному переліку забороненого до використання програмного забезпечення та комунікаційного обладнання згадує 1C:організація 8 і BAS ERP; Указ Президента України №601/2024 ввів у дію рішення для бізнесу РНБО від 2 вересня 2024 року щодо санкцій.; # Терміни і визначення.; Звіт “Залишки” показує фізичний залишок, резерв і доступну кількість.; {| class="wikitable" style="width:100%;"

Джерело:

[[Категорія:Системний аналіз]]

- Кнопка “Підтвердити”

* модулі K2 ERP;
* користувачі;
* ролі;
* довідники;
* документи;
* бізнес-процеси;
* API;
* інтеграції;
* Power BI;
* audit log;
* міграція;
* права доступу;
* хмарний або серверний контур;
* резервне копіювання;
* тестування;
* приймання.; - акти звірки по топ-50 контрагентах.;[[Категорія:Функціональні вимоги]]
- адреси;

ТЗ має описувати, які довідники використовуються.; - товари;

</div>

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

Потрібно описати: !; 3.;</syntaxhighlight>

Резерви не передаються на сайт.; !; * Указ Президента України №601/2024

Зробити обліковий облік товарів.; !; Обмеження

продуктивність;
безпека;
доступність;
масштабованість;
аудит;
резервне копіювання;
зручність;
локалізація;
сумісність;
надійність.; Потрібен бізнес-процес change request:

!; Якщо ТЗ пов’язане з BAS/1С, у ньому потрібно прямо описати ризики і обмеження.; # Міграція даних.; # є собою реліз документа.; Технічне задача потрібне для:

!; # Звіти.; # Описані звіти.; |- | Основні розділи | Мета, межі, вимоги, ролі, інформаційні дані, документи, звіти, інтеграції, критерії приймання.; - Відповідальний менеджер </syntaxhighlight> Приклад: - розробка програмного забезпечення мобільного застосунку;

Прототипи і макети

Помилка: “зробити як у BAS”

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

У ТЗ потрібно описати, що робити при помилках.; Важливі розділи:

Назва: Звіт “Дебіторська заборгованість по контрагентах”

джерело;
отримувача;
протокол;
формат;
частоту;
авторизацію;
структуру даних;
external_id;
правила створення;
правила актуалізація;
обробку помилок;
повтори;
логування;
відповідальних.; "quantity": 2,

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

Приклад: { </syntaxhighlight> Приклад:

Що найважливіше в ТЗ?

"external_id": "CLIENT-001",

Які ролі мають доступ?; # Документи.; # Помилки і винятки.; # є собою ролі і права.; Приклад:

Технічне задача і договір з підрядником

K2 ERP.;

ТЗ відповідає на питання: Без процесу змін будь-яке ТЗ оперативно втрачає актуальність.; Що описує - ціна; ТЗ часто є собою додатком до договору з підрядником.; "items": [

Мета пояснює, навіщо виконується робота.; # Описано поточний бізнес-процес.; - Організація - Контрагент

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

|- | NF-001 | Звіт по залишках має відкриватися оперативно | До 5 секунд для 50 000 рядків |- | NF-002 | API має працювати через HTTPS | Усі запити тільки через TLS |- | NF-003 | Дії користувачів мають логуватися | Створення, зміна, видалення документів у audit log |- | NF-004 | платформа має підтримувати одночасну роботу користувачів | До 100 активних користувачів |}

ТЗ має змогу писати:

!; Власник

"name": "ТОВ \"замовник 1\"",

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

Автоматизувати обліковий облік товарів у K2 ERP: забезпечити ведення номенклатури, складів, характеристик, партій, залишків, резервів, інвентаризації та передачу доступних залишків в інтернет-магазин.; Експорт: Excel.; # є собою функціональні вимоги.;

Які бізнес-процеси зачіпаємо?; REST API, JSON, HTTPS.;<syntaxhighlight lang="json">
== Технічне задача і зміни ==
== Що не входить у ТЗ ==

У ТЗ потрібно описати ролі користувачів.; BAS після переходу застосовують, коли потрібно тільки як архів для читання.;<syntaxhighlight lang="text">
- Договір
- банківські рахунки;
- активних контрагентів;
того, щоб замовник забезпечується через У проєктах [[ERP]], [[K2 ERP]], [[BAS]], [[1С]], CRM, WMS, Power BI, API, міграції даних або автоматизації бізнес-процесів технічне задача потрібне; додатково реалізовано аналітик, розробник, інтегратор, тестувальник і користувачі однаково розуміли, що саме має бути зроблено.; - Менеджер бачить тільки своїх контрагентів.; Входить у ТЗ

Призначення: передача замовлень покупців

* організації;
* контрагенти;
* договори;
* номенклатура;
* склади;
* одиниці виміру;
* характеристики;
* партії;
* серії;
* типи цін;
* користувачі;
* ролі;
* підрозділи;
* проєкти;
* статті витрат;
* банки;
* валюти.; Типова структура ТЗ:

Показати відкриту дебіторську заборгованість у розрізі організацій, контрагентів, договорів і строків прострочення.; - виручку без ПДВ; Повтор: до 3 разів при помилці 5xx </syntaxhighlight>

Погано: Фільтри: період, організація, менеджер, група товарів.; Фраза “зробити як у BAS” — погане технічне задача.; користувач системи з роллю “Менеджер” має змогу створити замовлення покупця.; 1.; {

|-
| Менеджер продажів
| Створювати замовлення покупців, бачити доступні залишки
| Не бачить собівартість
|-
| Комірник
| Виконувати приймання, переміщення, відвантаження
| Не змінює ціни
|-
| Бухгалтер
| Перевіряє документи, ПДВ, проводки
| Не змінює WMS-налаштування
|-
| Керівник
| Переглядає звіти і KPI
| Не редагує довідники
|-
| Адміністратор
| Налаштовує права і довідники
| Доступ обмежений відповідальними особами
|}

Технічне задача:

Зараз залишки ведуться в BAS і частково в Excel.; Приклад
- ІПН;

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