Цены и остатки на сайте не совпадают с учётной системой: как организовать обмен
Автоматическая выгрузка ещё не означает согласованные данные. Цена может относиться к другому типу покупателя, остаток — включать резерв, а успешно переданный файл — содержать неприменённые строки. Надёжный обмен начинается с правил: что передаём, кто владеет каждым полем, как узнаём об ошибке и чем подтверждаем результат.
1. Сначала уточните, какие значения сравниваются
Фраза «в 1С пять штук, а на сайте три» ещё не описывает ошибку. Возможно, две единицы зарезервированы; выбран другой склад или товарное предложение. То же с ценой: розничная, оптовая и персональная цены различаются, а скидка может применяться только в корзине. Сравнивайте один товарный вариант, склад, тип цены, валюту и момент времени.
Попросите для одной проблемной позиции собрать цепочку: значение в источнике, запись в выгрузке, результат обработки, значение в базе сайта и показанную покупателю карточку. Если в базе цена правильная, а на странице старая, проблема может быть в кеше, не в передаче. Повторный полный обмен без диагностики способен скрыть причину или затронуть исправные данные.
В документации 1С-Битрикс отдельно описаны товарные предложения, цены, остатки и документы обмена. Это полезное напоминание: «каталог» — не один неделимый файл. Конкретный состав зависит от версии модуля и настройки, поэтому карту своего обмена сверяют с действующей конфигурацией.
Документация: 1С-Битрикс: состав XML-файлов и зависимости пакетного обмена;
2. Назначьте эталонный источник для каждого поля
Если одно поле свободно меняют и в магазине, и в учётной системе, следующий обмен может отменить работу сотрудника. Вместо общего правила «1С главная» распределите ответственность по данным. Например, учётная система ведёт цену и остаток, а редактор сайта — описание и фотографии.
Ниже учебная карта для товара S18-K2: шуруповёрт в комплекте с двумя аккумуляторами. Значения и правила условные. Идентификатор должен быть устойчивым и общим для обеих систем; название товара не подходит как единственный ключ сопоставления.
| Данные | Эталон и направление | Пример | Правило изменения |
|---|---|---|---|
| Предложение | Учётная система → сайт | S18-K2; комплект 2 АКБ | Сопоставление по внешнему ID, не по названию |
| Розничная цена | Учётная система → сайт | 240.00 BYN; тип Retail | Передавать сумму, валюту и тип цены; не заменять оптовой |
| Доступность склада | Учётная система → сайт | Склад M1; доступно 5 шт. | Единица измерения и состав доступного остатка согласованы |
| Описание и фото | Редактор сайта | Комплектация и фотографии S18-K2 | Обмен не перезаписывает редакционные поля |
| Заказ | Сайт → учётная система | WEB-1042; S18-K2 × 1 | Сохранить связь внешнего и внутреннего номера |
| Резерв и отгрузка | Учётная система → сайт | WEB-1042: резерв подтверждён | Статус меняет назначенная система по разрешённым переходам |
| Оплата | Платёжный источник → система учёта → сайт | WEB-1042: подтверждена | Маршрут примерный; один владелец статуса, сверка по ID операции |
Если таблица не помещается на экране, прокрутите её по горизонтали.
Отдельно согласуйте поведение пустого поля, нулевой цены, исчезнувшего товара и снятого с продажи предложения. Отсутствие строки в частичной выгрузке не равно команде удалить товар. Правило полного снимка и правило пакета изменений должны различаться, иначе неполная отправка может массово скрыть ассортимент.
3. Не выдавайте физический остаток за доступный к продаже
Товар на складе может быть занят заказом, повреждён или отложен как страховой запас. В разных системах определения отличаются. Например, Shopify явно разделяет физическое наличие, доступность, обязательства по заказам и недоступные единицы. Этот источник иллюстрирует различие состояний, а не задаёт формулу для вашего магазина.
В учебной модели ниже на одном складе физически 10 единиц. Три зарезервированы, одна недоступна из-за повреждения, одна удерживается как страховой запас. Категории не пересекаются: доступно 10 − 3 − 1 − 1 = 5. Если ваша учётная система уже отдаёт готовое доступное количество 5, вычитать резерв ещё раз нельзя.
| Состояние | Количество | Как используется |
|---|---|---|
| Физически на складе | 10 | Общее количество, ещё не обещание покупателю |
| Резерв заказов | 3 | Исключён из свободной продажи |
| Повреждено | 1 | Не продаётся |
| Страховой запас | 1 | В этой модели исключён отдельно, не входит в предыдущие строки |
| Доступно к новому заказу | 5 | Итог для продажи: 10 − 3 − 1 − 1 |
Если таблица не помещается на экране, прокрутите её по горизонтали.
При нескольких складах нельзя просто сложить все остатки и обещать единый срок доставки. Товар может быть недоступен для конкретного региона или способа получения. Укажите, какие склады участвуют в интернет-продажах, кто выбирает склад исполнения и когда резерв снимается при отмене или истечении ожидания оплаты.
Документация: Shopify: физический, доступный и зарезервированный остаток;
4. Контролируйте применение данных, а не только передачу
Успешный сетевой ответ подтверждает только конкретный этап протокола. Для бизнеса важнее, что нужные строки обработаны и сайт показывает правильные значения. Фиксируйте идентификатор пакета, время формирования, число переданных, применённых и отклонённых записей, а также последнюю успешную сверку.
В пакетном обмене сначала должны появиться объекты, на которые ссылаются следующие записи: предложение нельзя корректно связать с неизвестным товаром. Такой порядок зависимостей описан в документации 1С-Битрикс. Готовые алгоритмы обмена также нужно сопоставлять с версиями системы и модуля, не предполагая одинаковое поведение всех установок.
- ИсточникСнимок данных, время и версия
- ПередачаID пакета и подтверждение получения
- ПроверкаТовары, типы цен, склады и зависимости
- ПрименениеСчётчики обработанных и отклонённых строк
- Сверка витриныКарточка, корзина и уведомление об отклонениях
Получение пакета не равно успешному применению каждой строки.
Документация: 1С-Битрикс: состав XML-файлов и зависимости пакетного обмена; 1С-Битрикс: алгоритмы взаимодействия учётной системы с сайтом;
5. Опишите задержки, конфликты и безопасный повтор
Частота обмена — не гарантия свежести. Процесс мог запускаться регулярно, но не завершаться. Измеряйте возраст последнего успешно применённого изменения, а порог тревоги согласуйте с тем, как быстро продаются товары и насколько допустима задержка. Универсального безопасного интервала для всех магазинов нет.
Поздно пришедший старый пакет не должен бесконтрольно заменять новое значение. Если протокол предоставляет версии, используйте их; иначе нужна согласованная последовательность обработки и сверка. В Shopify пример защиты массового импорта — сравнение ожидаемого предыдущего остатка с текущим: конфликтующая строка не перезаписывается молча. Это пример подхода, не обещание такой функции в любом модуле.
Повтор одного пакета должен распознаваться как повтор той же операции. Для абсолютного значения «остаток 5» и команды «уменьшить на 1» риски различаются: повтор второй команды способен списать лишнее. После тайм-аута сначала выясняют, была ли операция применена, и только затем повторяют её по правилам протокола.
| Ситуация | Что делает система | Что видит ответственный |
|---|---|---|
| Пакет доставлен повторно | Узнаёт ID; не применяет повторно уже выполненные изменения | Запись о повторе и ссылка на исходный результат |
| Пришла старая версия | Не перезаписывает новое значение без проверки порядка | ID товара, обе версии и причина отклонения |
| Неизвестный тип цены | Отклоняет эту строку, не подставляет другой тип автоматически | Название типа и список затронутых предложений |
| Ошибка части пакета | Сохраняет построчный результат; повторяет только по безопасному правилу | Сколько применено, сколько отклонено, что исправить |
| Обмен долго не завершён | Поднимает уведомление; применяет заранее согласованный режим витрины | Время последнего успеха и ответственный за восстановление |
Если таблица не помещается на экране, прокрутите её по горизонтали.
Режим витрины при сбое — решение бизнеса. Возможны сохранение последнего значения с дополнительной проверкой заказа, временное отключение покупки проблемных позиций или запрос подтверждения наличия. Не заменяйте неизвестный остаток нулём или бесконечным наличием без согласованного правила: оба варианта могут навредить.
Документация: Shopify: проверка конфликтов при массовом импорте остатков;
6. Принимайте обмен по сценариям и журналу
Проверки ниже выполняют на тестовом наборе, а не на всём рабочем каталоге. Это постановки испытаний; ожидаемые результаты не означают, что они уже получены. Для каждого теста сохраняют ID пакета, исходное значение, фактический результат и журнал обработки. Сценарий «Повтор» выполняют отдельно для уже применённого пакета цен и отдельно для пакета создания учебного заказа WEB-1042: проверка цены сама по себе не доказывает отсутствие дублей заказов.
| Проверка | Учебное действие | Ожидаемый результат |
|---|---|---|
| Цена | Изменить Retail для S18-K2 с 240 на 250 BYN | 250 BYN в базе и витрине; оптовая цена не изменена |
| Резерв | Из доступных 5 единиц зарезервировать 1 | Доступно 4, резерв не вычтен дважды |
| Повтор | Отправить тот же пакет ещё раз | Состояние не меняется повторно; нет дубликата заказа |
| Неверный справочник | Передать неизвестный склад X9 | Строка не привязана к случайному складу; ошибка видна |
| Задержка | Задержать старый пакет, применить новый, затем доставить старый | Новое значение не затёрто без проверки конфликта |
| Кеш | Изменить цену и проверить карточку после обработки | Витрина и корзина соответствуют принятому значению |
| Показатель | Значение | Решение |
|---|---|---|
| Пакет | DEMO-042, 10:00 | Использовать ID при повторе и поиске журнала |
| Строки цен | 100 передано; 98 применено; 2 отклонено | Не считать весь обмен полностью успешным |
| Причина отказа | Два предложения с неизвестным типом цены | Исправить справочник и повторить безопасным способом |
| Проверка витрины | Запланирована выборка пяти изменённых позиций | Записать фактические цены и дату; пока не подтверждено |
| Ответственный | Администратор обмена; владелец цен — менеджер каталога | Технический и смысловой результат проверяют разные роли |
Если таблица не помещается на экране, прокрутите её по горизонтали.
До запуска договоритесь, кто реагирует на уведомление, как долго хранится журнал и как восстановить предыдущие данные при ошибочном массовом обновлении. Доступы к обмену держат отдельно от публичных файлов; в диагностический отчёт не включают пароли и лишние данные покупателей. Цель — обнаруживать и исправлять расхождения управляемо, а не обещать их полное отсутствие.
Частые вопросы
Достаточно ли запускать обмен чаще?
Нет. Частый запуск не устраняет неверное сопоставление полей, конкурирующие изменения или отклонённые строки. Сначала проверьте причину расхождения и возраст последнего успешно применённого обновления.
Можно ли исправить цену вручную на сайте?
Только по согласованному правилу владения полем. Если эталон — учётная система, следующая выгрузка может перезаписать ручную правку. Для исключений нужен отдельный механизм, срок действия и запись причины.
Почему полный обмен не решает проблему навсегда?
Он может временно выровнять данные, но не исправит логику резервов, неправильные типы цен или ошибки порядка пакетов. Массовое обновление также способно затронуть редакционные поля и доступность товаров.
Какие данные нужны для диагностики?
Внешний ID предложения, склад, тип цены, время расхождения, ожидаемое и фактическое значение, ID пакета и обезличенный журнал. Доступы передаются безопасным способом, не внутри скриншотов или отчёта.
Источники и документация
Материал подготовлен для владельцев бизнеса на основе официальной документации. Примеры и планы работ в тексте — учебные: состав решений зависит от конкретного сайта.
Если нужна помощь с описанной задачей, посмотрите состав услуги Интеграция сайта с учётной системой. Объём работ, сроки и стоимость согласуются после изучения вашего проекта.
