vk youtube zen telegram
+7(495) 118-21-35
crm
+7(495) 118-21-35
vk youtube zen telegram

До слета в Пятигорске осталось

  • 1
  • 2
  • 3
дня

Форум

Главнаяtwo_oceans

two_oceans

Активные темы Поиск Пользователи Правила ТОП 20
Форум » Пользователи » two_oceans

Форум

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

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

Тема

Сообщение

Упорядочить

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

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

P.S. Если не секрет, кто загонял? ГЖИ с лицензионными требованиями?
Ошибки в ГИС (эмоции пост)
 
#
28.09.2023 08:36:33
Добрый день. Возможно не по теме вопрос, но не придумал куда еще прицепить. В раскрытии не стал тему заводить. Сориентируйте меня пожалуйста в нынешних реалиях на предмет ГИСом единым или сайты УК сейчас обязательны? Кто-нибудь вообще ведет странички в ВК?

В блоге обсуждалось, но довольно давно [URL=https://www.burmistr.ru/news/news_company/nado-li-uk-tszh-ustanavlivat-formu-obratnoy-svyazi-na-sayt/]https://www.burmistr.ru/news/news_company/nado-li-uk-tszh-ustanavlivat-formu-obratnoy-svyazi-na-sayt...[/URL]
[URL=https://burmistr.ru/blog/gis-zhkkh/raskrytie_informatsii_2020_kak_my_dokatilis_do_zhizni_takoy/#review_anchor]https://burmistr.ru/blog/gis-zhkkh/raskrytie_informatsii_2020_kak_my_dokatilis_do_zhizni_takoy/#revi...[/URL]
Есть что новое по теме?
Ситуация какая: еще с начала 2022 года правительство области "рекомендует" ОМСУ "организовать работу по подключению организаций, осуществляющих управление МКД и ресурсоснабжающих организаций" к Платформе обратной связи ЕПГУ. В нашем ОМСУ за ПОС отвечает наш отдел. До сих пор мы этот пункт отклоняли по причине, что муниципальных УК у нас нет, а частные УК мы не можем завести как подведомственные организации. Хотя надо признать, что большинство обращений поступающих через ПОС связано именно с дорогами и ЖКХ, но есть и другие способы пожаловаться кроме ПОС. Про ту же ГИС ЖКХ параллельно идет информационная компания по привлечению граждан, но немного вяло, а вот ПОС прямо на хайпе.

К слову, по муниципальным организациям (даже не имеющим сайтов) от Минцифры РФ через Минцифру области заставили всем сделать странички-визитки (сообщества или как там они) в ВК (самая базовая информация: наименование организации, режим работы, адрес, логотип в одном стиле), получить госметки, разместить виджеты ПОС и дать доступ к ним областному боту. На днях бот впервые поменял обложки на страницах - среди подведов была паническая атака. Будьте готовы если что.

Однако вот сейчас пошел очередной виток - хотят чтобы мы собрали информацию с НЕмуниципальных УК и РСО об ответственных лицах за обработку сообщений на ПОС. Надо полагать их заведут от области потом к ним будут домогаться с такими же процедурами. Вот только в постановлении Правительства РФ сказано вообще неявно "иные организации, осуществляющие публично значимые функции", а конкретизируется уже совещаниями между Минцифрами РФ и региона.Так что и непонятно на что ссылаться при сборе данных УК и РСО, но также и непонятно как от этого отбиться.
Подскажите люди добрые последние новости ГИСа, что нового за полгода выдумали для ГИСа?
 
#
30.12.2020 11:34:06
[QUOTE]axx написал:
[QUOTE][URL=/forum/?PAGE_NAME=profile_view&UID=15815&t=10416]olegkriv[/URL] написал:
Дочерней организации у нас нет, где ООО взять ребенка чтобы попасть в эту "волшебную" ГИС???[/QUOTE]
насколько я понимаю, под ЭЦП организацией Вы понимаете ЭЦП ее руководителя, вот про его ребенка и идет речь скорее всего. В чистом виде ЭЦП организации не существует, она всегда привязана к должностному лицу[/QUOTE]
Если Вам о них не известно, то это не значит что их не существует. Частный случай - серверный сертификат для удостоверения сайта организации, в нем возможно не указывать ФИО и снилс. Зато по отечественному законодательству там указывается огрн и наименование организации, то есть это чистый сертификат юридического лица. Просто число отечественных УЦ, которые их выпускают стремится к нулю.

На самом деле, клиентские сертификаты (без ФИО и снилса, но с огрн и иногда с должностью) тоже есть (аналог печати органа государственной власти или ОМСУ, предназначены для автоматического использования), ими можно подписывать документы (отчеты, запросы в СМЭВ, например), входить на некоторые сайты ФНС, но таким сертификатом нельзя войти на ЕСИА. ЕСИА принимает только сертификаты с ФИО и снилс. За такой сертификат без ФИО в общем случае конечно отвечает руководитель как уполномоченное лицо, но есть возможность уполномочить начальника IT отдела.
Подскажите люди добрые последние новости ГИСа, что нового за полгода выдумали для ГИСа?
 
#
16.12.2020 07:32:33
Для примерной оценки, у нас в городе тоже полгода периодичность "переаттестации" для получения субсидии. Из-за пандемии есть областное пояснение со ссылкой на постановление правительства о беззаявительном порядке продления субсидии. Однако, при переаттестации требуются данные о показаниях ПУ для корректного расчета субсидии (кому-то добавляют за прошедшие полгода, кому-то удерживают). В этом году РСО отопление не разбрасывала на летний период, так что летом практически у половины внезапно получилось, что субсидия не положена. Однако их все равно занесли в программу и в сентябре пересчитали - снова субсидия положена.

Вкратце, если начисления индивидуально меняются (от показаний ПУ, например), то нужно информацию за каждый месяц. Если начисления относительно одинаковы (от количества людей или площади, а изменения тарифа известны начисляющим субсидию), то нужно на конец периода (раз в полгода). Как минимум по тем, кто получает субсидии - у нас в городе это примерно 4-5% (2000-2500) от количества лицевых счетов (40000-50000).

Поэтому (с точки зрения начисляющих субсидию) конечно очень неудобно если запрос будет на каждого человека и срок всего 5 дней - гораздо проще было бы заранее (и как-то автоматически) запросить списком тех у кого запланирована переаттестация в этом месяце (пусть даже срок дольше) и заранее получить ответ по не имеющим задолженности (на кого даже не подавали в суд), а "новеньких" и должников (кто еще в суде или судебно признаны) уже запрашивать индивидуально - когда придут (вдруг оплатили). По одному колотить 330-400 человек в личном кабинете гис жкх - сомнительное удовольствие, а списки как водится могут на несколько дней зависать в обработке.
Подскажите люди добрые последние новости ГИСа, что нового за полгода выдумали для ГИСа?
 
#
10.12.2020 13:29:16
Добрый день, коллеги.
Вот и нам прислали бумаги (как водится датировано 9 ым числом, что надо сделать и отчитаться до 8 го) и я такой решил вспомнить, что такое ГИС ЖКХ (давненько заводил пользователей через госуслуги, а по текущим добавкам прав назначен еще один админ на гис жкх). Пользователей, ответственных за новое направление завел на госуслуги (конечно нашлось по паре аккаунтов через АРМ "Центр обслуживания"). Сказка о предоставлении доступа в 5 частях (приглашение - вспоминание пароля и присоединение - права ЕСИА на гис жкх - вход в гис жкх без реальных прав и пользовательское соглашение - назначение прав гис жкх).

Тыкнулся в ГИС ЖКХ, а там только галочка.Теперь выходит еще будет продолжение про ожидание реализации функционала. Да, начинаю вспоминать, что такое гис жкх. Серьезно, могли бы разработчики хоть сам пункт меню добавить с сообщением о разработке функционала. Было бы удобно скриншотить.
Докажи, что оплатил госпошлину! Иногда суды не понимают одну тонкость
 
#
11.09.2020 08:17:13
[QUOTE]Счетовод ВоТруБа пишет:
Все госпошлины видны в базе казначейства  ГИС ГМС.[/QUOTE]
ГИС ГМП - конечно есть, правда пользовательского интерфейса нет, каждое ведомство пишет свою програмку на доступ через СМЭВ. С подключением к СМЭВ свои закидоны.

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

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

Короче, подключить судей к ГИС ГМП еще задачка. Аналогично с ЗАГС. Не знаю как у кого, а у нас в области вообще ерунда с ГИС ГМП, начисляют в основном те у кого менее 100 начислений в год.
Минкомсвязи: «Новые ГОСТы для нормальной работы ГИС ЖКХ? Нет, не слышали…»
 
#
22.02.2019 05:49:24
[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 прошляпили. Полагаю, тут есть и частичная вина самих владельцев ИС, что они верили в своевременный переход ГИС на новый гост (как будто в раю живут, ага), за сроком своих сертификатов не проследили и пропустили уведомления УЦ мимо ушей. Подытоживая, ГИС ЖКХ и Минкомсвязь это не оправдывает, но и владельцам ИС надо помнить где живут и не терять бдительности.
Квитирование\Не сквитировано\Предварительно сквитировано\Сквитировано
 
#
11.07.2018 05:08:31
[quote:3dasmdq9]А один банк вместо 5 000 руб прислал, что оплатили 500 000 руб.[/quote:3dasmdq9]Если разница в 100 раз, скорее всего, этот банк указал сумму в копейках, как по форматам ГИС ГМП, и это недоработка программного обеспечения. Очень желательно связаться с банком и сообщить им, что данные платежа видны в ГИС ЖКХ неверно. Пусть в свою очередь разберутся со своими программистами в чем проблема.
Росреестр и кадастровые номера помещений и домов
 
#
14.06.2018 13:09:31
[QUOTE]Andrey_S пишет:
Но размещают они (РР) инфу через сервисы СМЭВ для ГИС ЖКХ, разработанные Ланитом[/QUOTE]А поподробнее почитать есть ссылка, что РР через интеграцию прицпелен? Какие у них роли? Судя по межведу - у РР достаточно тормозная сеть (или шлюз обмена со СМЭВ) внутри РР запрос может идти до 5 часов пока достигнет СМЭВ (видим по разнице в отметках времени между формированием и отправкой в СМЭВ). За это время чаще всего успевает закончиться рабочий день и мы видим запрос только на следующий день. Аналогично когда запрос посылаем мы, он шустро доходит до шлюза СМЭВ РР, через минуту регистрируется на их портале и зависает пока его увидят специалисты областного уровня. Минимальное время ответа отказом было около 40 минут. А так тоже может полдня где-то болтаться. Потом приходит почта с портала, что выполнен и втечение 20-30 минут появляется в СМЭВ. Так что думаю получится ужас, если сцепить РР через СМЭВ с ГИС жКХ.

Почему-то мне больше представляется, что все же обработка пакетная, как и с ФИАС. Выгружают дамп БД, а студенты Ланита при установке очередной версии пытается дамп "переварить".
ГИС ЖКХ: квитирование
 
#
01.06.2018 12:46:49
[QUOTE]Andrey_S пишет:
Нет. ПД это не просто выставленный "счет к оплате", а подробная информационная выкладка о состоянии взаиморасчетов.[/QUOTE]Проясним. Я согласен, что промежуточные цифры по взаиморасчетам могут стать отрицательными, и даже что итог по конкретной услуге может стать отрицательным. Однако Вы говорите "с отрицательной суммой документа", то есть либо в документе всего одна услуга (серьезно?) либо другие услуги не компенсируют минус по конкретной услуге (бывает и такое?).
Также похоже есть разница в терминологии и "сумма документа" отличается от "сумма к оплате"? Как я понимаю, ГИС будет категорически сопротивляться факту, что "сумма к оплате" станет отрицательная и при обработке исправит на ноль. Поэтому я и спрашиваю, удалось ли кому-то перебороть эту особенность ГИСа и разместить ПД, не исправленный на ноль.
[QUOTE]Andrey_S пишет:
Как выставление ПД с положительной суммой начислений не означает, что по нему в течение месяца будет выполнена оплата, так и выставление ПД с отрицательной суммой не означает, что в течение месяца будет сделан возврат.[/QUOTE]Частично соглашусь. По крайней мере, отрицательная сумма по услуге А означает, что деньги из состояния "оплачены по услуге А" виртуально перешли в какое-то другое состояние, например, "к возврату" или "оплачены по услуге Б". Однако, полагаю, должен быть предельный срок при переходе между состояниями "к возврату" и "возвращены". Например, при денежных расчетах по выборам деньги должны быть возвращены в срок от 10 до 45 дней (в зависимости от ситуации).
Ошибки в ГИС (эмоции пост)
 
#
31.05.2018 12:16:47
[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" как раз и есть "Остаток к оплате"? Если да, то по начислениям у которых не указано ФИО он просто не вернется. И по начисления где банк запрашивает без ФИО тоже. Вот такая вот "защита персональных данных".
ГИС ЖКХ: квитирование
 
#
31.05.2018 11:46:14
[QUOTE]Andrey_S пишет:
Контроль целостности есть. По нашему опыту нельзя ни аннулировать, ни изменить платежи со статусом, отличным от "Новый" (неквитированный).[/QUOTE]
В конкретном частном случае, если УК сама и принимает все платежи в кассу и начисляет ПД, то проблемы это не составит - сквитировать сможет только сама УК либо автоквитирование сработает. Если передавать платеж (авансовый) так, чтобы автоквитирование не срабатывало, то вполне можно сделать себе пространство для маневра, оставляя авансовые платежи несквитированными "Новыми".
В общем случае - конечно проблематично с таким недоделанным контролем целостности.

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

Мы недавно установили прямой контакт с Центральным аппаратом Сбера как раз в связи с локализацией этих проблем (технологии двигаются именно Сбером, движущим стимулом является самомотивация на внедрение функционала "Автоплатежей" по запросу сведений из ГИС ЖКХ).[/quote:1g4hczax]Если автоплатеж не будет фиксированной суммой, а по реальному размеру к оплате, то конечно будет проще, наверно всем. Видел в списке сервисов СМЭВ сведения для оплаты ЖКХ, так что наверно речь больше об отражении в них текущего "остатка к оплате"?
Смена наименования Общества в ГИС
 
#
31.05.2018 09:34:23
Где-то тут уже был подобный вопрос. Если инн/огрн организации остался прежний и сменилось только название, то нужно:
1) обновить ЕГРЮЛ;
2) зайти в кабинет организации в ЕСИА (госуслугах), желательно руководителем/администратором;
3) нажать на обновить данные организации.
ЕСИА подгрузит данные из ЕГРЮЛ, а чуть позже ГИС ЖКХ получит данные из ЕСИА.
Если изменился инн/огрн организации - регистрируем заново.
ГИС ЖКХ: квитирование
 
#
31.05.2018 09:20:32
[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]Головоломка еще та.
Связь ГИС ЖКХ и иных ИС
 
#
24.05.2018 15:05:23
Хотелось бы еще уточнить, раз вопрос был от РСО со своей ИС: если в гис уже есть эталонные помещения с кадастровым номером, занесенные УК, то возможно имеет смысл данные помещений из гиса загрузить в вашу ИС (хотя бы частично подтянуть данные которых у вас нет, например, часто у рсо нет номеров подъезда для помещений), тогда точно не испортите что УК загружает, ну и меньше забивать в ИС вручную. Таким образом, в идеале нужно в процесс интеграции включить и загрузку в ИС из ГИС данных, внесенных другими поставщиками (чтобы их не перезаписать старыми данными из ИС).
Новое поле в помещениях "Информация подтверждена поставщиком, ответственным за размещение сведений"
 
#
24.05.2018 13:41:48
[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.
Новое поле в помещениях "Информация подтверждена поставщиком, ответственным за размещение сведений"
 
#
22.05.2018 12:59:06
Контроль ссылочной целостности говорите? Ну это конечно замечательно, однако учитывая, как все это проявляется (только ставит в палки в колеса при наличии ЛС и ПУ), до настоящего контроля целостности там еще пилить и пилить. Потому как в полной реализации контроль не только проверяет наличие дочерних/родительских записей, но и при некоторых условиях позволяется дочерние записи либо каскадно удалять при удалении родительской записи либо переводить на другого родителя, а при обнаружении записи без родителя ("сиротской") можно либо ее отредактировать на другого родителя либо удалить либо создать соответствующую родительскую запись. Уже не говорю про недопустимость дублей и возможность не заполнять информацию, уже имеющуюся в системе.

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

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

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

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

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

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

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

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

Видимо ГИС по эцп узнает человека и кидает в первую организацию. Вероятно нужно удалить сотрудника из старой организации - из группы доступа в госуслугах, например. При этом должно стать недействительно пользовательское соглашение для первой организации. Для лучшего эффекта наверно из обеих удалить, сколько-то подождать чтобы перестало заходить и в 1 и во 2, потом в вторую добавить еще раз и подождать пока гис его опознает от второй организации и выдаст пользовательское соглашение. Кроме того, первый раз во вторую организацию нужно зайти по эцп директора второй организации и принять пользовательское соглашение. Как-то так, полагаю.
Связь ГИС ЖКХ и иных ИС
 
#
05.04.2018 12:40:36
Хотелось бы заметить, что чуть ниже отдельная тема только по 1С, где просили всех откликнуться. Но откликаются как всегда в непрофильных темах.  :lol:
Загрузка платежей в ГИС
 
#
26.03.2018 05:36:28
[quote:14px9vpp]Мы РСО, через нашу кассу идут платежи только по нашим квитанциям. Соответственно, мы должны размещать информацию по оплатам.
В функциях организации добавили "Оператор по приему платежей". Важно или нет, не знаю, но по этой функции статус "Заявлено организацией", а по остальным - "Подтверждено". [/quote:14px9vpp]Статус должен быть "Подтверждено". Однако, как я понимаю, в свой адрес можно грузить платежи и без этой функции. В правах, которые делегированы своей информационной системе должны быть разрешены операции с платежами. Если Вы размещаете только платежи в свой адрес принятые в свою кассу, то при интеграции нужно использовать метод загрузки платежей со словом Supplier. Однако будьте внимательны - он запрашивает гораздо меньше реквизитов и потому этим методом легко наделать дублей платежа - ГИС не хватает реквизитов для выявления дублей.
Ошибки в ГИС (эмоции пост)
 
#
26.03.2018 01:51:39
[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 в текстовом виде.

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

P.S. Если не секрет, кто загонял? ГЖИ с лицензионными требованиями?
#
28.09.2023
Добрый день. Возможно не по теме вопрос, но не придумал куда еще прицепить. В раскрытии не стал тему заводить. Сориентируйте меня пожалуйста в нынешних реалиях на предмет ГИСом единым или сайты УК сейчас обязательны? Кто-нибудь вообще ведет странички в ВК?

В блоге обсуждалось, но довольно давно [URL=https://www.burmistr.ru/news/news_company/nado-li-uk-tszh-ustanavlivat-formu-obratnoy-svyazi-na-sayt/]https://www.burmistr.ru/news/news_company/nado-li-uk-tszh-ustanavlivat-formu-obratnoy-svyazi-na-sayt...[/URL]
[URL=https://burmistr.ru/blog/gis-zhkkh/raskrytie_informatsii_2020_kak_my_dokatilis_do_zhizni_takoy/#review_anchor]https://burmistr.ru/blog/gis-zhkkh/raskrytie_informatsii_2020_kak_my_dokatilis_do_zhizni_takoy/#revi...[/URL]
Есть что новое по теме?
Ситуация какая: еще с начала 2022 года правительство области "рекомендует" ОМСУ "организовать работу по подключению организаций, осуществляющих управление МКД и ресурсоснабжающих организаций" к Платформе обратной связи ЕПГУ. В нашем ОМСУ за ПОС отвечает наш отдел. До сих пор мы этот пункт отклоняли по причине, что муниципальных УК у нас нет, а частные УК мы не можем завести как подведомственные организации. Хотя надо признать, что большинство обращений поступающих через ПОС связано именно с дорогами и ЖКХ, но есть и другие способы пожаловаться кроме ПОС. Про ту же ГИС ЖКХ параллельно идет информационная компания по привлечению граждан, но немного вяло, а вот ПОС прямо на хайпе.

К слову, по муниципальным организациям (даже не имеющим сайтов) от Минцифры РФ через Минцифру области заставили всем сделать странички-визитки (сообщества или как там они) в ВК (самая базовая информация: наименование организации, режим работы, адрес, логотип в одном стиле), получить госметки, разместить виджеты ПОС и дать доступ к ним областному боту. На днях бот впервые поменял обложки на страницах - среди подведов была паническая атака. Будьте готовы если что.

Однако вот сейчас пошел очередной виток - хотят чтобы мы собрали информацию с НЕмуниципальных УК и РСО об ответственных лицах за обработку сообщений на ПОС. Надо полагать их заведут от области потом к ним будут домогаться с такими же процедурами. Вот только в постановлении Правительства РФ сказано вообще неявно "иные организации, осуществляющие публично значимые функции", а конкретизируется уже совещаниями между Минцифрами РФ и региона.Так что и непонятно на что ссылаться при сборе данных УК и РСО, но также и непонятно как от этого отбиться.
#
30.12.2020
[QUOTE]axx написал:
[QUOTE][URL=/forum/?PAGE_NAME=profile_view&UID=15815&t=10416]olegkriv[/URL] написал:
Дочерней организации у нас нет, где ООО взять ребенка чтобы попасть в эту "волшебную" ГИС???[/QUOTE]
насколько я понимаю, под ЭЦП организацией Вы понимаете ЭЦП ее руководителя, вот про его ребенка и идет речь скорее всего. В чистом виде ЭЦП организации не существует, она всегда привязана к должностному лицу[/QUOTE]
Если Вам о них не известно, то это не значит что их не существует. Частный случай - серверный сертификат для удостоверения сайта организации, в нем возможно не указывать ФИО и снилс. Зато по отечественному законодательству там указывается огрн и наименование организации, то есть это чистый сертификат юридического лица. Просто число отечественных УЦ, которые их выпускают стремится к нулю.

На самом деле, клиентские сертификаты (без ФИО и снилса, но с огрн и иногда с должностью) тоже есть (аналог печати органа государственной власти или ОМСУ, предназначены для автоматического использования), ими можно подписывать документы (отчеты, запросы в СМЭВ, например), входить на некоторые сайты ФНС, но таким сертификатом нельзя войти на ЕСИА. ЕСИА принимает только сертификаты с ФИО и снилс. За такой сертификат без ФИО в общем случае конечно отвечает руководитель как уполномоченное лицо, но есть возможность уполномочить начальника IT отдела.
#
16.12.2020
Для примерной оценки, у нас в городе тоже полгода периодичность "переаттестации" для получения субсидии. Из-за пандемии есть областное пояснение со ссылкой на постановление правительства о беззаявительном порядке продления субсидии. Однако, при переаттестации требуются данные о показаниях ПУ для корректного расчета субсидии (кому-то добавляют за прошедшие полгода, кому-то удерживают). В этом году РСО отопление не разбрасывала на летний период, так что летом практически у половины внезапно получилось, что субсидия не положена. Однако их все равно занесли в программу и в сентябре пересчитали - снова субсидия положена.

Вкратце, если начисления индивидуально меняются (от показаний ПУ, например), то нужно информацию за каждый месяц. Если начисления относительно одинаковы (от количества людей или площади, а изменения тарифа известны начисляющим субсидию), то нужно на конец периода (раз в полгода). Как минимум по тем, кто получает субсидии - у нас в городе это примерно 4-5% (2000-2500) от количества лицевых счетов (40000-50000).

Поэтому (с точки зрения начисляющих субсидию) конечно очень неудобно если запрос будет на каждого человека и срок всего 5 дней - гораздо проще было бы заранее (и как-то автоматически) запросить списком тех у кого запланирована переаттестация в этом месяце (пусть даже срок дольше) и заранее получить ответ по не имеющим задолженности (на кого даже не подавали в суд), а "новеньких" и должников (кто еще в суде или судебно признаны) уже запрашивать индивидуально - когда придут (вдруг оплатили). По одному колотить 330-400 человек в личном кабинете гис жкх - сомнительное удовольствие, а списки как водится могут на несколько дней зависать в обработке.
#
10.12.2020
Добрый день, коллеги.
Вот и нам прислали бумаги (как водится датировано 9 ым числом, что надо сделать и отчитаться до 8 го) и я такой решил вспомнить, что такое ГИС ЖКХ (давненько заводил пользователей через госуслуги, а по текущим добавкам прав назначен еще один админ на гис жкх). Пользователей, ответственных за новое направление завел на госуслуги (конечно нашлось по паре аккаунтов через АРМ "Центр обслуживания"). Сказка о предоставлении доступа в 5 частях (приглашение - вспоминание пароля и присоединение - права ЕСИА на гис жкх - вход в гис жкх без реальных прав и пользовательское соглашение - назначение прав гис жкх).

Тыкнулся в ГИС ЖКХ, а там только галочка.Теперь выходит еще будет продолжение про ожидание реализации функционала. Да, начинаю вспоминать, что такое гис жкх. Серьезно, могли бы разработчики хоть сам пункт меню добавить с сообщением о разработке функционала. Было бы удобно скриншотить.
#
11.09.2020
[QUOTE]Счетовод ВоТруБа пишет:
Все госпошлины видны в базе казначейства  ГИС ГМС.[/QUOTE]
ГИС ГМП - конечно есть, правда пользовательского интерфейса нет, каждое ведомство пишет свою програмку на доступ через СМЭВ. С подключением к СМЭВ свои закидоны.

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

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

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

Почему-то мне больше представляется, что все же обработка пакетная, как и с ФИАС. Выгружают дамп БД, а студенты Ланита при установке очередной версии пытается дамп "переварить".
#
01.06.2018
[QUOTE]Andrey_S пишет:
Нет. ПД это не просто выставленный "счет к оплате", а подробная информационная выкладка о состоянии взаиморасчетов.[/QUOTE]Проясним. Я согласен, что промежуточные цифры по взаиморасчетам могут стать отрицательными, и даже что итог по конкретной услуге может стать отрицательным. Однако Вы говорите "с отрицательной суммой документа", то есть либо в документе всего одна услуга (серьезно?) либо другие услуги не компенсируют минус по конкретной услуге (бывает и такое?).
Также похоже есть разница в терминологии и "сумма документа" отличается от "сумма к оплате"? Как я понимаю, ГИС будет категорически сопротивляться факту, что "сумма к оплате" станет отрицательная и при обработке исправит на ноль. Поэтому я и спрашиваю, удалось ли кому-то перебороть эту особенность ГИСа и разместить ПД, не исправленный на ноль.
[QUOTE]Andrey_S пишет:
Как выставление ПД с положительной суммой начислений не означает, что по нему в течение месяца будет выполнена оплата, так и выставление ПД с отрицательной суммой не означает, что в течение месяца будет сделан возврат.[/QUOTE]Частично соглашусь. По крайней мере, отрицательная сумма по услуге А означает, что деньги из состояния "оплачены по услуге А" виртуально перешли в какое-то другое состояние, например, "к возврату" или "оплачены по услуге Б". Однако, полагаю, должен быть предельный срок при переходе между состояниями "к возврату" и "возвращены". Например, при денежных расчетах по выборам деньги должны быть возвращены в срок от 10 до 45 дней (в зависимости от ситуации).
#
31.05.2018
[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" как раз и есть "Остаток к оплате"? Если да, то по начислениям у которых не указано ФИО он просто не вернется. И по начисления где банк запрашивает без ФИО тоже. Вот такая вот "защита персональных данных".
#
31.05.2018
[QUOTE]Andrey_S пишет:
Контроль целостности есть. По нашему опыту нельзя ни аннулировать, ни изменить платежи со статусом, отличным от "Новый" (неквитированный).[/QUOTE]
В конкретном частном случае, если УК сама и принимает все платежи в кассу и начисляет ПД, то проблемы это не составит - сквитировать сможет только сама УК либо автоквитирование сработает. Если передавать платеж (авансовый) так, чтобы автоквитирование не срабатывало, то вполне можно сделать себе пространство для маневра, оставляя авансовые платежи несквитированными "Новыми".
В общем случае - конечно проблематично с таким недоделанным контролем целостности.

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

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

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

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

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

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

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

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

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

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

Видимо ГИС по эцп узнает человека и кидает в первую организацию. Вероятно нужно удалить сотрудника из старой организации - из группы доступа в госуслугах, например. При этом должно стать недействительно пользовательское соглашение для первой организации. Для лучшего эффекта наверно из обеих удалить, сколько-то подождать чтобы перестало заходить и в 1 и во 2, потом в вторую добавить еще раз и подождать пока гис его опознает от второй организации и выдаст пользовательское соглашение. Кроме того, первый раз во вторую организацию нужно зайти по эцп директора второй организации и принять пользовательское соглашение. Как-то так, полагаю.
#
05.04.2018
Хотелось бы заметить, что чуть ниже отдельная тема только по 1С, где просили всех откликнуться. Но откликаются как всегда в непрофильных темах.  :lol:
#
26.03.2018
[quote:14px9vpp]Мы РСО, через нашу кассу идут платежи только по нашим квитанциям. Соответственно, мы должны размещать информацию по оплатам.
В функциях организации добавили "Оператор по приему платежей". Важно или нет, не знаю, но по этой функции статус "Заявлено организацией", а по остальным - "Подтверждено". [/quote:14px9vpp]Статус должен быть "Подтверждено". Однако, как я понимаю, в свой адрес можно грузить платежи и без этой функции. В правах, которые делегированы своей информационной системе должны быть разрешены операции с платежами. Если Вы размещаете только платежи в свой адрес принятые в свою кассу, то при интеграции нужно использовать метод загрузки платежей со словом Supplier. Однако будьте внимательны - он запрашивает гораздо меньше реквизитов и потому этим методом легко наделать дублей платежа - ГИС не хватает реквизитов для выявления дублей.
#
26.03.2018
[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 в текстовом виде.

Заметьте, они оптимизируют не время обработки запроса от поставщика информации, а время когда изменяют структуру данных во время техработ. Даже не "те (проблемы), что есть у поставщиков информации в их собственном представлении". Про диалог с поставщиками похоже они и не думали.
Активные темы Поиск Пользователи Правила ТОП 20
Форум » Пользователи » two_oceans

Подписаться на рассылку
CAPTCHA

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

Оставить заявку на сайт

На какой период нужен сайт

Нужно ли вам наполнение новостей на сайте по общегосударственным праздникам?

Нужен ли вам новый логотип

Введите код с картинки

CAPTCHA
Поменять картинку

Мы получили Вашу заявку, скоро наши менеджеры свяжутся с Вами. Спасибо!

Годовая подписка на вебинары

Являлись ли участником «Закрытой ветки» ранее

Введите код с картинки

CAPTCHA
Поменять картинку

Мы получили Вашу заявку, скоро наши менеджеры свяжутся с Вами. Спасибо!

Заказать звонок

Введите код с картинки

CAPTCHA
Поменять картинку

Спасибо, мы скоро свяжемся с Вами!

Подать заявку

Название организации*

ИНН*

КПП*

ФИО Руководителя*

Должность руководителя*

Город*

Адрес*

Расчетный счет*

БИК*

Банк*

Кор. счет*

Моб. телефон*

E-mail (уникальный для каждой компании)*

Откуда Вы о нас узнали?*

Введите код с картинки

CAPTCHA
Поменять картинку
Спасибо!
С вами свяжется наш менеджер и поможет вам в регистрации
Подать заявку

Название организации*

ИНН*

КПП*

ФИО Руководителя*

Должность руководителя*

Город*

Адрес*

Расчетный счет*

БИК*

Банк*

Кор. счет*

Моб. телефон*

E-mail (уникальный для каждой компании)*

Откуда Вы о нас узнали?*

Введите код с картинки

CAPTCHA
Поменять картинку
Спасибо!
С вами свяжется наш менеджер и поможет вам в регистрации
Спасибо!
Ваше сообщение отправлено !
Подключить онлайн кассы
CAPTCHA

Ваша заявка принята!

Оставить заявку на расчет квартплаты

Уже пользуетесь CRM-системой Квартира.Бурмистр.ру?

Введите код с картинки

CAPTCHA
Поменять картинку

Мы получили Вашу заявку, скоро наши менеджеры свяжутся с Вами. Спасибо!

Оставить заявку на брендирование

Введите код с картинки

CAPTCHA
Поменять картинку

Мы получили Вашу заявку, скоро наши менеджеры свяжутся с Вами. Спасибо!

Подключить маркетплейс услуг

Введите код с картинки

CAPTCHA
Поменять картинку

Мы получили Вашу заявку, скоро наши менеджеры свяжутся с Вами. Спасибо!

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

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

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