Ограничения секций и единый порядок формирования отчетов по объектам учета

Контекст. С нуля настраиваем ЛЭРС Учет для нескольких управляющих компаний. Ранее они использовали другую систему, поэтому у нас есть четкое понимание требуемого результата. Уточняю это, чтобы обозначить: обходные решения допустимы, но они должны быть действительно временными.

Более 15–20% многоквартирных домов этих управляющих компаний имеют два и более узла управления с учетом. Есть дома с 9, 11 и даже 17 УУ. Для таких объектов предполагается использовать секции.

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

Однако внедрение секций в существующих системах при текущей реализации требует значительных трудозатрат. При этом доступные функции ограничивают их применение на объектах с несколькими ИТП или УУ.

Почти сразу я обнаружил три основных ограничения.

1. Жестко заданная структура секции

В секции предусмотрены:

  • один контур учета теплоснабжения, возможно с подпиткой;

  • один контур ГВС, возможно с подпиткой;

  • один канал ХВС;

  • один канал электроснабжения с резервным каналом.

Мне непонятно, зачем нужна такая жесткая структура, если цель секций — упростить работу с отчетами. В частности, почему предусмотрен только один контур отопления? Как использовать секцию, если есть две подачи или три подачи с одной обраткой? В моем понимании, секция должна представлять собой отдельную часть объекта, для которой можно создать простой отчет.

Это не теоретическая ситуация: указанное ограничение исключает использование секций примерно для 60% сложных отчетов в моей практике, в том числе в текущем проекте.

Например, есть объект с четырьмя ИТП:

ИТП 1
Отопление: четыре ввода, одна обратка.
ГВС: бойлер с циркуляцией и подпиткой, а также летняя ГВС.

ИТП 2
Отопление: три ввода, одна обратка.
ГВС: бойлер с циркуляцией и подпиткой, а также летняя ГВС.

ИТП 3
Отопление: два ввода, одна обратка.
ГВС: бойлер с циркуляцией и подпиткой, а также летняя ГВС.

ИТП 4
Отопление: четыре ввода, одна обратка.
ГВС: бойлер с циркуляцией и подпиткой, а также реверс бойлера с учетом на одной трубе.

В этом примере ни отопление, ни ГВС нельзя описать с помощью секций так, чтобы структура объекта оставалась понятной пользователю. Причем ГВС, то распространенная схема учета

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

Одного канала ХВС тоже бывает недостаточно.

2. Один отчет на секцию

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

При текущем ограничении для каждого ресурса придется создавать отдельную секцию. В результате одна фактическая часть объекта будет представлена несколькими секциями, что усложнит структуру объекта и она, как я писал выше, перестанет быть “понятной пользователю”.

3. Отдельный тип отчета для объектов с секциями

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

Чтобы получить отчет по объекту с секциями, нужно выбрать не «Ведомость параметров», а отдельный тип — «Отчет по секциям объекта учета». С точки зрения пользователя я не вижу причины для такого разделения.

Типичный пример из моей практики, где стоит использовать секции, — система с 50–200 МКД, из которых 5–15% имеют секции. При текущей реализации секция, пользователю нужно заранее знать, какой отчет формировать по каждому объекту.

Для этого придется вводить дополнительный способ различать объекты:
Я придумал 4 варианта, все кривые, но лучше не придумал:

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

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

Для специалиста, который регулярно формирует отчеты и знает принятые обозначения, различие между объектами будет понятным, хотя и сильно усложнит работу с ЛЭРСом. Но пользователь, который преимущественно анализирует данные и лишь изредка получает отчеты о потреблении, может не помнить это правило. Для него объекты выглядят одинаково, а необходимость выбирать между «Ведомостью параметров» и «Отчетом по секциям объекта учета» неочевидна.

Проблема не в том, что правило недоступно пользователю, а в необходимости помнить дополнительное условие при эпизодической работе с системой.

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

У этого разделения есть и другое следствие: автоматическая рассылка отчетов будет приходить двумя частями — отдельно по объектам без секций и отдельно по объектам с секциями.

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

Предлагаю сделать структуру секций гибкой по количеству контуров и каналов учета, разрешить назначать несколько отчетов на секцию и обеспечить единый порядок формирования и автоматической рассылки отчетов по объектам независимо от наличия секций.

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

Мне нужна реакция разработчиков ПО, чтобы понимать как двигаться дальше в проектах, где напрашивается использование секций