Почему обмен ломается не только в 1С
Интеграция - это договоренность между системами. 1С, сайт, CRM, маркетплейс или внешний сервис должны одинаково понимать товары, клиентов, заказы, оплаты, склады и статусы. Если одна сторона изменила структуру или правила, обмен начинает вести себя непредсказуемо.
Поэтому ошибка «в обмене» не всегда находится в модуле 1С. Иногда сайт передает заказ без внешнего идентификатора, CRM меняет статус раньше оплаты, а 1С выгружает остатки без учета резерва. Для пользователя результат один: цифры не сходятся.
Правильная диагностика смотрит весь маршрут данных, а не только кнопку «Выполнить обмен».
Откуда берутся дубли
Дубли появляются, когда система не может надежно понять, что объект уже существует. Например, товар сопоставляют по названию, а менеджер чуть изменил наименование. Клиента ищут по телефону, но телефон записан в другом формате. Заказ приходит без внешнего номера, и при повторной загрузке создается заново.
Особенно опасны ручные исправления. Пользователь видит дубль, удаляет или переименовывает его, но причина остается. Следующий обмен снова создает лишние элементы.
Для устойчивой интеграции нужны стабильные ключи сопоставления и понятные правила: что делать, если товар не найден, клиент изменил телефон, заказ уже загружен, а сумма оплаты отличается.
Что проверить при дублях:
- по какому полю сопоставляются товары, клиенты и заказы;
- сохраняется ли внешний идентификатор из сайта или CRM;
- есть ли ручные переименования после загрузки;
- как система ведет себя при повторной отправке того же заказа;
- есть ли разные правила для физических и юридических лиц.
Почему остатки не совпадают
Остатки кажутся простой цифрой, но в 1С за ней стоят склад, дата, резерв, характеристика, серия, единица измерения и состояние документов. Сайт часто хочет одну цифру «доступно к продаже», а учетная система хранит несколько разных представлений остатка.
Если не согласовать формулу, сайт может показывать товары, которые уже зарезервированы, или скрывать товары, которые физически есть на складе. То же относится к ценам: разные виды цен, скидки и условия клиента должны попадать в обмен осознанно.
Перед исправлением обмена нужно договориться, какую именно цифру бизнес считает правильной. Иначе технически обмен заработает, но пользователи продолжат спорить с результатом.
Карта диагностики обмена
- Описать, какие объекты передаются: товары, цены, остатки, заказы, оплаты, статусы, клиенты.
- Понять направление обмена для каждого объекта.
- Проверить ключи сопоставления и внешние идентификаторы.
- Собрать 3-5 примеров ошибок с номерами заказов или товаров.
- Проверить расписание обмена, права пользователя обмена и последние логи.
- Согласовать правила для дублей, отсутствующих товаров и конфликтов статусов.
- Протестировать исправления на копии или ограниченном наборе данных.
Таблица для быстрого решения
| Симптом | Вероятная причина |
|---|---|
| Дубли заказов | Нет стабильного внешнего ID или неправильно настроено сопоставление. |
| Неверные остатки | Не учтены резервы, склады, характеристики, дата остатка или единицы измерения. |
| Пропали оплаты | Разные статусы оплаты, ошибка прав доступа или фильтр выгрузки. |
| Статусы меняются хаотично | Нет единой схемы переходов между статусами сайта, CRM и 1С. |
Когда лучше не тянуть
Обращаться к специалисту стоит не тогда, когда все уже остановилось, а когда появились повторяющиеся симптомы: база давно не обновлялась, пользователи обходят проблему вручную, данные расходятся, один сотрудник хранит всю логику в голове или любое изменение вызывает страх сломать учет.
Нормальный первый шаг не обязывает начинать большой проект. Достаточно описать ситуацию, показать один-два примера и получить понятный маршрут: что проверить, где риск, какая работа действительно нужна.