Веб-приложение для приёмки металлолома: минимальный поток взвесил, рассчитал, выплатил. Формы актов, касса, отчёты по сменам и контроль ошибок.
Пункт приёма зарабатывает не на красивых таблицах, а на точном и быстром расчёте. Цель учёта простая: зафиксировать сделку так, чтобы по ней не было споров, а смена закрывалась за пару минут.
Чаще всего ломается базовое: вес записали на бумажке, цену нашли в чате, выплату отметили в Excel, а акт распечатали "потом". В итоге одна и та же информация дублируется, цифры расходятся, и уже вечером непонятно, где правда - в тетради, в кассе или в файле.
Если вы делаете веб-приложение для приёмки металлолома, начните с минимального потока. Он нужен не ради скорости, а ради контроля: каждый шаг должен оставлять проверяемый след.
Каждый день пункт повторяет один и тот же набор операций: принять вес, посчитать сумму, выдать деньги, сформировать документ. Когда это разнесено по разным местам, ошибки становятся нормой: забыли удержание, перепутали сорт, не хватает денег в кассе.
Роли лучше разделить сразу, даже если сегодня работает один человек. На старте обычно хватает трёх: приёмщик фиксирует взвешивание и параметры сделки, кассир подтверждает выплату и ведёт кассу, администратор задаёт цены и справочники и смотрит отчёты.
Минимальный поток "взвесил → рассчитал → выплатил" стоит сделать первым и довести до привычки. Сценарий должен быть прямым: водитель привёз лом, приёмщик внёс вес и тип, система показала расчёт, кассир нажал "Выплатить", и сразу появились акт и запись в отчёте смены.
Чтобы касса работала быстро и без споров, в каждой сделке нужен одинаковый базовый набор полей. Чем меньше свободного текста и ручных расчётов, тем проще закрывать смену и находить ошибки.
Минимум, без которого учёт рассыпается: дата и время, клиент (хотя бы имя или телефон), вид лома, вес, цена за кг и итоговая сумма. Этого достаточно, чтобы пройти путь "взвесил → рассчитал → выплатил" и собрать сменный отчёт.
Часть полей нужна не всегда, но должна быть рядом: тара (если взвешивают в контейнере), засор (процент или кг), скидка/надбавка, комментарий. Важно хранить это отдельными полями, а не заметкой, чтобы отчёты считались автоматически.
Чтобы данные не расползались, заведите простые справочники: виды лома (с кодом и правилами, что к нему относится), цены (по виду и дате действия, иногда по точке), точки приёма (если их несколько) и сотрудники (кто оформил сделку и кто выдал деньги).
Ещё одна опора - нумерация. У сделки должен быть свой номер, у акта - свой, у кассовой операции "выплата" - свой. Тогда связь очевидна: сделка №1045 породила акт №A-1045 и выплату №K-778, и это видно сразу, без ручных сверок.
Быстрый поток должен работать как касса в магазине: минимум полей, максимум ясности. Очередь не ждёт, а тихие исправления потом превращаются в споры.
Логика простая: вы заводите сделку, фиксируете взвешивание, получаете расчёт и проводите выплату. Всё остальное (печать документов, отчёт по смене, контроль кассы) строится на этих шагах.
Для старта обычно хватает такого сценария:
Чтобы не было ситуации "подправили цифру и забыли", нужны статусы и журнал действий: кто изменил, что именно, когда и почему. Практично разделять "черновик" (можно править) и "закрыто" (нельзя, только корректировка).
Пример: клиент привёз медь. Вы внесли брутто 120 кг, тару 10 кг, нетто 110 кг, засор 2%. Нажали "Рассчитать" и сразу видите итог к выдаче и понятную строку расчёта. Она же попадёт в акт и в отчёт по смене.
Взвешивание - главный источник ошибок, поэтому в системе лучше заложить простые и предсказуемые режимы. Оператор должен видеть одно понятное число - сколько пойдёт в оплату (нетто). Остальное хранится как расчётные поля.
Обычно хватает трёх вариантов: фиксированный вес (одно значение), брутто и тара (с автоматическим нетто) и повторное взвешивание, если весы "прыгнули" или клиент просит перепроверить. Повтор не должен затирать историю: новая попытка создаёт новую запись, а итог выбирается явно.
Базовая формула: нетто = брутто - тара - засор. Засор удобно поддержать в двух форматах: процент от веса или фиксированные килограммы. Если задан процент, сначала считаем вес после тары, затем удерживаем засор:
Пример: брутто 520 кг, тара 40 кг, засор 3%. Вес после тары 480 кг, засор 14,4 кг, нетто 465,6 кг. Дальше задайте правило округления (например, до 0,1 кг или до 1 кг) и применяйте его везде одинаково.
Система должна ловить странные значения до сохранения. На практике помогают простые проверки: запрет нулей и отрицательных значений для брутто, тара не больше брутто, верхний порог веса (под ваши весы и типичные партии), единое правило округления и его отображение рядом с итогом.
И обязательно фиксируйте историю: кто и когда ввёл вес, кто менял, что именно изменилось и почему. Это снимает споры в конце смены.
Расчёт должен быть понятен кассиру и клиенту с первого взгляда: сколько приняли, по какой цене, что удержали и сколько выдали. Принцип простой: никакой магии и скрытых коэффициентов.
Цена обычно задаётся одним из сценариев. Лучше выбрать один как основной, а остальные оставить как исключения, иначе начнутся ручные правки и споры: фиксированная цена за кг по виду, цена по диапазону веса, цена по качеству (категория/сорт) или цена по точке приёма.
Формула должна быть одинаковой всегда и показываться и в акте, и на экране кассы. База: нетто × цена. Всё, что уменьшает выплату, показывайте отдельными строками: удержания, корректировки, штрафы, округление.
Пример, как это выглядит:
Нетто: 120 кг Цена: 32 ₽/кг Сумма по весу: 3 840 ₽ Удержание за засор: -150 ₽ Корректировка (например, пересорт): -90 ₽ Итого к выплате: 3 600 ₽
На экране кассы достаточно показывать нетто, цену, промежуточную сумму, список удержаний с причинами и финальную выплату. Если удержаний нет, так и пишите: "Удержаний нет".
Изменение цены допускайте только до выплаты и только с причиной (например, "обновили прайс", "уточнили сорт после осмотра"). После статуса "выплачено" цена и удержания должны быть заблокированы, а правки оформляться отдельной корректировкой с ответственным.
Документы нужны не ради бумажек, а чтобы закрывать спорные ситуации и сводить смену без ручных пересчётов. Поэтому лучше, когда система формирует их сразу после расчёта, из тех же данных, по которым вы делали выплату.
Чаще всего хватает трёх форм: акт приёмки, ведомость выплат за смену и короткая квитанция для клиента. Даже если печать не всегда нужна, документ должен быть доступен для просмотра и повторного вывода.
В акте стоит генерировать минимум реквизитов: стороны, дата и время, вид металла, брутто/тара/нетто, засор (если применяется), цена, удержания, итоговая сумма, способ выплаты и место для подписей (или отметка о подписи).
Чтобы на всех точках всё выглядело одинаково, используйте единые шаблоны: одинаковые названия полей, порядок строк, формат чисел и округления, нумерацию документов (например, по точке и смене).
По хранению важно не только сохранить PDF, но и понимать состояние: черновик (до выплаты), сформирован, выдан, аннулирован и пересоздан. У документа должна быть версия и автор: кто сформировал, кто перепечатал, кто отменил. Если позже нашли ошибку, система аннулирует старую версию, выпускает новую и не даёт подменить историю.
Выплата - самый рискованный момент сделки: деньги уходят сразу, а ошибки потом трудно доказать. Поэтому важно разделить расчёт и выплату, а кассу вести как отдельный источник правды.
У каждой сделки должен быть понятный статус, видимый и приёмщику, и кассиру. Меняйте статус только через явные действия (кнопки) и оставляйте след в журнале.
Обычно хватает состояний: "к выплате" (сумма зафиксирована), "выплачено" (со способом и временем), "отменено" (ошибка/дубль) и "возврат" (деньги вернули в кассу по причине спора или ошибки).
Чаще всего нужны наличные и перевод на карту, иногда - смешанная выплата. Главное, чтобы сумма по способам сходилась с итогом сделки и попадала в кассовые движения.
Перед подтверждением выдачи система должна проверять остаток. Если выбран вариант "наличные" и остаток уходит в минус, выплата блокируется и показывается, сколько не хватает и что можно сделать (сменить способ, внести размен, перенести выдачу).
Пример: рассчитали 18 450 ₽. В кассе 12 000 ₽. Кассир выбирает смешанную выплату: 12 000 наличными и 6 450 переводом. Сделка уходит в "выплачено", а наличный остаток становится ноль.
Чтобы потом не спорить "кто выдавал", нужен журнал операций: кто нажал "выплатить", когда, на какую сумму, каким способом и по какой сделке.
Отчёт по смене нужен, чтобы за 3-5 минут понять: смена закрыта честно, касса сходится, сюрпризов утром не будет. Сделайте его обязательным экраном для приёмщика и администратора.
В базовой версии достаточно нескольких показателей, но они должны считаться одинаково всегда: количество сделок за смену, общий вес (лучше показывать и брутто, и нетто), сумма выплат клиентам, средняя цена за кг (по нетто) и кассовый итог (приход/расход).
Дальше добавьте разрезы, которые отвечают на самые частые вопросы без ручных фильтров: по виду лома, по сотруднику и по точке.
Главная вечерняя проверка - сверка сделок и кассы. Каждой выплате по сделке должна соответствовать кассовая операция. Если есть "сделки без выплаты" или "выплаты без сделки", это должно быть видно отдельными строками с суммой расхождения.
Для бухгалтера полезна выгрузка, где каждая сделка - одна строка: дата и время, номер смены и сделки, точка, сотрудник, вид лома, брутто/тара/нетто, цена, удержания, итог к выплате, способ выплаты, номер кассовой операции и статус.
Даже простая система чаще ломается не от сложной логики, а от мелочей: кто может править сделки, как считаются единицы и где видно, что деньги реально выданы.
Самая дорогая ошибка - тихие правки. Если кто-то может изменить уже выплаченную сделку без следа, вы теряете доверие и контроль. Решение прямое: после выплаты сделка только для чтения, а любые изменения идут отдельной операцией (сторно/корректировка) с автором, временем и причиной.
Вторая проблема - смешивание ролей. Когда один человек одновременно приёмщик, кассир и админ, всегда появляется соблазн "подправить" цену, вес или статус. Разделите права хотя бы минимально: приёмщик заводит и взвешивает, кассир подтверждает выплату, админ настраивает справочники и видит отчёты, но не переписывает историю.
Третья зона риска - единицы измерения и округления. Ошибка "тонны вместо кг" выглядит как лишний ноль и сразу превращается в крупную выплату. Помогают подсказки в полях (кг), ограничения на диапазон и явное правило округления.
Ещё одна боль - акт отдельно, деньги отдельно. Бывает, акт сформирован, а выплата не проведена, или деньги выдали, но документ не создан. Лечится связкой "документ + выплата" в одной сделке и проверкой: закрыть смену нельзя, пока есть несоответствия.
Хорошее веб-приложение для приёмки металлолома помогает не помнить правила, а просто идти по шагам и не пропускать важное.
Перед тем как нажать "Выплатить", проверьте четыре вещи: нетто подтверждено (видно брутто, тару и итог), категория и цена выбраны верно (единицы и актуальный прайс), сумма читается (вес x цена, удержания и округления отдельными строками), реквизиты заполнены (кто принял, кто сдал, время, точка, комментарий при нестандартной ситуации).
После выплаты убедитесь, что статус стал "выплачено", акт сформирован автоматически, а остаток кассы уменьшился ровно на сумму выплаты.
В конце смены контроль простой: нет незакрытых сделок (ни черновиков, ни "ожидает выплаты"), отчёт по смене сходится с кассой, возвраты и исправления видны отдельными строками.
Утро, 10:15. В пункт заезжает клиент с ломом. У него металлическая тара (контейнер), в партии есть засор (пластик и грязь). Плюс цена на этот вид лома уже менялась: до 10:00 было 28 ₽/кг, после 10:00 - 29 ₽/кг.
Приёмщик нажимает "Новая сделка". Полей минимум: клиент (можно "разовый"), вид лома, комментарий. Дальше идёт по потоку: взвешивание, расчёт, выплата.
На экране остаются 3-4 действия: "Взвесить брутто", "Взвесить тару", "Рассчитать", "Выплатить".
В 10:16 фиксируется брутто: 1 240 кг. Затем тара: 180 кг. Система считает нетто 1 060 кг. Приёмщик вводит засор 3%, и оплачиваемый вес становится 1 028,2 кг. Цена подставляется по времени сделки (10:16), значит 29 ₽/кг. Итог: 29 817,8 ₽, дальше применяется выбранное правило округления (например, до рублей).
После формирования акта приёмщик проводит выплату (наличные, перевод или смешанный вариант), сделка получает статус "оплачено", а остаток кассы уменьшается сразу.
В конце смены отчёт показывает количество сделок, общий оплачиваемый вес, сумму выплат, возвраты (если были) и остаток кассы. Расхождения обычно видны там же: например, забыли ввести тару или выбрали неверный вид лома, и всплывает необычно высокий вес или сумма.
Сформулируйте задачу одной строкой: нужно веб-приложение для приёмки металлолома, где касса проводит сделку, формируются акты, а в конце смены есть понятный отчёт. Затем выпишите поля, без которых сделка не имеет смысла: кто принял, что приняли, вес, цена, удержания, сумма к выплате, способ выплаты и номер документа.
Дальше быстрее всего собрать прототип двух экранов - "Касса" и "Отчёт смены". На нём сразу видно, где нужны проверки и статусы: нельзя выплатить без сохранённого взвешивания, нельзя закрыть смену при отрицательном остатке, нельзя менять цену задним числом без отметки и причины.
Права лучше продумать заранее: приёмщик создаёт сделку и фиксирует взвешивание, кассир проводит выплату, администратор управляет ценами и справочниками и оформляет корректировки, руководитель смотрит отчёты и сверки.
Если нужно быстро собрать первый рабочий вариант, такой поток удобно описать обычным текстом и прототипировать в TakProsto (takprosto.ai) через чат. Платформа ориентирована на создание приложений из диалога и помогает быстрее перейти от сценария и полей к рабочим экранам кассы и сменным отчётам.
Дальше закладывайте рост: экспорт исходников, деплой и хостинг, отдельный домен, а также снимки и откат, когда меняете формулу расчёта или добавляете новый документ. Начните с пилота на одной точке на 2-3 смены, соберите замечания и только потом раскатывайте на остальные пункты.
Начните с потока «взвесил → рассчитал → выплатил» и доведите его до состояния, когда сделка оформляется за 1–2 минуты. Если этот путь работает без ручных записей и правок «потом», всё остальное (документы, отчёты, контроль кассы) добавляется без боли.
Минимум: дата и время, клиент (хотя бы имя или телефон), вид лома, вес, цена за кг и итоговая сумма. Чтобы избежать спорных случаев, держите рядом отдельными полями тару, засор, скидку/надбавку и комментарий, а не прячьте это в свободный текст.
Лучше сразу ввести раздельные роли, даже если сейчас работает один человек: приёмщик фиксирует взвешивание и параметры сделки, кассир подтверждает выплату и ведёт кассу, администратор управляет ценами и справочниками и смотрит отчёты. Это снижает риск «тихих правок» и двойных выплат.
Держите правило: нетто = брутто − тара − засор. Засор удобнее поддержать и в процентах, и в килограммах, а округление зафиксировать одно и применять везде одинаково, чтобы цифры совпадали на экране, в акте и в отчёте смены.
Сделайте простые ограничения до сохранения: брутто не может быть нулём или отрицательным, тара не больше брутто, у веса есть разумный верхний предел под ваши весы. И обязательно показывайте, как сработало округление, чтобы оператор видел, почему итог отличается на копейки или на килограммы.
По умолчанию держите одну понятную формулу: сумма = нетто × цена, а всё, что уменьшает выплату, показывайте отдельными строками с причиной (удержание, корректировка, округление). Так кассиру проще объяснить результат, и меньше соблазна «подправить цифру вручную».
Разрешайте менять цену только до выплаты и только с причиной, которую видно в журнале действий. После статуса «выплачено» цена и удержания должны быть заблокированы, а любые изменения оформляйте через отдельную корректировку, чтобы история не переписывалась.
Автоматизируйте минимум: акт приёмки, ведомость выплат за смену и квитанцию для клиента (даже если печать не всегда нужна). Важно, чтобы документы формировались из тех же данных, по которым вы выдали деньги, и имели статус и версию, а не «перегенерировались тихо».
Разведите «расчёт» и «выдачу денег» по статусам: «к выплате», «выплачено», «отменено», «возврат». Перед подтверждением наличной выплаты проверяйте остаток кассы и блокируйте операцию при минусе, предлагая понятные варианты (сменить способ, сделать смешанную выплату, внести размен).
В сменном отчёте достаточно нескольких вещей: число сделок, брутто и нетто, сумма выплат, средняя цена за кг (по нетто), кассовый итог. Отдельно показывайте «сделки без выплаты» и «выплаты без сделки», потому что именно эти несоответствия чаще всего ломают закрытие смены.
