20.03.2018 12:36:38
С такими условиями, мне уже захотелось послать им резюме на тестировщика)))) Только чую, что студенты меня быстро достанут и парой матов KPI уронится до нуля.
|
20.03.2018 12:11:56
ГИС все время меняется, точно ответить сложно, тем более про порядок выборки документов ГИСом. Внутренних деталей нам не говорят, остается строить догадки методом тыка.
Как было: сумма оплаты квитировалась только с одним из ПД, со вторым (третьим, четвертым) нужно было квитировать вручную. Смысл был в том, что вручную смотрите куда лишнее закинуть. Сейчас (судя по сообщению AlexRed выше)видимо может вообще не сквитироваться автоматом. Хотя опять же мы не знаем наверняка, может в лк той организации автоматику когда-то отключили. Порядок - по идее должен изначально выбираться ПД за тот период, который указан в оплате. Сейчас видимо приоритет сместился на текущий ПД (или скажем точнее - последний непогашенный, именно его показывает плательщику) и потому более вероятно, что из Вашего примера 10 рублей сквитируются с текущим, а 95 рублей повиснут для ручного квитирования с долговым. Однако, если период в оплате и период в долговом ПД совпадет, то возможно будет и наоборот - загасится полностью долговой ПД, а 5 рублей останутся для ручного квитирования. |
20.03.2018 04:37:06
[QUOTE]Елена 34 пишет:
Добрый день, при выгрузке оплаты из 1С вся оплата удваивается, не пойму почему. У кого нибудь было такое или может кто-то знает причину, подскажите пожалуйста.[/QUOTE]Удваивается при выгрузке из 1с в шаблон? Тогда это скорее к авторам конфигурации 1с вопрос. Или удваивается при загрузке в ГИС выгруженного из 1с шаблона? |
19.03.2018 05:56:05
Да, регистрируют организацию они сами, сами получают функцию платежного агента. Как я понимаю, от Вас потребуется внести их как платежного агента и прикрепить договор по которому они принимают платежи. Они подтверждают договор и после подтверждения могут вносить платежи через ЛК в которых как получатель указаны Ваши реквизиты.
Если же они по СОАП работают, то кроме вышеперечисленного им будет нужно дать разрешение от их организации к их ИС на внесение платежей. |
19.03.2018 05:37:58
[QUOTE]Natulka93 пишет:
Согласна, но если человек переплатил хорошенько и просит перенести, то ведь нужно переносить.[/QUOTE]Они предусмотрели только перенос на другой период (убогим квитированием). Я конечно понимаю, что все переносят оплату... но есть какие-то положения из нормативки, которые это разрешают? А то может не только изменять начисления, но и переносить нельзя? И мы просто не такие "продвинутые в цитировании нормативки" как разработчики ГИС? Если же положение нормативки есть, то надо наехать на разработчиков ГИС. Может сделают в версии 100.500. |
13.03.2018 10:49:30
Если задолженность до начала размещения в ГИС, то нужно сделать долговой ПД перед самым первым размещаемым периодом, один раз. Потом добавлять текущие. Тогда будет сначала квитироваться на долговой ПД. Это если по старой схеме квитирования, где ПД и платежи. Как по новой (по "оплачено" в шаблоне) квитировать ТП вообще не может внятно объяснить, цитируют старую схему. Наверно надо сначала пока старая задолженность есть добить ее по старой схеме, а уже потом шаблонами закидывать.
Вот что ТП и по старой схеме не может объяснить такую простую вещь русским языком и выдают "платежным документом за тот период в котором возникла задолженность" вместо "долговым ПД", это, *бип*, печально. |
13.03.2018 10:01:10
Не совсем верно, а что делать... по-другому "официально" не перенести. Впрочем, я уже начитался в чате интеграции, что некая УК смогла внести квартиры с отрицательной площадью (и такие ЛС не экспортируются из ГИС)!! Полагаю, на них будет начисляться отрицательная плата. :lol: А Вы говорите "не совсем верно"... ГИС отрицательные площади не смущают, наверняка и отрицательную плату можно как-то пропихнуть.
Идеальный вариант: работать с банком и приучать вносить нормальные цифры по услугам, а не как делают многие банки - сумма сходится, а по услугам раскидана как оператору банка пришло в голову. Абсолютно не обращают внимание, что есть долг за прошлые периоды по одной из услуг, а по другой переплата, автоматом ставят за отопление сумму ровно за один месяц, остальное художественно раскидывают. Лично меня бесит, что потом в личном кабинете но одной услуге переплата 80,02 руб., по другой долг 80,00 руб, в сумме переплата 2 копейки, но строка с долгом горит красным. И у нас летом невозможно погасить долг за горячую воду (текущей платы по горячей воде летом нет согласно решению местной Думы), сколько ни напишешь оператору банка, он все равно ставит 0 по горячей воде и раскидывает по другим услугам. |
13.03.2018 08:12:17
Да, заставить РЦ будет сложно. Основная проблема, что чтобы нормально пользоваться ГИС, РЦ должен интегрироваться по СОАП. Как я понимаю, нет загрузки шаблонов и форм ручного ввода в личном кабинете РЦ. Отвечу как все может быть, если РЦ идет Вам на встречу.
Во многом все зависит, хотите ли сделать единый платежный документ. Если нет, то заполняете ЛС сами и выставляете счета (ПД) сами, а РЦ только как платежный агент должен вносить принятые оплаты. То что Вы оформили их как платежного агента как раз дает возможность им вносить платежи, указывая в качестве получателя оплат Ваши реквизиты. Так делают большинство, однако единую платежку так сделать будет очень сложно. В этом случае, есть возможность делегировать полномочия от УК к РЦ, чтобы РЦ смог выставлять ПД на ЛС, созданный Вами. Или создать ЛС УК/ЛС РСО от Вашего имени. Это может понадобится, если РЦ производит начисления. С другой стороны, заставить РЦ выставлять ПД нельзя, даже если РЦ делает начисления, так как есть законный вариант, при котором РЦ будет Вам отдавать заполненные шаблоны ПД, а Вы мучаться с загрузкой этих шаблонов. Если же на повестке стоит единый платежный документ, то по идее РЦ [B][U]может[/U][/B] создать единый ЛС (типа ЛС РЦ) и указать в основаниях как все договоры ресурсоснабжения (допустимо несколько), так и договор управления или социального найма (только один, в дополнение к нескольким ресурсоснабжения; управления и социального найма, как я понял, взаимоисключающие). И соответственно прицепить на ЛС РЦ все услуги, указанные в этих нескольких договорах. В этом случае РЦ сможет выставлять на все это единый ПД. Не ясно пока, как именно в едином ПД должны указываться реквизиты нескольких организаций. Поэтому пока единые платежки РЦ пробуют выставить на реквизиты РЦ, что неправильно. Еще раз подчеркну, для открытия лицевого счета с несколькими основаниями РЦ должен получить функцию РЦ и интегрироваться по СОАП. В итоге, пока РЦ с опытом такого очень мало, а документация ГИС ЖКХ по интеграции сильно отстает (в частности, про договоры управления на ЛС РЦ не говорится, что многих ввело в заблуждение, но фактически ГИС принимает и договора управления при открытии ЛС РЦ). |
05.03.2018 09:28:26
[QUOTE]Programmer пишет:
Да простит меня two_oceans, но я считаю, что хитроумные ИД приборов учета там и на фиг не нужны. Можно без них обойтись.[/QUOTE]Легко прощу, я даже не помню уже когда про это говорил. Другим пока голова занята - выборы-с. Насчет ИД приборов учета, полагаю, я говорил (точно не помню), что они нужны внутри системы "чисто для порядка", и если кто-то при интеграции может обойтись без них, то я не буду на него обижаться. :lol: Вне системы это нужно лишь как опция, если кто не может без них интегрироваться. Тем более, насчет хитроумности, чем проще тем лучше. К слову, лично для меня самым успешным примером идентификаторов являются mac-адреса сетевых плат. Сколько уж лет прошло, а адреса еще работают. |
05.03.2018 08:10:53
В общем случае "отсутствует родительская запись" возникает когда указан некий код объекта, но объекта с таким кодом нет. Как правило такую ошибку переправляют в что-то более осмысленное - вроде отсутствует дом в ФИАС, отсутствует помещение, отсутствует прибор учета и т.д. в зависимости от ситуации. Не обязательно он отсутствует в ГИС, может отсутствовать в шаблоне.
Специфично к шаблону о капитальном ремонте точно не скажу, нужно "методом тыка" проверить заполнено ли все что положено в шаблоне, допустим совпадают ли коды на одном листе шаблона и на другом. Потом проверить все ли в порядке с этими строками в ГИС (решение о капремонте, ЛС КР, их даты и т.д.) |
01.03.2018 12:12:03
Вот про это много раз говорит [B]Andrey_S[/B]: работаете с банками (чтобы вносили все реквизиты); размещаете на бумажной квитанции QR-код со всеми необходимыми реквизитами начисления (для этого есть разные сочетания реквизитов, в самом жестком/идеальном случае когда заполняете всё, Вы должны разместить ПД в ГИС, получить идентификатор начисления и воткнуть его в код); размещаете в ГИС раньше печатных квитанций; работаете с потребителями (чтобы "пропикивали" по коду, а не платили скопом за месяцы и не вводили реквизиты вручную с произвольной суммой).
И, может быть, доведете процент автоквитирования до 90-95%. На оставшиеся 5% придется находить время. |
01.03.2018 11:53:59
Если месяц указан и предыдущий, то в принципе вручную переквитировать можно. А вот "авансовый платеж" еще и не гасился до кучи, допустим, в кабинете УК сквитировали его нормально разницы с ожидаемой суммой нет, а у гражданина дважды считало платеж и как сквитированный и как авансовый.
|
01.03.2018 11:38:26
В смысле вдруг в 1С добавили, а в ГИС нет или наоборот. Или даже не сами. Например, зафигачил кто-то из коллег в 1С что-то по услугам или при обновлении конфигурации 1С что-то "вылезло". Все же синхронизация между ГИС и 1С не в реальном времени и не на 100%, а шаблонами.
|
01.03.2018 11:12:02
[quote:34ahmbfn]Суммарное количество автоматизированных рабочих мест: 19510[/quote:34ahmbfn]Ссылку еще не читал, но как-то даже не верится, что столько мест реально можно подключить к одной БД. Наверно тут какой-то подвох - или баз несколько у разных подразделений предприятия (зарплата и кадры та же) или как у нас (к базе по муниципальному имуществу, не к 1С), подключено 20 мест, пользуются чаще чем раз в полгода на трех местах.
Хотя конечно если у "мирового лидера" кластер высокопроизводительных серверов баз данных (ага, по серверу на каждую таблицу) и кластер высокопроизводительных серверов 1С (логика), кластер серверов с Апачами, пользователи работают в 1С через браузер (типа тонкий клиент) на навороченных рабочих местах и конфигурация вылизана до мелочей и миллисекунд, то может быть и заработает почти 20 тысяч мест. Хотя у нас - через терминал на одном сервере 5 бухгалтеров, 5 баз по 2 конфигурации, 16 Гб оперативки - все жестко тупит если серверную часть 1с и БД не перезагружать 3-4 дня. Ну, я конкретно конфигурацией не занимаюсь за это отдельный человечек деньги получает, он перегружает вообще весь сервак, не только 1с и бд. Если не ошибаюсь, имеет тот самый сертификат 1С:Эксперт. [quote:34ahmbfn]И курс по ссылке - не про экстенсивный подход, в нем как раз больше всего посвящено анализу программного кода на предмет производительности и раскрыта тесная связь этого со стратегиями выполнения запросов, заложенными на уровне СУБД.[/quote:34ahmbfn]Не стану спорить, потому что данный курс я не изучал. Лично мое мнение - пример не иллюстрирует ситуацию с ГИС. Хотя внятно обосновать так сразу не могу. [quote:34ahmbfn]В Ланите хорошо знают про требования к производительности ГИС ЖКХ, это одно из направлений работы над системой - есть записи семинаров о ГИС ЖКХ, где на вопросы об этом отвечал руководитель команды разработчиков Ланита А. Морлок. При всех справедливых нареканиях к качеству работы ГИС ЖКХ (как программно-аппаратного комплекса) - он не производит впечатление идиота.[/quote:34ahmbfn]Хорошо, не будем считать руководителя команды разработчиков идиотом. Легко соглашусь, что он даже гений. Однако: 1) он один не сможет написать/проконтролировать абсолютно ВСЕ, просто потому что система огромная; 2) как тут выяснили на днях, за веб-интерфейс отвечает совсем другая команда (и другая техподдержка) нежели за интеграцию с ИС. Не удивлюсь, если Морлок вообще из третьей команды или объединяет руководством несколько команд; 3) самому писать программу и руководить - абсолютно разные виды деятельности; 4) это ничего не говорит об уровне тех, кто у него в подчинении;5) как я уже приводил сравнение выше - есть разные подходы и я серьезно буду удивлен если разработчики занимаются настройкой пулов БД и планов выполнения запросов.[quote:34ahmbfn]Я вот о чем: не нужно считать, что мы, по сути не имея понятия, в чем заключаются причины неадекватной обработки очередей в ГИС ЖКХ, разбираемся в этом лучше.[/quote:34ahmbfn]Кстати, общепринято за рубежом давать алгоритмы различным экспертам на анализ ошибок и эффективности, а отечественные проекты как там руководитель разработчиков придумает, так и работают (хотя разработчики криптоалгоритмов приятное исключение). Вообще конечно да, не стоит судить книжку по обложке. Мне вот кажется, что в ГИС фундаментальный недостаток именно в том, что они останавливают все дважды в неделю на технические работы. Ну я понимаю, при обновлении ФИАС возможны блокировки, несогласования и т.д. Но что мешает ввести 4 сервера с теми же данными ФИАС? Один работает, второй его резервная копия, третий обновляется в фоне. При успехе со третьего делается копия на четвертый. Потом рабочим становится третий, с него делаются копии на первый для следующей "итерации". Сложная схема? Сложно предусмотреть смену сервера БД "на лету"? Вроде бы для такого кластеры серверов и делают - у кластера общий IP. Даже если не "на лету", то вполне элементарно ввести другой сервер на тот же адрес или изменить соответствие имени сервера и IP-адреса за пару минут. Код при этом не меняется, а persistent соединения восстановятся за минуту. нет никакой необходимости останавливать ВСЕ на несколько часов при правильном проектировании системы и достаточном количестве серверов. А дальше смотрите что за собой тянет остановка - 1) по статистике Яндекса при старте сервер с вероятностью 5% вообще не стартует, тупо не проходит автоматический контроль запуска; 2) запросы которые должны были обработаться за ночь увеличивают очередь (помните ту выкладку что пиковая мощность должна быть в 2 раза больше среднесуточной, если сделать по среднесуточной, то запросы как раз ночью дорабатываются полностью); 3) если резко меняется версия шаблонов/запросов интеграции, то необработанное уже не соответствует новой версии. Вывод: переход на новую версию серверов-обработчиков должен быть постепенным и управляемым с серверов-диспетчеров, если же переход резкий, да еще и после останова, то начинаются "чудеса" с очередью. Если они разбираются в этом лучше почему еще нет видимого результата? От того, что они разбираются, поставщикам информации лучше не становится. Все же деньги в проект вбуханы немалые и времени тоже было не так чтобы совсем в обрез. Ведь это поставщики подстраиваются под нововведения в ГИС, а не наоборот. Кстати, тут Вы сами себе противоречите: сначала говорили, что без реального потока данных разработчики не могли оптимизировать нагрузку, сейчас что "разработчики хорошо знаю требования к производительности". Знают только то, что видят и могут измерить? [quote:34ahmbfn]Такое ощущение, что ГИС разгребает свою очередь в обратном порядке. И файл либо обрабатывается быстро, если повезёт, либо "тонет" в очереди, и шансы на то, что до него дойдёт дело, становятся всё меньше и меньше. Зато можно бодро рапортовать, что "50% запросов обрабатываются в течение двух часов" при том, что остальные 50% не обрабатываются вообще.[/quote:34ahmbfn]Согласен с таким предположением. |
01.03.2018 04:51:04
Так как у Вас выгрузка с 1С, то я бы еще уточнил пункт 1:
1. кроме того, что проверяете все ли услуги есть в шаблоне полученном из 1С, также сверяете перечень услуг в шаблоне выгруженном с ГИС и в шаблоне полученном из 1С. |
01.03.2018 04:43:02
[QUOTE]Юлия Т. пишет:
Подскажите, если человек оплатил раньше, чем выложили ПД в ГИС, то при загрузке ПД автоматом все равно сквитируется или останется висеть в несквитированных?[/QUOTE]Сейчас точно не проверял, немного ранее было так: оплата поступившая раньше чем выставлен в ГИС ПД становилась "авансовым платежом" и не квитировалась при выставлении ПД. Сомневаюсь что исправили. |
27.02.2018 14:42:47
[QUOTE]Andrey_S пишет:
[QUOTE]two_oceans пишет: Собственно, для этого достаточно прочитать пару книжек по теории алгоритмов[/QUOTE]Вот не думаю, что "прочитать пару книжек" для разрешения такой задачи достаточно. Вопросы производительности в информационных системах - одни из самых сложных, в силу многофакторности.[/QUOTE]Ну не надо искажать, кроме книжек там было и про статистику достаточно много. В том числе статистику текущего состояния системы. Книжек достаточно для отбраковки заведомо требовательного к ресурсам алгоритма. Оптимальная реализация алгоритма в программе и моделирование/прогнозирование потребует больше практических и статистических знаний. По ссылке: во-первых, об 1С, где они говорят, что "сделать 1с на 200-500 сотрудников это круто!" С ГИС ЖКХ работает на 2-3 порядка пользователей больше, так что пример наверно не очень к месту. Во-вторых, там огромная углубленность в вопрос о базах данных и запросах. Написание запросов и понятие блокировки это тоже "пара книжек" на этот раз по теории СУБД. В-третьих, про технические настройки БД. Собственно с появлением SSD всю часть про кэшированием данных в памяти можно списывать в утиль. Потому что оперативная память сейчас также дает неслабое ожидание в тактах современных процессоров и SSD по скорости наступают оперативке на пятки. К слову, про оперативную память для самой программы, там часто бывает важнее правильно подобрать сочетание частот памяти и процессора, чем оптимизировать другие параметры (есть случаи когда более быстрая память и более быстрый процессор работают в связки медленнее из-за маленького несоответствия по временам такта и соответственно большего ожидания по числу тактов). Это уровень системного администратора, экстенсивный подход "давайте выжмем из этой консервной банки все что можно" (на оптимизацию платформы) чтобы дать программе больше ресурсов, а я про интенсивный подход на уровне программиста - "давайте оптимизируем программу чтобы они летала даже на этой консервной банке" (на оптимизацию приложения работающего на платформе) чтобы сама программа потребляла по минимуму. Скажете нет разницы? Разница в том, что если у дроби (скорость) увеличить числитель (производительность платформы) на 1%, то эффект на частное будет меньше чем при уменьшении знаменателя (требовательности к ресурсам программы) на 1%. сравните, 100/100=1 без изменения, 101/100=1,01 при первом подходе и 100/99=1,01(01) при втором подходе. Конечно, в идеале нужно использовать оба подхода. Не нужно быть гением, чтобы понять, что в ГИС в долговременном ключе будет больше всего информации про ПД и платежи и естественно их алгоритм нужно вылизать до мельчайших подробностей. Потому что это будет работать лучше чем закупить 100500 серверов с неэффективным алгоритмом. |
27.02.2018 06:59:57
Судя по нашим областным министерствам, туда пока не позвонишь, они даже почту полдня не смотрят, не то что заявку отправленную где-то в недрах гис жкх. Может они и знать не знают где эти заявки лежат. Так что наверно не ждите, а просто спокойно позвоните и узнайте видели ли они заявку, кто за заявки отвечает и примерные сроки.
|
27.02.2018 06:47:25
[QUOTE]Шла_мимо пишет:
У нашего бывшего сисадмина на работу с данными ГИСа был нанят его одногруппник по...колледжу)))[/QUOTE] Ну вот, а я как бы надеюсь в Ланите не выпускники горного колледжа. Я наивный? [SIZE=85px][COLOR=greenpt]Отправлено спустя 1 минуту 36 секунды:[/COLOR][/SIZE] Что и сисадмина уволили? |
27.02.2018 06:41:50
[QUOTE]Rizer пишет:
Внесены дома, при попытке внести лицевые счета через шаблон, возникает такая ошибка.Причем по любому дому.Код ФИАС проверен. [B]INT002000 Значение в поле Глобальный уникальный идентификатор дома по ФИАС/Идентификационный код дома в ГИС ЖКХ/Номер помещения/блока отсутствует в реестре.[/B] [/QUOTE]Доброго времени! Немного неясный вопрос, так что кучу уточняющих задам: 1) где внесены - в ГИС ЖКХ? а в лицензии есть, срок договора не закончился? Какой тип организации УК/РСО/ТСЖ? 2) вносили Вы или до Вас дома еще были? 3) подъезды/блоки/квартиры, указанные в шаблоне, внесены в дом? 4) код ФИАС проверяли на сайте ФИАС или по самому ГИС ЖКХ? Есть немало случаев когда код в ФИАС есть, но аннулирован. Или кто-то поспешил и внес в ГИС дом как "временный адрес" - из-за этого код в ФИАС не совпадает с кодом в ГИС, это можно узнать в самой ГИС (в открытой части либо сервис на главной странице либо файл с временными адресами в информации). Если дом в файле, то есть еще и дата обновления дома. Ждать придется если дом в фиас опубликован недавно(внесен или, например, был аннулирован и актуализирован), дату изменения в фиас можно посмотреть на сайте фиас. ГИС обновляет данные из ФИАС не так часто, об этом пишут в уведомлении о технических работах. Вроде бы в конце января или начале февраля было полное обновление по ФИАС. Если изменения в фиас раньше этого, но дом не обновлен, то однозначно надо техподдержку пытать. С приложением скриншотов с датами. 5) часто очень помогает с прояснение ошибок в шаблоне приложить к вопросу на форуме Ваш обработанный шаблон. Может быть Вы где-то лишний пробел в коде скопировали с сайта фиас и из-за пробела не идет шаблон. Можем хоть что тут гадать и проверять, выкладывать правильные шаблон, но пробел так не обнаружится. |
27.02.2018 06:03:48
Да, реально похоже на LIFO. В принципе, даже не должно быть уничтожения "писем внизу", просто если письмо достаточно долго лежит и поток входящих больше чем успевает обработаться, то до писем внизу никогда не дойдет очередь.
Как я себе представляю по многопоточности, то, похоже дело в частых обновлениях ГИС ЖКХ, при которых приостанавливается обработка всего что было в очереди. После обновления понятно, что большинство предыдущих запросов уже не соответствуют формату, поэтому алгоритм оптимизации присваивает старым запросам низкий приоритет и обрабатывает вперед "свеженькие". Касательно того, что разработчики не могли протестировать алгоритм в реальных условиях соглашусь лишь частично: естественно они не могли на 100% знать точные потоки и их параметры. Однако, масштаб достаточно велик чтобы уже работал закон больших чисел из статистики. Есть ведь оценки сколько УК/ТСЖ/РСО зарегистрировано в стране, сколько домов, сколько квартир, сколько ЛС, сколько ПУ (да с той же реформы). Есть сведения самой ГИС сколько "сущностей" уже занесено и из какого региона. Соответственно, есть представление о соотношении между разными типами запросов и о времени суток когда они могут поступить. И можно создать на тестовом стенде тестовый поток запросов больше или равный производительности стенда (хотя маленький по абсолютной величине, если стенд маленький), по относительному составу достаточно приближенный к реальному. И масштабировать результат. Естественно, там будут колебания из-за того, что сведения нужно заносить по порядку, но это можно в некоторых пределах спрогнозировать и скомпенсировать. Не думаю, что эта мысль прям гениальная. Вы же помните как я ничего не знаю о их внутренней кухне, просто по численности населения в часовых поясах, практически на коленке, прикинул часы когда система менее загружена? И что пиковая мощность системы должна быть больше среднесуточной примерно в 2 раза? Они такого расчета сделать не могут? Их взяли на работу после средней школы или у них не было теории вероятности и математической статистики в ВУЗе? Допустим, они двоечники по статистике, но тогда они должны были хотя бы программирование хорошо изучить. И знать, что параметры самого алгоритма известны заранее и определяются в том числе теоретически без практических испытаний. Собственно, для этого достаточно прочитать пару книжек по теории алгоритмов. А практическая производительность уже может определиться с учетом оптимизаций, добавляемых средой разработки/компилятором. Полагаю, ни для кого не секрет, что если переписать программу на ассемблере, да еще и с учетом архитектуры конкретного процессора, то программа будет быстрее на 30-40%. И наоборот если не удачно использовать среду разработки, то операция может выполняться в 1000 раз дольше. Для случаев, когда поток вычислений небольшой (компьютеры сейчас очень производительные по сравнению с временами ДОС когда все надо было уложить в 640Кб оперативки), а с программой работает человек незнание теории и правда не слишком важно (все же человек не слишком обращает внимание на задержки менее полсекунды). Но блин при проектировании системы в которую сливают данные со всей страны важна каждая микросекунда, поэтому программисты, ее делающие, просто обязаны в совершенстве владеть теорией алгоритмов и точно знать как работают встроенные алгоритмы оптимизации в среде разработки, с которой они работают. Со знанием всего этого - распределение нагрузки уже не такая сложная задача. |
27.02.2018 05:10:13
[quote:15bv6m08]Завтра, 27 февраля, в 11:00 (мск) в конференц-зале состоится подведение итогов работы ГИС ЖКХ за 2017 год.
Они поделятся успехами и достижениями команды, а также обозначат вектор дальнейшего развития системы. Планируется также выступления разработчиков ГИС ЖКХ об успешных кейсах на проекте. даже трансляция будет[/quote:15bv6m08]Цитата из чата разработчиков интеграции. Ссылки на трансляцию пока не указано. |
26.02.2018 11:23:08
На Дельфи вроде бы все почти что "готовенькое" (ну, кроме правильного приведения к каноническому виду, я приведение сам запилил, хоть и не во всех деталях, но есть вроде вариант через libxml2.dll). Хотя конечно есть и куча нюансов: если делать через майкрософтовский криптопровайдер (криптопро или випнет) за основу нужно брать jwawincrypt вместо стандартного модуля crypt2 (в нем неверные определения типов в функциях), перепроверить что везде при вызове виндовских функций есть stdcall, а если на win64 собирать, то придется еще типы подправить потому что хендлы будут другой разрядности (но это уже попроще, в интерфейсе jwawincrypt, а не в каждой функции). Еще как выяснилось есть разница - в некоторых исходниках указано A:pchar в вызове функции Pointer(A), а надо @A (или наоборот - это от используемого модуля зависит). Кроме того, для подписания xml не подходят функции "высокоуровневые" CryptSignMessage, CryptVerifyMessage - они для cades (двоичной подписи), но есть "низкоуровневые" CryptCreateHash, CryptHashData, CryptSignHash, CryptVerifySignature, которым все равно подпись в xml или в двоичном файле, однако из них надо будет ее правильно составить. Еще подпись из криптопро надо перевернуть перед преобразованием в base64. А так все готовенькое :lol:
Кроме пути через майкрософтовский криптопровайдер, есть вариант через openssl (там тоже каконикализацию не завезли) либо надстройки над openssl вроде xmlsec (там сразу libxml2 прикручена и составляет xades-bes правильно, но придется помучаться со включением поддержки госта и специфичных сведений подписи гис жкх). Я на FreePascal с Дельфи адаптировал, правда 32-разрядный вариант. КриптоПро 4.0.9842 немного подвел - не возвращает правильную длину для полученных данных строк, а всю длину буфера строки (в котором как водится много мусора), решилось поиском #0 в строке и принудительным обрезанием до этого места. Там где в буфере не строка (например, сертификат в двоичном виде), к счастью, длина возвращается правильная. Стандартную подпись xades-bes получил, на СМЭВ проверил, что базовая подпись верная, но за добавочную инфу в подписи гис жкх не брался. Еще пока не идет поиск сертификата по назначению сертификата. А, проверка подписи ответа от самого гиса тоже пока не сходится, но это не у меня одного так, просто все забили на проверку подписи ответа. |
26.02.2018 11:05:21
Через поддержку наверно еще слабее. Хотя бы прочитают ланитовцы и будет чуть меньше "приложите скриншоты что не работает". Формально они прислушиваются к предложениям, но нет никакой гарантии, что сделают "прям счас", могут тоже написать, что реализацию Вашего предложения запланировали на версию 100500, которая может быть выйдет через год. А если сделают "прям счас", то могут через пару недель переиграть.
|
26.02.2018 09:54:07
Да, это не единое целое. Как бы "переданное в экспертноую группу" по идее должно туда попасть, но связки номеров не видно.
|
19.02.2018 05:36:40
Кто же их знает... предположение, может они хотят, чтобы уведомили ГЖИ через ГИС, а на остальное чихать хотели? Или поняли что речь о сроках обработки уведомлений через ГИС? Ищут среди уведомлений по ГИС, не находят отправной точки и спрашивают снова.
|
19.02.2018 05:24:29
Подозрение, что про такую идею нужно писать сразу в Ланит (у них вроде багтрекер есть [URL=https://helpdesk.dom.gosuslugi.ru/browse/HCSINTEGRS-5040]https://helpdesk.dom.gosuslugi.ru/brows ... TEGRS-5040[/URL] ,который работает мимо техподдержки и там можно голосовать за предложения). Правда мне что-то не хочется там регистрироваться.
[quote:z6xknwpl]Для регистрации в системе учета инцидентов(JIRA) Вам необходимо отправить на почтовый ящик [URL=mailto:integration.helpdesk@dom.gosuslugi.ru]integration.helpdesk@dom.gosuslugi.ru[/URL] в свободной форме информацию следующего содержания: Фамилия Имя Отчество Контактный телефон ОГРН Наименование организации[/quote:z6xknwpl]Это цитировали из сообщения которое приходило, когда ИС регистрируется для интеграции. |
19.02.2018 05:03:04
[QUOTE]Елена 34 пишет:
Подскажите люди добрые, жилец оплатил 9070 руб. через банк, а в ГИСе стоит сумма 907 000 руб., я понимаю что банк не правильно выгрузил сумму платежа. Нам что делать? Обращаться в банк или самим можно как то исправить это?[/QUOTE]Кхм, это банк просто по требованиям нормативки указал сумму в копейках, а на практике все шлют в рублях и ГИС понимает как рубли. Одна из возможных причин - ИС банка не различила ГИС ЖКХ и ГИС ГМП (в ГИС ГМП как раз требование про копейки). С этим могут быть проблемы, так как банк может стать в позу что не может изменять введенное клиентом. На всякий случай, советую еще проверить формирование QR-кода если у Вас в квитанции он есть - по ГОСТУ в QR-коде тоже указывается сумма в копейках, но на практике все пишут в рублях. Еще вариант о разных рублях-валютах, 810 и 643, но тогда бы была разница суммы в 1000 раз, а не в 100 раз. |
14.02.2018 13:29:55
Пожалуйста. Наверно еще кому-то будет полезно.[QUOTE]andreas_2017 пишет:
Но всё равно не совсем понятно. Есть квитанция для жильцов, в них реквизиты платежного агента для оплаты. Потом платёжный агент перечисляет денежные средства УО. У платёжного агента я не нашёл возможности в ГИС вводить ПД (и это в принципе объяснимо).[/QUOTE]Да, и поэтому же он не сможет их сквитировать. А УО, в свою очередь не увидит у себя платежи, отправленные не по реквизитам УО, а по реквизитам платежного агента. Заметьте, я писал что платежный агент грузит платежи (что люди заплатили), а не платежные документы (что Вы начислили). [QUOTE]andreas_2017 пишет: Получается для ввода ПД я должен в шаблоне импорта ПД заменить реквизиты платёжного агента на реквизиты УО ? Но ГИС предполагает оплату через систему и получится что ПД в ГИС будет иметь реквизиты УО, а реальный ПД - реквизиты платёжного агента ???[/QUOTE]Да, именно так. По хорошему и в реальном тоже надо указать собственные реквизиты УО, чтобы 1) не было разночтения; 2) видеть у себя в ГИС все платежи. По антимонопольному законодательству Вы не можете указать своим плательщикам платить через определенного платежного агента и только через него. Смысл в том, что если кто-то захочет заплатить через ГИС (на сайте, а в перспективе и в любом банке), то предполагается, что платежные реквизиты должны браться из ГИС (точную ссылку на нормативку так сразу не скажу). При разнице реквизитов в ГИС и в бумажной квитанции использовать предполагается указанные в ГИС. По задумке идеологов ГИС, это должно помочь бороться с поддельными бумажными квитанциями. Другой довод они приводят - если деньги поступят напрямую на счет исполнителя услуги, посредник (платежный агент) не сможет их у себя на счете "крутить". Доводы признаны Минстроем, так что шансы на то, что в ГИС это пересмотрят близки к нулю. Вам важно чтобы все платежи шли через платежного агента? Ну тогда наверно нужно, чтобы в ГИС платежный агент грузил все платежи, которые перечисляет Вам с Вашими реквизитами, даже если кто-то заплатил по квитанции с его реквизитами. [QUOTE]andreas_2017 пишет: Тут скорее косяк системы, который разработчики пока не разрешили.[/QUOTE]Идеологи ГИС не считают это косяком, считают плюсом ГИС, вот в чем фокус. dash2 |
Подпишись на рассылку новостей ЖКХ, а также наших статей!
Спасибо, вы успешно подписались на рассылку!