Интеграция мобильного приложения с 1С: 4 способа обмена и как выбрать

Коротко. Интеграция мобильного приложения с 1С — это обмен данными между телефоном и базой: приложение забирает каталог, цены и остатки, а отправляет обратно заказы и статусы. Способов ровно четыре: HTTP-сервис, OData, план обмена и COM-соединение. Выбор зависит не от вкуса разработчика, а от объёма данных и от того, нужен ли офлайн. Ниже — механика каждого способа с кодом на встроенном языке, правило выбора под сценарий и то, что обычно ломается уже после запуска.

Что значит «интеграция мобильного приложения с 1С» на практике

Когда заказчик говорит «свяжите приложение с 1С», за этим почти всегда стоит один и тот же набор потоков данных. Из 1С в телефон уходят справочные и оперативные данные: каталог номенклатуры, цены по нужному типу, остатки по складам, список контрагентов, иногда дебиторка. Обратно, из телефона в 1С, идут документы и события: новый заказ покупателя, изменение статуса, отметка о доставке, фотография или подпись получателя.

Важное различие, которое упускают на старте: чтение и запись — это разные задачи с разной ценой ошибки. Если приложение показало устаревшую цену — неприятно, но поправимо следующей синхронизацией. Если приложение дважды записало один заказ — это уже деньги, склад и разбирательство с клиентом. Поэтому в нормальной интеграции мобильного приложения с 1С чтение и запись реализуют разными механизмами и с разными гарантиями: чтение можно повторять сколько угодно, запись — нельзя.

Второе различие — онлайн против офлайна. Приложение менеджера в офисе может ходить в базу по каждому нажатию. Приложение курьера или кладовщика — не может: связь пропадает в подвале, в лифте, за городом. Это меняет всю архитектуру обмена, а не только «добавляет кэш». Именно этот вопрос — а не выбор языка приложения — определяет, во что обойдётся проект.

Третье, о чём почти не говорят: у 1С нет одного «правильного» интерфейса наружу. Платформа даёт несколько механизмов, и они не взаимозаменяемы. Ошибка выбора на старте не видна месяцами — она проявляется, когда данных становится много или когда приложению впервые нужно работать без сети.

4 способа обмена — и чем они отличаются

Ниже — все четыре способа, которые реально применяются с 1С:Предприятие 8.3 для связи с мобильным приложением. Не «лучший» и «худший», а разные инструменты под разные задачи.

Способ	Кто пишет код	Объём данных	Когда уместен
HTTP-сервис	1С-разработчик	Любой — вы сами решаете, что отдавать	Основной выбор для мобильных приложений
OData	Почти никто — включается настройкой	Небольшой	Прототип, внутренние задачи, чтение справочников
План обмена	1С-разработчик	Большой, с историей изменений	Офлайн-приложения, много данных
COM-соединение	1С-разработчик	Любой	Практически никогда — см. ниже

HTTP-сервис в конфигураторе 1С (JSON)

Самый частый и самый управляемый способ. Вы создаёте в конфигураторе объект «HTTP-сервис», описываете шаблоны URL и методы, и пишете обработчики на встроенном языке. Приложение обращается к ним обычным HTTP-запросом и получает JSON — механизм штатный, он описан в документации платформы 1С по HTTP-сервисам.

Главное преимущество — вы полностью контролируете контракт. Отдаёте ровно те поля, которые нужны экрану приложения, в том виде, в котором ему удобно. Не «весь справочник номенклатуры со всеми реквизитами», а код, наименование, цена, остаток. Приложение не знает и не должно знать, как устроена ваша база: между ними стоит контракт, который вы написали сами и можете менять, не трогая учёт.

Второе преимущество — бизнес-логика остаётся в 1С, где ей и место. Проверка прав, доступных остатков, актуальной цены выполняется на сервере. Приложение не принимает решений, оно показывает и отправляет.

Обработчик метода, отдающего каталог, выглядит так:

Функция КаталогGET(Запрос)

	Ответ = Новый HTTPСервисОтвет(200);
	Ответ.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");

	ЗапросДанных = Новый Запрос;
	ЗапросДанных.Текст =
		"ВЫБРАТЬ
		|	Номенклатура.Код КАК Код,
		|	Номенклатура.Наименование КАК Наименование
		|ИЗ
		|	Справочник.Номенклатура КАК Номенклатура
		|ГДЕ
		|	НЕ Номенклатура.ПометкаУдаления
		|	И НЕ Номенклатура.ЭтоГруппа";

	Выборка = ЗапросДанных.Выполнить().Выбрать();

	Массив = Новый Массив;
	Пока Выборка.Следующий() Цикл
		Элемент = Новый Структура;
		Элемент.Вставить("code", Выборка.Код);
		Элемент.Вставить("name", Выборка.Наименование);
		Массив.Добавить(Элемент);
	КонецЦикла;

	ЗаписьJSON = Новый ЗаписьJSON;
	ЗаписьJSON.УстановитьСтроку();
	ЗаписатьJSON(ЗаписьJSON, Массив);

	Ответ.УстановитьТелоИзСтроки(ЗаписьJSON.Закрыть(), КодировкаТекста.UTF8);
	Возврат Ответ;

КонецФункции

Приём заказа — обратное направление. Здесь критично не просто «записать», а защититься от повторной записи. Обратите внимание на ключ идемпотентности: он превращает «отправить заказ» из опасной операции в безопасную.

Функция ЗаказPOST(Запрос)

	ЧтениеJSON = Новый ЧтениеJSON;
	ЧтениеJSON.УстановитьСтроку(Запрос.ПолучитьТелоКакСтроку());
	Данные = ПрочитатьJSON(ЧтениеJSON);

	// Идемпотентность: приложение присылает свой уникальный ключ.
	// Повторная отправка того же заказа не создаст второй документ.
	КлючКлиента = "";
	Если Данные.Свойство("client_id") Тогда
		КлючКлиента = Строка(Данные.client_id);
	КонецЕсли;

	Если ПустаяСтрока(КлючКлиента) Тогда
		Возврат Новый HTTPСервисОтвет(400);
	КонецЕсли;

	Существующий = НайтиЗаказПоКлючу(КлючКлиента);
	Если ЗначениеЗаполнено(Существующий) Тогда
		// Уже приняли раньше — отвечаем успехом, но НЕ создаём дубль
		Возврат ОтветСНомером(200, Существующий);
	КонецЕсли;

	Документ = Документы.ЗаказПокупателя.СоздатьДокумент();
	Документ.Дата = ТекущаяДатаСеанса();
	Документ.КлючКлиента = КлючКлиента;
	// ... заполнение табличной части из Данные

	Попытка
		Документ.Записать(РежимЗаписиДокумента.Проведение);
	Исключение
		ЗаписьЖурналаРегистрации("МобильныйОбмен", УровеньЖурналаРегистрации.Ошибка,,,
			ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()));
		Возврат Новый HTTPСервисОтвет(500);
	КонецПопытки;

	Возврат ОтветСНомером(200, Документ.Ссылка);

КонецФункции

Реквизит КлючКлиента — это не украшение. Это то, что отличает работающую интеграцию приложения с 1С от той, которая раз в месяц создаёт задвоенный заказ. Подробнее — в разделе про офлайн.

Отдельный вопрос, который решается здесь же, — авторизация. У HTTP-сервиса есть штатная аутентификация средствами 1С: запрос приходит от конкретного пользователя базы, и все ограничения прав работают как обычно. На практике для мобильного приложения делают так: заводят отдельного пользователя 1С под обмен, дают ему права только на нужные методы, и уже внутри обработчика определяют, от имени какого реального сотрудника или контрагента пришёл запрос — по токену, который приложение получило при входе.

Функция ПользовательПоТокену(Запрос)

	Токен = Запрос.Заголовки.Получить("X-Auth-Token");
	Если Токен = Неопределено ИЛИ ПустаяСтрока(Токен) Тогда
		Возврат Неопределено;
	КонецЕсли;

	ЗапросДанных = Новый Запрос;
	ЗапросДанных.Текст =
		"ВЫБРАТЬ ПЕРВЫЕ 1
		|	Сессии.Пользователь КАК Пользователь
		|ИЗ
		|	РегистрСведений.СессииПриложения КАК Сессии
		|ГДЕ
		|	Сессии.Токен = &Токен
		|	И Сессии.ДействуетДо > &Сейчас";
	ЗапросДанных.УстановитьПараметр("Токен", Токен);
	ЗапросДанных.УстановитьПараметр("Сейчас", ТекущаяУниверсальнаяДата());

	Выборка = ЗапросДанных.Выполнить().Выбрать();
	Возврат ?(Выборка.Следующий(), Выборка.Пользователь, Неопределено);

КонецФункции

Два правила, которые экономят инцидент: токен проверяется в каждом методе, а не только при входе, и у токена есть срок жизни. Приложение, установленное на телефон уволившегося сотрудника, не должно ходить в базу вечно.

OData — обмен без написания кода

1С умеет автоматически публиковать свои объекты через REST-интерфейс по стандарту OData. Включается это в конфигураторе (состав интерфейса) и в настройках публикации на веб-сервере — писать обработчики не нужно вообще.

Запрос к справочнику выглядит так:

GET /base/odata/standard.odata/Catalog_Номенклатура?$format=json&$top=50

Звучит идеально — и в этом ловушка. У OData три ограничения, из-за которых он редко доживает до продакшена в мобильных проектах:

• ✓Он отдаёт структуру вашей базы наружу. Имена реквизитов, состав справочников, внутренние поля. Приложение оказывается жёстко привязано к тому, как устроена конфигурация — любая доработка учёта ломает приложение, которое уже стоит у пользователей и обновляется через сторы неделями.
• ✓Он отдаёт слишком много. Фильтровать и выбирать поля можно, но вы всё равно тянете объект, а не то, что нужно экрану. На мобильном интернете разница между «сто байт» и «десять килобайт» на каждую позицию заметна.
• ✓Бизнес-логика остаётся снаружи. Записать заказ через OData технически можно, но вся проверка — остатки, цены, права — оказывается на стороне приложения. Это неправильно архитектурно и опасно с точки зрения безопасности: клиент никогда не должен быть источником истины о том, что ему можно.

Честный вывод: OData хорош, чтобы быстро проверить гипотезу или закрыть внутреннюю задачу на чтение. Как фундамент мобильного приложения для внешних пользователей — плохой выбор, и заменять его потом придётся вместе с половиной приложения.

План обмена — когда данных много

План обмена — штатный механизм 1С для обмена с другими системами. Его суть в одном: 1С сама регистрирует изменения. Вы не спрашиваете «дай всё», вы спрашиваете «дай то, что изменилось с прошлого раза». Для приложения, которое синхронизирует тысячи позиций по мобильной сети, это разница между пятью секундами и пятью минутами.

// Отдаём только изменённое для конкретного узла (устройства)
Функция ИзмененияДляУзла(УзелОбмена)

	Выборка = ПланыОбмена.ВыбратьИзменения(УзелОбмена, Неопределено);
	Массив = Новый Массив;

	Пока Выборка.Следующий() Цикл
		Данные = Выборка.Получить();
		Массив.Добавить(ПредставлениеДляМобильного(Данные));
	КонецЦикла;

	Возврат Массив;

КонецФункции

// Подтверждение приёма — только ПОСЛЕ того, как устройство ответило "принял"
Процедура ПодтвердитьПриём(УзелОбмена, НомерСообщения)
	ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбмена, НомерСообщения);
КонецПроцедуры

Ключевая деталь — регистрацию изменений снимают только после подтверждения от устройства, а не после отправки. Иначе пакет, потерянный в дороге, потеряется навсегда: 1С уже считает, что отдала его. Это ровно та ошибка, которая проявляется не на тесте, а через месяц эксплуатации, когда у одного пользователя «пропала часть номенклатуры».

Плата за механизм — сложность проектирования. Нужно решить: какие объекты входят в состав плана обмена, что считать узлом (устройство или пользователь), что делать с узлами, которые не выходили на связь полгода и накопили огромную очередь изменений. Для приложения на десяток экранов это избыточно. Для офлайн-приложения склада с тысячами позиций — это единственный способ не тянуть весь справочник при каждом запуске.

Жизненный цикл узла — та часть, которую забывают спроектировать, и она мстит через год. Устройство потеряли, сотрудник уволился, телефон перепрошили — узел остался, и 1С продолжает копить для него изменения. На базе с активной номенклатурой десяток забытых узлов превращается в миллионы записей регистрации, которые никто никогда не заберёт. Поэтому в связке мобильного приложения и 1С узлу нужны как минимум два атрибута: дата последней синхронизации и флаг активности — плюс регламентное задание, которое отключает узлы, молчащие дольше разумного срока.

Второй вопрос — что считать узлом. Если узел = пользователь, то смена телефона проходит бесшовно, но два устройства одного человека начнут воевать за одну очередь. Если узел = устройство, очереди независимы, но при замене телефона сотруднику придётся выкачивать всё заново. Правильного ответа нет — есть выбор, который надо сделать осознанно и записать, а не обнаружить случайно на третьем месяце эксплуатации.

COM-соединение — почему в 2026 не стоит

Исторически внешние системы подключались к 1С через COM. Технически это работает и сегодня. Практически для мобильного приложения — нет, и вот почему честно:

• ✓Только Windows. COM привязывает вас к конкретной платформе сервера и закрывает путь на Linux.
• ✓Это не веб. Телефон не может обратиться к COM напрямую — всё равно нужен промежуточный сервис. Вы получаете лишнее звено, которое само может упасть, и которое надо отдельно писать, разворачивать и мониторить.
• ✓Тяжёлое подключение. COM-соединение занимает лицензию и ресурсы, плохо переживает параллельные обращения. Десять курьеров, синхронизирующихся одновременно, — уже проблема.

Если в проекте предлагают COM ради мобильного приложения — это почти всегда значит, что решение переносят из старой десктопной интеграции, не пересматривая. Способ упомянут здесь для полноты: чтобы вы могли уверенно от него отказаться и объяснить почему. Если задача внутренняя и сотрудники работают в периметре компании, посмотрите в сторону разработки на 1С:Мобильной платформе — там обмен штатный.

Какой способ выбрать под ваш сценарий

Это тот раздел, которого обычно не хватает: методы перечислены, а правила выбора нет. Правило простое и строится на двух вопросах: нужен ли офлайн и какой объём данных. Всё остальное — следствие.

Сценарий	Офлайн	Объём	Способ
Приложение интернет-магазина (каталог, корзина, заказ)	Не нужен	Средний	HTTP-сервис
B2B-приложение для дилеров (свои цены, дебиторка)	Желателен	Средний	HTTP-сервис + локальный кэш
Приложение кладовщика (сканирование, приёмка)	Обязателен	Большой	План обмена
Приложение курьера (маршрут, статусы, оплата)	Обязателен	Небольшой	HTTP-сервис + очередь отправки
Приложение руководителя (отчёты, показатели)	Не нужен	Небольшой	HTTP-сервис
Прототип «показать за неделю»	Не нужен	Любой	OData

Заметьте: HTTP-сервис стоит почти везде. Именно по этой схеме мы делаем интеграцию мобильного приложения с 1С под ключ. Это не лень — это следствие того, что он единственный даёт полный контроль над контрактом при разумной цене разработки. План обмена подключают тогда, когда офлайн перестаёт быть «желательным» и становится условием работы: кладовщик в холодильном складе без связи не может ждать сеть, он должен работать.

Отдельно про строку «курьер»: объём данных небольшой, но офлайн обязателен — и это как раз случай, когда полноценный план обмена избыточен, а вот очередь отправки с ключом идемпотентности обязательна. Разберём её ниже.

Офлайн-режим и конфликты синхронизации

Здесь ломается больше всего проектов, и почти ни одна статья про интеграцию мобильного приложения с 1С этого не разбирает.

Сценарий: кладовщик принял товар, связи не было. Приложение сохранило приёмку локально. Через час связь появилась — приложение отправляет накопленное. За этот час в 1С тот же документ уже поправил менеджер. Чья версия правильная?

Ответ «пусть решает 1С» — не ответ. Политику нужно определить заранее, до первой строчки кода, потому что она меняет структуру данных. Рабочих политик три:

• ✓Побеждает сервер. Локальные изменения отбрасываются, приложение перечитывает данные. Годится для справочных данных: цены, каталог, остатки. Пользователь не редактирует их — он их потребляет.
• ✓Побеждает устройство. Приложение перезаписывает данные в 1С. Годится там, где источник истины — телефон: факт доставки, результат инвентаризации, геопозиция. Менеджер в офисе физически не знает лучше курьера, доставлен заказ или нет.
• ✓Не перезаписываем, а добавляем. Вместо изменения документа приложение создаёт новый — отдельную приёмку, отдельный факт. Конфликта не возникает в принципе, а «текущее состояние» вычисляется как сумма фактов.

Третий вариант выглядит скучно, но на практике выигрывает чаще всего. Самый надёжный способ разрешить конфликт — спроектировать обмен так, чтобы конфликта не было. Это стоит держать в голове при проектировании: спор двух версий одного документа всегда дороже, чем два независимых документа.

Технически офлайн-отправка строится через очередь. Приложение не «отправляет заказ» — оно кладёт его в локальную очередь со статусом «ожидает». Отдельный процесс разгребает очередь, когда появляется связь. И вот тут вступает ключ идемпотентности:

// Схема на стороне 1С: приём с ключом идемпотентности
// Приложение генерирует client_id ОДИН раз, при создании записи,
// и повторяет его при каждой попытке отправки.
//
//  Попытка 1: связь пропала на середине.
//             Приложение НЕ знает, дошёл заказ или нет.
//  Попытка 2: тот же client_id → 1С находит существующий документ
//             → отвечает 200 и номером → дубля нет.

Функция НайтиЗаказПоКлючу(КлючКлиента)

	ЗапросДанных = Новый Запрос;
	ЗапросДанных.Текст =
		"ВЫБРАТЬ ПЕРВЫЕ 1
		|	ЗаказПокупателя.Ссылка КАК Ссылка
		|ИЗ
		|	Документ.ЗаказПокупателя КАК ЗаказПокупателя
		|ГДЕ
		|	ЗаказПокупателя.КлючКлиента = &КлючКлиента";
	ЗапросДанных.УстановитьПараметр("КлючКлиента", КлючКлиента);

	Выборка = ЗапросДанных.Выполнить().Выбрать();
	Возврат ?(Выборка.Следующий(), Выборка.Ссылка, Неопределено);

КонецФункции

Обратите внимание на важную деталь: приложение не знает, дошёл ли запрос. Обрыв связи после отправки, но до получения ответа — это не редкий случай, это норма мобильной сети. Без ключа идемпотентности у вас ровно два плохих выбора: повторить и получить дубль, или не повторять и потерять заказ. Ключ убирает эту дилемму целиком.

Реквизит КлючКлиента обязательно нужно проиндексировать — иначе на документе с историей в сотни тысяч записей этот поиск сам станет причиной таймаута, и вы получите новый класс отказов вместо старого.

Есть ещё одна часть офлайна, про которую вспоминают поздно: локальная база на устройстве тоже живёт и обновляется. Приложение вышло в сторы, у пользователей накопились данные — и тут выходит версия, где в заказе появилось новое поле. Локальную базу нужно мигрировать прямо на телефоне, у которого может не быть связи, и который может обновиться сразу через три версии. Отсюда правило: схема локальной базы меняется только аддитивно — поля добавляем, старые не переименовываем и не удаляем. Это ровно та же дисциплина, что и с контрактом обмена: то, что уже уехало к пользователю, вы больше не контролируете.

И последнее про очередь: у неё должен быть предел попыток. Запись, которую сервер отвергает как некорректную, будет ретраиться вечно, разряжая батарею и забивая лог. После нескольких неудач элемент очереди уходит в статус «ошибка» и показывается пользователю — молча терять его нельзя, но и долбить сервер бесконечно тоже.

Что ломается в проде

Список ниже — из нашей практики интеграций мобильных приложений с 1С. Это не теория: каждый пункт стоил времени на отладку.

1. HTTP 500 вместо понятной ошибки — из-за одной буквы в имени поля. Приложение слало поле mail, обработчик 1С ждал email. 1С не находила свойство и падала уже внутри обработчика — наружу уходил голый 500. Урок, который экономит часы отладки: 500 и 401 — разные диагнозы. 401 значит «не пустили» — ищите авторизацию. 500 значит «пустили, но сервер упал, обрабатывая ваш запрос» — то есть авторизация прошла, а проблема в теле запроса или в коде обработчика. Путать их — значит несколько часов чинить не то.

2. Таймаут на длинной операции. Обработчик, который отдаёт данные за секунду на тестовой базе, на боевой работает сорок. Клиент по умолчанию столько не ждёт. Лечится двумя вещами: явным таймаутом на стороне приложения (не полагаться на умолчание платформы) и переводом тяжёлых операций в фоновое задание с отдельной проверкой готовности — приложение спрашивает «готово?», а не висит в ожидании.

3. Дубли в ответе. Внешний сервис отдавал одну и ту же запись по четыре раза — потому что данные собирались запросом, который размножал строки соединением. Приложение честно показывало четыре одинаковых договора. Дедупликацию нужно делать на стороне приёма, даже если «источник же не должен такое присылать». Источник может и будет.

4. Границы дат уезжают на часовой пояс. Сервер отдавал даты в UTC, приложение считало их локальными. Документ от 23:30 первого числа попадал в предыдущий месяц. В отчётах это выглядит как «пропали заказы» — и ищут пропажу где угодно, только не в часовом поясе. Правило: на проводе — всегда UTC и явный формат, конверсия — только на краю системы, при показе пользователю.

5. Пакетный лимит. Метод, который прекрасно работает на десяти записях, отвечает ошибкой на ста двадцати. Лимиты есть почти всегда — либо на стороне 1С, либо на стороне промежуточного сервиса, либо на веб-сервере. Их нужно узнать до начала разработки, а не поймать на приёмке, когда архитектура уже написана под «отдаём всё одним запросом».

6. Разделитель групп в числах. Число, переданное как строка средствами 1С без явного формата, приезжает с пробелом внутри — «1 234». Принимающая сторона пытается разобрать это как число и падает. В 1С формат нужно задавать явно — это касается и чисел, и дат.

Общее у всех шести пунктов: ни один не проявляется на демо. Все они вылезают в проде, на реальных объёмах и реальной сети. Поэтому в интеграции приложения с 1С этап опытной эксплуатации — не формальность, а часть разработки.

Сколько занимает и от чего зависит срок

Честный ответ: срок определяется не количеством экранов, а тремя вещами.

• ✓Состоянием конфигурации. Типовая, не переписанная конфигурация — быстро. Конфигурация, которую дорабатывали десять лет разные подрядчики, — медленно, потому что сначала нужно понять, где на самом деле лежат данные и какая из трёх похожих табличных частей используется.
• ✓Нужен ли офлайн. Это не «плюс неделя». Офлайн меняет архитектуру: появляется локальная база на устройстве, очередь отправки, политика конфликтов, миграции этой локальной базы при обновлениях. Разница между онлайн- и офлайн-приложением измеряется не процентами.
• ✓Готовностью сервера. Публикация HTTP-сервисов наружу — это ещё и вопрос доступа, сертификата, защиты и нагрузки. Если через обмен пойдут персональные данные, добавляется 152-ФЗ «О персональных данных» — он влияет на то, где физически может стоять сервер. Если 1С сейчас живёт внутри локальной сети и никогда не смотрела в интернет, часть срока уйдёт на инфраструктуру, а не на код — вплоть до переезда базы на арендованный сервер для 1С.

Поэтому оценка «в целом за столько-то» без просмотра конфигурации — это не оценка, а угадывание. Разумный порядок такой: сначала смотрим базу и сценарий, потом называем срок и цену.

Ещё одна статья расходов, которую забывают заложить: сопровождение обмена после запуска. Интеграция мобильного приложения с 1С — не разовая работа, а живая связь двух систем, каждая из которых меняется. Обновили конфигурацию — проверьте контракт. Выпустили версию приложения — старая продолжает ходить в те же методы ещё месяцами, пока пользователи обновятся. Отсюда практическое правило: методы обмена версионируют (/v1/orders, /v2/orders) и старую версию не выключают сразу. Приложение в сторе — это не сайт, откатить его одним нажатием нельзя.

❓ Частые вопросы

Нужно ли дорабатывать конфигурацию 1С ради приложения?

Почти всегда — да, но немного. Минимум — добавить HTTP-сервис и реквизит для ключа идемпотентности. Это аддитивные изменения: они не трогают учётную логику и не мешают обновлениям типовой конфигурации.

Как передаются остатки товаров в приложение?

Запросом к регистру накопления по нужным складам, а не к справочнику номенклатуры. Остаток — это не реквизит товара, это результат движений. На практике остатки отдают отдельным методом с фильтром по складу, потому что они меняются чаще каталога и синхронизируются чаще.

Что произойдёт, если связь пропала на середине отправки заказа?

При правильной реализации — ничего страшного: приложение повторит отправку с тем же ключом идемпотентности, 1С распознает повтор и вернёт номер уже созданного документа. Без ключа — получите дубль документа, и это самый частый дефект самодельных интеграций.

Можно ли обойтись без промежуточного сервера?

Да, если 1С опубликована и доступна снаружи — HTTP-сервис работает напрямую. Промежуточный сервис нужен, когда 1С нельзя выставлять в интернет, когда источников несколько или когда нужно выдержать нагрузку, которую база не должна на себя брать.

Подходит ли для этого 1С:Мобильная платформа?

Это отдельный инструмент со своей нишей: приложение пишется на встроенном языке и обменивается с базой штатно. Он хорош для внутренних задач сотрудников. Для приложения, которое выкладывается в сторы и должно выглядеть как современный продукт, чаще выбирают нативную разработку с обменом через HTTP-сервис.

Как защитить обмен?

Минимум: HTTPS, отдельный пользователь 1С с правами только на нужные методы, токен на стороне приложения и ограничение по IP там, где это возможно. Обмен персональными данными дополнительно попадает под требования 152-ФЗ — это стоит учитывать при выборе места размещения сервера.

Сколько живёт такая интеграция без вмешательства?

Пока не меняется конфигурация. Самая частая причина внезапной поломки — обновление или доработка учёта, изменившая состав данных. Поэтому контракт обмена стоит покрывать проверками на стороне 1С и не завязывать приложение на внутреннюю структуру базы (см. раздел про OData).

Что выбрать, если сценарий не попал в таблицу?

Ответьте на два вопроса — нужен ли офлайн и сколько данных синхронизируется — и вы окажетесь в одной из четырёх строк. Если офлайн не нужен, ответ почти всегда HTTP-сервис. Если нужен и данных много — план обмена. Если нужен, но данных мало — HTTP-сервис плюс очередь отправки.