2791 lines
128 KiB
Typst
2791 lines
128 KiB
Typst
#set document(title: "Техническое задание на разработку программного продукта")
|
||
#set page(
|
||
paper: "a4",
|
||
margin: (left: 20mm, right: 18mm, top: 18mm, bottom: 18mm),
|
||
numbering: "1",
|
||
header: none,
|
||
footer: none,
|
||
)
|
||
#set text(font: "Times New Roman", size: 10.5pt, lang: "ru")
|
||
#set par(justify: true, leading: 0.58em, first-line-indent: 0pt)
|
||
#set list(indent: 13pt, body-indent: 5pt)
|
||
#set heading(numbering: "1.1")
|
||
#show link: underline
|
||
#show raw: set text(font: "Times New Roman")
|
||
#show heading.where(level: 1): set text(size: 16pt, weight: "bold")
|
||
#show heading.where(level: 2): set text(size: 13pt, weight: "bold")
|
||
#show heading.where(level: 3): set text(size: 11.5pt, weight: "bold")
|
||
#show heading: it => {
|
||
if it.level == 1 {
|
||
pagebreak(weak: true)
|
||
}
|
||
block(above: 1.15em, below: 0.55em, it)
|
||
}
|
||
|
||
#v(1fr)
|
||
|
||
#align(center)[
|
||
#text(size: 16pt, weight: "bold")[Техническое задание]
|
||
|
||
#v(2mm)
|
||
#text(size: 16pt, weight: "bold")[на разработку программного продукта]
|
||
|
||
#v(2mm)
|
||
#text(size: 16pt, weight: "bold")[«Личный кабинет Фрегат»]
|
||
]
|
||
|
||
#v(1fr)
|
||
|
||
#align(center)[
|
||
#table(
|
||
columns: (40%, 60%),
|
||
stroke: rgb("#d0d7de"),
|
||
inset: 6pt,
|
||
[Заказчик], [ООО «Фрегат Групп»],
|
||
[Исполнитель], [ИП Бакиев Р.Ш.],
|
||
[Основание], [Договор №28/04-26ПО от 28.04.2026],
|
||
)
|
||
]
|
||
|
||
#v(8mm)
|
||
|
||
#pagebreak()
|
||
|
||
#set page(
|
||
paper: "a4",
|
||
margin: (left: 20mm, right: 18mm, top: 18mm, bottom: 18mm),
|
||
numbering: "1",
|
||
header: align(right)[#text(size: 8pt, fill: rgb("#667085"))[Приложение к договору №28/04-26ПО]],
|
||
footer: align(center)[#text(size: 8pt, fill: rgb("#667085"))[#context counter(page).display("1")]],
|
||
)
|
||
|
||
#outline(title: [Содержание], depth: 2, indent: auto)
|
||
|
||
#pagebreak()
|
||
|
||
|
||
= Общие положения
|
||
|
||
|
||
Настоящее техническое задание описывает разработку программного продукта Личный кабинет Фрегат.
|
||
|
||
Документ фиксирует назначение продукта, границы разработки, основные пользовательские контуры, функциональные и технические требования, порядок выполнения работ, приемки и гарантийного сопровождения.
|
||
|
||
== Основание для разработки
|
||
|
||
|
||
Разработка программного продукта выполняется на основании следующих документов и материалов:
|
||
|
||
- договор на разработку программного продукта №28/04-26ПО от 28 апреля 2026 года
|
||
- приложение №1 к договору: спецификация основных требований к программному обеспечению Личный кабинет Фрегат
|
||
- согласованные требования заказчика к клиентскому, менеджерскому, бонусному и интеграционному контурам
|
||
|
||
== Назначение продукта
|
||
|
||
|
||
Программный продукт предназначен для организации единого цифрового канала взаимодействия между ООО Фрегат Групп и B2B-клиентами компании.
|
||
|
||
Продукт должен объединять клиентский, менеджерский, административный и интеграционный контуры в единой веб-системе. Подробный состав функций, ролей, данных, интерфейсов и интеграций установлен в последующих разделах настоящего технического задания.
|
||
|
||
Объектом автоматизации являются процессы клиентского обслуживания и внутренней обработки заявок, выполняемые менеджерами ООО Фрегат Групп при работе с готовой и индивидуальной продукцией.
|
||
|
||
== Границы продукта
|
||
|
||
|
||
В состав программного продукта входят:
|
||
|
||
- клиентский веб-интерфейс
|
||
- менеджерский веб-интерфейс
|
||
- административный контур суперменеджера
|
||
- серверная бизнес-логика
|
||
- база данных
|
||
- модуль синхронизации с внешними системами
|
||
- модуль уведомлений
|
||
- модуль бонусной программы
|
||
- модуль административных настроек
|
||
|
||
Программный продукт не предназначен для выполнения следующих функций:
|
||
|
||
- самостоятельного ценообразования клиентом
|
||
- ведения бухгалтерского учета
|
||
- выполнения функций публичного B2C-магазина
|
||
- прямого редактирования клиентом внутренних бизнес-правил компании
|
||
- замены учетной системы 1С как первичного источника учетных данных
|
||
|
||
== Пользовательские контуры
|
||
|
||
|
||
В системе должны быть предусмотрены следующие пользовательские контуры:
|
||
|
||
- клиентский контур
|
||
- менеджерский контур
|
||
- административный контур суперменеджера
|
||
|
||
Клиентский контур предназначен для работы клиента с каталогом, заявками, заказами, уведомлениями и бонусным кабинетом.
|
||
|
||
Менеджерский контур предназначен для обработки клиентских заявок, публикации коммерческих условий, сопровождения заказов, работы с клиентскими карточками и бонусными операциями.
|
||
|
||
Административный контур предназначен для управления настройками каталога, уведомлений, интеграционных параметров и отдельных сервисных настроек системы.
|
||
|
||
== Основные принципы работы
|
||
|
||
- доступ к функциям и данным определяется ролью пользователя
|
||
- клиент работает только в пределах собственных данных и данных своего контрагента
|
||
- стоимость товара и условия поставки публикуются только после обработки менеджером
|
||
- история изменений по заявкам, заказам и бонусным операциям фиксируется в системе
|
||
- сведения о товарах, остатках, заказах и статусах могут обновляться из внешней учетной системы
|
||
|
||
= Функциональные требования
|
||
|
||
|
||
== Требования к подключению клиентов
|
||
|
||
|
||
Система должна поддерживать подключение клиента только по инициативе менеджера:
|
||
|
||
- менеджер создает или выбирает карточку клиента и привязывает ее к контрагенту
|
||
- менеджер направляет клиенту персональное приглашение на электронную почту
|
||
- клиент завершает подключение по персональной ссылке из письма
|
||
|
||
Функциональные требования:
|
||
|
||
+ Менеджер должен иметь возможность направить клиенту приглашение на подключение по электронной почте.
|
||
+ Менеджер должен иметь возможность связать приглашение с контрагентом, полученным из 1С либо заведенным для клиентской работы.
|
||
+ Клиент должен иметь возможность завершить подключение по персональной ссылке.
|
||
+ После завершения подключения клиент должен получить доступ к личному кабинету.
|
||
+ Публичная страница входа не должна содержать самостоятельную регистрацию или самостоятельную заявку на подключение.
|
||
+ Система должна поддерживать подключение доступных каналов уведомлений для клиентской учетной записи.
|
||
|
||
== Требования к каталогу готовой продукции
|
||
|
||
|
||
Система должна предоставлять клиенту каталог готовой продукции без отображения цены до обработки менеджером.
|
||
|
||
Функциональные требования:
|
||
|
||
+ Система должна отображать список товарных направлений.
|
||
+ Для каждого товарного направления система должна предоставлять отдельную карточку товара.
|
||
+ В карточке товара система должна отображать параметры выбора, применимые к данному типу продукции.
|
||
+ В карточке товара система должна отображать доступные стандартные варианты.
|
||
+ Для каждой доступной позиции система должна отображать складские остатки.
|
||
+ Система должна позволять клиенту выбрать параметры и добавить позицию в корзину.
|
||
+ Система должна исключать отображение стоимости до момента публикации условий менеджером.
|
||
+ Для параметров товара система должна отображать пояснения, помогающие клиенту понять назначение параметра и ограничения выбора.
|
||
|
||
== Требования к параметрам каталога и кастомизации
|
||
|
||
|
||
Система должна поддерживать настройку параметров по каждому товарному направлению.
|
||
|
||
Функциональные требования:
|
||
|
||
+ Для каждого типа продукции должен задаваться перечень стандартных параметров выбора.
|
||
+ Для параметров длины должна поддерживаться настройка доступных стандартных значений.
|
||
+ Для параметров длины должна поддерживаться возможность индивидуального значения при наличии соответствующего разрешения.
|
||
+ Для параметров втулки должна поддерживаться возможность заказа втулки с логотипом при наличии соответствующего разрешения.
|
||
+ Для параметров надписи должна поддерживаться возможность заказа индивидуального нанесения при наличии соответствующего разрешения.
|
||
+ Наборы стандартных параметров должны редактироваться в административном контуре.
|
||
+ Изменение набора стандартных параметров не должно приводить к потере уже сохраненных заказных данных.
|
||
|
||
== Требования к корзине и заявке на заказ
|
||
|
||
|
||
Система должна позволять клиенту собрать корзину и направить заявку на заказ.
|
||
|
||
Функциональные требования:
|
||
|
||
+ Клиент должен видеть перечень выбранных позиций.
|
||
+ Для каждой позиции клиент должен иметь возможность изменить количество.
|
||
+ Клиент должен иметь возможность удалить позицию из корзины.
|
||
+ Клиент должен иметь возможность направить заявку менеджеру.
|
||
+ После отправки заявки система должна зафиксировать состав, параметры и количество позиций.
|
||
+ Для заявки должны сохраняться дата создания, инициатор и закрепленный менеджер.
|
||
+ До обработки менеджером стоимость в заявке не должна отображаться клиенту.
|
||
|
||
== Требования к обработке заявки менеджером
|
||
|
||
|
||
Менеджер должен иметь возможность обработать клиентскую заявку вручную.
|
||
|
||
Функциональные требования:
|
||
|
||
+ Менеджер должен видеть состав заявки и параметры заказанных позиций.
|
||
+ Менеджер должен видеть карточку клиента и сведения о контрагенте.
|
||
+ Менеджер должен иметь возможность указать стоимость.
|
||
+ Менеджер должен иметь возможность указать условия поставки и доставки.
|
||
+ Менеджер должен иметь возможность оставить комментарий к заявке.
|
||
+ Менеджер должен иметь возможность опубликовать согласованные условия клиенту.
|
||
+ До перевода заявки в работу менеджер должен иметь возможность скорректировать опубликованные условия.
|
||
+ Менеджер должен иметь возможность перевести заявку в работу.
|
||
+ Менеджер должен иметь возможность отменить заявку с фиксацией основания отмены.
|
||
|
||
== Требования к заявке на расчет индивидуальной продукции
|
||
|
||
|
||
Система должна поддерживать отдельный сценарий расчета продукции с индивидуальными параметрами.
|
||
|
||
Функциональные требования:
|
||
|
||
+ Клиент должен иметь возможность перейти из каталога в сценарий расчета индивидуальной продукции.
|
||
+ Клиент должен иметь возможность указать параметры изделия.
|
||
+ Клиент должен иметь возможность приложить комментарий к заявке.
|
||
+ Клиент должен иметь возможность направить заявку менеджеру.
|
||
+ Менеджер должен иметь возможность обработать такую заявку по правилам, аналогичным заявке на заказ.
|
||
+ Стоимость и условия поставки должны публиковаться клиенту только после ручной обработки менеджером.
|
||
|
||
Минимальный состав параметров расчетной заявки должен поддерживать:
|
||
|
||
- тип продукции
|
||
- ширину
|
||
- длину
|
||
- толщину
|
||
- цвет
|
||
- надпись или маркировку
|
||
- иные параметры в зависимости от вида продукции
|
||
- текстовый комментарий клиента
|
||
|
||
== Требования к статусам заявок
|
||
|
||
|
||
Система должна обеспечивать сквозное сопровождение заявок по статусам.
|
||
|
||
Для заявок на заказ и заявок на расчет должны поддерживаться следующие базовые статусы:
|
||
|
||
- создана
|
||
- направлена менеджеру
|
||
- обработана менеджером
|
||
- условия опубликованы
|
||
- в работе
|
||
- отменена
|
||
|
||
Для каждого изменения статуса система должна сохранять:
|
||
|
||
- предыдущее состояние
|
||
- новое состояние
|
||
- дату и время изменения
|
||
- пользователя или источник, выполнивший изменение
|
||
- комментарий, если он предусмотрен сценарием
|
||
|
||
== Требования к заказам и их сопровождению
|
||
|
||
|
||
Система должна предоставлять клиенту и менеджеру доступ к списку заказов, карточке каждого заказа и актуальным учетным сведениям, полученным из 1С.
|
||
|
||
Функциональные требования:
|
||
|
||
+ Система должна отображать перечень заказов клиента.
|
||
+ Система должна поддерживать фильтрацию заказов по периоду и статусу.
|
||
+ Для каждого заказа система должна предоставлять отдельную карточку.
|
||
+ В карточке заказа должны отображаться состав, статус, стоимость, условия поставки и история изменений.
|
||
+ В карточке заказа должна отображаться дата актуальности данных.
|
||
+ При наличии обновлений из внешней системы сведения по заказу должны синхронизироваться и отображаться пользователю.
|
||
+ Система должна отображать текущую задолженность клиента, если такие сведения получены из 1С.
|
||
+ Для задолженности должна отображаться дата актуальности данных.
|
||
|
||
== Требования к уведомлениям
|
||
|
||
|
||
Система должна поддерживать уведомления по нескольким каналам связи.
|
||
|
||
Поддерживаемые каналы:
|
||
|
||
- электронная почта
|
||
- Telegram
|
||
- Max
|
||
|
||
Система должна поддерживать уведомления по следующим событиям:
|
||
|
||
- приглашение к подключению
|
||
- публикация условий по заявке
|
||
- изменение статуса заказа
|
||
- изменение бонусного баланса
|
||
- обработка заявки на использование либо вывод бонусов
|
||
|
||
== Требования к бонусной и реферальной программе
|
||
|
||
|
||
Система должна включать бонусный контур как самостоятельную функциональную область с отдельным пользовательским интерфейсом.
|
||
|
||
Функциональные требования:
|
||
|
||
+ Система должна хранить правила участия клиента в бонусной программе.
|
||
+ Система должна поддерживать фиксацию реферальных связей.
|
||
+ Система должна хранить начисления, списания и текущий остаток бонусов.
|
||
+ Клиент должен видеть текущий бонусный баланс.
|
||
+ Клиент должен видеть историю бонусных операций.
|
||
+ Клиент должен иметь возможность использовать бонусы в пределах установленных правил.
|
||
+ Клиент должен иметь возможность подать заявку на вывод либо иную операцию, если это предусмотрено правилами программы.
|
||
+ Менеджер должен иметь возможность обрабатывать операции бонусного контура.
|
||
+ Система должна уведомлять клиента об изменениях бонусного состояния.
|
||
|
||
== Требования к административным настройкам
|
||
|
||
|
||
Система должна содержать административные разделы для управления следующими объектами:
|
||
|
||
- параметрами каталога
|
||
- пользовательскими описаниями параметров
|
||
- шаблонами уведомлений
|
||
- параметрами синхронизации
|
||
- отдельными настройками бонусного контура
|
||
|
||
= Требования к ролям и правам доступа
|
||
|
||
|
||
== Состав ролей
|
||
|
||
|
||
В системе должны быть предусмотрены следующие роли пользователей:
|
||
|
||
- клиент
|
||
- менеджер
|
||
- суперменеджер
|
||
|
||
== Роль клиента
|
||
|
||
|
||
Пользователь с ролью Клиент представляет организацию-контрагента и работает только с данными своей компании.
|
||
|
||
Клиенту должны быть доступны следующие действия:
|
||
|
||
- завершение подключения по персональному приглашению
|
||
- просмотр и изменение разрешенных профильных данных
|
||
- подключение доступных каналов уведомлений
|
||
- просмотр каталога готовой продукции
|
||
- выбор параметров товара
|
||
- добавление позиций в корзину
|
||
- отправка заявки на заказ
|
||
- отправка заявки на расчет
|
||
- просмотр списка заявок и заказов
|
||
- просмотр карточки заявки и карточки заказа
|
||
- просмотр истории уведомлений
|
||
- просмотр бонусного баланса и истории бонусных операций
|
||
- подача заявки на использование либо вывод бонусов при наличии соответствующих правил
|
||
|
||
== Роль менеджера
|
||
|
||
|
||
Пользователь с ролью Менеджер представляет сотрудника компании, закрепленного за клиентами.
|
||
|
||
Менеджеру должны быть доступны следующие действия:
|
||
|
||
- создание или выбор клиентской карточки
|
||
- привязка клиента к контрагенту и назначение ответственного сопровождения
|
||
- отправка персонального приглашения клиенту
|
||
- просмотр и обработка заявок на заказ
|
||
- просмотр и обработка заявок на расчет
|
||
- указание стоимости, условий поставки и сопроводительного комментария
|
||
- публикация условий клиенту
|
||
- перевод заявки в работу
|
||
- отмена заявки при наличии оснований
|
||
- просмотр карточек клиентов, заявок и заказов
|
||
- выполнение операций в бонусном контуре в пределах полномочий
|
||
|
||
== Роль суперменеджера
|
||
|
||
|
||
Пользователь с ролью Суперменеджер обладает всеми правами менеджера и дополнительными административными полномочиями.
|
||
|
||
Суперменеджеру должны быть доступны следующие действия:
|
||
|
||
- доступ ко всем клиентам, заявкам и заказам
|
||
- управление параметрами каталога
|
||
- управление описаниями и наборами параметров товаров
|
||
- управление настройками уведомлений
|
||
- управление параметрами интеграции и синхронизации
|
||
- расширенное управление бонусным и реферальным контуром
|
||
|
||
== Матрица доступа
|
||
|
||
|
||
#text(size: 7.6pt)[
|
||
#table(
|
||
columns: (1fr, 1fr, 1fr, 1fr),
|
||
stroke: rgb("#d0d7de"),
|
||
inset: 4pt,
|
||
align: horizon + left,
|
||
[*Действие*],
|
||
[*Клиент*],
|
||
[*Менеджер*],
|
||
[*Суперменеджер*],
|
||
[Завершение подключения],
|
||
[Да],
|
||
[Нет],
|
||
[Нет],
|
||
[Отправка приглашения клиенту],
|
||
[Нет],
|
||
[Да],
|
||
[Да],
|
||
[Просмотр каталога],
|
||
[Да],
|
||
[Да],
|
||
[Да],
|
||
[Выбор параметров и добавление в корзину],
|
||
[Да],
|
||
[Нет],
|
||
[Нет],
|
||
[Отправка заявки на заказ],
|
||
[Да],
|
||
[Нет],
|
||
[Нет],
|
||
[Отправка заявки на расчет],
|
||
[Да],
|
||
[Нет],
|
||
[Нет],
|
||
[Назначение стоимости и условий поставки],
|
||
[Нет],
|
||
[Да],
|
||
[Да],
|
||
[Публикация условий клиенту],
|
||
[Нет],
|
||
[Да],
|
||
[Да],
|
||
[Перевод заявки в работу],
|
||
[Нет],
|
||
[Да],
|
||
[Да],
|
||
[Отмена заявки],
|
||
[Нет],
|
||
[Да],
|
||
[Да],
|
||
[Управление параметрами каталога],
|
||
[Нет],
|
||
[Нет],
|
||
[Да],
|
||
[Управление уведомлениями],
|
||
[Нет],
|
||
[Нет],
|
||
[Да],
|
||
[Управление параметрами синхронизации],
|
||
[Нет],
|
||
[Нет],
|
||
[Да],
|
||
[Управление бонусными правилами],
|
||
[Нет],
|
||
[Да],
|
||
[Да]
|
||
)
|
||
]
|
||
|
||
|
||
== Ограничения доступа и требования к безопасности
|
||
|
||
|
||
Система должна обеспечивать:
|
||
|
||
- раздельные интерфейсы для клиентского и менеджерского контуров
|
||
- доступ клиента только к данным собственного контрагента
|
||
- ограничение административных функций в соответствии с ролью
|
||
- журналирование значимых пользовательских действий
|
||
- хранение истории изменения статусов, условий заявок и бонусных операций
|
||
|
||
= Требования к данным и сущностям
|
||
|
||
|
||
== Общие требования к данным
|
||
|
||
|
||
Основное хранилище данных программного продукта реализуется на PostgreSQL. Прикладной доступ к данным осуществляется через Prisma ORM.
|
||
|
||
Система должна обеспечивать хранение:
|
||
|
||
- пользователей и ролей
|
||
- компаний и профилей контрагентов
|
||
- адресов доставки
|
||
- каталога и складских остатков
|
||
- корзины и ее позиций
|
||
- заказов и расчетных заявок
|
||
- событий изменения статусов
|
||
- подключений мессенджеров
|
||
- бонусных и реферальных сущностей
|
||
|
||
В прикладной реализации должны использоваться фактические сущности базы данных, определенные в schema.prisma. Наименование сущностей в документации и в базе данных должно сопоставляться однозначно.
|
||
|
||
== Справочник сущностей базы данных
|
||
|
||
|
||
#text(size: 7.6pt)[
|
||
#table(
|
||
columns: (1fr, 1fr, 1fr),
|
||
stroke: rgb("#d0d7de"),
|
||
inset: 4pt,
|
||
align: horizon + left,
|
||
[*Модель в базе данных*],
|
||
[*Русское наименование*],
|
||
[*Назначение*],
|
||
[Company],
|
||
[Компания],
|
||
[Клиентская организация],
|
||
[User],
|
||
[Пользователь],
|
||
[Учетная запись клиента, менеджера или суперменеджера],
|
||
[DeliveryAddress],
|
||
[Адрес доставки],
|
||
[Справочник адресов доставки клиента],
|
||
[CounterpartyProfile],
|
||
[Профиль контрагента],
|
||
[Юридические и банковские реквизиты клиента],
|
||
[Invitation],
|
||
[Приглашение],
|
||
[Менеджерское приглашение на подключение],
|
||
[MessengerConnection],
|
||
[Подключение мессенджера],
|
||
[Связка пользователя с Telegram или MAX],
|
||
[Product],
|
||
[Товар],
|
||
[Карточка товарной позиции каталога],
|
||
[CatalogProductTypeSetting],
|
||
[Настройки типа товара],
|
||
[Правила параметров и кастомизации по товарному направлению],
|
||
[Cart],
|
||
[Корзина],
|
||
[Корзина клиента],
|
||
[CartItem],
|
||
[Позиция корзины],
|
||
[Конкретный выбранный товар в корзине],
|
||
[Warehouse],
|
||
[Склад],
|
||
[Справочник складов],
|
||
[ProductStock],
|
||
[Складской остаток],
|
||
[Остаток товара на складе],
|
||
[Order],
|
||
[Заказ / заявка],
|
||
[Единая заказная сущность для готовой продукции и расчета],
|
||
[OrderItem],
|
||
[Позиция заказа],
|
||
[Состав заказа],
|
||
[OrderStatusEvent],
|
||
[Событие статуса заказа],
|
||
[История изменения статусов],
|
||
[ReferralLink],
|
||
[Реферальная связь],
|
||
[Связь между рекомендателем и приглашенным клиентом],
|
||
[BonusTransaction],
|
||
[Бонусная транзакция],
|
||
[Начисление или списание бонусов],
|
||
[RewardWithdrawalRequest],
|
||
[Заявка на вывод бонусов],
|
||
[Заявка клиента на использование или вывод бонусов]
|
||
)
|
||
]
|
||
|
||
|
||
== Служебные перечисления и статусы
|
||
|
||
|
||
В модели данных используются следующие перечисления:
|
||
|
||
- UserRole: CLIENT, MANAGER, SUPER_MANAGER
|
||
- RegistrationStatus: PENDING, APPROVED, REJECTED
|
||
- MessengerType: TELEGRAM, MAX
|
||
- OrderKind: READY, CALCULATION
|
||
- OrderStatus: NEW, MANAGER_PROCESSING, WAITING_DOUBLE_CONFIRM, CLIENT_REJECTED, MANAGER_REJECTED, MANAGER_BLOCKED, CONFIRMED, IN_PROGRESS, COMPLETED
|
||
- WithdrawalStatus: PENDING, APPROVED, REJECTED
|
||
|
||
== Пользователи и компании
|
||
|
||
|
||
=== Company
|
||
|
||
|
||
Русское наименование: Компания
|
||
|
||
Назначение:
|
||
|
||
- хранение клиентской организации
|
||
- объединение пользователей одной компании
|
||
|
||
Основные поля:
|
||
|
||
- id
|
||
- name
|
||
- inn
|
||
- createdAt
|
||
- updatedAt
|
||
|
||
Связи:
|
||
|
||
- одна компания связана со многими пользователями
|
||
|
||
=== User
|
||
|
||
|
||
Русское наименование: Пользователь
|
||
|
||
Назначение:
|
||
|
||
- хранение клиентской, менеджерской или административной учетной записи
|
||
- связывание пользователя с заказами, корзиной, бонусами и адресами
|
||
|
||
Основные поля:
|
||
|
||
- id
|
||
- email
|
||
- fullName
|
||
- role
|
||
- companyId
|
||
- defaultDeliveryAddressId
|
||
- createdAt
|
||
- updatedAt
|
||
|
||
Связи:
|
||
|
||
- пользователь может быть связан с компанией
|
||
- пользователь может иметь профиль контрагента
|
||
- пользователь может иметь адреса доставки
|
||
- пользователь может иметь корзину
|
||
- пользователь может выступать клиентом или менеджером в заказах
|
||
- пользователь может иметь бонусные операции и заявки на вывод
|
||
|
||
=== DeliveryAddress
|
||
|
||
|
||
Русское наименование: Адрес доставки
|
||
|
||
Назначение:
|
||
|
||
- хранение адресов доставки клиента
|
||
- выбор адреса по умолчанию для корзины и заказов
|
||
|
||
Основные поля:
|
||
|
||
- id
|
||
- userId
|
||
- label
|
||
- address
|
||
- unrestrictedValue
|
||
- fiasId
|
||
- createdAt
|
||
- updatedAt
|
||
|
||
=== CounterpartyProfile
|
||
|
||
|
||
Русское наименование: Профиль контрагента
|
||
|
||
Назначение:
|
||
|
||
- хранение полных реквизитов клиента для договоров, счетов и поставки
|
||
|
||
Основные поля:
|
||
|
||
- id
|
||
- userId
|
||
- companyName
|
||
- companyFullName
|
||
- inn
|
||
- kpp
|
||
- ogrn
|
||
- legalAddress
|
||
- bankName
|
||
- bik
|
||
- correspondentAccount
|
||
- checkingAccount
|
||
- signerFullName
|
||
- signerPosition
|
||
- signerBasis
|
||
- createdAt
|
||
- updatedAt
|
||
|
||
=== Invitation
|
||
|
||
|
||
Русское наименование: Приглашение
|
||
|
||
Назначение:
|
||
|
||
- хранение менеджерского приглашения клиента на подключение к личному кабинету
|
||
|
||
Основные поля:
|
||
|
||
- id
|
||
- token
|
||
- email
|
||
- companyName
|
||
- managerId
|
||
- acceptedById
|
||
- expiresAt
|
||
- acceptedAt
|
||
- createdAt
|
||
|
||
=== MessengerConnection
|
||
|
||
|
||
Русское наименование: Подключение мессенджера
|
||
|
||
Назначение:
|
||
|
||
- хранение подключенного Telegram или MAX-канала пользователя
|
||
|
||
Основные поля:
|
||
|
||
- id
|
||
- userId
|
||
- type
|
||
- channelId
|
||
- displayName
|
||
- username
|
||
- avatarFileId
|
||
- avatarFileUniqueId
|
||
- isActive
|
||
- createdAt
|
||
|
||
== Каталог и складской контур
|
||
|
||
|
||
=== Product
|
||
|
||
|
||
Русское наименование: Товар
|
||
|
||
Назначение:
|
||
|
||
- хранение карточки товарной позиции каталога
|
||
- хранение параметров товара и признаков кастомизации
|
||
|
||
Основные поля:
|
||
|
||
- id
|
||
- sku
|
||
- name
|
||
- productType
|
||
- widthMm
|
||
- lengthM
|
||
- thicknessMicron
|
||
- sleeveBrand
|
||
- quantityPerBox
|
||
- tags
|
||
- description
|
||
- isCustomizable
|
||
- isActive
|
||
- createdAt
|
||
- updatedAt
|
||
|
||
=== CatalogProductTypeSetting
|
||
|
||
|
||
Русское наименование: Настройки типа товара
|
||
|
||
Назначение:
|
||
|
||
- хранение правил параметров по товарному направлению
|
||
- хранение разрешений на кастомизацию
|
||
|
||
Основные поля:
|
||
|
||
- id
|
||
- productType
|
||
- showQuantityPerBox
|
||
- allowCustomLength
|
||
- customLengthMinM
|
||
- customLengthMaxM
|
||
- customLengthStepM
|
||
- allowCustomSleeveBrand
|
||
- allowCustomLabel
|
||
- widthOptionsMm
|
||
- lengthOptionsM
|
||
- thicknessOptionsMicron
|
||
- sleeveOptions
|
||
- colorOptions
|
||
- labelOptions
|
||
- createdAt
|
||
- updatedAt
|
||
|
||
=== Warehouse
|
||
|
||
|
||
Русское наименование: Склад
|
||
|
||
Назначение:
|
||
|
||
- хранение справочника складов
|
||
|
||
Основные поля:
|
||
|
||
- id
|
||
- code
|
||
- name
|
||
- createdAt
|
||
- updatedAt
|
||
|
||
=== ProductStock
|
||
|
||
|
||
Русское наименование: Складской остаток
|
||
|
||
Назначение:
|
||
|
||
- хранение остатка товара на конкретном складе
|
||
|
||
Основные поля:
|
||
|
||
- id
|
||
- productId
|
||
- warehouseId
|
||
- availableQty
|
||
- updatedAt
|
||
|
||
== Корзина, заявки и заказы
|
||
|
||
|
||
=== Cart
|
||
|
||
|
||
Русское наименование: Корзина
|
||
|
||
Назначение:
|
||
|
||
- хранение текущего набора выбранных клиентом позиций
|
||
|
||
Основные поля:
|
||
|
||
- id
|
||
- userId
|
||
- deliveryAddressId
|
||
- createdAt
|
||
- updatedAt
|
||
|
||
=== CartItem
|
||
|
||
|
||
Русское наименование: Позиция корзины
|
||
|
||
Назначение:
|
||
|
||
- хранение одной выбранной клиентом позиции с параметрами и количеством
|
||
|
||
Основные поля:
|
||
|
||
- id
|
||
- cartId
|
||
- productId
|
||
- productName
|
||
- sku
|
||
- isCustomizable
|
||
- quantity
|
||
- parameters
|
||
- createdAt
|
||
- updatedAt
|
||
|
||
=== Order
|
||
|
||
|
||
Русское наименование: Заказ / заявка
|
||
|
||
Назначение:
|
||
|
||
- хранение готовой заказной заявки и расчетной заявки в единой сущности
|
||
- хранение согласованных менеджером условий и статуса работы
|
||
|
||
Основные поля:
|
||
|
||
- id
|
||
- code
|
||
- kind
|
||
- customerId
|
||
- deliveryAddressId
|
||
- deliveryAddress
|
||
- managerId
|
||
- status
|
||
- clientApproved
|
||
- managerApproved
|
||
- blockReason
|
||
- deliveryTerms
|
||
- deliveryFee
|
||
- totalPrice
|
||
- calculationPayload
|
||
- createdAt
|
||
- updatedAt
|
||
|
||
Комментарий к модели:
|
||
|
||
- kind = READY означает сценарий заказа готовой продукции
|
||
- kind = CALCULATION означает сценарий расчета индивидуальной продукции
|
||
- поле calculationPayload хранит параметры расчетной заявки
|
||
|
||
=== OrderItem
|
||
|
||
|
||
Русское наименование: Позиция заказа
|
||
|
||
Назначение:
|
||
|
||
- хранение состава заказа
|
||
|
||
Основные поля:
|
||
|
||
- id
|
||
- orderId
|
||
- productId
|
||
- productName
|
||
- quantity
|
||
- unitPrice
|
||
- createdAt
|
||
|
||
=== OrderStatusEvent
|
||
|
||
|
||
Русское наименование: Событие статуса заказа
|
||
|
||
Назначение:
|
||
|
||
- хранение истории изменения статусов заказа или заявки
|
||
|
||
Основные поля:
|
||
|
||
- id
|
||
- orderId
|
||
- status
|
||
- actorUserId
|
||
- note
|
||
- createdAt
|
||
|
||
== Бонусный и реферальный контур
|
||
|
||
|
||
=== ReferralLink
|
||
|
||
|
||
Русское наименование: Реферальная связь
|
||
|
||
Назначение:
|
||
|
||
- фиксация связи между рекомендателем и приглашенным клиентом
|
||
|
||
Основные поля:
|
||
|
||
- id
|
||
- referrerId
|
||
- refereeId
|
||
- createdById
|
||
- bonusPercent
|
||
- createdAt
|
||
|
||
=== BonusTransaction
|
||
|
||
|
||
Русское наименование: Бонусная транзакция
|
||
|
||
Назначение:
|
||
|
||
- хранение начисления или списания бонусов
|
||
|
||
Основные поля:
|
||
|
||
- id
|
||
- userId
|
||
- amount
|
||
- reason
|
||
- orderId
|
||
- referralLinkId
|
||
- createdAt
|
||
|
||
=== RewardWithdrawalRequest
|
||
|
||
|
||
Русское наименование: Заявка на вывод бонусов
|
||
|
||
Назначение:
|
||
|
||
- хранение заявки клиента на использование или вывод бонусов
|
||
|
||
Основные поля:
|
||
|
||
- id
|
||
- requesterId
|
||
- amount
|
||
- status
|
||
- reviewedById
|
||
- reviewComment
|
||
- createdAt
|
||
- updatedAt
|
||
|
||
== Основные связи между сущностями
|
||
|
||
|
||
Укрупненная структура связей определяется следующими правилами:
|
||
|
||
- Company объединяет пользователей одной клиентской организации
|
||
- User связан с CounterpartyProfile, DeliveryAddress, MessengerConnection, Cart, Order, BonusTransaction и RewardWithdrawalRequest
|
||
- Cart содержит набор CartItem, привязанных к конкретным Product
|
||
- Order содержит набор OrderItem и историю OrderStatusEvent
|
||
- Product связан с остатками ProductStock, распределенными по сущностям Warehouse
|
||
- настройки параметров по товарному направлению хранятся в CatalogProductTypeSetting
|
||
- реферальные связи реализуются через ReferralLink, связывающий одного пользователя с другим пользователем
|
||
|
||
= Требования к интерфейсу, прототипам и дизайну
|
||
|
||
|
||
== Карта экранов
|
||
|
||
|
||
Ниже приведен базовый состав экранов, подлежащих реализации и сопровождению в рамках программного продукта.
|
||
|
||
#text(size: 7.6pt)[
|
||
#table(
|
||
columns: (1fr, 1fr, 1fr, 1fr),
|
||
stroke: rgb("#d0d7de"),
|
||
inset: 4pt,
|
||
align: horizon + left,
|
||
[*Раздел*],
|
||
[*Маршрут*],
|
||
[*Роль*],
|
||
[*Назначение*],
|
||
[Главная страница],
|
||
[/],
|
||
[клиент],
|
||
[стартовый экран каталога],
|
||
[Каталог],
|
||
[/products],
|
||
[клиент],
|
||
[выбор товарного направления],
|
||
[Карточка товара],
|
||
[/products/\[slug\]],
|
||
[клиент],
|
||
[выбор параметров, просмотр вариантов, добавление в корзину],
|
||
[Корзина],
|
||
[/cart],
|
||
[клиент],
|
||
[формирование и отправка заявки],
|
||
[Список заказов клиента],
|
||
[/client-orders],
|
||
[клиент],
|
||
[просмотр истории заявок и заказов],
|
||
[Карточка заказа клиента],
|
||
[/client-orders/\[id\]],
|
||
[клиент],
|
||
[просмотр статуса, состава, условий и истории],
|
||
[Профиль],
|
||
[/profile],
|
||
[клиент],
|
||
[базовые данные учетной записи],
|
||
[Контрагент],
|
||
[/profile/counterparty],
|
||
[клиент],
|
||
[реквизиты и юридические данные],
|
||
[Адреса доставки],
|
||
[/profile/addresses],
|
||
[клиент],
|
||
[адресный справочник],
|
||
[Уведомления],
|
||
[/notifications],
|
||
[клиент],
|
||
[история уведомлений],
|
||
[Бонусный кабинет],
|
||
[/bonus-program],
|
||
[клиент],
|
||
[баланс, история и бонусные действия],
|
||
[Список клиентов],
|
||
[/clients],
|
||
[менеджер],
|
||
[клиентская база],
|
||
[Карточка клиента],
|
||
[/clients/\[id\]],
|
||
[менеджер],
|
||
[данные компании, заказы, бонусы],
|
||
[Приглашение клиента],
|
||
[/clients/invite],
|
||
[менеджер],
|
||
[выдача приглашения на подключение],
|
||
[Список заказов],
|
||
[/orders],
|
||
[менеджер],
|
||
[обработка заказного контура],
|
||
[Карточка заказа],
|
||
[/orders/\[id\]],
|
||
[менеджер],
|
||
[обработка условий, статуса и доставки],
|
||
[Настройки каталога],
|
||
[/catalog-settings],
|
||
[суперменеджер],
|
||
[параметры товарных направлений],
|
||
[Настройки синхронизации],
|
||
[/settings-sync],
|
||
[суперменеджер],
|
||
[мониторинг и управление обменом],
|
||
[Бонусная система],
|
||
[/bonus-system/\\\*],
|
||
[менеджер/суперменеджер],
|
||
[рефералы, транзакции, выводы]
|
||
)
|
||
]
|
||
|
||
|
||
== Маршруты и экранные формы
|
||
|
||
|
||
Ниже приведен перечень экранных форм, предусмотренных в составе frontend-контура программного продукта.
|
||
|
||
=== Публичные и клиентские страницы
|
||
|
||
|
||
#text(size: 7.6pt)[
|
||
#table(
|
||
columns: (1fr, 1fr, 1fr),
|
||
stroke: rgb("#d0d7de"),
|
||
inset: 4pt,
|
||
align: horizon + left,
|
||
[*Маршрут*],
|
||
[*Экран*],
|
||
[*Назначение*],
|
||
[/],
|
||
[Главная страница],
|
||
[Стартовая страница личного кабинета],
|
||
[/login],
|
||
[Вход],
|
||
[Вход и первичный сценарий доступа],
|
||
[/products],
|
||
[Каталог продукции],
|
||
[Список товарных направлений],
|
||
[/products/\[slug\]],
|
||
[Карточка товара],
|
||
[Выбор параметров, просмотр вариантов, добавление в корзину],
|
||
[/cart],
|
||
[Корзина],
|
||
[Состав выбранных позиций и отправка заявки],
|
||
[/client-orders],
|
||
[Список заказов клиента],
|
||
[История заявок и заказов клиента],
|
||
[/client-orders/\[id\]],
|
||
[Карточка заказа клиента],
|
||
[Детали конкретного заказа клиента],
|
||
[/notifications],
|
||
[Уведомления],
|
||
[Список системных уведомлений],
|
||
[/bonus-program],
|
||
[Бонусный кабинет],
|
||
[Бонусный баланс, подарочные карты и бонусные действия]
|
||
)
|
||
]
|
||
|
||
|
||
=== Профиль клиента
|
||
|
||
|
||
#text(size: 7.6pt)[
|
||
#table(
|
||
columns: (1fr, 1fr, 1fr),
|
||
stroke: rgb("#d0d7de"),
|
||
inset: 4pt,
|
||
align: horizon + left,
|
||
[*Маршрут*],
|
||
[*Экран*],
|
||
[*Назначение*],
|
||
[/profile],
|
||
[Профиль],
|
||
[Основные данные пользователя],
|
||
[/profile/counterparty],
|
||
[Реквизиты контрагента],
|
||
[Юридические и банковские данные],
|
||
[/profile/addresses],
|
||
[Адреса доставки],
|
||
[Список адресов доставки],
|
||
[/profile/addresses/new],
|
||
[Новый адрес доставки],
|
||
[Создание адреса доставки],
|
||
[/profile/notifications],
|
||
[Настройки уведомлений],
|
||
[Подключение и настройка каналов уведомлений],
|
||
[/profile/notifications/success],
|
||
[Успешное подключение уведомлений],
|
||
[Финальный экран сценария подключения канала]
|
||
)
|
||
]
|
||
|
||
|
||
=== Менеджерские и административные страницы
|
||
|
||
|
||
#text(size: 7.6pt)[
|
||
#table(
|
||
columns: (1fr, 1fr, 1fr),
|
||
stroke: rgb("#d0d7de"),
|
||
inset: 4pt,
|
||
align: horizon + left,
|
||
[*Маршрут*],
|
||
[*Экран*],
|
||
[*Назначение*],
|
||
[/clients],
|
||
[Клиенты],
|
||
[Список клиентских компаний и пользователей],
|
||
[/clients/\[id\]],
|
||
[Карточка клиента],
|
||
[Детали клиента, его заказы и бонусные данные],
|
||
[/clients/invite],
|
||
[Пригласить клиента],
|
||
[Создание приглашения на подключение],
|
||
[/orders],
|
||
[Список заказов],
|
||
[Очередь заказов и заявок для менеджера],
|
||
[/orders/\[id\]],
|
||
[Карточка заказа],
|
||
[Обработка стоимости, условий поставки и статуса],
|
||
[/catalog-settings],
|
||
[Настройки каталога],
|
||
[Параметры товарных направлений и кастомизации],
|
||
[/settings-sync],
|
||
[1С / синхронизация],
|
||
[Управление и мониторинг синхронизации],
|
||
[/messages],
|
||
[Сообщения],
|
||
[Шаблоны и тексты менеджерских сообщений]
|
||
)
|
||
]
|
||
|
||
|
||
=== Бонусный менеджерский контур
|
||
|
||
|
||
#text(size: 7.6pt)[
|
||
#table(
|
||
columns: (1fr, 1fr, 1fr),
|
||
stroke: rgb("#d0d7de"),
|
||
inset: 4pt,
|
||
align: horizon + left,
|
||
[*Маршрут*],
|
||
[*Экран*],
|
||
[*Назначение*],
|
||
[/bonus-system],
|
||
[Бонусная система],
|
||
[Список клиентов и бонусных сущностей],
|
||
[/bonus-system/\[userId\]],
|
||
[Карточка бонусного счета клиента],
|
||
[История и состояние бонусного счета],
|
||
[/bonus-system/referrals/new],
|
||
[Создать бонусный счет],
|
||
[Создание реферальной связи],
|
||
[/bonus-system/transactions/new],
|
||
[Добавить бонусную транзакцию],
|
||
[Ручное начисление или списание],
|
||
[/bonus-system/withdrawals/\[id\]],
|
||
[Проверка заявки на вывод],
|
||
[Рассмотрение заявки клиента на вывод бонусов]
|
||
)
|
||
]
|
||
|
||
|
||
== Общие требования к экранным формам
|
||
|
||
|
||
Экранные формы должны обеспечивать:
|
||
|
||
- однозначное понимание текущего объекта работы
|
||
- явное отображение статуса объекта
|
||
- соответствие доступных действий роли пользователя
|
||
- единый визуальный подход для клиентского и менеджерского контуров
|
||
- понятное отображение параметров товара, условий заказа и бонусных операций
|
||
|
||
Для экранов, связанных с товарами, заявками и заказами, должны выполняться дополнительные требования:
|
||
|
||
- цена не отображается клиенту до публикации условий менеджером
|
||
- остатки и доступные варианты отображаются в наглядном виде
|
||
- пользователь понимает ограничения выбора и возможность кастомизации
|
||
|
||
Ниже приведены низкодетализированные wireframe-прототипы. Они используются как визуальная фиксация состава страниц, ключевых блоков и пользовательских действий.
|
||
|
||
== Требования к прототипам и визуальному дизайну
|
||
|
||
|
||
Прототипы, приведенные в настоящем техническом задании, являются низкодетализированными wireframe-схемами. Они фиксируют структуру экранов, состав блоков, расположение основных элементов и пользовательские действия.
|
||
|
||
Прототипы должны выполняться в черно-белом виде либо в оттенках серого. Цвета, графические акценты, иллюстрации, финальная типографика и иные элементы визуального стиля не считаются согласованным дизайном на основании wireframe-прототипов.
|
||
|
||
Визуальный дизайн программного продукта может быть зафиксирован отдельными дизайн-материалами, изображениями или макетами, согласованными сторонами. Такие материалы уточняют внешний вид интерфейса, но не изменяют функциональные требования, состав экранов, роли, данные и интеграции, если это прямо не согласовано сторонами отдельно.
|
||
|
||
== Клиентские экранные формы
|
||
|
||
|
||
=== Главная страница клиента
|
||
|
||
|
||
Назначение страницы:
|
||
|
||
- отображение каталога товарных направлений
|
||
- переход к карточке выбранного типа товара
|
||
|
||
Состав страницы:
|
||
|
||
- верхняя навигация
|
||
- заголовок раздела
|
||
- поиск по типу товара
|
||
- сетка карточек товарных направлений
|
||
- переход в карточку выбранного товарного направления
|
||
|
||
Wireframe-прототип:
|
||
|
||
#figure(
|
||
image("public/prototypes/dashboard.svg", width: 100%),
|
||
caption: [Прототип главной страницы клиента],
|
||
)
|
||
|
||
|
||
=== Каталог продукции
|
||
|
||
|
||
Назначение страницы:
|
||
|
||
- отображение товарных направлений
|
||
- переход к карточке выбранного типа товара
|
||
|
||
Состав страницы:
|
||
|
||
- заголовок раздела
|
||
- поиск при необходимости
|
||
- сетка карточек товарных направлений
|
||
- карточка каждого товарного направления с изображением и наименованием
|
||
- переход в карточку выбранного товарного направления
|
||
|
||
Wireframe-прототип:
|
||
|
||
#figure(
|
||
image("public/prototypes/catalog-grid.svg", width: 100%),
|
||
caption: [Прототип каталога продукции],
|
||
)
|
||
|
||
|
||
=== Карточка товара
|
||
|
||
|
||
Назначение страницы:
|
||
|
||
- выбор параметров товара
|
||
- просмотр стандартных вариантов
|
||
- просмотр складских остатков
|
||
- добавление выбранной позиции в корзину
|
||
|
||
Состав страницы:
|
||
|
||
- заголовок товара
|
||
- изображение товара
|
||
- блок выбора параметров
|
||
- блок пояснений по параметрам
|
||
- блок индивидуальных возможностей, если они разрешены
|
||
- блок добавления в корзину
|
||
- таблица доступных вариантов
|
||
|
||
Маршрут страницы:
|
||
|
||
- /products/[slug]
|
||
|
||
Wireframe-прототип:
|
||
|
||
#figure(
|
||
image("public/prototypes/product-card.svg", width: 100%),
|
||
caption: [Прототип карточки товара],
|
||
)
|
||
|
||
|
||
Состав блока выбора параметров:
|
||
|
||
- ширина
|
||
- длина
|
||
- толщина
|
||
- тип втулки
|
||
- цвет
|
||
- надпись
|
||
- индивидуальные опции при наличии разрешения
|
||
|
||
Состав блока пояснений:
|
||
|
||
- описание каждого параметра простым деловым языком
|
||
- ограничения по индивидуальной длине
|
||
- правила по втулке с логотипом
|
||
- правила по нанесению индивидуальной надписи
|
||
|
||
=== Корзина
|
||
|
||
|
||
Назначение страницы:
|
||
|
||
- просмотр выбранных позиций
|
||
- изменение количества
|
||
- удаление позиции
|
||
- отправка заявки на заказ
|
||
|
||
Состав страницы:
|
||
|
||
- список позиций
|
||
- параметры и количество
|
||
- комментарий клиента
|
||
- действие отправки заявки
|
||
- выбранный адрес доставки
|
||
- итоговая сводка по количеству позиций
|
||
|
||
Wireframe-прототип:
|
||
|
||
#figure(
|
||
image("public/prototypes/cart.svg", width: 100%),
|
||
caption: [Прототип корзины],
|
||
)
|
||
|
||
|
||
=== Карточка заявки или заказа
|
||
|
||
|
||
Назначение страницы:
|
||
|
||
- просмотр состава
|
||
- просмотр статуса
|
||
- просмотр стоимости и условий поставки после публикации
|
||
- просмотр истории изменений
|
||
|
||
Wireframe-прототип:
|
||
|
||
#figure(
|
||
image("public/prototypes/client-order.svg", width: 100%),
|
||
caption: [Прототип карточки заявки или заказа],
|
||
)
|
||
|
||
|
||
Состав страницы:
|
||
|
||
- номер документа
|
||
- статус
|
||
- состав позиций
|
||
- стоимость после публикации менеджером
|
||
- условия поставки и доставки
|
||
- история статусов
|
||
- системные комментарии
|
||
|
||
=== Страница входа и завершения приглашения
|
||
|
||
|
||
Назначение страницы:
|
||
|
||
- запуск входа в систему
|
||
- завершение подключения по персональной ссылке из приглашения
|
||
- запуск сценариев входа через мессенджеры
|
||
|
||
Состав страницы:
|
||
|
||
- форма запроса кода входа
|
||
- форма проверки кода из письма
|
||
- кнопки входа через доступные мессенджеры
|
||
- служебное сообщение о результате входа либо привязки канала
|
||
|
||
Wireframe-прототип:
|
||
|
||
#figure(
|
||
image("public/prototypes/login.svg", width: 100%),
|
||
caption: [Прототип страницы логина и подключения],
|
||
)
|
||
|
||
|
||
=== Список заказов
|
||
|
||
|
||
Назначение страницы:
|
||
|
||
- просмотр текущих и архивных заказов
|
||
- фильтрация по периоду и статусу
|
||
|
||
Состав страницы:
|
||
|
||
- фильтры
|
||
- карточки заказов
|
||
- переход в карточку конкретного заказа
|
||
|
||
=== Уведомления
|
||
|
||
|
||
Назначение страницы:
|
||
|
||
- просмотр истории уведомлений по заказам, заявкам и бонусным операциям
|
||
|
||
=== Бонусный кабинет
|
||
|
||
|
||
Назначение страницы:
|
||
|
||
- просмотр текущего бонусного баланса
|
||
- просмотр истории операций
|
||
- инициирование действий, допускаемых правилами бонусной программы
|
||
|
||
Состав страницы:
|
||
|
||
- текущий баланс
|
||
- история начислений и списаний
|
||
- связанные реферальные сведения
|
||
- форма подачи заявки на использование либо вывод бонусов
|
||
- магазин вознаграждений
|
||
|
||
Wireframe-прототип:
|
||
|
||
#figure(
|
||
image("public/prototypes/bonus-cabinet.svg", width: 100%),
|
||
caption: [Прототип бонусного кабинета],
|
||
)
|
||
|
||
|
||
== Менеджерские экранные формы
|
||
|
||
|
||
=== Список клиентов
|
||
|
||
|
||
Назначение страницы:
|
||
|
||
- просмотр клиентской базы
|
||
- переход в карточку конкретного клиента
|
||
|
||
Состав страницы:
|
||
|
||
- поиск и фильтры
|
||
- сетка карточек клиентов
|
||
- действие приглашения нового клиента
|
||
|
||
Wireframe-прототип:
|
||
|
||
#figure(
|
||
image("public/prototypes/client-list.svg", width: 100%),
|
||
caption: [Прототип списка клиентов],
|
||
)
|
||
|
||
|
||
=== Карточка клиента
|
||
|
||
|
||
Назначение страницы:
|
||
|
||
- просмотр сведений о компании
|
||
- просмотр истории заявок и заказов
|
||
|
||
Состав страницы:
|
||
|
||
- карточка компании и контактных данных
|
||
- реквизиты контрагента
|
||
- список заказов клиента
|
||
|
||
Wireframe-прототип:
|
||
|
||
#figure(
|
||
image("public/prototypes/client-card.svg", width: 100%),
|
||
caption: [Прототип карточки клиента],
|
||
)
|
||
|
||
|
||
=== Карточка обработки заявки
|
||
|
||
|
||
Назначение страницы:
|
||
|
||
- просмотр состава заявки
|
||
- ввод коммерческих условий
|
||
- публикация условий клиенту
|
||
- перевод заявки в работу либо отмена
|
||
|
||
Wireframe-прототип:
|
||
|
||
#figure(
|
||
image("public/prototypes/manager-order.svg", width: 100%),
|
||
caption: [Прототип карточки обработки заявки],
|
||
)
|
||
|
||
|
||
Состав страницы:
|
||
|
||
- клиент и контрагент
|
||
- состав позиции или расчетный payload
|
||
- стоимость
|
||
- доставка
|
||
- комментарий менеджера
|
||
- история изменений
|
||
- блок действий со статусом
|
||
|
||
=== Список заказов менеджера
|
||
|
||
|
||
Назначение страницы:
|
||
|
||
- просмотр заказов по клиентам
|
||
- фильтрация по статусам
|
||
- переход к обработке конкретного заказа
|
||
|
||
Wireframe-прототип:
|
||
|
||
#figure(
|
||
image("public/prototypes/manager-orders.svg", width: 100%),
|
||
caption: [Прототип списка заказов менеджера],
|
||
)
|
||
|
||
|
||
=== Настройки каталога
|
||
|
||
|
||
Назначение страницы:
|
||
|
||
- управление параметрами товарных направлений
|
||
- управление стандартными значениями параметров
|
||
- управление возможностями кастомизации
|
||
|
||
Состав страницы:
|
||
|
||
- список товарных направлений
|
||
- карточка настроек конкретного направления
|
||
- чекбоксы разрешений кастомизации
|
||
- списки стандартных параметров
|
||
- единое действие сохранения настроек
|
||
|
||
Wireframe-прототип:
|
||
|
||
#figure(
|
||
image("public/prototypes/catalog-settings.svg", width: 100%),
|
||
caption: [Прототип настроек каталога],
|
||
)
|
||
|
||
|
||
=== Настройки синхронизации
|
||
|
||
|
||
Назначение страницы:
|
||
|
||
- просмотр состояния интеграционного обмена
|
||
- контроль последних загрузок данных
|
||
|
||
Состав страницы:
|
||
|
||
- статусы последних синхронизаций
|
||
- количество загруженных записей
|
||
- дата последней загрузки
|
||
- примечание по каждому потоку обмена
|
||
|
||
Wireframe-прототип:
|
||
|
||
#figure(
|
||
image("public/prototypes/sync-settings.svg", width: 100%),
|
||
caption: [Прототип настроек синхронизации],
|
||
)
|
||
|
||
|
||
== Дополнительные профильные и сервисные страницы
|
||
|
||
|
||
Помимо основных клиентских и менеджерских экранов, программный продукт включает дополнительные экранные формы:
|
||
|
||
- профиль пользователя
|
||
- реквизиты контрагента
|
||
- список адресов доставки
|
||
- создание нового адреса доставки
|
||
- настройки уведомлений пользователя
|
||
- экран успешного подключения канала уведомлений
|
||
- менеджерский экран сообщений
|
||
- бонусная система для менеджера
|
||
- карточка бонусного счета клиента
|
||
- создание реферальной связи
|
||
- создание бонусной транзакции
|
||
- проверка заявки на вывод бонусов
|
||
|
||
Прототипы служебных и дополнительных экранов:
|
||
|
||
#figure(
|
||
image("public/prototypes/profile.svg", width: 100%),
|
||
caption: [Прототип профиля клиента],
|
||
)
|
||
|
||
|
||
#figure(
|
||
image("public/prototypes/bonus-manager.svg", width: 100%),
|
||
caption: [Прототип бонусной системы менеджера],
|
||
)
|
||
|
||
|
||
= Требования к интеграции с 1С и внешним интерфейсам
|
||
|
||
|
||
== Общие требования к интеграционному контуру
|
||
|
||
|
||
Интеграционный слой должен обеспечивать обмен данными между личным кабинетом и внешними системами без потери целостности внутренних сущностей и статусов.
|
||
|
||
Интеграционный контур должен обеспечивать:
|
||
|
||
- получение файлов обмена из 1С
|
||
- передачу в 1С файлов обмена, сформированных личным кабинетом
|
||
- передачу во внешние системы данных, необходимых для сопровождения заказов и клиентов, если такой обмен согласован сторонами
|
||
- сопоставление внутренних идентификаторов и идентификаторов внешних систем
|
||
- регистрацию входящих и исходящих операций обмена
|
||
- повторную обработку неуспешных сообщений
|
||
- хранение истории обновлений по интеграционным операциям
|
||
|
||
== Интеграция с 1С
|
||
|
||
|
||
Интеграция с 1С должна обеспечивать обмен данными, необходимыми для сопровождения каталога, заказов, статусов, остатков и сведений о задолженности клиента.
|
||
|
||
Система должна обеспечивать получение из 1С следующих данных:
|
||
|
||
- сведения о контрагентах
|
||
- каталог товаров
|
||
- характеристики товаров
|
||
- складские остатки
|
||
- сведения о заказах
|
||
- статусы заказов
|
||
- изменения состава, стоимости, доставки и иных существенных параметров заказа
|
||
- текущая задолженность клиента
|
||
- дата актуальности сведений, полученных из 1С
|
||
|
||
1С рассматривается как первичный источник учетных данных по контрагентам, заказам, складам, статусам, стоимости, доставке и задолженности. Личный кабинет отображает эти сведения, связывает их с созданными менеджером кабинетами клиентов и фиксирует дату их актуальности.
|
||
|
||
== Основной способ обмена с 1С
|
||
|
||
|
||
Основным способом интеграции является файловый обмен по согласованным структурам. 1С формирует регламентные snapshot-выгрузки с согласованным составом учетных данных, а личный кабинет принимает эти выгрузки, обновляет локальное представление данных и показывает клиентам только сведения, доступные их контрагенту.
|
||
|
||
В качестве базового формата обмена используется JSON. Если на стороне 1С по техническим причинам удобнее использовать XML или CSV, стороны могут согласовать эквивалентную структуру без изменения состава передаваемых данных.
|
||
|
||
Файлы обмена могут передаваться одним из согласованных способов:
|
||
|
||
- загрузка файла в согласованное файловое хранилище
|
||
- передача файла через HTTP endpoint личного кабинета
|
||
- передача через иной согласованный защищенный канал, доступный заказчику и 1С
|
||
|
||
Базовая логика обмена:
|
||
|
||
+ 1С формирует выгрузку контрагентов, балансов, заказов, статусов, каталога и остатков в согласованном объеме.
|
||
+ Личный кабинет принимает snapshot, сопоставляет данные по внешним идентификаторам 1С, ИНН и иным согласованным ключам.
|
||
+ Менеджер при создании доступа выбирает или связывает кабинет клиента с контрагентом, полученным из 1С.
|
||
+ Каталог и остатки передаются как актуальный общий snapshot.
|
||
+ Балансы и задолженность передаются как состояние по контрагентам на дату формирования выгрузки.
|
||
+ Заказы и статусы передаются по контрагентам за согласованный период, по умолчанию за последние 60 календарных дней, а также по активным заказам вне этого периода при необходимости отображения клиенту.
|
||
|
||
== Состав файлов обмена
|
||
|
||
|
||
Минимальный состав файлов обмена:
|
||
|
||
- `counterparties_snapshot` — контрагенты, реквизиты и признаки доступности для клиентского кабинета
|
||
- `balance_snapshot` — баланс, задолженность и дата актуальности по контрагентам
|
||
- `catalog_snapshot` — актуальная продукция, характеристики и складские остатки
|
||
- `orders_snapshot` — заказы, статусы, состав, стоимость, доставка и существенные изменения по заказам за согласованный период
|
||
|
||
Файлы `counterparties_snapshot`, `balance_snapshot`, `catalog_snapshot` и `orders_snapshot` передаются из 1С в личный кабинет. Обратная передача файлов из личного кабинета в 1С выполняется только для согласованных клиентских заявок или иных событий, если такой контур отдельно согласован сторонами.
|
||
|
||
Состав файлов может быть расширен по согласованию сторон, если в ходе интеграции появится отдельный тип данных, который нецелесообразно включать в существующие файлы обмена.
|
||
|
||
== Определение обновлений и идемпотентность
|
||
|
||
|
||
Каждый файл обмена должен содержать служебный блок с метаданными:
|
||
|
||
- `document_type` — тип файла обмена
|
||
- `schema_version` — версия структуры файла
|
||
- `snapshot_id` — уникальный идентификатор выгрузки
|
||
- `generated_at` — дата и время формирования файла
|
||
- `period_from` и `period_to` — период данных, если файл является выгрузкой за период
|
||
- `source` — источник файла
|
||
- `checksum` — контрольная сумма содержимого, если она формируется источником
|
||
|
||
Личный кабинет должен хранить журнал обработанных файлов обмена и не обрабатывать повторно файл с тем же `document_type`, `snapshot_id` и `checksum`.
|
||
|
||
Если 1С может формировать только полную выгрузку, личный кабинет должен принимать полный snapshot и обновлять данные идемпотентно по внешним идентификаторам 1С и дате изменения объекта.
|
||
|
||
Для заказов регулярная синхронизация ограничивается согласованным периодом. По умолчанию передаются заказы за последние 60 календарных дней, а также активные заказы, если они не попадают в этот период, но должны отображаться клиенту.
|
||
|
||
== Пример counterparties_snapshot
|
||
|
||
|
||
```json
|
||
{
|
||
"document_type": "counterparties_snapshot",
|
||
"schema_version": "1.0",
|
||
"snapshot_id": "1c-counterparties-2026-05-04T10:00:00",
|
||
"generated_at": "2026-05-04T10:00:00+03:00",
|
||
"source": "1c",
|
||
"counterparties": [
|
||
{
|
||
"counterparty_external_id": "1c-counterparty-77",
|
||
"inn": "7700000000",
|
||
"name": "ООО Клиент",
|
||
"kpp": "770001001",
|
||
"cabinet_allowed": true,
|
||
"manager_external_id": "1c-manager-12"
|
||
}
|
||
]
|
||
}
|
||
```
|
||
|
||
== Пример balance_snapshot
|
||
|
||
|
||
```json
|
||
{
|
||
"document_type": "balance_snapshot",
|
||
"schema_version": "1.0",
|
||
"snapshot_id": "1c-balances-2026-05-04T10:00:00",
|
||
"generated_at": "2026-05-04T10:00:00+03:00",
|
||
"balance_date": "2026-05-04",
|
||
"source": "1c",
|
||
"balances": [
|
||
{
|
||
"counterparty_external_id": "1c-counterparty-77",
|
||
"debt_amount": 125000,
|
||
"currency": "RUB"
|
||
}
|
||
]
|
||
}
|
||
```
|
||
|
||
== Пример catalog_snapshot
|
||
|
||
|
||
```json
|
||
{
|
||
"document_type": "catalog_snapshot",
|
||
"schema_version": "1.0",
|
||
"snapshot_id": "1c-catalog-2026-05-04T10:00:00",
|
||
"generated_at": "2026-05-04T10:00:00+03:00",
|
||
"source": "1c",
|
||
"products": [
|
||
{
|
||
"product_external_id": "1c-product-0001",
|
||
"article": "FRG-101",
|
||
"name": "Упаковочный скотч",
|
||
"is_active": true,
|
||
"stocks": [
|
||
{
|
||
"warehouse_external_id": "1c-warehouse-main",
|
||
"warehouse_name": "Основной склад",
|
||
"quantity": 120
|
||
}
|
||
]
|
||
}
|
||
]
|
||
}
|
||
```
|
||
|
||
== Пример orders_snapshot
|
||
|
||
|
||
```json
|
||
{
|
||
"document_type": "orders_snapshot",
|
||
"schema_version": "1.0",
|
||
"snapshot_id": "1c-orders-2026-05-04T10:00:00",
|
||
"generated_at": "2026-05-04T10:00:00+03:00",
|
||
"period_from": "2026-03-05",
|
||
"period_to": "2026-05-04",
|
||
"source": "1c",
|
||
"orders": [
|
||
{
|
||
"order_external_id": "1c-order-10025",
|
||
"cabinet_order_id": "FRG-2030",
|
||
"counterparty_external_id": "1c-counterparty-77",
|
||
"status": "in_production",
|
||
"status_name": "В производстве",
|
||
"total_amount": 145000,
|
||
"currency": "RUB",
|
||
"delivery_date": "2026-05-12",
|
||
"updated_at": "2026-05-04T09:45:00+03:00"
|
||
}
|
||
]
|
||
}
|
||
```
|
||
|
||
== Интеграционные поля и служебные атрибуты
|
||
|
||
|
||
Для сущностей, участвующих в обмене, должны поддерживаться:
|
||
|
||
- внешний идентификатор учетной системы
|
||
- дата последней синхронизации
|
||
- источник последнего обновления
|
||
- признак успешной или неуспешной обработки
|
||
- журнал интеграционных ошибок при наличии
|
||
- идентификатор последнего обработанного файла обмена
|
||
|
||
== Журналирование интеграционных операций
|
||
|
||
|
||
Для ключевых операций обмена система должна сохранять:
|
||
|
||
- тип объекта
|
||
- идентификатор объекта
|
||
- предыдущее состояние
|
||
- новое состояние
|
||
- дату и время изменения
|
||
- пользователя либо внешний источник, выполнивший изменение
|
||
- статус обработки сообщения
|
||
- текст ошибки при наличии
|
||
- идентификатор файла обмена и контрольную сумму при наличии
|
||
|
||
== Требования к защите интеграционного обмена
|
||
|
||
|
||
Интеграционные запросы должны выполняться с использованием согласованного механизма авторизации или подписи.
|
||
|
||
Система должна отклонять интеграционные запросы, если:
|
||
|
||
- отсутствуют обязательные параметры авторизации
|
||
- подпись или токен не прошли проверку
|
||
- файл обмена не соответствует согласованной структуре
|
||
- невозможно определить тип файла или объект обработки
|
||
|
||
Секреты, используемые для интеграции с 1С, должны храниться только в Vault и передаваться сервисам через runtime-конфигурацию.
|
||
|
||
== Критерии приемки интеграции с 1С
|
||
|
||
|
||
Интеграция с 1С считается готовой в согласованном объеме, если:
|
||
|
||
- контрагенты из 1С принимаются и доступны менеджеру для привязки клиентского кабинета
|
||
- каталог и характеристики товаров получаются и отображаются в личном кабинете
|
||
- остатки по складам отображаются в карточках товаров
|
||
- заказы клиента получаются и отображаются с актуальными статусами
|
||
- изменения заказа из 1С отображаются в карточке заказа
|
||
- текущая задолженность клиента и дата актуальности данных отображаются в предусмотренных интерфейсах
|
||
- повторная передача одного и того же файла обмена не приводит к дублированию данных
|
||
- ошибки интеграционного обмена фиксируются в журнале
|
||
- неуспешные сообщения могут быть проанализированы и повторно обработаны в согласованном порядке
|
||
|
||
= Техническая архитектура, стек, компоненты и эксплуатационный контур
|
||
|
||
|
||
== Общая архитектурная схема
|
||
|
||
|
||
Программный продукт реализуется по клиент-серверной модели и включает веб-клиент, сервер бизнес-логики, базу данных, модуль интеграции и вспомогательные сервисы уведомлений.
|
||
|
||
#figure(
|
||
image("public/diagrams/architecture-overview.svg", width: 100%),
|
||
caption: [Общая архитектурная схема],
|
||
)
|
||
|
||
|
||
== Состав прикладных сервисов
|
||
|
||
|
||
Согласно действующей карте деплоя в составе проекта используются следующие сервисы:
|
||
|
||
- web-frontend — клиентский и менеджерский веб-интерфейс
|
||
- apollo-backend — сервер GraphQL и бизнес-логика
|
||
- vault — централизованное хранилище секретов
|
||
- tg-bot — Telegram-контур
|
||
- max-bot — MAX-контур
|
||
- bonus-bot — бонусный мессенджерный контур
|
||
|
||
Основные прикладные сервисы web-frontend и apollo-backend разворачиваются через dokploy_webhook на сервере main.
|
||
|
||
== Технологический стек фронтенда
|
||
|
||
|
||
Клиентская часть программного продукта реализуется на следующих технологиях:
|
||
|
||
- Nuxt 4 — прикладной веб-фреймворк
|
||
- Vue 3 — библиотека пользовательского интерфейса
|
||
- \@nuxtjs/apollo и \@vue/apollo-composable — работа с GraphQL
|
||
- GraphQL Code Generator — генерация типизированных GraphQL-документов
|
||
- Tailwind CSS и daisyUI — базовая стилизация интерфейсов
|
||
- Storybook — контур изоляционного просмотра компонентов
|
||
- VitePress — подготовка проектной документации
|
||
|
||
== Технологический стек серверной части
|
||
|
||
|
||
Серверная часть программного продукта реализуется на следующих технологиях:
|
||
|
||
- Node.js — среда выполнения
|
||
- Express 5 — HTTP-сервер
|
||
- Apollo Server 5 — GraphQL-сервер
|
||
- Prisma 7 — доступ к данным и ORM-слой
|
||
- PostgreSQL — основное хранилище данных
|
||
- Zod — валидация структур данных в прикладных сценариях
|
||
- Nodemailer — отправка уведомлений по электронной почте
|
||
|
||
== Архитектура клиентской части
|
||
|
||
|
||
Клиентская часть организована по следующим слоям:
|
||
|
||
- страницы app/pages — входные экранные формы
|
||
- компоненты app/components — переиспользуемые элементы интерфейса
|
||
- composables app/composables — клиентская логика и представление данных
|
||
- GraphQL-документы graphql/operations — отдельные запросы и мутации
|
||
- сгенерированная типизированная схема app/composables/graphql/generated.ts
|
||
- серверные proxy и интеграционные обработчики server/api
|
||
|
||
Ключевые экранные маршруты текущей реализации:
|
||
|
||
- /products и /products/[slug] — каталог и карточка товара
|
||
- /cart — корзина
|
||
- /client-orders и /client-orders/[id] — клиентские заявки и заказы
|
||
- /clients и /clients/[id] — менеджерский контур клиентов
|
||
- /orders и /orders/[id] — менеджерский контур заказов
|
||
- /catalog-settings — административные настройки каталога
|
||
- /bonus-program, /bonus-system/\* — бонусный контур
|
||
|
||
== Карта слоев и компонентов
|
||
|
||
|
||
#figure(
|
||
image("public/diagrams/component-map.svg", width: 100%),
|
||
caption: [Карта слоев и компонентов],
|
||
)
|
||
|
||
|
||
== Архитектура серверной части
|
||
|
||
|
||
Серверная часть организована по следующим основным модулям:
|
||
|
||
- src/server.js — инициализация HTTP-сервера и GraphQL-сервера
|
||
- src/schema.graphql — контракт GraphQL API
|
||
- src/resolvers.js — реализация GraphQL-операций
|
||
- src/context.js — построение контекста запроса
|
||
- src/auth.js — аутентификация и токены доступа
|
||
- src/access.js — правила авторизации и проверки ролей
|
||
- src/prisma-client.js — точка подключения Prisma
|
||
- src/messenger\*.js, src/telegram\*.js, src/max-mini-app.js — мессенджерный контур и мини-приложения
|
||
|
||
== Взаимодействие фронтенда и backend
|
||
|
||
|
||
Взаимодействие клиентской и серверной части строится через GraphQL API.
|
||
|
||
На стороне Nuxt используется серверный proxy-маршрут /api/graphql, который:
|
||
|
||
- принимает запросы браузера
|
||
- прокидывает cookie и авторизационные заголовки
|
||
- перенаправляет запрос в apollo-backend
|
||
- возвращает результат в клиентское приложение
|
||
|
||
Такой подход позволяет:
|
||
|
||
- изолировать прямой backend endpoint от браузерного клиента
|
||
- централизованно передавать авторизационные данные
|
||
- поддерживать единый клиентский GraphQL endpoint
|
||
|
||
== Интеграционные и вспомогательные HTTP-точки
|
||
|
||
|
||
Помимо GraphQL API, во фронтенд-контуре реализованы вспомогательные серверные маршруты:
|
||
|
||
- /api/graphql — proxy в backend GraphQL API
|
||
- /api/auth/messenger-start — запуск сценариев messenger login / connect
|
||
- /api/dadata/address — подсказки адресов
|
||
- /api/dadata/bank — подсказки банковских реквизитов
|
||
- /api/dadata/party — подсказки контрагентов
|
||
- /api/messenger-avatar/[connectionId] — выдача изображений, связанных с мессенджерными подключениями
|
||
|
||
== Компонентные требования к реализации
|
||
|
||
|
||
Архитектура программного продукта должна сохранять следующие правила:
|
||
|
||
- экранная логика должна находиться на уровне страниц и composables
|
||
- переиспользуемые элементы интерфейса должны быть вынесены в компоненты
|
||
- каждый GraphQL-документ должен храниться в отдельном .graphql файле
|
||
- клиентский код должен использовать сгенерированные типизированные документы
|
||
- серверная логика доступа к данным должна проходить через Prisma
|
||
- бизнес-правила доступа должны контролироваться серверной частью, а не только интерфейсом
|
||
|
||
== Требования к конфигурации и секретам
|
||
|
||
|
||
Сервисы программного продукта должны получать прикладные секреты из Vault.
|
||
|
||
В конфигурации сервисов допускается хранение только bootstrap-параметров для подключения к Vault. Бизнес-секреты, ключи интеграций и иные чувствительные данные должны загружаться из Vault при старте приложения.
|
||
|
||
== Инфраструктура, деплой и эксплуатационный контур
|
||
|
||
|
||
Текущая инфраструктурная схема проекта включает прикладные сервисы, сервис секретов, мессенджерные сервисы и вспомогательный worker-контур.
|
||
|
||
#figure(
|
||
image("public/diagrams/infrastructure-topology.svg", width: 100%),
|
||
caption: [Инфраструктура, деплой и эксплуатационный контур],
|
||
)
|
||
|
||
|
||
Сервисы проекта и способ их развёртывания:
|
||
|
||
#text(size: 7.6pt)[
|
||
#table(
|
||
columns: (1fr, 1fr, 1fr, 1fr, 1fr),
|
||
stroke: rgb("#d0d7de"),
|
||
inset: 4pt,
|
||
align: horizon + left,
|
||
[*Сервис*],
|
||
[*Путь в репозитории*],
|
||
[*Роль*],
|
||
[*Deploy mode*],
|
||
[*Сервер*],
|
||
[web-frontend],
|
||
[web-frontend],
|
||
[клиентский и менеджерский веб-интерфейс],
|
||
[dokploy_webhook],
|
||
[main],
|
||
[apollo-backend],
|
||
[apollo-backend],
|
||
[GraphQL API и бизнес-логика],
|
||
[dokploy_webhook],
|
||
[main],
|
||
[hatchet-worker],
|
||
[hatchet-worker],
|
||
[фоновый worker-контур],
|
||
[dokploy_webhook],
|
||
[main],
|
||
[tg-bot],
|
||
[tg-bot],
|
||
[Telegram-контур],
|
||
[dokploy_webhook],
|
||
[main],
|
||
[max-bot],
|
||
[max-bot],
|
||
[MAX-контур],
|
||
[dokploy_webhook],
|
||
[main],
|
||
[bonus-bot],
|
||
[bonus-bot],
|
||
[бонусный сервис],
|
||
[dokploy_webhook],
|
||
[main],
|
||
[vault],
|
||
[vault],
|
||
[сервис секретов],
|
||
[dokploy_webhook],
|
||
[main]
|
||
)
|
||
]
|
||
|
||
|
||
Серверная карта текущего проекта:
|
||
|
||
- сервер main
|
||
- Tailscale user: root
|
||
- Tailscale host: dsrptlab
|
||
|
||
Эксплуатационные операции доступа и диагностики выполняются через Tailscale SSH.
|
||
|
||
== Dokploy и цепочка развёртывания
|
||
|
||
|
||
Для основных сервисов проекта используется режим dokploy_webhook.
|
||
|
||
Это означает следующую последовательность:
|
||
|
||
+ изменения фиксируются в Git-репозитории;
|
||
+ изменения публикуются в main;
|
||
+ Dokploy получает webhook-событие;
|
||
+ Dokploy выполняет сборку соответствующего сервиса;
|
||
+ сервис перезапускается с загрузкой секретов из Vault;
|
||
+ после старта выполняются bootstrap-действия, предусмотренные образом и entrypoint-командой.
|
||
|
||
Текущие особенности прикладных сервисов:
|
||
|
||
- web-frontend стартует через загрузку Vault env и запуск .output/server/index.mjs
|
||
- apollo-backend стартует через загрузку Vault env, prisma migrate deploy и запуск src/server.js
|
||
- bot-сервисы стартуют через общий паттерн загрузки Vault env и запуск node src/server.js
|
||
|
||
== Vault и хранение секретов
|
||
|
||
|
||
Сервис vault развернут как отдельное приложение на базе образа hashicorp/vault:1.21.3.
|
||
|
||
Текущие инфраструктурные правила работы Vault:
|
||
|
||
- используется raft storage
|
||
- данные Vault сохраняются в /vault/data
|
||
- конфигурация сервиса хранится в vault/config/vault.hcl
|
||
- при старте выполняется проверка и, при необходимости, автоматический unseal из переменных окружения
|
||
- прикладные сервисы подключаются к Vault через bootstrap-переменные VAULT_ADDR, VAULT_TOKEN, VAULT_KV_MOUNT, VAULT_SHARED_PATH, VAULT_PROJECT_PATH, VAULT_ENABLED
|
||
|
||
Прикладные сервисы используют общий shell-bootstrap load-vault-env.sh, который:
|
||
|
||
- ожидает доступность Vault по health endpoint
|
||
- загружает shared secrets
|
||
- загружает project secrets
|
||
- экспортирует секреты в runtime environment процесса
|
||
|
||
== Структура сервисных каталогов
|
||
|
||
|
||
Текущая сервисная структура репозитория:
|
||
|
||
- web-frontend — Nuxt-приложение, GraphQL operations, VitePress-документация
|
||
- apollo-backend — Apollo Server, Prisma schema, миграции, импорт каталога
|
||
- tg-bot — Telegram-сервис
|
||
- max-bot — MAX-сервис
|
||
- bonus-bot — бонусный сервис
|
||
- hatchet-worker — worker-контур
|
||
- vault — Dockerfile, конфигурация и entrypoint Vault
|
||
- hatchet — docker-compose инфраструктурного контура Hatchet
|
||
|
||
== Контур фоновых процессов
|
||
|
||
|
||
В проекте присутствует отдельный контур фонового исполнения задач:
|
||
|
||
- hatchet-worker как прикладной worker
|
||
- hatchet-engine как движок исполнения
|
||
- hatchet-dashboard как интерфейс мониторинга
|
||
- отдельный postgres для Hatchet-контура
|
||
|
||
Конфигурация этого контура находится в hatchet/docker-compose.yml.
|
||
|
||
== Зафиксированные runtime-версии и технологические зависимости
|
||
|
||
|
||
=== Базовые runtime и контейнерные образы
|
||
|
||
|
||
#text(size: 7.6pt)[
|
||
#table(
|
||
columns: (1fr, 1fr),
|
||
stroke: rgb("#d0d7de"),
|
||
inset: 4pt,
|
||
align: horizon + left,
|
||
[*Компонент*],
|
||
[*Текущая версия*],
|
||
[Node base image для web/backend/bots],
|
||
[node:22-bookworm-slim],
|
||
[Vault image],
|
||
[hashicorp/vault:1.21.3],
|
||
[Hatchet Postgres],
|
||
[postgres:15.6],
|
||
[Nuxt],
|
||
[4.4.2],
|
||
[Vue],
|
||
[3.5.30],
|
||
[Apollo Server],
|
||
[5.5.0],
|
||
[Prisma / Prisma Client],
|
||
[7.6.0],
|
||
[Mermaid],
|
||
[11.14.0],
|
||
[VitePress],
|
||
[1.6.4]
|
||
)
|
||
]
|
||
|
||
|
||
=== Основные зависимости фронтенда
|
||
|
||
|
||
#text(size: 7.6pt)[
|
||
#table(
|
||
columns: (1fr, 1fr, 1fr),
|
||
stroke: rgb("#d0d7de"),
|
||
inset: 4pt,
|
||
align: horizon + left,
|
||
[*Библиотека*],
|
||
[*Версия*],
|
||
[*Назначение*],
|
||
[\\\@nuxtjs/apollo],
|
||
[5.0.0-alpha.16],
|
||
[GraphQL-клиентский слой],
|
||
[\\\@vue/apollo-composable],
|
||
[4.2.2],
|
||
[composable API для GraphQL],
|
||
[\\\@apollo/client],
|
||
[3.14.1],
|
||
[Apollo client runtime],
|
||
[\\\@fullcalendar/core],
|
||
[6.1.20],
|
||
[calendar runtime],
|
||
[\\\@fullcalendar/daygrid],
|
||
[6.1.20],
|
||
[calendar day grid],
|
||
[\\\@fullcalendar/vue3],
|
||
[6.1.20],
|
||
[Vue integration for calendar],
|
||
[\\\@nuxt/eslint],
|
||
[1.15.2],
|
||
[linting Nuxt-проекта],
|
||
[\\\@nuxtjs/tailwindcss],
|
||
[6.14.0],
|
||
[Tailwind integration],
|
||
[daisyui],
|
||
[5.5.19],
|
||
[UI primitives],
|
||
[graphql],
|
||
[16.13.2],
|
||
[GraphQL runtime],
|
||
[mermaid],
|
||
[11.14.0],
|
||
[diagrams in documentation],
|
||
[\\\@sentry/vue],
|
||
[10.46.0],
|
||
[error tracking],
|
||
[storybook],
|
||
[8.6.14],
|
||
[UI component review],
|
||
[vue-router],
|
||
[5.0.4],
|
||
[Vue routing runtime]
|
||
)
|
||
]
|
||
|
||
|
||
=== Основные зависимости backend
|
||
|
||
|
||
#text(size: 7.6pt)[
|
||
#table(
|
||
columns: (1fr, 1fr, 1fr),
|
||
stroke: rgb("#d0d7de"),
|
||
inset: 4pt,
|
||
align: horizon + left,
|
||
[*Библиотека*],
|
||
[*Версия*],
|
||
[*Назначение*],
|
||
[\\\@apollo/server],
|
||
[5.5.0],
|
||
[GraphQL server],
|
||
[\\\@as-integrations/express5],
|
||
[1.1.2],
|
||
[Apollo + Express integration],
|
||
[express],
|
||
[5.2.1],
|
||
[HTTP server],
|
||
[\\\@prisma/client],
|
||
[7.6.0],
|
||
[data access],
|
||
[\\\@prisma/adapter-pg],
|
||
[7.6.0],
|
||
[Prisma adapter],
|
||
[pg],
|
||
[8.20.0],
|
||
[PostgreSQL driver],
|
||
[graphql],
|
||
[16.13.2],
|
||
[GraphQL runtime],
|
||
[zod],
|
||
[4.3.6],
|
||
[validation],
|
||
[nodemailer],
|
||
[8.0.4],
|
||
[email notifications],
|
||
[dotenv],
|
||
[17.3.1],
|
||
[env bootstrap in local/runtime layers]
|
||
)
|
||
]
|
||
|
||
|
||
=== Основные зависимости worker-контура
|
||
|
||
|
||
#text(size: 7.6pt)[
|
||
#table(
|
||
columns: (1fr, 1fr, 1fr),
|
||
stroke: rgb("#d0d7de"),
|
||
inset: 4pt,
|
||
align: horizon + left,
|
||
[*Библиотека*],
|
||
[*Версия*],
|
||
[*Назначение*],
|
||
[\\\@hatchet-dev/typescript-sdk],
|
||
[1.19.0],
|
||
[worker runtime],
|
||
[dotenv],
|
||
[17.3.1],
|
||
[env bootstrap in local/runtime layers]
|
||
)
|
||
]
|
||
|
||
|
||
== Технические конфигурационные файлы
|
||
|
||
|
||
Ключевые технические файлы текущей реализации:
|
||
|
||
- deploy-map.toml — карта сервисов, deploy mode и серверов
|
||
- web-frontend/nuxt.config.ts — конфигурация Nuxt и Apollo
|
||
- web-frontend/codegen.ts — конфигурация GraphQL codegen
|
||
- apollo-backend/prisma.config.ts — конфигурация Prisma
|
||
- apollo-backend/prisma/schema.prisma — модель данных
|
||
- web-frontend/scripts/load-vault-env.sh — Vault bootstrap frontend
|
||
- apollo-backend/scripts/load-vault-env.sh — Vault bootstrap backend
|
||
- vault/config/vault.hcl — конфигурация Vault
|
||
- vault/entrypoint.sh — startup/unseal логика Vault
|
||
|
||
= Нефункциональные требования
|
||
|
||
|
||
== Общие требования к архитектуре
|
||
|
||
|
||
Программный продукт должен быть реализован как веб-система с разделением клиентского и менеджерского контуров, серверной бизнес-логикой, постоянным хранением данных и возможностью интеграционного обмена с внешними системами.
|
||
|
||
== Требования к доступности интерфейсов
|
||
|
||
|
||
Система должна обеспечивать корректную работу:
|
||
|
||
- в десктопных браузерах
|
||
- в мобильных браузерах
|
||
- на основных пользовательских разрешениях экрана
|
||
|
||
Интерфейсы должны сохранять работоспособность и читаемость при адаптивном отображении.
|
||
|
||
== Требования к производительности
|
||
|
||
|
||
При штатной эксплуатации система должна обеспечивать:
|
||
|
||
- приемлемое время открытия основных экранов
|
||
- приемлемое время отправки заявок и выполнения пользовательских действий
|
||
- отображение каталогов, карточек и заказов без заметных задержек при типовом объеме данных
|
||
|
||
Точные количественные показатели производительности подлежат фиксации в рабочей документации по инфраструктуре и тестированию.
|
||
|
||
== Требования к безопасности
|
||
|
||
|
||
Система должна обеспечивать:
|
||
|
||
- аутентификацию пользователей
|
||
- авторизацию по ролям
|
||
- ограничение доступа клиента только к данным своего контрагента
|
||
- хранение и передачу чувствительных данных с использованием защищенных механизмов
|
||
- исключение несанкционированного доступа к административным функциям
|
||
|
||
== Требования к надежности и журналированию
|
||
|
||
|
||
Система должна обеспечивать:
|
||
|
||
- сохранность пользовательских данных
|
||
- сохранность истории изменений по заявкам, заказам и бонусным операциям
|
||
- фиксацию ошибок интеграционного обмена
|
||
- фиксацию значимых системных и пользовательских событий
|
||
|
||
== Требования к сопровождаемости
|
||
|
||
|
||
Реализация должна обеспечивать возможность:
|
||
|
||
- сопровождения и развития клиентского контура
|
||
- сопровождения и развития менеджерского контура
|
||
- изменения параметров каталога и уведомлений без переработки базовой структуры системы
|
||
- расширения интеграционного обмена с 1С и иными внешними системами
|
||
|
||
== Требования к данным и актуальности сведений
|
||
|
||
|
||
Система должна обеспечивать:
|
||
|
||
- хранение актуального состояния пользовательских данных
|
||
- отображение даты актуальности сведений, полученных из внешних систем, когда это применимо
|
||
- защиту от потери данных при обновлении параметров каталога и заказных сущностей
|
||
|
||
== Требования к документации
|
||
|
||
|
||
По результатам выполнения работ должна быть сформирована документация, достаточная для:
|
||
|
||
- приемки результата работ
|
||
- дальнейшего сопровождения программного продукта
|
||
- понимания состава функций, данных, ролей и интеграций
|
||
|
||
= Требования к программной документации
|
||
|
||
|
||
== Общий подход
|
||
|
||
|
||
Настоящее техническое задание является основным техническим документом программного продукта.
|
||
|
||
В составе настоящего технического задания фиксируются:
|
||
|
||
- назначение и границы продукта
|
||
- функциональные требования
|
||
- роли пользователей и права доступа
|
||
- требования к данным, сущностям и модели базы данных
|
||
- требования к интерфейсам
|
||
- требования к интеграциям
|
||
- архитектура, стек, компоненты и эксплуатационный контур
|
||
- нефункциональные требования
|
||
- порядок контроля, приемки и гарантийного сопровождения
|
||
|
||
Отдельные документы не должны дублировать техническое задание. Дополнительная документация должна описывать только то, что необходимо для использования, эксплуатации или интеграции программного продукта и не раскрыто в настоящем документе в достаточном объеме.
|
||
|
||
== Пользовательская документация
|
||
|
||
|
||
Пользовательская документация должна быть подготовлена в объеме, достаточном для работы пользователей в предусмотренных ролях:
|
||
|
||
- клиент
|
||
- менеджер
|
||
- суперменеджер
|
||
|
||
Пользовательская документация должна описывать:
|
||
|
||
- вход в личный кабинет и завершение подключения по приглашению
|
||
- работу с профилем и каналами уведомлений
|
||
- просмотр каталога готовой продукции
|
||
- добавление товаров в корзину и отправку заявки
|
||
- создание заявки на расчет индивидуальной продукции
|
||
- просмотр заказов, статусов, условий и истории изменений
|
||
- работу с бонусным кабинетом, бонусным балансом и заявками на вывод
|
||
- действия менеджера по обработке клиентов, заявок, заказов и бонусных операций
|
||
- действия суперменеджера в административных разделах, если они отличаются от действий менеджера
|
||
|
||
Документация должна быть написана прикладным языком и ориентирована на выполнение пользовательских сценариев, а не на описание внутренней реализации.
|
||
|
||
== Эксплуатационная документация
|
||
|
||
|
||
Эксплуатационная документация должна быть подготовлена в объеме, достаточном для сопровождения программного продукта после передачи результата работ.
|
||
|
||
Эксплуатационная документация должна описывать:
|
||
|
||
- состав сервисов и их назначение
|
||
- порядок запуска и перезапуска сервисов через согласованный контур деплоя
|
||
- используемые окружения и общие принципы конфигурации
|
||
- порядок загрузки секретов из Vault
|
||
- порядок просмотра логов и диагностики типовых сбоев
|
||
- порядок проверки работоспособности клиентского, менеджерского и интеграционного контуров
|
||
- порядок обновления приложения через Git и Dokploy
|
||
- перечень технических контактов или зон ответственности, если они согласованы сторонами
|
||
|
||
Эксплуатационная документация не должна содержать бизнес-секреты, токены, пароли и иные чувствительные значения. Для секретов указываются только имена переменных, назначение и источник получения.
|
||
|
||
== Интеграционная документация
|
||
|
||
|
||
Для интеграции с 1С должна быть подготовлена интеграционная спецификация либо отдельный раздел настоящего технического задания, если к моменту согласования ТЗ формат обмена уже определен.
|
||
|
||
Интеграционная документация должна описывать:
|
||
|
||
- состав файлов обмена, передаваемых между 1С и личным кабинетом
|
||
- структуру каждого файла обмена
|
||
- формат обмена: JSON, XML или CSV
|
||
- обязательные и необязательные поля
|
||
- правила сопоставления идентификаторов
|
||
- требования к авторизации, подписи или иному механизму защиты обмена
|
||
- порядок обработки дублей
|
||
- порядок фиксации ошибок и повторной обработки сообщений
|
||
- критерии приемки интеграционного обмена
|
||
|
||
Если точный формат обмена с 1С не определен на момент утверждения ТЗ, он фиксируется отдельной согласованной интеграционной спецификацией до начала завершающего этапа интеграции.
|
||
|
||
== Перечень сторонних компонентов
|
||
|
||
|
||
Перечень сторонних компонентов формируется на основании фактических файлов проекта, включая package.json, lock-файлы, Dockerfile и конфигурационные файлы сервисов.
|
||
|
||
Перечень должен содержать:
|
||
|
||
- наименование компонента
|
||
- версию или диапазон версий
|
||
- назначение компонента в продукте
|
||
- источник установки или репозиторий, если он отличается от стандартного пакетного менеджера
|
||
|
||
Ключевые сторонние компоненты, используемые в текущей реализации, перечислены в разделе технической архитектуры настоящего технического задания.
|
||
|
||
= Стадии и этапы разработки
|
||
|
||
|
||
== Общий порядок выполнения работ
|
||
|
||
|
||
Настоящее техническое задание уже фиксирует согласованный состав требований к программному продукту. Разработка и согласование настоящего технического задания не выделяются в качестве отдельного этапа выполнения работ в рамках данного раздела.
|
||
|
||
Работы по созданию программного продукта выполняются в два основных этапа:
|
||
|
||
- реализация рабочего контура программного продукта без интеграции с 1С
|
||
- интеграция с 1С, отладка обмена, передача результата и приемка
|
||
|
||
Отдельный этап UX/UI не выделяется: интерфейсные требования, карта экранов, wireframe-прототипы и требования к визуальному дизайну фиксируются в составе настоящего технического задания.
|
||
|
||
Переход к следующему этапу выполняется после согласования сторонами результата предыдущего этапа либо после фиксации замечаний, не препятствующих продолжению работ.
|
||
|
||
== Этап 1. Реализация программного продукта без интеграции с 1С
|
||
|
||
|
||
На этапе реализуются основные пользовательские, менеджерские, административные и бонусные функции программного продукта без подключения обмена с 1С.
|
||
|
||
В состав этапа входят:
|
||
|
||
- подключение клиентов по приглашению менеджера
|
||
- роли и разграничение доступа
|
||
- каталог готовой продукции
|
||
- корзина и заявки на заказ
|
||
- заявки на расчет индивидуальной продукции
|
||
- обработка заявок менеджером
|
||
- статусы и история изменений
|
||
- уведомления в согласованном объеме
|
||
- бонусный и реферальный контур
|
||
- административные настройки, необходимые для работы продукта
|
||
|
||
Результат этапа:
|
||
|
||
- работоспособный программный продукт с основным функционалом без интеграции с 1С
|
||
- возможность проверки клиентских, менеджерских, административных и бонусных сценариев
|
||
- готовность программного продукта к подключению интеграционного обмена с 1С
|
||
|
||
Критерий завершения этапа: готовность рабочего контура программного продукта без интеграции с 1С к проверке заказчиком.
|
||
|
||
== Этап 2. Интеграция с 1С, отладка обмена и приемка
|
||
|
||
|
||
На этапе выполняются подключение, настройка и отладка интеграционного обмена с 1С, проверка сценариев, зависящих от данных 1С, передача результата и приемка выполненных работ.
|
||
|
||
В состав этапа входят:
|
||
|
||
- сопоставление внутренних идентификаторов и идентификаторов 1С
|
||
- настройка приема файлов обмена от 1С
|
||
- настройка передачи файлов обмена из личного кабинета в 1С
|
||
- проверка получения каталога, остатков, заказов, статусов и задолженности
|
||
- проверка обработки дублей и ошибок обмена
|
||
- проверка отображения даты актуальности данных
|
||
- итоговая проверка программного продукта в согласованном эксплуатационном контуре
|
||
- устранение критичных замечаний, препятствующих приемке
|
||
- передача пользовательской и эксплуатационной документации в согласованном объеме
|
||
- передача перечня ключевых сторонних компонентов
|
||
- оформление результата приемки
|
||
|
||
Результат этапа:
|
||
|
||
- работоспособный интеграционный обмен с 1С в согласованном объеме, если необходимые доступы и параметры обмена предоставлены заказчиком
|
||
- журналирование ключевых интеграционных событий
|
||
- размещенный программный продукт в согласованном эксплуатационном контуре
|
||
- пользовательская и эксплуатационная документация в согласованном объеме
|
||
- перечень ключевых сторонних компонентов
|
||
- акт приемки выполненных работ
|
||
|
||
Критерий завершения этапа: подписание акта приемки либо наступление условий приемки, предусмотренных договором.
|
||
|
||
= Порядок контроля, приемки и гарантийного сопровождения
|
||
|
||
|
||
== Общие положения приемки
|
||
|
||
|
||
Приемка результата работ должна подтверждать соответствие программного продукта требованиям настоящего технического задания, условиям договора и согласованным требованиям заказчика.
|
||
|
||
При приемке подлежат проверке:
|
||
|
||
- клиентский контур
|
||
- менеджерский контур
|
||
- каталог готовой продукции
|
||
- сценарии заявок на заказ
|
||
- сценарии заявок на расчет
|
||
- сопровождение заказов
|
||
- уведомления
|
||
- бонусный и реферальный контур
|
||
- интеграционный обмен с 1С в согласованном объеме
|
||
- пользовательская и эксплуатационная документация в согласованном объеме
|
||
|
||
== Виды проверок
|
||
|
||
|
||
Для контроля результата работ используются следующие виды проверок:
|
||
|
||
- функциональная проверка основных пользовательских сценариев
|
||
- проверка разграничения ролей и прав доступа
|
||
- проверка корректности данных, статусов и истории изменений
|
||
- проверка интерфейсов на desktop и mobile
|
||
- проверка уведомлений по согласованным каналам
|
||
- проверка интеграционного обмена с 1С
|
||
- проверка запуска и работы сервисов в согласованном эксплуатационном контуре
|
||
|
||
== Критерии приемки
|
||
|
||
|
||
Программный продукт считается соответствующим требованиям, если:
|
||
|
||
- обязательные пользовательские сценарии выполняются корректно
|
||
- разграничение ролей и прав доступа реализовано корректно
|
||
- заявкам, заказам и бонусным операциям присваиваются и отображаются корректные статусы
|
||
- каталог и остатки отображаются корректно
|
||
- цена не отображается клиенту до публикации условий менеджером
|
||
- менеджер имеет возможность обработать заявку и опубликовать условия
|
||
- история изменений сохраняется и доступна в предусмотренных сценариях
|
||
- сведения из 1С отображаются в согласованном объеме
|
||
- текущая задолженность клиента и дата актуальности данных отображаются при наличии этих сведений из 1С
|
||
- критичные дефекты, препятствующие выполнению основных сценариев, устранены до передачи результата
|
||
|
||
== Передаваемые материалы
|
||
|
||
|
||
В состав передаваемых заказчику материалов входят:
|
||
|
||
- программный продукт, размещенный в согласованном эксплуатационном контуре
|
||
- исходный код разработанных компонентов в репозитории проекта
|
||
- согласованная редакция настоящего технического задания
|
||
- пользовательская документация в согласованном объеме
|
||
- эксплуатационная документация в согласованном объеме
|
||
- интеграционная спецификация 1С, если точные форматы обмена фиксируются отдельно от настоящего технического задания
|
||
- перечень ключевых сторонних компонентов, сформированный на основании фактических файлов проекта
|
||
|
||
Технические схемы, модель данных, роли, архитектура, стек, состав сервисов и требования к интеграциям являются частью настоящего технического задания и не дублируются в отдельных документах без отдельного согласования сторон.
|
||
|
||
== Порядок фиксации замечаний
|
||
|
||
|
||
Каждое замечание, выявленное при приемке, должно содержать:
|
||
|
||
- описание проблемы
|
||
- сценарий воспроизведения
|
||
- ожидаемый результат
|
||
- фактический результат
|
||
- уровень критичности
|
||
- статус устранения
|
||
|
||
Замечания, не препятствующие выполнению основных пользовательских и интеграционных сценариев, могут быть зафиксированы сторонами для последующего устранения в согласованном порядке.
|
||
|
||
== Гарантийный срок
|
||
|
||
|
||
Гарантийный срок на разработанные модули, сервисы и дополнительный функционал составляет 6 месяцев с даты подписания акта приемки выполненных работ, если иной порядок не согласован сторонами.
|
||
|
||
Гарантия распространяется на дефекты разработанного программного продукта, проявившиеся при штатной эксплуатации и относящиеся к функционалу, реализованному исполнителем.
|
||
|
||
== Первичная проверка гарантийного случая заказчиком
|
||
|
||
|
||
До направления гарантийного обращения заказчик выполняет первичную проверку на своей стороне и исключает причины, не относящиеся к разработанному программному продукту.
|
||
|
||
В рамках первичной проверки заказчик проверяет:
|
||
|
||
- доступность сервера, контейнеров, базы данных и сетевой инфраструктуры, на которых размещен программный продукт
|
||
- работоспособность домена, DNS, TLS-сертификатов, reverse proxy и иных инфраструктурных компонентов заказчика
|
||
- наличие необходимых ресурсов сервера, включая доступное место, память и процессорную нагрузку
|
||
- корректность переменных окружения, секретов, токенов и доступов, которые находятся в зоне ответственности заказчика
|
||
- доступность и корректную работу 1С, внешних API, почтового сервиса, Telegram, Max и иных внешних систем
|
||
- отсутствие изменений в форматах, правах доступа, настройках интеграций и учетных данных внешних систем
|
||
- отсутствие самостоятельных изменений кода, конфигурации, базы данных или инфраструктуры без согласования с исполнителем
|
||
- воспроизводимость проблемы на конкретном пользовательском сценарии
|
||
|
||
Если по итогам первичной проверки заказчик предполагает, что причина относится к разработанному исполнителем функционалу, заказчик направляет гарантийное обращение исполнителю.
|
||
|
||
== Порядок гарантийного обращения
|
||
|
||
|
||
Гарантийное обращение должно быть передано исполнителю в письменной форме или иным согласованным сторонами способом после первичной проверки на стороне заказчика.
|
||
|
||
В обращении должны быть указаны:
|
||
|
||
- описание дефекта
|
||
- пользовательская роль или контур, в котором проявляется дефект
|
||
- шаги воспроизведения
|
||
- ожидаемый результат
|
||
- фактический результат
|
||
- дата и время обнаружения
|
||
- результат первичной проверки на стороне заказчика
|
||
- сведения о состоянии сервера, контейнеров, базы данных и внешних систем, если они связаны с проявлением дефекта
|
||
- дополнительные материалы, если они нужны для диагностики
|
||
|
||
Исполнитель выполняет диагностику обращения в пределах разработанного им функционала. Если по результатам диагностики дефект относится к гарантийной зоне ответственности исполнителя, исполнитель устраняет его без дополнительной оплаты.
|
||
|
||
Если по результатам диагностики причина связана с инфраструктурой заказчика, внешними системами, изменением доступов, изменением форматов обмена, настройками 1С, почтовыми или мессенджерными сервисами, такое обращение не считается гарантийным дефектом программного продукта.
|
||
|
||
Срок устранения гарантийного дефекта составляет не более 3 дней с даты получения полного обращения, содержащего сведения, достаточные для воспроизведения и диагностики дефекта, либо иной срок, согласованный сторонами с учетом критичности и характера дефекта.
|
||
|
||
== Ограничения гарантийного сопровождения
|
||
|
||
|
||
Гарантийное сопровождение не распространяется на случаи, когда некорректная работа вызвана:
|
||
|
||
- самостоятельным изменением программного продукта заказчиком или третьими лицами без согласования с исполнителем
|
||
- ошибками сервера, хостинга, инфраструктуры или базы данных, не связанными с разработанным функционалом
|
||
- атакой, компрометацией доступа или нарушением требований информационной безопасности со стороны заказчика
|
||
- некорректной работой стороннего программного обеспечения
|
||
- недоступностью или некорректной работой внешних систем, включая 1С, Telegram, Max, почтовые сервисы и иные внешние API
|
||
- изменением форматов или правил работы внешних систем без предварительного согласования и обновления интеграционной спецификации
|
||
|
||
Если дефект связан с внешней системой или инфраструктурой, исполнитель фиксирует результат диагностики и передает заказчику сведения, достаточные для дальнейшего устранения причины на стороне соответствующей системы или поставщика.
|