Арбитражный управляющий ведёт десятки дел: реестры и документы на сервере

MAATRIX

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

Десятки дел, один ноутбук: где это ломается

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

Классическая картина: часть файлов на рабочем ноутбуке, часть — в письмах с вложениями, часть — в общей папке облачного диска, куда когда-то давно скинули документы и забыли структуру. Реестр требований кредиторов существует в трёх версиях Excel с именами вроде «РТК_финал_2.xlsx» и «РТК_итоговый_испр.xlsx», и никто не может с уверенностью сказать, какая из них актуальна. Если ноутбук потерян, украден или просто завис перед заседанием суда — под ударом не абстрактные рабочие файлы, а материалы по делам о банкротстве, часть которых содержит чувствительную финансовую информацию должников и кредиторов.

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

Что должно жить в единой системе

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

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

По отдельности каждый из этих потоков несложно вести. Но когда их десятки одновременно по разным делам, а каждый поток ещё и меняется во времени, ручное «где-то у меня было» превращается в системный риск — и для текущей работы, и для последующей отчётности, если кто-то (суд, СРО, кредитор) попросит поднять историю по конкретному делу.

Структура: как разложить дела, чтобы не потеряться

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

/srv/dela/
├── 2024-018-bankrotstvo-ooo-stroyresurs/
│   ├── 01-sudebnye-akty/
│   ├── 02-reestr-trebovaniy/
│   ├── 03-perepiska/
│   ├── 04-inventarizaciya-ocenka/
│   ├── 05-torgi/
│   ├── 06-otchety/
│   ├── 07-efrsb-publikacii/
│   └── delo.md
├── 2024-025-bankrotstvo-ivanov-ip/
│   ├── 01-sudebnye-akty/
│   ├── ...
│   └── delo.md
└── _shablony/
    └── struktura-dela/

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

Такую структуру удобно поднять на своём VPS через файловый сервис вроде Nextcloud — он даёт веб-интерфейс, синхронизацию на компьютер и телефон, а также встроенное версионирование файлов, что критично для документов, которые правятся многократно. Установка на чистый сервер занимает не так много времени, если следовать пошаговой инструкции — этот процесс подробно разобран в статье про установку Nextcloud на Ubuntu 24.04. У юристов похожая по сути задача — держать материалы дел в одном месте и не терять версии — решается тем же путём, и в статье про хранение материалов дел юриста на своём сервере можно посмотреть на организацию с другого профессионального угла.

Реестр требований кредиторов: от Excel на флешке до общей базы

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

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

Версионирование через файловый сервис. Если РТК ведётся в таблице на сервере с включённым версионированием (Nextcloud хранит историю версий файла из коробки), у вас всегда есть возможность откатиться к состоянию на конкретную дату и посмотреть, кто и когда вносил правки — это снимает львиную долю споров «а что было в реестре на момент собрания».

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

CREATE TABLE registry_claims (
    id SERIAL PRIMARY KEY,
    case_id TEXT NOT NULL,
    creditor_name TEXT NOT NULL,
    claim_amount NUMERIC(14,2),
    priority_order TEXT,
    status TEXT,
    included_at DATE,
    basis_document TEXT
);

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

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

Резервные копии и доступ из зала суда, дома, в дороге

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

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

# первичная инициализация репозитория бэкапов
restic -r /mnt/backup-storage/dela init

# ежедневный бэкап с тегом по дате
restic -r /mnt/backup-storage/dela backup /srv/dela --tag dela-$(date +%F)

# автоматическая очистка старых версий
restic -r /mnt/backup-storage/dela forget --keep-daily 14 --keep-weekly 8 --keep-monthly 12

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

Для удалённого доступа без лишних рисков разумно закрыть сервер VPN-туннелем (например, WireGuard) и не открывать веб-интерфейс напрямую в интернет всем подряд — тогда доступ к материалам дел есть только у тех, кто подключён через ваш собственный туннель, а не у любого, кто подберёт пароль на публичной странице входа.

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

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

Практичная модель — группы доступа на уровне файлового сервиса:

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

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

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

С чего начать: минимальный рабочий набор

Разворачивать всё и сразу необязательно — систему можно собирать поэтапно, начиная с самого нужного:

1. Арендуйте сервер под задачу — файловое хранилище с реестрами и документами не требует мощного железа, важнее стабильный канал и достаточный объём диска под растущий архив дел.
2. Поднимите файловый сервис (например, Nextcloud) и создайте структуру папок по делам — на старте достаточно единого шаблона на все текущие дела.
3. Перенесите активные дела — начните с тех процедур, где документооборот идёт прямо сейчас, архивные дела можно перенести позже без спешки.
4. Настройте автоматический бэкап сразу, а не «когда будет время» — на этапе переноса данных риск потери максимален.
5. Заведите группы доступа для помощника и приглашённых специалистов — прежде чем появится необходимость срочно кому-то что-то передать.
6. Закройте удалённый доступ VPN-туннелем, если планируете работать не только из офиса.

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

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