Частина 1 "Початок роботи АТ "Прозорро.Продажі" - Видача ключів до тестового середовища

1. Подання запиту на інтеграцію – Майданчик подає запит на первинну взаємодію через форму на порталі АТ "Прозорро.Продажі"
2. Укладення договору на інтеграцію – Менеджер по роботі з майданчиками підписує договір про інтеграцію з майданчиком.
3. Створення каналу Slack – Менеджер по роботі з майданчиками створює канал в Slack, додає розробника та менеджмент майданчика, додає всі необхідні WF для якісної взаємодії з майданчиком та запускає WF "Отримання інтеграційного ключа"
4. Отримання технічної документації – Менеджер по роботі з майданчиками додає до Slack каналу посилання на технічну документацію (ТЗ процедур Swagger)
5. Подання запиту на інтеграційний ключ – Майданчик подає запит на отримання ключа до інтеграційного оточення через надання посилання на SD у розпочатому WF "Отримання ключа до оточення для розробки"
6. Надання інтеграційного ключа – DevOps команда виконує видачу ключів до інтеграційного оточення до всіх напрямків , коментуючи доступ в конфігураційному файлі вручну.
7. Оновлення статусу задачі DevOps команди– після переведення задачі в статус "Готово"/"Done" в канал майданчика та в канал відділу по роботі з майданчиками приходить повідомлення про видачу ключів майданчику до інтеграційного оточення.

Частина 2. Розробка майданчиком функціоналу
Частина 3. Акредитація та тестування + Видача ключа до продуктивного оточення

1. Подання запевнення про намір проходження акредитації:
   1. Майданчик подає запевнення про намір проходження акредитації
   2. Проходить 1-2-1 з менеджером по роботі з майданчиками
   3. Ознайомлення з внутрішньою документацією
2. Подача документів до МЮ:
   1. Майданчик підготовлює перелік документів для проходження акредитації
   2. Майданчик подає пакет документів до міністерства юстицій (далі МЮ)
   3. МЮ розглядає пакет документів та надає рішення
3. Подача доументів до АТ "Прозорро.Продажі"комісії:
   1. Надання майданчиком пакету документів з рішенням від МЮ через офіційну пошту(ел. та паперовий варіант)
   2. Перевірка юридичним відділом АТ "Прозорро.Продажі" пакету документів на наявність всього переліку
4. Розгляд комісією:
   1. Комісія проводить перевірку та рекомендує (або ні) майданчик до роботи в системі АТ"Прозорро.Продажі"
   2. Комісія видає протокол
5. Створення задачі на акредитацію – Менеджер по роботі з майданчиками створює задачу в системі (для виконання всіх дій по акредитації тощо)
6. Укладення договору на тестування – Менеджер по роботі з майданчиками підписує договір про тестування з майданчиком.
7. Оплата тестування – Майданчик оплачує тестування.
8. Початок майданчиком WF "Взаємодія для тестування функціоналу" – Майданчик починає WF через Slack
9. Перевірка наявності всіх документів для подачі заявки на тестування та тестовий ключ – Менеджер по роботі з майданчиками перевіряє та підтверджує через WF, чи всі необхідні документи присутні та наявна сплата за тестування.
10. Подача заявки на тестування – Майданчик створює заявку посилання в SD отриманому в WF "Взаємодія для тестування функціоналу"+"Видача ключа до тестового оточення". 
11. Перевірка створеного запиту на наявність усіх документів – Менеджер по роботі з майданчиками перевіряє зазначений перелік на тестування та підтведжує видачу змінивши виконавця задачі на QA команду (Т. Бондарчук).
12. Тестування – Проводиться тестування доступу з виданими ключами.
13. Завершення тестування:
    
    1. Якщо тестування успішне Команда QA закриває задачу на тестування в JIRA та інформують Менеджера по роботі з майданчиками.
       1. Команда QA надає draft висновку тестування менеджеру по роботі з майданчиками
       2. Менеджер по роботі з майданчиками дозаповнює інформацію про майданчик у висновку
       3. Начальник відділу ІТ підписує висновок про тестування або профільний член правління 
    2. Якщо тестування не успішне Команда QA не закриває задачу на тестування в JIRA але інформує Менеджера по роботі з майданчиками.
       1. Менеджер по роботі з майданчиками проводить опитування
14. Закриття акта виконаних робіт – Команда по роботі з майданчиками інформує відділ бухгалтерського обліку про завершення робіт.
15. Укладення договору про використання ЕТС – Менеджер по роботі з майданчиками укладає договір із майданчиком.
16. Початок майданчиком WF "Отримання продуктивного ключа" – Майданчик подає запит на отримання ключа до продуктивного оточення через WF "Отримання продуктивного ключа".
17. Перевірка наявності всіх документів для подачі заявки на прод ключі– Менеджер по роботі з майданчиками перевіряє та підтверджує через WF, чи всі необхідні документи присутні.
18. Подання запиту на продуктивний ключ – Майданчик подає запит на отримання ключа до продуктивного оточення через заповнення форми SD у розпочатому WF "Отримання продуктивного ключа"
19. Перевірка створеного запиту на наявність усіх документів – Менеджер по роботі з майданчиками перевіряє зазначений перелік доступів та підтведжує видачу змінивши виконавця задачі на DevOps команду (П. Кузьменко).
20. Надання ключів до продуктивного оточення – DevOps команда виконує видачу ключа з доступами зазначеними в задачі, коментуючи доступ в конфігураційному файлі вручну.
21. Оновлення статусу задачі DevOps команди– після переведення задачі в статус "Готово"/"Done" в канал майданчика приходить повідомлення про видачу ключів майданчику до продуктивного оточення .
22. Створення заявки на відділ маркетингу – після надходження повідомлення про надання продуктивних ключей майданчику менеджер по роботі з майданчиками створює задачу на контент менеджера для додавання логотипу майданчика на портал та до каталогу.
23. Оновлення інформації на порталі – Контент менеджер додає логотип майданчика на портал та до каталогу і переводить задачу в термінальний стан ("Готово"/"Done") та інформує відділ по роботі з майданчиками.
24. Повідомлення BI – Менеджер по роботі з майданчиками інформує РО (Андрія Салія) про необхідність внесення змін до аналітичної звітності в BI-системі.
25. Оновлення статусу задачі – після виконання всіх дій і домовленостей по основній задачі, менеджер по роботі з майданчиками переводить задачу в термінальний стан ("Готово"/"Done")

Частина 5. Розробка майданчиком додаткового функціоналу

Частина 6. Тестування розширеного функціоналу

1. Початок майданчиком WF "Взаємодія для тестування функціоналу" – Майданчик починає WF через Slack
2. Визначення майданчиком типу тестуввання – Майданчик обирає який тип тестування майданчику необхідний
   
   1. Обрано тип "Тестування нової напрямку/процедури" +вказується напрямок/процедура
      1. Менеджер по роботі з майданчиками перевіряє та підтверджує через WF, чи всі необхідні документи присутні.
      2. Майданчик створює заявку посилання в SD в WF "Взаємодія для тестування функціоналу"
      3. Менеджер по роботі з майданчиками перевіряє зазначений перелік на тестування та підтведжує видачу змінивши виконавця задачі на QA команду (Т. Бондарчук)
      4. Тестування зазначеного функціоналу
      5. Команда QA закриває задачу на тестування в Jira після чого в канал майданчика приходить повідомлення про завершення тестування
      6. Майданчик подає запит на отримання ключа до продуктивного оточення через WF "Розширення продуктивного ключа"
   2. Обрано тип "Тестування існуючого напрямку/процедури"+вказується напрямок/процедура
      1. Менеджер по роботі з майданчиками перевіряє та підтверджує через WF, чи всі необхідні документи присутні.
      2. Майданчик створює заявку посилання в SD в WF "Взаємодія для тестування функціоналу"
      3. Тестування зазначеного функціоналу
      4. Команда QA закриває задачу на тестування в Jira після чого в канал майданчика приходить повідомлення про завершення тестування
      5. Майданчик подає запит на отримання ключа до продуктивного оточення через WF "Розширення продуктивного ключа"
   3. Обрано тип "Тестування функціоналу відповівдно до задачі"
      1. Майданчик створює заявку посилання в SD в WF "Взаємодія для тестування функціоналу"
      2. Тестування зазначеного функціоналу
      3. Команда QA закриває задачу на тестування в Jira після чого в канал майданчика приходить повідомлення про завершення тестування

Частина 7. Розширення дозволів на продуктивне оточення

1. Подання запиту на ключ – Майданчик подає запит на розширення ключа до продуктивного оточення через WF "Розширення дозволів на Прод оточення".
2. Перевірка створеного запиту на наявність всіх документів – Менеджер по роботі з майданчиками підтверджує проходження тестування та наявність договорів за протестованим функціоналом з майданчиком змінивши виконавця задачі на DevOps команду (П. Кузьменко).
3. Розширення дозволів ключа до продуктивного оточення – DevOps команда виконує розширення дозволів ключа відповідно до зазначених задачі, коментуючи доступ в конфігураційному файлі вручну.
4. Оновлення статусу задачі DevOps команди– після переведення задачі в статус "Готово"/"Done" в канал майданчика надходить повідомлення про видачу ключів майданчику до продуктивного оточення .

Частина 8. Блокування майданчиків на всіх ототченнях / Обмеження дозволів 

1. Офіційний лист/виявлення порушення – Якщо майданчик ініціює вихід , подається офіційний лист про розірвання договору (на основі завершення співпраці чи фінансових причин). Якщо ж є порушення, то питання ініціюється з нашого боку.
2. Створення завдання – Менеджер по роботі з майданчиками створює задачу в системі та тегає Тараса Бондарчука (приклад: SBM-1046 - Аутентификация для просмотра подробных данных проблемы ) для подальшого виконання.
3. Юридична перевірка – Юридичний відділ проводить перевірку обґрунтованості вимоги та підтверджує її.
4. Офіційне підтвердження – Наказ про припинення/обмеження доступу (видається юридичним відділом або менеджером по роботі з майданчиками); у разі власного бажання – розірвання договору.
5. Інформування бухгалтерії – Бухгалтерія інформується про припинення доступу майданчику.
6. Оцінка на наявність активних об'єктів – Визначає подальший шлях чи це блокування чи обмеження ключів
7. Якщо всі взаємодії завершено - відбувається блокування ключів
   1. Створення заявки на DevOps – Менеджер по роботі з майданчиками створює задачу через SD на DevOps команду
   2. Виконання блокування – DevOps команда виконує блокування, коментуючи доступ в конфігураційному файлі вручну.
   3. Оновлення статусу задачі DevOps команди– після переведення задачі в статус "Готово"/"Done" в канал майданчика та в канал відділу по роботі з майданчиками приходить повідомлення про блокування доступу майданчику.
   4. Створення заявки на відділ маркетингу – після надходження повідомлення про блокування доступу майданчику менеджер по роботі з майданчиками створює задачу на контент менеджера для видалення логотипу майданчика з порталу та з каталогу.
   5. Оновлення інформації на порталі – Контент менеджер видаляє логотип майданчика з порталу та з каталогу і переводить задачу в термінальний стан ("Готово"/"Done") та інформує відділ по роботі з майданчиками.
   6. Повідомлення BI – Менеджер по роботі з майданчиками інформує РО (Андрія Салія) про необхідність внесення змін до аналітичної звітності в BI-системі.
   7. Оновлення статусу задачі на юр відділ – після надходження повідомлення про видалення логотипу майданчика з порталу та з каталогу та інформування PO, менеджер по роботі з майданчиками переводить задачу в термінальний стан ("Готово"/"Done").
8. Якщо присутні обмеження, які не дозволяють повне блокування ключів - відбувається обмеження дозволів 
   1. Створення заявки на DevOps – Менеджер по роботі з майданчиками створює задачу через SD на DevOps команду
   2. Виконання блокування – DevOps команда виконує обмеження доступів ключа згідно задачі, коментуючи доступ в конфігураційному файлі вручну.
   3. Оновлення статусу задачі DevOps команди– після переведення задачі в статус "Готово"/"Done" в канал майданчика та в канал відділу по роботі з майданчиками приходить повідомлення про обмеження доступу майданчику.
   4. Створення заявки на відділ маркетингу – після надходження повідомлення про блокування доступу майданчику менеджер по роботі з майданчиками створює задачу на контент менеджера для видалення логотипу майданчика з порталу та з каталогу.
   5. Оновлення інформації на порталі – Контент менеджер видаляє логотип майданчика з порталу та з каталогу і переводить задачу в термінальний стан ("Готово"/"Done") та інформує відділ по роботі з майданчиками.
   6. Повідомлення BI – Менеджер по роботі з майданчиками інформує РО (Андрія Салія) про необхідність внесення змін до аналітичної звітності в BI-системі.
   7. Оновлення статусу задачі на юр відділ – після надходження повідомлення про видалення логотипу майданчика з порталу та з каталогу та інформування PO, менеджер по роботі з майданчиками переводить задачу в термінальний стан ("Готово"/"Done")

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