BORNLI
BORNLI / Материалы / Приложение для склада: разработка и интеграция с 1С

BORNLI / о разработке по делу

Разработка мобильного приложения для склада.

Сканирование товаров, приёмка и сборка заказов — с передачей результата в вашу учётную систему. Разбираем модельный сценарий, состав первой версии и проверки перед оценкой.

Редакция BORNLI ·

Приложение для склада на заказ

От сканирования товара до записи в учёте.

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

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

Выбор решения

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

Процесс укладывается в существующий модуль

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

Например, «1С:Кладовщик» поддерживает совместную работу с 1С:Розницей и 1С:УНФ, приёмку, сборку заказов и инвентаризацию. Производитель описывает его как инструмент для подсобных помещений и небольших магазинов; для крупных складов с адресным хранением продукт не позиционируется. Документация 1С и требования к подключению ↗

Есть конкретный пробел в процессе

Индивидуальную разработку стоит оценивать, когда готовый вариант не закрывает обязательное действие: особые правила сборки, согласование замен, несколько систем или интерфейс для выбранного оборудования.

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

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

Модельный сценарий

Сборка одного заказа с расхождением.

Это собирательный пример для обсуждения будущего приложения. Он не описывает клиента BORNLI, выполненный проект или достигнутые результаты.

01 / Учётная системаЗадание

Заказ, позиции, количество и доступные места хранения

02 / Сотрудник складаСверка

Штрихкод, фактическое количество и расхождение

03 / Обмен даннымиРезультат

Подтверждение операции или понятная ошибка

Модельный сценарий. Роли, статусы и правила учёта согласовываются для каждого склада.

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

Такой путь можно показать в кликабельном прототипе. Для рабочей версии дополнительно нужны обмен данными, права сотрудников, проверка на выбранных устройствах и обработка ошибок.

Состав первой версии

Выберите операцию, которую проверите целиком.

01 / Приёмка

План и фактически полученный товар

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

02 / Сборка

Задание и разрешённые действия

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

03 / Инвентаризация

Пересчёт и согласование

Участок проверки, фактические количества, повторный пересчёт и передача расхождений ответственному. Право исправлять учётные остатки согласовывают отдельно.

04 / Управление

Состояние работ и история

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

Не обязательно включать все четыре направления в первый этап. Выберите путь от задания до подтверждённого результата и перечислите исключения. Как определить состав рабочей первой версии.

Интеграция с 1С или WMS

Согласуйте, какая система отвечает за данные.

WMS — система управления складом. В предлагаемом сценарии учётная система выдаёт задания и принимает результаты. Если архитектура у вас другая, распределение ответственности меняется.

  1. Товары и единицы измерения. Как приложение узнаёт позицию по штрихкоду? Что делать с упаковкой, которая содержит несколько единиц, неизвестным кодом или товаром без этикетки?
  2. Задания и остатки. Где создаётся заказ, кто назначает сотрудника и когда меняется статус? Приложение должно показывать время обновления, если использует сохранённые данные.
  3. Права и согласование. Кто может подтвердить недостачу, разрешить замену, отменить сборку или изменить уже переданный результат? Эти действия нужно сопоставить с правами в учётной системе.
  4. Повторная отправка. Операции присваивают идентификатор, по которому можно распознать повтор. Проверяют обе стороны обмена: повторное нажатие и восстановление связи не должны создавать вторую запись об одной операции.
  5. Работа без связи. Заранее определяют, какие действия разрешены по сохранённым данным, как видна очередь отправки и что произойдёт при конфликте с обновлённым заданием. Полноценная работа офлайн — отдельная часть объёма разработки.

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

Телефон или ТСД

Проверьте интерфейс на рабочем устройстве.

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

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

В разборе прототипа AVIOKI показано, как проверять действия и состояния интерфейса до разработки. AVIOKI демонстрирует заказ еды; это пример метода проверки, а не складское приложение или подтверждение интеграции с WMS.

Приёмка рабочей версии

Пять проверок перед первым рабочим заданием.

Ниже — предлагаемый план проверки модельного сценария. Ожидаемое поведение фиксируют в задании на разработку и затем проверяют в тестовой среде.

  1. Сканировали другую позицию. Приложение показывает несоответствие заданию. Операция не проходит как правильный товар; разрешённый способ замены проверяется отдельно.
  2. Количество не совпало. План, факт и причина расхождения остаются доступны сотруднику и ответственному. В учётной системе отображается согласованное решение.
  3. Связь оборвалась во время передачи. После восстановления приложение выясняет состояние уже отправленной операции. В учёте остаётся одна запись, а очередь передачи очищается только после подтверждения.
  4. Задание изменили на другом рабочем месте. Проверяют, как приложение обнаруживает отмену или новую версию задания и кому передаёт конфликт. Сохранённые на устройстве данные не должны молча заменять актуальные.
  5. Сотрудник вышел из аккаунта или сменил устройство. Незавершённые задания и права нового пользователя отображаются согласно согласованным правилам. Действия можно связать с сотрудником и конкретным заданием.

Лист проверки: повторная отправка после обрыва связи.

Этот заполненный пример можно перенести в ТЗ и заменить обозначения своими. Это модельный сценарий для тестовой среды: заказ WH-TEST-01 и товар A-001 вымышлены.

Исходные данные и действия

  1. Задание WH-TEST-01: товар A-001, план — 6 штук. Сотрудник находит 5 и указывает недостачу 1.
  2. Перед отправкой сохраните версию задания, роль сотрудника и состояние документа в учётной системе.
  3. Разорвите связь после приёма результата сервером, но до получения ответа приложением. Затем восстановите связь и повторите отправку той же операции.

Момент обрыва воспроизводят вместе с разработчиком в тестовой среде. Простое выключение Wi-Fi до нажатия кнопки проверяет другой случай: запрос мог ещё не попасть на сервер.

Ожидаемый результат

  • В истории учётной системы одна принятая операция с тем же идентификатором; повтор не создаёт второй документ.
  • План 6, факт 5 и причина расхождения сохранены. Решение о частичной отгрузке остаётся за согласованной ролью.
  • Приложение получает подтверждение, убирает операцию из очереди и показывает тот же результат, что учётная система.

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

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

Модельный сценарий, не результат внедрения BORNLI. Критерии приёмки адаптируют к вашему обмену и правилам учёта.

Стоимость и срок

Что входит в оценку складского приложения?

Типовой проект BORNLI для iOS и Android стоит 300 000 ₽ в согласованном объёме: один основной сценарий, личный кабинет, дизайн, разработка, тестирование и подготовка к публикации. Интеграции и дополнительные функции оцениваются отдельно. Это не готовая смета приложения для склада.

На главной также указаны сложные проекты от 450 000 ₽ и экосистемы от 600 000 ₽. Для вашего склада сумму определяют количество операций и ролей, способы обмена, оборудование, работа без связи и необходимость панели управления. Из чего складывается стоимость разработки.

Ориентир 30 дней относится к типовому согласованному объёму после получения материалов. Срок интеграции с учётной системой определяем после проверки её возможностей. Бесплатный кликабельный прототип за 24 часа после обсуждения и получения материалов помогает согласовать путь сотрудника до договора.

Перед оценкой

Что передать для обсуждения проекта?

  1. Одну операцию, которую хотите перенести в приложение, и пример её задания без конфиденциальных данных.
  2. Название, конфигурацию и версию учётной системы; контакт специалиста, который отвечает за обмен.
  3. Модели рабочих устройств и примеры типов штрихкодов.
  4. Роли сотрудников, правила работы с расхождениями и потребность в работе без связи.
  5. Признак готовности: какое действие и какой результат в учётной системе нужно показать при сдаче первого этапа.

Если отдельного ТЗ пока нет, начните с описания одного рабочего дня сотрудника. Обсудим процесс и подготовим прототип ↗.

Редакция BORNLI. Лист приёмки дополнен 9 октября 2026 года. Оффер и документация 1С повторно проверены 12 октября 2026 года. Сценарий сборки, состав проекта и план приёмки разработаны как модельный пример; результаты реального клиента не заявляются.

От идеи к конкретике

Покажем, как может работать ваш продукт.

Обсудим задачу и материалы, затем подготовим бесплатный кликабельный прототип за 24 часа. До договора.

Обсудить прототип ↗