You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Бізнес дані

ТВ

Бізнес сценарії

Бізнес мета

Метою розробки -  створення окремого сервісу з можливістю взаємодію через АРІ що повертає альтернативну покращену версію лоту на основі інформації, внесеної у систему організатором.

Обґрунтування

Через те, що інформація про лот створюється організатором, якість опису лоту, його відображення на порталі та на сайтах майданчиків, залежить від спроможності організатора такий опис створити. Як наслідок, можуть використовуватись неякісні зображення (особливо в якості титульного), може використовуватись довга назва або неструктурований опис. 

При цьому зараз лоти з довгою назвою мають значимо кращий показник успішності. 

Розробка рішення дозволить:

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

Техічні вимоги

Технічні вимоги до введення тексту

На формі майданчика - В разі якщо будемо міняти і основний description

  1. надати користувачу поле description у форматі <textarea>;
  2. дозволити як ручне введення з переносами рядків (Enter), так і вставку тексту з Word.

У БД для альтернативних полів title та description:

  1. зберігати текст в полях metaInfo як звичайний текст (plain text) без змін і додаткового форматування

На фронті при відображенні:

  1. використовувати CSS-властивість white-space: pre-wrap для збереження переносів рядків;
  2. або виконувати заміну символів нового рядка \n на <br> при рендері - треба перевірити

  3. відображення нумерованих/не нумерованих списків

  4. відображення тексту bolt та italic
  5. Заголовки не використовуються

Загальна архітектура системи

Створюється окремий middleware-сервіс — “Система покращення опису лоту”, який працює як незалежний асинхронний компонент

Основні кроки роботи сервісу:

  1. ЦБД надсилає запит в сервіс з даними (title та description) по опублікованому аукціону в момент його оголошешення (datePublished).
  2. Система отримує вхідні дані (title, description) через API - ?.
  3. Проганяє їх через набір правил (регулярні вирази, форматування, валідація, ML-моделі).
  4. Формує альтернативні версії полів (titleAlt, descriptionAlt).
  5. Записує результат обробки даних полів (titleAlt, descriptionAlt) в metaInfo відповідної процедури.

Основні компоненти:

  1. Вхідний API сервісу покращення опису лоту (REST/HTTP).
  2. Модуль обробки текстів (форматування, правила побудови titleAlt, descriptionAlt).

Правила обробки:

  1. Робота з полями title та description
    1. Формування структурованих описів із переносами рядків і логічними блоками.
    2. Збереження змісту критично важливих даних (кадастровий номер, площа, адреса тощо).
    3. Генерація альтернативних полів: titleAlt та descriptionAlt.
    4. Контроль максимальної довжини назви та опису (з урахуванням встановленних обмежень ЦБД).
  2. Використання альтернативного тексту в інтерфейсах
    1. У шаблоні "Детальний опис" за замовчуванням відображається альтернативний текст (titleAlt, descriptionAlt), якщо він існує, з можливістю перемикання на оригінальний (title, description).
    2. Для інших шаблонів використовується значення полів title та description.
    3. Для протоколів завжди використовується значення полів title та description.


UseCase

Use Case 1. Відправка запиту на створення альтернативної версії полів через сервіс покращення опису лоту

Назва

Відправка запиту на створення альтернативної версії полів через сервіс покращення опису лоту

Актори

Системні: ЦБД (майданчик), Сервіс покращення опису лоту

Передумови

  1. Процедура опублікована в ЦБД

Основний хід подій (дій)

  1. Як тільки процедура публікується організатором в ЦБД, ЦБД відправляє запит в систему покращення опису лоту з полями title, description.
  2. Сервіс покращення опису лоту обробляє дані та генерує titleAlt, descriptionAlt.
  3. Сервіс записує результати опрацювання (значення полів  titleAlt, descriptionAlt) в metaInfo процедури.

Альтернативні шляхи, помилки, крайові випадки

  1. Система покращення опису лоту не створила альтернативні варіанти
  2. Система покращення опису лоту не відповідає

Результат (Постумови)

  1. Альтернативні значення titleAlt, descriptionAlt збережені  в metaInfo процедури.

Інші вимоги


Use Case 2. Відображення альтернативного опису на порталі/майданчику

Назва

Публікація процедури з використанням альтернативного опису на порталі/майданчику

Обґрунтування


Актори

Системні: ЕТМ (майданчик), Портал Prozorro.Sale

Передумови

  1. Існує процедура з полями title, description - в процедурі та titleAlt, descriptionAlt - в metaInfo

Основний хід подій (дій)

  1. Портал Prozorro.Sale використовує значення title/description для відображення в загальних списках та протоколах.
  2. У шаблоні "Детальний опис"
    1. на порталі ПП за замовченням відображаться альтернативна версія titleAlt/descriptionAlt 
    2. майданчику може відображатися або оригінальна версія або альтернативна (якщо це передбачено інтерфейсом).

Альтернативні шляхи, помилки, крайові випадки

  1. В разі відсутності полів titleAlt/descriptionAlt необхідно відображати значення з полів title/description без можливості перемикання на альтернативний текст

Результат (Постумови)

  1. Для користувачів порталу доступний альтернативний та основний title та description

Інші вимоги


Use Case 3. Перегляд лоту з можливістю перемикання між оригінальним та альтернативним описом

Назва

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

Обґрунтування


Актори

Основний: Учасник, гість порталу, Організатор.

Системні: Портал Prozorro.Sale, ЕТМ

Передумови

  1. Для лоту існують поля title/description та альтернативні titleAlt/descriptionAlt

Основний хід подій (дій)

  1. Користувач відкриває сторінку лоту в шаблоні "Детальний опис".
  2. Система перевіряє наявність titleAlt/descriptionAlt.
  3. Якщо альтернативний опис є — за замовчуванням відображається він.
  4. Користувачу доступний перемикач "Альтернативний / Оригінальний опис".
  5. При перемиканні інтерфейс оновлює відображувані поля без додаткових запитів до бекенду (якщо всі дані вже отримані)

Альтернативні шляхи, помилки, крайові випадки


Результат (Постумови)

Користувач має прозорий доступ до обох версій опису лоту

Інші вимоги


Use Case 4. Масова генерація альтернативних описів для існуючих лотів (в разі batch-обробки)

Назва

Масова генерація альтернативних описів для існуючих лотів (batch-обробка)

Обґрунтування


Актори

Основний: Адміністратор Prozorro.Sale або відповідальний аналітик.

Системні: Внутрішній сервіс/скрипт, Сервіс покращення опису лоту

Передумови

  1. Існує масив уже опублікованих або активних лотів без альтернативного опису

Основний хід подій (дій)

  1. Адміністратор ініціює масову обробку (через внутрішній інструмент або планове завдання).
  2. Система по черзі або пакетами відправляє дані лотів до сервісу покращення опису лоту.
  3. Сервіс повертає згенеровані titleAlt/descriptionAlt.
  4. Результати зберігаються у metaInfo лотів.
  5. Інтерфейси порталу/майданчиків автоматично починають використовувати альтернативні|jосновні описи в "Детальному описі" (за потреби — після додаткового схвалення)

Альтернативні шляхи, помилки, крайові випадки


Результат (Постумови)

Багато існуючих лотів отримують покращені описи без ручного втручання організаторів

Інші вимоги

Не робимо перегенерацію всіх старих  title/description тільки для тих на яких буде вчитись система

Use Case 5. Моніторинг та адміністрування сервісу покращення опису лоту

Назва

Моніторинг та адміністрування сервісу покращення опису лоту

Обґрунтування


Актори

Основний: Адміністратор / DevOps / Підтримка.

Системні: Сервіс покращення опису лоту, системи моніторингу

Передумови

  1. Сервіс покращення опису лоту розгорнутий у промисловому середовищі

Основний хід подій (дій)

  1. Адміністратор переглядає дашборди стану сервісу (доступність, час відповіді, кількість помилок).
  2. За потреби вмикає/вимикає окремі версії ruleset або інтеграцію для окремих майданчиків.
  3. Аналізує логи проблемних запитів та, за потреби, передає інформацію команді розробки

Альтернативні шляхи, помилки, крайові випадки


Результат (Постумови)

Сервіс покращення опису лоту підтримується у стабільному та контрольованому стані

Інші вимоги


  • No labels