Технічне завдання: Передача звітності з K2 ERP до Електронного кабінету ДПС
16.; Нефункціональні вимоги
=== 16.2.; Надійність ===
== 9.; Сценарій 1: ручне подання ==
</div>
{| class="wikitable"
== 19.; Етапи реалізації ==
{| class="wikitable"
=== 10.3.; Endpoint для відправки одного звіту ===
!Як зменшити
== 2.; Область сфера застосування ==
Метою задачі є собою розробка програмного забезпечення механізму передачі податкової звітності з K2 ERP до Електронного кабінету ДПС України.; |-
|Не прийнято
|Звіт відхилено ДПС.; !характеристика
=== 6.1.; Ручне подання звітності ===
}
!характеристика
|-
|K2 ERP
|ERP-система, з якої формується та передається формування звітів.; |}
=== 8.4.; Перевірка XML ===
=== 10.4.; Endpoint для пакетного подання ===
{| class="wikitable"
!Роль
!Параметр
|-
|API URL
|Базова адреса API ДПС.; |-
|Код ДПС
|Рядок
|Так
|Код контролюючого органу.; |}
Окремо варто відзначити підписання КЕП, шифрування, передачі через API і обробки квитанцій.; платформа повинна підтримувати підписання XML-документів за допомогою КЕП.; |-
|XML перевірено
|XML пройшов внутрішню перевірку.; |-
|Сформувати XML
|Генерує XML-файл.; # платформа запитує квитанції.; "contentBase64": "BASE64_ПІДПИСАНИЙ_ТА_ЗАШИФРОВАНИЙ_XML"
Мінімальні вимоги:
* використовувати актуальні сертифікати ДПС;
* перевіряти строк дії сертифікатів;
* шифрувати підписаний XML;
* формувати транспортний контейнер;
* кодувати результат у Base64;
* зберігати дату та результат шифрування.; |-
|Експортувати XML
|Завантажує XML-файл користувачу.; |-
|AC-4
|користувач системи експортує XML
|XML-файл завантажується на комп'ютер.; |-
|AC-8
|платформа перевіряє XML
|XML проходить XSD-перевірку.; |-
|Податковий номер
|Перевірити формат РНОКПП або ЄДРПОУ.;<pre>
|-
|Обов'язкові поля
|Перевірити, що всі обов'язкові реквізити заповнені.; |-
|Передано до ДПС
|Запит до API успішно виконано.;=== 9.4.; Статуси ручного сценарію ===
=== Етап 2.; Напівавтоматичний сценарій ===
* додавання нових форм звітності;
* актуалізація XSD-схем;
* додавання нових сценаріїв підписання;
* розширення списку API-методів;
* підтримку пакетної передачі.; |-
|Очікується квитанція №1
|платформа очікує первинну квитанцію.; |-
|Режим роботи
|Ручний або автоматизований.; |}
платформа повинна дозволяти:
{| class="wikitable"
До MVP входить:
<div style="border-left: 6px solid #2e7d32; background: #e8f5e9; padding: 12px 16px; margin: 16px 0;">
* вибір ключа користувачем;
* введення пароля до ключа;
* перевірка строку дії сертифіката;
* перевірка належності сертифіката платнику;
* підписання XML;
* збереження інформації про підписанта;
* журналювання факту підписання.; # платформа формує Base64-контейнер.; |-
|Квитанція №1 отримана
|ДПС підтвердила отримання документа.; |-
|Аудитор
|Перевіряє історію дій.; |-
|403
|Доступ заборонено.; |-
|Подано вручну
|користувач системи підтвердив ручне подання.; |-
|Помилка
|Етап, код, характеристика, користувач системи.; |-
|ФОП
|Самостійно формує та подає власну формування звітів.; |-
|Експортовано
|користувач системи завантажив XML.; # Чи потрібна супровід тільки ФОП, чи додатково юридичних осіб?; |Показувати текст помилки та дозволяти повторне формування.; |-
|Помилка КЕП
|Виникла помилка підписання.;Тип запиту:
== 23.; Див.; додатково == === 11.1.; Загальні вимоги === '''Головна ідея:''' реалізувати в K2 ERP два варіанти подання звітності до ДПС: ручний експорт XML для подальшого подання користувачем та автоматизовану передачу через API Електронного кабінету ДПС.; # Чи потрібно робити окрему роль для податкового консультанта?; |- |AC-12 |платформа відправляє звіт |API ДПС приймає запит.; |Перегляд, підписання, контроль статусів.;== 15.; конфігурація інтеграції == == 18. MVP ==
- XML не відповідає XSD;
- відсутній обов'язковий тег;
- неправильна структура XML;
- неправильне ім'я файлу;
- застосовується застаріла форма звіту.; |-
|Отримання квитанції |Тип квитанції, дата, статус.; |Використовувати актуальні сертифікати ДПС.; |- |Помилки КЕП |Можливі проблеми з ключами, паролями, сертифікатами.; |- |Шлях до ключа |Для файлового КЕП.; |- |Назва / ПІБ |Рядок |Так |Найменування юридичної особи або ПІБ ФОП.; |- |Позначити як подано вручну |Змінює статус документа після ручного подання.;=== 10.2.; Послідовність дій === Приклади:
- довідник платників податків у K2 ERP;
- реквізити ФОП або юридичної особи;
- код контролюючого органу ДПС;
- актуальні форми звітності;
- XSD-схеми для відповідних форм;
- правила іменування XML-файлів;
- механізм роботи з КЕП;
- актуальні сертифікати ДПС для шифрування;
- доступ до API Електронного кабінету ДПС.; # Обирає тип звіту.; |-
|AC-15 |платформа журналює дії |Усі етапи записані в журнал.;</div><div style="border-left: 6px solid #f57c00; background: #fff3e0; padding: 12px 16px; margin: 16px 0;"> </div>За замовчуванням пароль КЕП має вводитися користувачем під час підписання.;== 13.; Журналювання == платформа повинна підтримувати два сценарії: До MVP не входить:
"fname": "назва_файлу_згідно_правил_ДПС.xml",
<pre> |- |401 |Неавторизований запит.; |}
== 17. Acceptance Criteria == У K2 ERP має бути розроблена картка звіту.; # платформа отримує відповідь API.; [ випадків забезпечується через Ручний сценарій призначений; додатково реалізовано коли K2 ERP формує XML, але не передає його напряму до ДПС.; |- |AC-11 |платформа формує Base64 |Підготовлено тіло запиту для API.; # Чи є собою в K2 ERP існуючий компонент КЕП?; |- |Ім'я файлу |Перевірити відповідність правилам ДПС.; |- |Податковий номер |Рядок |Так |РНОКПП або ЄДРПОУ.; |- |КЕП |Кваліфікований електронний підпис.; |- |Логування |Рівень деталізації журналу.; |- |Відправка API |Endpoint, HTTP-код, час відповіді.;=== 6.3.; Отримання квитанцій ===
- автоматичне підписання КЕП;
- автоматичне шифрування;
- передача через API;
- автоматичне отримання квитанцій;
- пакетне подання.; До області задачі входить:
- формування XML-документів звітності;
- перевірка XML перед поданням;
- експорт XML для ручного подання;
- завантаження квитанцій вручну;
- підписання XML за допомогою КЕП;
- шифрування XML;
- передача звітності через API ДПС;
- отримання квитанцій;
- ведення статусів звіту;
- журналювання дій користувачів та системи.; # платформа завантажує XML-файл.; |-
|Формування XML |Дата, форма, реліз, результат.; |- |Зашифровано
|XML зашифровано для ДПС.;Логічна структура тіла запиту:
* даних платника;
* даних обліку в K2 ERP;
* вибраного звітного періоду;
* вибраної форми звітності;
* актуальної структури XML;
* правил ДПС щодо іменування файлів.; |}
Мінімальний набір полів:
== 20.; Ризики ==
* довідник платника;
* картка звіту;
* формування XML;
* базова перевірка XML;
* експорт XML;
* ручне завантаження квитанцій;
* статуси ручного сценарію;
* журнал дій.; |}
=== 6.4.; Контроль помилок ===
# Які форми звітності підтримуються першими?; |-
|AC-13
|платформа отримує квитанції
|Квитанції збережено в картці звіту.; |Додати перевірку сертифікатів до підписання.;== 8.; Функціональні блоки ==
=== 8.1.; Довідник платника податків ===
|-
|Створити звіт
|Створює нову картку звіту.; |конфігурація API, сертифікатів, ролей, журналів.; # Обирає звітний період.; # платформа зберігає ідентифікатор документа.; |-
|Готово до відправки
|Сформовано Base64-контейнер.; # користувач системи натискає '''Експортувати XML'''.; |-
|XML сформовано
|XML-файл створено.; |-
|Перевірка сертифіката
|Обов'язкова перед підписанням.; |-
|Timeout
|Перевищено час очікування відповіді.; |-
|Помилка шифрування
|Виникла помилка шифрування.; |-
|Відповідальна особа
|користувач системи
|Ні
|користувач системи, відповідальний за подання звітності.; |-
|Період
|Перевірити коректність звітного періоду.; |-
|XSD
|Схема перевірки структури XML-документа.; |-
|XML сформовано
|XML-документ створено.; |-
|XML-структура
|Перевірити наявність потрібних тегів.; # Чи потрібна супровід хмарного КЕП?; Автоматизований сценарій призначений для передачі звітності до ДПС без ручного завантаження XML у кабінет.; !характеристика
== 1.; Мета ==
* ключ не знайдено;
* неправильний пароль;
* сертифікат прострочено;
* сертифікат не відповідає платнику;
* користувач системи не має права підпису.; |-
|Група платника
|Довідник
|Ні
|Для ФОП на єдиному податку.; |-
|Завантажити квитанцію
|Додає квитанцію до картки звіту.; '''Заборонено:''' зберігати пароль КЕП у відкритому вигляді.; |-
|Підписано
|XML підписано КЕП.; |-
|Юридична особа
== 22.; Джерела ==
|}
=== 9.2.; Послідовність дій ===
У системі має бути довідник платника податків.; # Чи потрібно реалізовувати пакетне подання?; |-
|Керівник
|Підписує формування звітів.; # Створює новий звіт.;=== Етап 3.; Повна API-інтеграція ===
!Критерій
До першої версії має змогу не входити:
Як бухгалтер або ФОП, я хочу сформувати XML-файл звітності в K2 ERP, щоб завантажити його та самостійно подати через Електронний кабінет ДПС.; Як користувач системи K2 ERP, я хочу бачити квитанції ДПС безпосередньо в картці звіту, щоб контролювати, чи прийнята формування звітів.; |-
|КНЕДП
|Надавач електронних довірчих послуг.;== 11.; Вимоги до КЕП ==
!Очікуваний результат
* створити довідник платника;
* створити картку звіту;
* реалізувати формування XML;
* реалізувати перевірку XML;
* реалізувати експорт XML;
* реалізувати завантаження квитанцій;
* реалізувати ручні статуси;
* реалізувати журнал дій.; |-
|Зберігання пароля
|Заборонено за замовчуванням.; |Передбачити механізм актуалізація схем.; |Перегляд звітів, квитанцій, журналів.; |-
|Квитанція №1
|Підтвердження отримання документа контролюючим органом.; '''істотно:''' автоматизований сценарій потребує формування XML за актуальними XSD-схемами ДПС.; платформа повинна:
!Тип платника
!характеристика !№ |- |Зміна форм звітності |ДПС має змогу оновлювати форми та XSD.; |- |Очікується квитанція №2 |платформа очікує фінальну квитанцію.; # платформа формує XML.; |}
Приклади:
6.2.; Автоматизоване подання звітності
Приклади:
!Тип
!характеристика
- користувач системи відкриває розділ звітності.; !Код / тип
!Очікуваний результат
12.; Вимоги до шифрування
15.2.; конфігурація КЕП
17.2.; Автоматизований сценарій
!Ризик
Етап 1.; Ручний сценарій
!Термін
15.1.; конфігурація API
9.1.; характеристика
| |-- Формування звітних даних | |-- Генерація XML | |-- Перевірка XML / XSD | |-- Сценарій 1: ручний експорт | | | |-- користувач системи завантажує XML | |-- користувач системи подає XML через кабінет ДПС | |-- користувач системи завантажує квитанції в K2 ERP | |-- Сценарій 2: автоматизована передача | |-- Підписання КЕП |-- Шифрування |-- Передача через API ДПС |-- Отримання квитанцій |-- актуалізація статусу
!№
</syntaxhighlight>17.1.; Ручний сценарій
11.3.; Зберігання пароля
| Статус | Сценарій
21.; Відкриті питання
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|