Весовой товар на сайте: сумма до и после взвешивания

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

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

Корзина ещё не результат взвешивания

Возьмём вымышленную позицию с учебной ценой восемьсот рублей за килограмм. Покупатель просит один килограмм. Предварительная строка составляет восемьсот рублей. После сборки получена масса 1,08 килограмма. Простое умножение даёт 864 рубля. Разница в 64 рубля должна быть объяснима по исходным величинам, а не появляться как безымянная надбавка в итоговом счёте.

Эти числа не являются прайсом какого-либо магазина. Они нужны, чтобы проверить модель. Если сотрудник исправит массу обратно на единицу ради совпадения суммы, данные перестанут описывать собранный товар. Если программа молча заменит первоначальный запрос на 1,08, исчезнет основание для сравнения. Поэтому храните желаемое количество и фактическую массу раздельно.

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

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

Что покупатель выбирает до оформления

Карточка должна сообщать единицу цены рядом с числом. Подпись «800» без «за килограмм» или другой подтверждённой единицы не позволяет восстановить расчёт. Если выбранное количество является ориентиром, это должно быть понятно в момент выбора, а не только после сборки. Точное содержание условий нужно согласовать для конкретного магазина.

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

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

Экран сборщика показывает исходное пожелание

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

Браузерное поле само по себе не определяет допустимый шаг бизнеса. В документации MDN о числовом вводе описаны ограничения min, max и step; по умолчанию шаг составляет единицу. Для дробной массы требуется соответствующая настройка. При этом браузерная проверка не заменяет проверку значений на сервере и правил конкретной позиции.

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

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

Пересчёт должен оставаться воспроизводимым

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

Определите точность хранения и порядок округления. Масса, цена за единицу и денежный результат могут иметь разные требования. Не стоит округлять вес до целого килограмма только потому, что итог показывается в рублях. Пример 1,08 умножить на 800 даёт точное значение 864; другие исходные данные требуют заранее описанного правила представления результата.

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

Изменение состава должно быть заметным

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

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

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

Приёмка на учебном заказе

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

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

В конце попросите человека, который не участвовал в настройке, объяснить учебную сумму по экрану. Он должен найти цену за единицу, фактическую массу и причину изменения. Если для этого требуется устный комментарий разработчика, представление ещё не готово. Принимать нужно понятность заказа и воспроизводимость расчёта, а условия продажи и оплаты проверять отдельными согласованными сценариями.