Технічне завдання: Передача звітності з K2 ERP до Електронного кабінету ДПС
!Ризик
випадків забезпечується через Ручний сценарій призначений; так само реалізовано коли K2 ERP формує XML, але не передає його напряму до ДПС. |}
Приклади: платформа повинна формувати XML-документ на основі: !Сценарій
Етап 1. Ручний сценарій
|- |Тип КЕП |Файловий або хмарний. |- |AC-4 |користувач системи експортує XML |XML-файл завантажується на комп'ютер. |- |платформа оподаткування |Довідник |Так |Єдиний податок, загальна платформа, ПДВ тощо. # Обирає тип звіту. |Показувати текст помилки та дозволяти повторне формування. |- |Зашифровано |XML зашифровано для ДПС. # платформа перевіряє XML. |- |Період |Перевірити коректність звітного періоду. # платформа формує XML. |- |Інтервал опитування |Періодичність перевірки квитанцій. Автоматизований сценарій призначений для передачі звітності до ДПС без ручного завантаження XML у кабінет. { Перед експортом або відправкою платформа повинна виконати перевірку:
9. Сценарій 1: ручне подання
!Поле
6.4. Контроль помилок
|- |Створення звіту |користувач системи, дата, тип звіту, період. |- |Помилки КЕП |Можливі проблеми з ключами, паролями, сертифікатами. |- |Експортувати XML |Завантажує XML-файл користувачу. # Чи потрібно робити окрему роль для податкового консультанта? # Чи потрібно реалізовувати пакетне подання? # платформа запитує квитанції. |- |Позначити як подано вручну |Змінює статус документа після ручного подання. # Обирає звітний період. |}
</syntaxhighlight>- не заповнено обов'язкове поле;
- некоректний податковий номер;
- неправильний звітний період;
- відсутній код контролюючого органу;
- некоректний формат суми. |-
| Електронний кабінет | - | Timeout | - | Експортовано | }
Приклади: Приклади: </syntaxhighlight> Головна ідея: реалізувати в K2 ERP два варіанти подання звітності до ДПС: ручний експорт XML для подальшого подання користувачем та автоматизовану передачу через API Електронного кабінету ДПС. |- |
Помилка | - | Код ДПС | Рядок | Так | - | Очікується квитанція №2 | Перегляд, підписання, контроль статусів. |- | Помилка КЕП | - | XML перевірено | - | AC-5 | користувач системи додає квитанцію | - | XML | - | Код ДПС | Створення звіту, перевірка, експорт, підписання, відправка. Заборонено: зберігати пароль КЕП у відкритому вигляді. |- | Очікується квитанція №1 | - | XML-структура | } | Параметр
11. Вимоги до КЕП}
|
Квитанція №1 отримана | - | AC-15 | платформа журналює дії | - | Податковий номер | Рядок | Так | - | КНЕДП | - | AC-2 | користувач системи формує XML | - | Група платника | Довідник | Ні | Для ФОП на єдиному податку. !SEO-опис
|
Квитанція №1 отримана | - | Негативна квитанція | - | Логування | - | Режим роботи | - | Прийнято | }
10.5. Endpoint для отримання квитанцій18. MVP"encryptedId": "ІДЕНТИФІКАТОР_ДОКУМЕНТА" |
Як зменшити | Код / тип |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| API URL | - | AC-12 | платформа відправляє звіт | - | Сертифікати ДПС | Джерело актуальних сертифікатів. # платформа шифрує XML для ДПС.=== 10.6. Статуси автоматизованого сценарію ===
|
500 | - | Відповідальна особа | користувач системи | Ні | - | 2 | Автоматизований | - | Перевірка XML | - | Назва / ПІБ | Рядок | Так | Використовувати актуальні сертифікати ДПС. |Додати повторні спроби та журнал помилок. |- | Подано вручну | користувач системи підтвердив ручне подання. !SEO-опис
|
Підписання | - | AC-10 | платформа шифрує XML | - | AC-3 | користувач системи перевіряє XML | - | Отримання квитанції | - | Помилка API | }
20. Ризики"zipBase64": "BASE64_АРХІВ_ЗІ_ЗВІТАМИ" 13. Журналювання |
Критерій
Логічна структура тіла запиту:|-
|Адміністратор
|конфігурація API, сертифікатів, ролей, журналів. |-
|XSD
|Схема перевірки структури XML-документа. |-
|AC-8
|платформа перевіряє XML
|XML проходить XSD-перевірку. |-
|Потребує виправлення
|Звіт містить помилки. |-
|ДПС
|Державна податкова служба України. |-
|No receipt
|Квитанція ще не сформована. POST https://cabinet.tax.gov.ua/cabinet/public/api/exchange/reportzip
!№
</div>
!Основні права
|
|-- Формування звітних даних
|
|-- Генерація XML
|
|-- Перевірка XML / XSD
|
|-- Сценарій 1: ручний експорт
| |
| |-- користувач системи завантажує XML
| |-- користувач системи подає XML через кабінет ДПС
| |-- користувач системи завантажує квитанції в K2 ERP
|
|-- Сценарій 2: автоматизована передача
|
|-- Підписання КЕП
|-- Шифрування
|-- Передача через API ДПС
|-- Отримання квитанцій
|-- оновлення версій статусу
користувач системи самостійно подає файл через Електронний кабінет ДПС або інше офіційне ПЗ. |}
== 16. Нефункціональні вимоги ==
!SEO-опис
платформа повинна дозволяти:
* формування XML-документів звітності;
* перевірка XML перед поданням;
* експорт XML для ручного подання;
* завантаження квитанцій вручну;
* підписання XML за допомогою КЕП;
* шифрування XML;
* передача звітності через API ДПС;
* отримання квитанцій;
* ведення статусів звіту;
* журналювання дій користувачів та системи. # Хто відповідає за оновлення версій форм і XSD? |-
|Помилка шифрування
|Виникла помилка шифрування. {| class="wikitable"
платформа повинна:
{| class="wikitable"
{{SEO|title=Технічне завдання: Передача звітності з K2 ERP до Електронного кабінету ДПС|description=Технічне завдання на реалізацію ручного та автоматизованого сценарію передачі податкової звітності з K2 ERP до Електронного кабінету ДПС України.|keywords=K2 ERP, K2 Cloud ERP, ДПС, електронний кабінет, податкова звітність, API ДПС, КЕП, XML, квитанції, технічне завдання}}
До MVP входить:
{| class="wikitable"
=== 8.2. Картка звіту ===
== 14. Обробка помилок ==
платформа повинна:
!інформаційні дані журналу
=== 9.1. SEO-опис ===
У системі має бути довідник платника податків. |-
|Шлях до ключа
|Для файлового КЕП. # платформа оновлює статус звіту. |}
функції ERP застосовують, коли потрібно для підготовки та передачі податкової звітності з K2 ERP. |-
|Податковий номер
|Перевірити формат РНОКПП або ЄДРПОУ. |-
|Аудитор
|Перевіряє історію дій. # Чи виступає як в K2 ERP існуючий компонент КЕП? |-
|Зберігання пароля
|Заборонено за замовчуванням. |-
|Не прийнято
|Звіт відхилено ДПС. # платформа підписує XML. # Де зберігати XML та квитанції: БД, файлове сховище або DMS? |-
|AC-6
|користувач системи фіксує результат подання
|Статус звіту змінюється на відповідний.=== 10.4. Endpoint для пакетного подання ===
POST https://cabinet.tax.gov.ua/cabinet/public/api/exchange/kvt_by_id
До MVP не входить:
|-
|ФОП
|КЕП ФОП. |}
K2 ERP
=== 14.4. Помилки API ===
!SEO-опис
Для реалізації задачі необхідно мати:
!Перевірка
# користувач системи відкриває розділ звітності. |-
|Експорт XML
|користувач системи, дата, назва файлу. !SEO-опис
Content-Type: application/json
* створити довідник платника;
* створити картку звіту;
* реалізувати формування XML;
* реалізувати перевірку XML;
* реалізувати експорт XML;
* реалізувати завантаження квитанцій;
* реалізувати ручні статуси;
* реалізувати журнал дій. # Хто відповідає за оновлення версій сертифікатів ДПС?=== Етап 2. Напівавтоматичний сценарій ===
* даних платника;
* даних обліку в K2 ERP;
* вибраного звітного періоду;
* вибраної форми звітності;
* актуальної структури XML;
* правил ДПС щодо іменування файлів. |-
|Квитанція №2
|Фінальний результат обробки звітності: прийнято або не прийнято. |-
|Юридична особа
<pre>
|}
== 3. Передумови ==
== 5. Ролі користувачів ==
=== 8.4. Перевірка XML ===
</pre>
!Тип платника
=== 15.2. конфігурація КЕП ===
{| class="wikitable"
* використовувати актуальні сертифікати ДПС;
* перевіряти строк дії сертифікатів;
* шифрувати підписаний XML;
* формувати транспортний контейнер;
* кодувати результат у Base64;
* зберігати дату та результат шифрування.=== 6.3. Отримання квитанцій ===
"contentBase64": "BASE64_ПІДПИСАНИЙ_ТА_ЗАШИФРОВАНИЙ_XML"
* XML не відповідає XSD;
* відсутній обов'язковий тег;
* неправильна структура XML;
* неправильне ім'я файлу;
* застосовується для застаріла форма звіту. |-
|КЕП
|Кваліфікований електронний підпис. |Налаштовує інтеграцію та доступи. !№
* повна технічна підтримка всіх форм звітності;
* автоматичне оновлення версій всіх XSD-схем;
* технічна підтримка всіх КНЕДП;
* технічна підтримка всіх варіантів хмарного КЕП;
* повноцінний податковий календар. |Передбачити механізм оновлення версій схем. У цьому сценарії K2 ERP виконує:
{| class="wikitable"
{| class="wikitable"
{| class="wikitable"
== Див. 23. так само ==
|-
|Обов'язкові поля
|Перевірити, що всі обов'язкові реквізити заповнені. Як користувач системи K2 ERP, я хочу бачити квитанції ДПС безпосередньо в картці звіту, щоб контролювати, чи прийнята формування звітів. Метою задачі виступає як розробка програмного забезпечення механізму передачі податкової звітності з K2 ERP до Електронного кабінету ДПС України. |-
|Кількість повторів
|Максимальна кількість повторних спроб. # платформа перевіряє XML.=== 8.1. Довідник платника податків ===
{| class="wikitable"
!SEO-опис
=== 15.1. конфігурація API ===
[
!SEO-опис
!Кнопка
!Термін
!Параметр
== 19. Етапи реалізації ==
платформа повинна підтримувати два сценарії:
== 8. Функціональні блоки ==
== 4. Терміни та скорочення ==
|-
|Чернетка
|Звіт створено.=== 11.3. Зберігання пароля ===
POST https://cabinet.tax.gov.ua/cabinet/public/api/exchange/report
=== 17.1. Ручний сценарій ===
|-
|Створити звіт
|Створює нову картку звіту. # платформа формує XML.</pre>Логічна структура тіла запиту:<syntaxhighlight lang="json">
=== 11.1. Загальні вимоги ===
* довідник платників податків у K2 ERP;
* реквізити ФОП або юридичної особи;
* код контролюючого органу ДПС;
* актуальні форми звітності;
* XSD-схеми для відповідних форм;
* правила іменування XML-файлів;
* механізм роботи з КЕП;
* актуальні сертифікати ДПС для шифрування;
* доступ до API Електронного кабінету ДПС. # Натискає '''Сформувати XML'''. |-
|ФОП
|Самостійно формує та подає власну формування звітів. |Додати перевірку сертифікатів до підписання. |-
|Квитанція №1
|Підтвердження отримання документа контролюючим органом. Як бухгалтер або ФОП, я хочу передати формування звітів до ДПС напряму з K2 ERP, щоб не виконувати ручний експорт, підписання та завантаження звіту в кабінет ДПС. }
* додавання нових форм звітності;
* оновлення версій XSD-схем;
* додавання нових сценаріїв підписання;
* розширення списку API-методів;
* підтримку пакетної передачі. !Тип
=== 14.3. Помилки КЕП ===
=== 6.2. Автоматизоване подання звітності ===
== 12. Вимоги до шифрування ==
{| class="wikitable"
== 7. Загальний бізнес-процес ==
== 1. Мета ==
!Роль
У K2 ERP має бути розроблена картка звіту.</pre>Логічна структура тіла запиту:<syntaxhighlight lang="json">
* реалізувати відправку одного звіту через API;
* реалізувати пакетну відправку;
* реалізувати отримання квитанцій;
* реалізувати автоматичне оновлення версій статусів;
* додати повторні спроби;
* додати моніторинг помилок;
* додати адміністративну панель інтеграції. # платформа надсилає звіт через API ДПС. |-
|Шифрування
|Дата, сертифікат ДПС, результат. |-
|AC-11
|платформа формує Base64
|Підготовлено тіло запиту для API. |-
|AC-13
|платформа отримує квитанції
|Квитанції збережено в картці звіту. |-
|Керівник
|Підписує формування звітів. |-
|Некоректне шифрування
|Документ здатна бути відхилений через неправильний контейнер.=== 10.3. Endpoint для відправки одного звіту ===
=== 16.2. Надійність ===
* зберігати проміжні стани обробки;
* не втрачати XML після помилки API;
* дозволяти повторну відправку;
* не дублювати звіт без підтвердження користувача;
* фіксувати всі помилки в журналі.=== 6.1. Ручне подання звітності ===
!№
!SEO-опис
{| class="wikitable"
}
=== Етап 3. Повна API-інтеграція ===
== 22. Джерела ==
"fname": "назва_файлу_згідно_правил_ДПС.xml",
=== 10.1. SEO-опис ===
|-
|Тип платника
|Довідник
|Так
|ФОП або юридична особа. |-
|XML сформовано
|XML-документ створено. |-
|Не прийнято
|Отримано негативну квитанцію. # платформа оновлює статус звіту. |-
|XML перевірено
|XML пройшов перевірку. |-
|Недоступність API
|API ДПС здатна бути тимчасово недоступним. |-
|Перевірити
|Запускає перевірку XML. |-
|403
|Доступ заборонено. |-
|Таймаут
|Час очікування відповіді API. |Формування, підписання, подання, перегляд квитанцій. |-
|AC-9
|платформа підписує XML
|XML підписано КЕП. Картка звіту повинна містити:
До області задачі входить:
!Статус
6. User Story |
Критерій | ||||||||||||||||||||||
| AC-1 | користувач системи створює звіт | }
Технічне задача: Передача звітності з K2 ERP до Електронного кабінету ДПС8.3. Формування XML
|
Підписано | КЕП директора, бухгалтера, печатки. * ключ не знайдено;
|
1 | Ручний | - | AC-14 | платформа оновлює статус | - | Бухгалтер | Формує та подає формування звітів. До першої версії здатна не входити:
Як бухгалтер, я хочу бачити зрозумілий SEO-опис помилки, щоб оперативно виправити звіт і повторно подати його. |- |
Прийнято | - | Перевірка сертифіката | - | Ім'я файлу | }
Мінімальні вимоги:
|