Выбирайте способ обмена на конкретной операции
Оставляйте CommerceML для операций, которые текущая связка 1С и сайта выполняет корректно. Проверяйте OData, если нужен доступ к отдельным объектам базы. Проектируйте собственный HTTP API, если внешней системе требуется действие с особыми правилами. Смешанный обмен тоже возможен: например, каталог остаётся в штатной выгрузке, а новая операция получает свой сервис.
Начните с воспроизводимого примера. Допустим, магазин загружает заказы, но сотрудник вручную обрабатывает отмену после частичной отгрузки. Мы сначала проверяем настройку обмена, версии модулей и сам порядок отмены в 1С. Если нужное действие действительно отсутствует, сравниваем доработку текущего механизма с отдельным API. Так у первого этапа появляется понятная граница.
Как выглядит сквозной обмен в нашей работе
В магазине «Бакаев» мы связали приложение, админ-панель и 1С через сервер синхронизации. Сотрудник заменяет фотографию в панели, и она обновляется в 1С. Покупатель оформляет заказ в приложении, и остаток уменьшается в панели и учётной системе. Изменения из 1С проходят обратный путь к приложению.
Этот путь удобно разложить на отдельные операции: заменить изображение, передать заказ, отразить изменение остатка. Для каждой мы выясняем, кто меняет данные и где сотрудник проверит результат. Такой разбор помогает увидеть, какую часть существующего обмена нужно расширить в вашем проекте.
Реальный проект 13FOX
«Бакаев»: товары в связанной системе
Мы помогли перенести локальную 1С в облако и настроили двусторонний API-обмен с админ-панелью магазина.
Что сравнивают под названиями CommerceML и API
CommerceML задаёт структуру коммерческих данных в XML: какие сведения о товарах и документах передавать. Штатный протокол обмена 1С с сайтом описывает и передачу файлов по HTTP, и обратный путь заказов со статусами. Поэтому сам факт наличия XML ещё не объясняет, почему операция не проходит.
API описывает доступные запросы между программами. Варианты API различаются: стандартный интерфейс 1С использует OData 3.0 и открывает объекты базы через HTTP. Собственный HTTP-сервис позволяет разработчику задать обработчик запроса, его входные данные и ответ. REST описывает подход к устройству интерфейса; один этот термин не показывает набор ваших операций.
Например, для чтения карточки товара может подойти опубликованный объект OData. Для команды «подтвердить заказ по договору клиента» нужно определить проверку цены, наличия и допустимого состояния заказа. Мы проверяем, можно ли выполнить её через существующие объекты и правила базы или потребуется свой обработчик.
Матрица операций: что проверить в вашей базе
Сравните способы на одном товаре и заказе из тестовой копии. В таблице ниже указаны возможности механизмов и вопросы к реализации. Поддержку каждого поля, действия и направления подтверждаем на установленной конфигурации и модуле сайта.
| Операция | CommerceML | OData | Свой HTTP API |
|---|---|---|---|
| Каталог и варианты товара | Пакет каталога. Сверить характеристики, единицы и постоянные ID в обоих модулях. | Чтение опубликованных справочников. Сайт должен понимать связи объектов конфигурации. | Согласованный состав карточки и вариантов. Преобразования данных нужно разработать. |
| Цены и остатки по складам | Протокол предусматривает цены и остатки. Проверить отбор складов и смысл доступного количества. | Данные регистров и доступные методы остатков. Состав и расчёт зависят от базы. | Можно задать ответ для конкретного покупателя и склада. Правило доступности согласуют отдельно. |
| Создание заказа с сайта | Обратный обмен заказами предусмотрен. Проверить сопоставление клиента, состава и номера. | Создание документа при наличии объекта и прав. Его реквизиты и проверки нужно изучить. | Команда создания заказа с согласованными проверками и ответом. Обработчик пишут под процесс. |
| Проведение документа | Порядок обработки загруженного заказа определяет прикладной модуль 1С. | Есть методы проведения и отмены проведения. Проверить права и результат в учёте. | Можно включить проведение в обработчик. Условия выполнения и ошибки нужно задать. |
| Отмена, частичная отгрузка, резерв | Проверить конкретные статусы и действия модулей; их состав может не покрыть ваш процесс. | Доступ к данным и методам объектов ещё требует проверки всей цепочки действий. | Собственная команда может собрать нужную цепочку. Конкурирующие изменения проверяют отдельно. |
| Фотография из панели в 1С | Проверить обратное направление и обработку изображения в выбранной связке. | Проверить способ хранения изображения и возможность доступа к нему в этой базе. | Можно согласовать отдельную загрузку и связь с товаром. Хранение и ошибки входят в разработку. |
| Повтор и сверка после сбоя | Контролировать этап передачи файла и этап применения данных; сверять ID и результат. | При неизвестном результате запроса проверить объект до повторной записи. | Задать ключ операции, ответ на повтор и проверку результата. Сам HTTP этого не обеспечивает. |
Для CommerceML отправной точкой служат описанные 1С механизмы обмена. Для собственного API основа возможностей дана в документации HTTP-сервисов: ответ и логику формирует разработчик. По этой таблице мы проверяем функции вашей связки и фиксируем результат каждого испытания.
Версия платформы, конфигурации и модуля меняют решение
У названия «1С 8.3» слишком широкий смысл для выбора обмена. Платформа предоставляет технические механизмы, конфигурация задаёт товары и документы, а модуль обмена сопоставляет их с сайтом. Мы отдельно фиксируем все три версии, изменения конфигурации и расширения.
- CommerceML: 1С описывает штатный обмен для «Управления торговлей», «Комплексной автоматизации» и «Управления нашей фирмой». Это отправная точка проверки. Возьмите фактический XML и сверьте версию схемы, поля и обработку с модулем сайта. На странице стандарта доступна схема CommerceML 2.10; наличие этой схемы не подтверждает поддержку вашей установленной связкой.
- OData: по документации 1С:Фреш, механизм поддерживается с платформы 8.3.5. Затем проверяем веб-публикацию, состав открытых объектов, их метаданные и права служебного пользователя. Если сайт обращается к недоступному объекту, замена XML на JSON не решит проблему.
- Собственный HTTP-сервис: выясняем, можно ли добавить обработчик в вашей среде размещения, как его публиковать и сопровождать после обновлений. В управляемом облаке условия доработки и публикации проверяем у оператора сервиса.
В 1С:Фреш есть отдельное ограничение: OData-запрос с заголовком 1C_OData-DataLoadMode: true не поддерживается. Этот заголовок включает режим записи, аналогичный загрузке при обмене. Если старый механизм использует этот режим, перенос требует проверки обработчиков и результата записи.
Результатом обследования станет список доступных операций именно в вашей базе: что уже работает, что можно настроить и что потребует разработки. К нему прикладываем проверенный пример запроса или пакета и ожидаемое состояние товара либо заказа.
Запись документа и завершение бизнес-операции
OData позволяет создавать и изменять объекты, а для документов предусмотрено проведение. При этом 1С отдельно указывает исключение для проверки заполнения при чтении и записи через этот интерфейс. Поэтому после успешного запроса мы проверяем обязательные данные и результат операции в самой программе.
Допустим, сайт создал заказ с товарным составом. Сотруднику ещё нужны корректный договор, склад, цена, налоговые реквизиты и согласованное состояние документа. Какие проверки выполняет база, в какой момент они срабатывают и что произойдёт при отказе, выясняем на тестовом заказе. Проведённый документ тоже проверяем по его результату в учёте.
Собственный HTTP-сервис позволяет собрать эти действия в одну команду с понятным ответом сайту. Мы задаём входные поля, разрешённые состояния, границы одной транзакции в 1С и сообщение при отказе. Изменения сразу в нескольких системах требуют отдельного порядка восстановления: один успешный HTTP-ответ не подтверждает согласованность всей цепочки.
Пропавший ответ: как узнать, дошёл ли заказ
Представьте: 1С создала заказ, но сайт не получил ответ из-за обрыва связи. Ошибка на сайте означает, что результат неизвестен. Перед повтором нужно найти операцию или документ по постоянному идентификатору и проверить, какие действия уже выполнены. Новая безусловная отправка может создать дубль.
Для каждого канала мы согласуем журнал с ID операции, ID объекта в обеих системах, временем, этапом обработки и причиной отказа. Правило повторной отправки должно учитывать конкурентные запросы. Если применяется ключ повтора, отдельно определяем, что произойдёт при том же ключе с изменённым составом заказа и как долго хранится результат.
У CommerceML также нужно отличать принятие файла от применения его содержимого: протокол описывает эти этапы отдельно. Восстановление начинаем с последнего подтверждённого этапа и сверки данных. Для API проверяем значение HTTP-ответа: он подтверждает приём запроса или уже завершённую операцию.
Сотруднику нужен результат проверки: заказ найден в 1С и связан с номером сайта; обработка ещё идёт; либо требуется исправить конкретное поле. Технический журнал дополняем списком ошибок и ответственным за их разбор.
Как перейти на API по одному участку обмена
Полная замена нужна, когда проверка показывает, что текущий механизм не покрывает согласованный процесс и его доработка не подходит. Если пробел локальный, мы предлагаем перенос одной операции. Например, каталог остаётся в CommerceML, а проверка доступности с созданием резерва получает отдельную команду. Правила резерва, отмены и истечения срока проектируем для конкретной конфигурации.
- Зафиксировать текущую карту. Сохранить настройки, примеры пакетов и связи ID. Для цены, фото, остатка и статуса выбрать систему, в которой данные меняют.
- Проверить новый путь на копии. Выполнить обычную операцию, отказ и повтор. Для операции резерва проверить два конкурирующих заказа на последнюю единицу. Измерить задержку и нагрузку при согласованном объёме, сравнить результат со старым обменом.
- Разделить запись. Назначить один канал для каждой переносимой операции и поля. Во время сравнения новый канал может читать данные; две независимые записи одного заказа требуют специального согласованного механизма.
- Переключить выбранный участок. Остановить его старую запись, разобрать незавершённые пакеты и запросы, выполнить сверку, затем включить новую. Согласовать допустимый перерыв с сотрудниками.
- Проверить восстановление и возврат. Зафиксировать условие остановки нового канала и порядок возврата. Сначала сверить уже принятые изменения и сохранить связи ID; простое включение старого задания может повторно загрузить их.
Для обновлений 1С и сайта сохраняем контрольные примеры и повторяем затронутые проверки. Если новый API оставляет CommerceML для каталога, в документации указываем, какой канал отвечает за каждое поле. Это помогает сотруднику понять, где исправлять ошибку, а разработчику не перезаписать данные соседним обменом.
Что включить в карту и границы первого этапа
Для оценки перехода мы собираем паспорт недостающей операции. На первом обсуждении достаточно обезличенного примера и описания ожидаемого результата. Затем на обследовании проверяем техническую возможность и состав работ.
В смете разделяем обследование, настройки или доработку 1С, изменения сайта, сопоставление данных, журнал и восстановление, тестирование, переключение и сопровождение. Отдельно фиксируем, кто предоставляет тестовую базу и кто отвечает за обновления. Так можно сравнить варианты по одинаковому результату.
Мы обсуждаем проекты компаний из Москвы, Санкт-Петербурга и других регионов России удалённо. Для начала важны доступность ответственного за 1С и описание процесса. Общий состав работ по интеграции с 1С вынесен на страницу услуги; здесь основой оценки служит выбранная операция.
Вопросы перед выбором обмена
Нужно ли менять CommerceML ради двустороннего обмена?
Штатный протокол уже предусматривает передачу заказов с сайта в 1С и синхронизацию их параметров и статусов. Сначала проверьте, поддерживают ли ваши модули нужные поля и действия. Замена оправдана подтверждённым ограничением.
OData подходит только для чтения?
Стандартный интерфейс 1С позволяет создавать и изменять объекты; для документов предусмотрены проведение и отмена проведения. Возможность нужной операции проверяют по опубликованным объектам, правам и правилам конкретной базы.
API гарантирует обмен в реальном времени?
Задержку определяют способ запуска, нагрузка, обработка и доступность систем. API позволяет проектировать отдельные запросы; нужную скорость подтверждают измерением. Для заказа отдельно согласуют поведение при недоступности 1С.
Можно оставить CommerceML и добавить API?
Можно, если операции и поля закреплены за каналами, сохранены связи ID и есть общий порядок сверки. Начните с участка, которого не хватает текущему обмену, и проверьте переключение вместе с возвратом.
Документы для проверки своей связки
Технические возможности сверены 7 октября 2026 года по документации 1С: протокол обмена с сайтом, стандартный REST-интерфейс, HTTP-сервисы и OData в 1С:Фреш. Используйте их вместе с описанием установленной конфигурации и контрольным обменом на тестовой базе.
Если вы ещё определяете общий состав связи сайта и учёта, начните с руководства по интеграции интернет-магазина с 1С. Для модернизации уже работающего обмена заполните паспорт операции выше и выберите первый проверяемый участок.
Составим карту обмена и границы первого этапа
Укажите конфигурацию и версию 1С, связанные системы, одну сущность и пример ошибки. На первом обсуждении разложим нужное действие по системам и определим, что проверить в текущем обмене. Затем согласуем карту обмена и границы первого этапа для оценки работ.
Оставьте контакт в форме. Пример операции разберём при обратной связи; для начала достаточно обезличенных данных.