Карточка объекта: A7 Потребитель (детально)
- Домен / источник данных: Grace CRM/ERP. OpenSearch (89):
itech_accounts(ядро),itech_projects(сделка = фаза ЖЦ),itech_contacts,itech_orders(стык с A8). Регламент:manager_crm_workflow.md(=rules_1.md, утв. 24.06.2024). Словарь:grace_concept_dictionary.md. - Бизнес-объект CoreStream: A7 Потребитель («Продвижение и продажи»).
- Экземпляр объекта = один
accountв роли Покупателя (type_id=1). ⚠️ Тот жеaccountв роли поставщика — это объект A6 (двойная роль, см. §4). - Дата / автор: 2026-06-19, сессия моделирования KB. Заземлено на структуру индексов от 04.05.2026.
Принцип: данные Grace = зёрна (экземпляры). Эта карточка = контекст, из которого разворачиваются процесс (методы) и метрики (corestream-metrics). Фиксируется в BookStack (книга A7 на полке «Коммерческий»), питает агентов через Onyx-теги.
1. Атрибуты (только подтверждённые реальными полями)
| Категория | Атрибут | Поле-источник | Тип | Замечание |
|---|---|---|---|---|
| Идентификаторы | ID контрагента | itech_accounts.id |
int | PK |
| Идентификаторы | ИНН | itech_accounts.inn |
keyword | юрлицо |
| Идентификаторы | Наименование | itech_accounts.name |
text | ru_standard |
| Состояния | Тип контрагента | account_types / type_id |
keyword | Покупатель=1 (роль в цепочке, НЕ теплота) |
| Состояния | Надёжность | reliability |
keyword | категория |
| Состояния | Теплота клиента | — | enum | ⚠️ Потенциальный/Холодный/Тёплый/Горячий/Покупатель/Спящий/Потерянный/Нулевой — НЕ синкнуто (см. §5) |
| Количественные | Кол-во сделок | project_count |
int | |
| Количественные | Кол-во заказов | order_count |
int | |
| Количественные | Выручка, млн | revenue_mln |
float | |
| Количественные | Оплачено / Долг, млн | paid_mln / debt_mln |
float | дебиторка |
| Качественные | Отраслевые сектора | sectors |
keyword | |
| Качественные | Роль покупателя | — | enum | Генподрядчик/ЭМК/Проектировщик/Системный интегратор/Заказчик — словарь accounts/get/roles; ⚠️ в индексе явного поля нет |
| Временные | Создан | created_at |
date | маркер фазы A7.1 |
| Временные | Последний заказ | last_order_at |
date | маркер активности (→ Спящий) |
Внешние (связи-ссылки): manager_id, owned_by_id, assistant_user_id → A5 Сотрудник.
2. Жизненный цикл — 6 фаз (A7.1 → A7.6)
Состояние A7 двухуровневое: теплота (уровень контрагента, ⚠️ не синкнута) и статус сделки itech_projects.project_status (уровень сделки, синкнут). Сделка = фаза ЖЦ потребителя, не отдельный объект.
| # | Фаза (A7.x) | Состояния объекта | Событие перехода дальше | Подтверждено полем |
|---|---|---|---|---|
| 1 | A7.1 Идентификация | Потенциальный (ИНН + роль) | внесены контактные данные | created_at; теплота ⚠️ нет поля; itech_contacts появляются |
| 2 | A7.2 Привлечение | Холодный→Тёплый→Горячий; сделка: Заявка на расчёт→Расчёт выполнен→Отправлено КП→Согласование договора | счёт переведён «в работу» | itech_projects.project_status, probability_percent, amount, forecast_date; itech_calculations.kp_exposed_at |
| 3 | A7.3 Обслуживание | Покупатель; сделка: Реализация→Закрытие | сделка закрыта / отгрузка | itech_orders.is_shipped, shipping_date_fact, project_status |
| 4 | A7.4 Оценка удовлетворённости | (удовлетворённость) | — | ⚠️ нет поля (в Grace «в разработке») |
| 5 | A7.5 Удержание | повторные продажи; риск Спящий | новая сделка / уход в Спящий | last_order_at, order_count; переход в Спящий ⚠️ не датирован |
| 6 | A7.6 Претензии / вывод | рекламация; Потерянный / Нулевой потенциал | закрытие отношений | itech_projects.refusal_reason; типы Потерянный/Нулевой — ⚠️ ручные, не синкнуты |
Исключения: отказ по сделке (refusal_reason, заполнен ~8%), Потерянный/Нулевой потенциал (менеджер вручную).
Спонтанные переходы: → Спящий автоматически при отсутствии активности > 3 мес (таймаут от last_order_at).
3. Методы (процессы объекта)
| Вид | Метод | Код CoreStream | След в данных |
|---|---|---|---|
| Конструктор | Создание контрагента (внести ИНН, роль) | A7.1 | insert itech_accounts + created_at |
| Адаптация | Квалификация, создание сделки, заявка на расчёт, КП | A7.2 | itech_projects, itech_calculations.kp_exposed_at |
| Использование | Договор, реализация, заказы | A7.3 | itech_orders (стык A8) |
| Валидация | Оценка удовлетворённости | A7.4 | ⚠️ нет следа |
| Воспроизводство | Повторные продажи, мониторинг активности | A7.5 | itech_comments, напоминания; last_order_at |
| Деструктор | Рекламации, перевод в Потерянный/Нулевой | A7.6 | refusal_reason; смена типа вручную |
Методы данных (бизнес-правила): теплота проставляется CRM автоматически по событиям (но не синкается в OpenSearch); вероятность и плановая дата обновляются менеджером 25-го числа каждого месяца (регламент) → свежесть probability_percent/forecast_date привязана к этой дате.
4. Связи
| С объектом | Тип | Характер | Поле/механизм | Атрибуты связи |
|---|---|---|---|---|
| A5 Сотрудник (менеджер) | ассоциация | двусторонняя асимм. | manager_id, owned_by_id |
ответственность |
| A8 Товар (заказ) | ассоциация | двусторонняя | itech_orders.account_id, project_id |
сумма, отгрузка |
| Контактное лицо | агрегация | — | itech_contacts.accounts (nested) |
должность, приоритет |
| Объект (здание) | ассоциация через Проект | — | itech_projects.property_id → itech_properties |
⚠️ соседний самостоятельный объект (объектный контур), НЕ атрибут A7. Один объект ↔ много компаний |
| A2 Бизнес-система (договор) | связь-договор | — | договор = ассоциация A7↔A2 | цена, сроки, оплата |
| A6 Поставщик (тот же account) | обобщение/полиморфизм | — | account_types=[1,2] |
один субъект — два объекта по роли |
Проект (
itech_projects) — это не объект, а интегрирующая связь (центральный узел функц. схемы): несёт фазы A7.2–A7.3 и соединяет A7 (компания) ↔ Объект (здание) ↔ A8 (заказ). Прямого ребра «Объект → Компания» нет — только через Проект. Поэтому «потребитель» = компания (свой ЖЦ продаж), а здание = место потребления (отдельный объект). Карта объектов →00_object_map.md.
5. Пробелы (не подтверждено данными — вход для Quality-агента / вопрос владельцу)
- Теплота клиента не синкнута (Потенциальный→…→Спящий нет в
itech_accounts) → воронку по теплоте из OpenSearch не построить; живёт только в Grace MySQL. Кандидат №1 на добавление в sync_agent. - Переходы теплоты не датированы → cycle time «сколько шёл от Холодного до Покупателя» не посчитать (нет таймстемпов фаз A7.1→A7.3 на уровне контрагента).
- A7.4 удовлетворённость — поля нет (Grace «в разработке»).
- Роль покупателя (Генподрядчик/ЭМК/…) — в индексе явного поля нет, только
sectors. status_updated_atвitech_projects= text и пуст ~53% → датировка переходов фаз сделки слабая.refusal_reasonзаполнен ~8% → причины ухода (A7.6) почти не аналитируемы.
→ Эти пробелы — реестр для аудита и чистки данных и список на обогащение синхронизации (sync_agent).
No comments to display
No comments to display