Смета перестаёт быть файлом в Excel и становится системой
Платформа, которая держит всю экономику подрядчика в одном месте: справочники материалов и работ с живыми ценами от поставщиков, технологические карты как рецептуры, сметы с прозрачной калькуляцией надбавок и накладных, импорт чужих Excel-смет и ИИ-сборка недостающих техкарт. Мультитенантная — каждая компания работает в своей схеме базы.
Смета — документ, на котором подрядчик зарабатывает или теряет
Всё остальное в стройке — следствие. Ошибся на этапе расчёта — весь объект отработаешь в минус и узнаешь об этом на закрытии. Заложил лишнего — не выиграл тендер. При этом инструмент, которым считают, обычно один и тот же: Excel-файл, который сметчик двадцать лет носит из компании в компанию.
Считают по прайсу, которого больше нет
Материал взяли по цене трёхмесячной давности. К моменту закупки она другая, а смета уже подписана. Разница уходит из маржи, и никто не может сказать, где именно она потерялась.
Опыт хранится в голове сметчика
«Как мы считали такой же узел в прошлом году» знает один человек. Он уходит — компания начинает считать заново, и по-другому.
Смета собирается днями
Заказчик просит расчёт к завтра. На сборку уходит неделя, потому что каждую позицию ищут, считают и перепроверяют руками.
Нельзя объяснить, из чего сложилась цифра
Итог в Excel — результат цепочки формул, которые правили пятеро. Показать заказчику структуру цены невозможно, а спорить о ней приходится.
Три уровня, из которых собирается любая смета
Ключевая идея платформы: между «материалом» и «сметой» есть промежуточный уровень — технологическая карта. Именно она превращает разрозненные цены в воспроизводимую единицу работы, которую можно посчитать один раз и переиспользовать на всех объектах.
Название, единица измерения, цена, поставщик. Материалы приходят из справочника, от поставщиков или из нормализованного поиска. Работы — со ставкой за час или единицу.
Сколько материала и труда нужно на одну единицу результата: «1 м² перегородки ГКЛ» — столько-то профиля, листов, крепежа и человеко-часов. Здесь же живут надбавки на материалы и работы, транспортные расходы и маржинальность. Техкарта знает свою себестоимость и свою цену продажи.
Контейнер техкарт с количествами и группами любой вложенности. Плюс накладные расходы — отдельная сущность со статьями и правилом распределения между материалами и работами. Все цифры считаются вживую от текущих цен и настроек.
Каждая цифра прослеживается до основания
От итога сметы можно спуститься до конкретного материала, его цены, поставщика и надбавки, которая эту цену изменила. Разговор с заказчиком о цене перестаёт быть спором о числах.
Подписанная смета не поедет завтра
Техкарта версионируется: версия хранит снимок цен, надбавок и состава на момент публикации. Подорожал кабель — новая версия, а расчёты, сделанные вчера, остаются такими, какими их согласовали.
Чужой Excel превращается в структуру за один проход
Барьер внедрения любой такой системы — накопленный архив смет в чужих форматах. Поэтому импорт сделан не «загрузкой по шаблону», а разметкой: файл может быть каким угодно, размечает его человек, а материализует система.
Файл разбирается и сохраняется как есть
Результат парсинга хранится отдельно от разметки: исходник остаётся неприкосновенным, к нему можно вернуться и разметить иначе.
Пользователь размечает колонки и роли строк
Что здесь наименование, что количество, где цена материалов, а где работ. Уровни вложенности групп определяются цветом и отступами исходной сметы — иерархия сохраняется, а не схлопывается в плоский список.
Строки сопоставляются с каталогом техкарт
Нечёткое сравнение по названию с учётом единиц измерения и ключевых слов: система предлагает подходящую техкарту, человек подтверждает. Для больших смет сопоставление идёт пакетом.
Смета материализуется в сущности системы
На выходе — не картинка бывшего Excel, а живая смета: группы, связи с техкартами, количества и калькуляция, которая пересчитывается при изменении цен.
Модель пишет черновик. Материалы подбирает детерминированный код
Самая дорогая работа сметчика — собрать техкарту с нуля: вспомнить состав, найти материалы, посчитать нормы. Контур ИИ закрывает именно это. Но разделение ответственности жёсткое: LLM отвечает за технологический смысл, а за то, какой конкретно товар и по какой цене попал в карту, отвечает код.
LLM собирает состав техкарты
По названию узла модель предлагает, какие материалы и работы в него входят и в каких количествах — под формат, который дальше поймёт нормализатор.
Материалы выбираются из нормализованных кандидатов
Не «модель придумала товар», а поиск по реальным позициям поставщиков с детерминированным выбором. Работы подбирает отдельный batch-picker по каталогу компании.
Кабель километрами, стяжки упаковками, клей мешками
Отдельный сервис приводит товар любого поставщика к единой модели: что это, в чём продаётся, в чём учитывается в расходе, сколько единиц расхода в единице продажи, цена за обе — и почему принято такое решение.
Правила, а не «нейросеть так решила»
Нормализация построена на детерминированном пайплайне: профиль поставщика, классификатор, извлечение фактов, разрешение единиц. Каждое решение сопровождается обоснованием, а сомнительные попадают в метаданные качества версии техкарты.
Генерация не держит пользователя
Запрос уходит в очередь, результат возвращается сообщением. Пакетная генерация десятков техкарт не превращается в получасовой HTTP-запрос.
Мониторинг изменений вместо разовой выгрузки
Поставщики не присылают событий об изменении цены, поэтому источники переопрашиваются по расписанию. Изменение не применяется молча: оно попадает в историю, проходит проверку и оценку влияния на техкарты.
Мультитенантность, поиск и то, что делает это продуктом, а не проектом
Схема базы на каждую компанию
Не «колонка company_id во всех таблицах», а отдельная схема PostgreSQL на арендатора. Данные компаний физически не пересекаются, а миграции применяются ко всем схемам одинаково.
Общая страница входа поверх схем
Пользователь не должен помнить свой поддомен. Логин резолвится на публичном уровне, дальше выдаётся одноразовый тикет и пользователь попадает в свою схему уже аутентифицированным.
Индекс на арендатора
Материалы, работы и техкарты индексируются в Meilisearch отдельными индексами на компанию и обновляются по сигналам Django. Поиск по каталогу в тысячи позиций — мгновенный и не задевает чужие данные.
Экономика настраивается, а не зашита
Надбавки, транспорт, маржинальность, валюта, правила распределения накладных, интеграции с поставщиками — параметры компании. Две компании на одной платформе считают по-разному, и это нормальный режим работы.
Регламент, а не «выкатили и посмотрим»
Ветки master и __prod__, семантическое версионирование, эндпоинт /__meta__/version, по которому в любой момент видно, что именно развёрнуто, и привязка каждой ветки к задаче трекера.
Технический владелец продукта
Роль отделена от продуктовой: архитектурные решения, оценка влияния изменений и границы того, что платформа делать не должна, — зона ответственности одного человека, и она зафиксирована, а не подразумевается.
Монолит с доменом внутри, специализированные сервисы снаружи
Разделение проведено по одному признаку: всё, что владеет данными компании и бизнес-решениями, живёт в Django. Всё, что общается с внешним миром — поставщиками, моделями, поисковыми индексами, — вынесено в отдельные сервисы и может падать, не роняя основную систему.
Django для домена, FastAPI для сервисов
Продукт, а не сайт: если у вас похожая задача
Metis One — это отраслевая SaaS-платформа, спроектированная и построенная от модели предметной области до контура эксплуатации. Тот же подход применим везде, где у бизнеса есть сложная считаемая экономика, зашитая в Excel и в головах: производство, монтаж, сервис, логистика.
Похожие задачи в других отраслях
СКУД v2
Проход по карте и лицу, мгновенный перехват на всех точках, табель рабочего времени.
смотреть кейс → Ритейл · ИИDialog Analyzer
Разбор телефонных разговоров: диаризация, оценка по методике, сверка каждой цитаты.
смотреть кейс → E-commerce · SaaSВитрина в Telegram
Магазин подключается тремя токенами и получает витрину прямо в мессенджере.
смотреть кейс →