Содержание
Интеграция сайта с 1С передаёт товары, цены, остатки и заказы между интернет-магазином и учётной системой. Проверять её нужно по результату: нужная цена появилась на витрине, заказ записался в учёте, повторный запуск не создал дубль. Надпись «обмен завершён» этого ещё не доказывает. Если покупатель видит старый остаток, а менеджер переносит заказы вручную, разбирать придётся весь путь данных, включая расписание, правила сопоставления и обработку ошибок.
Как устроен обмен сайта с 1С
В типовом обмене на сайт приходят каталог, торговые предложения, цены и остатки. Заказы передаются с сайта в учётную систему; затем могут возвращаться статусы и другие изменения. Точный состав зависит от конфигурации 1С, CMS, версии модуля и внесённых доработок.
В открытом протоколе 1С и 1С-Битрикс эти потоки разделены на каталог и заказы. Сеанс такого обмена инициирует 1С, а документы передаются в формате CommerceML 2. Это описание штатного протокола. В отдельной интеграции через API инициатором может быть сайт или промежуточный сервис.
Для владельца магазина важнее другая граница: кто вправе менять конкретное значение. Например, розничная цена ведётся в 1С, описание товара редактируется на сайте, статус оплаты приходит от платёжной системы. Если две системы без правил перезаписывают одно поле, очередной обмен способен отменить правильное изменение.
Составьте карту данных до исправления кода. В ней нужны поле, источник, направление, условие обновления и ответственный. Формулировка «всё синхронизируется» скрывает больше вопросов, чем решает.
| Данные | Что согласовать | Как проверить |
|---|---|---|
| Товар и варианты | Постоянные идентификаторы, связь размера и цвета с товаром | Повторно передать существующую позицию |
| Цена | Тип цены, валюта, округление, скидки | Сверить витрину и итог корзины |
| Остаток | Склады, резерв, правило доступности | Проверить последний доступный экземпляр |
| Заказ | Идентификатор, состав, сумма, состояние передачи | Найти одну и ту же покупку в обеих системах |
| Статусы | Допустимые переходы и владелец каждого статуса | Проверить оплату, отмену и повторное уведомление |
Почему не обновляются цены и остатки
Начните с одного товара, у которого известны идентификатор, вариант, склад и тип цены. Сравните его значение в 1С, переданный пакет, запись в базе сайта и витрину. Так можно найти участок, на котором данные перестали соответствовать ожиданию. Массовая полная выгрузка до этой проверки часто только увеличивает объём работы.
Если в пакете уже старая цена, проверьте отбор и настройки выгрузки в 1С. Если пакет правильный, а запись сайта старая, смотрите импорт и сопоставление полей. Если в базе всё верно, но покупатель видит прежнюю сумму, проверьте кеш, выбранный тип цены и правила расчёта скидок. Страница товара и корзина могут использовать разные вычисления.
С остатками отдельно выясните, какое количество магазин считает доступным для продажи. Физический остаток склада, свободный остаток и количество с учётом резерва могут различаться. Это не всегда ошибка интеграции. Ошибкой становится ситуация, когда разработчики и склад понимают поле по-разному.
Интервал обмена тоже выбирают по процессу магазина. Часовая задержка приемлема для одного каталога и опасна для другого. Зафиксируйте допустимый возраст данных, а затем проверьте, выполняется ли это условие в рабочее время. Частый запуск не гарантирует свежесть: предыдущий сеанс может ещё обрабатываться или регулярно завершаться ошибкой.
Откуда берутся дубли товаров и заказов
Название товара плохо подходит для сопоставления. Его исправляют, сокращают и переводят. Артикул тоже не всегда уникален: один артикул может объединять несколько вариантов или повторяться в разных источниках. Для обмена нужен устойчивый идентификатор и понятные правила его сохранения при переносах.
Если каталог уже задвоился, не удаляйте одну половину только по похожим названиям. На карточки могут ссылаться старые заказы, отзывы, остатки и поисковые страницы. Сначала определите основную запись, зависимости и порядок объединения. Иначе уборка дублей превратится в потерю истории.
Для заказов особенно важна безопасная повторная обработка, её называют идемпотентностью. Отправитель может не получить подтверждение, хотя получатель уже сохранил документ. Если при повторе создавать новую запись, одна покупка появится в учёте дважды. Согласованный идентификатор позволяет распознать повтор и обработать его по правилам.
Здесь мало поставить проверку «такой номер уже есть». Нужно определить, какие поля разрешено обновлять после оплаты, отгрузки и отмены, как обрабатывать одновременные изменения и где фиксировать конфликт. Номер, видимый менеджеру, может отличаться от внутреннего идентификатора обмена. Связь между ними должна сохраняться.
Что делать, если заказы с сайта не попадают в 1С
Возьмите конкретный потерянный заказ и запишите время создания, номер, сумму и состояние оплаты. Проверьте, сохранён ли он на сайте и входит ли в условия выгрузки. Затем проследите запрос, ответ и запись в 1С. Не начинайте с общего вопроса «почему интеграция не работает»: без примера обе стороны будут проверять разные события.
| Симптом | Где искать | Что считать подтверждением |
|---|---|---|
| Заказ есть на сайте, передачи нет | Отбор, расписание, очередь | Запись о попытке отправки конкретного заказа |
| Передача была, документа нет | Ответ сервера, импорт, обязательные поля | Документ в 1С и его связь с заказом сайта |
| Заказ пришёл дважды | Повторы, идентификаторы, параллельные запуски | Один документ после повторной передачи |
| Сумма отличается | Скидки, доставка, округление, состав | Согласованная сумма по строкам и итогу |
| Изменение статуса пропало | Направления обмена, допустимые переходы | Сохранённый статус после следующего сеанса |
Журнал должен позволять найти событие по номеру заказа или идентификатору обмена. Полезны время, направление, этап обработки, код ошибки и число попыток. Пароли, токены и полные платёжные данные в таком журнале хранить не следует.
Договоритесь, кто замечает зависший обмен. Уведомление «сервер доступен» не обнаружит заказ, который двое суток лежит в очереди. Для интеграции нужны собственные признаки сбоя: нет успешного сеанса дольше допустимого интервала, растёт очередь, появилась ошибка записи. Принципы разбора повторяющихся инцидентов описаны в статье о поиске первопричины сбоя.
Как принять интеграцию: сценарии вместо одной выгрузки
Проверяйте обмен на изолированных копиях сайта и учётной базы. Тестовая среда не должна рассылать сообщения настоящим покупателям или передавать учебные заказы в рабочую 1С. Если безопасной копии нет, сначала согласуйте ограниченный тест и способ защиты рабочих данных.
Для первичной проверки подготовьте небольшой набор: простой товар, товар с вариантами, позицию с нулевым остатком, товар с несколькими ценами. Добавьте заказы со скидкой, платной доставкой и отменой. Набор зависит от магазина, универсальной проверки одной карточкой здесь нет.
Обязательные сценарии приёмки:
- Изменить цену и доступное количество, дождаться обработки, проверить карточку и корзину.
- Создать заказ и найти его в обеих системах с одинаковым составом и суммой.
- Повторить передачу того же заказа, проверить отсутствие второго документа.
- Прервать связь на согласованном этапе, восстановить её и проверить завершение обработки.
- Выполнить отмену или изменение, затем убедиться, что следующий обмен не вернул старое состояние.
- Передать некорректную запись, проверить понятную ошибку и возможность исправить её без повторной загрузки всего каталога.
Для каждого сценария сохраните ожидаемый и фактический результат, идентификаторы записей и время проверки. Это пригодится после обновления модуля или замены подрядчика. Скриншот зелёного уведомления без сверки документов такой протокол не заменяет.
Когда дорабатывать обмен и с чего начать
Штатного CommerceML бывает достаточно для стандартного каталога и понятного движения заказов. Собственный API рассматривают, когда нужны другие сущности, сложные правила, особые требования к задержке или несколько источников данных. Сам по себе переход на API не исправляет неясные идентификаторы и противоречивые статусы.
Не стоит одновременно менять CMS, конфигурацию 1С и транспорт обмена без отдельного плана. После такой замены трудно понять, где возникла ошибка. Начните с карты текущего обмена и воспроизводимого примера сбоя, затем меняйте один согласованный участок.
Если обмен держится на ручных перезапусках, история доработок потеряна или исправление одного поля ломает другое, полезен технический аудит. На выходе нужны схема потоков, список причин с примерами, порядок исправлений и критерии приёмки. Объём, стоимость и сроки обследования фиксируются до старта.
Частые вопросы
Что даёт интеграция сайта с 1С?
Она передаёт согласованные данные между магазином и учётной системой: обычно каталог, цены, остатки, заказы и статусы. Состав и направления зависят от конфигурации и настроек. Приёмка должна подтверждать результат в обеих системах.
Почему обмен завершён, а цена на сайте старая?
Сообщение об окончании сеанса не доказывает обновление каждого товара. Проверьте цену в исходном пакете, запись в базе сайта, тип цены и кеш витрины. Это позволит отделить ошибку выгрузки от ошибки отображения.
Как избежать дублей при повторной передаче заказа?
Использовать устойчивый идентификатор заказа и безопасную повторную обработку. Повтор должен распознаваться как обращение к существующей записи. Отдельно задаются правила изменения уже оплаченных, отменённых и отгруженных заказов.
Как часто нужно обновлять остатки?
Интервал зависит от скорости продаж, резервирования и допустимого риска продать отсутствующий товар. Сначала определите допустимую задержку для магазина, затем измерьте фактический возраст данных и длительность обработки.
Обязательно ли писать собственный API для обмена?
Нет. Сначала проверьте возможности штатного модуля и CommerceML. Собственный API имеет смысл при требованиях, которые они не покрывают. В любом варианте нужны правила данных, журнал ошибок и сценарии восстановления.
Кто должен исправлять ошибку: разработчик сайта или специалист 1С?
Исполнитель определяется после локализации сбоя: выгрузка, передача, импорт или отображение. Обе стороны должны иметь общий пример и сверять результат. Ответственного за приёмку всего обмена назначают заранее.
