Интеграция сайта с 1С: как проверить обмен данными

Как проверить обмен сайта с 1С: товары, цены, остатки и заказы

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

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

Первый вопрос при проверке интеграции — какая система является источником каждого типа данных и какой результат должен получиться после обмена. Без этого даже очевидное на первый взгляд расхождение нельзя однозначно назвать ошибкой.

С чего начинать проверку интеграции сайта с 1С

До запуска тестов нужно составить карту обмена: какие данные передаются, из какой системы, в каком направлении и при каком событии.

В типичном интернет-магазине товары, цены и остатки могут передаваться из 1С на сайт, а заказы — с сайта в 1С. Но это не универсальная схема. В конкретном проекте часть данных может управляться на сайте, через CRM или промежуточный интеграционный сервис.

Для каждого поля важно определить источник истины — систему, в которой значение считается основным.

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

До проверки желательно зафиксировать:

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

Интеграция может использовать CommerceML, API или собственный механизм обмена. Способ передачи влияет на техническую диагностику, но не меняет основной принцип тестирования: нужно пройти путь данных от источника до конечного бизнес-результата.

Как проверить выгрузку товаров из 1С

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

Полезно проверить:

• новый товар;
• уже существующий товар;
• товар с характеристиками или вариантами, если они используются;
• товар, данные которого изменяются;
• товар, который должен стать недоступным по правилам проекта.

Для нового товара сверяют не только название. В зависимости от структуры каталога проверяют:

• идентификатор;
• артикул или SKU;
• категорию;
• характеристики;
• торговые предложения;
• изображения, если они входят в обмен;
• активность;
• обязательные свойства;
• связь с нужным разделом сайта.

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

Например, в 1С товар «Кресло офисное А» переименовали в «Кресло офисное А, серое». После синхронизации на сайте должна измениться существующая карточка. Если рядом появилась вторая, проблема может быть не в содержимом выгрузки, а в сопоставлении сущностей.

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

Как проверить изменение существующего товара

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

Для проверки можно взять один товар, который уже есть в обеих системах, изменить в источнике одно контролируемое поле и выполнить обмен.

После синхронизации нужно убедиться, что:

обновился именно существующий товар;

новое значение передалось правильно;

не появился дубль;

остальные данные не изменились неожиданно.

Отдельно можно протестировать:

смену названия;

изменение характеристики;

перенос в другую категорию;

изменение активности;

обновление описания, если оно синхронизируется;

изменение состава торговых предложений.

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

Как проверить цены

Цены нужно тестировать отдельно от карточки товара, потому что правильная номенклатура ещё не гарантирует правильное коммерческое предложение покупателю.

Базовый сценарий выглядит так:

Зафиксировать цену в системе-источнике.

Запустить обмен.

Проверить значение на сайте.

Изменить цену.

Выполнить синхронизацию повторно.

Убедиться, что обновилась нужная позиция.

Проверить цену на всех этапах покупки.

Последний пункт особенно важен.

Цена может быть правильной в карточке и отличаться:

• в каталоге;
• в корзине;
• при оформлении заказа;
• в переданном в 1С заказе.

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

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

Если бизнес использует несколько типов цен — розничную, оптовую, партнёрскую или персональную — они проверяются отдельно. Но такие сценарии не нужно создавать искусственно, если проект их не использует.

Важно также разделять цену, переданную из 1С, и итоговую цену покупки.

Сайт может самостоятельно применять:

• промокоды;
• скидки;
• бонусы;
• акции;
• персональные правила.

Поэтому ситуация «в 1С 10 000 рублей, а пользователь видит 9 000» не обязательно является ошибкой. Сначала нужно определить, какие расчёты выполняет каждая система.

Как проверить остатки

При проверке остатков сначала нужно выяснить, что именно сайт получает из 1С.

Это может быть:

• остаток одного склада;
• сумма нескольких складов;
• доступное к продаже количество;
• другое вычисляемое значение по правилам бизнеса.

Поэтому простое сравнение цифры в карточке товара с первым найденным остатком в 1С может дать ложный вывод.

Для контролируемого теста удобно последовательно менять значение, например: 10 → 3 → 0 → 7.

После каждого обмена проверяются:

• значение на сайте;
• нужный товар или SKU;
• возможность добавить товар в корзину;
• возможность оформить заказ;
• восстановление доступности после появления товара.

Особенно важен нулевой остаток. Нужно заранее знать, что должен делать сайт:

• полностью запрещать заказ;
• оставлять карточку активной, но отключать покупку;
• позволять предзаказ;
• использовать другой сценарий.

Это уже бизнес-логика, а не универсальное правило интеграции.

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

Как проверить передачу заказа с сайта в 1С

Заказ нельзя считать успешно синхронизированным только потому, что в 1С появилась новая запись.

Нужно сравнить содержимое заказа в двух системах.

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

Лучше всего использовать тестовый заказ с заранее известным результатом.

Например: 2 единицы товара А + 1 единица товара Б → определённая доставка → известная итоговая сумма.

После оформления фиксируются данные на сайте, затем находится соответствующий заказ в 1С и выполняется сверка.

Если проект поддерживает разные сценарии, можно дополнительно проверить:

• заказ одного товара;
• несколько позиций;
• несколько единиц одной позиции;
• скидку;
• разные способы доставки;
• разные способы оплаты;
• оформление авторизованным и неавторизованным пользователем.

Что проверить после изменения заказа

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

Перед тестированием нужно определить, какая система является основной после создания заказа.

Возможны разные модели:

• сайт создаёт заказ, затем все изменения выполняются в 1С;
• сайт продолжает управлять частью полей;
• обе системы обмениваются изменениями;
• между ними работает CRM или другой промежуточный сервис.

По требованиям конкретного проекта проверяют:

• изменение статуса;
• отмену;
• оплату;
• отгрузку;
• изменение состава;
• изменение количества;
• другие предусмотренные состояния.

Ключевой критерий — сайт и 1С не должны показывать противоречащие друг другу версии одного заказа.

Например, если в 1С заказ отменён, а клиент продолжает видеть в личном кабинете статус «готовится к отправке», технически обмен мог отработать частично, но бизнес-процесс остаётся сломанным.

Как проверить связь товаров в заказе

Иногда заказ успешно создаётся в 1С, но его позиции сопоставляются неправильно.

Особенно это возможно для каталогов с:

• торговыми предложениями;
• размерами;
• цветами;
• комплектациями;
• разными единицами измерения.

Для каждой позиции тестового заказа нужно убедиться, что:

• выбран правильный товар;
• передано нужное предложение;
• количество совпадает;
• не произошла подмена родительского товара и конкретного SKU;
• переименование товара не разрушило связь.

Например, пользователь заказал смартфон на 256 ГБ в чёрном цвете. Недостаточно увидеть в 1С название модели: нужно убедиться, что передалась именно выбранная модификация.

Как тестировать полный обмен и обмен изменениями

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

Полный обмен позволяет передать большой актуальный набор данных.

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

Для проверки можно последовательно:

создать новый товар;

изменить существующий товар;

обновить цену;

изменить остаток;

запустить обычную синхронизацию;

убедиться, что все изменения пришли без необходимости полного переимпорта каталога.

Если корректность данных регулярно восстанавливается только после полного обмена, это не стоит считать нормальным рабочим решением без анализа причины.

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

Какие ошибки и сбои нужно проверить отдельно

Интеграция должна работать не только в идеальном сценарии.

До запуска полезно понять, что произойдёт, если:

1С временно недоступна;

сайт недоступен;

соединение оборвалось;

обмен остановился посередине;

пришли некорректные данные;

синхронизация запустилась повторно;

один заказ был отправлен дважды;

сервис восстановился после сбоя.

Здесь не существует одного правильного поведения для всех проектов. Важно, чтобы оно было определено заранее.

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

Нужно проверить:

• фиксируется ли ошибка;
• можно ли безопасно повторить синхронизацию;
• не появляются ли дубли;
• не теряются ли данные;
• получает ли ответственный специалист информацию о проблеме.

Особенно опасна ситуация, когда обмен фактически остановился, но ни пользователь, ни администратор этого не видят.

Где искать проблему, если данные не совпадают

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

Рабочая диагностическая схема: Источник → формирование → передача → импорт → сохранение → отображение

Она позволяет локализовать проблему значительно быстрее, чем формулировка «1С опять неправильно синхронизируется».

Почему одного тестового товара недостаточно

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

Проверять весь каталог вручную обычно не требуется. Гораздо полезнее сформировать контрольную выборку, которая представляет разные сценарии.

Например:

• простой товар;
• товар с вариантами;
• новый товар;
• изменённый товар;
• товар с нулевым остатком;
• позиция с изменённой ценой;
• заказ из одной позиции;
• заказ из нескольких позиций.

После запуска интеграции полезно дополнять такую проверку агрегированными показателями.

Можно контролировать:

• количество активных товаров;
• товары без цены;
• товары с неожиданным нулевым остатком;
• количество заказов на сайте и в 1С;
• непереданные заказы;
• заказы, у которых долго не меняется ожидаемый статус.

Конкретные контрольные значения зависят от магазина. Универсального допустимого процента расхождений здесь нет.

Как отличить ошибку интеграции от бизнес-правила

Не каждое различие между сайтом и 1С является дефектом.

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

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

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

До создания задачи разработчику стоит сформулировать ожидаемый результат: Какое именно значение должно быть на сайте по согласованной бизнес-логике?

Если ожидаемого результата никто не может определить, проблема сначала находится в требованиях, а не обязательно в интеграции.

Что зафиксировать в требованиях к обмену

Для поддержки интеграции недостаточно требования «синхронизировать сайт с 1С».

Для каждого важного типа данных желательно зафиксировать:

Для заказов дополнительно нужно определить:

• в какой момент заказ передаётся;
• какая система управляет им после создания;
• как сопоставляются статусы;
• как передаётся отмена;
• что происходит при изменении состава;
• какие данные не должны меняться после определённого этапа.

Такая документация полезна не только разработчику. Она позволяет бизнесу быстрее понять, является ли конкретное расхождение дефектом.

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

Как принимать интеграцию перед запуском

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

После исправления найденной ошибки тот же сценарий нужно пройти заново.

Такую проверку лучше проводить на тестовых данных с заранее определённым ожидаемым результатом, а не на реальных заказах покупателей.

Что контролировать после запуска

Даже полностью протестированная интеграция может перестать работать позже.

Причиной могут стать:

• обновление 1С;
• изменение сайта;
• новая бизнес-логика;
• изменение структуры данных;
• изменение инфраструктуры;
• доработка API;
• некорректная настройка расписания обмена.

После запуска стоит контролировать:

• время последней успешной синхронизации;
• ошибки обмена;
• непереданные заказы;
• неожиданные расхождения цен;
• проблемы с остатками;
• появление дублей;
• заказы без ожидаемых обновлений статуса.

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

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

Основные ошибки при проверке интеграции

Проверили только первый полный обмен

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

Проверили товары, но не заказы

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

Ориентируются на статус «успешно»

Обмен завершается технически без ошибки, но значения никто не сравнивает.

Не определили источник каждого поля

Сотрудники правят значение на сайте, 1С при следующем обмене возвращает старое, после чего проблема воспринимается как случайная.

Проверили только простой товар

Торговые предложения, характеристики и нулевые остатки остаются непроверенными.

Не проверили повторную отправку

После временного сбоя повтор запуска создаёт дубли товаров или заказов.

Не контролируют обмен после запуска

Интеграция перестаёт работать, а бизнес узнаёт об этом после серии звонков клиентов или ручной сверки заказов.