Разработка и Конфигурация · 11 мин
1С мобильная касса для разработчиков: что это и как с ней работать
Что такое 1С мобильная касса для разработчиков: архитектура, API, интеграция с мобильными приложениями, печать чеков и типичные ошибки при внедрении.
1С мобильная касса — это решение на платформе «1С:Предприятие», которое превращает смартфон или планшет в полноценную кассу с регистрацией продаж, печатью чеков и передачей фискальных данных. Для разработчика это не просто готовое приложение из магазина, а конфигурация и набор механизмов платформы, которые можно расширять, дорабатывать и интегрировать с товароучётной системой.
Под термином «мобильная касса» в экосистеме 1С обычно понимают два разных сценария: готовое мобильное приложение «1С:Мобильная касса» для малого бизнеса и мобильные решения, собранные на мобильной платформе 1С собственными силами. Разработчику важно различать эти варианты, потому что подходы к доработке, обмену данными и фискализации в них принципиально различаются.
Типовая задача выглядит так: курьер, выездной продавец или кассир на разъездной торговле пробивает чек на устройстве, данные о продаже попадают в центральную базу (1С:Управление торговлей, 1С:Розница, самописная конфигурация), а фискализация выполняется либо через подключённый фискальный регистратор, либо через облачную кассу. Роль разработчика — собрать эту цепочку и обеспечить её устойчивость.
Что именно скрывается за термином
Мобильная платформа 1С — это среда исполнения, позволяющая запускать конфигурации на Android и iOS. Разработчик собирает мобильное приложение из конфигурации в мобильной платформе, а не пишет код на Java, Kotlin или Swift. Вся логика — на встроенном языке 1С, интерфейс описывается формами, адаптированными под сенсорный экран.
Готовое приложение «1С:Мобильная касса» распространяется как типовое решение и ориентировано на микробизнес: продажа за наличные и по карте, простой товарный справочник, отчёты по выручке. Его исходный код доступен для изучения и доработки, что делает приложение удобной отправной точкой для собственных решений.
Важно понимать ограничение: мобильная платформа поддерживает не весь функционал «большой» платформы. Часть объектов метаданных и механизмов недоступна, поэтому перенести на смартфон полноценную конфигурацию уровня УТ или ERP нельзя — мобильный клиент проектируется как облегчённое рабочее место с узким набором операций.
Архитектура решения: как устроена связка
Типовая архитектура включает три компонента. Первый — мобильное приложение с локальной базой на устройстве: оно должно работать автономно, потому что связь в точке продажи не гарантирована. Второй — центральная информационная база, куда стекаются данные о продажах и откуда загружаются товары и цены. Третий — механизм фискализации: физический фискальный регистратор по Bluetooth или облачная касса.
Обмен между мобильным и центральным узлами обычно строится на планах обмена, веб-сервисах или HTTP-сервисах. План обмена «Мобильное приложение» даёт готовую модель распределённой базы: регистрация изменений, пакеты сообщений, разрешение коллизий. HTTP-сервисы гибче, но требуют самостоятельной реализации протокола обмена, контроля дублей и очередей.
Локальная база на устройстве — критичный элемент. Если продажа не сохраняется при отсутствии сети, кассир теряет возможность работать, а это прямые убытки. Поэтому принцип проектирования прост: сначала запись в локальную базу и печать чека, затем выгрузка в центральный узел при появлении связи.
Инструменты разработчика и цикл сборки
Разработка ведётся в конфигураторе с установленной мобильной платформой. Отладка возможна на реальном устройстве по Wi-Fi: конфигуратор подключается к мобильному клиенту, и код можно выполнять по шагам, смотреть переменные и стек вызовов — как в обычной базе.
Для публикации приложение собирается сборщиком мобильных приложений: на входе — конфигурация, иконки, параметры подписи, на выходе — APK для Android или пакет для iOS. Для iOS потребуется учётная запись разработчика Apple и сертификаты, это отдельная организационная процедура, которую стоит заложить в сроки проекта.
Практический порядок работы над типовым проектом выглядит так.
- 1Установите мобильную платформу и изучите демонстрационную конфигурацию мобильной кассы
- 2Спроектируйте состав данных: какие справочники и документы нужны на устройстве, что остаётся в центре
- 3Настройте обмен: план обмена или HTTP-сервисы, протестируйте работу без сети
- 4Подключите и проверьте фискализацию на тестовом оборудовании или облачной кассе
- 5Соберите приложение сборщиком и проведите полевое тестирование на целевых устройствах
Фискализация и печать чеков
Печать чеков — самая чувствительная часть решения. Вариантов два: подключение фискального регистратора к устройству (обычно по Bluetooth) или использование облачной кассы, когда чек фискализируется на стороне сервиса, а покупателю отправляется электронный чек или печатается на обычном принтере с указанием реквизитов.
В мобильной платформе работа с оборудованием выполняется через механизм внешних компонентов, адаптированных под мобильную среду. Производители фискальных регистраторов поставляют компоненты для своих устройств; перед выбором модели убедитесь, что компонента существует и поддерживается под нужную версию мобильной платформы.
Облачная касса снимает проблему драйверов, но добавляет зависимость от интернета и внешнего сервиса. Если связь пропала в момент фискализации, нужен сценарий повторной отправки и контроль, чтобы один и тот же чек не ушёл дважды. Это решается уникальными идентификаторами чеков и проверкой статуса на стороне сервиса.
Обмен данными с центральной базой
Главные требования к обмену: идемпотентность (повторная отправка пакета не создаёт дубли), устойчивость к обрывам и контроль очерёдности. Продажи должны попадать в центральную базу в хронологии, иначе отчёты по сменам и остаткам «поедут».
Типовая схема: на устройстве документы «Отчет о розничных продажах» или аналогичные регистрируются в плане обмена, при синхронизации пакет уходит в центральный узел, ответ подтверждает приём. Товары и цены движутся в обратную сторону — из центра на устройство, причём выгружать следует только актуальный для точки ассортимент, чтобы не раздувать локальную базу.
Проверить корректность обмена помогают контрольные точки: сверка количества и сумм документов за смену на устройстве и в центре, отсутствие «зависших» неотправленных пакетов, совпадение остатков после инвентаризации.
Как проверить результат
Чек печатается, документ сохраняется локально и уходит в центр после появления сети
Продажа блокируется или теряется при отсутствии связи
Документы не дублируются в центральной базе
После повторной отправки появляются двойные продажи
Чек содержит все обязательные реквизиты и фискальные признаки
Чек обрывается, реквизиты отсутствуют или чек не фискализируется
Типичные ошибки и их последствия
Опыт внедрений показывает, что большинство проблем связано не с кодом, а с проектными решениями на старте. Ниже — ошибки, которые встречаются чаще всего.
Отдельно стоит сказать про обновления. Мобильное приложение живёт на устройствах пользователей, и обновить всех разом невозможно. Значит, протокол обмена должен быть обратно совместим: центральная база обязана принимать данные от старых версий приложения хотя бы в переходный период.
Когда выбирать готовое приложение, а когда — свою разработку
Сравнение вариантов
Подходит микробизнесу с простыми продажами без специфики. Ограничение: нестандартные процессы (маркировка, сложные скидки, интеграции) потребуют доработки или не реализуются вовсе.
Разумный средний путь: берёте готовую логику чеков и обмена, добавляете свои формы и правила. Ограничение: нужно поддерживать совместимость при обновлениях типового решения.
Полный контроль над процессами и интерфейсом, оправдано при уникальных сценариях. Ограничение: вся ответственность за фискализацию, обмен и поддержку ложится на вашу команду.
Критерий выбора простой: чем дальше процессы компании от стандартной розничной продажи, тем сильнее аргумент в пользу собственной разработки. Если же требуется «продавать и печатать чеки» без особенностей, изобретать решение с нуля экономически бессмысленно.
Что важно запомнить
1С мобильная касса для разработчика — это конфигурация на мобильной платформе с локальной базой, обменом с центральным узлом и фискализацией через ФР или облачную кассу. Ключевые принципы: автономность работы без сети, идемпотентный обмен, тестирование на реальных устройствах и аккуратное обновление протоколов.
Частые вопросы
Нужно ли знать Java или Swift для разработки мобильной кассы на 1С?
Нет. Вся бизнес-логика пишется на встроенном языке 1С в конфигураторе, а сборка в нативное приложение выполняется сборщиком мобильных приложений. Знание нативных языков может пригодиться только для написания собственных внешних компонентов под нестандартное оборудование.
Может ли мобильная касса работать полностью без интернета?
Регистрация продаж и сохранение документов в локальной базе — да, это базовое требование к проектированию. Ограничение касается фискализации: при использовании облачной кассы связь нужна в момент фискализации, поэтому для полностью автономной работы выбирают физический фискальный регистратор, подключаемый к устройству.
Как отлаживать код на мобильном устройстве?
Конфигуратор поддерживает отладку мобильного приложения по сети: устройство и компьютер разработчика должны быть в одной Wi-Fi сети, в настройках мобильного клиента включается режим отладки. Дальше работают привычные точки останова, просмотр переменных и пошаговое выполнение.
Что делать, если чек не напечатался из-за обрыва связи с принтером?
Нужен отдельный сценарий восстановления: проверить статус документа в фискальном регистраторе или облачном сервисе, при необходимости выполнить повторную печать копии чека, но не повторную фискализацию. Повторная фискализация одной продажи создаст расхождение с реальной выручкой.
Как организовать обновление приложения на десятках устройств?
Через механизм дистрибуции: публикацию в магазинах приложений или корпоративную рассылку APK с принудительной проверкой версии при синхронизации. Центральная база должна принимать данные от предыдущих версий приложения, пока обновятся все устройства.
Подходит ли мобильная касса для работы с маркированными товарами?
Мобильная платформа поддерживает работу со сканерами штрихкодов, включая коды DataMatrix, поэтому технически сканирование маркировки реализуемо. Однако полный контур проверки кодов и передачи данных в систему маркировки требует отдельной проработки обмена и тестирования на соответствие требованиям, действующим для вашей товарной группы.