Форум

Главнаяtwo_oceans

two_oceans

Форум

Дата создания

Выбрать дату в календареВыбрать дату в календаре

Тема

Сообщение

Упорядочить

Выбрать дату в календареВыбрать дату в календаре

Минкомсвязи: «Новые ГОСТы для нормальной работы ГИС ЖКХ? Нет, не слышали…»
 
[QUOTE]Andrey_S пишет:
Дело полезное (шум в таких делах нужен), но за реализацию дизлайк. В наличии передергивание и неаккуратность с фактурой.
ГИС ЖКХ не единственная информационная система, не готовая к ГОСТ 2012...
... для всех из которых без исключения этот вопрос нужно признать более насущный, т.к. они могут размещать информацию исключительно через сервисы СМЭВ (с квалифицированной ЭЦП).[/QUOTE]В целом соглашусь, шум нужен, но текст не точно отражает картину. Процитированное окно появляется независимо установлен ли криптопровайдер и поддерживает ли он гост-2001. Тут хотелось бы заострить внимание что в TLS есть односторонняя аутентификация (когда сертификат клиента не запрашивается) и есть двухсторонняя аутентификация (когда сертификат клиента обязателен). В ГИС ЖКХ можно зайти просто по логину-паролю ЕСИА, обязательного запроса сертификата клиента нет (не берем в расчет ситуацию, когда по сертификату заходят в ЕСИА, хотя могли бы и по паролю зайти и ситуацию смены руководителя, когда ЕСИА требует ЭП руководителя. Заметьте тут везде ЕСИА, а не ГИС ЖКХ). Таким образом, ГИС ЖКХ при входе из личного кабинета вообще с сертифкатом не работает, картинка совершенно не отражает тему статьи, просто увидели что про гост написано и приплели до кучи. А ЕСИА умеет с гост-2012 работать. Проблема в основном для информационных систем, передающих информацию.

Хотя там тоже могут быть нюансы, например, неготовность это самой ГИС ЖКХ или неготовность СМЭВ. И конечно тут дело не в количестве, 673 ИС тоже немало и наверняка через них проходят миллионы записей, так что довод что "всего" 673 "подождут" неуместен, поэтому шум нужен. Однако будет ли эффект от шума?

Если это решать через госконтракт, то там есть сроки прописанные в законах и даже [U]если бы хотели[/U], то сделать и заключить контракт за неделю не получится, аукцион обычно занимает 30-40 дней. В целом, например, на форуме Криптопро сейчас полно вопросов по переходу решений на джаве на гост-2012, и там тоже не все так гладко, заменой пары строк программы дело не кончается надо обновлять джаву, а в новой версии как водится много еще чего поменяли кроме добавления поддержки гост-2012. Итого - крайне сомневаюсь, что реально поддержка гост-2012 даже во втором квартале появится (второй квартал = 1 апреля, уже через 37 дней), если взялись только в январе, а уж если возьмутся только после госконтракта, то ждите во второй половине года.

[quote:297cm73y]по нормативке формирование ключей по ГОСТ 2001 должно выполняться до конца 2019 года.[/quote:297cm73y]Про Минкомсвязи насколько помню им ГИС ЖКХ передали из Почты не так давно и они ужасно тугие на подъем - вспомните как гост-2012 запускали сначала с марта 2018 и в итоге еле запустили к концу года. Подозреваю, что запустили только из-за спешной отмены выпуска сертификатов гост-2001 с 1 января. Все еще интереснее: и сообщение Минкомсвязи про запрет выпуска с 1 января 2019 сертификатов алгоритма гост-2001 и сообщение про продление использования сертификатов алгоритма гост-2001 до 31 декабря 2019 (и сертификатов УЦ до 31 марта 2020 = 31 декабря 2018 + 1 год 3 месяца) [U]ссылаются на один документ[/U]. К слову, сам документ ФСБ все цитируют из Минкомсвязи, но вообще мало кто видел, так что немного неясно про какую нормативку речь. Скорее уж дело в разнице понятий [B]использование сертификата[/B] и [B]выпуск сертификата[/B]: уже выпущенный разрешено использовать, но новый нельзя получить - иначе сертификаты УЦ придется продлевать еще дальше.

Относительно перехода на гост-2012: факт о невозможности выпуска с 1 января 2019 года сертификатов гост-2001 всплыл еще в конце года и было уведомление от УЦ (например, УЦ Федерального казначейства) о необходимости срочно заменить сертификаты гост-2001 кому они нужны до конца 2019 года в связи с задержкой перехода информационных систем на гост-2012.  Как видно, уведомления УЦ до многих владельцев ИС не дошли и срок истечения сертификатов гост-2001 прошляпили. Полагаю, тут есть и частичная вина самих владельцев ИС, что они верили в своевременный переход ГИС на новый гост (как будто в раю живут, ага), за сроком своих сертификатов не проследили и пропустили уведомления УЦ мимо ушей. Подытоживая, ГИС ЖКХ и Минкомсвязь это не оправдывает, но и владельцам ИС надо помнить где живут и не терять бдительности.
Квитирование\Не сквитировано\Предварительно сквитировано\Сквитировано
 
[quote:3dasmdq9]А один банк вместо 5 000 руб прислал, что оплатили 500 000 руб.[/quote:3dasmdq9]Если разница в 100 раз, скорее всего, этот банк указал сумму в копейках, как по форматам ГИС ГМП, и это недоработка программного обеспечения. Очень желательно связаться с банком и сообщить им, что данные платежа видны в ГИС ЖКХ неверно. Пусть в свою очередь разберутся со своими программистами в чем проблема.
Росреестр и кадастровые номера помещений и домов
 
[QUOTE]Andrey_S пишет:
Но размещают они (РР) инфу через сервисы СМЭВ для ГИС ЖКХ, разработанные Ланитом[/QUOTE]А поподробнее почитать есть ссылка, что РР через интеграцию прицпелен? Какие у них роли? Судя по межведу - у РР достаточно тормозная сеть (или шлюз обмена со СМЭВ) внутри РР запрос может идти до 5 часов пока достигнет СМЭВ (видим по разнице в отметках времени между формированием и отправкой в СМЭВ). За это время чаще всего успевает закончиться рабочий день и мы видим запрос только на следующий день. Аналогично когда запрос посылаем мы, он шустро доходит до шлюза СМЭВ РР, через минуту регистрируется на их портале и зависает пока его увидят специалисты областного уровня. Минимальное время ответа отказом было около 40 минут. А так тоже может полдня где-то болтаться. Потом приходит почта с портала, что выполнен и втечение 20-30 минут появляется в СМЭВ. Так что думаю получится ужас, если сцепить РР через СМЭВ с ГИС жКХ.

Почему-то мне больше представляется, что все же обработка пакетная, как и с ФИАС. Выгружают дамп БД, а студенты Ланита при установке очередной версии пытается дамп "переварить".
ГИС ЖКХ: квитирование
 
[QUOTE]Andrey_S пишет:
Нет. ПД это не просто выставленный "счет к оплате", а подробная информационная выкладка о состоянии взаиморасчетов.[/QUOTE]Проясним. Я согласен, что промежуточные цифры по взаиморасчетам могут стать отрицательными, и даже что итог по конкретной услуге может стать отрицательным. Однако Вы говорите "с отрицательной суммой документа", то есть либо в документе всего одна услуга (серьезно?) либо другие услуги не компенсируют минус по конкретной услуге (бывает и такое?).
Также похоже есть разница в терминологии и "сумма документа" отличается от "сумма к оплате"? Как я понимаю, ГИС будет категорически сопротивляться факту, что "сумма к оплате" станет отрицательная и при обработке исправит на ноль. Поэтому я и спрашиваю, удалось ли кому-то перебороть эту особенность ГИСа и разместить ПД, не исправленный на ноль.
[QUOTE]Andrey_S пишет:
Как выставление ПД с положительной суммой начислений не означает, что по нему в течение месяца будет выполнена оплата, так и выставление ПД с отрицательной суммой не означает, что в течение месяца будет сделан возврат.[/QUOTE]Частично соглашусь. По крайней мере, отрицательная сумма по услуге А означает, что деньги из состояния "оплачены по услуге А" виртуально перешли в какое-то другое состояние, например, "к возврату" или "оплачены по услуге Б". Однако, полагаю, должен быть предельный срок при переходе между состояниями "к возврату" и "возвращены". Например, при денежных расчетах по выборам деньги должны быть возвращены в срок от 10 до 45 дней (в зависимости от ситуации).
Ошибки в ГИС (эмоции пост)
 
[QUOTE]Andrey_S пишет:
На прошлой неделе обсуждали это с представителями ЦА Сбера - получили подтверждение о том, что Сбер будет ставить вопрос о доработке сервиса перед Ланитом и регуляторами.[/QUOTE]Они паспорт сервиса читали?Цитата из паспорта [URL=https://smev.gosuslugi.ru/portal/services.jsp#!/F/MNSV10gisGKHtest/1.10/p00smev/SID0004157]сервиса[/URL] по ссылке выше, страница 7. Просмотрел по диагонали. [quote:2grejq6t]4) сведения о начисленном размере платы и имеющейся задолженности (предоставляются только в случаях, указанных в пункте 125 настоящего Порядка);[/quote:2grejq6t][quote:2grejq6t]Операция возвращает только те платежные документы, которые имеют ненулевой остаток к оплате. Значение «Задолженность» (Debt) возвращается только при полном совпадении сведений о плательщике в AmountRequired со сведениями о плательщике в найденном платежном документе (описание сравнения ФИО физического лица см. в описании контроля INT012009). Сумма к оплате (Reminder) возвращается независимо от результата проверки плательщика, и не меняется при квитировании поступившей в отношении платежного документа оплаты.[/quote:2grejq6t][quote:2grejq6t]Элемент: Debt [type PaymentDocumentDetailsType] Описание: Задолженность (в копейках)[/quote:2grejq6t]Я так понимаю "Debt" как раз и есть "Остаток к оплате"? Если да, то по начислениям у которых не указано ФИО он просто не вернется. И по начисления где банк запрашивает без ФИО тоже. Вот такая вот "защита персональных данных".
ГИС ЖКХ: квитирование
 
[QUOTE]Andrey_S пишет:
Контроль целостности есть. По нашему опыту нельзя ни аннулировать, ни изменить платежи со статусом, отличным от "Новый" (неквитированный).[/QUOTE]
В конкретном частном случае, если УК сама и принимает все платежи в кассу и начисляет ПД, то проблемы это не составит - сквитировать сможет только сама УК либо автоквитирование сработает. Если передавать платеж (авансовый) так, чтобы автоквитирование не срабатывало, то вполне можно сделать себе пространство для маневра, оставляя авансовые платежи несквитированными "Новыми".
В общем случае - конечно проблематично с таким недоделанным контролем целостности.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 8 минуты 9 секунды:[/COLOR][/SIZE]
Насчет ПД с отрицательной суммой - интересный случай. Такой ПД вообще удалось разместить?
Раньше я предполагал (или краем глаза где-то видел), что придется передавать ноль в сумме к оплате пока "остаток к оплате" не станет положительным. Все же отрицательная сумма по идее значит, что потребителю надо вернуть деньги, а нулевая - что переплата есть и платить не обязательно.
Ошибки в ГИС (эмоции пост)
 
[quote:1g4hczax]5) необходима доработка сервисов СМЭВ в части доступа к сведениям о размере текущего "Остатка к оплате" по платежным документам (сейчас банкам такие сведения недоступны, причем мало кто из банкиров даже осознает то, что такие сведения нужны).

Мы недавно установили прямой контакт с Центральным аппаратом Сбера как раз в связи с локализацией этих проблем (технологии двигаются именно Сбером, движущим стимулом является самомотивация на внедрение функционала "Автоплатежей" по запросу сведений из ГИС ЖКХ).[/quote:1g4hczax]Если автоплатеж не будет фиксированной суммой, а по реальному размеру к оплате, то конечно будет проще, наверно всем. Видел в списке сервисов СМЭВ сведения для оплаты ЖКХ, так что наверно речь больше об отражении в них текущего "остатка к оплате"?
Смена наименования Общества в ГИС
 
Где-то тут уже был подобный вопрос. Если инн/огрн организации остался прежний и сменилось только название, то нужно:
1) обновить ЕГРЮЛ;
2) зайти в кабинет организации в ЕСИА (госуслугах), желательно руководителем/администратором;
3) нажать на обновить данные организации.
ЕСИА подгрузит данные из ЕГРЮЛ, а чуть позже ГИС ЖКХ получит данные из ЕСИА.
Если изменился инн/огрн организации - регистрируем заново.
ГИС ЖКХ: квитирование
 
[quote:619xncuw]Технически Вас система в этом никак не ограничивает.[/quote:619xncuw]Ничего себе. Интересно надолго ли такое продлится.[quote:619xncuw]можно ли сторнировать платежи[/quote:619xncuw]Все верно, для поставщика ЖКУ проще и правильнее через квитирование "перекидывать". Однако не забываем, что у загрузившего платеж есть возможность платеж аннулировать или исправить. Насчет шаблонов точно не скажу, но по soap точно есть - многие матерятся потому что исправленные и аннулированные платежи надо выискивать по гису, а условия отбора "недружелюбные" - условие по дате есть, но применяется оно к дате создания платежа. У аннулированного/измененного платежа дата создания естественно не изменяется, то есть приходится все что было запросить снова, а там может будет 1 такой платеж с указанной датой изменения из миллиона. Обещали сделать фильтр по статусу (изменен/аннулирован), но не знаю сделали ли.

В случае приема платежа в кассу самой УК, у УК будет возможность отредактировать существующий платеж в ГИС либо аннулировать платеж в ГИС и загрузить новый вариант платежа (так как насовсем аннулировать и не вернуть деньги потребителю= неразмещению) с исправленным лицевым счетом или периодом оплаты (хотя тут как раз то из-за чего банки платежи не правят - потребитель может потом потрясти бумажкой где указывал май и счет 4, затем возмутиться почему указан март и счет 5, однако если потребитель не указывал их изначально либо написал заявление на изменение, то проблемы нет). Есть еще баги с "отквитированием" при аннулировании платежа.

Если минусы не пугают, то технически возможно "собственную систему квитирования" перенести в ГИС через такие исправления-аннулирования-создания. В конце концов, никто не запрещает вместо 500 рублей в одном платеже, заплатить в один день 5 платежей по сотне. По реквизитам можно подобрать так, чтобы платежи автоквитировались в ГИС только когда нужно и не возиться с их отквитированием.

Грубый теоретический пример: был платеж 500 руб. (авансовый) без месяца, задолженность 0. Через месяц начислили 100, исправили сумму 500 на 400 + создали новый платеж на 100 (начисленную сумму) с конкретным месяцем (дата = дате первоначального платежа), сотенки автосквитировались; повторили еще 3 раза; последний раз создание нового не нужно - только месяц дописать.

Естественно такая схема возможно только при приеме денег самой УК и должна поддерживаться системой учета чтобы можно было однозначно соотнести платежи в гис и платежи в системе учета.
Алгоритм выбора платежа для соотнесения с начисленным месяцем  конечно усложнится. Желательно завести 2 поля месяца: одно рабочее, "указанное системой учета" (пустое для авансовых, заполненное для "псевдосквитированных"), другое справочное, "указанное потребителем" (пустое, если потребитель не указал месяца, заполненное, если указал).

Если потребитель указал, то это значение должно быть скопировано в рабочее при наступлении момента начисления за указанный месяц. Потом определить начисленную за месяц сумму и начать выбор платежей на "псевдоквитирование" этой суммы.  Сначала выбрать платежи с указанным потребителем месяцем. Если их больше чем нужно, у лишних рабочее значение месяца очищается. Если указанных потребителем недостаточно, то из неуказанных потребителем (с пустым справочным) выбрать несоотнесенные (с пустым рабочим) и выбрать из них на недостающую сумму (допустим самые давние), соотнести (указать месяц в рабочее, отразится в гис исправлением платежа с указанием месяца). При избытке набранной суммы разбить платеж (отразится в гис уменьшением суммы и созданием нового платежа с той же датой на остаток суммы). Если у разбиваемого платежа был указан месяц потребителем, остаточный создается без указанного месяца. Ещё наверно при разбиении у нового указывать в дополнительное поле id первоначального. Как-то так наверно?

[SIZE=85px][COLOR=greenpt]Отправлено спустя 14 минуты 43 секунды:[/COLOR][/SIZE]
Впрочем схема неустойчива к изменению начисленного.
[QUOTE]AlcorVol пишет:
Смотря какая ошибка.  Если в сторону завышения суммы ПД - то да. Но мы никогда не правим непосредственно старые ПД. Корректировку начислений (и пеней, если требуется) делаем текущим периодом. (Хотя тут и есть, над чем подумать - в смысле технологии расчёта пеней.)[/QUOTE]Головоломка еще та.
Связь ГИС ЖКХ и иных ИС
 
Хотелось бы еще уточнить, раз вопрос был от РСО со своей ИС: если в гис уже есть эталонные помещения с кадастровым номером, занесенные УК, то возможно имеет смысл данные помещений из гиса загрузить в вашу ИС (хотя бы частично подтянуть данные которых у вас нет, например, часто у рсо нет номеров подъезда для помещений), тогда точно не испортите что УК загружает, ну и меньше забивать в ИС вручную. Таким образом, в идеале нужно в процесс интеграции включить и загрузку в ИС из ГИС данных, внесенных другими поставщиками (чтобы их не перезаписать старыми данными из ИС).
Новое поле в помещениях "Информация подтверждена поставщиком, ответственным за размещение сведений"
 
[QUOTE]Sergey_P пишет:
[QUOTE]two_oceans пишет:
В то, что не было варианта поставить значение "не установлено" тоже слабо верится - большинство баз данных (правда про postgres не уверен) поддерживает значение null, которое как раз и имеет смысл "значение поля не установлено". Конечно с ним тоже есть множество неудобств при работе, но это основы построения баз данных.[/QUOTE]а разве в булеоновских переменных нулл не выдает в итоге ложь на выходе?[/QUOTE]Смотря как проверять. Если точнее, то переменная из базы данных не может быть чистой булевой (чисто строковой и т.д.), она всегда Variant с подтипом булевый (строковый и т.д.), а variant может содержать null (этакий нежданчик). В структуре таблицы базы данных можно запретить для поля возможность содержать null, то есть сделать осмысленное значение обязательным. Так обычно и делают. Когда мы точно знаем, что не получим null мы можем эгоистично использовать обычные типы и не беспокоиться о преобразовании - среда программирования позаботится за нас. А вот есть null не запрещено, то все сводится к тому как именно мы преобразуем variant к обычному типу.

В PHP (и Javascript), например, оператор  сравнения == выдаст равенство значений переменных null и ложи и пустой строке и нолю и пустому объекту, однако оператор === уже скажет что типы разные и потому значения не тождественно равны, отличит ложь и null. В Бэйсике есть специальная функция IsNull(проверяемая_переменная). Аналогично в большинстве других языков отличить значения возможно, но при написании программы нужно учитывать возможность, что переменная, полученная из базы данных, может оказаться со значением null и использовать "несколько нестандартные" функции/операторы. Именно это я и имею ввиду под "неудобствами в работе" часть 1.

В базах данных же в запросах sql есть отдельное условие [имя_таблицы].[имя_поля] is null либо [имя_таблицы].[имя_поля] is not null которое позволяет напрямую отобрать только записи, где поле с неустановленными значениями либо с установленными значениями соответственно. Если такого условия не использовать, то, например, в запросе на выборку объединение таблиц по полю содержащему значения null, может выбрать не все результаты или наоборот выбрать одно и то же несколько раз. Это тоже "неудобства в работе" часть 2.
Новое поле в помещениях "Информация подтверждена поставщиком, ответственным за размещение сведений"
 
Контроль ссылочной целостности говорите? Ну это конечно замечательно, однако учитывая, как все это проявляется (только ставит в палки в колеса при наличии ЛС и ПУ), до настоящего контроля целостности там еще пилить и пилить. Потому как в полной реализации контроль не только проверяет наличие дочерних/родительских записей, но и при некоторых условиях позволяется дочерние записи либо каскадно удалять при удалении родительской записи либо переводить на другого родителя, а при обнаружении записи без родителя ("сиротской") можно либо ее отредактировать на другого родителя либо удалить либо создать соответствующую родительскую запись. Уже не говорю про недопустимость дублей и возможность не заполнять информацию, уже имеющуюся в системе.

А в ГИС выходит захотели рсо и сменили родителя помещений на подъезд 1. То есть ГИС тупо потребовал указать родителя помещений, хотя у них уже был нормальный родитель. Не требовал бы - и наверняка рсо не заполнили бы поле подъезд и все было нормально. Хотя наверно рсо могли выгрузить данные из гис сначала - какие помещения есть и из полученных данных заполнить ПУ, а не пилить свою загрузку данных о которых не имеют сведений (номер подъезда).
Далее - каскадное удаление запрещено, некоторые объекты вообще можно только в архив списать, но не удалить полностью. ГИС допускает существование помещений 1 и 01 и 000001 и считает их не дублями, а разными помещениями. Короче - такая недоделанная ссылочная целостность скорее мешает чем помогает.

Постановку метки "подтверждено" можно рассматривать как начало работы с "неподтвержденными" записями - это плюс. Но нужно как минимум еще функцию устранения дубликатов - не редактированием и удалением вручную поэтапно, а отметкой объектов дублей, отметкой правильного варианта и одним нажатием кнопки "устранить дубликат". Чтобы по нажатию кнопки ГИС сам переводил дочерние записи с дубликатов на правильного родителя и лишние дубли удалял, без месячной переписки с техподдержкой. С этим ладно понятно целостность нужна. А вот то что есть еще и "целостность" с неявной ссылкой на создателя, который может не иметь возможность отредактировать/удалить объект - это однозначно перемудрили.

В то, что не было варианта поставить значение "не установлено" тоже слабо верится - большинство баз данных (правда про postgres не уверен) поддерживает значение null, которое как раз и имеет смысл "значение поля не установлено". Конечно с ним тоже есть множество неудобств при работе, но это основы построения баз данных.
Ошибки в ГИС (эмоции пост)
 
Интересное сочетание смайликов - когда заряжает револьвер ствол на смайлика бьющегося об стену.
Справочник услуг в ГИС ЖКХ
 
[QUOTE]Sergey Cheban пишет:
Убирая и ремонтируя ОДИ, УК что делает? Содержит жилое помещение.[/QUOTE]Замечательно сказано. Для квитанции это прокатит. Вот только это совершенно не решает проблему - потому как ГИС заставляет еще и тот самый тариф в рублях на квадратный метр набрать из конкретных работ. Не какой-то там сферический в вакууме, а хотя бы "средний по больнице" (то есть проиндексировать по инфляции среднее за месяц по итогам затрат прошлого года по всем домам одного типа и разделить на площадь по всем домам одного типа, например. Тип имеется в виду - с мусоропроводом или без, с газопроводом или без. По всем - потому что будет странно выставить 2 одинаковым соседним домам разный тариф). И если работа в квадратных метрах мытой площади, то ее все равно надо будет привести к рублям на квадратный метр доли в доме.
Долговые платежные документы
 
[QUOTE]ТСЖЕлена пишет:
Пример: в декабре за несвоевременную оплату были начислены пени, 25 января собственник их оплатил, а 31 января мы выставили ПД. За январь в начислении пени нет, и куда мне поставить оплаченные и начисленные пени?[/QUOTE]Пример я полагаю, некорректный. Кстати, даже не сказано оплатил ли ту сумму на которую были начислены пени, пусть оплатил. Поясните пожалуйста, почему Вы так настаиваете на том что заполняете ГИС с января? Это имеет смысл только если УК/ТСЖ действует с января, в таком случае пени за декабрь немного не Ваша забота, с ними должна разбираться УК/ТСЖ действовавшая в декабре.

Если же в декабре Вы уже действовали, то непонятно что Вам мешает для данного конкретного лицевого счета разместить текущий ПД за декабрь и нормально указать в нем пени? Это наиболее правильный вариант. Так Вы сэконимите себе и нервы и время на лишние вопросы. Ведь вообще-то предполагается размещение текущих ПД начиная с июля прошлого (2017) года, а долговые соответственно можно разместить и за июнь 2017 (и наверно даже раньше). Чтобы баланс в личном кабинете более менее сходился как минимум Вам нужно что-то разместить с того момента когда банки стали присылать сведения об оплате (либо с того момента когда Вы начали действовать, если начали действовать позже). Если же с июля 2017 по каким-то причинам не можете (не хотите) размещать, то сформируйте на месяцы до января 2018 долговой ПД.

Можно ли включить пени в долговой ПД точно не помню, но если нет, то можно (хоть и не совсем правильно) завести специальную услугу для пени. Тогда сможете их включать как захотите.
Справочник услуг в ГИС ЖКХ
 
Опять про мытье вопросы))) Ну я тоже не могу ничего уловить в логике ГИС по данному вопросу. Квадратные метры предлагаемые ГИСом это площадь, которую вымыли (ладно стекол, стен, полов и лестницы, надо измерить площадь перил и дверных ручек в том числе, вот же бред) и не имеет ничего общего с той площадью, которая используемся для вычисления руб/кв.м. Хотя наверно можно высчитать некий коэффициент без размерности между двумя площадями как соотношение вымытой площади к 1 квадратному метру доли в доме. Умножаем безразмерный коэффициент на долю в доме (в кв.м) получаем долю в вымытой площади (кв.м.). Умножаем на цену мытья руб./кв.м., получаем рубли. Но в целом получается тот еще бред.
Справочник услуг в ГИС ЖКХ
 
[QUOTE]Элина пишет:
Исключительно для удовлетворения хотелок жЫтелей мне нужно ввести Единицу измерения "Лифт" и "кв.м. общей площади помещения кладовки"[/QUOTE]В теории баз данных есть термин "домен" (не путать с интернет-доменом) он используется при описании поля данных как раз для того чтобы не складывать килограммы с метрами хотя оба поля имеют формат "длинная циферка", в данном случае Вы хотите пойти еще дальше и отличать штуки-лифты от штук-швабр, квадратные метры общей площади от квадратных метров кладовки. Но это принципиально неправильно - единица остается либо штука либо квадратный метр, а уточнение - это уже домен.

Мне вот вообще не понятен смысл такой единицы измерения как "лифт"  или даже "штука"(лифт) - у Вас в подъезде несколько лифтов? Кто-то пользуется одним, а у кто-то влазит только в два сразу? Кто-то умудряется подняться на половинке лифта? Как можно в этом контексте лифты измерять штуками? Как по мне это как раз и есть антинаучные фокусы. Другой вопрос - если это там осмотры лифта или профилактика, тогда конечно штука подойдет, возможно и элемент тоже.

Может логичнее измерять в объективных единицах как "этажах" или "килограммах живого веса" или "человеках" или "квадратных метрах площади" (в зависимости какая это услуга). Естественно договор и протокол не канает для ГИС, так как УК не орган государственной власти и не орган местного самоуправления. Техподдержка спрашивает на основании какого пункта ЖК (или другого нормативного акта) у Вас они изменяются лифтами в договоре. Предположительно обращение в прокуратуру имеет все основания, но не в разрезе "сделать в ГИС все как в договоре", а в разрезе "сделать в ГИС и договоре по закону".[QUOTE]Sergey_P пишет:
что и сделала Тс[/QUOTE]Что-то я не знаю, можно ли 61-ое сообщение в теме назвать топик-стартером.
Файлы договора и доп соглашения
 
Про ограничения соглашусь - 10 файлов это бред, да и про 50 мб тоже. В чате разработчиков интеграции не давно раскапывали интерфейс личного кабинета и оказался бред - страница поддерживает загрузку файла по частям, но судя по ограничению закачивается максимум ровно 2 части. Ограничение со стороны сервера ровно такое же как и у страницы, так что обмануть страницу не удалось. Вот студентам в Ланите не лениво было ради 2 частей пилить деление загрузки на части. Для сравнения в интеграции можно в каких-то запросах до 1 гб частями пулять.

А вообще не только можно, но и НУЖНО ставить на минимальное качество везде, где нет каких либо графических вставок на листе. Текст - что рукописный, что печатный , независимо как страшно и убого он выглядит в электронном виде (Fine Reader для распознавания текста просит 300 dpi, но и 150 dpi терпимое качество при загрузке без текстового слоя, а разрешение дисплеев классически было даже 96 dpi), вполне читается, если электронный вариант распечатать так, чтобы скан точно входил на лист.
Выгрузка банком поступлений на счёт УК
 
Ну да, про это уже говорили. Пришли к выводу, что в идеале при оплате в сторону УК/РСО (по списку таких организация) в терминале и в мобильном банке должен появляться пункт "Платеж за ЖКХ?" с вариантами да/нет. Если да, то грузят, если нет, то нет. Это значит, что надо работать с банками и заставлять внедрять такую логику. Фильтровать по "назначению платежа" к сожалению не вариант - поле текстовое и туда пишут что попало, автоматика не вывезет творчество человека.
Квитирование\Не сквитировано\Предварительно сквитировано\Сквитировано
 
[QUOTE]Елена 34 пишет:
Так я и написала что данные только по кассе выгружаю и они задваиваются.[/QUOTE]Вы написали, что выбираете метод выгрузки "касса", а это я так понимаю несколько иное чем отфильтровывание своей базы платежей по признаку "касса" - это раз. Два - мало ли может у Вас и из банка платежи тоже считаются как "касса". Три - может быть банк тупит и отправляет платежи принятые в кассу. Без более точной информации не сможем разобраться.
Регистрация второй организации
 
Как я понял у Вас один сотрудник с действительными ЭЦП обеих организаций? Это недопустимая ситуация, так как при преобразовании организации теоретически Вы обязаны отозвать ЭЦП первой организации, так как сотрудник больше не работает в организации с реквизитами указанными в ЭЦП. Хранить на токене несколько контейнеров также допустимо только если они принадлежат одному человеку. Но если отзыв не сделали, то пока и не надо, сначала со второй разберитесь.

Видимо ГИС по эцп узнает человека и кидает в первую организацию. Вероятно нужно удалить сотрудника из старой организации - из группы доступа в госуслугах, например. При этом должно стать недействительно пользовательское соглашение для первой организации. Для лучшего эффекта наверно из обеих удалить, сколько-то подождать чтобы перестало заходить и в 1 и во 2, потом в вторую добавить еще раз и подождать пока гис его опознает от второй организации и выдаст пользовательское соглашение. Кроме того, первый раз во вторую организацию нужно зайти по эцп директора второй организации и принять пользовательское соглашение. Как-то так, полагаю.
Связь ГИС ЖКХ и иных ИС
 
Хотелось бы заметить, что чуть ниже отдельная тема только по 1С, где просили всех откликнуться. Но откликаются как всегда в непрофильных темах.  :lol:
Загрузка платежей в ГИС
 
[quote:14px9vpp]Мы РСО, через нашу кассу идут платежи только по нашим квитанциям. Соответственно, мы должны размещать информацию по оплатам.
В функциях организации добавили "Оператор по приему платежей". Важно или нет, не знаю, но по этой функции статус "Заявлено организацией", а по остальным - "Подтверждено". [/quote:14px9vpp]Статус должен быть "Подтверждено". Однако, как я понимаю, в свой адрес можно грузить платежи и без этой функции. В правах, которые делегированы своей информационной системе должны быть разрешены операции с платежами. Если Вы размещаете только платежи в свой адрес принятые в свою кассу, то при интеграции нужно использовать метод загрузки платежей со словом Supplier. Однако будьте внимательны - он запрашивает гораздо меньше реквизитов и потому этим методом легко наделать дублей платежа - ГИС не хватает реквизитов для выявления дублей.
Ошибки в ГИС (эмоции пост)
 
[QUOTE]Andrey_S пишет:
[QUOTE]Andrey_S пишет:
Я вот о чем: не нужно считать, что мы, по сути не имея понятия, в чем заключаются причины неадекватной обработки очередей в ГИС ЖКХ, разбираемся в этом лучше.[/QUOTE]
По моему, об этом - [URL=https://m.habrahabr.ru/company/lanit/blog/351160/]https://m.habrahabr.ru/company/lanit/blog/351160/[/URL]

Они тоже подстраиваются. Проблема в отсутствии диалога. Поэтому они решают не те проблемы, которые очевидны поставщикам информации, а те, что есть у поставщиков информации в их собственном представлении.
Плюс в последние месяцы есть непоследовательное руководство проектом со стороны ответственных министерств (что в том числе связано и с внешними причинами).[/QUOTE]Про непоследовательность в целом соглашусь.

Да, я уже почитал эту статью в начале недели. Впечатление унылое - подтвердились худшие опасения по структуре БД. Про распределение нагрузки вообще что-то не заметил упоминаний. Если дословно понимать, то все свалили на виртуальную машину - отдельную для каждого сервиса. И понадеялись, что виртуальная машина как-то сама оптимально распределит нагрузку по физическим узлам. А теперь удивляются, что не распределяет и вместо использования настроек БД пытаются чего-то оптимизировать вручную.

Они что, реально, студенты? Вместо того, чтобы поделить базы в региональном разрезе (по населению регионов), они их поделили в разрезе сервисов. И теперь изобретают велосипед как же снизить время изменения структуры БД делением записей БД по диапазонам. Излишне говорить, что такие запросы как добавление полей, индексов вообще не делятся по диапазонам. Их тоже запускают по сто раз? Хотя да, на втором запуске будет ошибка что индекс уже есть и многопоточка остановится. Гениально.

Про то, что "многопоточка" запускается автоматом только в одном потоке и ее надо вручную "распараллелить" вообще молчу. Чего ж мы удивляемся, что один запрос обработался сразу, а другой завис на неделю? Может это админ запустил вручную обработку первого, а потом поток получил некую ошибку обработки и до второго "не дошел".

Если бы разделили БД по регионам, то такое "деление диапазонов" бы вышло естественным образом (хотя идентификаторы были бы уникальны только в регионе). И запускать многопоточку было бы еще проще - только указать имя БД, без всяких параметров диапазона. И сам "вес" БД был бы меньше - вертелось бы шустрее. Полагаю, интеграцию с системой версий кода можно построить и в таком случае. Однако похоже у рядовых разработчиков нет права голоса о распределении БД и они пытаются сделать "изящное решение" как быстро выдрать зуб через задний проход. И останавливают все регионы на несколько часов вместо остановки по расписанию одного региона на 5-10 минут.

В то время как при "удачном" разделении БД и взаимодействии поставщиков только с очередями обработки, можно вообще сделать техработы незаметными для поставщика. Просто аккуратно переключать с веб-интерфейса (или сервиса-обработчика) необновленной по структуре БД региона на веб-интерфейс (обработчик) БД обновленной структуры. Допустим раз в час. И хоть 24/7 можно вести техработы. Опять же не надо админам ночью сидеть и полусонными набирать команды в терминале.

На мой взгляд само наличие эффекта "время обработки целого больше сумма времен обработки всех частей" - показывает наличие серьезных проблем либо в структуре БД либо в самих запросах. Например, запрос написан без учета оптимизации работы по индексам в БД. Что серьезно в Postgre нет средств для оптимизации обработки запроса?

Про размер - насколько помню пара-тройка индексов по длинным текстовым полям легко удваивает размер БД. А всякие идентификаторы гис включают буквы и тире, то есть по сути текстовые поля. И по идентификаторам естественно есть индексы. Без комментариев.
К слову, guid можно преобразовать к двоичному виду, про них не говорю. Хотя иногда встречал БД хранящие guid в текстовом виде.

Заметьте, они оптимизируют не время обработки запроса от поставщика информации, а время когда изменяют структуру данных во время техработ. Даже не "те (проблемы), что есть у поставщиков информации в их собственном представлении". Про диалог с поставщиками похоже они и не думали.
Квитирование\Не сквитировано\Предварительно сквитировано\Сквитировано
 
[QUOTE]Элина пишет:
У меня всегда задвоения оплат в ГИС что банк выгружает и того что мы уже сами из свеого ПО выгрузили[/QUOTE]Естественно. Платежи, принятые банком, обязан загружать банк. Вы же загружаете только платежи, принятые в свою кассу. В том числе, если принимаете в кассу и отправляете на счет другой организации. Если кассы нет, то и выгружать какие-либо платежи вообще нет обязанности.

Просто многие смотрели, что информации от банка нет и загружали самостоятельно. Если информация от банков поступает своевременно, то завязывайте с привычкой выгружать платежи из банков. И по идее лучше бы удалить дубли, не создавать мусорку, но это уже как Вы решите.[QUOTE]Элина пишет:
Если делать вручную, то с квитированием никаких проблем нет. Кроме того, что старые долги (ПлДок по которым не выгружали в ГИС) не закрываются нормально[/QUOTE]Для старых долгов предусмотрено создание долгового ПД перед загрузкой самого первого "текущего".[QUOTE]Елена 34 пишет:
Я получается шаблоном не пользуюсь, в 1С есть "выгрузить оплату в ГИС" и всё.[/QUOTE]То есть у Вас 1С настроена на работу с ГИС напрямую через соап? Или даже кто-то докрутил промежуточную систему для стабильной отправки данных. Это, я так понимаю, будет интересно всем кто в 1с работает - хотелось бы узнать подробности механизма. И придумать как избежать шаблонов.[QUOTE]Елена 34 пишет:
Я выбираю способ оплаты "касса" и выгружаю, в экселе смотрю оплата удвоилась, в трех соснах блуждаю[/QUOTE]Опять же, не нужно выгружать все оплаты (так как они включают оплаты поступившие из банка - их банк грузит), нужно выгружать только принятые в кассу Вашей организацией (их больше никто не загрузит).
[SIZE=85px][COLOR=greenpt]Отправлено спустя 20 минуты 27 секунды:[/COLOR][/SIZE]
[QUOTE]МарияМария пишет:
Добрый день.Только добралась до квитирования... с какой даты квитировать платежи-январь потом февраль и т.п или не важен порядок?
В ТП ГИСа сказали, что вообще начиная с июля надо квитировать платежные документы!  Платежи к тому же поступают из банка[/QUOTE]Да, хоть Вы и "позже подъехали" (вижу регистрацию на форуме в октябре), но обязанность размещать информацию есть с июля. В том числе и ПД. А где ПД, там и квитирование. Если Вы начали осуществлять управление позже июля, то естественно размещаете с момента когда начали. Как я понимаю, Вы не сможете разместить текущий ПД за период когда ЛС и договора еще не существовало.

Если Ваше ГЖИ не проверяет с какого месяца есть информация о ПД - то есть шанс "подвинуть" срок на более поздний, но это уже риск штрафа когда проверят. Тут все индивидуально. Я бы посоветовал как минимум разместить все ПД по которым прислали платежи банки (сами посмотрите с какого месяца) и проквитировать их. Это поможет минимально "навести порядок" в личных кабинетах потребителей, потому что иначе платежи от банков будут рассматриваться как "авансовые" и нарушать баланс.

Однако не обязательно делать с июля (или когда там банки начали слать) текущими ПД. Например, технически возможно разместить по 1 долговому ПД с суммарными начислениями за июль-декабрь (плюс долг на 1 июля) на каждый ЛС. Потом приквитировать все платежи до декабря к этому долговому ПД (если банки что-то из платежей не прислали, то самим загрузить до выравнивания баланса), а с января размещать текущие ПД и их квитировать.

По поводу порядка как квитировать - зависит как будут оплаты поступать. Если в оплате указан месяц, то обязаны приквитировать хотя бы копейку из суммы оплаты к ПД за тот месяц (а в идеале должны целиком совпасть суммы). Если месяц не указан - обычно закрывают самые старые ПД, но это вроде бы не регламентировано достаточно четко.
Квитирование\Не сквитировано\Предварительно сквитировано\Сквитировано
 
Можно сделать некую попытку реконструировать "логику" разработчиков ГИС. До момента ввода в шаблоне поля "оплачено" я в какой-то из тем доказал теорему, что задолженность за прошлые периоды, это не "сальдо на 1 число месяца", а "сальдо за миллисекунду до выставления ПД", тогда все логично сходилось. Суть была в том, чтобы к "сальдо на 1 число месяца" прибавить все что оплачено с 1 числа до даты выставления счета.

Исходя из предыдущей "логики", рискну предположить, что после добавления "оплачено"  оплату задолженностей в текущем периоде надо все равно плюсовать к задолженности за прошлые периоды, а в оплачено писать только оплату в текущем периоде (с прошлого выставления счета до текущего выставления счета) за текущий период, но без оплаты задолженностей в текущем периоде. Фактического подтверждения у меня нет, но похоже "логику" искривило в эту сторону. Тогда да, все что в оплачено "логично" падает на текущий ПД.
Куда пожаловаться на ТП ГИС
 
С такими условиями, мне уже захотелось послать им резюме на тестировщика)))) Только чую, что студенты меня быстро достанут и парой матов KPI уронится до нуля.
Квитирование\Не сквитировано\Предварительно сквитировано\Сквитировано
 
ГИС все время меняется, точно ответить сложно, тем более про порядок выборки документов ГИСом. Внутренних деталей нам не говорят, остается строить догадки методом тыка.

Как было: сумма оплаты квитировалась только с одним из ПД, со вторым (третьим, четвертым) нужно было квитировать вручную. Смысл был в том, что вручную смотрите куда лишнее закинуть. Сейчас (судя по сообщению AlexRed выше)видимо может вообще не сквитироваться автоматом. Хотя опять же мы не знаем наверняка, может в лк той организации автоматику когда-то отключили.

Порядок - по идее должен изначально выбираться ПД за тот период, который указан в оплате. Сейчас видимо приоритет сместился на текущий ПД (или скажем точнее - последний непогашенный, именно его показывает плательщику) и потому более вероятно, что из Вашего примера 10 рублей сквитируются с текущим, а 95 рублей повиснут для ручного квитирования с долговым. Однако, если период в оплате и период в долговом ПД совпадет, то возможно будет и наоборот - загасится полностью долговой ПД, а 5 рублей останутся для ручного квитирования.
Квитирование\Не сквитировано\Предварительно сквитировано\Сквитировано
 
[QUOTE]Елена 34 пишет:
Добрый день, при выгрузке оплаты из 1С вся оплата удваивается, не пойму почему. У кого нибудь было такое или может кто-то знает причину, подскажите пожалуйста.[/QUOTE]Удваивается при выгрузке из 1с в шаблон? Тогда это скорее к авторам конфигурации 1с вопрос.
Или удваивается при загрузке в ГИС выгруженного из 1с шаблона?
Как регистрировать?
 
Да, регистрируют организацию они сами, сами получают функцию платежного агента. Как я понимаю, от Вас потребуется внести их как платежного агента и прикрепить договор по которому они принимают платежи. Они подтверждают договор и после подтверждения могут вносить платежи через ЛК в которых как получатель указаны Ваши реквизиты.

Если же они по СОАП работают, то кроме вышеперечисленного  им будет нужно дать разрешение от их организации к их ИС на внесение платежей.
#
[QUOTE]Andrey_S пишет:
Дело полезное (шум в таких делах нужен), но за реализацию дизлайк. В наличии передергивание и неаккуратность с фактурой.
ГИС ЖКХ не единственная информационная система, не готовая к ГОСТ 2012...
... для всех из которых без исключения этот вопрос нужно признать более насущный, т.к. они могут размещать информацию исключительно через сервисы СМЭВ (с квалифицированной ЭЦП).[/QUOTE]В целом соглашусь, шум нужен, но текст не точно отражает картину. Процитированное окно появляется независимо установлен ли криптопровайдер и поддерживает ли он гост-2001. Тут хотелось бы заострить внимание что в TLS есть односторонняя аутентификация (когда сертификат клиента не запрашивается) и есть двухсторонняя аутентификация (когда сертификат клиента обязателен). В ГИС ЖКХ можно зайти просто по логину-паролю ЕСИА, обязательного запроса сертификата клиента нет (не берем в расчет ситуацию, когда по сертификату заходят в ЕСИА, хотя могли бы и по паролю зайти и ситуацию смены руководителя, когда ЕСИА требует ЭП руководителя. Заметьте тут везде ЕСИА, а не ГИС ЖКХ). Таким образом, ГИС ЖКХ при входе из личного кабинета вообще с сертифкатом не работает, картинка совершенно не отражает тему статьи, просто увидели что про гост написано и приплели до кучи. А ЕСИА умеет с гост-2012 работать. Проблема в основном для информационных систем, передающих информацию.

Хотя там тоже могут быть нюансы, например, неготовность это самой ГИС ЖКХ или неготовность СМЭВ. И конечно тут дело не в количестве, 673 ИС тоже немало и наверняка через них проходят миллионы записей, так что довод что "всего" 673 "подождут" неуместен, поэтому шум нужен. Однако будет ли эффект от шума?

Если это решать через госконтракт, то там есть сроки прописанные в законах и даже [U]если бы хотели[/U], то сделать и заключить контракт за неделю не получится, аукцион обычно занимает 30-40 дней. В целом, например, на форуме Криптопро сейчас полно вопросов по переходу решений на джаве на гост-2012, и там тоже не все так гладко, заменой пары строк программы дело не кончается надо обновлять джаву, а в новой версии как водится много еще чего поменяли кроме добавления поддержки гост-2012. Итого - крайне сомневаюсь, что реально поддержка гост-2012 даже во втором квартале появится (второй квартал = 1 апреля, уже через 37 дней), если взялись только в январе, а уж если возьмутся только после госконтракта, то ждите во второй половине года.

[quote:297cm73y]по нормативке формирование ключей по ГОСТ 2001 должно выполняться до конца 2019 года.[/quote:297cm73y]Про Минкомсвязи насколько помню им ГИС ЖКХ передали из Почты не так давно и они ужасно тугие на подъем - вспомните как гост-2012 запускали сначала с марта 2018 и в итоге еле запустили к концу года. Подозреваю, что запустили только из-за спешной отмены выпуска сертификатов гост-2001 с 1 января. Все еще интереснее: и сообщение Минкомсвязи про запрет выпуска с 1 января 2019 сертификатов алгоритма гост-2001 и сообщение про продление использования сертификатов алгоритма гост-2001 до 31 декабря 2019 (и сертификатов УЦ до 31 марта 2020 = 31 декабря 2018 + 1 год 3 месяца) [U]ссылаются на один документ[/U]. К слову, сам документ ФСБ все цитируют из Минкомсвязи, но вообще мало кто видел, так что немного неясно про какую нормативку речь. Скорее уж дело в разнице понятий [B]использование сертификата[/B] и [B]выпуск сертификата[/B]: уже выпущенный разрешено использовать, но новый нельзя получить - иначе сертификаты УЦ придется продлевать еще дальше.

Относительно перехода на гост-2012: факт о невозможности выпуска с 1 января 2019 года сертификатов гост-2001 всплыл еще в конце года и было уведомление от УЦ (например, УЦ Федерального казначейства) о необходимости срочно заменить сертификаты гост-2001 кому они нужны до конца 2019 года в связи с задержкой перехода информационных систем на гост-2012.  Как видно, уведомления УЦ до многих владельцев ИС не дошли и срок истечения сертификатов гост-2001 прошляпили. Полагаю, тут есть и частичная вина самих владельцев ИС, что они верили в своевременный переход ГИС на новый гост (как будто в раю живут, ага), за сроком своих сертификатов не проследили и пропустили уведомления УЦ мимо ушей. Подытоживая, ГИС ЖКХ и Минкомсвязь это не оправдывает, но и владельцам ИС надо помнить где живут и не терять бдительности.
#
[quote:3dasmdq9]А один банк вместо 5 000 руб прислал, что оплатили 500 000 руб.[/quote:3dasmdq9]Если разница в 100 раз, скорее всего, этот банк указал сумму в копейках, как по форматам ГИС ГМП, и это недоработка программного обеспечения. Очень желательно связаться с банком и сообщить им, что данные платежа видны в ГИС ЖКХ неверно. Пусть в свою очередь разберутся со своими программистами в чем проблема.
#
[QUOTE]Andrey_S пишет:
Но размещают они (РР) инфу через сервисы СМЭВ для ГИС ЖКХ, разработанные Ланитом[/QUOTE]А поподробнее почитать есть ссылка, что РР через интеграцию прицпелен? Какие у них роли? Судя по межведу - у РР достаточно тормозная сеть (или шлюз обмена со СМЭВ) внутри РР запрос может идти до 5 часов пока достигнет СМЭВ (видим по разнице в отметках времени между формированием и отправкой в СМЭВ). За это время чаще всего успевает закончиться рабочий день и мы видим запрос только на следующий день. Аналогично когда запрос посылаем мы, он шустро доходит до шлюза СМЭВ РР, через минуту регистрируется на их портале и зависает пока его увидят специалисты областного уровня. Минимальное время ответа отказом было около 40 минут. А так тоже может полдня где-то болтаться. Потом приходит почта с портала, что выполнен и втечение 20-30 минут появляется в СМЭВ. Так что думаю получится ужас, если сцепить РР через СМЭВ с ГИС жКХ.

Почему-то мне больше представляется, что все же обработка пакетная, как и с ФИАС. Выгружают дамп БД, а студенты Ланита при установке очередной версии пытается дамп "переварить".
#
[QUOTE]Andrey_S пишет:
Нет. ПД это не просто выставленный "счет к оплате", а подробная информационная выкладка о состоянии взаиморасчетов.[/QUOTE]Проясним. Я согласен, что промежуточные цифры по взаиморасчетам могут стать отрицательными, и даже что итог по конкретной услуге может стать отрицательным. Однако Вы говорите "с отрицательной суммой документа", то есть либо в документе всего одна услуга (серьезно?) либо другие услуги не компенсируют минус по конкретной услуге (бывает и такое?).
Также похоже есть разница в терминологии и "сумма документа" отличается от "сумма к оплате"? Как я понимаю, ГИС будет категорически сопротивляться факту, что "сумма к оплате" станет отрицательная и при обработке исправит на ноль. Поэтому я и спрашиваю, удалось ли кому-то перебороть эту особенность ГИСа и разместить ПД, не исправленный на ноль.
[QUOTE]Andrey_S пишет:
Как выставление ПД с положительной суммой начислений не означает, что по нему в течение месяца будет выполнена оплата, так и выставление ПД с отрицательной суммой не означает, что в течение месяца будет сделан возврат.[/QUOTE]Частично соглашусь. По крайней мере, отрицательная сумма по услуге А означает, что деньги из состояния "оплачены по услуге А" виртуально перешли в какое-то другое состояние, например, "к возврату" или "оплачены по услуге Б". Однако, полагаю, должен быть предельный срок при переходе между состояниями "к возврату" и "возвращены". Например, при денежных расчетах по выборам деньги должны быть возвращены в срок от 10 до 45 дней (в зависимости от ситуации).
#
[QUOTE]Andrey_S пишет:
На прошлой неделе обсуждали это с представителями ЦА Сбера - получили подтверждение о том, что Сбер будет ставить вопрос о доработке сервиса перед Ланитом и регуляторами.[/QUOTE]Они паспорт сервиса читали?Цитата из паспорта [URL=https://smev.gosuslugi.ru/portal/services.jsp#!/F/MNSV10gisGKHtest/1.10/p00smev/SID0004157]сервиса[/URL] по ссылке выше, страница 7. Просмотрел по диагонали. [quote:2grejq6t]4) сведения о начисленном размере платы и имеющейся задолженности (предоставляются только в случаях, указанных в пункте 125 настоящего Порядка);[/quote:2grejq6t][quote:2grejq6t]Операция возвращает только те платежные документы, которые имеют ненулевой остаток к оплате. Значение «Задолженность» (Debt) возвращается только при полном совпадении сведений о плательщике в AmountRequired со сведениями о плательщике в найденном платежном документе (описание сравнения ФИО физического лица см. в описании контроля INT012009). Сумма к оплате (Reminder) возвращается независимо от результата проверки плательщика, и не меняется при квитировании поступившей в отношении платежного документа оплаты.[/quote:2grejq6t][quote:2grejq6t]Элемент: Debt [type PaymentDocumentDetailsType] Описание: Задолженность (в копейках)[/quote:2grejq6t]Я так понимаю "Debt" как раз и есть "Остаток к оплате"? Если да, то по начислениям у которых не указано ФИО он просто не вернется. И по начисления где банк запрашивает без ФИО тоже. Вот такая вот "защита персональных данных".
#
[QUOTE]Andrey_S пишет:
Контроль целостности есть. По нашему опыту нельзя ни аннулировать, ни изменить платежи со статусом, отличным от "Новый" (неквитированный).[/QUOTE]
В конкретном частном случае, если УК сама и принимает все платежи в кассу и начисляет ПД, то проблемы это не составит - сквитировать сможет только сама УК либо автоквитирование сработает. Если передавать платеж (авансовый) так, чтобы автоквитирование не срабатывало, то вполне можно сделать себе пространство для маневра, оставляя авансовые платежи несквитированными "Новыми".
В общем случае - конечно проблематично с таким недоделанным контролем целостности.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 8 минуты 9 секунды:[/COLOR][/SIZE]
Насчет ПД с отрицательной суммой - интересный случай. Такой ПД вообще удалось разместить?
Раньше я предполагал (или краем глаза где-то видел), что придется передавать ноль в сумме к оплате пока "остаток к оплате" не станет положительным. Все же отрицательная сумма по идее значит, что потребителю надо вернуть деньги, а нулевая - что переплата есть и платить не обязательно.
#
[quote:1g4hczax]5) необходима доработка сервисов СМЭВ в части доступа к сведениям о размере текущего "Остатка к оплате" по платежным документам (сейчас банкам такие сведения недоступны, причем мало кто из банкиров даже осознает то, что такие сведения нужны).

Мы недавно установили прямой контакт с Центральным аппаратом Сбера как раз в связи с локализацией этих проблем (технологии двигаются именно Сбером, движущим стимулом является самомотивация на внедрение функционала "Автоплатежей" по запросу сведений из ГИС ЖКХ).[/quote:1g4hczax]Если автоплатеж не будет фиксированной суммой, а по реальному размеру к оплате, то конечно будет проще, наверно всем. Видел в списке сервисов СМЭВ сведения для оплаты ЖКХ, так что наверно речь больше об отражении в них текущего "остатка к оплате"?
#
Где-то тут уже был подобный вопрос. Если инн/огрн организации остался прежний и сменилось только название, то нужно:
1) обновить ЕГРЮЛ;
2) зайти в кабинет организации в ЕСИА (госуслугах), желательно руководителем/администратором;
3) нажать на обновить данные организации.
ЕСИА подгрузит данные из ЕГРЮЛ, а чуть позже ГИС ЖКХ получит данные из ЕСИА.
Если изменился инн/огрн организации - регистрируем заново.
#
[quote:619xncuw]Технически Вас система в этом никак не ограничивает.[/quote:619xncuw]Ничего себе. Интересно надолго ли такое продлится.[quote:619xncuw]можно ли сторнировать платежи[/quote:619xncuw]Все верно, для поставщика ЖКУ проще и правильнее через квитирование "перекидывать". Однако не забываем, что у загрузившего платеж есть возможность платеж аннулировать или исправить. Насчет шаблонов точно не скажу, но по soap точно есть - многие матерятся потому что исправленные и аннулированные платежи надо выискивать по гису, а условия отбора "недружелюбные" - условие по дате есть, но применяется оно к дате создания платежа. У аннулированного/измененного платежа дата создания естественно не изменяется, то есть приходится все что было запросить снова, а там может будет 1 такой платеж с указанной датой изменения из миллиона. Обещали сделать фильтр по статусу (изменен/аннулирован), но не знаю сделали ли.

В случае приема платежа в кассу самой УК, у УК будет возможность отредактировать существующий платеж в ГИС либо аннулировать платеж в ГИС и загрузить новый вариант платежа (так как насовсем аннулировать и не вернуть деньги потребителю= неразмещению) с исправленным лицевым счетом или периодом оплаты (хотя тут как раз то из-за чего банки платежи не правят - потребитель может потом потрясти бумажкой где указывал май и счет 4, затем возмутиться почему указан март и счет 5, однако если потребитель не указывал их изначально либо написал заявление на изменение, то проблемы нет). Есть еще баги с "отквитированием" при аннулировании платежа.

Если минусы не пугают, то технически возможно "собственную систему квитирования" перенести в ГИС через такие исправления-аннулирования-создания. В конце концов, никто не запрещает вместо 500 рублей в одном платеже, заплатить в один день 5 платежей по сотне. По реквизитам можно подобрать так, чтобы платежи автоквитировались в ГИС только когда нужно и не возиться с их отквитированием.

Грубый теоретический пример: был платеж 500 руб. (авансовый) без месяца, задолженность 0. Через месяц начислили 100, исправили сумму 500 на 400 + создали новый платеж на 100 (начисленную сумму) с конкретным месяцем (дата = дате первоначального платежа), сотенки автосквитировались; повторили еще 3 раза; последний раз создание нового не нужно - только месяц дописать.

Естественно такая схема возможно только при приеме денег самой УК и должна поддерживаться системой учета чтобы можно было однозначно соотнести платежи в гис и платежи в системе учета.
Алгоритм выбора платежа для соотнесения с начисленным месяцем  конечно усложнится. Желательно завести 2 поля месяца: одно рабочее, "указанное системой учета" (пустое для авансовых, заполненное для "псевдосквитированных"), другое справочное, "указанное потребителем" (пустое, если потребитель не указал месяца, заполненное, если указал).

Если потребитель указал, то это значение должно быть скопировано в рабочее при наступлении момента начисления за указанный месяц. Потом определить начисленную за месяц сумму и начать выбор платежей на "псевдоквитирование" этой суммы.  Сначала выбрать платежи с указанным потребителем месяцем. Если их больше чем нужно, у лишних рабочее значение месяца очищается. Если указанных потребителем недостаточно, то из неуказанных потребителем (с пустым справочным) выбрать несоотнесенные (с пустым рабочим) и выбрать из них на недостающую сумму (допустим самые давние), соотнести (указать месяц в рабочее, отразится в гис исправлением платежа с указанием месяца). При избытке набранной суммы разбить платеж (отразится в гис уменьшением суммы и созданием нового платежа с той же датой на остаток суммы). Если у разбиваемого платежа был указан месяц потребителем, остаточный создается без указанного месяца. Ещё наверно при разбиении у нового указывать в дополнительное поле id первоначального. Как-то так наверно?

[SIZE=85px][COLOR=greenpt]Отправлено спустя 14 минуты 43 секунды:[/COLOR][/SIZE]
Впрочем схема неустойчива к изменению начисленного.
[QUOTE]AlcorVol пишет:
Смотря какая ошибка.  Если в сторону завышения суммы ПД - то да. Но мы никогда не правим непосредственно старые ПД. Корректировку начислений (и пеней, если требуется) делаем текущим периодом. (Хотя тут и есть, над чем подумать - в смысле технологии расчёта пеней.)[/QUOTE]Головоломка еще та.
#
Хотелось бы еще уточнить, раз вопрос был от РСО со своей ИС: если в гис уже есть эталонные помещения с кадастровым номером, занесенные УК, то возможно имеет смысл данные помещений из гиса загрузить в вашу ИС (хотя бы частично подтянуть данные которых у вас нет, например, часто у рсо нет номеров подъезда для помещений), тогда точно не испортите что УК загружает, ну и меньше забивать в ИС вручную. Таким образом, в идеале нужно в процесс интеграции включить и загрузку в ИС из ГИС данных, внесенных другими поставщиками (чтобы их не перезаписать старыми данными из ИС).
#
[QUOTE]Sergey_P пишет:
[QUOTE]two_oceans пишет:
В то, что не было варианта поставить значение "не установлено" тоже слабо верится - большинство баз данных (правда про postgres не уверен) поддерживает значение null, которое как раз и имеет смысл "значение поля не установлено". Конечно с ним тоже есть множество неудобств при работе, но это основы построения баз данных.[/QUOTE]а разве в булеоновских переменных нулл не выдает в итоге ложь на выходе?[/QUOTE]Смотря как проверять. Если точнее, то переменная из базы данных не может быть чистой булевой (чисто строковой и т.д.), она всегда Variant с подтипом булевый (строковый и т.д.), а variant может содержать null (этакий нежданчик). В структуре таблицы базы данных можно запретить для поля возможность содержать null, то есть сделать осмысленное значение обязательным. Так обычно и делают. Когда мы точно знаем, что не получим null мы можем эгоистично использовать обычные типы и не беспокоиться о преобразовании - среда программирования позаботится за нас. А вот есть null не запрещено, то все сводится к тому как именно мы преобразуем variant к обычному типу.

В PHP (и Javascript), например, оператор  сравнения == выдаст равенство значений переменных null и ложи и пустой строке и нолю и пустому объекту, однако оператор === уже скажет что типы разные и потому значения не тождественно равны, отличит ложь и null. В Бэйсике есть специальная функция IsNull(проверяемая_переменная). Аналогично в большинстве других языков отличить значения возможно, но при написании программы нужно учитывать возможность, что переменная, полученная из базы данных, может оказаться со значением null и использовать "несколько нестандартные" функции/операторы. Именно это я и имею ввиду под "неудобствами в работе" часть 1.

В базах данных же в запросах sql есть отдельное условие [имя_таблицы].[имя_поля] is null либо [имя_таблицы].[имя_поля] is not null которое позволяет напрямую отобрать только записи, где поле с неустановленными значениями либо с установленными значениями соответственно. Если такого условия не использовать, то, например, в запросе на выборку объединение таблиц по полю содержащему значения null, может выбрать не все результаты или наоборот выбрать одно и то же несколько раз. Это тоже "неудобства в работе" часть 2.
#
Контроль ссылочной целостности говорите? Ну это конечно замечательно, однако учитывая, как все это проявляется (только ставит в палки в колеса при наличии ЛС и ПУ), до настоящего контроля целостности там еще пилить и пилить. Потому как в полной реализации контроль не только проверяет наличие дочерних/родительских записей, но и при некоторых условиях позволяется дочерние записи либо каскадно удалять при удалении родительской записи либо переводить на другого родителя, а при обнаружении записи без родителя ("сиротской") можно либо ее отредактировать на другого родителя либо удалить либо создать соответствующую родительскую запись. Уже не говорю про недопустимость дублей и возможность не заполнять информацию, уже имеющуюся в системе.

А в ГИС выходит захотели рсо и сменили родителя помещений на подъезд 1. То есть ГИС тупо потребовал указать родителя помещений, хотя у них уже был нормальный родитель. Не требовал бы - и наверняка рсо не заполнили бы поле подъезд и все было нормально. Хотя наверно рсо могли выгрузить данные из гис сначала - какие помещения есть и из полученных данных заполнить ПУ, а не пилить свою загрузку данных о которых не имеют сведений (номер подъезда).
Далее - каскадное удаление запрещено, некоторые объекты вообще можно только в архив списать, но не удалить полностью. ГИС допускает существование помещений 1 и 01 и 000001 и считает их не дублями, а разными помещениями. Короче - такая недоделанная ссылочная целостность скорее мешает чем помогает.

Постановку метки "подтверждено" можно рассматривать как начало работы с "неподтвержденными" записями - это плюс. Но нужно как минимум еще функцию устранения дубликатов - не редактированием и удалением вручную поэтапно, а отметкой объектов дублей, отметкой правильного варианта и одним нажатием кнопки "устранить дубликат". Чтобы по нажатию кнопки ГИС сам переводил дочерние записи с дубликатов на правильного родителя и лишние дубли удалял, без месячной переписки с техподдержкой. С этим ладно понятно целостность нужна. А вот то что есть еще и "целостность" с неявной ссылкой на создателя, который может не иметь возможность отредактировать/удалить объект - это однозначно перемудрили.

В то, что не было варианта поставить значение "не установлено" тоже слабо верится - большинство баз данных (правда про postgres не уверен) поддерживает значение null, которое как раз и имеет смысл "значение поля не установлено". Конечно с ним тоже есть множество неудобств при работе, но это основы построения баз данных.
#
Интересное сочетание смайликов - когда заряжает револьвер ствол на смайлика бьющегося об стену.
#
[QUOTE]Sergey Cheban пишет:
Убирая и ремонтируя ОДИ, УК что делает? Содержит жилое помещение.[/QUOTE]Замечательно сказано. Для квитанции это прокатит. Вот только это совершенно не решает проблему - потому как ГИС заставляет еще и тот самый тариф в рублях на квадратный метр набрать из конкретных работ. Не какой-то там сферический в вакууме, а хотя бы "средний по больнице" (то есть проиндексировать по инфляции среднее за месяц по итогам затрат прошлого года по всем домам одного типа и разделить на площадь по всем домам одного типа, например. Тип имеется в виду - с мусоропроводом или без, с газопроводом или без. По всем - потому что будет странно выставить 2 одинаковым соседним домам разный тариф). И если работа в квадратных метрах мытой площади, то ее все равно надо будет привести к рублям на квадратный метр доли в доме.
#
[QUOTE]ТСЖЕлена пишет:
Пример: в декабре за несвоевременную оплату были начислены пени, 25 января собственник их оплатил, а 31 января мы выставили ПД. За январь в начислении пени нет, и куда мне поставить оплаченные и начисленные пени?[/QUOTE]Пример я полагаю, некорректный. Кстати, даже не сказано оплатил ли ту сумму на которую были начислены пени, пусть оплатил. Поясните пожалуйста, почему Вы так настаиваете на том что заполняете ГИС с января? Это имеет смысл только если УК/ТСЖ действует с января, в таком случае пени за декабрь немного не Ваша забота, с ними должна разбираться УК/ТСЖ действовавшая в декабре.

Если же в декабре Вы уже действовали, то непонятно что Вам мешает для данного конкретного лицевого счета разместить текущий ПД за декабрь и нормально указать в нем пени? Это наиболее правильный вариант. Так Вы сэконимите себе и нервы и время на лишние вопросы. Ведь вообще-то предполагается размещение текущих ПД начиная с июля прошлого (2017) года, а долговые соответственно можно разместить и за июнь 2017 (и наверно даже раньше). Чтобы баланс в личном кабинете более менее сходился как минимум Вам нужно что-то разместить с того момента когда банки стали присылать сведения об оплате (либо с того момента когда Вы начали действовать, если начали действовать позже). Если же с июля 2017 по каким-то причинам не можете (не хотите) размещать, то сформируйте на месяцы до января 2018 долговой ПД.

Можно ли включить пени в долговой ПД точно не помню, но если нет, то можно (хоть и не совсем правильно) завести специальную услугу для пени. Тогда сможете их включать как захотите.
#
Опять про мытье вопросы))) Ну я тоже не могу ничего уловить в логике ГИС по данному вопросу. Квадратные метры предлагаемые ГИСом это площадь, которую вымыли (ладно стекол, стен, полов и лестницы, надо измерить площадь перил и дверных ручек в том числе, вот же бред) и не имеет ничего общего с той площадью, которая используемся для вычисления руб/кв.м. Хотя наверно можно высчитать некий коэффициент без размерности между двумя площадями как соотношение вымытой площади к 1 квадратному метру доли в доме. Умножаем безразмерный коэффициент на долю в доме (в кв.м) получаем долю в вымытой площади (кв.м.). Умножаем на цену мытья руб./кв.м., получаем рубли. Но в целом получается тот еще бред.
#
[QUOTE]Элина пишет:
Исключительно для удовлетворения хотелок жЫтелей мне нужно ввести Единицу измерения "Лифт" и "кв.м. общей площади помещения кладовки"[/QUOTE]В теории баз данных есть термин "домен" (не путать с интернет-доменом) он используется при описании поля данных как раз для того чтобы не складывать килограммы с метрами хотя оба поля имеют формат "длинная циферка", в данном случае Вы хотите пойти еще дальше и отличать штуки-лифты от штук-швабр, квадратные метры общей площади от квадратных метров кладовки. Но это принципиально неправильно - единица остается либо штука либо квадратный метр, а уточнение - это уже домен.

Мне вот вообще не понятен смысл такой единицы измерения как "лифт"  или даже "штука"(лифт) - у Вас в подъезде несколько лифтов? Кто-то пользуется одним, а у кто-то влазит только в два сразу? Кто-то умудряется подняться на половинке лифта? Как можно в этом контексте лифты измерять штуками? Как по мне это как раз и есть антинаучные фокусы. Другой вопрос - если это там осмотры лифта или профилактика, тогда конечно штука подойдет, возможно и элемент тоже.

Может логичнее измерять в объективных единицах как "этажах" или "килограммах живого веса" или "человеках" или "квадратных метрах площади" (в зависимости какая это услуга). Естественно договор и протокол не канает для ГИС, так как УК не орган государственной власти и не орган местного самоуправления. Техподдержка спрашивает на основании какого пункта ЖК (или другого нормативного акта) у Вас они изменяются лифтами в договоре. Предположительно обращение в прокуратуру имеет все основания, но не в разрезе "сделать в ГИС все как в договоре", а в разрезе "сделать в ГИС и договоре по закону".[QUOTE]Sergey_P пишет:
что и сделала Тс[/QUOTE]Что-то я не знаю, можно ли 61-ое сообщение в теме назвать топик-стартером.
#
Про ограничения соглашусь - 10 файлов это бред, да и про 50 мб тоже. В чате разработчиков интеграции не давно раскапывали интерфейс личного кабинета и оказался бред - страница поддерживает загрузку файла по частям, но судя по ограничению закачивается максимум ровно 2 части. Ограничение со стороны сервера ровно такое же как и у страницы, так что обмануть страницу не удалось. Вот студентам в Ланите не лениво было ради 2 частей пилить деление загрузки на части. Для сравнения в интеграции можно в каких-то запросах до 1 гб частями пулять.

А вообще не только можно, но и НУЖНО ставить на минимальное качество везде, где нет каких либо графических вставок на листе. Текст - что рукописный, что печатный , независимо как страшно и убого он выглядит в электронном виде (Fine Reader для распознавания текста просит 300 dpi, но и 150 dpi терпимое качество при загрузке без текстового слоя, а разрешение дисплеев классически было даже 96 dpi), вполне читается, если электронный вариант распечатать так, чтобы скан точно входил на лист.
#
Ну да, про это уже говорили. Пришли к выводу, что в идеале при оплате в сторону УК/РСО (по списку таких организация) в терминале и в мобильном банке должен появляться пункт "Платеж за ЖКХ?" с вариантами да/нет. Если да, то грузят, если нет, то нет. Это значит, что надо работать с банками и заставлять внедрять такую логику. Фильтровать по "назначению платежа" к сожалению не вариант - поле текстовое и туда пишут что попало, автоматика не вывезет творчество человека.
#
[QUOTE]Елена 34 пишет:
Так я и написала что данные только по кассе выгружаю и они задваиваются.[/QUOTE]Вы написали, что выбираете метод выгрузки "касса", а это я так понимаю несколько иное чем отфильтровывание своей базы платежей по признаку "касса" - это раз. Два - мало ли может у Вас и из банка платежи тоже считаются как "касса". Три - может быть банк тупит и отправляет платежи принятые в кассу. Без более точной информации не сможем разобраться.
#
Как я понял у Вас один сотрудник с действительными ЭЦП обеих организаций? Это недопустимая ситуация, так как при преобразовании организации теоретически Вы обязаны отозвать ЭЦП первой организации, так как сотрудник больше не работает в организации с реквизитами указанными в ЭЦП. Хранить на токене несколько контейнеров также допустимо только если они принадлежат одному человеку. Но если отзыв не сделали, то пока и не надо, сначала со второй разберитесь.

Видимо ГИС по эцп узнает человека и кидает в первую организацию. Вероятно нужно удалить сотрудника из старой организации - из группы доступа в госуслугах, например. При этом должно стать недействительно пользовательское соглашение для первой организации. Для лучшего эффекта наверно из обеих удалить, сколько-то подождать чтобы перестало заходить и в 1 и во 2, потом в вторую добавить еще раз и подождать пока гис его опознает от второй организации и выдаст пользовательское соглашение. Кроме того, первый раз во вторую организацию нужно зайти по эцп директора второй организации и принять пользовательское соглашение. Как-то так, полагаю.
#
Хотелось бы заметить, что чуть ниже отдельная тема только по 1С, где просили всех откликнуться. Но откликаются как всегда в непрофильных темах.  :lol:
#
[quote:14px9vpp]Мы РСО, через нашу кассу идут платежи только по нашим квитанциям. Соответственно, мы должны размещать информацию по оплатам.
В функциях организации добавили "Оператор по приему платежей". Важно или нет, не знаю, но по этой функции статус "Заявлено организацией", а по остальным - "Подтверждено". [/quote:14px9vpp]Статус должен быть "Подтверждено". Однако, как я понимаю, в свой адрес можно грузить платежи и без этой функции. В правах, которые делегированы своей информационной системе должны быть разрешены операции с платежами. Если Вы размещаете только платежи в свой адрес принятые в свою кассу, то при интеграции нужно использовать метод загрузки платежей со словом Supplier. Однако будьте внимательны - он запрашивает гораздо меньше реквизитов и потому этим методом легко наделать дублей платежа - ГИС не хватает реквизитов для выявления дублей.
#
[QUOTE]Andrey_S пишет:
[QUOTE]Andrey_S пишет:
Я вот о чем: не нужно считать, что мы, по сути не имея понятия, в чем заключаются причины неадекватной обработки очередей в ГИС ЖКХ, разбираемся в этом лучше.[/QUOTE]
По моему, об этом - [URL=https://m.habrahabr.ru/company/lanit/blog/351160/]https://m.habrahabr.ru/company/lanit/blog/351160/[/URL]

Они тоже подстраиваются. Проблема в отсутствии диалога. Поэтому они решают не те проблемы, которые очевидны поставщикам информации, а те, что есть у поставщиков информации в их собственном представлении.
Плюс в последние месяцы есть непоследовательное руководство проектом со стороны ответственных министерств (что в том числе связано и с внешними причинами).[/QUOTE]Про непоследовательность в целом соглашусь.

Да, я уже почитал эту статью в начале недели. Впечатление унылое - подтвердились худшие опасения по структуре БД. Про распределение нагрузки вообще что-то не заметил упоминаний. Если дословно понимать, то все свалили на виртуальную машину - отдельную для каждого сервиса. И понадеялись, что виртуальная машина как-то сама оптимально распределит нагрузку по физическим узлам. А теперь удивляются, что не распределяет и вместо использования настроек БД пытаются чего-то оптимизировать вручную.

Они что, реально, студенты? Вместо того, чтобы поделить базы в региональном разрезе (по населению регионов), они их поделили в разрезе сервисов. И теперь изобретают велосипед как же снизить время изменения структуры БД делением записей БД по диапазонам. Излишне говорить, что такие запросы как добавление полей, индексов вообще не делятся по диапазонам. Их тоже запускают по сто раз? Хотя да, на втором запуске будет ошибка что индекс уже есть и многопоточка остановится. Гениально.

Про то, что "многопоточка" запускается автоматом только в одном потоке и ее надо вручную "распараллелить" вообще молчу. Чего ж мы удивляемся, что один запрос обработался сразу, а другой завис на неделю? Может это админ запустил вручную обработку первого, а потом поток получил некую ошибку обработки и до второго "не дошел".

Если бы разделили БД по регионам, то такое "деление диапазонов" бы вышло естественным образом (хотя идентификаторы были бы уникальны только в регионе). И запускать многопоточку было бы еще проще - только указать имя БД, без всяких параметров диапазона. И сам "вес" БД был бы меньше - вертелось бы шустрее. Полагаю, интеграцию с системой версий кода можно построить и в таком случае. Однако похоже у рядовых разработчиков нет права голоса о распределении БД и они пытаются сделать "изящное решение" как быстро выдрать зуб через задний проход. И останавливают все регионы на несколько часов вместо остановки по расписанию одного региона на 5-10 минут.

В то время как при "удачном" разделении БД и взаимодействии поставщиков только с очередями обработки, можно вообще сделать техработы незаметными для поставщика. Просто аккуратно переключать с веб-интерфейса (или сервиса-обработчика) необновленной по структуре БД региона на веб-интерфейс (обработчик) БД обновленной структуры. Допустим раз в час. И хоть 24/7 можно вести техработы. Опять же не надо админам ночью сидеть и полусонными набирать команды в терминале.

На мой взгляд само наличие эффекта "время обработки целого больше сумма времен обработки всех частей" - показывает наличие серьезных проблем либо в структуре БД либо в самих запросах. Например, запрос написан без учета оптимизации работы по индексам в БД. Что серьезно в Postgre нет средств для оптимизации обработки запроса?

Про размер - насколько помню пара-тройка индексов по длинным текстовым полям легко удваивает размер БД. А всякие идентификаторы гис включают буквы и тире, то есть по сути текстовые поля. И по идентификаторам естественно есть индексы. Без комментариев.
К слову, guid можно преобразовать к двоичному виду, про них не говорю. Хотя иногда встречал БД хранящие guid в текстовом виде.

Заметьте, они оптимизируют не время обработки запроса от поставщика информации, а время когда изменяют структуру данных во время техработ. Даже не "те (проблемы), что есть у поставщиков информации в их собственном представлении". Про диалог с поставщиками похоже они и не думали.
#
[QUOTE]Элина пишет:
У меня всегда задвоения оплат в ГИС что банк выгружает и того что мы уже сами из свеого ПО выгрузили[/QUOTE]Естественно. Платежи, принятые банком, обязан загружать банк. Вы же загружаете только платежи, принятые в свою кассу. В том числе, если принимаете в кассу и отправляете на счет другой организации. Если кассы нет, то и выгружать какие-либо платежи вообще нет обязанности.

Просто многие смотрели, что информации от банка нет и загружали самостоятельно. Если информация от банков поступает своевременно, то завязывайте с привычкой выгружать платежи из банков. И по идее лучше бы удалить дубли, не создавать мусорку, но это уже как Вы решите.[QUOTE]Элина пишет:
Если делать вручную, то с квитированием никаких проблем нет. Кроме того, что старые долги (ПлДок по которым не выгружали в ГИС) не закрываются нормально[/QUOTE]Для старых долгов предусмотрено создание долгового ПД перед загрузкой самого первого "текущего".[QUOTE]Елена 34 пишет:
Я получается шаблоном не пользуюсь, в 1С есть "выгрузить оплату в ГИС" и всё.[/QUOTE]То есть у Вас 1С настроена на работу с ГИС напрямую через соап? Или даже кто-то докрутил промежуточную систему для стабильной отправки данных. Это, я так понимаю, будет интересно всем кто в 1с работает - хотелось бы узнать подробности механизма. И придумать как избежать шаблонов.[QUOTE]Елена 34 пишет:
Я выбираю способ оплаты "касса" и выгружаю, в экселе смотрю оплата удвоилась, в трех соснах блуждаю[/QUOTE]Опять же, не нужно выгружать все оплаты (так как они включают оплаты поступившие из банка - их банк грузит), нужно выгружать только принятые в кассу Вашей организацией (их больше никто не загрузит).
[SIZE=85px][COLOR=greenpt]Отправлено спустя 20 минуты 27 секунды:[/COLOR][/SIZE]
[QUOTE]МарияМария пишет:
Добрый день.Только добралась до квитирования... с какой даты квитировать платежи-январь потом февраль и т.п или не важен порядок?
В ТП ГИСа сказали, что вообще начиная с июля надо квитировать платежные документы!  Платежи к тому же поступают из банка[/QUOTE]Да, хоть Вы и "позже подъехали" (вижу регистрацию на форуме в октябре), но обязанность размещать информацию есть с июля. В том числе и ПД. А где ПД, там и квитирование. Если Вы начали осуществлять управление позже июля, то естественно размещаете с момента когда начали. Как я понимаю, Вы не сможете разместить текущий ПД за период когда ЛС и договора еще не существовало.

Если Ваше ГЖИ не проверяет с какого месяца есть информация о ПД - то есть шанс "подвинуть" срок на более поздний, но это уже риск штрафа когда проверят. Тут все индивидуально. Я бы посоветовал как минимум разместить все ПД по которым прислали платежи банки (сами посмотрите с какого месяца) и проквитировать их. Это поможет минимально "навести порядок" в личных кабинетах потребителей, потому что иначе платежи от банков будут рассматриваться как "авансовые" и нарушать баланс.

Однако не обязательно делать с июля (или когда там банки начали слать) текущими ПД. Например, технически возможно разместить по 1 долговому ПД с суммарными начислениями за июль-декабрь (плюс долг на 1 июля) на каждый ЛС. Потом приквитировать все платежи до декабря к этому долговому ПД (если банки что-то из платежей не прислали, то самим загрузить до выравнивания баланса), а с января размещать текущие ПД и их квитировать.

По поводу порядка как квитировать - зависит как будут оплаты поступать. Если в оплате указан месяц, то обязаны приквитировать хотя бы копейку из суммы оплаты к ПД за тот месяц (а в идеале должны целиком совпасть суммы). Если месяц не указан - обычно закрывают самые старые ПД, но это вроде бы не регламентировано достаточно четко.
#
Можно сделать некую попытку реконструировать "логику" разработчиков ГИС. До момента ввода в шаблоне поля "оплачено" я в какой-то из тем доказал теорему, что задолженность за прошлые периоды, это не "сальдо на 1 число месяца", а "сальдо за миллисекунду до выставления ПД", тогда все логично сходилось. Суть была в том, чтобы к "сальдо на 1 число месяца" прибавить все что оплачено с 1 числа до даты выставления счета.

Исходя из предыдущей "логики", рискну предположить, что после добавления "оплачено"  оплату задолженностей в текущем периоде надо все равно плюсовать к задолженности за прошлые периоды, а в оплачено писать только оплату в текущем периоде (с прошлого выставления счета до текущего выставления счета) за текущий период, но без оплаты задолженностей в текущем периоде. Фактического подтверждения у меня нет, но похоже "логику" искривило в эту сторону. Тогда да, все что в оплачено "логично" падает на текущий ПД.
#
С такими условиями, мне уже захотелось послать им резюме на тестировщика)))) Только чую, что студенты меня быстро достанут и парой матов KPI уронится до нуля.
#
ГИС все время меняется, точно ответить сложно, тем более про порядок выборки документов ГИСом. Внутренних деталей нам не говорят, остается строить догадки методом тыка.

Как было: сумма оплаты квитировалась только с одним из ПД, со вторым (третьим, четвертым) нужно было квитировать вручную. Смысл был в том, что вручную смотрите куда лишнее закинуть. Сейчас (судя по сообщению AlexRed выше)видимо может вообще не сквитироваться автоматом. Хотя опять же мы не знаем наверняка, может в лк той организации автоматику когда-то отключили.

Порядок - по идее должен изначально выбираться ПД за тот период, который указан в оплате. Сейчас видимо приоритет сместился на текущий ПД (или скажем точнее - последний непогашенный, именно его показывает плательщику) и потому более вероятно, что из Вашего примера 10 рублей сквитируются с текущим, а 95 рублей повиснут для ручного квитирования с долговым. Однако, если период в оплате и период в долговом ПД совпадет, то возможно будет и наоборот - загасится полностью долговой ПД, а 5 рублей останутся для ручного квитирования.
#
[QUOTE]Елена 34 пишет:
Добрый день, при выгрузке оплаты из 1С вся оплата удваивается, не пойму почему. У кого нибудь было такое или может кто-то знает причину, подскажите пожалуйста.[/QUOTE]Удваивается при выгрузке из 1с в шаблон? Тогда это скорее к авторам конфигурации 1с вопрос.
Или удваивается при загрузке в ГИС выгруженного из 1с шаблона?
#
Да, регистрируют организацию они сами, сами получают функцию платежного агента. Как я понимаю, от Вас потребуется внести их как платежного агента и прикрепить договор по которому они принимают платежи. Они подтверждают договор и после подтверждения могут вносить платежи через ЛК в которых как получатель указаны Ваши реквизиты.

Если же они по СОАП работают, то кроме вышеперечисленного  им будет нужно дать разрешение от их организации к их ИС на внесение платежей.

Подпишись на рассылку новостей ЖКХ, а также наших статей!

Спасибо, вы успешно подписались на рассылку!