Мобильная разработка за неделю #646 (14 — 20 сентября): спринт с 1С по дням

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

Выпуск #646 не пересказывает новости магазинов приложений. Мы возьмём условный проект и проживём неделю с 14 по 20 сентября как рабочий спринт: оптовая компания в Москве, 30 торговых представителей, заказы оформляются в приложении и уходят в 1С:Управление торговлей. Цифры в примере условные, механика совпадает с реальными проектами.

🗓 понедельник: что в приложении своё, а что принадлежит 1С

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

В понедельник на бумаге фиксируем пять вещей:

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

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

⚙️ вторник: обмен с 1С, где всё ломается первым

Вторник, 9:10. Представитель открывает карточку товара, видит остаток 12 штук и оформляет заказ на десять. Менеджер в офисе открывает этот заказ в 1С и видит ноль: час назад склад отгрузил товар другому клиенту. Приложение показало остаток последнего обмена, но обмен шёл раз в час по расписанию, поэтому цифра на экране отставала от склада.

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

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

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

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

📴 среда: офлайн и конфликты, когда связь пропала на складе клиента

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

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

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

🧩 четыре варианта платформы и когда какой брать

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

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

📱 четверг: тест на телефонах представителей, а не на эмуляторе

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

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

Поэтому в четверг тест идёт на устройствах из парка заказчика: самый старый Android, самый дешёвый, один iPhone. Проверяем:

• ✓поиск по номенклатуре на полном каталоге, а не на десяти тестовых позициях;
• ✓вход после недели без обновления данных;
• ✓отправку заказа в режиме полёта и через минуту после включения сети;
• ✓отзыв доступа у уволенного сотрудника без переустановки приложения;
• ✓сканирование штрихкода при плохом освещении.

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

📦 пятница: релиз-кандидат и пилот на пяти людях

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

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

Способ доставки выбирают по задаче: RuStore, Google Play, App Store или закрытая раздача сотрудникам. Для внутреннего инструмента публичная страница в магазине нужна не всегда. Сроки проверки в магазинах непредсказуемы, поэтому дату выхода без запаса не обещайте ни себе, ни представителям.

💰 сколько стоит такая неделя и что мы делаем иначе

Мобильная разработка у нас стоит от 500 000 ₽. Конечная цифра зависит от числа экранов, глубины офлайн-режима, работы со сканером или принтером и сложности обмена. Приложение, которое показывает каталог и принимает заказы, и приложение с офлайн-очередью, онлайн-резервом и сканером — разные по объёму проекты, и считаем мы их по-разному. Что входит в стоимость, смотрите в разделе цены и тарифы.

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

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

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

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

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

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

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

Как приложение получает актуальные остатки из 1С?

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

Что выбрать: 1С:Мобильную платформу или кроссплатформенную разработку?

Мобильная платформа 1С подходит для учётных задач с типовым интерфейсом: инвентаризация, заявки, выездной сервис. Если нужен фирменный дизайн или приложением пользуются клиенты, берут Flutter или React Native с обменом через HTTP-сервисы 1С. Нативная разработка нужна для сложной работы с оборудованием.

Нужно ли хранить данные мобильного приложения в России?

Если приложение собирает персональные данные граждан России, например контакты клиентов или геопозицию сотрудников, 152-ФЗ требует хранить базы с ними на серверах в России. Серверную часть приложения поэтому размещают в российском дата-центре.