Разберем, как спроектировать веб-приложение для закупки запчастей: справочник аналогов, история цен, сроки поставки, заявки и таблицы сравнения.
Когда запчасть нужна срочно, чаще всего ломается не логистика, а поиск информации: где взять нужную позицию, чем ее заменить, почему у одного поставщика цена в два раза выше, и что на практике значит «доставка 3-5 дней».
В закупках участвуют разные роли, и у каждой своя боль. Снабжению нужно быстро собрать предложения и не ошибиться с выбором. Сервису важно, чтобы аналог действительно подошел и машина не вернулась в ремонт. Склад смотрит остатки и совместимость с тем, что уже лежит. Руководителю нужен контроль: почему выбрали именно этого поставщика и как менялась цена.
По сути приложение для закупки запчастей помогает принимать несколько простых, но дорогих решений: что купить (оригинал или замену), у кого купить, когда заказывать и какую цену считать разумной с учетом сроков и рисков.
Живой пример: мастер просит «ремень 6PK, как в прошлый раз». В переписке находится старый артикул, потом еще три «почти таких же». В итоге заказывают «похожий», он не подходит по длине, а неделя уходит на возвраты. Когда справочник аналогов и история закупок находятся в одном месте, такие промахи случаются заметно реже.
Чтобы система начала приносить пользу, с первого дня достаточно минимального набора данных: карточка запчасти (артикулы, описание, применяемость, единицы измерения), связи аналогов с пояснениями и ограничениями, поставщики и их предложения (цена, валюта, наличие, срок, условия), заявки (инициатор, приоритет, объект ремонта, нужная дата, статус) и фактический итог (что купили, за сколько, сколько шло, были ли возвраты).
Рейтинги поставщиков, рекомендации и интеграции лучше добавлять позже, когда станет понятно, где именно теряются деньги и время.
Чтобы приложение не превратилось в «табличку на тысячу строк», разделите справочник (что покупаем) и операционную часть (как покупаем). Тогда аналоги, цены и сроки будут жить в понятной структуре.
В простом варианте достаточно пяти объектов: запчасть (позиция каталога), артикул (конкретный код из разных источников), производитель, поставщик и предложение (цена и условия от поставщика).
Заявку лучше хранить отдельной сущностью, но связывать ее со строками предложений: «что хотим купить» и «какое предложение выбрали». Так сохраняется история выбора, даже если позже цены поменяются.
Одна запчасть часто имеет несколько артикулов: оригинал, внутренний код, коды разных каталогов. Удобная модель здесь простая: одна запчасть - много артикулов.
Аналоги (кроссы) лучше хранить как связи между запчастями. Тогда вы сравниваете именно позиции, а не случайные совпадения по строке. Например, «Фильтр масляный для X» - это запчасть. У нее есть артикулы производителя и артикулы поставщиков. Аналоги - другие запчасти с отметкой типа замены (полный или условный) и уровнем доверия.
Чтобы предложения можно было честно сравнивать, заранее договоритесь о минимуме обязательных полей: единица измерения (шт, комплект, м), валюта и цена, НДС/без НДС, минимальная партия (MOQ), срок поставки (обещанный).
Для заявок достаточно простых статусов: черновик, на согласовании, отправлено, подтверждено, закрыто. В интерфейсе их лучше показывать как шаги - так сразу видно, где застряло.
По ролям не усложняйте. Обычно хватает трех: снабженец ведет заявку и собирает предложения, согласующий утверждает, админ управляет справочниками и правами. Если собираете MVP в TakProsto, эти роли удобно сразу заложить в доступ к экранам и действиям, без сложных регламентов.
Справочник аналогов нужен не для «похожих» позиций, а для управляемой замены, которой можно доверять. Это означает одно: вы заранее фиксируете, что считается заменой, при каких условиях, и кто за это отвечает. Тогда выбор не превращается в спор в чате.
Начните с понятных типов:
Карточка аналога должна объяснять, почему замена допустима. Хороший минимум: тип аналога, источник (каталог производителя, опыт эксплуатации, сервис), комментарий простыми словами (что совпадает и что может отличаться), ограничения (температура, среда, напряжение, бренд, серия, ревизия), уровень доверия и дата проверки.
Важно правильно хранить связи. На практике почти всегда это «многие ко многим»: один оригинал имеет несколько кроссов, и один кросс подходит к нескольким оригиналам. Также полезно хранить направление: замена A на B не всегда равна замене B на A.
Поиск делайте не только по артикулу. Люди часто приходят с названием, производителем или параметром (диаметр, резьба, материал). Это экономит минуты на каждом запросе.
Чтобы аналоги не превращались в свалку, зафиксируйте способ подтверждения: либо правило (например, «совпадает серия и параметр X»), либо ручная валидация ответственным. Для подшипника, например, «допустимый аналог» можно разрешать только при совпадении класса точности и температурного диапазона. Иначе ставить «условный» и требовать согласование.
Чтобы аналоги не превращались в лотерею, нужны понятные правила. Их лучше заложить в систему сразу: тогда выбор будет одинаковым у разных сотрудников, а спорные случаи проще разбирать.
Держите короткий набор критериев, которые реально влияют на итог: совместимость (размеры, посадочные места, разъемы, допуски, материал), качество (бренд, сертификаты, опыт эксплуатации), условия возврата, доступность (наличие, MOQ, стабильность поставок), цена и срок (включая доставку и реальный дедлайн).
Вес критериев меняется по ситуации. Если оборудование стоит и простой дорогой, срок и наличие важнее цены. Если закупка плановая и есть запас, можно сильнее учитывать цену. Удобно, когда в интерфейсе есть режимы вроде «срочно» и «планово» с заранее заданными весами.
Правила должны учитывать ограничения бизнеса: «только оригинал» для критичных узлов, «только одобренные бренды» для гарантийной техники, запрет на восстановленные детали. Такие фильтры лучше делать жесткими, чтобы система не предлагала то, что все равно нельзя купить.
Для оценки используйте простую шкалу 1-5 или «светофор». Например, совместимость и качество должны быть не ниже 4, иначе вариант не допускается к выбору.
Пример: нужна помпа для производственной линии. Два аналога дешевле, но у одного нет подтвержденной совместимости по материалу уплотнений, у второго срок 14 дней. Если линия простаивает, система должна поднимать вариант «в наличии завтра» даже при более высокой цене - и показывать, почему это решение считается лучшим.
Чтобы не было споров, фиксируйте причину выбора: выбранный режим («срочно/планово»), итоговый балл и пороги допуска, какие параметры совпали по совместимости, источник уверенности (документ, опыт, комментарий инженера), кто и когда утвердил.
История цен нужна, чтобы отвечать на один вопрос: цена нормальная или нас «качает» рынок (или конкретный поставщик). В закупке запчастей это особенно важно, потому что у одной позиции бывают десятки аналогов и разные условия поставки.
Есть два рабочих подхода.
Первый - хранить снимки предложений: вы сохраняете все, что поставщик прислал (или что менеджер ввел), целиком на дату. Это удобно для аудита.
Второй - хранить ценовые события: каждая запись - факт фиксации или изменения цены. Это проще для графиков и сигналов и обычно меньше раздувает базу.
Часто используют гибрид: событие цены со ссылкой на исходный снимок предложения.
Минимальный набор: цена и валюта, дата фиксации, срок действия, источник (прайс, письмо, портал, ручной ввод), условия (НДС, доставка включена или нет), срок поставки, объем (если цена зависит от количества). Также важно хранить единицу измерения и упаковку (шт/уп), иначе сравнение будет обманывать.
Отдельно различайте прайс и предложение под конкретную заявку. Прайс - ориентир, часто без гарантий наличия и сроков. Предложение под заявку - обещание на конкретный объем и дату, обычно с ограниченным сроком действия. В карточке цены это удобно обозначать типом записи и связью с заявкой.
Пользователям чаще нужен список с фильтрами (поставщик, период, валюта) и короткими заметками. График хорошо работает как быстрый сигнал «почему стало дороже», поэтому его можно оставлять по кнопке.
Для контроля добавьте простые сигналы: резкий рост относительно среднего за 30-90 дней, подозрительно низкая цена (ниже медианы), устаревшая цена (просрочен срок действия), цена без ключевых условий (не указан НДС или доставка), расхождение прайса и предложения под заявку.
Сроки поставки в закупках часто звучат уверенно только в письме. Поэтому в карточке предложения лучше хранить не одно поле «срок, дней», а разложить срок на части и добавить признак надежности. Тогда система помогает выбирать не «самое быстрое обещание», а вариант, который реально приезжает вовремя.
В предложении поставщика фиксируйте обещанную дату отгрузки, срок доставки, общий срок (в днях) и уверенность (шкала 1-5 или процент).
Рядом держите два признака по наличию: «есть на складе» и «подтверждено». Наличие без подтверждения часто означает «есть в прайсе», а не «готово к отгрузке». Отдельная галка «подтверждено поставщиком» снижает сюрпризы.
После закрытия заказа запишите фактические даты: реальная отгрузка и реальное поступление. Это основа для будущих решений: вы увидите, кто стабильно выполняет обещания, а кто регулярно приезжает с «плюс 5 дней».
Причины задержек лучше фиксировать короткими категориями: логистика, производство, документы, склад (не подтвердилось наличие), другое.
Правило выбора простое: смотрите не только обещанный минимум, но и надежность. Если поставщик А обещает 3 дня, но 6 из 10 раз привозит за 7, а поставщик Б обещает 5 и почти всегда укладывается, для критичных позиций выгоднее Б.
Заявка на закупку должна быть короткой карточкой, которая ведет команду от потребности до приемки. Чем меньше ручных переписок и пересылок таблиц, тем быстрее приходит деталь и тем проще объяснить, почему выбрали именно этого поставщика.
Практичный процесс обычно укладывается в несколько шагов: создание заявки (что нужно и к какому сроку), согласование, сбор предложений, выбор победителя с фиксацией причины, заказ и контроль статуса, приемка и закрытие.
В карточке заявки держите только то, что помогает принять решение: объект или техника (куда ставим), количество, дедлайн, приоритет, короткий комментарий (например, «нужен полный комплект прокладок»). Заявку полезно сразу связывать с позицией из справочника и выбранным аналогом, чтобы все участники видели один и тот же вариант.
Дальше важна связка «заявка - предложения». Каждое КП поставщика должно быть отдельной строкой с ценой, сроком, условиями оплаты, гарантией и примечанием. После выбора система помечает победителя и сохраняет причину: «быстрее на 3 дня» или «дешевле при том же производителе».
Уведомления делайте внутри системы и строго по шагам: инициатору - что заявку взяли в работу, согласующему - что ждет подтверждения, закупщику - что пришли новые КП, складу - что ожидается приемка. И не забудьте журнал изменений. Минимально полезные события: изменили количество, сдвинули дедлайн, обновили цену в выбранном предложении, поменяли выбранный аналог, закрыли заявку с результатом приемки.
MVP нужен, чтобы за 1-2 недели проверить один сценарий от поиска до согласования: снабженцу удобно искать по артикулу, сравнивать предложения и оформлять заявку.
На старте часто достаточно двух ролей: снабженец и согласующий. В первом приближении может хватить одного рабочего экрана: поиск запчасти, блок аналогов, таблица предложений, кнопка «Создать заявку» и поле комментария. Для согласующего - список заявок и действия «одобрить» или «вернуть с комментарием». Обоим пригодится просмотр истории изменений.
Сначала зафиксируйте структуру данных и правила. Базовые сущности: запчасть, аналог (с типом замены и примечанием), предложение поставщика (цена, валюта, срок, дата), заявка и позиции заявки.
Дальше переходите к реализации по шагам: модели и миграции, затем базовые формы и поиск по артикулу с подсказками. После этого добавьте статусы заявки и простое согласование: кто отправил, кто утвердил, когда и с каким комментарием.
Если собираете MVP в TakProsto, удобно начать с planning mode, а перед крупными изменениями использовать snapshots и rollback, чтобы спокойно править процесс по итогам теста.
Сравнительная таблица нужна, чтобы за полминуты понять, что реально можно купить, у кого быстрее и где риск ниже. Важно уметь сравнивать не только один артикул, но и разные аналоги в одной таблице, иначе выбор каждый раз превращается в гадание.
Хорошая таблица короткая. Обычно достаточно: цена (с валютой, НДС и единицей измерения), срок поставки (обещание) и факт по прошлым поставкам, наличие (подтверждено или нет и когда), условия (MOQ, предоплата, доставка, гарантия), надежность и комментарии.
Чтобы сравнение аналогов было честным, добавьте два поля: какой это аналог (полный/допустимый/условный) и что именно сравниваем (например, комплектность или ресурс). Тогда одинаковая цена не создает ложного ощущения равенства.
Без фильтров таблица быстро разрастается. На старте обычно хватает нескольких переключателей: только подтвержденное наличие, только одобренные бренды, срок до N дней, исключить поставщиков ниже заданного рейтинга.
Подсветка «лучшего варианта» должна зависеть от выбранного правила (самая низкая цена среди подтвержденного наличия, самый быстрый срок при рейтинге не ниже 4/5, лучшее соотношение цена/срок). И важно показывать, почему строка стала лучшей, короткой подписью рядом с подсветкой.
Главная причина провалов простая: пытаются учесть все сразу. В итоге система выглядит умно, но ей неудобно пользоваться, а данные быстро перестают быть надежными.
Прайс - общий ориентир. Предложение - ответ на вашу заявку с конкретными условиями (срок, партия, доставка, валюта, скидка, замена). Если смешать их в одной таблице, история цен становится ложной: вы смотрите на «цену поставщика», а на деле это разовая цена под срочную поставку.
Простой тест: если по одной и той же позиции цена «менялась» пять раз за неделю, часто это признак того, что вы смешали типы данных.
Когда аналоги не разделены по смыслу (полный аналог, подходит с ограничениями, требует доработки), сотрудник выбирает случайную замену, потому что в списке все выглядит одинаково. Доверие к справочнику падает после первого же возврата или простоя.
Минимум, который спасает: у аналога должны быть тип замены, причина (почему подходит) и уровень риска (низкий, средний, высокий).
Чаще всего систему «убивают» мелочи:
Типичный сценарий: в таблице «дешево», но это цена за 10 штук и в другой валюте, а срок взят из старого письма без даты. Итог - неверный заказ и срочная закупка по завышенной цене.
После MVP лучше не «допиливать все подряд», а проверить, стало ли принимать решения быстрее и спокойнее. Для пилота обычно достаточно одного закупщика и одного инженера, пары десятков позиций и 2-3 поставщиков.
В карточке запчасти держите короткий, но полезный набор: артикул и производитель, описание, единица измерения, применяемость (модель оборудования) и связи на аналоги внутри системы. У аналога фиксируйте тип замены, причину (по каким признакам совпадает) и ограничения (например, только для определенных ревизий).
Чтобы аналоги вызывали доверие, добавьте простую проверку качества и покажите ее в интерфейсе: статус (черновик, проверено инженером, подтверждено эксплуатацией), кто подтвердил и когда, что именно сравнили (размер, материал, допуски), источник.
С ценами не пытайтесь «угадать правильную». Лучше задайте правило устаревания: например, предложение старше 30 дней считается просроченным, а для дефицитных позиций - 7-14 дней. При просрочке система должна подсказывать «нужно обновить предложение» и фиксировать дату запроса.
По срокам держите рядом обещание и факт. В карточке предложения показывайте заявленный срок, фактическую дату прихода по прошлым поставкам и простую надежность (например, доля поставок без просрочки за 90 дней).
Дальше расширяйтесь по шагам: аккуратно разделяйте роли (инициатор, согласующий, закупщик, кладовщик), добавляйте импорт прайсов и остатков, подключайте отчеты (экономия на аналогах, просрочки, отклонение цены от средней) и уведомления (устаревшие цены, критические сроки, дефицит).
Если нужно быстро собрать первую рабочую версию без длинной разработки, TakProsto (takprosto.ai) подходит для такого MVP: вы описываете логику словами, получаете интерфейс и формы, а затем при необходимости экспортируете исходники и развиваете решение в своем контуре.
Начните с разделения на две части: справочник и операции. В справочнике держите «что покупаем» (запчасть, артикулы, производитель, связи аналогов), а в операционной части — «как покупаем» (поставщики, их предложения, заявки и выбранные варианты). Так аналоги и артикулы не смешаются с ценами и статусами, и история выбора останется понятной.
Обычно хватает пяти сущностей: запчасть, артикул, производитель, поставщик, предложение. Плюс отдельная сущность «заявка», которая связывается с выбранным предложением и фиксирует итог. Это дает минимально достаточную базу для поиска, сравнения и аудита решений без лишней сложности.
Храните аналоги как связь между запчастями, а не как «похожие строки» по артикулу. Добавьте тип замены и комментарий, почему подходит, и обязательно учитывайте направление: A можно заменить на B, но обратная замена может быть неверной. Тогда поиск и выбор будут опираться на позиции, а не на случайные совпадения кода.
Дайте пользователям простую классификацию: полный, допустимый, условный, не рекомендован. В карточке связи фиксируйте источник уверенности и ограничения, чтобы было ясно, когда аналог можно ставить без вопросов, а когда нужна проверка или согласование. Если этого нет, справочник быстро теряет доверие после первых возвратов.
Минимум для честного сравнения: цена и валюта, единица измерения и упаковка, НДС/без НДС, MOQ, обещанный срок и ключевые условия (доставка включена или нет). Без единиц измерения и условий любая «дешевая цена» может оказаться ценой за другую упаковку или без доставки, и решение будет ошибочным.
Самый практичный вариант — хранить ценовые события: зафиксировали цену на дату, с условиями и источником. Если нужен аудит «как прислали», добавьте привязку к снимку предложения, но не мешайте прайсы и ответы на конкретную заявку. Тогда графики и сигналы работают, и видно, где реальная динамика, а где разовая срочная поставка.
Фиксируйте не только обещание, но и факт: реальные даты отгрузки и поступления по закрытым заказам. В предложении полезно хранить отдельные поля про «есть на складе» и «подтверждено», потому что «наличие» в прайсе часто не означает готовность отгрузить. Дальше решение простое: для критичных закупок выбирайте надежность, а не самое смелое обещание.
Делайте одну таблицу, где в строке — конкретное предложение, а внутри видно, к какому аналогу оно относится. Важнее всего подсветить не «самую низкую цену», а лучший вариант по выбранному режиму, например «срочно» или «планово», и коротко показать причину. Тогда решение занимает минуты, а не обсуждения в чате.
Оставьте короткую цепочку статусов, чтобы было видно, где застряло: черновик, на согласовании, отправлено, подтверждено, закрыто. В заявке держите только то, что влияет на решение: что нужно, сколько, к какому сроку и куда ставим, плюс выбранный аналог и выбранное предложение. И обязательно ведите журнал изменений, чтобы потом не спорить, кто и почему поменял вариант.
Сфокусируйтесь на одном сценарии «поиск → сравнение → заявка → согласование» и ограничьте роли до снабженца и согласующего. В TakProsto удобно начать с planning mode, а перед серьезными правками делать snapshots и при необходимости откатываться через rollback, чтобы быстро проверять гипотезы без риска сломать работающий поток. Как только сценарий стал стабильным, можно расширять роли, импорт прайсов и отчеты.
