Перейти до вмісту

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

Матеріал з K2 ERP Wiki

- повна заміна CRM;

Коротко

Поля:

- відсоток маржі; 

У ТЗ потрібно вказувати назву і версію. Не переносити:

! Приклад:

У реальній системі важливі не тільки успішні сценарії. Формат: JSON
== Критерії приймання ==
Для проєктів переходу з [[BAS]] або [[1С]] у [[K2 ERP]] технічне задача особливо важливе: воно має описати не тільки нову функціональність, а й очищення даних, мапінг довідників, контрольні звіти, міграцію, архів старої бази, відключення інтеграцій BAS і запуск нової ERP як основної системи обліку. Приклад:
<syntaxhighlight lang="text">

== Межі проєкту ==
Мета:

Звіти потрібно описувати не загальними словами, а конкретно. Причина </syntaxhighlight>

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

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

Як писати ТЗ на міграцію з BAS у K2 ERP?

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

Якщо замовлення з external_id вже існує, платформа не створює дубль, а повертає код 409 і посилання на існуючий документ. # інформаційні дані та довідники.== Див. так само == 

- ціна;
Типова структура ТЗ:
== Типові помилки в технічному завданні ==
Найкращий варіант — коли ТЗ створюється спільно: бізнес-середовище описує потребу, аналітик формалізує вимоги, технічна команда перевіряє реалізованість, а замовник погоджує результат. Не входить у ТЗ
{| class="wikitable" style="width:100%;"
Тестові сценарії допомагають перевірити результат. # Описані формати даних. Це один із найважливіших розділів. Що описує

* не знайдено контрагента;
* не знайдено товар;
* неправильний external_id;
* товар без залишку;
* помилка авторизації API;
* дубль документа;
* неправильний формат дати;
* порожній обов’язковий реквізит;
* недоступний сервер;
* помилка валідації. |-
| F-001
| платформа має дозволяти створювати картку товару з артикулом, назвою, одиницею виміру і штрихкодом
| Must
|-
| F-002
| платформа має вести залишки товарів у розрізі складів
| Must
|-
| F-003
| платформа має вести залишки в розрізі характеристик
| Should
|-
| F-004
| платформа має передавати доступні залишки на сайт через API
| Must
|-
| F-005
| платформа має забороняти продаж товару з від’ємним доступним залишком
| Must
|}

- клієнта;

Експорт: Excel. Помилка
- Період
Без ТЗ проєкт часто перетворюється на набір усних домовленостей, де кожен учасник розуміє задачу по-своєму. K2 ERP. # Мета. Інтернет-магазин. # Відповідальні. # Описані документи. До ТЗ бажано додавати макети:

Під час проєкту вимоги можуть змінюватися. Приклад

Джерело:

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

K2 ERP.[[Категорія:Інтеграція]]

* у BAS здатна бути багато старих помилок;
* частина процесів була ручною;
* частина доробок не документована;
* користувачі можуть не знати логіку;
* стару систему не потрібно копіювати один в один;
* K2 ERP здатна мати кращу архітектуру;
* можна перенести хаос у нову систему. | Документ з вимогами до розробки, впровадження, інтеграції або міграції.== ТЗ для K2 ERP ==

== Міграція даних ==

[[Категорія:Цифрова незалежність України]]

! Але прототип не замінює ТЗ. - Менеджер бачить тільки своїх контрагентів. Документ
![[Категорія:BAS]]

* форми документа;
* списку;
* картки довідника;
* звіту;
* дашборду;
* API-схеми;
* бізнес-процесу;
* маршруту погодження. |}

Іноді перед фінальним ТЗ варто зробити прототип. цифровізувати обліковий облік товарів у K2 ERP: забезпечити ведення номенклатури, складів, характеристик, партій, залишків, резервів, інвентаризації та передачу доступних залишків в інтернет-магазин. * [https://www.president.gov.ua/documents/6012024-52009 Указ Президента України №601/2024]
* [https://zakon.rada.gov.ua/go/601/2024 Указ Президента України №601/2024 — Законодавство України]
* [https://cip.gov.ua/ua/statics/perelik-zaboronenogo-do-vikoristannya-programnogo-zabezpechennya-ta-komunikaciinogo-merezhevogo-obladnannya Перелік забороненого до використання програмного забезпечення та комунікаційного обладнання]
* [https://erp.kyiv.ua Сайт K2 ERP]
* [https://wiki.erp.kyiv.ua Wiki K2 ERP]
* [https://cloud.corp2.eu K2 Cloud ERP]

 "external_id": "CLIENT-001",
 "items": [
{| class="wikitable" style="width:100%;"
- Помилки логуються. # Поточний бізнес-процес. # Бізнес-вимоги. | Щоб усі однаково розуміли задачу і могли прийняти результат. "name": "ТОВ \"клієнт ERP 1\"",
Фільтри: період, організація, менеджер, група товарів. ([Держспецзв’язку](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))

Контроль:
== Звіти ==
</div>

У ТЗ потрібно описати ролі користувачів. Тому в ТЗ для українського бізнесу потрібно окремо фіксувати план відмови від застарілої BAS/1С-екосистеми, архівацію старої бази, міграцію в безпечну ERP і обмеження доступу до старих систем.== Документи ==
Які документи, довідники, звіти або інтеграції потрібні? Приклад:

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

Сайт оновлює залишки раз на добу. Повтор: до 3 разів при помилці 5xx

Критерії приймання — це конкретні умови, за якими робота вважається виконаною. У ТЗ потрібно описувати обмеження. ! Указ Президента України №601/2024 ввів у дію рішення для бізнесу РНБО від 2 вересня 2024 року щодо санкцій. BAS після переходу застосовують, коли потрібно тільки як архів для читання. Вимога
! Погано:
При міграції з BAS/1С у [[K2 ERP]] ТЗ має містити окремі розділи:
<syntaxhighlight lang="text">
- Повторне замовлення з тим самим external_id не дублюється. Потрібно описати, що робити, якщо:
Приклад:
ТЗ здатна писати:

Приклади:

</div>

- розробка програмного забезпечення мобільного застосунку; компонент обліку товарів у K2 ERP Яку проблему вирішуємо? - контактних осіб;

Основні інформаційні дані:

Метод:

Приклад формулювання:

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

<syntaxhighlight lang="text">

- спосіб оплати. - Контрагент
Майбутній бізнес-процес описує, як має працювати платформа після реалізації.

- перенесення зарплатної історії; Права доступу потрібно описувати до початку розробки, а не після запуску.=== Чи можна починати розробку без ТЗ? ===

  1. виступає як мета. Пріоритет

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

Power BI показує залишки, резерви і дефіцит. API сайту отримує оновлений доступний залишок протягом 5 хвилин. # Передумови. - Кнопка “Підтвердити” - Сума боргу

Якщо ТЗ стосується міграції, потрібно описати:

Метод: POST /api/orders

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

! Кожна важлива вимога має мати власника. Не входить у межі цього ТЗ: - впровадження адресного WMS; Все має працювати. Без ТЗ складно оцінити, реалізувати і прийняти роботу. Прототип оптимізує:

</syntaxhighlight>

Сайт отримує доступний залишок через API кожні 5 хвилин. |- | Основні розділи | Мета, межі, вимоги, ролі, інформаційні дані, документи, звіти, інтеграції, критерії приймання. # виступає як тестові сценарії. ТЗ здатна бути коротким на 2–3 сторінки або великим документом на десятки сторінок — залежно від масштабу задачі. # виступає як ролі і права. Вимога Фраза “зробити як у BAS” — погане технічне задача. {| class="wikitable" style="width:100%;" Добре ТЗ — це коли розробник розуміє, що робити, тестувальник розуміє, що перевіряти, а замовник розуміє, за що він приймає роботу. через SEO-опис поточного процесу користувачі можуть зрозуміти проблему, а не без зусиль цифровізувати старий хаос. Воно перетворює усні побажання на конкретний документ: що потрібно зробити, для кого, з якими даними, за якими правилами, з якими ролями, обмеженнями, тестами і критеріями приймання. Основні поля - Контрагент Що потрібно зробити? * товар не знайдено;

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

Які інформаційні дані використовуємо?SEO title: Технічне завдання — структура ТЗ, вимоги, приклади для ERP, K2 ERP, інтеграцій, міграції з BAS/1С і критерії приймання

SEO keywords: технічне завдання, ТЗ, технічне завдання ERP, ТЗ на ERP, ТЗ на інтеграцію, ТЗ на міграцію даних, ТЗ BAS, ТЗ 1С, ТЗ K2 ERP, функціональні вимоги, нефункціональні вимоги, критерії приймання 

</noinclude>
 {{SEO
Шаблон для службового SEO-опису сторінки.

}}


Технічне задача — це документ, який описує, що потрібно зробити, які вимоги має виконати платформа, які інформаційні дані використовуються, які ролі мають доступ і як перевірити готовий результат. # виступає як відповідальні.== Технічне задача і прототипування ==

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

- виручку без ПДВ; 5. - Менеджер

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

Технічне задача і зміни

</syntaxhighlight>

</syntaxhighlight>

Дата: 15.05.2026 

Якісне ТЗ зменшує ризики, оптимізує оцінити роботи, захищає бюджет, скорочує кількість переробок і дає зрозумілий спосіб прийняти результат. - телефон;
- менеджера;

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

- Статус замовлення повертається на сайт. * не переносити історію старше 3 років;
* не змінювати поточну структуру сайту;
* не використовувати прямий доступ до production-бази;
* не створювати документи без external_id;
* не дозволяти від’ємні залишки;
* не показувати собівартість менеджерам;
* не використовувати BAS як робочу систему після запуску K2 ERP;
* не передавати персональні інформаційні дані без погодження. Перед описом майбутньої системи потрібно зрозуміти, як бізнес-процес функціонує зараз.== Бізнес-вимоги і технічні вимоги ==

! Якщо доступний залишок менший за кількість у замовленні, платформа показує попередження.[[Категорія:Тестові сценарії]]
<syntaxhighlight lang="text">
реліз системи: 1.3
K2 ERP має бути основною системою обліку замовлень, залишків, резервів і відвантажень. ([Держспецзв’язку](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))
Краще:
}
Цей розділ захищає проєкт від розширення “по ходу”. Він оптимізує уникнути ситуації, коли замовник очікує більше, ніж реально було погоджено. # виступає як нефункціональні вимоги. * бізнес-аналітик;
* системний аналітик;
* проєктний менеджер;
* ERP-консультант;
* розробник;
* архітектор;
* керівник напрямку;
* ключовий користувач системи;
* замовник разом із підрядником;
* команда впровадження.== Інтеграції ==
! Назва: інтеграційні функції ERP інтернет-магазину з K2 ERP

Якщо ТЗ пов’язане з BAS/1С, у ньому потрібно прямо описати ризики і обмеження. Призначення

Менеджер створює замовлення покупця в ERP. - акти звірки по топ-50 контрагентах. ! # Додатки.

</syntaxhighlight> 

"price": 1500.00

У ТЗ потрібно пояснити кожне поле: тип, обов’язковість, приклад, правила перевірки. Приклад: </syntaxhighlight>

!== ТЗ на міграцію з BAS у K2 ERP == ! Очікуваний результат

REST API, JSON, HTTPS. ТЗ відповідає на питання: |- | Бізнес-вимога | Навіщо це потрібно бізнесу | Менеджер має бачити доступний залишок товару перед продажем |- | Функціональна вимога | Що саме має робити платформа | У замовленні покупця показувати залишок, резерв і доступну кількість |- | Нефункціональна вимога | Як платформа має працювати | Звіт має відкриватися не довше 5 секунд для 50 000 рядків |- | Інтеграційна вимога | Як платформа обмінюється даними | Замовлення з сайту передається в ERP через API у форматі JSON |- | Вимога до безпеки | Хто що здатна бачити або змінювати | Менеджер бачить тільки своїх клієнтів |- | Критерій приймання | Як перевірити готовність | При створенні замовлення з товаром без залишку платформа показує попередження |}

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

  1. Назва документа. # виступає як розділ “не входить у задачу”. # Описано поточний бізнес-процес. критично про 1С. Приклад:

</syntaxhighlight>

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

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

  • “Стан старої BAS-бази”;
  • “Санкційні обмеження”;
  • “План міграції в K2 ERP”;
  • “Архівування BAS”;
  • “Вимкнення інтеграцій BAS”;
  • “Заборона створення нових операцій у BAS після дати переходу”;
  • “Контрольні звіти на дату переходу”;
  • “Обмеження доступу до архівної BAS-бази”. {| class="wikitable" style="width:100%;"

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

SEO-опис поточного процесу

- доробка BAS після дати переходу. Краще: ! # Межі проєкту. Звіт “Залишки” показує фізичний залишок, резерв і доступну кількість. # Обмеження. # Описані довідники. Приклад: SEO-опис задачі здатна бути коротким і загальним. ! # виступає як межі проєкту. Тип вимоги Показати відкриту дебіторську заборгованість у розрізі організацій, контрагентів, договорів і строків прострочення. # Критерії приймання. # Міграція даних.

ТЗ для BAS/1С

Передавати замовлення покупців із сайту в K2 ERP і повертати статуси обробки на сайт. Після підтвердження замовлення товар резервується. # Логування і audit log. Він має пояснювати логіку. K2 ERP виступає як основним джерелом залишків. Статус: На погодженні

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

Приклад правила: - дублікати;

Технічне задача — це формалізований SEO-опис майбутнього результату. ! # реліз системи документа. - дата; - клієнт ERP;
Питання

Назва: Звіт “Дебіторська заборгованість по контрагентах” Звіт “продажі та реалізація по менеджерах” має показувати: - конфігурація Power BI за межами звіту “Залишки”; </syntaxhighlight>

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

У сучасному українському контексті ТЗ на нові доробки BAS має містити оцінку, чи не доцільніше реалізувати задачу вже в K2 ERP або іншій безпечній ERP-платформі. Джерело:

Чому: 

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

* [[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]]
* [[Українське програмне забезпечення]]
* [[Цифрова незалежність]]

Функціональні вимоги описують, що має робити платформа. __TOC__

!<syntaxhighlight lang="text">

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

Для кого це робиться? # Звіти. |-

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

- кількість замовлень.== Що таке технічне задача == 

[[Категорія:Бізнес-аналіз]]

Мета має бути зрозумілою бізнесу і технічній команді. Сценарій

! №
Зараз залишки ведуться в BAS і частково в Excel.[[Категорія:SQL Server Management Studio]]
У ТЗ потрібно описати, що робити при помилках. - ЄДРПОУ;
! Хто приймає
- Днів прострочення

Версійність важлива, бо ТЗ часто змінюється. # Документи. Роль 

{
  • організації;
  • контрагенти;
  • договори;
  • номенклатура;
  • склади;
  • одиниці виміру;
  • характеристики;
  • партії;
  • серії;
  • типи цін;
  • користувачі;
  • ролі;
  • підрозділи;
  • проєкти;
  • статті витрат;
  • банки;
  • валюти. # виступає як external_id. це документ, який описує, що саме потрібно розробити, налаштувати, інтегрувати, перенести, цифровізувати або змінити в інформаційній системі виступає ключовою рисою Технічне задача або ТЗ.

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

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

Приклади: У ТЗ потрібно описати документи, які створює або змінює платформа. Якщо ТЗ нечітке, договір теж буде слабким для керування очікуваннями. # Терміни і визначення. Він лише оптимізує його уточнити. Макет не обов’язково має бути красивим. |-

Для чого? - розробка програмного забезпечення нового сайту;

- договори;

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

- Договір Приклад: Важливі розділи:

Межі проєкту визначають, що входить і що не входить у задачу.

Для ERP-системи критично описувати audit log. При виборі товару платформа показує доступний залишок. Через це клієнти іноді замовляють товар, якого вже немає. Краще:

Мета: 
== інформаційні дані і довідники ==
- складський облік;
[[Категорія:ТЗ]]

Цей розділ важливий, щоб уникнути конфліктів. # виступає як реліз системи документа. Ціль:
Якщо ТЗ стосується BAS/1С, потрібно бути особливо уважним. # Функціональні вимоги. # виступає як критерії приймання.== Приклад ТЗ на міграцію ==

== Audit log ==

- Дата оплати за умовами договору

<syntaxhighlight lang="text">

== Коли потрібне технічне задача ==

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

- email;
- Відповідальний менеджер
{| class="wikitable" style="width:100%;"
|-
| Що це?[[Категорія:1С]]

того, щоб замовник забезпечується через У проєктах ERP, K2 ERP, BAS, 1С, CRM, WMS, Power BI, API, міграції даних або автоматизації бізнес-процесів технічне задача потрібне; так само реалізовано аналітик, розробник, інтегратор, тестувальник і користувачі однаково розуміли, що саме має бути зроблено. ТЗ деталізує вимоги, межі, інформаційні дані, логіку, ролі, інтеграції, помилки, критерії приймання і тестові сценарії. # Нефункціональні вимоги. Технічне задача — це основа керованої розробки, впровадження, інтеграції або міграції. - Контрагент

платформа перевіряє фізичний залишок, резерв і доступну кількість.
Потрібно логувати:
=== Що таке технічне задача? ===
! # Майбутній бізнес-процес. # Що не входить у задачу.

Логування: усі запити і відповіді - Організація

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

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

Зробити звіт по продажах. Приклад для ERP: - Договір

T-001 Створити замовлення на товар із достатнім залишком Замовлення створено, товар зарезервовано
T-002 Створити замовлення на товар без залишку платформа показує попередження або заборону
T-003 Завантажити замовлення з сайту через API Замовлення створено в ERP з правильним external_id
T-004 Змінити залишок товару API передає новий доступний залишок на сайт 
Критерії приймання:

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

BAS ERP, база BAS_ERP_WORK. №

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

|- | обліковий облік залишків | Керівник складу | Логістика |- | Дебіторка | Фінансовий директор | фінансовий блок |- | ПДВ | провідний бухгалтер | бухгалтерський обліковий облік |- | API сайту | CTO | ІТ-відділ |- | Power BI | Керівник аналітики | BI-команда |}

- external_id. Фільтри: 

6. Це погоджений документ, за яким можна розробити рішення для бізнесу, протестувати його і прийняти роботу. # Описано майбутній бізнес-процес. Зробити обліковий облік товарів. # Описані звіти. {| class="wikitable" style="width:100%;"

* продуктивність;
* безпека;
* доступність;
* масштабованість;
* аудит;
* резервне копіювання;
* зручність;
* локалізація;
* сумісність;
* надійність. Які ролі мають доступ?

- Доступний залишок 

"date": "2026-05-15",

- кількість активних контрагентів; Замовник: Відділ логістики Можна для дуже маленьких задач, але для ERP, інтеграцій, міграції, звітів, прав доступу або бізнес-процесів це ризиковано. # Помилки і винятки. - Таблична частина товарів Головне. Технічне задача — це не “побажання в чаті” і не “зробіть як у нас в голові”. Критерій

SEO-опис майбутнього процесу

Назва і реліз системи ТЗ

- складський облік Приклад: 3. Відповідь

! користувач системи з роллю “Менеджер” здатна створити замовлення покупця. Авторизація: Bearer token

  • перелік інформаційних баз BAS;
  • реліз BAS;
  • конфігурація BAS;
  • організації;
  • контрагенти;
  • договори;
  • номенклатура;
  • склади;
  • залишки;
  • партії;
  • серії;
  • характеристики;
  • взаєморозрахунки;
  • банк;
  • ПДВ;
  • зарплата, якщо переноситься;
  • документи;
  • регістри;
  • зовнішні обробки;
  • інтеграції;
  • Power BI;
  • архів BAS;
  • контрольні звіти;
  • санкційні обмеження;
  • план відмови від BAS. Що здатна робити
- ІПН; Так. - Нове замовлення створюється в K2 ERP. "sku": "SKU-001", - Організація
  • впровадження ERP;
  • впровадження K2 ERP;
  • міграції з BAS або 1С;
  • створення нового модуля;
  • доробки існуючого модуля;
  • інтеграції з сайтом;
  • інтеграції з банком;
  • інтеграції з CRM;
  • інтеграції з WMS;
  • інтеграції через API;
  • інтеграції через JSON або XML;
  • створення звіту;
  • створення Power BI-дашборду;
  • зміни прав доступу;
  • автоматизації бізнес-процесу;
  • запуску документообігу;
  • створення імпорту або експорту;
  • розробки мобільного застосунку;
  • конфігурація обліку товарів;
  • розробки регламентної операції;
  • опису вимог до безпеки. ТЗ часто виступає як додатком до договору з підрядником. Для кожного довідника бажано описати обов’язкові поля. ]
- банківські рахунки;

Приклад JSON у ТЗ

Форма “Замовлення покупця”: - товарну групу; Для інтеграцій ТЗ має бути особливо точним. ! - період;

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

ТЗ має описувати, які довідники використовуються. Які бізнес-процеси зачіпаємо? Держспецзв’язку веде офіційний перелік забороненого до використання програмного забезпечення та комунікаційного обладнання, де згадуються продукти 1С/BAS, зокрема 1C:компанія-користувач 8 і BAS ERP. Приклад:

Частота: у момент створення замовлення

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

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

Отримувач: Приклади:

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

- адреси;

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

- Резерв

Audit log потрібен для безпеки, розслідування помилок і контролю відповідальності. }, } Приклади: Мета пояснює, навіщо виконується робота. Після підтвердження замовлення товар резервується. Призначення: передача замовлень покупців 
* показати форму;
* перевірити логіку;
* уточнити поля;
* отримати зворотний зв’язок;
* зменшити ризики;
* швидше погодити вимоги. !<syntaxhighlight lang="text">

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

[[Категорія:Функціональні вимоги]]

Менеджери перевіряють доступність товару вручну. # виступає як обробка помилок. Без критеріїв приймання незрозуміло, коли роботу можна вважати завершеною. Краще:

"quantity": 2,

Мета ТЗ

1. - Дата документа інтеграційні функції ERP: сайт → K2 ERP Як перевірити, що робота виконана правильно? - тестових контрагентів; - список дублікатів за ЄДРПОУ; - собівартість;

# виступає як audit log. "organization": "COMPANY_1",

Чим ТЗ відрізняється від опису задачі?

Якщо власника немає, вимогу складно погодити і прийняти. Власник Приклад:

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

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

Потрібен бізнес-процес change request:

Резерви не передаються на сайт. - контрагентів без руху за останні 5 років і без відкритого боргу;

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

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

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

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

</syntaxhighlight>

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

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

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

=== Чи потрібно в ТЗ описувати те, що не входить у задачу? ===

Без процесу змін будь-яке ТЗ оперативно втрачає актуальність. - Документ розрахунків
- Статус
{
<syntaxhighlight lang="text">

- спосіб доставки;

2. # Описані інтеграції. # Ролі і права доступу. №
[[Категорія:DBeaver]]
<syntaxhighlight lang="text">
! - валову маржу;

 "counterparty": {

- Сума

4. |-

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

- демо-записи. ! - відкриті взаєморозрахунки;

Отримано з https://wiki.kyiv.ua/index.php?title=Технічне_завдання&oldid=2052