Мобильная разработка за неделю #647: заказы агентов не доходят до 1С

Заказы из мобильного приложения не доходят до 1С, когда приложение отправляет их одним запросом без очереди и подтверждения: связь оборвалась, и заказ пропал. Лечится офлайн-очередью на телефоне, уникальным номером каждого заказа и ответом 1С «принято». Тогда агент в метро или на складе не теряет заявку.

Выпуск #647 (21–27 сентября) разбирает одну задачу, с которой сталкиваются B2B-проекты с выездными сотрудниками: как передавать заказы из приложения в 1С так, чтобы они не пропадали и не дублировались. Для московских компаний, где торговые агенты, монтажники и курьеры оформляют заявки с телефона, это вопрос ежедневной выручки.

Почему заказы из приложения не доходят до 1С 📉

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

Такая картина складывается из нескольких конкретных сбоев.

Обрыв связи в момент отправки

Мобильная сеть рвётся в метро, лифтах и на складах с металлическими стеллажами. Если заказ не сохранён на телефоне, он существует только внутри запроса и пропадает вместе с обрывом.

Дубли после повторного нажатия

Агент видит, что заказ «завис», и жмёт кнопку ещё раз. Первый запрос на самом деле дошёл, просто ответ не вернулся. В 1С появляются два одинаковых заказа, и склад собирает оба.

Тихий отказ после обновления 1С

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

Что теряет бизнес

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

Как исправить: схема обмена, которая не теряет заказы 🔧

Заказ должен жить на телефоне, пока 1С явно не подтвердит приём. Для этого нужны пять правил:

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

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

Агенту нужен экран «Исходящие» со статусами всех заказов за день. Он занимает один экран, но избавляет от звонков в офис с вопросом «дошло или нет». Если заказ получил статус «ошибка» две попытки подряд, приложение предлагает позвонить в офис и называет номер заказа в очереди. Менеджер при этом видит то же, что видит агент.

Когда проще взять 1С:Мобильную платформу

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

Четыре подхода, которые встречаются чаще всего:

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

Если заказы продолжают пропадать после того, как очередь заработала, причина лежит не в приложении. Идите по цепочке от телефона к базе:

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

Как отличить сбой сети от сбоя сервера

Попросите агента отправить тот же заказ с офисного Wi-Fi. Прошёл: проблема в мобильной сети или в том, как приложение переживает слабый сигнал. Не прошёл и с Wi-Fi: ищите в сервере, сертификате или сервисе 1С. Эта минутная проверка сразу делит поиск на две половины.

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

Как предотвратить потерю заказов в будущем 🛡️

Часть защиты закладывается до релиза, часть работает каждый день.

• ✓Тест на обрыв связи перед каждым релизом: включите режим полёта посреди отправки, зайдите в лифт, спуститесь в подвал. Тест занимает несколько минут и ловит именно ошибки очереди.
• ✓Версия протокола обмена в каждом запросе. После обновления 1С сервис отвечает, что приложение устарело, и агент видит просьбу обновиться вместо молчаливой ошибки.
• ✓Мониторинг очереди. Счётчик заказов, которые лежат в статусе «в очереди» дольше 15 минут, уходит в Telegram руководителю отдела продаж.
• ✓Ежедневная автоматическая сверка: число заказов за день на устройствах и в 1С. Расхождение приходит уведомлением, а не находится вручную.

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

Персональные данные в телефоне агента

В приложении лежат контакты клиентов, а имена и телефоны контактных лиц и ИП относятся к персональным данным, поэтому действует 152-ФЗ. Блокировка экрана, шифрование локальной базы и удалённый сброс при потере телефона закрывают самый частый риск: смартфон, забытый в такси. Хранить на устройстве стоит только те поля, без которых агент не оформит заказ. Какие обязанности возникают именно у вашей компании, уточняйте у юриста.

Сколько стоит такое приложение и чем отличается наш подход 💼

Разработка мобильных приложений у нас начинается от 500 000 ₽. Итог зависит от числа экранов, платформ (Android, iOS) и сложности обмена с 1С. Актуальные цены и тарифы смотрите на странице цены и тарифы. Если приложение уже работает и надо поправить только обмен на стороне 1С, это работа специалиста по 1С: сопровождение стоит 3800 ₽/час.

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

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

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

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

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

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

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

Может ли приложение для торговых агентов работать без интернета?

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

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

Мобильная разработка у нас начинается от 500 000 ₽. Итоговая цена зависит от числа экранов, платформ и сложности обмена с 1С. Если приложение уже есть и нужно исправить обмен на стороне 1С, сопровождение 1С стоит 3800 ₽/час. Сроки и точную стоимость называем после разбора задачи.

Нужно ли учитывать 152-ФЗ в приложении для торговых агентов?

Да, если в приложении лежат имена и телефоны контактных лиц клиентов, это персональные данные. Включите блокировку экрана, шифрование локальной базы и удалённый сброс при потере телефона, храните на устройстве только нужные поля. Какие именно обязанности возникают у вашей компании по 152-ФЗ, уточните у юриста.