Веб-приложение для центра переработки отходов: как свести процесс к заявке и акту, добавить статусы логистики и собрать отчеты по типам отходов.
У центра переработки почти всегда одна и та же боль: процесс выглядит простым (принять заявку, вывезти, взвесить, оформить документы), но в реальности расползается по звонкам, чатам и таблицам. В итоге сложно быстро ответить клиенту: когда приедут, что вывезли, сколько приняли, где акт и почему цифры в отчете не сходятся.
Обычно «тонут» мелочи, которые потом превращаются в разборы: у заявки нет единого номера, водитель присылает фото весов в мессенджер, диспетчер перепечатывает данные вручную, бухгалтерия ищет подтверждения по папкам, а отчет по типам отходов собирается раз в месяц и с ошибками.
Чтобы это не превращалось в бесконечные уточнения, полезно свести первую версию системы к двум опорам: один документ на договоренность и один документ на факт.
Все остальное - статусы, маршруты, фото, комментарии - должно «приклеиваться» к этим двум сущностям, а не жить отдельно.
В первом контуре обычно достаточно закрыть четыре вещи: вывоз (план и факт), приемку (вес и классификация), статусы логистики (чтобы всем было ясно, что происходит), и отчеты (чтобы руководство видело объемы по типам отходов без ручной сборки).
Роли, которые должны работать в системе без лишних полей и кнопок:
Начните с двух сущностей: Заявка на вывоз и подтверждающий Акт. Эта связка уже дает контроль и порядок, а логистику, отчеты и интеграции можно нарастить позже.
Заявка отвечает на вопрос: что и откуда нужно забрать. Акт - что фактически приняли и на каких условиях. Сразу заложите связь: 1 заявка - 1 или несколько актов (частичные вывозы, корректировки после взвешивания).
Минимальный набор обязательных полей в заявке держите коротким:
Чтобы не путаться в адресах и контактах, храните их не одной строкой, а как справочники, привязанные к клиенту. У одного юрлица может быть несколько площадок, и на каждой - свой ответственный. Тогда в заявке вы выбираете клиента, затем адрес, затем контакт. При смене персонала обновляете карточку контакта, а не правите старые заявки.
В акте фиксируйте факт: номер и дату, кто принял, чем подтвердили (подпись, печать, фото как файл), и фактические значения по каждой позиции.
По отходам на старте достаточно хранить: тип (из справочника), вес (план и факт), тару (мешки, биг-бэг, контейнер), класс/категорию (если требуется), и короткое примечание (например, «мокрое», «смешано»).
Пример: клиент привозит ПЭТ и картон. В заявке стоит 300 кг ПЭТ и 200 кг картона, по весам выходит 280 и 215. Эти цифры попадают в акт и дальше становятся основой отчета без ручных правок.
Чтобы заявки не превращались в переписку, разделите два уровня: статус заявки и статус логистики. Заявка может быть юридически подтверждена, но машина еще не выехала.
Статус заявки лучше оставить «документным». Обычно хватает цепочки: создана (запрос пришел), подтверждена (согласованы дата и условия), на площадке (факт прибытия подтвержден), закрыта (есть акт и итоговые веса).
Статусы логистики нужны для операционного контроля. Их удобно вести как отдельную шкалу внутри заявки: назначен водитель, выезд, прибытие, погрузка, завершено. Эти отметки отвечают на вопрос «где машина и что происходит сейчас», но не заменяют документы.
Чтобы не было путаницы, заранее закрепите права на изменения:
История статусов должна помогать разбирать спорные ситуации. Минимум фиксируйте: время изменения и автора, старый и новый статус, комментарий (например, причина задержки), привязку к документу или событию (например, номер акта).
Пример: водитель отметил «выезд» и «прибытие», приемка поставила «на площадке», после взвешивания менеджер закрыл заявку актом. Если клиент спорит о времени простоя, вы поднимаете историю и видите факты.
Нужен один понятный маршрут данных: от заявки до закрывающего акта. Тогда статусы, отчеты и контроль расхождений ложатся поверх и не ломают учет.
Создание заявки. Ее заводит клиент, менеджер или оператор: что вывозим, адрес, контакт, желаемая дата, объем, особые условия (контейнер, погрузка, пропуск).
Подтверждение условий. Менеджер фиксирует договоренности: окно времени, тариф, кто отвечает на месте, какие документы нужны. Полезен короткий комментарий: что обязательно проверить на приемке.
Назначение транспорта. Диспетчер выбирает машину и водителя, добавляет маршрут и плановое время прибытия. Если перевозка через подрядчика, достаточно поля «исполнитель» и номера машины.
Приемка и акт. На площадке приемка отмечает факт приезда, взвешивание, итоговую массу, типы отходов и замечания. На основе этих данных формируется акт.
Закрытие заявки. После подписания акта заявка уходит в «закрыто», а цифры попадают в отчеты: сколько вывезли, по каким типам, по каким клиентам и машинам.
Пример: клиент заказал вывоз картона и пленки. Менеджер подтвердил окно 10:00-12:00, диспетчер назначил машину. На приемке оказалось, что пленки больше, чем ожидали - это фиксируется в акте и в разрезе типов отходов, без ручных корректировок в конце месяца.
Короткое правило для первой версии: без акта заявка не считается закрытой.
Разделите данные на две группы: поля документов (заявка и акт) и справочники (то, что переиспользуется много раз). Документы меняются каждый вывоз, а справочники должны жить годами.
С клиентами чаще всего ошибаются из-за адресов и договоров. Одному юрлицу могут соответствовать несколько площадок и контактных лиц. Поэтому держите отдельно:
По вывозу не пытайтесь сразу учесть все. На старте достаточно: дата, окно времени, тип транспорта, комментарий, а также «кто создал» и «кто подтверждает». Тип транспорта лучше вынести в справочник, чтобы в отчетах не было десяти вариантов написания одного и того же.
Номенклатуру отходов тоже делайте справочником. Для каждого типа задайте единицу измерения, при необходимости коэффициент пересчета (например, мешки в кг) и признак «нужно фото». Масса в заявке обычно плановая, а в акте - фактическая, и это важно разделять.
В акте храните фактическую массу по позициям, причину расхождения (справочник причин), ответственных и фиксацию подписи: ФИО, роль, дата и способ (подпись на месте, электронное подтверждение).
Проверка, что базу не придется переделывать через месяц:
Отчеты должны отвечать на вопросы руководителя и бухгалтера за полминуты: что приняли, у кого, сколько рейсов было, где теряем время и где цифры не сходятся.
Начните с отчета по типам отходов за период. В нем обычно достаточно трех метрик: общий вес, количество рейсов и доля каждого типа в общем объеме. Это помогает видеть сезонность и загрузку площадки.
Дальше добавьте два операционных среза:
Главная проверка простая: акт подтверждает заявку, а расхождения видны и объяснимы. Сделайте экран «Сверка» за период, где в строке показаны заявка, акт, разница и причина.
Чтобы контроль не превратился в ручную охоту за ошибками, хватит нескольких правил:
Пример: в заявке «пластик 500 кг», по факту в акте «пластик 460 кг, пленка 30 кг». В отчете это должно выглядеть как понятное уточнение состава и разницы по весу, а не как «ошибка системы».
Экспорт для бухгалтерии держите простым: одна таблица по актам за период (дата, клиент, договор, типы, веса, сумма при необходимости). Пользователю достаточно кнопки «Выгрузить», а формат настраивается один раз.
Системы быстро становятся неудобными, когда все видят все. Люди ищут нужное среди лишних полей, путаются в статусах и распечатывают не те документы. Надежнее сделать интерфейс по ролям: каждому - свой короткий экран и понятные действия.
Оператору важны скорость и точность на площадке. Ему не нужен календарь рейсов и чужие заявки. В карточке должны быть текущая заявка, ожидаемые позиции, место разгрузки и короткие подсказки.
Две ключевые операции: зафиксировать факт (вес и примечание) и сформировать акт.
Диспетчеру нужен обзор: какие выезды запланированы, где риски опоздания, какие заявки без машины. Здесь же удобно менять статус логистики и оставлять служебные комментарии.
Рабочее правило: диспетчер видит все заявки, но не редактирует «факт приемки». Тогда меньше споров о том, кто подтвердил данные.
Водителю нужен один простой экран: адрес, контакт, окно времени, что забрать, кнопки статусов и поле для короткого комментария («не дозвонился», «пробка», «нужен пропуск»). Чем меньше шагов, тем чаще статусы будут обновляться вовремя.
Клиенту достаточно создать заявку, видеть статус и получить акт. В личном кабинете оставьте минимум: список заявок, текущий статус, дата и итоговый документ. Полезная мелочь - «повторить как в прошлый раз».
Самая частая ошибка - пытаться построить полный документооборот с первого дня. Для центра переработки обычно хватает цепочки «заявка на вывоз - подтверждающий акт». Если начать с десятков форм и «особых случаев», сотрудники быстро вернутся к Excel и мессенджерам.
Вторая ловушка - путать статусы. Логистика отвечает на вопрос «где машина и что с вывозом», бухгалтерия - «что проведено и оплачено». Если смешать это в одну шкалу, получится каша: «оплачено» внезапно означает «выехали», а «закрыто» - «ждем оригиналы». Разведите статусы по смыслу.
Чтобы учет не превратился в спор «кто и когда поменял цифры», заложите дисциплину:
Отдельная боль - свободное редактирование. Если всем разрешить править вес и тип отхода в любой момент, отчеты начнут расходиться с актами. Лучше: после подписи акта поля блокируются, а исправления идут через корректировку с причиной.
Перед запуском убедитесь, что у вас есть один понятный «источник правды». Обычно это связка «заявка на вывоз - подтверждающий акт». У каждой заявки должен быть максимум один актуальный акт, а у каждого акта - одна исходная заявка. Если возможны корректировки, фиксируйте их как новую версию акта, а не как «еще один акт».
Проверьте, что поля заявки закрывают 90% случаев без лишних таблиц: контрагент, адрес, дата/окно, типы отходов, плановый вес/объем, ответственное лицо, комментарий.
Со статусами логистики держите дисциплину: конечный набор, без дублей, и один статус отвечает на один вопрос «что сейчас происходит».
Короткий чек-лист:
Права ролей лучше проверить на реальном сценарии: диспетчер создает заявку, логистика меняет статусы, приемка подтверждает акт, бухгалтер закрывает период. Это быстро выявляет лишние доступы и «серые зоны».
Типовой запрос: клиент просит вывезти картон и пленку с двух точек. Менеджер заводит одну заявку, в ней две позиции, плановая дата и окно времени, адреса, контакт на месте и ожидаемый вес.
В день вывоза клиент пишет, что на первой точке будут готовы позже. Диспетчер не создает новую заявку, а меняет плановое окно и фиксирует перенос с комментарием. Это видно водителю и приемке, а в истории остается: кто поменял, когда и почему.
Дальше логистика живет короткими статусами: «Машина назначена», «В пути», «На точке», «Забрали», «Взвешивание», «Закрыто». Комментарий обязателен только для спорных случаев: перенос, отказ, частичный вывоз.
На приемке фиксируют фактический вес. Оказалось, что картона больше, а пленки меньше, чем ожидали. Приемщик вводит фактические цифры и формирует акт. Система показывает расхождение и просит выбрать причину: «пересорт», «упаковка/влага», «оценка клиента», «часть не готова». Так появляется статистика причин, а не разовые объяснения.
В отчете за неделю видно: по пленке объем вырос, но почти все вывозы с недоборами. Это сигнал, что пленку лучше планировать отдельным рейсом или подтверждать готовность за сутки.
Через неделю использования обычно просят несколько доработок: шаблоны заявок для постоянных клиентов, быстрый чек-лист приемки (фото, примечание, причина расхождения), напоминание диспетчеру, если статус «В пути» не менялся слишком долго.
Начните не с «идеальной системы», а с короткого набора правил: что считаем заявкой, что считаем подтверждающим актом, и где появляется расхождение. Остальное добавите по ходу.
Соберите требования максимально конкретно: какие поля заполняем и кто это делает. Удобно сразу разделить на три блока: заявка, акт, и то, что должно получаться в отчетах.
Заранее решите, что будете добавлять уже после запуска: новые статусы, роли, формулировки в отчетах, новые типы отходов.
Первую версию можно собрать в TakProsto (takprosto.ai): задать сущности «Заявка» и «Акт», добавить статусы и базовые отчеты, а затем расширять систему по фактическим запросам команды. Для многих это еще и вопрос данных: платформа работает на серверах в России и не отправляет данные в другие страны.
Перед стартом пилота проверьте минимум:
Начните с двух документов: «Заявка» как договоренность и «Акт» как факт. В заявке храните план (что, откуда, когда, на каких условиях), в акте — итог (что приняли, сколько по весам, кем подтверждено). Остальные функции добавляйте только после того, как эта связка стабильно работает в смене.
Держите обязательные поля короткими: клиент, адрес площадки, контакты, плановая дата и окно времени, позиции отходов с плановым весом и коротким комментарием по доступу. Все, что «может быть когда-нибудь», лучше не делать обязательным, иначе люди начнут обходить систему. Детали вроде маршрута и фото можно добавлять как вложения и комментарии.
Заявка отвечает за план и договоренности, акт — за фактические данные после взвешивания и приемки. Если смешать их, вы начнете править «план» задним числом, а отчеты будут постоянно спорить с документами. Простое правило: отчетность и сверка строятся по актам, а не по заявкам.
Сделайте два уровня: документный статус заявки и операционные статусы логистики внутри нее. Статус заявки должен отвечать на вопрос «есть ли подтвержденная договоренность и закрыта ли она актом», а логистика — «где машина и что происходит сейчас». Тогда бухгалтерия и диспетчер не тянут шкалу статусов в разные стороны.
Разведите права по смыслу. Менеджер подтверждает условия и может отменить ошибочную заявку, диспетчер назначает машину и ведет логистические статусы, водитель отмечает только этапы поездки и пишет комментарий по факту, приемка фиксирует вес и формирует акт. После подписания акта критичные поля лучше блокировать, а исправления делать через корректировку с причиной.
Делайте «1 заявка — 1 или несколько актов» для частичных вывозов и уточнений после взвешивания. При этом держите понятное правило: у заявки должен быть один актуальный итоговый акт, а предыдущие версии остаются в истории. Так вы не потеряете факт и не запутаете отчетность.
Вынесите в справочники клиентов, адреса площадок и контакты, а также номенклатуру отходов и единицы измерения. Тогда в заявке вы выбираете готовые сущности, а не пишете все вручную, и у вас не появится десять вариантов одного и того же адреса. Это также упрощает отчеты и поиск по истории.
Сначала сделайте отчет по типам отходов за период на основе актов: он дает понятный объем и структуру. Затем добавьте экран сверки «заявка vs акт», где видно разницу и выбранную причину расхождения. Это быстро убирает споры и помогает находить повторяющиеся проблемы вроде пересорта или постоянных недовесов.
Обычно проблема в том, что вес и типы отходов правят задним числом без следа, а подтверждения лежат в мессенджерах. Решение — история изменений и правило, что «закрыто» возможно только при наличии акта или явной причины, почему его нет. Фото весов и подписи лучше хранить как файлы, привязанные к акту, чтобы они не терялись.
Сформулируйте в чате, какие сущности нужны (заявка, акт, справочники), какие статусы и роли, и какие отчеты должны сходиться с актами. Для пилота достаточно одного маршрута и одной смены: вы быстро увидите, какие поля лишние, а каких не хватает. В TakProsto удобно начать с базовой схемы и наращивать ее по реальным запросам команды, не превращая запуск в большой проект.
