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