Интеграция ocStore с 1С УНФ 2026: как связать каталог, остатки и заказы без дублей

Интеграция ocStore с 1С УНФ нужна не ради красивой кнопки "обмен с сайтом", а ради конкретной операционной задачи: товар завели в 1С, цена и остаток ушли на витрину, заказ из ocStore попал в УНФ, а статус отгрузки не потерялся между менеджером и складом.

В 2026 году эту задачу нельзя честно описывать как "поставьте модуль за 15 минут". ocStore построен на OpenCart, а OpenCart и 1С УНФ имеют разные модели данных: в 1С главный объект - номенклатура, характеристика, склад и документ; в ocStore - товар, опция, заказ, статус и модификаторы магазина. Поэтому сначала проверяем совместимость обмена, ключи сопоставления, версии и журналы, и только потом включаем автоматическую синхронизацию.

Ключевые факты

• ocStore официально описывает себя как OpenCart-based дистрибутив с собственной локализацией и экосистемой модулей, поэтому интеграция почти всегда зависит от конкретной версии ocStore/OpenCart, установленных OCMOD/VQMOD-модификаторов и темы.
• Протокол "Обмен с сайтом" в 1С работает по HTTP и CommerceML 2: 1С инициирует сеанс, запрашивает параметры сайта, передает XML-файлы каталога/предложений и отдельно обменивается заказами.
• Типовой обмен 1С покрывает товары, цены, остатки и заказы, но не гарантирует корректную карту опций ocStore, нескольких складов, нестандартных скидок, доставок и пользовательских полей заказа без проверки.
• В 1С УНФ с версии 3.0.12 старый механизм "Обмен с сайтом" заменяется на обновленный раздел "Интернет-магазин"; при аудите надо смотреть не только версию платформы, но и какой механизм реально открыт в базе.
• OpenCart API требует включенного API-пользователя и добавления разрешенного IP-адреса. Если интеграция идет не через чистый CommerceML-модуль, это становится отдельной точкой диагностики.
• В нашей практике безопасный запуск начинается с тестового набора: 20-50 товаров, 10 контрольных SKU по остаткам, 3-5 заказов с разными оплатами/доставками и повторный прогон без создания дублей.

Что реально синхронизировать между ocStore и УНФ

Практическая диагностика перед интеграцией

В нашей практике обмен ocStore + 1С УНФ чаще ломается не на "неверном пароле", а на несовпадении модели каталога. На демо один товар без опций проходит нормально, а на боевом магазине появляются разные размеры, несколько складов, скидки, купоны, доставка СДЭК, частичная оплата и старые заказы с уже занятыми номерами.

Минимальный диагностический прогон:

1. Зафиксировать версии. Нужны версия ocStore/OpenCart, PHP, список модификаторов, установленный модуль обмена, версия 1С УНФ, версия платформы 1С и факт перехода на новый раздел "Интернет-магазин" в УНФ 3.0.12+.
2. Проверить endpoint обмена. Для CommerceML смотрим ответы checkauth, init, file, import и query/orders. Для API-сценария проверяем API-пользователя OpenCart, ключ, разрешенный IP и права.
3. Проверить ключи товаров. Сравниваем Ид из CommerceML, артикул, SKU/model в ocStore и внутренний product_id. Главный ключ должен переживать переименование товара.
4. Сверить 10 SKU. Для каждого SKU фиксируем остаток в УНФ, остаток в файле обмена или ответе API, остаток в карточке ocStore после импорта и время последней успешной синхронизации.
5. Прогнать реальные заказы. Нужны заказ с одной позицией, заказ с опцией, заказ со скидкой, заказ с доставкой, отмененный заказ и заказ с изменением статуса.
6. Проверить повторный запуск. Второй прогон того же файла или того же заказа должен обновить существующие объекты, а не создать новые товары, клиентов или документы.
7. Включить журнал без секретов. В логе должны быть объект, направление, время, HTTP-код, короткий ответ, действие повтора и ответственный. Пароли, токены и cookie в лог не пишутся.

Такой аудит обычно быстрее, чем восстановление каталога после неудачного импорта. В одном из проектов проблема выглядела как "1С не выгружает остатки", а фактически ocStore принимал offers.xml, но модуль сопоставлял характеристики по названию опции, которое отличалось от характеристики УНФ на один пробел.

Риски и диагностика

Как проходит подключение через Синхрон1С

Шаг 1. Диагностика. Вы присылаете версию ocStore/OpenCart, ссылку на магазин, версию УНФ, список модулей обмена, пример 20-50 товаров и 3-5 тестовых заказов. Доступы передаются отдельно, не в тексте заявки.

Шаг 2. Карта обмена. Фиксируем, какая система главная для товаров, цен, остатков, заказов, оплат и статусов. Отдельно описываем ключи сопоставления, правила дублей, склады, опции и действия при ошибках.

Шаг 3. Тестовый прогон. Запускаем обмен на тестовом наборе, сверяем контрольные SKU, повторяем импорт, проверяем создание и изменение заказов. Если модуль CommerceML не закрывает задачу, проектируем API/промежуточный слой.

Шаг 4. Запуск и мониторинг. Включаем расписание: для остатков обычно 15-60 минут, для заказов чаще, если позволяет контур. Добавляем журнал, повторные попытки и Telegram-уведомления по ошибкам.

Синхрон1С полезен не тем, что "магически соединяет всё", а тем, что делает обмен управляемым: ключи, журнал, повторы, уведомления и понятная диагностика по каждому товару или заказу.

Когда достаточно готового модуля

Готовый CommerceML-модуль для OpenCart/ocStore может быть нормальным решением, если каталог простой: один магазин, один основной склад, типовые цены, без сложных опций, без доработанных документов УНФ и без нескольких источников остатков. Но даже в этом случае нужно проверить совместимость с вашей версией ocStore, PHP и установленными модификаторами.

Внешний слой Синхрон1С имеет смысл, если есть несколько складов, разные типы цен, нестандартные статусы, кастомные поля заказа, доработанная УНФ, необходимость Telegram-уведомлений или требование не терять заказы при временной недоступности 1С/сайта.

Что подготовить перед заявкой

Часто задаваемые вопросы

Можно ли подключить ocStore к 1С УНФ без программиста?

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

CommerceML лучше, чем OpenCart API?

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

Почему нельзя просто выгрузить все товары из 1С в ocStore?

Можно, но без карты сопоставления это риск дублей. Если старый каталог уже создан вручную, сначала нужно понять, по чему связывать объекты: Ид CommerceML, артикул, model/SKU или отдельная таблица соответствий.

Что делать, если в УНФ уже новый раздел "Интернет-магазин", а инструкция модуля пишет про "Обмен с сайтом"?

Проверить версию УНФ и фактический механизм в базе. Начиная с УНФ 3.0.12 старый механизм заменяется обновленным "Интернет-магазином", поэтому старые инструкции могут не совпадать с интерфейсом и поведением обмена.

Как часто обновлять остатки?

Для небольшого каталога обычно начинают с 15-60 минут и отдельно смотрят нагрузку на 1С, сайт и размер XML. Для заказов можно делать чаще, но важнее не частота, а гарантия повторной обработки при сбое.

Сколько стоит интеграция через Синхрон1С?

Базовая диагностика и настройка обмена ocStore + 1С УНФ - 30 000 ₽ за проект. Если нужен постоянный мониторинг, журнал ошибок и Telegram-уведомления, поддержку обсуждаем отдельно после диагностики.

Смотрите также

• Интеграция 1С и Тильда: выгрузка товаров
• Экспорт остатков из 1С в Озон
• Выгрузка из 1С в Wildberries
• Экспорт номенклатуры из 1С
• 1С УТ или УНФ: сравнение конфигураций
• Сколько стоит интеграция 1С

Заказать интеграцию ocStore и 1С УНФ

Если у вас типовой магазин, начните с диагностики готового CommerceML-модуля. Если нужна управляемая интеграция с журналом, защитой от дублей, повторными попытками и Telegram-уведомлениями, напишите в Telegram: @onoutnoxon или в бот @sync1cbot.

Пришлите версии ocStore и УНФ, список сущностей для обмена и несколько тестовых заказов. Я верну короткий план: какой способ интеграции выбрать, какие риски закрыть до запуска и где возможны дубли или расхождение остатков.

Источники:

• 1С: протокол обмена с сайтом, HTTP-сценарий checkauth/init/file/import, CommerceML и обмен заказами - https://v8.1c.ru/tekhnologii/obmen-dannymi-i-integratsiya/standarty-i-formaty/protokol-obmena-s-saytom/
• 1С: стандарт CommerceML 2, XML-схема для каталогов, коммерческих предложений и торговых документов - https://v8.1c.ru/tekhnologii/obmen-dannymi-i-integratsiya/standarty-i-formaty/standarty-commerceml/commerceml-2/
• 1С:УНФ, новость о замене старого "Обмена с сайтом" на раздел "Интернет-магазин" начиная с версии 3.0.12 - https://torg.1c.ru/news/novoe-v-1s-unf-avtomaticheskaya-zamena-prezhnego-obmena-s-saytom-na-novyy/
• Scloud: настройка интеграции 1С:УНФ с сайтом, CommerceML 2.05+, обмен заказами, товарами, остатками, оплатами и отгрузками - https://scloud.ru/ask_question/obmen-s-saytom/nastroyka-integratsii-1s-unf-s-saytom-dlya-versii-1-6-27-kh-i-novee/
• ocStore: официальный сайт дистрибутива на базе OpenCart, локализация, экосистема модулей и демо ocStore 3.0.3.7 - https://ocstore.com/
• OpenCart Documentation: включение API-пользователя, генерация ключа и список разрешенных IP-адресов - https://docs.opencart.com/en-gb/system/users/api/
• OpenCart Documentation: заказы, статусы заказов и ручное управление статусами в админке - https://docs.opencart.com/admin-interface/sales/orders

Для статьи использован AI-ассистент для черновой структуризации и проверки полноты. Факты о CommerceML, протоколе обмена с сайтом, изменении механизма УНФ 3.0.12, API OpenCart и статусах заказов перепроверены по источникам 2026-05-04. Практический диагностический блок, риск-таблица и рекомендации по Синхрон1С основаны на внедренческом опыте habab.ru/Noxon; финальную редактуру выполнил Александр Руин.