Динамические поля и расширенный поиск
[[search.extended_fields]] индексируются и участвуют в поиске только в PRO-сборке. В Free-режиме секция [[search.extended_fields]] игнорируется; произвольные атрибуты можно индексировать через enable_attrs_indexing (см. раздел «Произвольные поля (attrs)» ниже).
Представьте: вам нужно найти всех поставщиков, у которых есть товар с определенным кодом ТН ВЭД, или найти все позиции конкретного бренда. Вы не знаете точное название — знаете только характеристики. Сервис ищет по ним, даже если name пустой.
Как это работает: два режима
В конфиге есть два ключевых параметра, которые управляют расширенным поиском:
true— сервис индексирует и ищет по дополнительным полям (бренд, поставщик, цвет, размер и т.д.)false— секция[[search.extended_fields]]игнорируется
false. Во встроенных production-конфигах (deployment/sku-pro/config.toml) параметр установлен в true.
true(режим совместимости по умолчанию) — нечеткий поиск поnameтребует непустогоname. Поиск ТОЛЬКО по динамическим полям приname = ""работает независимо от этого флагаfalse— разрешает нечеткий поиск поnameдаже с пустымname(полностью коммерческий режим)
supplier, brand, tnved и другим расширенным полям работает при любом значении, если extended_search_enabled = true.
Таблица режимов работы
extended_search_enabled | require_name_for_fuzzy | Что получаем | Когда использовать |
|---|---|---|---|
false | true или false | Базовые поля (name, code, barcode, art) + attrs при enable_attrs_indexing = true. Расширенные поля [[search.extended_fields]] не используются | Простая база, не нужны доп. реквизиты |
true | true | Расширенные поля работают как доп. фильтр; нечеткий поиск по name требует непустого name. Поиск только по динамическим полям при name = "" работает | Нужны доп. характеристики, но название всегда известно |
true | false | ПОЛНЫЙ КОММЕРЧЕСКИЙ РЕЖИМ — можно искать ТОЛЬКО по динамическим полям; нечеткий поиск по name также доступен с пустым name | Поставщики, бренды, ТН ВЭД, характеристики — название не требуется |
Что такое динамические поля и как их настроить
Динамические поля — это любые дополнительные реквизиты товара. Например:
supplier— поставщик ("ООО Ромашка")brand— бренд ("Bosch", "Samsung")tnved— код ТН ВЭД (для таможни)color— цвет ("красный", "синий")size— размер ("42", "XL")diagonal— диагональ телевизора ("55")material— материал ("нержавеющая сталь")
Главная особенность: разные товары могут иметь РАЗНЫЕ наборы полей. Обувь — цвет и размер. Холодильники — диагональ и бренд. Сервис индексирует только те поля, которые есть у конкретного товара. Поиск работает по любым полям, независимо от их наличия у других товаров.
Настройка в config.toml
# Включаем расширенный поиск
[search]
extended_search_enabled = true
require_name_for_fuzzy = false # ← коммерческий режим
# Описываем все возможные поля (один раз для всей базы)
[[search.extended_fields]]
field = "supplier" # Имя поля в JSON
weight = 0.7 # Сохраняется в конфиге; в текущей версии не влияет на FS-ранжирование
stemmed = true # Приводить к основе слова ("поставщики" → "поставщик")
fuzzy = true # Разрешить опечатки ("Ромашкаа" → "Ромашка")
[[search.extended_fields]]
field = "tnved"
weight = 0.9 # Сохраняется в конфиге; в текущей версии не влияет на FS-ранжирование
stemmed = false # Код должен совпадать ТОЧНО
fuzzy = false
[[search.extended_fields]]
field = "size"
weight = 0.4 # Сохраняется в конфиге; в текущей версии не влияет на FS-ранжирование
stemmed = false
fuzzy = true
[[search.extended_fields]]
field = "color"
weight = 0.3 # Сохраняется в конфиге; в текущей версии не влияет на FS-ранжирование
stemmed = true
fuzzy = true
Параметры поля ([[search.extended_fields]])
/api/search-config, но в текущей версии не используется при вычислении итогового скора в FS-поиске. Ранжирование по динамическим полям определяется глобальными настройками [search.weights] и фиксированными бустами.
- Для кодов (tnved, артикулы производителя): 0.8-1.0 — точное совпадение критично
- Для названий (бренд, поставщик): 0.5-0.7 — важно, но не фатально
- Для характеристик (цвет, размер): 0.3-0.5 — уточняющие параметры
true: "поставщики", "поставщиком", "поставщиках" → все найдет "поставщик"false: только точное совпадение (для кодов, артикулов)
true: "Ромашкаа" найдет "Ромашка", "Samsng" найдет "Samsung"false: только точное совпадение
Сценарии использования с примерами
Сценарий 1: Поиск всех товаров поставщика
Найти все товары от "ООО Ромашка", даже не зная названий:
curl -X POST http://localhost:8080/find \
-H "Content-Type: application/json" \
-d '{
"items": [{
"name": "",
"supplier": "ООО Ромашка"
}],
"limit": 50
}'
# Тот же запрос через CLI
sku-cli search "" --field supplier="ООО Ромашка" --dynamic-only --limit 50
Сценарий 2: Фильтрация по характеристикам
Найти все телевизоры Samsung с диагональю 55 дюймов:
curl -X POST http://localhost:8080/find \
-H "Content-Type: application/json" \
-d '{
"items": [{
"name": "",
"brand": "Samsung",
"diagonal": "55"
}],
"limit": 20
}'
# Тот же запрос через CLI
sku-cli search "" --field brand="Samsung" --field diagonal="55" --dynamic-only --limit 20
Сценарий 3: Поиск по коду ТН ВЭД
Точный поиск по классификатору (без опечаток, точное совпадение):
curl -X POST http://localhost:8080/find \
-H "Content-Type: application/json" \
-d '{
"items": [{
"name": "",
"tnved": "7307 19 100 0"
}]
}'
# Тот же запрос через CLI
sku-cli search "" --field tnved="7307 19 100 0" --dynamic-only
Сценарий 4: Смешанный поиск (название + характеристики)
Ищем красные кроссовки 42 размера:
curl -X POST http://localhost:8080/find \
-H "Content-Type: application/json" \
-d '{
"items": [{
"name": "кроссовки",
"color": "красный",
"size": "42"
}],
"limit": 10
}'
# Тот же запрос через CLI
sku-cli search "кроссовки" --field color="красный" --field size="42" --limit 10
Сценарий 5: Пакетный поиск для сверки с прайсом поставщика
Загружаете прайс от поставщика и хотите найти, какие товары уже есть в вашей базе:
curl -X POST http://localhost:8080/find \
-H "Content-Type: application/json" \
-d '{
"items": [
{"name": "", "supplier_code": "ART-001"},
{"name": "", "supplier_code": "ART-002"},
{"name": "", "supplier_code": "ART-003"}
],
"limit": 1
}'
Как это работает внутри (для понимания)
- Настройка полей в конфиге — вы описываете все возможные поля один раз. Сервис запоминает их.
- Загрузка товара — вы отправляете товар с любым набором полей. Сервис индексирует ТОЛЬКО те поля, которые есть у этого товара.
- Поиск — вы отправляете запрос с любыми полями. Сервис ищет среди товаров, у которых эти поля есть. Если поля нет у товара — он просто не попадет в результаты.
- Точные совпадения —
id,barcode,code,art(1-2 мс) - Точные совпадения по динамическим полям —
supplier,tnvedи т.д. (1-2 мс) - Нечеткий поиск — по названию и динамическим полям (3-10 мс)
color и brand), сервис вернет только товары, у которых совпали ВСЕ указанные поля. ExtendedField.fuzzy определяет, разрешен ли нечеткий поиск для конкретного поля.
Пример: разные товары — разные поля
Представьте, что у вас в базе есть и обувь, и холодильники. У них совершенно разные характеристики:
# Загружаем кроссовки (есть цвет, размер, бренд)
{
"id": "SHOE-001",
"name": "Кроссовки спортивные",
"color": "красный",
"size": "42",
"brand": "Nike"
}
# Загружаем холодильник (есть бренд, диагональ, объем)
{
"id": "FRIDGE-001",
"name": "Холодильник Side-by-Side",
"brand": "Samsung",
"diagonal": "55",
"volume": "600"
}
Что получится при поиске:
- Запрос
{"color": "красный"}→ найдет ТОЛЬКО кроссовки - Запрос
{"diagonal": "55"}→ найдет ТОЛЬКО холодильник - Запрос
{"brand": "Samsung"}→ найдет холодильник (и ничего больше) - Запрос
{"color": "красный", "brand": "Samsung"}→ ничего не найдет (нет товара, у которого есть оба поля)
Частые ошибки и как их исправить
Решение: Проверьте, что extended_search_enabled = true и поля описаны в [[search.extended_fields]]. Поиск только по динамическим полям работает независимо от require_name_for_fuzzy. Если же нужен нечеткий поиск по пустому name — установите require_name_for_fuzzy = false.
Решение: Проверьте, описано ли поле в [[search.extended_fields]]. Если поле не описано — оно не индексируется и не участвует в поиске.
Решение: Проверьте настройки стемминга и fuzzy, а также глобальные веса в секции [search.weights] (см. config.md). Индивидуальный параметр weight в [[search.extended_fields]] в текущей версии не влияет на ранжирование.
Решение: Включите fuzzy = true для этого поля. Без него только точные совпадения.
Рекомендации для коммерческого внедрения
- Включите
extended_search_enabled = true - Опишите ВСЕ поля, которые есть в вашей базе (даже если они есть не у всех товаров)
- Для коммерческого режима установите
require_name_for_fuzzy = false - Настройте стемминг и fuzzy-логику полей в зависимости от их важности:
- Ключевые идентификаторы (ТН ВЭД, артикул производителя) →
stemmed = false,fuzzy = false - Бренд, поставщик →
stemmed = true,fuzzy = true - Характеристики (цвет, размер) →
stemmed = false или true(по ситуации),fuzzy = true
- Ключевые идентификаторы (ТН ВЭД, артикул производителя) →
- Протестируйте поиск: отправьте запросы, которые реально делают ваши операторы
- При необходимости скорректируйте глобальные веса в секции
[search.weights](см.config.md)
Произвольные поля (attrs) — Атрибуты и реквизиты 1С
Для разработчиков и аналитиков: В 1С у номенклатуры могут быть сотни произвольных реквизитов (цвет, материал, ГОСТ, гарантия, страна и т.д.). Сервис умеет автоматически индексировать и искать по ним, даже если они не описаны в конфиге явно.
Как это работает под капотом: API → Индекс
При загрузке товара через POST /add вы передаете произвольные ключи плоско, на одном уровне с name, id, code (они попадают в ItemQuery.extra благодаря #[serde(flatten)]). Не заворачивайте их во вложенный объект extra — это вызовет ошибку 422. Сервис автоматически разделяет их на два потока индексации:
attrs— для точной фильтрации. Идеально для кодов, размеров, артикулов производителей, нормативных документов.attrs_flat— для нечеткого и стеммированного поиска. Сервис склеивает значения в строку, применяет стеммер и стоп-слова. Идеально для названий брендов, материалов, характеристик.
Важно: Механизм управляется параметром enable_attrs_indexing в секции [search]. При false произвольные поля игнорируются на уровне индексации.
Настройка в config.toml
| Параметр | Тип | По умолчанию | Описание |
|---|---|---|---|
enable_attrs_indexing | bool | false | Включить индексацию произвольных полей. true активирует двойную запись: attrs (точное) + attrs_flat (текстовое). |
search.weights.attrs_exact_weight | f32 | 1.0 | Множитель к скору при точном совпадении по JSON-атрибутам (динамическим extra-полям). |
search.weights.attrs_flat_weight | f32 | 0.7 | Вес текстового буста через плоские атрибуты. Влияет на скор при нечетком/тематическом поиске по характеристикам. |
Пример загрузки товара с атрибутами
curl -X POST http://localhost:8080/add \
-H "Content-Type: application/json" \
-d '{
"items": [{
"name": "Болт М16х60",
"id": "1C-GUID-0001",
"code": "BOLT-16-60",
"color": "оцинкованный",
"material": "сталь 35",
"gost": "7798-70",
"warranty_months": "24",
"manufacturer": "Уралметиз"
}]
}'
Что произойдет внутри сервиса:
- Известные поля (
name,id,code) пойдут в стандартные индексы. - Остальные поля (
color,material,gostи др.) автоматически попадут вattrs(для точного поиска) иattrs_flat(для текстового поиска с учетом опечаток и словоформ). - Авто-фильтрация мусора: Поля с техническими значениями (только цифры, символы
- . / пробел _ </code>, GUID, внутренние коды 1С) и значения короче 2 символов не участвуют в полнотекстовом поиске: они пропускаются изattrs_flat. Однако после версии с исправлением ATTR-001 они все равно сохраняются в JSONattrsи возвращаются в ответе — это позволяет использовать их как точный фильтр (например,"size": "42"или"internal_code": "000000042").
Как искать по атрибутам
Сервис автоматически ищет по attrs_flat, если вы передаете текст в запросе. Для точной фильтрации по конкретному атрибуту передавайте ключ в теле запроса:
# Поиск товаров из "стали 35" (с учетом опечаток: "сталь", "стл", "стали 35")
curl -X POST http://localhost:8080/find \
-H "Content-Type: application/json" \
-d '{"items": [{"name": "", "material": "сталь"}], "limit": 10}'
# Точный поиск по ГОСТу (через attrs JSON, без стемминга и fuzzy)
curl -X POST http://localhost:8080/find \
-H "Content-Type: application/json" \
-d '{"items": [{"name": "", "gost": "7798-70"}], "limit": 5}'
# Комбинированный запрос: название + произвольный атрибут
curl -X POST http://localhost:8080/find \
-H "Content-Type: application/json" \
-d '{"items": [{"name": "болт", "color": "оцинк"}], "limit": 20}'
Совет: При включенном enable_attrs_indexing атрибуты участвуют в поиске автоматически. Вам не нужно описывать их в [[search.extended_fields]], если не требуется индивидуальная настройка веса, стемминга или fuzzy-логики.
Ограничения и рекомендации для продакшена
- Рост индекса: Индексация
attrsиattrs_flatувеличивает размер индекса на ~10-15%. Для баз >1 млн позиций с редким поиском по реквизитам рекомендуетсяfalse. - Приоритет полей: Если поле явно описано в
[[search.extended_fields]], оно будет индексироваться строго по правилам конфига и не попадет в автоматическийattrs_flat. - Post-фильтрация: Результаты, найденные через
attrs, проходят строгую проверку на совпадение ключ-значение. Если в запросе"gost": "7798-70", товар с"gost": "7798"не пройдет фильтр, даже если скор высокий. - Производительность: Поиск по
attrs_flatиспользует тот же стеммер и стоп-слова, что иname. Убедитесь, что отраслевой шум (упак, кор, шт) добавлен вstopwords.txt.
Что класть в extra, а что нет
Произвольные атрибуты удобны для коротких характеристик товара. Но не все стоит туда складывать — важно понимать, что попадает в поисковый индекс, а что только хранится.
Подходит для extra:
- Краткие характеристики:
color,size,brand,material,gost,country,warranty. - Идентификаторы, которые нужны в ответе или как фильтр:
supplier_code,internal_code,oem,serial. - Короткие текстовые метки и теги:
series,line,segment. - Значения, по которым может искать оператор:
diagonal,voltage,weight.
Не подходит для extra:
- Большие тексты документов (текст договора, ТЗ, спецификации, инструкции). Они сохранятся, но и будут токенизироваться в индексе — индекс сильно разрастется, а поиск замедлится.
- Бинарные данные в base64, JSON-объекты, HTML-разметка.
- Длинные табличные данные (например, прайс-лист внутри одного поля).
- Поля, которые нужно искать по диапазонам: даты, цены (если требуется «от/до»).
Правило: если значение больше пары строк или им не ищут как по обычному слову — храните его в 1С / файловом хранилище / S3, а в SKU Search передавайте только метаданные и ключевые слова.
42), даты (2026-09-29), булевы значения (true) передаются JSON-корректно, но внутри сервиса и при сравнении они являются строками. Это значит: нет числовых операций («цена от 1000 до 2000»), нет диапазонов дат, нет математики. Если нужно искать по диапазону — используйте 1С или нормальную базу данных.
extra при включенном enable_attrs_indexing индексируются. Для таких сценариев используйте внешнее хранилище и передавайте в сервис только ссылку или краткое содержание.
Режимы фильтрации по extra
По умолчанию параметры extra работают как жесткий фильтр: товар не попадает в результаты, если хотя бы одно указанное поле не совпадает. Это поведение можно изменить без переиндексации.
| Параметр | Значение | Эффект |
|---|---|---|
search.extra_filter_mode = "hard" | По умолчанию | Точный фильтр: только товары со всеми совпавшими extra-полями. |
search.extra_filter_mode = "soft" | Требует enable_attrs_indexing = true | Совпадение по extra увеличивает скор, но не отсекает остальные товары. Силу буста задает search.weights.extra_match_boost. |
search.extra_filter_mode = "off" | Требует enable_attrs_indexing = true | extra игнорируется при поиске; поля по-прежнему сохраняются и возвращаются в ответе. |
Пример: мягкое бустирование по бренду
Допустим, оператор ищет "кроссовки" и хочет, чтобы товары Nike шли первыми, но не хочет терять Adidas:
# config.toml
[search]
enable_attrs_indexing = true
extra_filter_mode = "soft"
[search.weights]
extra_match_boost = 0.5
curl -X POST http://localhost:8080/find \
-H "Content-Type: application/json" \
-d '{"items": [{"name": "кроссовки", "brand": "Nike"}], "limit": 20}'
В ответе Nike будет выше, чем Adidas, но Adidas тоже останется в списке. При extra_filter_mode = "hard" в ответе остались бы только Nike.
"soft" и "off" работают только при enable_attrs_indexing = true. Если индексация атрибутов выключена, extra не влияет на поиск в любом режиме.
Кросс-коды (аналоги и заменители) — PRO only
Что это такое: Когда один товар можно заменить другим. Например, у вас есть оригинальная деталь "Болт М16х60 оцинкованный", а в базе есть три аналога от разных производителей. При поиске по артикулу ЛЮБОГО аналога — сервис вернет ВСЮ группу, и оператор увидит все доступные варианты.
Как это устроено в данных
При загрузке товаров вы указываете для каждого:
group_id— идентификатор группы аналогов (одинаковый для всех взаимозаменяемых товаров)is_original— является ли этот товар оригиналом (true/false)
# Загружаем группу аналогов
curl -X POST http://localhost:8080/add \
-H "Content-Type: application/json" \
-d '{
"items": [
{
"id": "DETAL-001",
"name": "Болт М16х60 оцинкованный оригинал",
"group_id": "GROUP-BOLT-001",
"is_original": true
},
{
"id": "DETAL-002",
"name": "Болт М16х60 оцинкованный аналог (Nord)",
"group_id": "GROUP-BOLT-001",
"is_original": false
},
{
"id": "DETAL-003",
"name": "Болт М16х60 оцинкованный аналог (DIN)",
"group_id": "GROUP-BOLT-001",
"is_original": false
}
]
}'
# Тот же запрос через CLI
# Создайте файл items.json:
[
{
"id": "DETAL-001",
"name": "Болт М16х60 оцинкованный оригинал",
"group_id": "GROUP-BOLT-001",
"is_original": true
},
{
"id": "DETAL-002",
"name": "Болт М16х60 оцинкованный аналог (Nord)",
"group_id": "GROUP-BOLT-001",
"is_original": false
},
{
"id": "DETAL-003",
"name": "Болт М16х60 оцинкованный аналог (DIN)",
"group_id": "GROUP-BOLT-001",
"is_original": false
}
]
sku-cli add items.json
Как это выглядит в ответе поиска
При поиске по любому из товаров группы вы получите оригинал + список аналогов:
{
"search_time_ms": 10,
"results": [{
"query": { "name": "болт м16" },
"matches": [{
"original": {
"name_out": "Болт М16х60 оцинкованный оригинал",
"id_out": "DETAL-001",
"group_id": "GROUP-BOLT-001",
"is_original": true,
"score": 0.94
},
"cross_codes": [
{
"name_out": "Болт М16х60 оцинкованный аналог (Nord)",
"id_out": "DETAL-002",
"score": 0.89,
"is_original": false
},
{
"name_out": "Болт М16х60 оцинкованный аналог (DIN)",
"id_out": "DETAL-003",
"score": 0.85,
"is_original": false
}
]
}]
}]
}
Настройка в config.toml
[pro.cross_codes]
enabled = true # Включить поддержку кросс-кодов
max_group_size = 30 # Максимум аналогов в ответе
include_in_response = true # Возвращать кросс-коды в /find
sort_within_group = true # Сортировать аналоги по релевантности
include_original_in_cross_list = false # Не дублировать оригинал в массиве аналогов
- 10 — для быстрых ответов (магазины)
- 30 — стандарт (рекомендуется)
- 50-100 — для автозапчастей (много аналогов)
Иерархия (BOM / Where-Used) — PRO only
pro.plugins.hierarchy.enabled = true. Для построения нетривиальных деревьев (связей parent_id) необходимо также включить pro.cross_codes.enabled = true; иначе /hierarchy вернет вырожденное дерево (root без детей).
Что это такое: Возможность строить деревья спецификаций (BOM — Bill of Materials) и находить, где используется деталь (Where-Used).
- "Вниз" (down) — берем готовое изделие и смотрим, из каких деталей оно состоит (разузлование)
- "Вверх" (up) — берем деталь и ищем, в каких изделиях она используется (где применяется)
Как это устроено в данных
При загрузке товаров вы указываете для каждого:
parent_id— ID родительского товара (для которого эта деталь является составной частью)
# Загружаем иерархию: Изделие → Деталь1 → Деталь2
curl -X POST http://localhost:8080/add \
-H "Content-Type: application/json" \
-d '{
"items": [
{
"id": "PROD-001",
"name": "Изделие (корневая сборка)",
"parent_id": null
},
{
"id": "PART-001",
"name": "Деталь А",
"parent_id": "PROD-001"
},
{
"id": "PART-002",
"name": "Деталь Б",
"parent_id": "PROD-001"
},
{
"id": "SUB-001",
"name": "Поддеталь А.1",
"parent_id": "PART-001"
}
]
}'
# Тот же запрос через CLI
# Создайте файл items.json:
[
{
"id": "PROD-001",
"name": "Изделие (корневая сборка)",
"parent_id": null
},
{
"id": "PART-001",
"name": "Деталь А",
"parent_id": "PROD-001"
},
{
"id": "PART-002",
"name": "Деталь Б",
"parent_id": "PROD-001"
},
{
"id": "SUB-001",
"name": "Поддеталь А.1",
"parent_id": "PART-001"
}
]
sku-cli add items.json
Пример 1: Разузлование (direction = "down")
Показать, из чего состоит изделие "PROD-001":
curl -X POST http://localhost:8080/hierarchy \
-H "Content-Type: application/json" \
-d '{
"root_id": "PROD-001",
"direction": "down",
"max_depth": 5,
"include_cross_codes": false,
"limit": 100
}'
Ответ (дерево):
{
"root": {
"name_out": "Изделие (корневая сборка)",
"id_out": "PROD-001"
},
"tree": {
"item": { "name_out": "Изделие (корневая сборка)", "id_out": "PROD-001" },
"level": 0,
"children": [
{
"item": { "name_out": "Деталь А", "id_out": "PART-001" },
"level": 1,
"children": [
{
"item": { "name_out": "Поддеталь А.1", "id_out": "SUB-001" },
"level": 2,
"children": []
}
]
},
{
"item": { "name_out": "Деталь Б", "id_out": "PART-002" },
"level": 1,
"children": []
}
]
},
"stats": {
"total_nodes": 4,
"max_depth_reached": 2,
"cross_codes_found": 0,
"elapsed_ms": 8
}
}
Пример 2: Where-Used (direction = "up")
Найти, где используется деталь "PART-001":
curl -X POST http://localhost:8080/hierarchy \
-H "Content-Type: application/json" \
-d '{
"root_id": "PART-001",
"direction": "up",
"max_depth": 5
}'
Ответ (цепочка родителей):
{
"root": {
"name_out": "Изделие (корневая сборка)",
"id_out": "PROD-001"
},
"tree": {
"item": { "name_out": "Изделие (корневая сборка)", "id_out": "PROD-001" },
"level": 0,
"children": [
{
"item": { "name_out": "Деталь А", "id_out": "PART-001" },
"level": 1,
"children": []
}
]
},
"stats": {
"total_nodes": 2,
"max_depth_reached": 1,
"elapsed_ms": 5
}
}
Пример 3: С включением кросс-кодов
При разузловании можно также получить аналоги для каждой детали:
curl -X POST http://localhost:8080/hierarchy \
-H "Content-Type: application/json" \
-d '{
"root_id": "PROD-001",
"direction": "down",
"include_cross_codes": true
}'
Ответ (с аналогами):
{
"tree": {
"item": { ... },
"cross_codes": [], // у корневого изделия может не быть аналогов
"children": [
{
"item": { "name_out": "Деталь А", "id_out": "PART-001" },
"cross_codes": [
{ "name_out": "Деталь А аналог (Nord)", "id_out": "PART-001-ALT" }
],
"children": [ ... ]
}
]
}
}
Настройка в config.toml
[pro.plugins.hierarchy]
enabled = true # Включить плагин иерархии
default_max_depth = 5 # Максимальная глубина по умолчанию
default_limit = 1000 # Лимит узлов в ответе
include_cross_codes_by_default = false # Включать кросс-коды по умолчанию
Когда это нужно
| Сценарий | Что делаем | Направление |
|---|---|---|
| Производство (спецификация изделия) | Показать из каких деталей состоит продукт | down |
| Ремонт (запчасти) | Найти, в каких изделиях используется деталь | up |
| Закупки | При поиске аналога детали — показать все родительские изделия | down + include_cross_codes |
| Конструкторская документация | Экспорт полного дерева в JSON или CSV | down |