Сервис для работы с заявками.
- Merchant - заказчик, участник
- Создание заявки
- Revoke заявки
- Manager - сотрудник компании
- Создание, Изменение, Принятие, Отклонение заявки
- Создание и просмотр комментариев
- Просмотр истории изменений заявки
- Заявка создается пользователем или менеджером, попадает в HellGate
- event попадает в Bustermaze
- Walker опрашивает Bustermaze создает, сохраняет заявку
- Manager просматривает актуальные заявки на UI и принимает решение по заявке (отклонить или принять)
- Walker получает событие c подтверждением обновляет (закрывает) заявку.
- Пользователь создает аккаунт и логинится.
- создается аккаунт в Keycloak
- заводится запись в HG с авто-принятой заявкой и тестовым магазином
- Пользователь создает заявку о создании магазина
- создается заявка в HG на создание магазина с указанными данными
- Manager - получает почтой документы от мерчанта. Добавляет в заявку:
- данные о договоре (legal agreement)
- категорию магазина
- contract template
- Manager принимает заявку
- Пользователь видит рабочий тестовый магазин
Есть методы для добавления комментария к конкретной заявки от имени менеджера Сейчас Комментарии могут оставлять и просматривать могут только пользователи PAPI. По сути это записи привязаннее к ClaimId + PartyId.
Есть история изменений Claim-а - (Actions). Они привязаные к ClaimId + PartyId и ведут историю изменений статуса, обновлений комментариев и т.д. Есть методы для просмотра истории изменения текущего claim-a
Все данные по claim-am хранятся в базе данных в виде
- partyId
- версия дамзели
- assigned user (пока не используется)
- сконвертированное в json представление modification unit-a
- атрибуты заявки (дата, claimId ...)
При запросе на получение заявок json конвертируется в thrift.
Thrift используется тот же что и в HG. Изменение структуры Claim в HG требует конвертации заявок в Walker
Либо перезаливку claim-ов.
При получениия события об обновлении claim-a
Предполагаемый процесс регистрации пользователя с Лендинга:
1. Мерчант попадет на Лендинг оставляет свои данные и генерируется письмо менеджеру RBKmoney
и заводится заявка в ZenDesk
2. Менеджер получив контакты пользователя связывается с ним и запрашивает документы по почте.
3. Менеджер регистрирует пользователя через Dashboard - заполняет данные и создавая магазин
4. Менеджер в PAPI заполняет недостающие поля - категория магазина, шаблон контракта, данные о договоре
5. Менеджер принимает заявку и магазин активируется.
6. Менеджер сбрасывает пароль через PAPI и мерчанту приход оповещение на почту (в теории должно быть кастомное письмо)
7. Мерчант при первом входе сбрасывает пароль и настраивает магазин
Обсуждения по лендингу, немного подробнее: https://github.com/rbkmoney/talks_summary/pull/49/files
- Предполагается что будет возможность назначать пользователеям заявки - как в Jira и просматривать "мои задачи".
- Для сохранения событий по изенению заявки нужно добавить передачу контекста через PAPI - почта и имя пользователя.
Неплохо было бы искать заявки по их содержимому - можно положить json содержимое changeset-оф в elasticsearch.
- Контракт мерчанта содержит ссылку на ContractTemplate
- ContractTemplate содержит ссылку на TermSetHierarchyObject
- TermSetHierarchyObject содержит набор из PaymentsServiceTerms
- PaymentsServiceTerms - содержит информацию о fee, холдах рефанда и прочее
При добвалении пользователся создается контракт с дефолтным темплейтом, либо с указанным в заяке Сейчас (вроде) нет возможности частично изменить PaymentsServiceTerms - только переписать все сразу, поэтому на данный момент для каждого мерчанта с другим процентом создается новый ContractTemplate.
- Для упрощения регистрации можно сделать автоматическое создание заявки с Лендинга и интеграция с Zendesk
- Позволить пользователям видеть комментарии к заявкам
- Позволить пользователям прикреплять документы к заявкам, а не пересылать их по почте