Как создать веб‑приложение для стройкомпаний: учет и контроль

Цели приложения и сценарии использования

Веб‑приложение для строительства нужно не «для учета ради учета», а чтобы управлять объектом по фактам: видеть, что происходит на площадке, сколько это стоит, кто отвечает за результат и где риски по срокам и деньгам.

Какие проблемы решает система

Обычно «болит» одно и то же:

• Сроки: план работ живет в одном файле, факт — в чатах и звонках. В итоге сдвиги замечают поздно.
• Перерасход: заявки, счета и платежи идут разрозненно, и руководитель узнает о превышении бюджета постфактум.
• Хаос в подрядчиках: договоры, объемы, акты и закрытия теряются, спорные вопросы решаются «по памяти».
• Непрозрачность для руководителя: нет единого дашборда, а отчетность собирается вручную и долго.

Для каких компаний и проектов подходит

Система одинаково полезна, если вы:

• Генподрядчик — координируете несколько субподрядов, контролируете график и закрывающие документы.
• Субподрядчик — ведете собственные бригады, объемы и ежедневный факт, чтобы быстрее закрываться и получать оплату.
• Девелопер/заказчик — сравниваете план/факт по срокам и бюджету, отслеживаете исполнение обязательств подрядчиков.

Подходит и для одного объекта, и для портфеля проектов — важно, чтобы данные были сопоставимы.

Как измерять успех

Хорошие метрики простые:

• Точность бюджета: меньше «неожиданных» расходов, понятные причины отклонений.
• Скорость отчетности: отчет по объекту — за минуты, а не «к концу недели».
• Дисциплина задач и фиксации факта: регулярные обновления статусов, меньше провалов из‑за забытых договоренностей.

Что будет в статье

Дальше разберем, какие данные хранить (план/факт), как вести бюджеты, подрядчиков, материалы и документы, какие экраны нужны на объекте и как подойти к MVP, чтобы быстро получить рабочий результат.

Отдельно полезно держать в голове, что многие команды сейчас выбирают подход «быстро собрать и проверить» вместо долгой разработки с нуля. Например, TakProsto.AI помогает собрать прототип или рабочее MVP через чат (vibe‑coding): вы описываете бизнес‑процессы и экраны, а платформа ускоряет реализацию веб‑части, бэкенда и базы данных, сохраняя возможность экспортировать исходники и развивать продукт дальше.

Пользователи, роли и сбор требований

Приложение для стройкомпании почти всегда «ломается» не на функциях, а на несоответствии реальным ролям на объекте и в офисе. Поэтому начать стоит с понятной карты пользователей и договоренностей о доступах: кто что вводит, кто проверяет и кто утверждает.

Ключевые пользователи внутри компании

Обычно ядро выглядит так:

• Руководитель / собственник — смотрит сводные дашборды, отклонения по срокам и бюджету, утверждает крупные платежи.
• Прораб / начальник участка — ведет план‑факт по работам, фиксирует выполненные объемы, прикрепляет фото и документы с объекта.
• Сметчик / ПТО — отвечает за структуру сметы, расценки, изменения, привязку объемов к этапам.
• Бухгалтер / финансы — отражает счета, оплаты, закрывающие документы, контролирует НДС/статьи учета (в рамках вашей модели).
• Снабжение — заявки, заказы, поставки, остатки, списание и связь с работами.

Роли подрядчика

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

• Представитель подрядчика — получает задания, загружает акты/счета, согласует объемы.
• Бригадир — подтверждает выполнение работ по дням/захваткам.
• Табельщик (если нужно) — ведет явку/часы, если это влияет на расчет.

Матрица доступов: что критично разделить

Заранее определите правила: кто видит бюджеты и маржу, кто имеет доступ к договорам и ценам, кто может просматривать персональные данные (телефоны, паспорта, банковские реквизиты).

Практичный подход — стартовать с 6–10 ролей и простых уровней: «просмотр / создание / согласование / администрирование», а затем уточнять по мере внедрения.

Как собирать требования без фантазий

1. Интервью (по 45–60 минут) с каждой ролью: что болит, какие решения принимают, где ошибаются.

2. Дневник процессов на 3–5 рабочих дней: пусть прораб и снабженец фиксируют реальные шаги и документы (в мессенджерах, Excel, на бумаге).

3. Разбор типового проекта: берете один завершенный объект и проходите путь «договор → смета → заявки → акты → оплаты», отмечая точки контроля.

Выходные артефакты, которые ускоряют разработку

Результатом должны стать: карта ролей, список пользовательских задач (user stories) и приоритеты (что в MVP, что позже). Эти материалы пригодятся в следующем шаге — при планировании MVP и этапов внедрения (см. /blog/mvp-dlya-stroykompanii, если у вас есть такой раздел).

Управление проектами: этапы, сроки и задачи

Хорошее приложение для стройкомпании начинается с понятного «скелета» проекта: где мы сейчас, что должно быть сделано дальше и кто отвечает. Если это видно за 30 секунд — руководитель доверяет данным, а прораб не тратит время на лишние поля.

Канбан или список проектов — одна точка входа

На главном экране удобно держать список объектов (или канбан по статусам). Минимальный набор для карточки проекта:

• объект и заказчик;
• текущий этап (подготовка, нулевой цикл, коробка, инженерка, отделка, сдача);
• ответственные (РП, прораб, снабжение);
• статус и «красные флажки» (просрочка, превышение бюджета, нет актов).

Такой экран помогает быстро фильтровать «где горит» без погружения в документы.

Календарный план: вехи и зависимости без сложной теории

В календаре полезно хранить вехи (старт/финиш этапов) и ключевые работы. Дайте возможность задавать простые зависимости «после/до» (например, «стяжка после разводки электрики»).

Для управленца достаточно упрощенного критического пути: система подсвечивает задачи, сдвиг которых немедленно сдвигает дату сдачи, и показывает прогноз окончания.

Задачи на объекте: чек‑листы, фото и комментарии

Оперативные задачи должны создаваться за минуту: чек‑листы по типовым работам, прикрепление фото «до/после», короткие комментарии и отметка факта.

Важно разделить «задачи» и «работы по договору», чтобы не путать контроль качества с объемами.

Уведомления: только то, что влияет на срок и деньги

Минимум уведомлений, максимум пользы: просрочки по вехам, изменения сметы/лимитов, появление новых актов/счетов, а также запросы на согласование.

Мобильный интерфейс для прораба: минимум требований

Критично: крупные кнопки, работа одной рукой, быстрый поиск по объекту, офлайн‑режим с очередью отправки, загрузка фото с сжатием и роль «прораб» с доступом только к своим объектам и задачам.

Модель данных: что хранить, чтобы считать план и факт

Чтобы приложение реально помогало управлять стройкой, модель данных должна отвечать на один практичный вопрос: «Что у нас было запланировано и что получилось по факту — в сроках, объемах и деньгах?». Для этого важно заранее договориться о сущностях и правилах «план/факт».

Базовые сущности, без которых план/факт не посчитать

Минимальный «скелет» обычно выглядит так: проект → объект → этап → работа. Работа — ключевая единица учета: именно на нее «ложатся» объемы, сроки, деньги и документы.

Рядом обязательно идут контрагенты и финансы: подрядчик, договор, счет, платеж. Связи простые: договор привязан к подрядчику и объекту (или проекту), счета относятся к договору, платежи закрывают счета.

Разделение «план/факт» по работам, материалам и услугам

План и факт лучше хранить не «в одной цифре», а как отдельные записи:

• План: объем, цена/ставка, плановая дата начала/окончания.
• Факт: выполненный объем по периодам, фактические даты, принятые суммы.

Такое разделение нужно не только для работ, но и для материалов и услуг: у материалов важны количество, партия, склад/объект и списание; у услуг — период оказания и подтверждающие документы.

Справочники: чтобы данные были одинаковыми у всех

Справочники снижают хаос в отчетах: статьи затрат, единицы измерения, ставки, типы работ. Если прораб пишет «м3», бухгалтер — «м^3», а сметчик — «куб», то сводные отчеты начнут «плыть». Справочник решает это на входе.

Версионирование сметы и согласования

Смета и план меняются — это нормально. Важно хранить версии: номер версии, кто изменил, когда, что именно поменялось и статус согласования. Тогда можно честно сравнить факт не с «последней правкой», а с утвержденной базой.

Единые идентификаторы для интеграций и отчетов

Сразу заложите единые идентификаторы (ID) для проекта, договора, счета и работы. Они станут опорой для обмена данными с бухгалтерией и для сквозных отчетов (например, «работа → договор → счета → платежи»). Подробнее об обмене данными — в разделе Интеграции и обмен данными.

Бюджеты и финансы: сметы, платежи, отклонения

Финансовый контур в стройке должен отвечать на простые вопросы: сколько запланировали, сколько уже потратили, что еще обязательно оплатить и где «пополз» перерасход. Чтобы приложение реально использовали на объектах, важнее прозрачные статусы и понятные формулы, чем сложные финансовые термины.

Базовая структура бюджета

Стартуйте со сметы как со «скелета» проекта: статьи затрат (работы, материалы, техника, субподряд, прочее), объемы, цена за единицу и итог по строке. Полезно сразу добавить:

• резервы по статьям (например, 3–5% на риски);
• отдельную строку «непредвиденные» с правилами расходования;
• привязку статей к этапам/разделам работ, чтобы видеть бюджет не только «в целом», но и по календарю.

Так руководитель быстро понимает, где деньги «сидят» — в фундаменте, отделке или инженерии.

Факт: от счета до закрытия

Факт расходов лучше строить не из ручного ввода сумм, а из цепочки документов и событий: счет → согласование → платеж (частичный/полный) → закрывающие документы.

Отдельно важно поддержать строительные реалии: авансы, удержания, поэтапные оплаты и возвраты.

Минимальный набор статусов, понятный всем: «черновик», «на согласовании», «согласовано», «оплачено», «закрыто документами», «отклонено».

Контроль перерасхода и правила согласования

Перерасход обычно начинается незаметно — небольшими доборами и «допами». Поэтому в приложении нужны лимиты:

• по статье;
• по этапу;
• по договору/подрядчику.

При превышении — простое правило: кто и в каком порядке согласует, какие комментарии обязательны, можно ли платить частично.

Отчеты без бухгалтерского языка

Дайте руководителю 2–3 отчета, которые читаются за минуту: отчет по прибыли/убытку проекта (план/факт/прогноз), сводка по объектам и динамика отклонений по неделям.

В идеале — с расшифровкой «кликнул и провалился» до счета или договора, без лишней бюрократии.

Подрядчики: договоры, объемы работ и документы

Подрядчики — самая «живая» часть стройки: люди меняются, объемы уточняются, документы приезжают с опозданием, а руководителю нужен понятный ответ «кто делает что и на каких условиях». Поэтому важно собрать подрядный контур так, чтобы он поддерживал контроль, но не превращался в бюрократию.

Карточка подрядчика

Начните с единого профиля: контакты ответственных, специализация (инженерка, монолит, отделка), регионы/объекты, а также допуски и документы (например, лицензии, страховки, сертификаты) со сроками действия.

Полезно добавить внутренний рейтинг или заметки по качеству и дисциплине — как управленческий ориентир, без претензии на «абсолютную точность».

Договоры как основа контроля

В договоре фиксируются сроки, объемы, цены, условия гарантии и этапы оплаты. В интерфейсе это лучше хранить не одним PDF, а структурой:

• ключевые даты (старт/финиш, контрольные точки);
• разделение на этапы и позиции работ;
• привязка к объекту и ответственным.

Так проще сравнивать обещанное и фактическое, а также быстро собирать сводку по обязательствам.

Фиксация выполненных работ (наряд/объем)

Нужен понятный процесс подтверждения: подрядчик подает объем, прораб/технадзор подтверждает, руководитель видит статус.

Фиксация может включать фото, комментарии, привязку к зоне/этажу и дату выполнения. Ключевое — кто именно подтверждает и по каким правилам (например, «2 уровня согласования при превышении объема»).

Акты и счета без потери связи с работами

Акты и счета должны иметь статусы (черновик → на согласовании → согласовано → оплачено/частично) и обязательную привязку к конкретным работам и этапам договора. Тогда любая оплата объяснима: «за какой объем, по какому этапу, на основании какого акта».

Споры и замечания

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

Материалы и снабжение: от заявки до списания

Материалы — одна из самых «шумных» статей на стройке: много мелких позиций, поставки частями, замены, возвраты. Поэтому в веб‑приложении важно сделать понятный, короткий путь от потребности на объекте до факта списания в работы.

Журнал закупок: заявки, согласования, поставки

Базовая единица — заявка на закупку. В ней достаточно: объект, позиция (наименование/единица), количество, желаемая дата, комментарий, приоритет.

Дальше заявка проходит простое состояние: «черновик → на согласовании → согласовано → заказано → в пути → получено/закрыто/отменено».

В журнале закупок полезны поля: поставщик, плановая/фактическая дата поставки, цена/сумма (если известны), ответственный. Это дает прозрачность: что уже заказано, что просрочено, по кому «висит» решение.

Упрощенный склад: приход, расход, списание на объект

Если полноценный складской учет не является приоритетом, достаточно «упрощенного склада» по объектам:

• приход (по накладной/счету/УПД): что приехало и в каком количестве;
• расход/перемещение: передали бригаде или между объектами;
• списание: зафиксировали, что материал израсходован.

Остаток считается автоматически как приход минус расход/списание.

Связь материалов с работами и сметой

Чтобы считать план/факт и контролировать перерасход, связывайте каждую позицию с:

• работой/этапом (например, «стяжка пола», «монтаж ГКЛ»);
• сметной статьей (материалы, расходники, аренда и т. п.).

Тогда приложение покажет не только «сколько купили», но и на какую работу ушли материалы и где появились отклонения.

Вложения: фото, накладные, поиск

Для «полевого» использования добавьте вложения к приходу/заявке: фото разгрузки, фото маркировки, накладные, счета.

Важно, чтобы документы можно было найти по объекту, поставщику, дате и номеру (хотя бы через теги и быстрый фильтр).

Минимальный набор, если склад — не главное

Если нужно стартовать быстро (MVP), оставьте: заявки + статусы, поставщик и сроки, приход по документу, списание на работу, вложения и фильтры. Этого достаточно, чтобы убрать хаос в снабжении без тяжелой логистики и сложных регламентов.

UX для стройки: простые экраны, мобильность и офлайн

Хороший UX в стройке — это не «красиво», а «быстро и без ошибок». На объекте у людей грязные руки, перчатки, шум, слабый интернет и мало времени. Поэтому интерфейс нужно проектировать вокруг коротких действий: отметил факт, приложил фото, отправил на согласование — и пошел дальше.

Дашборд руководителя: видеть риски за 30 секунд

Руководителю важны не детали, а сигналы. Главный экран стоит собирать из трех блоков: риск срыва сроков (по критическому пути или по задачам с просрочкой), перерасход (план/факт по статьям и объектам) и «узкие места» в согласованиях (зависшие акты, счета, допсоглашения).

Полезно сразу показывать причины: какая задача тянет график, какой подрядчик не подтвердил объем, какой платеж просрочен. Это превращает дашборд в инструмент действия, а не в витрину.

Интерфейс прораба: минимум полей, максимум скорости

Для прораба важна «быстрая отметка»: выполнено/не выполнено, объем, люди/техника, короткий комментарий. Фото — обязательное как подтверждение, а голосовые комментарии можно сделать опционально (они хорошо работают в шуме, но требуют дисциплины в расшифровке и хранении).

Единые статусы и цвета

Если у снабжения «в работе» означает одно, а у ПТО — другое, проект превращается в спор терминов. Введите единый справочник статусов и цветов (например: серый — черновик, синий — на согласовании, зеленый — утверждено, красный — просрочено) и используйте его везде: задачи, счета, акты, заявки.

Офлайн‑режим: черновики и синхронизация

На объекте связь пропадает регулярно. Правило простое: пользователь должен уметь создать черновик (отметка работ, фото, комментарий), а приложение — синхронизировать изменения при появлении интернета, аккуратно решая конфликты (кто и когда поменял данные).

Подсказки и защита от ошибок

Самые дорогие ошибки — суммы и даты. Добавляйте подсказки: формат дат, предупреждения о пересечениях периодов, контроль «план < факт», маски для денег и понятные сообщения об ошибках без канцелярита. Чем меньше ручной проверки — тем выше доверие к системе и тем быстрее ее принимают на объекте.

Документооборот и отчетность без лишней бюрократии

Стройка быстро превращается в «папку на папке»: договоры, акты, счета, чертежи, письма и переписка по задачам. Веб‑приложение должно уметь принимать документы так же просто, как мессенджер, но хранить их так же строго, как бухгалтерия.

Загрузка документов: быстро и по делу

Сделайте единый виджет загрузки в карточках проекта, этапа и подрядчика. Пользователь прикрепляет файл и сразу отвечает на два вопроса: к чему относится (проект/этап/договор/задача) и что это за документ (договор, акт, счет, чертеж, письмо). Остальное — по умолчаниям.

Поддержите типовые сценарии: загрузка пачки файлов, добавление комментария, привязка к сумме/платежу, а также прикрепление переписки по задачам — например, писем с согласованием объема работ.

Структура хранения: порядок без ручной дисциплины

Храните документы в иерархии проект → этап → подрядчик → договор/работа. Добавьте правила именования, которые формируются автоматически: дата + тип + номер + контрагент. Пользователь видит человекочитаемое имя, а внутри система держит стабильный идентификатор.

Поиск, фильтры и теги (OCR — опционально)

Базовый поиск должен работать и без «умных» технологий: фильтры по типу, статусу, периоду, подрядчику, этапу; теги вроде «срочно», «на согласовании», «исправить». OCR можно предлагать как опцию: помогает находить по номеру счета или сумме, но не стоит обещать идеальную точность.

История изменений: доверие и контроль

Любое изменение суммы, статуса или привязки документа фиксируйте в истории: кто, когда, что было и что стало. Это снимает споры и ускоряет внутренние проверки.

Шаблоны отчетов: PDF/Excel под роли

Вместо десятков «уникальных» выгрузок сделайте несколько шаблонов по ролям: для руководителя (сводно), для ПТО (по этапам и актам), для бухгалтера (счета и статусы оплат). Экспорт в PDF и Excel должен повторять структуру экрана, чтобы отчет не требовал ручной обработки после выгрузки.

Интеграции и обмен данными

Интеграции в стройке нужны не «для галочки», а чтобы убрать двойной ввод и ускорить согласования: смета живет в одном месте, платежи — в другом, документы — в третьем. Важно заранее определить, какие данные являются «источником истины» и кто за них отвечает.

Что интегрировать в первую очередь

Обычно максимальный эффект дают связки с:

• Бухгалтерией и платежами: статусы оплат по счетам, выгрузка платежного календаря, сверка контрагентов.
• Почтой: автоматическая привязка входящих счетов/писем к проекту и договору.
• Календарем: встречи по объекту, дедлайны актов, контрольные точки.
• Электронной подписью (если требуется): отправка договоров/актов на подписание и возврат подписанных версий в карточку документа.

Импорт/экспорт: Excel как первый шаг, API как следующий

На старте часто достаточно качественного импорта/экспорта Excel: загрузить справочник объектов, сметы, список договоров и быстро выгрузить отчет для руководителя.

Когда процессы стабилизируются, логично добавлять API: регулярный обмен платежами, статусами документов, изменениями по календарному плану. Так данные обновляются автоматически и без ручных «сверок по пятницам».

Справочники и синхронизация контрагентов

Боль №1 — дубли: «ООО Ромашка», «Ромашка ООО», «Ромашка (ИНН…)». Решение — единые правила и поля:

• хранить ИНН/КПП как ключ;
• включить поиск дублей при заведении;
• настроить синхронизацию справочника контрагентов с бухгалтерией.

Права доступа и журнал операций

Интеграции — это доступ к деньгам и документам, поэтому нужны:

• отдельные роли на подключение/отключение интеграций;
• ограничение по проектам/юрлицам;
• журнал операций: кто выгрузил отчет, кто изменил реквизиты, кто инициировал отправку на подпись.

Если планируете внедрение поэтапно, полезно посмотреть подходы к MVP и типовым модулям в /blog, а варианты тарификации — на /pricing.

Безопасность, доступы и надежность

Безопасность в стройке — это не только про «пароли посложнее». В приложении крутятся сметы, договоры, счета, акты и контакты подрядчиков, а значит важно сразу заложить понятные правила доступа, следы изменений и план восстановления.

Роли и минимальные права

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

Обычно хватает базовых ролей: руководитель/собственник, руководитель проекта, инженер/ПТО, снабжение, бухгалтерия, подрядчик (ограниченный доступ), наблюдатель (только чтение). Для критичных действий (утверждение акта, смена реквизитов, удаление платежа) добавьте подтверждение и, по желанию, 2FA как опцию.

Персональные данные и коммерческая тайна

Заранее определите, какие поля относятся к персональным данным (ФИО, телефон, email) и что является коммерческой тайной (цены, маржа, условия договоров). Практика: шифровать чувствительные данные в хранилище, ограничивать экспорт, а в интерфейсе скрывать «лишние» цифры для ролей без финансовых полномочий.

Логи и аудит

Аудит — обязательный элемент контроля: кто изменил бюджет, кто утвердил акт, кто поменял объем работ.

Хороший минимум:

• история версий по сметам/актам/платежам (что было → что стало);
• отметка пользователя, времени и основания (комментарий/причина);
• журнал входов и попыток доступа.

Резервные копии и восстановление

Определите частоту бэкапов (например, ежедневные + точка восстановления каждые несколько часов для критичных данных), ответственность (кто проверяет) и главное — регулярное тестирование восстановления. Без проверки «бэкап есть» не равняется «данные спасем».

Чек‑лист для заказчиков на старте

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

MVP, стек и план внедрения по шагам

Хорошая новость: чтобы получить пользу от системы учета на стройке, не нужно сразу «закрывать всё». Гораздо эффективнее начать с MVP — первого релиза, который решает ключевые задачи на одном объекте и быстро показывает эффект.

Что включить в MVP (5–7 функций)

Для стройкомпаний обычно достаточно следующего набора:

1. Проекты и объекты: карточка объекта, ответственные, статусы.

2. Календарный план работ (простая версия): этапы/работы, даты, процент выполнения.

3. План‑факт по объемам и деньгам: сколько «запланировали» и сколько реально сделали/потратили.

4. Подрядчики: реестр, привязка к работам, суммы, базовые документы.

5. Заявки/счета/платежи: фиксация обязательств и оплат с привязкой к объекту.

6. Акты и закрывающие: загрузка файлов, статусы согласования.

7. Дашборд руководителя: несколько понятных показателей (сроки, отклонения, дебиторка/кредиторка, проблемные работы).

Если цель — максимально быстро проверить гипотезу и «приземлить» процессы на один объект, MVP можно собирать итеративно: сначала экраны и статусы, затем документы и лимиты, потом отчеты и интеграции. В этом формате TakProsto.AI удобен тем, что позволяет быстро пройти путь «описали сценарии → получили рабочие экраны и логику», а затем при необходимости экспортировать исходный код, развернуть у себя и масштабировать.

Стек «человеческим языком»

• Веб‑приложение для офиса и руководителей: работает в браузере.
• Мобильный доступ для прораба/мастера: адаптивная версия или отдельное приложение.
• База данных (например, PostgreSQL) для надежного хранения и отчетов.
• Хостинг в облаке или на сервере компании: выбирают по требованиям безопасности и интеграциям.

План внедрения: прототип → пилот → масштабирование

Сначала делается прототип экранов и согласуются правила учета (что считается фактом, кто подтверждает). Затем — пилот на одном объекте на 4–8 недель: вводят реальные данные, фиксируют узкие места, уточняют роли. После этого — масштабирование на остальные объекты и добавление функций, которые действительно востребованы.

Тестирование: не «по кнопкам», а по сценариям стройки

Проверяйте типовые цепочки: «заявка → счет → оплата», «работа → акт → закрытие», а также корректность расчетов, ограничения прав (кто что видит/может править) и работу при плохой связи.

Запуск и поддержка

Запуск лучше делать через короткое обучение (30–60 минут по ролям), шаблоны ввода и чат поддержки. Дальше — регулярный цикл улучшений: раз в 2–4 недели собирать обратную связь и выпускать небольшие обновления, чтобы система не превращалась в «еще одну обязаловку».