← Все статьи

SiteGuard12 мин чтения

Не работает обмен 1С с сайтом: где искать сбой товаров, цен и заказов

Если не работает обмен 1С с сайтом, сначала нужно уточнить, что именно перестало обновляться. Каталог может загружаться, а цены оставаться прежними; заказы могут поступать в учётную систему, но их статусы не возвращаться в магазин. Общая надпись об ошибке не показывает ни направление сбоя, ни последний успешно обработанный объект.

Ниже — последовательность диагностики обмена с 1С-Битрикс через CommerceML. Она помогает связать журнал операции, переданный XML, результат импорта и данные, которые видит покупатель. Названия настроек и состав пакетов зависят от конфигурации 1С, версии модуля и доработок проекта: проверяйте их по документации своей связки, а не по случайному примеру из другой системы.

1. Зафиксируйте направление и состав обмена

Запишите конфигурацию и версию 1С, модуль обмена, версию сайта, профиль интеграции и адрес обработчика. Добавьте время последнего подтверждённого успеха и первое наблюдаемое расхождение. Подтверждённым считается результат сверки данных, а не только завершение фонового задания без сообщения пользователю.

Что проверяемНаправлениеПодтверждение результата
Товар, предложение, цена, остатокОбычно из 1С на сайтНужный объект и значения в каталоге
Заказ покупателяС сайта в 1ССоответствующий документ в нужной базе
Изменение заказаПо настроенному направлениюСогласованные статусы и реквизиты

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

Обозначьте границу задачи конкретно: «розничная цена выбранного предложения не изменилась после операции». Тогда успех передачи описаний товаров не будет ошибочно принят за исправление всей интеграции.

2. Соберите журнал одной операции целиком

Нужна связная запись от начала сеанса до его завершения. В документации модуля для УТ 11.5 описан журнал обменов с отбором по датам и типам. В другой конфигурации способ просмотра может отличаться; задача остаётся прежней — найти конкретный запуск и все его этапы.

Сопоставьте время в 1С с журналами веб-сервера и приложения. Для каждого запроса полезны адрес, режим, имя файла, размер, HTTP-статус и текст ответа. Если часы или часовые пояса различаются, отметьте поправку. Иначе ошибка соседнего запуска может выглядеть причиной текущего сбоя.

Не ограничивайтесь последней строкой. В официальном FAQ по интеграции показано, что сообщение о неизвестном статусе импорта может сопровождаться конкретной ошибкой PHP или базы данных. Именно дополнительный ответ помогает выбрать участок проверки; само название ошибки не определяет универсальное исправление.

Сохраните копию проблемного пакета и относящуюся к нему запись до очистки временных файлов. В обращение подрядчику передавайте обезличенный фрагмент, версии компонентов и идентификатор операции. Пароли, cookie сеанса и персональные сведения покупателей не должны попадать в публичную переписку или снимок журнала.

3. Проверьте адрес, авторизацию и сохранение сеанса

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

В разборе типичных ошибок 1С-Битрикс отдельно рассматривается передача данных HTTP-авторизации до PHP. Это повод проверить соответствующую границу сервера, но не инструкция переносить старые настройки Apache или CGI в любую современную инфраструктуру.

Посмотрите, не подменяется ли ответ страницей входа, защитной проверкой или перенаправлением на другой адрес. Если первый шаг проходит, а следующий теряет авторизацию, исследуйте сохранение сеанса и маршрут запросов. Не отключайте защиту сайта целиком: подтвердите конкретное блокирующее правило и согласуйте ограниченное изменение с ответственным за инфраструктуру.

Исправление авторизации проверяйте штатным клиентом обмена. Ручной запрос из другого компьютера может идти через иной прокси, использовать другую учётную запись и не воспроизводить исходные условия.

4. Разделите доставку файла и завершение импорта

Документированный алгоритм передачи данных на сайт использует режимы, приведённые ниже. После авторизации клиент сохраняет полученные имя и значение cookie и передаёт их в следующих запросах. Если версия протокола предусматривает ключ сеанса, его также нужно сохранять и отправлять установленным способом.

РежимЧто проверяется
checkauthАвторизация и получение данных сеанса
initПараметры обмена, включая ZIP и file_limit
fileДоставка файла или его части
importОбработка переданного файла

success и progress здесь обозначают ответы, а не одинаковые для всех операций команды. Успех этапа file ещё не подтверждает импорт. Ответ progress требует продолжения предусмотренной протоколом пошаговой обработки до окончательного результата; failure означает отказ.

HTTP 200 с текстом failure нельзя записывать как успешную синхронизацию. Пустой ответ также не даёт подтверждения. Если связь прервалась после выполнения операции, её результат может быть неопределённым для клиента: перед повтором сопоставьте журнал и состояние целевых объектов.

При длительном progress сравнивайте этапы и время, ищите изменения состояния обработки. Само повторение этого слова не отличает нормальную работу большого пакета от застрявшего шага. Не запускайте параллельно ещё несколько обменов ради ускорения диагностики.

При отказе не предполагайте, что сайт остался полностью неизменным. Часть объектов могла обновиться до проблемного шага. Зафиксируйте уже обработанные записи и проверьте правила повторного запуска своего модуля. Восстановление после частичного импорта должно учитывать текущее состояние, иначе повторная загрузка скроет первоначальную последовательность событий.

5. Убедитесь, что объект вообще выбран для выгрузки

Отсутствие товара в пакете начинается раньше HTTP. Проверьте профиль, отбор номенклатуры, выбранные виды цен, склады и режим выгрузки. Фильтр определяет, какие данные попадут в обмен; наличие товара в справочнике ещё не означает, что он удовлетворяет условиям этого профиля.

В описании зарегистрированных изменений для модуля обмена версии 8.1 отдельно указаны неотправленные пакеты и отбор по условиям выгрузки. Поэтому проверьте обе стороны: зарегистрировано ли нужное изменение и может ли оно пройти выбранный фильтр. Название формы относится к конкретному модулю, а не ко всем конфигурациям 1С.

Изменение карточки на сайте не обязано зарегистрировать изменение в исходной базе 1С. Удаление товара на сайте тем более не является безопасным способом заставить систему выгрузить его заново. Сначала найдите исходный объект и установленный для него механизм регистрации.

Полный обмен меняет масштаб операции и при определённых настройках затрагивает объекты, которых нет в выгрузке. Не используйте его первым диагностическим действием. Для повторной отправки согласуйте состав данных, проверьте правила деактивации и испытайте выбранный сценарий на копии или ограниченном тестовом наборе.

6. Проверьте пакет CommerceML, архив и целостность XML

Сверьте версию схемы, структуру архива и перечень файлов с документацией используемого модуля. В официальном описании XML-файлов встречаются import.xml, offers.xml, prices.xml и rests.xml, включая размещение в каталогах пакета. Это пример поддерживаемой структуры, а не обязательный набор имён для любой версии CommerceML.

Сведения о ценах и остатках могут быть организованы по-разному. Не объявляйте обмен неполным только потому, что отсутствует ожидаемый вами stocks.xml: сначала установите, в каком файле и разделе текущая схема передаёт остатки. Аналогично наличие одного import.xml не доказывает передачу всех нужных сущностей.

Параметры ZIP и допустимого размера передаваемой части берутся из согласованного протокола, в том числе ответа init. Проверьте, что получены все части и сервер собрал нужный файл. Сравнивайте размер и контрольную сумму одной и той же формы данных: исходный ZIP нельзя напрямую сравнивать с распакованным XML.

Проверьте распаковку, кодировку, завершённость XML и ошибки синтаксического разбора. Корректный синтаксис не гарантирует соответствия схеме и правильного содержимого. Найдите внутри конкретный идентификатор объекта и ожидаемое значение. Для передачи в поддержку используйте копию; не редактируйте рабочий пакет до сохранения исходного свидетельства.

Проследите ссылки между сущностями: предложение относится к товару, цена — к предложению и типу цены, остаток — к выбранному складу. Связанный объект может передаваться в другом пакете или уже существовать на сайте. Поэтому проверяйте всю цепочку соответствий, не требуя, чтобы каждая порция изменений заново содержала полный каталог.

7. Сверьте товар, предложение и внешние идентификаторы

Карточка товара и торговое предложение, или SKU, могут быть разными объектами. Условная футболка объединяет варианты по размеру и цвету, а цена и остаток относятся к выбранному варианту. Проверка только родительской карточки не показывает, что произошло с конкретным предложением.

Сопоставьте идентификатор или GUID в 1С, значение <Ид> в XML и внешний код целевого элемента. В описании полей инфоблоков XML_ID указан отдельно от внутреннего ID и названия NAME. Одинаковые названия не являются доказательством, что найден один и тот же объект обмена.

У предложений схема может использовать составной идентификатор, связанный с товаром и характеристикой. Не отбрасывайте часть кода и не заменяйте его артикулом ради совпадения строк. Сверьте также каталог, инфоблок предложений и связь с родителем: данные могли обновиться в другом месте, которое публичная карточка не использует.

Если после переименования или переноса появились дубли, сохраните обе записи и выясните происхождение идентификаторов. Массовая перезапись внешних кодов без карты соответствий способна испортить последующие обмены. Исправление должно восстанавливать конкретную связь, а не просто объединять похожие названия.

8. Если не выгружаются цены на сайт, проверьте их разрезы

Для одной номенклатуры могут существовать разные цены по характеристикам и типам. Уточните, какая цена должна попасть на сайт: розничная или оптовая, в какой валюте, для какой единицы и на какой момент. Сравнение двух чисел без этих признаков часто создаёт ложное впечатление потери данных.

В описании файла цен отдельно передаются идентификатор предложения, тип цены, значение за единицу и валюта. Проверьте эту связку целиком. Если нужного значения нет в исходном пакете, исследуйте выборку 1С; если оно есть, переходите к результату импорта на сайте.

После импорта найдите цену у того же предложения и типа. Затем проверьте, какую цену использует публичный компонент и кому она доступна. Посетитель и администратор могут видеть разные результаты из-за правил проекта. Скидка, округление или пересчёт валюты также должны быть учтены в заранее согласованном ожидании.

Не подменяйте исправление обмена ручным изменением цены в административном разделе. Такое действие может временно изменить витрину, но следующий обмен снова запишет исходные данные. Сначала определите источник верного значения и правило его передачи.

9. Разделите остаток, доступность и отображение карточки

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

Проверьте выбранный склад, идентификатор предложения, единицу измерения и момент расчёта. Установите, входят ли в показатель резервы и другие ограничения по правилам вашей конфигурации. Если обмен передаёт несколько складов, сравните значения отдельно, прежде чем объяснять расхождение их суммой.

Затем откройте состояние импортированного объекта на сайте: активность, привязку к разделу, цену и настройки возможности покупки. Товар может присутствовать в каталоге, но не попадать в публичную выборку. Это уже следующий участок цепочки, а не доказательство неудачной передачи XML.

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

10. Диагностируйте заказы отдельным маршрутом

В протоколе интеграции type=catalog относится к каталогу, а type=sale используется для документов. Для получения документов с сайта официальный алгоритм загрузки в учётную систему описывает запрос mode=query после подготовки сеанса. Работоспособность каталога не подтверждает этот маршрут.

Выберите один тестовый заказ и проследите его от отбора на сайте до документа в нужной базе 1С. Сверьте идентификаторы, состав, количество и сумму. Если XML получен, но документ не записан, ищите ошибку заполнения обязательных реквизитов, сопоставления номенклатуры или контрагента, а не повторяйте проверку доступности сайта.

Обратное обновление заказа исследуйте отдельно: какие изменения должны сформироваться в 1С, какой пакет их содержит и какие правила сайта применяют результат. Не переносите инструкции о документах оплаты и отгрузки одной конфигурации на все варианты интеграции.

Проверяйте завершение и подтверждение обмена по протоколу используемого модуля. После сбоя выясните, создан ли документ, прежде чем отправлять его повторно. Тест не должен запускать настоящую оплату, отгрузку или уведомления покупателям: предусмотрите согласованный учебный сценарий и контроль дублей.

11. Проведите сверку одного тестового предложения

Предположим, в учебном магазине у синей футболки размера M должна измениться розничная цена с 1200 до 1350 рублей. Для проверки выбран один SKU, один тип цены и один склад. Наличие соседнего размера L с другой ценой не должно влиять на критерий успеха.

  1. Зафиксируйте идентификаторы товара и предложения, текущую цену и ожидаемое значение.
  2. Подтвердите исходное изменение в 1С и включение объекта в выбранный обмен.
  3. Найдите в сформированном пакете тот же идентификатор, тип цены и 1350 рублей.
  4. Проверьте доставку файла и окончательный результат его обработки.
  5. Сверьте сохранённую цену предложения в административной части сайта.
  6. Откройте публичную карточку с вариантом M и проверьте ожидаемое отображение.

Если XML содержит 1350, а в объекте сайта остаётся 1200, изучайте сопоставление и импорт. Если в объекте уже 1350, а посетитель видит 1200, проверяйте выбор предложения, правила цены и кеш. Если в пакете вообще нет нужной записи, вернитесь к настройкам выгрузки 1С.

Меняйте по одной подтверждённой причине. После исправления повторите ограниченный сценарий и убедитесь, что он не создаёт дубликат. Такой тест показывает место расхождения; он не доказывает автоматически корректность всех товаров, складов и заказов.

До испытания на копии проверьте адрес назначения тестового профиля. Он не должен случайно отправлять учебные цены в рабочий магазин. Если проверка согласована на действующем сайте, заранее определите допустимый объект, время изменения и порядок возврата значения, чтобы покупатель не оформил заказ по экспериментальной цене.

12. Подтвердите восстановление и закрепите проверку

Завершайте работу по наблюдаемому результату. Для затронутого направления должны совпасть выбранные исходные данные, переданный пакет, результат обработки и состояние целевого объекта. Для каталога добавляется проверка витрины, для заказов — запись документа и согласованные изменения его состояния.

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

В итоговой записи укажите, где именно найден разрыв: объект не выбран, пакет не передан, импорт отклонён, соответствие нарушено или витрина использует другое значение. Для каждой оставшейся проблемы назначьте следующий проверяемый шаг. Формулировка «обмен заработал» без контрольных объектов затруднит разбор повторного расхождения.

Сохраните причину, изменённые параметры, проверенные объекты и ответственного за следующий запуск. Для регулярного контроля полезны время последней подтверждённой операции, число ожидаемых и обработанных объектов, отказы и возраст неотправленных изменений. Нормы задавайте с учётом расписания и режима обмена: отсутствие пакета без новых изменений само по себе не является сбоем.

Подключите SiteGuard для внешнего наблюдения за HTTP-доступностью магазина. Корректность синхронизации товаров, цен и заказов проверяйте по журналам и контрольным объектам своей интеграции.