Для весовых товаров нужно отдельно хранить заказанное количество и фактический вес. Изменение состава и суммы показывают покупателю, а замену подтверждают по выбранным им правилам. После сборки приложение, платёж и учёт должны использовать одну итоговую версию заказа.
Понятный состав и прозрачная сумма
Когда вес и замены обсуждают только по телефону, детали остаются в звонках и переписке. Сборщик, оператор и курьер могут увидеть разный состав. Единый процесс сохраняет решения покупателя в заказе: команда работает с понятным итогом, а клиент видит изменения до завершения покупки.
Опыт 13FOX в интернет-торговле
Для разработки сборки важно понимать весь путь заказа. В 13FOX мы делаем и интерфейс покупателя, и инструменты сотрудников.
Наш проект · «Бакаев»
От покупки в телефоне до работы команды
- В «Бакаеве» создали мобильный магазин и админ-панель, в которой собраны заказы и курьеры.
- Связали торговую систему с облачной 1С по API, включая товары, остатки и изображения.
В Frost Mining автоматизировали передачу состава заказа в доставку и складские операции. Для продуктового магазина спроектируем отдельную работу с фактическим весом и согласованием замен.
Один заказ: план 450 ₽, после сборки 393 ₽
Возьмём пример заказа без скидок и доставки: килограмм яблок по 150 ₽, 200 г сыра по 900 ₽ за килограмм и два йогурта по 60 ₽. В корзине 450 ₽. Сборщик получил 1,08 кг яблок, 190 г сыра и нашёл только один йогурт. При выбранной в примере политике недостающую упаковку удаляют после согласования.
Сумма после сборки: 393 ₽. Она возникает не из произвольной скидки, а из фактического количества каждой строки. Покупатель должен увидеть, где изменился вес и чего не будет в пакете. Старую корзину сохраняют для сравнения, а итог сборки фиксируют отдельной версией заказа.
| Товар | Запрошено | Собрано | Итог |
|---|---|---|---|
| Яблоки · 150 ₽/кг | 1 кг · 150 ₽ | 1,08 кг | 162 ₽ |
| Сыр · 900 ₽/кг | 0,20 кг · 180 ₽ | 0,19 кг | 171 ₽ |
| Йогурт · 60 ₽/шт. | 2 шт. · 120 ₽ | 1 шт. | 60 ₽ |
| Всего | 450 ₽ | Изменения согласованы | 393 ₽ |
Разделите запрос, допуск и результат взвешивания
В карточке товара укажите единицу продажи и цену за неё. Если пользователь выбирает примерный вес, интерфейс должен так и сообщать: итог уточняется после сборки. Поле «около килограмма» не означает разрешение собрать любое количество.
Нужны как минимум запрошенное количество, фактическое количество, единица, цена и допустимое отклонение по принятой политике магазина. Допуск может задаваться иначе для разных товаров. Его согласуют с бизнесом и показывают покупателю, а не зашивают одинаковым процентом во все категории.
Штрихкод фасованного товара может содержать вес, количество или другую информацию по настройкам оборудования. Это не универсальная строка, которую достаточно разделить в одном месте. Образцы реальных этикеток, префиксы и единицы проверяют вместе с весами, кассой и учётом. Ручной ввод веса тоже должен проверять единицу и допустимый диапазон.
Источники к разделу: 1С:УНФ: история изменений штрихкодов весовых и фасованных товаров.
Замена — отдельное решение покупателя
Второго йогурта нет. Программа может предложить аналог, но похожая цена не делает два товара одинаковыми. До сборки полезно дать выбор: удалить отсутствующий товар, связаться для согласования или использовать заранее выбранную замену в пределах явно описанных условий.
Для каждой замены сохраняют исходную позицию, предложенный товар, количество, новую цену, способ подтверждения и время решения. Отказ и отсутствие ответа — самостоятельные состояния. Сборщик не должен превращать молчание в автоматическое согласие, если такая политика не была явно установлена и принята.
В официальных инструкциях Picker App отдельно описаны удаление отсутствующего товара, изменение веса и замена, которую согласуют с клиентом. Это полезный пример разделения действий. В собственной системе нужно проверить свои каналы уведомлений, роли сотрудников и ограничения интеграции, а не просто повторить внешний экран.
Источники к разделу: Яндекс Picker App: изменение состава заказа; Яндекс Picker App: сборка заказа.
Как сборщику видеть статус каждой позиции
Понятный путь строки: ожидает сборки → собрана либо требует решения → решение получено → итог зафиксирован. В заказе одновременно могут быть готовые товары и позиции, по которым ещё нужен ответ. Кнопка передачи курьеру не должна скрывать нерешённое расхождение.
Повторное сообщение от телефона не должно ещё раз заменить товар или увеличить количество. Каждое изменение получает идентификатор и относится к определённой версии заказа. Если другой сотрудник уже изменил строку, приложение показывает актуальное состояние и предлагает проверить конфликт. Это особенно важно при плохой связи и нескольких сборщиках.
Перед завершением сборки показывают короткое сравнение: изменённый вес, замены, удаления и новая сумма. Покупателю не нужен внутренний журнал событий, но оператору важно восстановить, кто и на каком основании подтвердил итог. Отдельно определите, какое действие разрешает завершить сборку.
Перерасчёт заказа и операция с деньгами — разные шаги
Для итога 393 ₽ в нашем примере недостаточно поменять цифру в приложении. Нужно понять текущее состояние платежа: деньги ещё не списаны, ожидают подтверждения или уже списаны. От этого зависит дальнейшая операция. Успешный статус заказа сам по себе не подтверждает успешный платёж.
Двухстадийная оплата с предварительным резервированием может подойти не каждому способу оплаты. Например, ЮKassa документирует холдирование и частичное списание для поддерживаемых способов. Доступность, срок подтверждения и сумму проверяют в документации и настройках конкретного подключения. Нельзя обещать уменьшать и увеличивать любой платёж одним методом.
Если итог стал больше доступной к списанию суммы, заранее определите отдельный допустимый сценарий: согласование состава, дополнительная оплата или изменение заказа. Если платёж уже завершён, уменьшение суммы может потребовать другой операции, а не повторного подтверждения. Эти ветки проектируются и проверяются с платёжным провайдером.
Товарные строки, итог оплаты и данные, передаваемые кассовому сервису, должны соответствовать фактическому результату. Порядок чеков зависит от схемы расчёта и используемой кассы. Здесь описан процесс согласования систем, а не универсальная правовая или бухгалтерская инструкция.
Источники к разделу: ЮKassa: процесс платежа; ЮKassa: тестирование интеграции.
Что именно отправлять в 1С
Учёту нужны товар, характеристика при наличии, фактическое количество, единица и связь с исходным заказом. Для замены сохраняют обе стороны решения, чтобы последующее обращение покупателя не искали по устаревшей карточке. Исходный запрос полезен для анализа недостач, но не должен подменять факт отгрузки.
Уточните источник итоговой цены, правила скидок и момент резервирования. При изменении веса скидка на строку или весь заказ может пересчитаться. Итоговая формула должна быть одной для приложения, сервера и учёта. Повтор обмена возвращает тот же результат, а не новый заказ или повторное списание.
Сначала проверьте один заказ на тестовом подключении: исходный состав, изменённый вес, подтверждение замены, итог сборки и отражение оплаты. Массовое включение без такой сверки переносит ошибку одной единицы измерения на весь поток заказов.
Пять проверок до первой рабочей смены
Подготовьте товары с целым количеством, дробным весом и отсутствующей позицией. Пройдите смену с сотрудником магазина: он должен без подсказок понять единицу, увидеть ожидающее решение и передать правильный заказ. Демонстрация на экране разработчика ещё не подтверждает удобство сборщика.
Проверьте отказ от замены, недоступного покупателя, изменение веса в пределах и за пределами допуска, меньшую и большую сумму, задержанный ответ оплаты и повторную отправку результата. Для платежей используйте тестовый магазин и сценарии провайдера, а не реальные списания у клиентов.
В скачиваемом листе есть условия и ожидаемые результаты. Пройдите их с сотрудником магазина, разработчиком и специалистами по учёту и оплате. По результатам станет понятно, достаточно ли текущей платформы или нужна отдельная разработка.
- Запрошенный и фактический вес различимы.
- Отказ или молчание покупателя не скрывают проблему.
- Итог виден перед завершением сборки.
- Повтор события не меняет заказ второй раз.
- Приложение, оплата и учёт показывают один фактический состав.
Шаблон для вашего сценария
Откройте CSV в Excel или другой таблице и заполните данные вашего магазина. Доступен без регистрации.
Когда лучше доработать готовую систему
Если готовое приложение сборки поддерживает ваши товары, замену и обмен с учётом, начните с проверки его функций. Собственное решение требуется, когда нужны особые согласования, оборудование, роли, несколько каналов заказов или процессы, которые платформа не покрывает.
В проекте «Бакаев» мы разработали мобильный магазин и настроили двусторонний обмен с 1С. Работу с весом и заменами для вашего магазина спроектируем отдельно и проверим вместе со сборщиками.
По теме: Приложение продуктового магазина · Приложение сборщика заказов · Кейс «Бакаев».
Вопросы по теме
Можно ли сразу списать точную сумму весового заказа?
Это зависит от того, известен ли фактический вес до оплаты. Если он уточняется при сборке, нужно заранее спроектировать перерасчёт и поддерживаемый платёжным сервисом сценарий. Одной смены суммы в приложении недостаточно.
Можно ли заменять товар автоматически?
Только в рамках заранее определённых и явно согласованных условий. В остальных случаях система предлагает замену и сохраняет решение покупателя. Отсутствие ответа не следует незаметно трактовать как согласие.
Подходит ли холдирование для любой оплаты?
Нет. Поддержка двухстадийной оплаты, частичного списания и сроки зависят от способа оплаты и подключения. Это проверяют у конкретного провайдера до обещаний покупателю.
Что передавать в учёт: плановый или фактический вес?
Для результата сборки нужен фактический вес с правильной единицей. Исходный запрос сохраняют отдельно, чтобы объяснить расхождение и связать заказ с отгрузкой, оплатой и обращениями покупателя.
Обязательно ли писать новое приложение сборщика?
Нет. Сначала проверяют готовый продукт и существующую интеграцию на одном заказе с весом, заменой и изменением суммы. Заказная разработка нужна для подтверждённых ограничений текущего решения.
Источники
Материал подготовлен 2 ноября 2026 года. При настройке сверяйте документацию с вашей версией системы и условиями подключения.
Сборка, оплата и учёт — один понятный процесс
Разработаем приложение сборщика или доработаем действующую систему. Свяжем вес, замены, согласование с покупателем и передачу результата в 1С. Платёжный сценарий подберём под ваше подключение.