tools/sp/README.md

@@ -112,14 +112,33 @@ claims-логине частей будет четыре. Разбирать с
 
 Отличить «managed property нет вовсе» от «есть, но у строк пусто» через
 `SelectProperties` НЕЛЬЗЯ — на несуществующее имя ответ молча приходит с `null`.
-Отличается сортировкой: `SortList` по несуществующему свойству падает ошибкой
-400/500, по существующему — работает.
+**И `SortList` для этого не годится тоже**, хотя соблазнительно: `Sortable` — флаг,
+независимый от `Retrievable`, и у автосозданных `ows_*` свойств он обычно выключен.
+`SortList` падает 400/500 и на заведомо живом `PositionOWSTEXT`, то есть меряет не то.
+Рабочий способ — сверять Search с REST на одних и тех же элементах, это делает
+`sp-write props` (репозиторий `C:\work\git\tools`).
 
-При этом рядом в тех же списках нормально отдаются `PositionOWSTEXT`,
-`RequestStatusOWSCHCS`, `SelectionRequestIdOWSNMBR`, `SelectionRequestListIdOWSTEXT`,
-`SubmitDateOWSDATE`, `TansuSiteApproverOWSUSER` — то есть это не про тип колонки и не
-про задержку crawl (у свежесозданных элементов рабочие поля появляются, а эти нет).
-Из-за этого отчёт по вакансиям в `tnsu-approval-route` остался на items REST по
+**Корневая причина (нашлась 2026-08-28): одноимённые колонки в разных списках — это
+РАЗНЫЕ поля.** У каждого свой GUID, значит и своё crawled property (`ows_Position`,
+`ows_Position1`, …), а автосозданное managed property привязано только к одному из них.
+Отсюда картина, которая иначе выглядит бессмыслицей:
+
+| Managed property | «Заявка на подбор 1 — данные» | «Прием на работу 1 — данные» |
+| --- | --- | --- |
+| `PositionOWSTEXT` | отдаёт | **молчит** |
+| `CandidateNameOWSTEXT` | (колонки нет) | **молчит**, но свойство рабочее в других списках |
+| `RequestStatusOWSCHCS` | отдаёт | отдаёт |
+
+То есть проверять надо не «работает ли свойство», а «работает ли оно **для этого
+списка**». `sp-write props` в конце как раз и говорит, рабочее ли свойство где-то ещё
+на сайте: если да — колонка этого списка отдельное поле, и в Search Schema нужно
+домапить её crawled property к тому же managed property; если нигде — свойства нет и
+его надо заводить.
+
+Полностью отсутствуют в схеме (проверено по всему сайту): `OpenReason`,
+`OpenReasonDetails`, `HireDate`.
+
+Из-за всего этого отчёт по вакансиям в `tnsu-approval-route` остался на items REST по
 партициям, а не на Search — подробный расчёт в doc-комментарии `VacancyReportService`.
 
 **Права разорваны на КАЖДОМ элементе.** У заявок портала