ERP для строительной компании: как учитывать частичную приёмку работ

Возьмите на встречу с разработчиком один незакрытый объект

В строительной компании заказ ведут по объекту, но работы редко принимают одной кнопкой в последний день. Часть штукатурки уже принята, другая предъявляется сейчас, двери закрываются отдельной строкой. Если в задании на ERP оставить только статус «выполнено на 70%», система не объяснит, что входит в этот процент, какой объём новый и не попал ли он в отчёт повторно.

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

Три количества в строке нельзя заменять друг другом

Согласованный объём

База, относительно которой проверяется исполнение. В расчёте она фиксирована и относится к одной выбранной версии перечня работ.

Ранее принято

Накопленный объём до начала текущего периода. При переносе данных нужно знать, что он включает и на какую дату подтверждён.

Принято сейчас

Добавление только за рассматриваемый период. Оно не должно повторять предыдущий накопленный результат.

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

Почему средние 75% вводят в заблуждение

В первой строке готова половина, во второй — всё. Простое среднее равно семидесяти пяти процентам. Однако строки имеют разный вес в согласованной стоимости: сто тысяч и десять тысяч рублей. Стоимостная доля принятого равна 60 000 / 110 000, то есть примерно 54,55%. Именно такой смысл у общего процента в инструменте ниже.

Это не универсальная физическая готовность здания и не соблюдение графика. Для технологической готовности нужны собственные критерии, для срока — план и зависимости. Дорогая позиция автоматически получает больший вес только в стоимостной оценке. Нельзя назвать этот показатель прибылью, остатком денег или суммой, которую заказчик обязан немедленно перечислить.

Что попросить показать на прототипе ERP

1. Карточку позиции с устойчивым номером, единицей, согласованным количеством и выбранной версией расценки.
2. Раздельные поля для предъявленного и подтверждённого объёма, если в компании эти этапы различаются.
3. Период, автора, проверяющего и основание подтверждения: документ, измерение или иной согласованный источник.
4. Контроль превышения по каждой позиции. Десять лишних квадратных метров нельзя скрыть свободным остатком другой работы.
5. Отчёт с колонками «до периода», «за период», «с начала» и возможностью перейти к основаниям.
6. Порядок исправления ошибочного подтверждения. Изменение задним числом должно оставлять историю, а не молча переписывать прошлый итог.

В официальной справке Procore количество за прошлые периоды и новое количество выделены отдельно. Это полезный пример разделения данных в отраслевой системе, но не готовый регламент для российского подрядчика. Формы документов, налоги, удержания и расчёты с заказчиком требуют отдельного согласования; наш учебный инструмент их не воспроизводит.

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

На пилоте сравните один закрытый период с исходными данными. Затем добавьте следующий и убедитесь, что прежний результат не начислился повторно. Если из старой таблицы перенесён только общий процент объекта, восстановить принятые количества по разным позициям из него невозможно. Нужна детализация или явно обозначенная неполнота, а не распределение «на глаз».

Одинаковое название работ не заменяет идентификатор. Штукатурка на разных этажах может иметь разные основания и расценки. И наоборот, переименование строки не должно терять уже принятый объём. Структуру объектов, помещений и позиций лучше согласовать на реальном обезличенном примере до импорта всей истории.

Как пользоваться расчётом

Каждая строка содержит ID, единицу, согласованное количество, ранее принятое, текущий период и цену единицы. Допустимо до ста позиций. Количества задаются с точностью до трёх знаков, расценки — до копеек. Все значения неотрицательные, согласованный объём и цена положительные. Инструмент отклоняет превышение, а не обрезает его до плана.

Стоимость выводится без потери точности произведения, иногда до пяти знаков после запятой. Например, 0,001 единицы по 0,01 ₽ дают 0,00001 ₽ в аналитическом расчёте. Это не сумма платёжного документа: правила округления при оформлении документов здесь не заданы. Процент округляется отдельно до двух знаков и не участвует в обратном вычислении объёмов.

Короткий сценарий приёмки будущей системы

Загрузите две строки из таблицы. Получите 40 000 ₽ за текущий период и 60 000 ₽ накопительно. Затем у штукатурки замените текущие 30 м² на 81 м²: вместе с прежними двадцатью это выше ста, поэтому система должна потребовать исправление или согласование изменения исходной базы. Автоматически увеличить смету или принять только оставшиеся восемьдесят — другое бизнес-решение, его нельзя включать незаметно.

Для разработки ERP строительной компании такой сценарий уточняет модуль смет и подтверждённых объёмов. Если основной процесс — ремонт помещений, его можно обсуждать в рамках CRM для ремонта квартир. До оценки проекта подготовьте перечень позиций, правила подтверждения и один пример исправления. Это поможет проверить нужную логику раньше, чем команда начнёт переносить действующие объекты.