Параметры

Фоновый поллер, который вычерпывает очередь offline-событий Bitrix в durable-инбокс reverse_inbox. Сам по себе в 1С НЕ пишет (запись — отдельный рубильник). ⚠️ Требует OAuth-приложения: offline-события вебхуку недоступны (нужен CLIENT_ID). Без него правки из Bitrix доезжают только периодической досверкой.

⚠️ Применяется без перезапуска — в течение нескольких секунд. Предусловие: задан CLIENT_ID (OAuth-приложение); без него луп честно показывает «нет предусловия» на вкладке «Диагностика».

дефолт: false

Как часто дренируем offline-очередь портала. При повторных сбоях действует бэкофф.

дефолт: 15.0

Идентификатор потребителя очереди event.offline.get/clear: группирует накопленные события под НАШ дренаж, чтобы clear одного потребителя не задел других.

⚠️ Идентификатор потребителя очереди портала: смена на лету рассинхронит get/clear.

дефолт: app1

⚠️ По умолчанию НЕТ. На боевой коробке (rest 26.x) get с process_id ФИЛЬТРУЕТ очередь по нему и возвращает пусто (события помечены PROCESS_ID=""), то есть дренаж встаёт — так и было живьём после хардненинга. Поэтому get зовём без него, а clear берёт process_id ИЗ ОТВЕТА get. Включай, только если версия коробки требует резерв по нашему id (выверяется живьём через /events/drain).

дефолт: false

Что портал кладёт нам в очередь (подписка транспорта, не набор сущности). ⚠️ Коды версионно-зависимы и выверяются ЖИВЬЁМ. Для реквизитных обратных полей (legal_name/okpo живут на crm.requisite) нужен код события реквизита (ONCRMREQUISITEUPDATE); для обратки техники — код события смарт-процесса (ONCRMDYNAMICITEMUPDATE_1112 на боевом портале).

⚠️ После правки нужен POST /events/bind — сам по себе список ничего не привязывает.

дефолт: ONCRMCOMPANYUPDATE,ONCRMCONTACTUPDATE,ONCRMDEALUPDATE

ЕДИНЫЙ предохранитель ВСЕХ путей записи Bitrix → 1С: фонового поллера, досверки и ручек (/contractors/reverse/process|replay|apply, /contractors/equipment/apply — без флага они отвечают 409). ⚠️ Включённый РЕАЛЬНО ПИШЕТ в прод-базу 1С. Что именно пишется — в наборах полей контрагента и техники; этот флаг лишь открывает путь.

дефолт: false

Сколько событий инбокса обработчик забирает за один тик (claim_pending).

дефолт: 25

Сколько раз пробуем обработать одно событие до перевода в dead_letter (транзиентные сбои). Отложенные (deferred) попыток не тратят.

дефолт: 5

Отдельный луп: поднимает deferred-события и полным сканом карты лечит вовсе пропущенные события. ⚠️ Даёт заметный REST-трафик в Bitrix (полный скан ~684 карточек × ~6 вызовов ≈ 8 минут) — держим выключенным и с длинным интервалом. ⚠️ При включённой обратной записи проход РЕАЛЬНО ПИШЕТ в 1С и держит общий лок записи: на это время realtime-обработка событий ждёт.

⚠️ Применяется без перезапуска — в течение нескольких секунд. Предусловие: задан CLIENT_ID. ⚠️ Выключение не прерывает уже идущий проход (полный скан ~8 минут) — оно означает «следующего прохода не будет».

дефолт: false

Интервал ≥ 1800 или выключено — иначе досверка хаммерит портал.

дефолт: 900.0

Поллер тянет durable-outbox 1С (план обмена) в forward_inbox. Записи в Bitrix ещё НЕТ — она за отдельным рубильником. ⚠️ Гейт — адрес сервиса 1С, а НЕ CLIENT_ID: форвард работает на вебхуке, OAuth-приложение ему не нужно.

⚠️ Применяется без перезапуска — в течение нескольких секунд. Предусловие: задан адрес хотя бы одного сервиса 1С (ONEC_BASE_URL / ONEC_REPAIRS_BASE_URL / ONEC_PRODUCTS_BASE_URL); каждая сущность дренит только свою очередь.

дефолт: false

Как часто дренируем очередь изменений 1С. При повторных сбоях действует бэкофф.

дефолт: 15.0

ЕДИНЫЙ рубильник ВСЕХ путей форвардной записи (поллер + ручка /contractors/forward/process). Правка в 1С сама уезжает в Bitrix, без кнопки. ⚠️ Форвард — безусловная перезапись мастером: правка менеджера в Bitrix будет затёрта значением 1С. Риск принят владельцем; закрывает его не отказ от записи, а НАБЛЮДЕНИЕ — «След форварда» в журнале расхождений.

дефолт: false

Сколько 1С-событий обработчик забирает за один проход claim_pending.

дефолт: 25

Poison-guard: сколько раз пробуем обработать одно 1С-событие до dead_letter.

дефолт: 5

Периодический полный прогон run_full по всей базе — лечит пропуски realtime. ⚠️ Дорог по REST (полный справочник) — держим выключенным и с длинным интервалом.

⚠️ Применяется без перезапуска — в течение нескольких секунд. Предусловие: задан адрес хотя бы одного сервиса 1С (у каждой сущности — свой). Пишет в Bitrix (master-wins). ⚠️ Выключение не прерывает уже идущий полный прогон.

дефолт: false

Интервал полного скана. Держим длинным: проход дорогой.

дефолт: 3600.0

Префикс тега source форвардного инбокса: репо собирает source = "<префикс>:<сущность>" (onec:contractor). Сущность в ключ вносит сама строка, не этот флаг.

⚠️ Входит в ключ дедупа форвардного инбокса: смена на живой очереди = повторная обработка всей истории. Применяется только после перезапуска контейнера.

дефолт: onec

Вести журнал field_conflict в режиме «не писать»: детект наблюдаемых полей. ⚠️ ОРТОГОНАЛЕН обратной записи — детект идёт в форвардном направлении, ему не нужны ни BSL, ни право записи в 1С. При включённом наблюдении поллер обрабатывает события и БЕЗ включённой обратной записи.

дефолт: false

По факту конфликта подтянуть карточку 1С → Bitrix (привести Bitrix к 1С, master-wins). ⚠️ ПИШЕТ в Bitrix и затирает правку менеджера — включать после того, как детект выверен живьём. Только тёплый путь по GUID; при N:1 или недоступном mapping мини-форвард не запускается.

дефолт: false

Анти-шторм: при достижении новые расхождения не регистрируем и не сигналим (уже открытые продолжают жить). Мини-форвард потолком НЕ гасится — он единственный выход из переполнения.

дефолт: 500

Задел под периодическую чистку журнала; сама чистка пока не гоняется.

дефолт: 90

Сигнал о расхождении ответственному менеджеру карточки (im.message.add, фолбэк im.notify.personal.add). ⚠️ Пишет НАРУЖУ, живым людям, и сообщение из чата не отзывается: включать только ПОСЛЕ приёмки детекта. ⚠️ Доступность im.* на коробке версионно-зависима: метода нет → канал честно гаснет с предупреждением, контур жив.

⚠️ Решение владельца 30.07.2026: выключено ОСОЗНАННО (режим «журнал без сигналов») — класс потерь «устаревшая форма» неотслеживаем по построению, и сигнал создавал бы ложное ожидание полноты. Каналы проверены живьём и работают.

дефолт: false

Второй, независимый канал сигнала: комментарий в таймлайн карточки (crm.timeline.comment.add). Отдельный флаг намеренно — страховка на случай, когда im.* на коробке недоступен: след останется в истории карточки.

дефолт: false

Кому уходит сигнал, если ответственный карточки не прочитался, если он — МЫ САМИ (портал ставит создателя карточки, а им был наш форвард) или если портал его отверг. Пусто → в таком случае молчим (журнал уже написан; комментарий, если включён, всё равно уйдёт в карточку).

дефолт: пусто

🛑 Непусто → ВСЕ сигналы уходят ТОЛЬКО на этот ID, ответственный карточки в текст лишь вписывается. Без него живую проверку не провести: ASSIGNED_BY_ID в Битриксе никогда не пуст, поэтому фолбэк не сработает ни разу, и первое же включение написало бы реальным менеджерам в чат.

дефолт: пусто

Первый проход после включения (~684 карточки) высыпал бы сотни сообщений нескольким людям. Непросигналенные отпечатка не получают и доедут следующим проходом. 0 — без потолка. ⚠️ Значение НИЖЕ размера партии поллера бессмысленно: на событийном пути повторить непросигналенное нечем, поэтому код сам поднимает потолок до размера партии.

дефолт: 50

Когда форвард перезаписывает правку менеджера в Bitrix значением 1С — оставить строку в журнале (kind=overwritten) и позвать человека теми же каналами. Закрывает дыру, которую детект не видит ПО ПОСТРОЕНИЮ: успей форвард первым, он сам сдвинул baseline, и обратный проход рапортует equal. ⚠️ Поведение записи не меняется ни на байт — добавляется только наблюдение. ⚠️ Цена — 1–2 REST на форвардную карточку (значение Битрикса надо прочитать ДО записи, после неё его нет нигде). Читаем лишь там, где есть с чем сравнивать. Требует включённого журнала расхождений и форвардной записи.

дефолт: false

Писать в наш Postgres КАЖДОЕ реально записанное поле: объект, поле, «что было → что стало», направление (1С → Bitrix / Bitrix → 1С), кто инициировал, когда. Пишет только в НАШУ базу — движения в 1С/Bitrix не прибавляет и не убавляет. Пишутся только ФАКТИЧЕСКИЕ записи: равные/пропущенные/конфликтные исходы строк не порождают. Ретеншен — месяц, фоновая очистка раз в сутки.

⚠️ Применяется без перезапуска: строки начинают писаться со следующего прогона. Таблица создана заранее — включение ничего не мигрирует.

дефолт: false

Сколько дней хранить записи журнала. Очистка — фоновая, раз в сутки (плюс ручная ручка на вкладке журнала). Месяц — решение владельца: на месячном объёме хватает обычного поиска без индексов полнотекста.

⚠️ Применяется без перезапуска: следующий проход очистки возьмёт новый срок.

дефолт: 31

Как часто фоновый луп чистит строки старше ретеншена. Раз в сутки — дефолт.

⚠️ Применяется без перезапуска — в течение нескольких секунд.

дефолт: 86400

Какие коллекции смарт-процессов синхронизируем/провизионим/сверяем: equipment (техника), rail_station (жд станции), sowing_year / sowing_culture (севооборот; алиас sowing включает оба). Остальные ВЫКЛЮЧЕНЫ — код цел, просто не трогаем их на портале. По умолчанию только техника (решение владельца «пока не нужно»).

⚠️ Включённая коллекция начинает писаться в Bitrix прямой синхрой.

дефолт: equipment

Какие поля реально пишем Bitrix → 1С (Подзадача 3 С6 + батч D). Ортогонально рубильнику «Обратная запись в 1С»: тот — предохранитель ВСЕХ путей записи, это — набор полей контрагента под ним. Дефолт — только comment (доказанное живьём С5). ⚠️ legal_name/okpo требуют ещё и события реквизита в кодах offline-событий. ⚠️ Поля батча D (наши UF) требуют провизии UF на портале + прогона прямой синхры: без UF поле честно уйдёт в unreadable, без прогона — в deferred/no_baseline. Ни то ни другое не портит 1С.

⚠️ Правило владельца: поля включаем ПО ОДНОМУ и каждое проверяем живьём. Каждое включённое поле реально пишет в боевую базу 1С.

дефолт: comment

Зеркало обратных полей контрагента, но для коллекции ЭПФ «Техника» (Подзадача 7 Э3): ключи реестра equipment_fields. ⚠️ Дефолт ПУСТО, и это несущее: общий рубильник обратной записи у владельца уже включён, поэтому инертность держит именно пустой набор. Пусто → техника обратно не пишется и НЕ ЧИТАЕТСЯ (событие смарт-процесса терминально пропускается без единого REST-вызова). Предусловия поля: (1) поле НЕПУСТО в 1С; (2) прогнана прямая синхра (она сеет baseline единицы техники); (3) для realtime — код offline-события смарт-процесса в кодах offline-событий.

⚠️ Включаем ПО ОДНОМУ полю живьём, как батч D.

дефолт: пусто

По каким полям детектим расхождение и ведём журнал field_conflict (Подзадача 4 К1). Наружу НЕ пишем. ОРТОГОНАЛЬНО набору записи и рубильнику обратной записи: детект — форвардное направление, ему не нужны ни BSL, ни право записи в 1С. Дефолт — важные скаляры: полное наименование ЮЛ, ОКПО, рабочее наименование. Сам контур включается рубильником «Журнал расхождений».

дефолт: legal_name,okpo,title

Наблюдать ли коллекции (адреса/ИНН/банк) через периодическую обратную СВЕРКУ (compare-путь, С2) — им нужен baseline compare-пути (развилка РК-7, tz/04 §3.3). ⚠️ Дефолт выключено: пока РК-7 не решена, compare-путь конфликты НЕ сигналит (иначе ложный сигнал от лага форварда).

дефолт: false

Сколько последних ведомых значений хранит history строки журнала (второй правщик не затирает текст первого).

⚠️ Снимается при подъёме журнала расхождений — применится после перезапуска контейнера.

дефолт: 10

Фоновый луп партиями тянет из 1С таблицу «показатель × год» по каждому контрагенту, у которого есть карточка Bitrix, и кладёт снимок в нашу базу. В Bitrix при этом НЕ пишет ничего — за показ отвечает отдельный рубильник. ⚠️ Расчёт дорогой: ~600 мс и шесть тяжёлых агрегатов по табличным частям проведённых документов на КАЖДУЮ карточку. Держи партию и период такими, чтобы не занимать 1С в часы закрытия месяца и бэкапа.

⚠️ Применяется без перезапуска. Предусловия: задан ONEC_BASE_URL и доступен Postgres.

дефолт: false

Писать собранный текст витрины в поле карточки компании (crm.company.update, ровно один наш ключ). Пишет ТОЛЬКО когда текст изменился. 🛑 Предусловие: поле на портале заведено (POST /contractors/turnover/provision). 🛑 Включать ПОСЛЕ того, как цифры сверены с вкладкой «Обороты контрагента» в 1С: увиденные менеджерами суммы обратно не отзываются.

⚠️ Пишет в карточки Bitrix. Обратно в 1С обороты не едут никогда — витрина односторонняя.

дефолт: false

Как часто берём очередную партию. Полный круг ≈ (число карточек / партия) × период: при 25 и 900 с это ~7 часов на 684 контрагента.

дефолт: 900.0

Сколько контрагентов пересчитываем за тик. 25 × 600 мс ≈ 15 секунд работы 1С. ⚠️ Больше — быстрее круг, но дольше непрерывная нагрузка на боевую ERP.

дефолт: 25

Карточка попадает в очередь пересчёта, когда её снимку больше стольких часов. Те, у кого снимка нет вовсе, идут первыми.

дефолт: 24

Фоновый луп раз в период читает из 1С всех партнёров с посевными (страницами по 500) и кладёт в нашу базу только разницу; строку, пропавшую из 1С, скрывает лишь после точечной проверки партнёра. В 1С и Bitrix НЕ пишет ничего. Нужен, чтобы вкладка в карточке и фильтры работали без похода в 1С на каждый показ. Предусловия: задан ONEC_SOWING_BASE_URL (свой сервис посевных) и доступен Postgres.

⚠️ Применяется без перезапуска. Разовый проход по кнопке работает и при выключенном.

дефолт: false

Как часто луп сверяет зеркало с 1С целиком. Не меньше часа: проход читает сотни снимков боевой 1С, а свежесть вкладки держит перечитывание партнёра при открытии.

дефолт: 3600.0

Сколько строк (годов и культур), пропавших из 1С, проход вправе скрыть за раз. Больше — это почти всегда сбой прав/RLS или выгрузки 1С, а не бизнес: проход ничего не скрывает и пишет громкое предупреждение. Скрытие обратимо (строка вернётся со следующим ответом 1С), удаления нет вовсе.

дефолт: 50

Обработчик вкладки CRM_COMPANY_DETAIL_TAB: проверяет токен пользователя на НАШЕМ портале (приложение, пользователь, доступ к компании) и показывает посевные партнёра из зеркала, перечитывая их из 1С при открытии. Только чтение: в 1С и Bitrix не пишет ничего. Выключен — вкладка отвечает «выключена», даже если привязана к порталу (placement.bind).

⚠️ Применяется без перезапуска. Привязка вкладки к порталу — отдельной кнопкой под PIN.

дефолт: false

Рубильник контура уведомлений о заявках на ремонт. false → плагин не дренирует, не обрабатывает, ни одного REST в ленту или чат. Старт байт-в-байт. Куда именно уходит уведомление — параметр «Канал уведомлений».

⚠️ Применяется без перезапуска — в течение нескольких секунд.

дефолт: false

feed — пост в ЛЕНТУ группы (log.blogpost.add отдельным вебхуком ленты, адрес — «ID групп для постов»); chat — сообщение в ЧАТ группы (im.message.add основным вебхуком, адрес — «Адрес чата группы»). Уже опубликованное при смене канала НЕ дублируется: дедуп ключуется событием, а не каналом.

⚠️ Переключать на chat ТОЛЬКО после пробы: POST /repairs/feed/test с channel=chat — сообщение обязано быть видно В ЧАТЕ ГРУППЫ глазами (HTTP 200 не доказательство). Неверный адресат уводит события в dead_letter с первой попытки, а replay нет.

дефолт: feed

Только канал feed. CSV ID рабочих групп Bitrix24, куда публикуются посты о заявках (например "136"). Пусто → путь ленты закрыт (никуда не шлём).

дефолт: пусто

Только канал chat. sg<ID группы> (например sg136) или chat<ID чата> — тот, что подтвердила проба. Голое число НЕ принимается: это личный диалог пользователя. Пусто → путь чата закрыт.

дефолт: пусто

Только канал feed. true → смена статуса уходит КОММЕНТАРИЕМ к посту этой заявки в ленте (log.blogcomment.add), а не новым постом. Поста о заявке ещё нет (её создали до ленты) → смена статуса публикуется постом, как раньше, и следующие идут комментариями к нему. Комментарий не лёг (пост удалили, метода нет) → пост. false → каждая смена статуса — отдельный пост.

⚠️ Включать ТОЛЬКО после пробы: POST /repairs/feed/test-comment с ID живого поста — комментарий обязан быть виден ПОД ПОСТОМ в ленте глазами.

дефолт: false

Только канал feed. Использовать USER_ID автора заявки при публикации (пост выходит от его имени). false → всегда от аккаунта хаба + строка «Создал(а): ФИО» в теле. ⚠️ Требует админства учётки хаба на портале. В канале chat не действует: im.message.add пишет от владельца вебхука всегда, автор остаётся строкой в теле.

дефолт: true

Сколько раз повторять публикацию поста при ТРАНЗИЕНТНОМ отказе портала, прежде чем увести строку очереди в dead_letter. Свой потолок (не общий форвардный): уведомление дешевле потерять, чем долбить портал.

дефолт: 3

Рубильник второго приёмника событий заявок: задача в группе (создать по снимку, дальше — колонка по ТЕКУЩЕМУ статусу и недостающие участники). Независим от уведомлений в ленту/чат. false → ни одного REST в задачи. Старт байт-в-байт.

⚠️ Включать ТОЛЬКО после пробы POST /repairs/tasks/test в тестовой группе: задача видна в канбане, постановщик и участники на месте (HTTP 200 не доказательство). Пока включённый приёмник не готов (группа/исполнитель не заданы), события НЕ забираются из очереди вовсе — ни задачи, ни уведомления: ждут, а не теряются.

дефолт: false

Рабочая группа, где создаются задачи и чей канбан двигается (136 на проде). 0 → путь закрыт.

дефолт: 0

Исполнитель КАЖДОЙ задачи по заявке (Валерий Потапов: 1174 на проде). Обязательное поле задачи: 0 → путь закрыт. На dev-портале ID людей другие.

дефолт: 0

Соисполнители каждой задачи (Дарья Семенова: 995 на проде). К ним добавляется ответственный из заявки, когда 1С начнёт отдавать его пользователем (§12).

дефолт: пусто

ID потока, в который попадают задачи по заявкам («Заявка в СЦ (выездной сервис)» — 15 на боевом портале). 0 → задачи создаются вне потока. ⚠️ У задачи в потоке коробка САМА назначает исполнителя (им становится распределяющий потока), срок, группу и контроль — «Исполнитель задач» при заданном потоке не действует.

⚠️ ID потока не виден по REST (методов потоков там нет): возьми его из разведки — она показывает FLOW_ID последних задач группы.

дефолт: 0

Отдельный поток для заявок ремонтной зоны («Заявка в РЗ» — 16 на боевом портале). 0 → ремзонные заявки идут тем же потоком, что и остальные.

дефолт: 0

Пары «Статус=Колонка» через точку с запятой, например «Поступила=Новые заявки; Готов к выезду=Готовы к выезду». Статус, которого здесь нет, ищет колонку с ТЕМ ЖЕ названием (без учёта регистра, пробелов и ё). Не нашлось — карточка остаётся, где была, причина видна в диагностике. Нечёткого сравнения нет намеренно.

⚠️ Проверь сопоставление в GET /repairs/tasks/discovery до включения рубильника.

дефолт: пусто

Единый предохранитель ВСЕХ записей среза в каталог Bitrix: кнопки вкладки «Номенклатура», сверка по расписанию и события из очереди 1С. Выключен → ручки записи отвечают 409, пробный прогон (dry-run) при этом доступен. Перепроверяется перед КАЖДОЙ страницей длинного прохода — снятие останавливает запись со следующей.

⚠️ Применяется без перезапуска — в течение нескольких секунд.

дефолт: false

Дренаж очереди изменений номенклатуры 1С и обработка событий по одной позиции. Создаёт и обновляет товары, но сам НЕ гасит: «ушло из папки» копится кандидатом для полного прохода. Событие ГРУППЫ запускает фоновый полный проход; исчезнувшее он гасит, только если включена сверка по расписанию (ENABLE_PRODUCT_RECONCILE), иначе подтверждённые кандидаты ждут кнопки «Применить деактивацию». Пишет только при включённой записи номенклатуры; фоновый поллер форварда (ENABLE_FORWARD_POLLER) тоже должен работать.

⚠️ Применяется без перезапуска — в течение нескольких секунд.

дефолт: false

Раз в интервал запускает полный проход фоном: он видит то, чего не видят события (перенос группы, переименование поставщика/модели, изменения из обменов), и гасит исчезнувшее под анти-штормом. Обязательный контур, а не резерв. Стартует из тика фонового поллера форварда (ENABLE_FORWARD_POLLER).

⚠️ Применяется без перезапуска — в течение нескольких секунд.

дефолт: false

Сколько секунд от конца прошлого полного прохода (по журналу прогонов) до начала следующего по расписанию. Не меньше 600: повторный проход без изменений — это всё равно ~170 чтений каталога.

⚠️ Применяется без перезапуска — в течение нескольких секунд.

дефолт: 3600

GUID групп справочника «Номенклатура», поддерево которых едет в каталог (через запятую). По умолчанию — «С/Х техника». Пустым быть не может. Найти GUID — кнопка «Корни 1С» на вкладке «Номенклатура». ⚠️ Неверный корень делает «ушедшим из папки» всё связанное — гашение удержит только анти-шторм.

⚠️ Применяется без перезапуска — в течение нескольких секунд.

дефолт: e7d6f56d-440f-11e0-a8b8-001676d419f0

Товарный каталог, в который пишет срез: 24 — «Товарный каталог CRM». Перед записью проверяется по catalog.catalog.list: каталог существует и НЕ каталог торговых предложений. Связи хранятся по каталогу — смена не путает товары разных каталогов.

⚠️ Применяется без перезапуска — в течение нескольких секунд.

дефолт: 24

ID раздела каталога, под которым строится дерево групп 1С. 0 — разделы корневых групп ложатся в корень каталога. Ручные разделы и товары менеджеров срез не трогает.

⚠️ Применяется без перезапуска — в течение нескольких секунд.

дефолт: 0

Сколько товаров и разделов, ушедших из папки, полный проход вправе погасить сам (active=N; удаления нет никогда). Больше — не гасит ничего, список кандидатов ждёт кнопки «Применить деактивацию» (с повторной проверкой в 1С).

⚠️ Применяется без перезапуска — в течение нескольких секунд.

дефолт: 50