Энумы

Большинство ID в API ссылаются на справочники в БД. Значения могут отличаться между средами, поэтому в боевом коде надёжнее один раз дёрнуть list-endpoint и закэшировать map id → name. Ниже — снимки справочников + указатель «откуда брать живые значения».

Где взять актуальные значения

Поле в запросе	List-endpoint (GET)	Описание	Источник
`order_status_id`	`/api/order_statuses`	Статус заказа	таблица ниже
`delivery_type_id`	`/api/delivery_types`	Способ доставки	динамический
`payment_type_id`	`/api/payment_types`	Способ оплаты	динамический
`counterparty_type_id`	`/api/counterparty_types`	Тип контрагента (физ/юр/розница…)	таблица ниже
`file_type_id`	`/api/file_types`	Тип файла	таблица ниже (хардкод)
`role_id` (user)	`/api/roles`	Роль сотрудника	таблица ниже
`permission ids`	`/api/permissions`	Право доступа	таблица ниже
`screen.id`	— (возвращается в permissions)	Экран в админке	таблица ниже
`department_id`	`/api/departments`	Отдел	динамический
`category_id`	`/api/categories`	Категория номенклатуры	динамический
`brand_id`	`/api/brands`	Бренд	динамический
`country_id`	`/api/countries`	Страна	динамический
`city_id`	`/api/cities`	Город	динамический
`vat_id`	`/api/vats`	Ставка НДС	динамический
`sales_channel_id`	`/api/sales_channels`	Канал продаж	динамический
`sales_strategy_id`	`/api/sales_strategies`	Стратегия продаж	динамический
`nomenclature_type_id`	`/api/nomenclature_types`	Тип номенклатуры	динамический
`nomenclature_kind_id`	`/api/nomenclature_kinds`	Вид номенклатуры	динамический
`object_id`	`/api/objects`	Объект	динамический
`unit_id`	`/api/units`	Единица измерения	динамический

Статусы заказа

10 значений из дефолтного seed’а (database/seeders/OrderStatusSeeder.php в itecho-erp-backend) — это проектно-производственная вертикаль. ID могут разниться между средами, поэтому для отображения fetch’и через /api/order_statuses. Источник в event_ai: src/utils/orderStatusTone.ts.

⚠ Для e-commerce / оплаты — другие статусы. Платёжный поток (YooKassa) использует захардкоженные ID: 2 = ожидание оплаты, 22 = оплачен, 6 = отменён. Для отслеживания оплаты ориентируйтесь на эти ID, а не на названия из таблицы ниже. См. полную таблицу констант в erp-rules §12.1.

Название	Tone	Семантика
`Расчёт`	neutral	Заказ в работе, формируется КП
`Коммерческое предложение`	info	Отправлено КП клиенту
`Счёт`	info	Выставлен счёт
`Ожидание оплаты`	info	Ждём оплату
`Замер`	info	Замер на объекте
`Ожид. матер.`	info	Ожидание материалов
`Производство`	info	Производство
`Доставка`	info	Доставка клиенту
`Монтаж`	info	Монтаж у клиента
`Приёмка`	pos	Приёмка работ, финал

Tone — внутренний маркер для UI:

Tone	Значение	CSS-переменная
`neutral`	Нейтрально	`--gg-ink-500`
`info`	В процессе	`--gg-accent`
`pos`	Успех / завершено	`--gg-pos`
`neg`	Отменено / ошибка	`--gg-neg`

Эвристика для нестандартных статусов (тот же файл):

содержит отмен → neg
содержит готов, выполн, оплач → pos
содержит работе, процессе, ожидан → info
иначе → neutral

Типы файлов

Хардкод в event_ai/src/constants/file-types.ts — стабильные ID, можно полагаться:

ID	Название	Константа в TS	Когда
1	Трудовой договор	`EMPLOYMENT_CONTRACT_ID`	Документы сотрудника
2	Аватар	`AVATAR`	Аватар пользователя/контрагента
3	Файл заказа	`ORDER_FILE`	Вложения к заказу (`POST /api/orders/{id}/files`)

Полный список — GET /api/file_types. Используется в file_type_id при POST /api/files.

Типы контрагентов

Дефолтный seed (наблюдалось в JSON-примерах):

ID	Название	Назначение
1	Юр. лицо	`is_company: true`
2	Розница	`is_company: false`

Эти ID могут различаться между установками. Перед созданием контрагента — GET /api/counterparty_types.

Роли сотрудников

Известны из JSON-примеров /api/user. Полный список — GET /api/roles.

ID	`name` (slug)	`description`
1	`owner`	Собственник
3	`manager`	Руководитель отдела
4	`accountant`	Бухгалтер

ID 2 не встречался в примерах — вероятно admin или схожая роль. Проверьте через /api/roles.

Права доступа (permissions)

Известны из JSON-примеров /api/user. Используются в массиве user.permissions[]. Полный список — GET /api/permissions.

ID	`name`	`description`	Screen
2	`edit-admins`	Редактирование администраторов	—
4	`edit-users`	Редактирование пользователей	—
5	`edit-roles`	Редактирование ролей	—
6	`edit-permissions`	Редактирование прав доступа	—
7	`edit-branches`	Редактирование филиалов	—
8	`edit-departments`	Редактирование отделов	—
10	`edit-counterparties`	Редактирование контрагентов	Контрагенты (1)
12	`edit-communications`	Редактирование коммуникаций	—
14	`edit-orders`	Редактирование заказов	Заказы (2)
16	`edit-tasks`	Редактирование задач	Задачи (3)

Список не полный — гэпы (ID 1, 3, 9, 11, 13, 15) указывают на ещё ~6 прав. ID 1 вероятно view-… или базовое право; ID 3, 9, 11, 13, 15 — соседние «view-» к парным `edit-`.

Экраны (screens)

Возвращается во вложенном объекте permission.screen. Получить полный список — GET /api/screens.

ID	Название
1	Контрагенты
2	Заказы
3	Задачи

Связаны с правами через permission.screen.id (см. таблицу выше).

Тоны истории (color)

Используется в histories[].color / counterparties.data[].color (events). 8 значений из стандартного Material-набора:

Значение	Семантика
`primary`	Основное действие
`secondary`	Вторичное действие
`info`	Информация
`success`	Успех
`warning`	Предупреждение
`error`	Ошибка
`dark`	Тёмный нейтральный
`light`	Светлый нейтральный

См. JSON-пример в ERP/Контрагенты → история и ERP/Бизнесы → история.

Что НЕ нужно угадывать

Поля, в которые передаётся ID из любого справочника выше, обязательно сначала проверять через list-endpoint — даже если значение видели в JSON-примере доки. Снимки справочников на этой странице сделаны в апреле 2024 и могут устареть.

Безопасно:

GET /api/order_statuses HTTP/1.1
Host: api.gigma.ru
Authorization: Bearer <token>
Accept: application/json

→ { "orderStatuses": [{ "id": 1, "name": "Расчёт", ... }, ...], "orderStatusesCount": 10 }

Полученный map сохраняется на стороне клиента и используется в каждом запросе создания заказа.