Система онлайн-управления общежитием: места, договоры, финансы и оплата вместо бумаги и таблиц

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

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

Проблема: общежитие на ручном управлении

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

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

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

Три роли: администратор, комендант, жилец

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

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

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

Учёт мест без двойных броней

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

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

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

Договоры, финансы и должники

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

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

Онлайн-оплата с проверяемым вебхуком

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

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

Аналитика, личный кабинет и заявки

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

Жилец получил личный кабинет, где видит свои начисления и статус оплаты, подаёт заявки (например, на ремонт или бытовые вопросы) и получает уведомления. Заявки перестают теряться между устными просьбами: они попадают в систему, у них есть статус, и комендант работает с ними как с очередью, а не как с ворохом записок. Уведомления держат жильца в курсе — о новом начислении, о статусе заявки, о важных событиях. Так система закрывает не только учёт, но и живую коммуникацию между общежитием и его жителями.

Стек, безопасность и 152-ФЗ

Систему я построил на надёжном и полностью открытом стеке: серверная часть на FastAPI с базой данных PostgreSQL, интерфейс на React. Никакой привязки к проприетарным платформам — заказчик владеет всем кодом и может развивать систему дальше с любым разработчиком. Разворачивается всё в контейнерах, что делает переустановку и перенос предсказуемыми, а за фасадом стоит веб-сервер с HTTPS-шифрованием.

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

Что получил заказчик

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

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

Кому подойдёт такое же решение

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

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

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

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

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

Где хранятся данные жильцов и как с 152-ФЗ? Данные жильцов — персональные, поэтому система спроектирована под хранение на подконтрольном сервере, а не в чужом облаке, с авторизацией по ролям, защищённым хранением паролей и автоматическими резервными копиями базы. Это соответствует требованиям к хранению персональных данных.

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

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

Сколько времени занимает внедрение? Срок складывается из проектирования модели данных, разработки ролей и интерфейсов, интеграции оплаты и тестирования на реальных сценариях заселения. Для системы такого масштаба это вопрос последовательных этапов, а не одной короткой итерации.

Коротко о главном

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

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