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