Как связать смету, закупки и фактические расходы, сохранив действующую 1С

У многих подрядчиков учёт давно ведётся в 1С или другой учётной системе. Там закупки, склад, расчёты с поставщиками, бухгалтерия. Проектная сторона живёт отдельно: смета в табличном файле, изменения в переписке, прогноз затрат в голове руководителя проекта. Когда хочется навести порядок, первая мысль бывает радикальной: перенести всё в одну новую систему. Обычно это дорого, долго и не нужно.

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

Почему не стоит всё переносить

Учётная система уже настроена под бухгалтерию, налоговый учёт и привычки сотрудников. Её замена затрагивает людей, которые к проектам отношения не имеют. Для управления изменениями проекта такая замена не требуется.

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

Из‑за этого руководитель проекта собирает картину вручную: выгружает расходы из учёта, сводит их со сметой в таблице, добавляет изменения из переписки. Такая сводка устаревает в день составления, и делают её обычно раз в месяц, когда исправлять что‑то уже поздно. Факт расходов в учёте есть, но его не с чем сравнить: смета хранится в другом месте и не учитывает согласованные изменения.

Кто хранит какие данные

Полезно начать с таблицы, где у каждого вида данных один владелец:

Главное правило: одна и та же величина не вводится руками в двух местах. Если факт расходов живёт в учёте, в систему проекта он попадает обменом.

Три версии бюджета

Факт сравнивают с тремя цифрами сразу. Исходный бюджет показывает, с чего начинали. Утверждённый бюджет включает согласованные изменения. Прогноз затрат показывает, сколько проект потратит к окончанию с учётом того, что уже известно. В отчётах Autodesk по затратам эти величины выделены отдельно, и такое разделение стоит повторить в любой системе.

Без трёх версий разговор о перерасходе становится спором. Руководитель проекта говорит, что бюджет вырос из‑за изменений заказчика, финансы видят только исходную цифру. Когда изменения записаны отдельно, видно, какая часть роста согласована, а какая нет.

Как устроить обмен

Обмен между системой проекта и учётом обычно включает два направления.

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

У производственных учётных систем свои модели данных. Это относится и к таким решениям, как 1С для управления производством или производственный раздел МойСклад. От модели зависит, к чему можно привязать расход: к заказу, к статье, к проекту. Это определяет, насколько подробно будет видна сверка. Детали обмена проектируются при внедрении на конкретной конфигурации.

Проверка: готовы ли данные к связке

Прежде чем проектировать интеграцию, ответьте на вопросы:

1. Можно ли в учёте отнести каждую закупку к проекту и разделу сметы?
2. Совпадают ли разделы сметы с тем, как снабжение группирует закупки?
3. Кто сегодня обновляет прогноз затрат и как часто?
4. Где записаны согласованные изменения и можно ли их перечислить по проекту?
5. Есть ли справочник, общий для сметы и учёта, или названия расходятся?

Если разделы сметы и учёта не совпадают, начинать надо с общего справочника. Интеграция без него будет передавать данные, которые нельзя сопоставить. Справочник не обязан быть подробным: десяти‑пятнадцати разделов на проект обычно хватает, чтобы видеть, где расход расходится с прогнозом.

Чего ожидать и чего нет

Связка не сделает прогноз точным сама по себе. Она покажет расхождение раньше: по разделу и по месяцу, ещё до конца проекта. Решения по‑прежнему принимает руководитель проекта.

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

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

В демонстрационном сценарии можно проследить, как согласованное изменение создаёт новую версию бюджета, а исходная смета сохраняется для сравнения. Связь с учётной системой в демо не показана, это предмет будущего внедрения.

Посмотреть сценарий

Связанная статья: Заказчик попросил небольшое изменение. Кто посчитает его полную стоимость?.

Источники и границы примера

• Бюджеты и прогнозы
• Управление производством
• Производство

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