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

В коммерческом объекте мы начнём с организации-арендатора и её договоров. Например, одна компания может занимать офис и склад, получать отдельные счета и назначать разных сотрудников для общения с УК. Такой состав отличается от приложения для жителей дома: модель лицевого счёта квартиры нельзя автоматически переносить на аренду торговой площади.
Помещения, договоры и права: основа оценки
До оценки интеграций мы разберём, где ведутся организации, помещения и договоры. Для каждой записи нужен устойчивый ключ: внутренний идентификатор, по которому системы узнают один и тот же объект. Номер офиса помогает человеку найти помещение, но может повторяться в разных зданиях и сохраняться после смены арендатора.
Представьте, что у компании два договора. Бухгалтеру нужны счета по обоим, а администратору офиса нужны обращения только по одному помещению. Если ограничиться общим аккаунтом организации, придётся раздавать лишние права или вручную пересылать документы. В состав разработки стоит включить приглашение сотрудников, назначение доступа и его отзыв.
Мы предложим матрицу ролей: кто видит финансовые документы, кто создаёт обращения, кто приглашает коллег и кто подтверждает их полномочия. Управление доступом к счетам требует отдельного решения. Администратор арендатора сможет выдавать эти права только в пределах, которые утвердит управляющая компания.
Смена сотрудника и завершение договора тоже входят в сценарий. Нужно согласовать доступ к архиву, срок хранения документов и порядок отключения аккаунта. Затем проверить запреты на сервере: запрос по прямой ссылке на чужой файл должен получить отказ независимо от того, какие кнопки показаны на экране.
Как мы связывали заявку, статус и документы
В CentreVisa мы собрали личный путь клиента в мобильном приложении. В разделе «Мои заявки» человек видит обращения в работе и завершённые, а в чате заявки задаёт вопрос консультанту и обсуждает документы. История разговора остаётся рядом с обращением, поэтому клиент может продолжить работу с ним при следующем входе.
Реальный проект 13FOX
CentreVisa: вернуться к своей заявке
Два экрана показывают статус обращения и переписку с консультантом.


Для кабинета арендатора этот принцип поможет спроектировать эксплуатационное обращение: помещение, описание проблемы, ответ и статус должны быть связаны. Счета и договорные права мы разберём отдельным процессом с бухгалтерией и УК. Так можно использовать понятный пользовательский путь и сразу увидеть дополнительную работу для коммерческой аренды.
Готовый счёт и расчёт начислений: два состава работ
Если бухгалтерия уже рассчитывает аренду и выпускает счета, предлагаем сначала подключить получение готового документа. Кабинету понадобятся его ключ, договор, период, сумма, доступная редакция и файл. Согласуем момент публикации: черновик расчёта может существовать в учёте раньше документа, который разрешено показать арендатору.
Разработка собственного расчёта добавит другой объём. Например, понадобятся правила индексации, эксплуатационных платежей и распределения расходов по показаниям, если они предусмотрены договором. Для каждого правила нужно определить входные данные, порядок изменений и сверку с учётом. Эти работы стоит вынести в отдельный блок предложения, чтобы они были видны при сравнении цены.
Что проверить в 1С до фиксации сметы
Мы запросим название и версию конфигурации, способ размещения базы и пример нужного документа. Затем проверим, как получить счёт вместе с файлом, доступна ли связь с договором и какие операции разрешены. Отдельно выясним, потребуется ли работа специалиста 1С: например, создание сервиса, который отдаёт согласованный набор данных кабинету.
У платформы 1С есть стандартный REST-интерфейс: через него сервер кабинета запрашивает разрешённые записи по протоколу OData. В 1С:Фреш состав доступных объектов и права пользователя настраиваются отдельно. Если нужен специальный обмен, платформа позволяет создавать HTTP-сервисы. Такой сервис принимает запрос и возвращает данные по правилам, которые разработчик задаёт для конкретной задачи. Выбор способа подключения зависит от конкретной базы: наличие интерфейса ещё не определяет, какие данные и файлы можно получить для вашего сценария.
В «Бакаеве» мы помогли перенести локальную 1С в облако и связали её с админ-панелью магазина. Сервер синхронизации передаёт изменённое изображение из админки в 1С; заказ из приложения отражается в остатках админ-панели и учётной системы. Изменения из 1С проходят обратный путь к приложению. Для нового проекта мы так же разберём обе стороны обмена: кто изменяет данные, что получает другая система и как проверить результат.
Допустим, после загрузки бухгалтерия исправила счёт. Исправление может появиться как новая редакция или как отдельный связанный документ. В кабинете сохраним модель источника и покажем актуальный счёт по согласованному правилу. Если источник временно недоступен, арендатору нужно видеть время последней успешной загрузки. Ошибку обмена получит ответственный сотрудник, который сможет восстановить передачу и сверить результат.
Обращение должно попасть в работу службы эксплуатации
Для обращения о неисправности определим, где диспетчер принимает задачу и исполнитель меняет её статус. Если это действующая сервисная система, кабинет передаст туда помещение, категорию, описание и вложения, получит номер обращения и будет показывать согласованные статусы. При отсутствии такой системы отдельно оценим рабочее место диспетчера и исполнителя.
Уведомление по почте может быть достаточным для первой версии, если УК готова обрабатывать обращения вручную. Тогда в предложении нужно прямо указать этот этап и человека, который обновляет статус. Автоматический возврат статусов из сервисной системы потребует её интерфейса обмена и согласования того, какие внутренние состояния показывать арендатору.
Представьте, что сервисная система создала заявку, но ответ с её номером не дошёл до кабинета. Повтор должен найти уже созданное обращение по согласованному ключу. Мы включим этот сценарий в проверку, вместе с журналом ошибок и порядком повторной передачи. Аварийные обращения потребуют отдельного маршрута и резервного способа связи, которые утвердит УК.
Оплаты, показания и подписанные документы
Эти функции лучше оценивать отдельными строками после счетов и обращений. Для каждой нужно назвать источник подтверждения и действие сотрудника, которое кабинет позволит выполнить.
- Статус оплаты. Определим, где бухгалтерия подтверждает поступление и привязку денег к счёту. Приложенное арендатором платёжное поручение станет материалом для проверки. Статус «оплачен» появится по согласованному учётному источнику или после подтверждения уполномоченным сотрудником.
- Оплата из кабинета. Если нужна кнопка оплаты, отдельно проверим провайдера, условия подключения и сверку платежа с документом. Согласуем частичные платежи и ошибочное назначение, если такие сценарии входят в процесс.
- Показания. Выберем источник: приборная система или ввод сотрудника арендатора. Для ввода потребуются связь прибора с помещением, дата, проверка значений и обработка исправлений. Передача показаний и расчёт начисления по ним имеют разный состав.
- Документы. Для скачивания договора определим версии и доступ. Если нужен электронный документооборот (ЭДО), то есть обмен документами с подписанием по выбранной процедуре, отдельно проверим полномочия подписанта, оператора, процедуру и интеграцию. Скачивание PDF само по себе не описывает такой обмен.
Например, архив счетов можно включить в первую версию, а подписание дополнительных соглашений вынести в следующий этап. Это даст конкретную границу проекта. Обязательные для выбранных действий права, обработку сбоев и проверку документов нужно сохранить в первоначальном составе.
Матрица для сравнения смет
Передайте подрядчикам одинаковый набор обезличенных данных и попросите заполнить таблицу. Для каждой строки нужны источник, результат обмена, включённые работы и исключения. Тогда станет видно, например, содержит ли предложение только список счетов или также получение файлов, обработку редакций и проверку доступа.
| Блок | Входные данные | Что должно быть в оценке |
|---|---|---|
| Организации и договоры | Источник организаций, помещений, договоров и их ключей | Связи, импорт, изменения договора, архив и исправление неверных связей |
| Счета из учёта | Обезличенный счёт, файл, период и пример исправления | Получение данных и файла, редакции, права, актуальность, сверка; работа специалиста 1С отдельной строкой |
| Обращения | Одна заявка и маршрут от диспетчера до закрытия | Создание, вложения, возврат номера и статуса, уведомления, повтор после сбоя |
| Сотрудники арендатора | Роли и доступ по двум разным договорам | Приглашение, подтверждение полномочий, отзыв, проверка доступа к файлам и действиям |
| Дополнительные функции | Источник оплат, приборы или процедура ЭДО | Каждая интеграция и её исключения отдельно; необходимые внешние подключения |
| Запуск и сопровождение | Старые документы, тестовые роли, ответственные | Перенос, проверка сценариев, обучение, наблюдение за обменом, размещение и поддержка |
К таблице добавьте две границы: что входит в первую версию и что остаётся во внутренних системах. Например, бухгалтерия выпускает счёт в 1С, кабинет показывает его арендатору, а сервисная система ведёт работу исполнителя. Так ответственность за изменение данных остаётся понятной всем участникам.
Например, в оценке получения счёта выделите работу разработчика кабинета и специалиста 1С. Перенос старых документов и поддержку после запуска тоже попросите указать отдельно. Рядом с итогом должны стоять допущения: доступен ли нужный обмен, кто исправляет исходные данные и какие функции перенесены на следующий этап. Платежи внешним сервисам подтвердите для выбранных условий.
Как проверить первую версию на одном договоре
Согласуйте с УК один основной обезличенный договор, связанное помещение, счёт с исправлением и эксплуатационное обращение. Для проверки ограничений добавьте второй договор той же организации, его счёт и сотрудника без доступа к нему. Понадобится и пользователь другой организации. На этом наборе можно проверить основной сценарий и ограничения доступа ещё до подключения всех арендаторов.
- Открыть договор и счёт. Проверить связь помещения, периода, суммы и файла с источником. Сотрудник без доступа ко второму договору не получает его счёт.
- Исправить счёт в источнике. Убедиться, что кабинет показывает актуальный документ и понятную историю исправлений.
- Создать обращение. Диспетчер получает помещение, описание и вложение; арендатор видит номер. После смены статуса в рабочей системе обновляется кабинет.
- Прервать обмен и повторить запрос. Проверить актуальность данных, журнал ошибок и предусмотренную обработку повтора, включая пропавший ответ о создании заявки.
- Проверить чужой файл и отзыв прав. Запросить документ под другим пользователем, отключить сотрудника и проверить доступ при следующем обращении к серверу.
- Проверить подтверждение оплаты, если оно входит в первую версию. Приложить платёжное поручение и убедиться, что статус следует утверждённому процессу.
Результат каждого шага запишите в критерии приёмки. Если счёт скачивается, но статус обращения приходится искать вручную, это должно соответствовать согласованной границе первой версии. С этой матрицей и критериями приёмки можно перейти к разработке кабинета арендатора.
Частые вопросы перед оценкой
Можно ли начать со счетов и обращений?
Да, если определены источники, связи с договорами и права. Для первой версии можно получить готовые счета и подключить один маршрут обращения, а оплаты, показания и ЭДО оценить следующим этапом.
Подойдёт ли наша существующая 1С?
Проверим конфигурацию, размещение базы, доступные объекты и получение файла счёта. Если нужный обмен уже есть, используем его. Если понадобится доработка на стороне 1С, выделим её в составе работ.
Почему число арендаторов не даёт готовую цену?
Количество влияет на перенос данных, нагрузку и сопровождение. Состав разработки также зависит от договоров, ролей, источников и исключений. Один арендатор с несколькими договорами и процедурами может потребовать больше правил, чем множество арендаторов с одинаковым сценарием.
Нужно ли делать отдельное мобильное приложение?
Сначала проверим частоту действий и условия работы. Для скачивания счетов и обычных обращений можно рассмотреть адаптивный веб-кабинет. Если сотрудникам нужны регулярные действия с телефона и особые мобильные функции, оценим их отдельным составом.
Разберём состав вашего кабинета арендатора
Покажите договор, обезличенный счёт и обращение. Мы разберём источники, роли и путь данных, составим перечень интеграций и работ для оценки первой версии. Оставьте контакт в форме: согласуем, как передать примеры.