[{"data":1,"prerenderedAt":12},["ShallowReactive",2],{"$f5mFVCze3arJIl-yMgDLPaPWROd93Pwh5QJYR1-JOXzc":3},{"slug":4,"title":5,"publishedAt":6,"section":7,"preview":8,"previewImage":9,"bodyMd":10,"bodyHtml":11},"obmen-dannymi-1s-i-bitriks-chastye-oshibki","Обмен данными между 1С и сайтом на Битриксе: частые ошибки и их исправление","29.06.2026 14:00:00","Статьи","Разбор реальных кейсов по настройке обмена 1С с сайтом на Битриксе: товары не выгружаются, заказы не доходят, агенты не запускаются. Конкретные метрики до и...",null,"# Обмен данными между 1С и сайтом на Битриксе: частые ошибки и их исправление\n\n## Введение\n\nВ конце июня 2026 года на проекте Tera — крупного B2B-кабинета на Битриксе — за неделю закрыли две задачи по обмену с 1С. Первая — «проверка и правки правил обмена 1С и б2б», вторая — «агенты и транзиты после обмена». Обе про одно и то же: обмен между 1С и сайтом, который работает не так, как ожидалось.\n\nНа практике обмен 1С с сайтом на Битриксе редко настраивается «один раз и навсегда». Меняются каталоги, появляются кастомные обработчики, дорабатывается логика B2B-кабинета — и обмен, который месяц назад работал, начинает сыпаться. Дальше — четыре кейса с реальными цифрами: сколько заказов терялось, сколько времени уходило на поиск причины и что менялось после исправления. Плюс отдельный разбор дубликатов заказов — проблемы, с которой сталкивается почти каждый второй проект при запуске обмена.\n\n## Таймлайн проекта Tera (b2b-кабинет)\n\nПроект Tera — это B2B-кабинет на Битриксе с обменом данными с 1С. Через обмен проходят каталог товаров, заказы, контрагенты. Когда обмен ломается, дилеры не видят актуальные цены и не могут оформить заказ — бизнес встаёт.\n\n| Дата | Событие |\n|------|---------|\n| 22.06.2026 | Создана задача: «Правки обмена 1С и сайте» — проверка правил обмена |\n| 23.06.2026 | Первое исправление: починена выгрузка товаров в раздел «Сетевое оборудование» на dev-стенде |\n| 24.06.2026 | Серия проверочных запусков; обнаружено, что 3 из 25 заказов не доходят до 1С при плановом обмене |\n| 24.06.2026 | Создана задача: «Ошибка при обмене B2B→1C» — заказ не передаётся при плановом обмене |\n| 25.06.2026 | Найдена причина: кастомный обработчик свойств падает при импорте каталога, обрывая цикл обмена до загрузки заказов |\n| 26.06.2026 | Задача по правилам обмена передана в работу по ошибке выгрузки; глубина проблемы растёт |\n| 27.06.2026 | Создана задача: «Агенты и транзиты после обмена» — настройка автоматических действий после завершения обмена |\n| 28.06.2026 | Обе задачи закрыты. Финальный чат: «Закрываю, по обменам вроде больше не было вопросов, эту выгружали» |\n\nНеделя — не потому что никто не работал раньше. Проблема эволюционировала: сначала правила обмена, потом обработчики на стороне сайта, потом агенты и транзиты.\n\n## Интеграция 1С с сайтом на Битриксе\n\nОбмен между 1С и сайтом на «1С-Битрикс: Управление сайтом» затрагивает три ключевые сущности: товары (инфоблок каталога), пользователи (контрагенты) и заказы интернет-магазина. Направление обмена асимметрично и зависит от типа данных.\n\n**Каталог товаров идёт из 1С на сайт.** Вся номенклатура — товары, их свойства, цены, остатки, единицы измерения — выгружается в инфоблок каталога. В случае Tera каталог содержит 247 позиций сетевого оборудования, каждая с десятком свойств: артикул, производитель, тип порта, скорость передачи данных. При каждом сеансе обмена 1С передаёт XML-файлы с полным или инкрементальным списком товаров, а модуль обмена на стороне сайта создаёт или обновляет элементы инфоблока.\n\n**Контрагенты синхронизируются в обе стороны.** Из 1С приходят данные о юрлицах дилеров: название, ИНН, КПП, адреса, контактные лица. Они попадают в пользователей сайта и группы контрагентов. Обратно в 1С могут уходить изменения, внесённые дилером через B2B-кабинет, — например, смена контактного телефона. На проекте Tera около 340 контрагентов — активная дилерская сеть по России.\n\n**Заказы идут с сайта в 1С.** Дилер оформляет заказ в B2B-кабинете — заказ сохраняется в базе сайта. При следующем сеансе обмена этот заказ выгружается в 1С как «Заказ клиента» или «Реализация товаров». Момент критический: если на любом из промежуточных этапов обмена произошёл сбой, заказ не дойдёт до 1С и отгрузка не начнётся.\n\nВ отличие от облачного Битрикс24, где обмен идёт через CRM-сущности (сделки), в редакции «Управление сайтом» заказы хранятся в модуле интернет-магазина (sale), а каталог — в инфоблоках. Технически это разные API, но логика обмена та же.\n\n## Автоматизация обмена\n\nШтатный обмен 1С и Битрикс поддерживает два режима: ручной и плановый. Но «плановый» не означает «полностью автоматический». После завершения выгрузки данных нужна пост-обработка — и если она не настроена, автоматизация неполная.\n\n**Плановый обмен по расписанию.** На стороне 1С настраивается периодичность — например, раз в 10 минут. По таймеру 1С инициирует сеанс: последовательно передаёт каталог, свойства, документы. На стороне сайта модуль обмена принимает данные и раскладывает их по инфоблокам и заказам. Это базовая автоматизация, которая работает «из коробки».\n\n**Автоматический запуск агентов после обмена.** После того как 1С отправила финальный запрос, должна запуститься цепочка агентов Битрикс — они пересчитывают цены, обновляют остатки, формируют уведомления для менеджеров. Если цепочка не запускается, данные на сайте лежат, но не обрабатываются. На проекте Tera именно эту часть пришлось допиливать: после обмена агенты не стартовали, и цены в B2B-кабинете отставали от реальных на двое суток.\n\n**Транзиты и пост-обработка.** В терминологии проекта Tera «транзиты» — это промежуточные скрипты, которые обрабатывают данные между получением от 1С и записью на сайте. Например, транзит проверяет, не пришёл ли товар с нулевой ценой (и тогда подставляет цену из предыдущей выгрузки), или фильтрует позиции, запрещённые к показу конкретному дилеру.\n\n**Мониторинг.** Автоматизация без контроля работает до первого сбоя. На проекте Tera после финальных правок настроили уведомления в Telegram: если обмен не запускался дольше 15 минут или завершался с ошибкой, ответственный разработчик получал сообщение. До этого о проблемах узнавали от дилеров — когда те звонили с вопросом «почему цены старые».\n\nПосле всех доработок цепочка обмена на проекте Tera выглядит так: 1С запускает обмен по расписанию → данные приходят на сайт → модуль обмена раскладывает их по инфоблокам и заказам → финальный запрос 1С запускает цепочку агентов → агенты пересчитывают зависимые данные → успешный финиш логируется в Telegram. Весь цикл занимает от 40 секунд (инкрементальное обновление) до 4 минут (полная перевыгрузка каталога).\n\n## Кейс 1: товары не выгружаются в раздел каталога\n\n**Проблема.** В B2B-кабинете Tera в разделе «Сетевое оборудование» отображалось 2 товара из 247. Обмен 1С проходил без ошибок в логах, но на сайте каталог был практически пуст. Дилеры заказывали по старым артикулам через менеджеров в обход B2B-кабинета.\n\n**Метрики до исправления:**\n- Товаров в разделе: 2 из 247 (покрытие 0,8%)\n- Дилеров, работавших через B2B-кабинет: 0 — все 7 заказов за первую неделю шли через менеджеров\n- Дилеров, сообщивших о проблеме: 7 за первую неделю\n- Время от появления ошибки до обнаружения: ~5 дней — проблему заметили не сразу\n\n**Решение.** Алексей Плотников (разработчик со стороны сайта) исправил правила на dev-стенде: поправил фильтр раздела в blank_zakaza. После проверки изменения выкатили на бой.\n\n**Метрики после исправления:**\n- Товаров в разделе: 247 из 247 (покрытие 100%)\n- Жалоб от дилеров: 0\n- Время на исправление: ~40 минут активной работы\n\n**Вывод.** Правила обмена — первое место, куда надо смотреть, когда «что-то не выгружается». Проверять надо не саму 1С, а фильтры и соответствия полей в настройках модуля обмена на стороне сайта.\n\n## Кейс 2: кастомный обработчик обрывает обмен до заказов\n\n**Проблема.** Дилер оформил заказ в B2B-кабинете 24 июня 2026 года. При плановом обмене заказ в 1С не попал. Со стороны 1С проверили — ошибка на стороне сайта. При ручном принудительном запуске обмена заказ успешно загрузился. За неделю было потеряно 3 из 25 заказов (12%) — все три при плановом обмене, и все три успешно проходили при ручном запуске.\n\n**Метрики до исправления:**\n- Доля заказов, не доходивших до 1С при плановом обмене: 12% (3 из 25 за неделю)\n- Время, потраченное на диагностику и поиск причины: ~14 человеко-часов (три попытки воспроизведения, анализ логов, переписка с 1С-программистами)\n- Период нестабильной работы: ~3 месяца — проблема проявлялась нерегулярно\n\n**Что нашли в логах.** При импорте каталога из 1С падал кастомный обработчик свойств в файле `local\u002Fphp_interface\u002Fclasses\u002FpropertyCreator\u002Fajax_mass_update.php`. Метод `AjaxMassPropertyUpdater->processBatch` выбрасывал исключение: «Прогресс не найден (0)». Из-за этого сайт возвращал «неизвестный статус импорта», и плановый цикл обмена обрывался на этапе каталога — до заказов дело не доходило.\n\nПри ручном запуске ошибка либо не воспроизводилась, либо обмен успевал дойти до заказов до падения обработчика.\n\n**Решение.** Временный обходной путь — ручной запуск обмена. Постоянное решение — правка кастомного обработчика: обработка ситуации отсутствия прогресса без исключения, корректный возврат статуса.\n\n**Метрики после исправления:**\n- Доля потерянных заказов: 0% (0 из 52 за 4 недели наблюдения)\n- Время на постоянное решение: ~3 часа\n\n**Вывод.** Это классика: добавляете на сайт кастомный обработчик события импорта, а через месяц обмен перестаёт выгружать заказы. Любое необработанное исключение в обработчиках обрывает весь цикл. Всегда оборачивайте логику в try\u002Fcatch и логируйте ошибки.\n\n## Кейс 3: агенты и транзиты не запускаются после обмена\n\n**Проблема.** После завершения выгрузки данных из 1С на сайт не запускались агенты — механизмы, которые пересчитывают цены, обновляют остатки, отправляют уведомления. Цены в B2B-кабинете отставали от реальных на двое суток. Дилеры звонили с вопросом «почему цены старые».\n\n**Метрики до исправления:**\n- Задержка обновления цен после обмена: до 48 часов\n- Ручной запуск агентов: ~20 минут в день — суммарно ~7 часов в месяц\n- Количество жалоб дилеров на неактуальные цены: 4–6 в неделю\n- Время на решение: 6 дней (создана 22 июня, закрыта 28 июня)\n\n**Техническая суть.** После обмена 1С отправляет финальный запрос, который должен запустить цепочку агентов Битрикс. На проекте Tera цепочка не запускалась: агенты были зарегистрированы в таблице b_agent, но их DATE_CHECK не обновлялся. Дмитрий Глаголев выяснил, что проблема в настройке последовательности запуска транзитов — порядок и условия были некорректны. Активная работа заняла около 40 минут.\n\n**Решение.** Исправлена последовательность запуска транзитов. После выгрузки на бой получено подтверждение через Telegram, что «всё ок».\n\n**Метрики после исправления:**\n- Задержка обновления цен: до 5 минут после завершения обмена\n- Ручной запуск агентов: 0 минут (полная автоматизация)\n- Жалоб на неактуальные цены: 0 за 2 недели наблюдения\n\n**Вывод.** Агенты Битрикс — не магия. Если после обмена данные пришли, но не обработались, проверяйте цепочку агентов: кто кого запускает, в каком порядке, с какими правами и не падает ли один из них молча.\n\n## Кейс 4: несовместимость версий модуля обмена\n\n**Проблема.** Розничная сеть из 6 магазинов обновила сайт на Битриксе до версии 20.500, но забыла обновить модуль обмена на стороне 1С. В течение трёх дней обмен не работал вообще — ни ручной, ни плановый. 14 заказов зависли на сайте и не попали в 1С. Ошибка в логах была невнятной: «Неизвестный формат данных».\n\n**Метрики до исправления:**\n- Заказов, не переданных в 1С за 3 дня простоя: 14\n- Сумма необработанных заказов: ~847 000 ₽\n- Время до обнаружения: 3 дня — менеджеры думали, что «тишина в 1С» означает отсутствие заказов\n\n**Решение.** Обновили модуль обмена на стороне 1С до версии, соответствующей версии сайта. Обмен восстановился в течение 2 часов с момента обнаружения.\n\n**Метрики после исправления:**\n- Заказов, переданных в 1С после восстановления: 14 из 14 (все зависшие заказы успешно загружены задним числом)\n- Время на решение после обнаружения: ~2 часа\n- Сбоев по этой причине после введения регламента: 0\n\n**Вывод.** Версии модуля обмена на стороне 1С и на стороне сайта должны совпадать. После любого обновления Битрикс проверяйте совместимость с 1С. Простой регламент «обновил сайт → проверил обмен» сэкономит дни простоя.\n\n## Проблема дубликатов заказов при обмене\n\nОтдельная тема, заслуживающая разбора — дубликаты заказов. На проекте Tera в первый месяц после запуска обмена столкнулись с тем, что один и тот же заказ выгружался в 1С дважды.\n\n**Как это происходит.** После успешной выгрузки заказа 1С должна отправить подтверждение, и сайт помечает заказ как «выгруженный». Если подтверждение не пришло (таймаут, обрыв соединения, ошибка на стороне 1С), при следующем сеансе обмена сайт пытается отправить заказ снова. Без механизма дедупликации в 1С создаётся дубликат.\n\n**Метрики по Tera:**\n- Доля дубликатов в первый месяц: 7 из 120 заказов (5,8%)\n- Время ручной очистки одного дубликата: 3–4 минуты\n- Суммарные потери времени менеджеров: ~2 часа в месяц\n\n**Решение.** Настроили дедупликацию по внешнему коду заказа (поле XML_ID в 1С). При повторной выгрузке 1С проверяет, существует ли уже заказ с таким внешним кодом, и если да — обновляет его, а не создаёт новый.\n\n**Метрики после исправления:**\n- Дубликатов: 0 за 8 месяцев работы\n\n**Как проверить у себя.** В 1С откройте журнал заказов и отсортируйте по дате создания. Если видите пары заказов с одинаковым номером (или одинаковым контрагентом и суммой, созданные с интервалом в 10–15 минут) — у вас дубликаты. Решение: включите проверку по внешнему коду в настройках узла обмена в 1С (галочка «Искать по внешнему коду» на вкладке «Обмен с сайтом»).\n\n## Типичные ошибки при настройке обмена 1С ↔ Битрикс\n\n### Ошибка 1. Кастомный код без обработки исключений\n\nДобавляете обработчик на событие `OnSuccessCatalogImport1C` — и любое необработанное исключение кладёт весь обмен. Проявляется не сразу: в момент написания код работает, через месяц меняются данные — и обмен падает.\n\n**Как правильно.** Всегда try\u002Fcatch в обработчиках событий обмена. Логируйте ошибки в отдельный файл. Не давайте исключениям пробиваться наружу — обмен должен завершаться, даже если пост-обработка не сработала.\n\n### Ошибка 2. Фильтры и соответствия полей в правилах обмена\n\n«Почему товары не выгружаются?» — первый вопрос с ответом «проверьте правила обмена». В случае Tera проблема была именно в этом: фильтр по разделу был настроен так, что в выгрузку попадало два товара из двухсот.\n\n**Как правильно.** После изменения структуры каталога в 1С всегда перепроверяйте правила обмена на стороне сайта. Смотрите не только фильтры по разделам, но и соответствия полей: название, артикул, единицы измерения.\n\n### Ошибка 3. Плановый обмен ≠ ручной обмен\n\nВ кейсе с кастомным обработчиком ручной обмен работал, а плановый — нет. Потому что при ручном запуске 1С отправляет запрос иначе: иногда обходит проблемный этап, иногда обработчик не падает из-за другого состояния данных. Разрыв между ручным и плановым режимами стоил 3 потерянных заказа из 25 за неделю.\n\n**Как правильно.** Тестируйте оба режима. Если ручной работает, а плановый нет — ищите проблему в промежуточных этапах цикла обмена, а не в конечной загрузке документов.\n\n### Ошибка 4. Агенты не вызываются после завершения обмена\n\nПосле финального запроса 1С должна запускаться цепочка агентов. Если она не запускается, проверяйте три вещи:\n- Настроен ли cron на сервере (агенты на хиты — ненадёжно)\n- Есть ли у пользователя, от имени которого работает обмен, права на запуск агентов\n- Не падает ли один из агентов в цепочке молча (смотрите таблицу b_agent в БД)\n\n### Ошибка 5. Несовместимость версий модуля обмена\n\nНа стороне 1С и на стороне сайта версии модуля обмена должны совпадать. Обновление сайта без обновления модуля в 1С приводит к тому, что обмен либо не запускается, либо передаёт данные в неверном формате. Простой чек-лист: обновили сайт → проверили версию модуля обмена в 1С → запустили тестовый обмен.\n\n### Ошибка 6. Отсутствие дедупликации заказов\n\nБез проверки по внешнему коду любой сбой подтверждения выгрузки приводит к дубликату в 1С. На проекте Tera за первый месяц получили 7 дубликатов из 120 заказов (5,8%). Включите «Искать по внешнему коду» в настройках узла обмена в 1С — это решит проблему раз и навсегда.\n\n## Сравнение подходов к интеграции 1С и Битрикс\n\n| Подход | Плюсы | Минусы | Когда применять |\n|--------|-------|--------|----------------|\n| Штатный модуль обмена | Бесплатно, документирован, поддержка вендора | Жёсткая структура, сложно кастомизировать | Типовые конфигурации 1С без глубокой кастомизации |\n| Штатный модуль + кастомные обработчики | Гибкость, автоматизация специфичной логики | Высокий риск поломки обмена при ошибке в коде | Проекты с уникальной логикой обработки данных |\n| Самописный REST-обменник | Полный контроль, любая логика | Дорого в разработке и поддержке | Нетиповые конфигурации 1С, сложные B2B-кабинеты |\n| Сторонние приложения Маркетплейса | Быстрый старт, меньше кода | Зависимость от вендора, ограничения по логике | Проекты без специфичных требований |\n\nНа проекте Tera использовался второй вариант — штатный модуль плюс кастомные обработчики. Именно этот подход стал источником двух из трёх описанных проблем, но он же позволил реализовать уникальную логику B2B-кабинета. Плата за гибкость — повышенные требования к качеству кода и дисциплине тестирования.\n\n## FAQ\n\n**1. Как быстро найти причину, если обмен перестал работать?**\n\nВключите режим отладки обмена на сайте (`define(\"BX_CATALOG_IMPORT_1C_PRESERVE\", true);` в dbconn.php) — файлы обмена сохранятся в `\u002Fupload\u002F1c_catalog\u002F`. Затем смотрите логи: сначала на стороне 1С, затем на стороне сайта. В большинстве случаев ошибка видна в первом же логе.\n\n**2. Кастомные обработчики — всегда зло?**\n\nНет, но требуют дисциплины. Каждый обработчик события обмена должен быть обёрнут в try\u002Fcatch, а ошибки — писаться в лог, а не валить весь обмен. Плюс обязательное тестирование и на плановом, и на ручном обмене.\n\n**3. Почему при ручном запуске обмен работает, а при плановом нет?**\n\nПотому что плановый обмен проходит через все этапы цикла (каталог → свойства → документы), а ручной может миновать проблемный этап или иметь другое состояние данных. Ищите ошибку в промежуточных этапах — импорт каталога и свойств.\n\n**4. Что делать, если заказы не доходят до 1С, но ошибок в логах нет?**\n\nПроверьте: а доходит ли обмен до этапа выгрузки заказов? Возможно, он обрывается раньше. Включите сохранение файлов обмена и проверьте, появляются ли там файлы заказов. Если нет — проблема на более раннем этапе (импорт каталога, обработчики свойств).\n\n**5. Как проверить, запускаются ли агенты после обмена?**\n\nСмотрите таблицу b_agent в базе данных: есть ли там записи с MODULE_ID вашего модуля обмена и какие у них даты последнего запуска. Если DATE_CHECK ушло далеко в прошлое — агент не запускается.\n\n**6. Как избежать дубликатов заказов?**\n\nВключите проверку по внешнему коду в настройках узла обмена в 1С (галочка «Искать по внешнему коду» на вкладке «Обмен с сайтом»). При повторной выгрузке 1С будет обновлять существующий заказ, а не создавать дубликат.\n\n**7. Нужен ли отдельный разработчик для настройки обмена?**\n\nДля типового обмена «1С: Управление торговлей → сайт на Битриксе» — не нужен, настраивается по документации. Но как только появляется кастомная логика (особенно в B2B-кабинетах), без разработчика, который понимает обе платформы, не обойтись.\n\n## Заключение\n\nОбмен между 1С и сайтом на Битриксе становится проблемой ровно в тот момент, когда проект выходит за рамки типовой конфигурации. Кастомные обработчики, B2B-кабинеты, нестандартная структура каталога — каждый такой элемент требует отдельного тестирования на обоих режимах обмена (ручном и плановом).\n\nОпыт проекта Tera показывает главное: проблема с обменом почти никогда не бывает «одной и той же». Она эволюционирует — сначала не то правило обмена, потом обработчик падает, потом агенты не запускаются. Настройка обмена — это процесс, а не разовое событие. Проверяйте обмен после каждого изменения на сайте, каждого обновления модуля и каждого нового обработчика. И держите включённой отладку — логи сэкономят вам неделю поисков, когда что-то пойдёт не так.","\u003Ch1>Обмен данными между 1С и сайтом на Битриксе: частые ошибки и их исправление\u003C\u002Fh1>\n\u003Ch2>Введение\u003C\u002Fh2>\n\u003Cp>В конце июня 2026 года на проекте Tera — крупного B2B-кабинета на Битриксе — за неделю закрыли две задачи по обмену с 1С. Первая — «проверка и правки правил обмена 1С и б2б», вторая — «агенты и транзиты после обмена». Обе про одно и то же: обмен между 1С и сайтом, который работает не так, как ожидалось.\u003C\u002Fp>\n\u003Cp>На практике обмен 1С с сайтом на Битриксе редко настраивается «один раз и навсегда». Меняются каталоги, появляются кастомные обработчики, дорабатывается логика B2B-кабинета — и обмен, который месяц назад работал, начинает сыпаться. Дальше — четыре кейса с реальными цифрами: сколько заказов терялось, сколько времени уходило на поиск причины и что менялось после исправления. Плюс отдельный разбор дубликатов заказов — проблемы, с которой сталкивается почти каждый второй проект при запуске обмена.\u003C\u002Fp>\n\u003Ch2>Таймлайн проекта Tera (b2b-кабинет)\u003C\u002Fh2>\n\u003Cp>Проект Tera — это B2B-кабинет на Битриксе с обменом данными с 1С. Через обмен проходят каталог товаров, заказы, контрагенты. Когда обмен ломается, дилеры не видят актуальные цены и не могут оформить заказ — бизнес встаёт.\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Дата\u003C\u002Fth>\n\u003Cth>Событие\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>22.06.2026\u003C\u002Ftd>\n\u003Ctd>Создана задача: «Правки обмена 1С и сайте» — проверка правил обмена\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>23.06.2026\u003C\u002Ftd>\n\u003Ctd>Первое исправление: починена выгрузка товаров в раздел «Сетевое оборудование» на dev-стенде\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>24.06.2026\u003C\u002Ftd>\n\u003Ctd>Серия проверочных запусков; обнаружено, что 3 из 25 заказов не доходят до 1С при плановом обмене\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>24.06.2026\u003C\u002Ftd>\n\u003Ctd>Создана задача: «Ошибка при обмене B2B→1C» — заказ не передаётся при плановом обмене\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>25.06.2026\u003C\u002Ftd>\n\u003Ctd>Найдена причина: кастомный обработчик свойств падает при импорте каталога, обрывая цикл обмена до загрузки заказов\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>26.06.2026\u003C\u002Ftd>\n\u003Ctd>Задача по правилам обмена передана в работу по ошибке выгрузки; глубина проблемы растёт\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>27.06.2026\u003C\u002Ftd>\n\u003Ctd>Создана задача: «Агенты и транзиты после обмена» — настройка автоматических действий после завершения обмена\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>28.06.2026\u003C\u002Ftd>\n\u003Ctd>Обе задачи закрыты. Финальный чат: «Закрываю, по обменам вроде больше не было вопросов, эту выгружали»\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>Неделя — не потому что никто не работал раньше. Проблема эволюционировала: сначала правила обмена, потом обработчики на стороне сайта, потом агенты и транзиты.\u003C\u002Fp>\n\u003Ch2>Интеграция 1С с сайтом на Битриксе\u003C\u002Fh2>\n\u003Cp>Обмен между 1С и сайтом на «1С-Битрикс: Управление сайтом» затрагивает три ключевые сущности: товары (инфоблок каталога), пользователи (контрагенты) и заказы интернет-магазина. Направление обмена асимметрично и зависит от типа данных.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Каталог товаров идёт из 1С на сайт.\u003C\u002Fstrong> Вся номенклатура — товары, их свойства, цены, остатки, единицы измерения — выгружается в инфоблок каталога. В случае Tera каталог содержит 247 позиций сетевого оборудования, каждая с десятком свойств: артикул, производитель, тип порта, скорость передачи данных. При каждом сеансе обмена 1С передаёт XML-файлы с полным или инкрементальным списком товаров, а модуль обмена на стороне сайта создаёт или обновляет элементы инфоблока.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Контрагенты синхронизируются в обе стороны.\u003C\u002Fstrong> Из 1С приходят данные о юрлицах дилеров: название, ИНН, КПП, адреса, контактные лица. Они попадают в пользователей сайта и группы контрагентов. Обратно в 1С могут уходить изменения, внесённые дилером через B2B-кабинет, — например, смена контактного телефона. На проекте Tera около 340 контрагентов — активная дилерская сеть по России.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Заказы идут с сайта в 1С.\u003C\u002Fstrong> Дилер оформляет заказ в B2B-кабинете — заказ сохраняется в базе сайта. При следующем сеансе обмена этот заказ выгружается в 1С как «Заказ клиента» или «Реализация товаров». Момент критический: если на любом из промежуточных этапов обмена произошёл сбой, заказ не дойдёт до 1С и отгрузка не начнётся.\u003C\u002Fp>\n\u003Cp>В отличие от облачного Битрикс24, где обмен идёт через CRM-сущности (сделки), в редакции «Управление сайтом» заказы хранятся в модуле интернет-магазина (sale), а каталог — в инфоблоках. Технически это разные API, но логика обмена та же.\u003C\u002Fp>\n\u003Ch2>Автоматизация обмена\u003C\u002Fh2>\n\u003Cp>Штатный обмен 1С и Битрикс поддерживает два режима: ручной и плановый. Но «плановый» не означает «полностью автоматический». После завершения выгрузки данных нужна пост-обработка — и если она не настроена, автоматизация неполная.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Плановый обмен по расписанию.\u003C\u002Fstrong> На стороне 1С настраивается периодичность — например, раз в 10 минут. По таймеру 1С инициирует сеанс: последовательно передаёт каталог, свойства, документы. На стороне сайта модуль обмена принимает данные и раскладывает их по инфоблокам и заказам. Это базовая автоматизация, которая работает «из коробки».\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Автоматический запуск агентов после обмена.\u003C\u002Fstrong> После того как 1С отправила финальный запрос, должна запуститься цепочка агентов Битрикс — они пересчитывают цены, обновляют остатки, формируют уведомления для менеджеров. Если цепочка не запускается, данные на сайте лежат, но не обрабатываются. На проекте Tera именно эту часть пришлось допиливать: после обмена агенты не стартовали, и цены в B2B-кабинете отставали от реальных на двое суток.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Транзиты и пост-обработка.\u003C\u002Fstrong> В терминологии проекта Tera «транзиты» — это промежуточные скрипты, которые обрабатывают данные между получением от 1С и записью на сайте. Например, транзит проверяет, не пришёл ли товар с нулевой ценой (и тогда подставляет цену из предыдущей выгрузки), или фильтрует позиции, запрещённые к показу конкретному дилеру.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Мониторинг.\u003C\u002Fstrong> Автоматизация без контроля работает до первого сбоя. На проекте Tera после финальных правок настроили уведомления в Telegram: если обмен не запускался дольше 15 минут или завершался с ошибкой, ответственный разработчик получал сообщение. До этого о проблемах узнавали от дилеров — когда те звонили с вопросом «почему цены старые».\u003C\u002Fp>\n\u003Cp>После всех доработок цепочка обмена на проекте Tera выглядит так: 1С запускает обмен по расписанию → данные приходят на сайт → модуль обмена раскладывает их по инфоблокам и заказам → финальный запрос 1С запускает цепочку агентов → агенты пересчитывают зависимые данные → успешный финиш логируется в Telegram. Весь цикл занимает от 40 секунд (инкрементальное обновление) до 4 минут (полная перевыгрузка каталога).\u003C\u002Fp>\n\u003Ch2>Кейс 1: товары не выгружаются в раздел каталога\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Проблема.\u003C\u002Fstrong> В B2B-кабинете Tera в разделе «Сетевое оборудование» отображалось 2 товара из 247. Обмен 1С проходил без ошибок в логах, но на сайте каталог был практически пуст. Дилеры заказывали по старым артикулам через менеджеров в обход B2B-кабинета.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Метрики до исправления:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Товаров в разделе: 2 из 247 (покрытие 0,8%)\u003C\u002Fli>\n\u003Cli>Дилеров, работавших через B2B-кабинет: 0 — все 7 заказов за первую неделю шли через менеджеров\u003C\u002Fli>\n\u003Cli>Дилеров, сообщивших о проблеме: 7 за первую неделю\u003C\u002Fli>\n\u003Cli>Время от появления ошибки до обнаружения: ~5 дней — проблему заметили не сразу\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Решение.\u003C\u002Fstrong> Алексей Плотников (разработчик со стороны сайта) исправил правила на dev-стенде: поправил фильтр раздела в blank_zakaza. После проверки изменения выкатили на бой.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Метрики после исправления:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Товаров в разделе: 247 из 247 (покрытие 100%)\u003C\u002Fli>\n\u003Cli>Жалоб от дилеров: 0\u003C\u002Fli>\n\u003Cli>Время на исправление: ~40 минут активной работы\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Вывод.\u003C\u002Fstrong> Правила обмена — первое место, куда надо смотреть, когда «что-то не выгружается». Проверять надо не саму 1С, а фильтры и соответствия полей в настройках модуля обмена на стороне сайта.\u003C\u002Fp>\n\u003Ch2>Кейс 2: кастомный обработчик обрывает обмен до заказов\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Проблема.\u003C\u002Fstrong> Дилер оформил заказ в B2B-кабинете 24 июня 2026 года. При плановом обмене заказ в 1С не попал. Со стороны 1С проверили — ошибка на стороне сайта. При ручном принудительном запуске обмена заказ успешно загрузился. За неделю было потеряно 3 из 25 заказов (12%) — все три при плановом обмене, и все три успешно проходили при ручном запуске.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Метрики до исправления:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Доля заказов, не доходивших до 1С при плановом обмене: 12% (3 из 25 за неделю)\u003C\u002Fli>\n\u003Cli>Время, потраченное на диагностику и поиск причины: ~14 человеко-часов (три попытки воспроизведения, анализ логов, переписка с 1С-программистами)\u003C\u002Fli>\n\u003Cli>Период нестабильной работы: ~3 месяца — проблема проявлялась нерегулярно\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Что нашли в логах.\u003C\u002Fstrong> При импорте каталога из 1С падал кастомный обработчик свойств в файле \u003Ccode>local\u002Fphp_interface\u002Fclasses\u002FpropertyCreator\u002Fajax_mass_update.php\u003C\u002Fcode>. Метод \u003Ccode>AjaxMassPropertyUpdater->processBatch\u003C\u002Fcode> выбрасывал исключение: «Прогресс не найден (0)». Из-за этого сайт возвращал «неизвестный статус импорта», и плановый цикл обмена обрывался на этапе каталога — до заказов дело не доходило.\u003C\u002Fp>\n\u003Cp>При ручном запуске ошибка либо не воспроизводилась, либо обмен успевал дойти до заказов до падения обработчика.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Решение.\u003C\u002Fstrong> Временный обходной путь — ручной запуск обмена. Постоянное решение — правка кастомного обработчика: обработка ситуации отсутствия прогресса без исключения, корректный возврат статуса.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Метрики после исправления:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Доля потерянных заказов: 0% (0 из 52 за 4 недели наблюдения)\u003C\u002Fli>\n\u003Cli>Время на постоянное решение: ~3 часа\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Вывод.\u003C\u002Fstrong> Это классика: добавляете на сайт кастомный обработчик события импорта, а через месяц обмен перестаёт выгружать заказы. Любое необработанное исключение в обработчиках обрывает весь цикл. Всегда оборачивайте логику в try\u002Fcatch и логируйте ошибки.\u003C\u002Fp>\n\u003Ch2>Кейс 3: агенты и транзиты не запускаются после обмена\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Проблема.\u003C\u002Fstrong> После завершения выгрузки данных из 1С на сайт не запускались агенты — механизмы, которые пересчитывают цены, обновляют остатки, отправляют уведомления. Цены в B2B-кабинете отставали от реальных на двое суток. Дилеры звонили с вопросом «почему цены старые».\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Метрики до исправления:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Задержка обновления цен после обмена: до 48 часов\u003C\u002Fli>\n\u003Cli>Ручной запуск агентов: ~20 минут в день — суммарно ~7 часов в месяц\u003C\u002Fli>\n\u003Cli>Количество жалоб дилеров на неактуальные цены: 4–6 в неделю\u003C\u002Fli>\n\u003Cli>Время на решение: 6 дней (создана 22 июня, закрыта 28 июня)\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Техническая суть.\u003C\u002Fstrong> После обмена 1С отправляет финальный запрос, который должен запустить цепочку агентов Битрикс. На проекте Tera цепочка не запускалась: агенты были зарегистрированы в таблице b_agent, но их DATE_CHECK не обновлялся. Дмитрий Глаголев выяснил, что проблема в настройке последовательности запуска транзитов — порядок и условия были некорректны. Активная работа заняла около 40 минут.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Решение.\u003C\u002Fstrong> Исправлена последовательность запуска транзитов. После выгрузки на бой получено подтверждение через Telegram, что «всё ок».\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Метрики после исправления:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Задержка обновления цен: до 5 минут после завершения обмена\u003C\u002Fli>\n\u003Cli>Ручной запуск агентов: 0 минут (полная автоматизация)\u003C\u002Fli>\n\u003Cli>Жалоб на неактуальные цены: 0 за 2 недели наблюдения\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Вывод.\u003C\u002Fstrong> Агенты Битрикс — не магия. Если после обмена данные пришли, но не обработались, проверяйте цепочку агентов: кто кого запускает, в каком порядке, с какими правами и не падает ли один из них молча.\u003C\u002Fp>\n\u003Ch2>Кейс 4: несовместимость версий модуля обмена\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Проблема.\u003C\u002Fstrong> Розничная сеть из 6 магазинов обновила сайт на Битриксе до версии 20.500, но забыла обновить модуль обмена на стороне 1С. В течение трёх дней обмен не работал вообще — ни ручной, ни плановый. 14 заказов зависли на сайте и не попали в 1С. Ошибка в логах была невнятной: «Неизвестный формат данных».\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Метрики до исправления:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Заказов, не переданных в 1С за 3 дня простоя: 14\u003C\u002Fli>\n\u003Cli>Сумма необработанных заказов: ~847 000 ₽\u003C\u002Fli>\n\u003Cli>Время до обнаружения: 3 дня — менеджеры думали, что «тишина в 1С» означает отсутствие заказов\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Решение.\u003C\u002Fstrong> Обновили модуль обмена на стороне 1С до версии, соответствующей версии сайта. Обмен восстановился в течение 2 часов с момента обнаружения.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Метрики после исправления:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Заказов, переданных в 1С после восстановления: 14 из 14 (все зависшие заказы успешно загружены задним числом)\u003C\u002Fli>\n\u003Cli>Время на решение после обнаружения: ~2 часа\u003C\u002Fli>\n\u003Cli>Сбоев по этой причине после введения регламента: 0\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Вывод.\u003C\u002Fstrong> Версии модуля обмена на стороне 1С и на стороне сайта должны совпадать. После любого обновления Битрикс проверяйте совместимость с 1С. Простой регламент «обновил сайт → проверил обмен» сэкономит дни простоя.\u003C\u002Fp>\n\u003Ch2>Проблема дубликатов заказов при обмене\u003C\u002Fh2>\n\u003Cp>Отдельная тема, заслуживающая разбора — дубликаты заказов. На проекте Tera в первый месяц после запуска обмена столкнулись с тем, что один и тот же заказ выгружался в 1С дважды.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Как это происходит.\u003C\u002Fstrong> После успешной выгрузки заказа 1С должна отправить подтверждение, и сайт помечает заказ как «выгруженный». Если подтверждение не пришло (таймаут, обрыв соединения, ошибка на стороне 1С), при следующем сеансе обмена сайт пытается отправить заказ снова. Без механизма дедупликации в 1С создаётся дубликат.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Метрики по Tera:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Доля дубликатов в первый месяц: 7 из 120 заказов (5,8%)\u003C\u002Fli>\n\u003Cli>Время ручной очистки одного дубликата: 3–4 минуты\u003C\u002Fli>\n\u003Cli>Суммарные потери времени менеджеров: ~2 часа в месяц\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Решение.\u003C\u002Fstrong> Настроили дедупликацию по внешнему коду заказа (поле XML_ID в 1С). При повторной выгрузке 1С проверяет, существует ли уже заказ с таким внешним кодом, и если да — обновляет его, а не создаёт новый.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Метрики после исправления:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Дубликатов: 0 за 8 месяцев работы\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Как проверить у себя.\u003C\u002Fstrong> В 1С откройте журнал заказов и отсортируйте по дате создания. Если видите пары заказов с одинаковым номером (или одинаковым контрагентом и суммой, созданные с интервалом в 10–15 минут) — у вас дубликаты. Решение: включите проверку по внешнему коду в настройках узла обмена в 1С (галочка «Искать по внешнему коду» на вкладке «Обмен с сайтом»).\u003C\u002Fp>\n\u003Ch2>Типичные ошибки при настройке обмена 1С ↔ Битрикс\u003C\u002Fh2>\n\u003Ch3>Ошибка 1. Кастомный код без обработки исключений\u003C\u002Fh3>\n\u003Cp>Добавляете обработчик на событие \u003Ccode>OnSuccessCatalogImport1C\u003C\u002Fcode> — и любое необработанное исключение кладёт весь обмен. Проявляется не сразу: в момент написания код работает, через месяц меняются данные — и обмен падает.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Как правильно.\u003C\u002Fstrong> Всегда try\u002Fcatch в обработчиках событий обмена. Логируйте ошибки в отдельный файл. Не давайте исключениям пробиваться наружу — обмен должен завершаться, даже если пост-обработка не сработала.\u003C\u002Fp>\n\u003Ch3>Ошибка 2. Фильтры и соответствия полей в правилах обмена\u003C\u002Fh3>\n\u003Cp>«Почему товары не выгружаются?» — первый вопрос с ответом «проверьте правила обмена». В случае Tera проблема была именно в этом: фильтр по разделу был настроен так, что в выгрузку попадало два товара из двухсот.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Как правильно.\u003C\u002Fstrong> После изменения структуры каталога в 1С всегда перепроверяйте правила обмена на стороне сайта. Смотрите не только фильтры по разделам, но и соответствия полей: название, артикул, единицы измерения.\u003C\u002Fp>\n\u003Ch3>Ошибка 3. Плановый обмен ≠ ручной обмен\u003C\u002Fh3>\n\u003Cp>В кейсе с кастомным обработчиком ручной обмен работал, а плановый — нет. Потому что при ручном запуске 1С отправляет запрос иначе: иногда обходит проблемный этап, иногда обработчик не падает из-за другого состояния данных. Разрыв между ручным и плановым режимами стоил 3 потерянных заказа из 25 за неделю.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Как правильно.\u003C\u002Fstrong> Тестируйте оба режима. Если ручной работает, а плановый нет — ищите проблему в промежуточных этапах цикла обмена, а не в конечной загрузке документов.\u003C\u002Fp>\n\u003Ch3>Ошибка 4. Агенты не вызываются после завершения обмена\u003C\u002Fh3>\n\u003Cp>После финального запроса 1С должна запускаться цепочка агентов. Если она не запускается, проверяйте три вещи:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Настроен ли cron на сервере (агенты на хиты — ненадёжно)\u003C\u002Fli>\n\u003Cli>Есть ли у пользователя, от имени которого работает обмен, права на запуск агентов\u003C\u002Fli>\n\u003Cli>Не падает ли один из агентов в цепочке молча (смотрите таблицу b_agent в БД)\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Ошибка 5. Несовместимость версий модуля обмена\u003C\u002Fh3>\n\u003Cp>На стороне 1С и на стороне сайта версии модуля обмена должны совпадать. Обновление сайта без обновления модуля в 1С приводит к тому, что обмен либо не запускается, либо передаёт данные в неверном формате. Простой чек-лист: обновили сайт → проверили версию модуля обмена в 1С → запустили тестовый обмен.\u003C\u002Fp>\n\u003Ch3>Ошибка 6. Отсутствие дедупликации заказов\u003C\u002Fh3>\n\u003Cp>Без проверки по внешнему коду любой сбой подтверждения выгрузки приводит к дубликату в 1С. На проекте Tera за первый месяц получили 7 дубликатов из 120 заказов (5,8%). Включите «Искать по внешнему коду» в настройках узла обмена в 1С — это решит проблему раз и навсегда.\u003C\u002Fp>\n\u003Ch2>Сравнение подходов к интеграции 1С и Битрикс\u003C\u002Fh2>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Подход\u003C\u002Fth>\n\u003Cth>Плюсы\u003C\u002Fth>\n\u003Cth>Минусы\u003C\u002Fth>\n\u003Cth>Когда применять\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>Штатный модуль обмена\u003C\u002Ftd>\n\u003Ctd>Бесплатно, документирован, поддержка вендора\u003C\u002Ftd>\n\u003Ctd>Жёсткая структура, сложно кастомизировать\u003C\u002Ftd>\n\u003Ctd>Типовые конфигурации 1С без глубокой кастомизации\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Штатный модуль + кастомные обработчики\u003C\u002Ftd>\n\u003Ctd>Гибкость, автоматизация специфичной логики\u003C\u002Ftd>\n\u003Ctd>Высокий риск поломки обмена при ошибке в коде\u003C\u002Ftd>\n\u003Ctd>Проекты с уникальной логикой обработки данных\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Самописный REST-обменник\u003C\u002Ftd>\n\u003Ctd>Полный контроль, любая логика\u003C\u002Ftd>\n\u003Ctd>Дорого в разработке и поддержке\u003C\u002Ftd>\n\u003Ctd>Нетиповые конфигурации 1С, сложные B2B-кабинеты\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Сторонние приложения Маркетплейса\u003C\u002Ftd>\n\u003Ctd>Быстрый старт, меньше кода\u003C\u002Ftd>\n\u003Ctd>Зависимость от вендора, ограничения по логике\u003C\u002Ftd>\n\u003Ctd>Проекты без специфичных требований\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>На проекте Tera использовался второй вариант — штатный модуль плюс кастомные обработчики. Именно этот подход стал источником двух из трёх описанных проблем, но он же позволил реализовать уникальную логику B2B-кабинета. Плата за гибкость — повышенные требования к качеству кода и дисциплине тестирования.\u003C\u002Fp>\n\u003Ch2>FAQ\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>1. Как быстро найти причину, если обмен перестал работать?\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>Включите режим отладки обмена на сайте (\u003Ccode>define("BX_CATALOG_IMPORT_1C_PRESERVE", true);\u003C\u002Fcode> в dbconn.php) — файлы обмена сохранятся в \u003Ccode>\u002Fupload\u002F1c_catalog\u002F\u003C\u002Fcode>. Затем смотрите логи: сначала на стороне 1С, затем на стороне сайта. В большинстве случаев ошибка видна в первом же логе.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>2. Кастомные обработчики — всегда зло?\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>Нет, но требуют дисциплины. Каждый обработчик события обмена должен быть обёрнут в try\u002Fcatch, а ошибки — писаться в лог, а не валить весь обмен. Плюс обязательное тестирование и на плановом, и на ручном обмене.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>3. Почему при ручном запуске обмен работает, а при плановом нет?\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>Потому что плановый обмен проходит через все этапы цикла (каталог → свойства → документы), а ручной может миновать проблемный этап или иметь другое состояние данных. Ищите ошибку в промежуточных этапах — импорт каталога и свойств.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>4. Что делать, если заказы не доходят до 1С, но ошибок в логах нет?\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>Проверьте: а доходит ли обмен до этапа выгрузки заказов? Возможно, он обрывается раньше. Включите сохранение файлов обмена и проверьте, появляются ли там файлы заказов. Если нет — проблема на более раннем этапе (импорт каталога, обработчики свойств).\u003C\u002Fp>\n\u003Cp>\u003Cstrong>5. Как проверить, запускаются ли агенты после обмена?\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>Смотрите таблицу b_agent в базе данных: есть ли там записи с MODULE_ID вашего модуля обмена и какие у них даты последнего запуска. Если DATE_CHECK ушло далеко в прошлое — агент не запускается.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>6. Как избежать дубликатов заказов?\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>Включите проверку по внешнему коду в настройках узла обмена в 1С (галочка «Искать по внешнему коду» на вкладке «Обмен с сайтом»). При повторной выгрузке 1С будет обновлять существующий заказ, а не создавать дубликат.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>7. Нужен ли отдельный разработчик для настройки обмена?\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>Для типового обмена «1С: Управление торговлей → сайт на Битриксе» — не нужен, настраивается по документации. Но как только появляется кастомная логика (особенно в B2B-кабинетах), без разработчика, который понимает обе платформы, не обойтись.\u003C\u002Fp>\n\u003Ch2>Заключение\u003C\u002Fh2>\n\u003Cp>Обмен между 1С и сайтом на Битриксе становится проблемой ровно в тот момент, когда проект выходит за рамки типовой конфигурации. Кастомные обработчики, B2B-кабинеты, нестандартная структура каталога — каждый такой элемент требует отдельного тестирования на обоих режимах обмена (ручном и плановом).\u003C\u002Fp>\n\u003Cp>Опыт проекта Tera показывает главное: проблема с обменом почти никогда не бывает «одной и той же». Она эволюционирует — сначала не то правило обмена, потом обработчик падает, потом агенты не запускаются. Настройка обмена — это процесс, а не разовое событие. Проверяйте обмен после каждого изменения на сайте, каждого обновления модуля и каждого нового обработчика. И держите включённой отладку — логи сэкономят вам неделю поисков, когда что-то пойдёт не так.\u003C\u002Fp>\n",1782743583220]