Нода 0.4.1, ядро ЛДО 6.9. Поиск использует общие возможности ядра и локальные разрешения вашей базы. Совместимость ноды и ядра.
Как устроен поиск
Два действия основной ноды: Search Documents и Search Catalog Items. Типы объектов и фильтры нода получает из capabilities подключённой базы. Общий обработчик не содержит имён документов, справочников или реквизитов конкретной конфигурации. Стандартные поля берутся из метаданных 1С; дополнительные фильтры задаются локальной политикой администратора.
| Тип | Стандартные фильтры | Дополнительные фильтры |
|---|---|---|
| Документ | Номер, календарная дата или период | Например организация: явное отображение на ссылочный реквизит |
| Справочник | Наименование, код | Например ИНН: явное отображение на строковый реквизит |
Поддерживаются string/date/number/reference. Для числового номера или кода используется точное числовое сравнение; для строкового сохраняются префикс и ведущие нули. Даты — календарные дни в часовом поясе сеанса 1С.
Разрешение в 1С
В настройках «ЛДО Интеграции → Доступ к данным» есть таблица с колонками «Разрешить поиск», «Объект», «Тип объекта». Разрешение устанавливается отдельно для каждого типа и применяется общей командой обновления доступа n8n. По умолчанию поиск выключен. Сам выбор типа или просмотр метаданных доступа не предоставляют.
Search-grant независим от записи и от чтения по известному ID. Например, можно разрешить поиск и его минимальный результат, не разрешая Update Fields. Для следующего Get Fields нужно отдельно разрешить обычное чтение. Штатные права текущего пользователя и RLS продолжают действовать.
Дополнительные фильтры настраиваются в JSON-профиле режима интегратора. Пример с заменяемыми именами метаданных, не готовый профиль конфигурации:
{
"object_type": "catalog.YourDirectory",
"metadata_kind": "catalog",
"metadata_name": "YourDirectory",
"read_fields": ["name", "code"],
"search": {
"filters": [
{"id": "name", "attribute": "Наименование", "value_type": "string", "match_modes": ["exact", "contains", "startsWith"]},
{"id": "tax_number", "attribute": "YourTaxAttribute", "value_type": "string", "match_modes": ["exact"]}
],
"max_results": 200,
"max_period_days": 31
}
}
YourDirectory и YourTaxAttribute заменить реальными именами вашей базы.
Для ссылочного фильтра дополнительно задать reference.kind (catalog/document)
и reference.metadata_name. Сервер проверяет наличие реквизита и совместимость
типа. Клиент n8n получает ID фильтра, тип и разрешённые режимы; имена реквизитов
и локальный секрет курсора в capabilities не передаются.
JSON экспорт учитывает выбор в таблице поиска; изменение разрешений сохраняется только при явном применении доступа. Новая policy revision инвалидирует старые курсоры. Перезапуск исходного поиска получает новую политику автоматически.
Настройка ноды
- Выбрать транспорт и credential; для очереди — своё подключение.
- Выбрать Search Documents или Search Catalog Items и разрешённый тип.
- Добавить Filters: Filter Name or ID, Match, Value; для Between Dates — Last Day.
- Выбрать Result Mode: List либо Single Match.
- Для List указать Limit или включить Return All.
Для ссылочного фильтра Value — ID из предыдущего шага/внешней системы. Организацию также можно сначала найти отдельным Search Catalog Items, если такой тип и фильтры разрешены политикой.
Workflow без копирования UUID
Номер/дата из входного запроса
→ Search Documents (Single Match)
→ Get Document Fields
В следующей ноде:
// Document Type / Catalog Type
={{$json.object.type}}
// Document ID / Catalog Item ID
={{$json.object.id}}
// Expected Revision для записи
={{$json.revision}}
List возвращает отдельный output item на каждый объект; Split Out не нужен.
Результат содержит object, revision, разрешённые values и _ldo.
Найденный ID не предоставляет новых прав записи: следующая операция отдельно
проверяет разрешения и ожидаемую revision.
Пустые и неоднозначные результаты
- List без совпадений возвращает ноль items. Downstream шаги не запускаются.
- При необходимости отдельной ветки «не найдено» использовать Always Output Data и IF; пустой item без object.id не передавать в запись/PDF.
- Single Match при отсутствии объекта выдаёт object_not_found; при двух и более совпадениях — ambiguous_match. Первый результат автоматически не выбирается.
- Webhook с ответом от последней ноды требует отдельной настройки ответа на пустой результат; поведение HTTP webhook не меняет успешность самого поиска.
Лимиты и страницы
Размер страницы — 1–50, по умолчанию 20. Локальная политика ограничивает общий Return All максимумом до 200 объектов. Нода собирает страницы до выдачи результата; при превышении лимита возвращает search_limit_exceeded вместо частичного списка. Общее ожидание ограничено Timeout, включая последующие страницы.
_ldo.search.next_cursor позволяет продолжить List с теми же фильтрами.
Порядок документов: дата и ссылка; справочников: ссылка. Используется seek,
без OFFSET. Курсор проверяется по целостности и контексту профиля/политики/фильтров.
Single Match не использует курсор предыдущей страницы.
Для документов требуется точный строковый/числовой фильтр либо ограниченный период; префикс от трёх символов требует дополнительного селективного ограничения. Для справочников текстовый поиск от двух символов. Период ограничен политикой. Поиск не является снимком базы: между страницами объекты могут измениться.
Подключение и совместимость
Поиск использует те же настройки подключения, что и остальные операции ноды. Самостоятельная очередь и прямой HTTP не обращаются к MSRV.
Для поиска требуется совместимая пара ноды и ядра, указанная выше. Доступные фильтры определяются метаданными базы и разрешениями администратора. Через MSRV дополнительно нужна поддержка поисковых операций сервисом. Подробнее о совместимости.