Параметры

Фоновый поллер, который вычерпывает очередь 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 ещё НЕТ — она за отдельным рубильником. ⚠️ Гейт — ONEC_BASE_URL, а НЕ CLIENT_ID: форвард работает на вебхуке, OAuth-приложение ему не нужно.

⚠️ Применяется без перезапуска — в течение нескольких секунд. Предусловие: задан ONEC_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 (полный справочник) — держим выключенным и с длинным интервалом.

⚠️ Применяется без перезапуска — в течение нескольких секунд. Предусловие: задан ONEC_BASE_URL. Пишет в 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

Какие коллекции смарт-процессов синхронизируем/провизионим/сверяем: 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