Сметчик ведёт сметы по десяти объектам: архив и совместная работа

MAATRIX

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

Десять объектов, десять комплектов файлов — и один ноутбук

Смета — это не один файл. Это база расценок, локальная смета по разделам, сводный расчёт, акты выполненных работ, переписка с заказчиком по корректировкам, иногда сканы актов КС-2 и КС-3, приложенные чертежи и спецификации. Когда объектов немного, всё это худо-бедно умещается в папках на рабочем компьютере. Но когда объектов десять и они в разных стадиях — где-то только предварительная смета, где-то уже идут КС-2 за третий месяц, — начинается путаница.

Типичная картина: папка «Объект_Ленина15» соседствует с «Объект_Ленина15_финал», «Объект_Ленина15_финал2» и «Объект_Ленина15_для_заказчика». Через полгода никто, включая самого сметчика, не вспомнит, чем они отличаются. Добавьте к этому, что ноутбук может сломаться, потеряться или просто оказаться не под рукой, когда бухгалтерия срочно просит акт по объекту, а вы в этот момент на выезде на другой площадке.

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

Что должно лежать в архиве по каждому объекту

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

На практике по каждому объекту в архиве стоит держать:

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

Если организовать сервер так, чтобы под каждый объект была своя папка верхнего уровня с одинаковой внутренней структурой подпапок («01_Проект», «02_Смета», «03_Согласования», «04_Акты»), то через год работы по десяти и более объектам вы не тратите время на поиск — заходите в нужную папку и сразу понимаете, где что лежит. Это кажется мелочью, пока не начинаешь искать конкретный акт трёхмесячной давности по объекту, название которого сходу и не вспомнишь.

Совместная работа: проверка, согласование, доступ коллег

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

• сам сметчик — редактирует и обновляет смету;
• проверяющий (главный инженер, руководитель проекта) — смотрит, комментирует, иногда просто должен видеть актуальную версию без права её менять;
• смежный сметчик или представитель заказчика — иногда нужен временный доступ только к одному объекту, без права видеть остальные девять.

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

Важный побочный эффект такой организации — снимается вопрос ответственности. Когда все правки видны в истории изменений конкретной папки, легко понять, кто и когда внёс правку в объёмы или расценки, а не разбираться постфактум, откуда взялась разница в сумме сметы.

Свой сервер как централизованный архив: как это работает

Практический способ получить такой архив — развернуть на своём сервере файловое хранилище с веб-интерфейсом и синхронизацией, например Nextcloud. Это открытое решение, которое устанавливается на обычный VPS и даёт три вещи сразу: веб-доступ из браузера с любого устройства, синхронизацию через клиент на компьютере (папка ведёт себя как обычная сетевая папка) и управление пользователями и правами на уровне папок.

Развёртывание на Ubuntu через Docker выглядит примерно так:

sudo apt update && sudo apt install -y docker.io docker-compose-plugin
mkdir -p ~/nextcloud && cd ~/nextcloud

Минимальный docker-compose.yml:

services:
  db:
    image: mariadb:10.11
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: замените_на_свой_пароль
      MYSQL_DATABASE: nextcloud
      MYSQL_USER: nextcloud
      MYSQL_PASSWORD: замените_на_свой_пароль
    volumes:
      - db_data:/var/lib/mysql

  app:
    image: nextcloud:latest
    restart: unless-stopped
    ports:
      - "8080:80"
    depends_on:
      - db
    environment:
      MYSQL_HOST: db
      MYSQL_DATABASE: nextcloud
      MYSQL_USER: nextcloud
      MYSQL_PASSWORD: замените_на_свой_пароль
    volumes:
      - nc_data:/var/www/html

volumes:
  db_data:
  nc_data:

sudo docker compose up -d

Дальше через веб-мастер создаётся администратор, настраивается домен (лучше сразу за обратным прокси с HTTPS, если сервер будет доступен по имени домена), и можно создавать структуру папок по объектам — каждая как отдельная папка верхнего уровня. Подробный пошаговый разбор установки, включая нюансы с правами файлов и обратным прокси, есть в статье про установку Nextcloud на VPS.

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

Права доступа и версии: кто что видит и как найти прошлый вариант

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

Создание групп и пользователей через консольную утилиту occ (выполняется внутри контейнера):

sudo docker exec -u www-data -it nextcloud-app-1 php occ group:add obj-lenina15
sudo docker exec -u www-data -it nextcloud-app-1 php occ user:add --group=obj-lenina15 proveryayuschy

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

Отдельно стоит упомянуть версионность файлов — встроенную функцию, которая закрывает ровно ту проблему с «финал2» и «финал3». При каждом сохранении и синхронизации файла Nextcloud сохраняет предыдущую версию, и в панели файла можно открыть историю изменений и вернуться к любой из них, посмотреть, кто и когда сохранял. Это избавляет от необходимости вручную плодить копии с номерами в имени — файл всегда один, «Смета_Ленина15.xlsx», а вся история правок хранится внутри системы, а не в названии файла.

Для крупных объектов, где расчёты и таблицы весят заметно, стоит сразу продумать дисковые квоты на пользователя или на объект, чтобы архив по одному крупному объекту не съел всё место, отведённое под остальные девять. Логика настройки квот для нескольких пользователей на одном сервере не специфична для смет — она разобрана универсально и подойдёт как есть.

Резервные копии: архив смет — это то, что нельзя терять

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

Минимальная рабочая схема — регулярный rsync данных Nextcloud и дампа базы на отдельное хранилище (второй диск того же сервера этого не даёт — при отказе диска или сервера целиком архив пропадёт вместе с оригиналом):

#!/bin/bash
# backup-nextcloud.sh
BACKUP_DIR=/mnt/backup/nextcloud/$(date +%F)
mkdir -p "$BACKUP_DIR"

sudo docker exec nextcloud-db-1 mysqldump -u root -p"$MYSQL_ROOT_PASSWORD" nextcloud > "$BACKUP_DIR/db.sql"
rsync -a ~/nextcloud/nc_data/ "$BACKUP_DIR/files/"

И в crontab -e:

0 3 * * * /home/user/backup-nextcloud.sh

Стоит хранить копии за несколько последних дней, а не только последнюю — если ошибка или случайное удаление обнаружится не сразу, свежая резервная копия может уже содержать ту же проблему. Общий подход к тому, сколько ресурсов закладывать под резервные копии и архив и как выбрать схему хранения, разобран в статье про VPS для бэкапов и архива.

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

Частые вопросы