то я ни раньше не понял что точно это значит, ни сейчас.
Поразмышляю. А Вы поправите. Сейчас 1 объект - это здание/сооружение - 1 лицензия с не более 10 точками.
Объект должен обладать уникальностью для набора адрес + название объекта.
Вы, возможно, но я не уверен, предлагаете разорвать адрес и название объекта и сделать 3 уровневую иерархию: адрес/название объекта/точка учета.
Наверное это сделает какие-то вопросы использования программы оптимальнее, но для прочих объектов, на мой взгляд, создаст серьезную избыточность.
Количество сложных объектов для меня не понятно. Я не встречал такого, чтобы мне нужна была 3 уровневая иерархия для выделения ИТП. Хотя для проектов в промышленности это бы не помешало.
Однозначно нужны примеры с пояснением на объектах как именно должна измениться система. И зачем это изменение, т.е. алгоритм использования.
И все таки, описание 1-2 объектов из-за которых Вы хотите это изменение
Экземплярам справочника “дома/адреса” я предлагаю перенести данные из объекта, а именно:
адрес
геопозиция
размещение
код фиас
потребитель
поквартирный учёт
обслуживание
остальное оставить как есть.
П.С. и это без учёта “сложных домов” в которых есть ЦТП или транзитная схема подключения ИТП(что я смог бы реализовать через объект-источник в том же доме/адресе)
именно это я и предлагаю. Избыточность мнимая, при первом приближении структура выглядит сложнее, при минимальном вникании всё встаёт на свои места. Текущая структура вводит в ступор сильнее. На этапе интеграции слово “подпитка” каждый раз заставляет придумывать отмазы в защиту программы.
А как такая группировка решит изначальный вопрос с подпиткой? Может, я не совсем понимаю в чём главная причина этого предложения? Изначально я понял, что будет проще настраивать точки теплоснабжения, так как сразу будет присутствовать понятие “Подпитка”. Оно мне, в принципе, показалось логичным, но трудоёмким, поэтому, сроки я определить не могу.
Однако, ваше предложение с какой-то дополнительной иерархией не упрощает систему, а наоборот усложняет. И, как я вижу, основная идея этой доработки в том, что вы не можете покупать дополнительные лицензии, чтобы использовать существующую иерархию. Но руководство не позволит мне вносить какие-то изменения, которые позволят использовать одну лицензию с несколькими объектами, это сто процентов.
Если формировать отчёты не по точкам учёта, а по объектам вопрос с подпиткой закрывается сам собой. Но, если, в объекте учёта несколько ИТП(к примеру 10) - это превращается в кошмар. Необходимо создать 10 отчётов и 10 отчётных форм(по 1 на каждый ИТП), а также приходится выносить кучу параметров в пользовательские атрибуты. Такие как источник, договор, акт допуска, РСО…
Раскидать ИТП по разным объектам сейчас невозможно, так как адрес, наименование, код фиас уникальны.
П.С. Предлагаемое изменение порядка лицензирования происходит “на словах”, так как сейчас вы подразумеваете, что объект учёта это дом. Так и останется: 1 лицензия = 1 дом = 10 точек учёта.
Это тот же самый подход, только с другого ракурса. Впихивание “слоя” иерархии между объектами и точками. Отличается лишь сложностью разработки.
Также, он менее интуитивен, и обусловлен попыткой закрыть глаза на логическую ошибку(дом=объект учёта).
Но если это единственный вариант решения, пусть будет хотя бы так.
Т.е. у вас обычные дома, которые строят по всей стране. С ними есть проблема в сложности подготовки отчетных форм, чтобы печатать отчеты по объекту. Но это преодолимо.
Вот в этом Ваша особенность. И это вносит в подготовку отчетов дополнительную сложность, особенно если у РСО происходит миграция элементов транспортной сети и источников между юр.лицами.
Это становится проблемой, когда нужно привести многостраничные отчеты в соответствии текущей ситуации в короткий срок.
Т.е. понятна причина по которой требуете изменения.
Да это так. Мы предложили очень похожие вещи. Создать дополнительный элемент группировки и назначать для него примитивные отчеты.
Есть видимо отличие. И это стоит обсудить. Я предлагал при печати, собирать отчет по объекту из примитивов в один отчет, а Вы, видимо, печатать их по отдельности, наверное отфильтровав их каким-то образом.
В любом случае, дополнительная явная или неявная иерархия и назначение отчетов примитивов решает ваш вопрос. Так?
Почему секции. В моей вселенной, дома с многими ИТП еще на этапе строительства часто делятся на секции. И название “секция” привычно в моей практике, причем и в среде строителей, и в среде эксплуатации зданий, и в среде РСО.
А вот если назвать секцию/ИТП - объектом, то нужно будет каждый раз объясняться. Притом, что объектом ранее называлось другое. Да и смена смысла при неизменности названия - “сломает голову” пользователям
Оставим секцию как есть, секция она и есть секция. А объектом учёта пусть будет объект учёта(ИТП/ГРЩ/ВУ). Мы уже обсуждали секции в другой теме. У нас почти никогда “секции” по электроснабжению не совпадают с “секциями” по теплоснабжению, а ещё есть ХВС и ГВС.
На текущий момент вокруг объектов построено множество удобных инструментов, и они будут работать только лучше, при разделении дома на объекты учёта вида ИТП/ГРЩ/ВУ, и, что важно, без дополнительных доработок.
Пользователям не обязательно что-то менять. Экземпляры “адресов” будут созданы автоматически из свойств существующих объектов учёта. Разделять дома на объекты ИТП/ГРЩ/ВУ они смогут опционально, либо оставить всё как есть.
Для меня секции выглядят избыточным инструментом, если удастся ввести уровень иерархии “сверху”, но возможно для каких-то целей он будет удобен, пока я этого не могу увидеть.
Вы подразумеваете секции Жильё/Нежильё/Паркинг? Если да, внутри секции всё так же может быть несколько ИТП. 5 на жильё, 2 на нежильё, 1 на паркинг.
Опять же, при разделении строения на объекты учёта можно будет создавать транзитные объекты-“источники”, такие как ЦТП. С Электроэнергией такие транзитные узлы - нормальная практика. Например 4 ввода(по 2 ПУ на ввод) и 16-20 внутренних ГРЩ(по 2 ПУ каждый) питающихся с этих вводов для корректного распределения по потребителям.
Я уверен, предложение хорошее. Но, на мой взгляд, Вы его изложили противоречиво.
Вы явно описываете 3-уровневую иерархию и при этом: “Пользователям не обязательно что-то менять.” и “Разделять дома на объекты ИТП/ГРЩ/ВУ они смогут опционально, либо оставить всё как есть”
Я не представляю одновременно то 2, то 3 уровневую систему и при этом достаточно простую, чтобы она была интуитивно понятной.
Кроме того. Выдержка из РЭ на ПО
" Объект учёта - это базовое понятие ЛЭРС УЧЁТ, которое объединяет все остальные сущности. Объект представляет собой отдельно стоящее здание/сооружение с собственным адресом."
и
“Комбинация из наименования объекта и его адреса уникальна и не может повторятся в системе.”
А вы присваиваете термину совершенно другой смысл и далее оперируете термином “объект” только с новым Вашим смыслом:
Это сильно путает, с точки зрения обсуждения и это плохое предложение именно из-за названия “объект”. Это будет большой путаницой в продажах и поддержке ПО, сломает текущую модель лицензирование, дальше не анализирую.
И замена будет стоит немалых денег: я не могу оценить во времени написания кода, тестирования и исправления документации, но могу оценить усилия по поддержке, изменению сопроводительных видео и прочих материалов у производителя, у их партнеров, переучиванию в продажах и т.д… При этом есть еще частная документация крупных клиентов на конкретные системы на базе ЛЭРСа, ее тоже нужно привести в соответствие.
А с другой стороны. не понятны до конца плюсы от этого изменения. С учетом затрат, плюсы должны быть ПЛЮСами. Пока Вы широкими мазками набросали, на мой взгляд, новую модель, содержащую противоречия.
А теперь про секцию. Как я и писал. По сути, Ваше предложение не очень отличается от моего. Меня напрягает - слово “объект” и отделение его от адреса.
Хотелось бы услышать более сильный аргумент
“Секция” сейчас только появилась. Вообще не видна обычным пользователям ПО. Этому термину можно придать разный смысл, дополнить смыслом без особого ущерба. Именно поэтому я и предложил расширить понятие “секция”
На секции Вы можете делить здание так, как Вам и Вашим клиентам удобно в конкретной системе/здании. Это же логический элемент, не более, Вы вправе сами определять его точный смысл в конкретном случае.
Например. Можете секции присвоить названия: ИТП1. ИТП2. ИТП3, а внутри собрать все нужные Вам точки учета.
А можете секциями назвать кострукт, связанный с ресурсами и РСО. Например:
РСО1.Тепло
РСО2.Тепло
РСО3. Электроэнергия
РСО4. Электроэнергия
Способ делить на секции в каждом случае можно и нужно выбирать исходя из целей, ну и чтобы пользователи понимали это деление.
и
Две цитаты - это описание одного и того же. Вам удобно печатать отчеты по
точке учета(если бы в ней была подпитка)/ИТП/ объекту (в вашем смысле)/секции (в моем смысле).
Но сейчас в ЛЭРСЕ еще можно печатать отчет целиком по объекту. В моей практике встречаются оба способа.
Я попытался обозначить, что оба способа должны работать после нововведений
Представил в голове вариант с секциями, и решил наделать “предложений по улучшению” в этом направлении. Оказалось их надо очень много, причём некоторые довольно спорные. К примеру:
Добавить тип объекта “Секция” для отчётных форм.
Перенести “Режим работы” из Объекта учёта в Секцию.
Перенести темп. хол. воды из Объекта учёта в Секцию.
Перенести РСО со всеми свойствами из Объекта учёта в Секцию.
Перенести Источники со всеми свойствами из Объекта учёта в Секцию.
Перенести Температурный график со всеми свойствами из Объекта учёта в Секцию.
Перенести Документы со всеми свойствами из Объекта учёта в Секцию.
Перенести Энергоснабжающая организация со всеми свойствами из Объекта учёта в Секцию.
Добавить функционал справочника Объекты учёта справочнику Секции.
Добавить описание инструмента Секции в РЭ.
А теперь рассмотрим вариант добавления Адрес/Дом в иерархию над Объектами учёта:
Создать справочник Адреса/Дома.
Изменить порядок лицензирования “1 лицензия = 1 объект(10 точек)” на “1 лицензия = 1 дом/адрес(10 точек)”
Добавить функционал справочника Объекты учёта справочнику Адреса/Дома.
Перенести свойство Адрес объекта учёта в свойства Адреса/Дома.
Перенести свойство ФИАС объекта учёта в свойства Адреса/Дома.
Перенести свойство Геопозиция объекта учёта в свойства Адреса/Дома.
Перенести свойство Размещение объекта учёта в свойства Адреса/Дома.
Перенести Поквартирный учёт со всеми свойствами из Объекта учёта в Адреса/Дома.
Описать изменения в РЭ
Первый список выглядит сильно масштабнее, и это огромный труд не только для разработчиков но и для пользователей.
Во втором варианте у пользователей останется всё по прежнему, и при желании они смогут изменить конфигурацию объектов.
Ну именно это я и называл отчетами “примитивами”. Это упрощает создание отчетов для домов с многими ИТП.
Это актуально для объектов, где на одном доме более 1 РСО поставляют 1 ресурс. До сих пор их это были редкие/маргинальные случаи и их приходилось решать отдельно и почти всегда это у РСО, а не у УК. В Вашем случае их много и нужно предлагать решение и для этих случаев.
Это ситуационно. Это просто документы. У меня до сих пор нет рабочих, хороших вариантов их использования.
Это два разных пункта?
Непонятно о чем речь.
Уже эти пункты мне сломали мозг
Резюме того, что я писал ранее: Вы предлагаете взять 1 из двух основных терминов в ПО, который был самого начала присутствия ПО на рынке и придать ему новый смысл. Я предложил этот смысл приложить к другому элементы программы, который появился, вроде 2-3 месяца назад, и который почти все пользователи не видят/не обращают внимания.
Это почти все отличие вариантов.
Особо большого функционала по балансу нет, его нужно развивать. Его, на мой взгляд, не нужно переносить, он будет ситуационно востребован и на всех уровнях.
