| Цитата |
|---|
| Поскольку на квитанциях УИН нет - все и ставят 0. |
Может быть и так. Во многих случаях даже и квитанции нет, только протокол о штрафе. Однако это тем более должно подталкивать банки включить в логику оплаты запрос начислений - а если нужного все-таки нет, то ввод вручную. Иначе какой смысл в идентификаторах, если их вбивать вручную, несмотря на то, что они есть в ГИС.
| Цитата |
|---|
| Этим общение банка с ГИС ЖКХ и заканчивается - ГИС ЖКХ не передает банку и не спрашивает у банка никакие персональные данные. |
Хм... В схеме предусмотрено как минимум необязательная передача ФИО (само ФИО может и не потянет на персональные данные, но там еще есть и адрес, который отдельно не тянет на персональные, но вместе в одном сообщении они уже потянут), и мне не вполне ясно на основе чего формируется идентификатор плательщика (по аналогии предполагаю что паспорт для физлиц), так что не убедили. Кстати, для запроса начислений тоже нужно передать персональные данные или хотя бы адрес, чтобы получить список начислений.[spoil:a5xccb46]hcs-payment-types.xsd[code:a5xccb46]<xs:element name="Individual">
<xs:annotation>
<xs:documentation>Потребитель-физическое лицо, в том числе индивидуальный предприниматель</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="individual-registry-base:FIOType"/>
</xs:complexContent>
</xs:complexType>
</xs:element>[/code:a5xccb46]hcs-payment-base.xsd[code:a5xccb46]<xs:element name="SupplierInfo" minOccurs="0">
<xs:annotation>
<xs:documentation>Сведения о потребителе</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="SupplierID" minOccurs="0">
<xs:annotation>
<xs:documentation>Уникальный идентификатор плательщика</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:maxLength value="25"/>
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="SupplierName" minOccurs="0">
<xs:annotation>
<xs:documentation>Наименование плательщика</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:maxLength value="160"/>
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Ind" type="individual-registry-base:FIOType">
<xs:annotation>
<xs:documentation>Физлицо, не являющееся индивидуальным предпринимателем</xs:documentation>
</xs:annotation>
</xs:element>[/code:a5xccb46][/spoil:a5xccb46]
| Цитата |
|---|
| банк запросит и проверит паспорт |
ЖКХ многие платят через терминал - терминал паспорт не запросит. Так что утвержение не в полной мере верно.
| Цитата |
|---|
| 1) генерации уникального ЕЛС (связки "плательщик-помещение") |
Если он всего один - он и так уникален, но если больше (в том числе, например, сменился потребитель) совершенно согласен. Тут у нас разногласия нет.
| Цитата |
|---|
| им может быть НЕ ТОЛЬКО собственник помещения по данным ЕГРН |
Убедили. Но тогда получается связь с ЕГРН постольку-поскольку. Основная проблема тогда получается в том, что это самое лицо, которому нужно все раскрыть очень сложно установить, чтобы выяснить чьи реквизиты вбить - те же недееспособные и умершие тоже имеют паспорт и нет никакого механизма установить что человек стал недееспособным или умер, пока опекуны/наследники не принесут документы. Предлагаю все же закругляться с "теорией" пока нас снова не наругали "практики".
такие помещения и связывает их с лицевыми: комнаты в разделенной квартире - это отдельные помещения с номерами, напр. "3/1" и "3/2", либо это помещение коммунального заселения "3", к которому добавляются комнаты с номерами "1" и "2" (у каждой кадномер).
Опыта ноль.
