Мобильная разработка за неделю #643: приложение не шлёт заказы в 1С

Мобильное приложение перестаёт отправлять заказы в 1С, когда меняется одна из трёх сторон обмена: версия приложения, версия ОС телефона или публикация HTTP-сервиса на сервере 1С. Чинится это проверкой журнала обмена и версии API; повторы предотвращает версионирование методов, очередь отправки на телефоне и тестовый прогон перед каждым релизом.

В выпуске #643 (10—16 августа) не пересказываем новости, а разбираем одну типовую поломку: приложение торговых агентов или склада открывается, экраны работают, а данные до 1С не доходят. Дальше по шагам: откуда она берётся, как её диагностировать, какой способ обмена выбрать и сколько это стоит.

Почему возникает сбой: приложение не отправляет заказы в 1С 🔍

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

Связь обрывается в одном из трёх мест, и у каждого свой признак.

Приложение и 1С говорят на разных версиях API

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

Слетела публикация или истёк сертификат на стороне 1С

После обновления платформы или конфигурации веб-сервер иногда публикуется заново без HTTP-сервиса обмена или без прав у служебного пользователя. Отдельный случай: истёк TLS-сертификат. Браузер на офисном компьютере показывает предупреждение, которое сотрудники привычно закрывают, но мобильное приложение соединение с таким сертификатом не установит вовсе. Запросов в журнале 1С при этом нет совсем.

Новая версия ОС ограничивает фоновую работу и сеть

Android и iOS из года в год ужесточают правила: запрещают обычный HTTP без шифрования, усыпляют фоновые задачи ради батареи, требуют отдельных разрешений. Приложение, написанное под прежние правила, на одних телефонах работает, а на других молча теряет фоновую отправку. У одного агента заказы уходят, у второго нет, и поиск причины идёт по кругу.

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

Как исправить, если заказы уже застряли 🛠

Порядок важен: сначала остановить рост проблемы, потом искать причину.

1. ✓Попросите агентов не нажимать «Отправить» повторно и не переустанавливать приложение. Вместе с приложением пропадёт локальная очередь, где лежат неотправленные заказы.
2. ✓Откройте журнал регистрации 1С за период сбоя и найдите обращения к HTTP-сервису. Обращений нет совсем: разрыв до 1С, то есть сеть, сертификат или публикация. Обращения есть, но с ошибками: читайте текст ошибки, он называет метод, поле или права.
3. ✓Откройте адрес сервиса на телефоне через мобильный интернет, а не через офисный Wi-Fi. Так вы увидите то, что видит агент: проблемы с сертификатом и недоступность из внешней сети.
4. ✓Сверьте версию приложения у агентов с версией метода обмена в 1С. Расхождение лечится откатом публикации на прежний метод или принудительным обновлением приложения.
5. ✓Когда связь восстановлена, выгрузите очередь заказов с телефонов и проверьте номера на дубли до того, как 1С проведёт документы.

Работа на стороне 1С (публикация, права, сертификат) идёт по ставке сопровождения 1С и сисадмина: 3800 руб/час. Если обмен писали без журнала в самом приложении и без версий методов, быстрее переписать этот слой, чем гадать по косвенным признакам. Так мы строим интеграцию мобильного приложения с 1С: у каждого заказа есть идентификатор, созданный на телефоне, поэтому повторная отправка не плодит дубли, а журнал ведётся с обеих сторон.

Что делать, если ошибка повторяется

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

• ✓после каждого релиза приложения: у обмена нет версий, любое изменение метода бьёт по старым установкам;
• ✓после обновления 1С или платформы: публикацию собирают вручную, и каждый раз что-то теряется;
• ✓раз в год в один и тот же день: истекает сертификат, и за сроком никто не следит;
• ✓только у части телефонов: экономия батареи или ограничения конкретной оболочки убивают фоновую отправку;
• ✓по утрам или при закрытии месяца: 1С отвечает минутами, приложение не дожидается и повторяет запрос.

Последний пункт лежит вне приложения. Если база подвисает на слабом офисном сервере, любой обмен с ней превращается в лотерею. Лечится переносом на сервер с нормальными ресурсами: аренда 1С стоит от 1100 руб/мес за пользователя.

Какой способ обмена выбрать

Повторяющиеся сбои обычно значат, что выбран слишком простой способ обмена. Сравним четыре варианта.

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

Как предотвратить повтор после следующего релиза ✅

Предотвращение сводится к привычкам релиза, а не к сложной технике. Рабочий минимум такой:

• ✓Версия в адресе метода. Новая версия приложения ходит в v2, старая в v1, и отключать v1 можно только тогда, когда на неё не осталось установок.
• ✓Идентификатор заказа создаётся на телефоне. Если запрос ушёл дважды, 1С находит заказ по идентификатору и не создаёт второй документ.
• ✓Приложение различает ошибки. Нет сети: повторить позже. 1С вернула отказ: показать причину пользователю и записать в журнал, но не повторять бесконечно.
• ✓Релиз выходит в начале недели, а не в пятницу вечером, и сначала доходит до небольшой группы. Где магазин приложений поддерживает поэтапную выкатку, используйте её; для внутренней раздачи выберите несколько активных агентов.
• ✓Напоминание о сроке сертификата и сигнал, если за рабочее утро в 1С не появилось ни одного заказа из приложения. Такой мониторинг не требует отдельной системы и ловит ровно ту ситуацию, с которой началась эта статья.

Отдельно про данные. В заказах лежат имена, телефоны и адреса клиентов, это персональные данные, а 152-ФЗ требует хранить данные граждан РФ в базах на территории России. Проверьте, что журналы обмена и промежуточный сервер, если он есть, тоже стоят в российском контуре и не пишут телефоны клиентов открытым текстом.

Если приложение нужно не вашим агентам, а клиентам, которые оформляют заказ и смотрят статус отгрузки, те же правила действуют жёстче: обзвонить всех и попросить обновиться не получится. Для такого случая мы делаем мобильное B2B-приложение с 1С, где версия API живёт дольше версии приложения.

Чинить обмен или разрабатывать заново: что и за сколько 💰

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

Разработка нового приложения у нас стоит от 500000 руб. Итог зависит от числа экранов, от того, какие документы приложение создаёт в 1С, и от офлайн-режима. Точную сумму мы называем после разбора вашей конфигурации и схемы обмена. Ставки на сопровождение и другие услуги собраны на странице цены и тарифы.

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

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

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

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

Как не получить дубли заказов при повторной отправке из приложения?

Создавайте идентификатор заказа на телефоне в момент оформления и передавайте его в 1С вместе с документом. При повторном запросе 1С ищет заказ по этому идентификатору и возвращает уже созданный документ вместо нового. Без такого ключа каждая повторная отправка после сбоя связи рискует породить второй заказ и вторую отгрузку.

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

Разработка мобильного приложения у нас стоит от 500000 руб. Итоговая сумма зависит от числа экранов, документов, которые приложение создаёт в 1С, и от офлайн-режима. Точную цифру мы называем после разбора вашей конфигурации и схемы обмена. Работы на стороне 1С, например публикацию, права и сертификат, считаем по ставке сопровождения 3800 руб/час.

Нужен ли офлайн-режим в приложении для торговых агентов?

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

Как проверить, что после релиза обмен с 1С не сломался?

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