Форум

С такими условиями, мне уже захотелось послать им резюме на тестировщика)))) Только чую, что студенты меня быстро достанут и парой матов KPI уронится до нуля.

ГИС все время меняется, точно ответить сложно, тем более про порядок выборки документов ГИСом. Внутренних деталей нам не говорят, остается строить догадки методом тыка.

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

Порядок - по идее должен изначально выбираться ПД за тот период, который указан в оплате. Сейчас видимо приоритет сместился на текущий ПД (или скажем точнее - последний непогашенный, именно его показывает плательщику) и потому более вероятно, что из Вашего примера 10 рублей сквитируются с текущим, а 95 рублей повиснут для ручного квитирования с долговым. Однако, если период в оплате и период в долговом ПД совпадет, то возможно будет и наоборот - загасится полностью долговой ПД, а 5 рублей останутся для ручного квитирования.

[QUOTE]Елена 34 пишет:
Добрый день, при выгрузке оплаты из 1С вся оплата удваивается, не пойму почему. У кого нибудь было такое или может кто-то знает причину, подскажите пожалуйста.[/QUOTE]Удваивается при выгрузке из 1с в шаблон? Тогда это скорее к авторам конфигурации 1с вопрос.
Или удваивается при загрузке в ГИС выгруженного из 1с шаблона?

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

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

[QUOTE]Natulka93 пишет:
Согласна, но если человек переплатил хорошенько и просит перенести, то ведь нужно переносить.[/QUOTE]Они предусмотрели только перенос на другой период (убогим квитированием). Я конечно понимаю, что все переносят оплату... но есть какие-то положения из нормативки, которые это разрешают? А то может не только изменять начисления, но и переносить нельзя? И мы просто не такие "продвинутые в цитировании нормативки" как разработчики ГИС?

Если же положение нормативки есть, то надо наехать на разработчиков ГИС. Может сделают в версии 100.500.

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

Не совсем верно, а что делать... по-другому "официально" не перенести. Впрочем, я уже начитался в чате интеграции, что некая УК смогла внести квартиры с отрицательной площадью (и такие ЛС не экспортируются из ГИС)!! Полагаю, на них будет начисляться отрицательная плата.  :lol: А Вы говорите "не совсем верно"... ГИС отрицательные площади не смущают, наверняка и отрицательную плату можно как-то пропихнуть.

Идеальный вариант: работать с банком и приучать вносить нормальные цифры по услугам, а не как делают многие банки - сумма сходится, а по услугам раскидана как оператору банка пришло в голову. Абсолютно не обращают внимание, что есть долг за прошлые периоды по одной из услуг, а по другой переплата, автоматом ставят за отопление сумму ровно за один месяц, остальное художественно раскидывают. Лично меня бесит, что потом в личном кабинете но одной услуге переплата 80,02 руб., по другой долг 80,00 руб, в сумме переплата 2 копейки, но строка с долгом горит красным. И у нас летом невозможно погасить долг за горячую воду (текущей платы по горячей воде летом нет согласно решению местной Думы), сколько ни напишешь оператору банка, он все равно ставит 0 по горячей воде и раскидывает по другим услугам.

Да, заставить РЦ будет сложно. Основная проблема, что чтобы нормально пользоваться ГИС, РЦ должен интегрироваться по СОАП. Как я понимаю, нет загрузки шаблонов и форм ручного ввода в личном кабинете РЦ. Отвечу как все может быть, если РЦ идет Вам на встречу.

Во многом все зависит, хотите ли сделать единый платежный документ. Если нет, то заполняете ЛС сами и выставляете счета (ПД) сами, а РЦ только как платежный агент должен вносить принятые оплаты. То что Вы оформили их как платежного агента как раз дает возможность им вносить платежи, указывая в качестве получателя оплат Ваши реквизиты. Так делают большинство, однако единую платежку так сделать будет очень сложно.

В этом случае, есть возможность делегировать полномочия от УК к РЦ, чтобы РЦ смог выставлять ПД на ЛС, созданный Вами. Или создать ЛС УК/ЛС РСО от Вашего имени. Это может понадобится, если РЦ производит начисления. С другой стороны, заставить РЦ выставлять ПД нельзя, даже если РЦ делает начисления, так как есть законный вариант, при котором РЦ будет Вам отдавать заполненные шаблоны ПД, а Вы мучаться с загрузкой этих шаблонов.

Если же на повестке стоит единый платежный документ, то по идее РЦ [B][U]может[/U][/B] создать единый ЛС (типа ЛС РЦ) и указать в основаниях как все договоры ресурсоснабжения (допустимо несколько), так и договор управления или социального найма (только один, в дополнение к нескольким ресурсоснабжения; управления и социального найма, как я понял, взаимоисключающие). И соответственно прицепить на ЛС РЦ все услуги, указанные в этих нескольких договорах. В этом случае РЦ сможет выставлять на все это единый ПД. Не ясно пока, как именно в едином ПД должны указываться реквизиты нескольких организаций. Поэтому пока единые платежки РЦ пробуют выставить на реквизиты РЦ, что неправильно.

Еще раз подчеркну, для открытия лицевого счета с несколькими основаниями РЦ должен получить функцию РЦ и интегрироваться по СОАП.  В итоге, пока РЦ с опытом такого очень мало, а документация ГИС ЖКХ по интеграции сильно отстает (в частности, про договоры управления на ЛС РЦ не говорится, что многих ввело в заблуждение, но фактически ГИС принимает и договора управления при открытии ЛС РЦ).

[QUOTE]Programmer пишет:
Да простит меня two_oceans, но я считаю, что хитроумные ИД приборов учета там и на фиг не нужны. Можно без них обойтись.[/QUOTE]Легко прощу, я даже не помню уже когда про это говорил. Другим пока голова занята - выборы-с. Насчет ИД приборов учета, полагаю, я говорил (точно не помню), что они нужны внутри системы "чисто для порядка", и если кто-то при интеграции может обойтись без них, то я не буду на него обижаться. :lol: Вне системы это нужно лишь как опция, если кто не может без них интегрироваться.
Тем более, насчет хитроумности, чем проще тем лучше. К слову, лично для меня самым успешным примером идентификаторов являются mac-адреса сетевых плат. Сколько уж лет прошло, а адреса еще работают.

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

Специфично к шаблону о капитальном ремонте точно не скажу, нужно "методом тыка" проверить заполнено ли все что положено в шаблоне, допустим совпадают ли коды на одном листе шаблона и на другом. Потом проверить все ли в порядке с этими строками в ГИС (решение о капремонте, ЛС КР, их даты и т.д.)

Вот про это много раз говорит [B]Andrey_S[/B]: работаете с банками (чтобы вносили все реквизиты); размещаете на бумажной квитанции QR-код со всеми необходимыми реквизитами начисления (для этого есть разные сочетания реквизитов, в самом жестком/идеальном случае когда заполняете всё, Вы должны разместить ПД в ГИС, получить идентификатор начисления и воткнуть его в код); размещаете в ГИС раньше печатных квитанций; работаете с потребителями (чтобы "пропикивали" по коду, а не платили скопом за месяцы и не вводили реквизиты вручную с произвольной суммой).

И, может быть, доведете процент автоквитирования до 90-95%. На оставшиеся 5% придется находить время.

[QUOTE]Форест пишет:
Есесно там не идет речь о непосредственной одновременной работе 20к пользователей с одной базой. Это просто официальные цифры с официального источника.[/QUOTE]Мне полегчало. :idea:

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

В смысле вдруг в 1С добавили, а в ГИС нет или наоборот. Или даже не сами. Например, зафигачил кто-то из коллег в 1С что-то по услугам или при обновлении конфигурации 1С что-то "вылезло". Все же синхронизация между ГИС и 1С не в реальном времени и не на 100%, а шаблонами.

[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]Согласен с таким предположением.

Так как у Вас выгрузка с 1С, то я бы еще уточнил пункт 1:
1. кроме того, что проверяете все ли услуги есть в шаблоне полученном из 1С, также сверяете перечень услуг в шаблоне выгруженном с ГИС и в шаблоне полученном из 1С.

[QUOTE]Юлия Т. пишет:
Подскажите, если человек оплатил раньше, чем выложили ПД в ГИС, то при загрузке ПД автоматом все равно сквитируется или останется висеть в несквитированных?[/QUOTE]Сейчас точно не проверял, немного ранее было так: оплата поступившая раньше чем выставлен в ГИС ПД становилась "авансовым платежом" и не квитировалась при выставлении ПД. Сомневаюсь что исправили.

[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 серверов с неэффективным алгоритмом.

Судя по нашим областным министерствам, туда пока не позвонишь, они даже почту полдня не смотрят, не то что заявку отправленную где-то в недрах гис жкх. Может они и знать не знают где эти заявки лежат. Так что наверно не ждите, а просто спокойно позвоните и узнайте видели ли они заявку, кто за заявки отвечает и примерные сроки.

[QUOTE]Шла_мимо пишет:
У нашего бывшего сисадмина на работу с данными ГИСа был нанят его одногруппник по...колледжу)))[/QUOTE]
Ну вот, а я как бы надеюсь в Ланите не выпускники горного колледжа. Я наивный?

[SIZE=85px][COLOR=greenpt]Отправлено спустя 1 минуту 36 секунды:[/COLOR][/SIZE]
Что и сисадмина уволили?

[QUOTE]Rizer пишет:
Внесены дома, при попытке внести лицевые счета через шаблон, возникает такая ошибка.Причем по любому дому.Код ФИАС проверен.
[B]INT002000 Значение в поле Глобальный уникальный идентификатор дома по ФИАС/Идентификационный код дома в ГИС ЖКХ/Номер помещения/блока отсутствует в реестре.[/B] [/QUOTE]Доброго времени! Немного неясный вопрос, так что кучу уточняющих задам:
1) где внесены - в ГИС ЖКХ? а в лицензии есть, срок договора не закончился? Какой тип организации УК/РСО/ТСЖ?
2) вносили Вы или до Вас дома еще были?
3) подъезды/блоки/квартиры, указанные в шаблоне, внесены в дом?
4) код ФИАС проверяли на сайте ФИАС или по самому ГИС ЖКХ? Есть немало случаев когда код в ФИАС есть, но аннулирован. Или кто-то поспешил и внес в ГИС дом как "временный адрес" - из-за этого код в ФИАС не совпадает с кодом в ГИС, это можно узнать в самой ГИС (в открытой части либо сервис на главной странице либо файл с временными адресами в информации). Если дом в файле, то есть еще и дата обновления дома. Ждать придется если дом в фиас опубликован недавно(внесен или, например, был аннулирован и актуализирован), дату изменения в фиас можно посмотреть на сайте фиас. ГИС обновляет данные из ФИАС не так часто, об этом пишут в уведомлении о технических работах. Вроде бы в конце января или начале февраля было полное обновление по ФИАС. Если изменения в фиас раньше этого, но дом не обновлен, то однозначно надо техподдержку пытать. С приложением скриншотов с датами.
5) часто очень помогает с прояснение ошибок в шаблоне приложить к вопросу на форуме Ваш обработанный шаблон. Может быть Вы где-то лишний пробел в коде скопировали с сайта фиас и из-за пробела не идет шаблон. Можем хоть что тут гадать и проверять, выкладывать правильные шаблон, но пробел так не обнаружится.

Да, реально похоже на LIFO. В принципе, даже не должно быть уничтожения "писем внизу", просто если письмо достаточно долго лежит и поток входящих больше чем успевает обработаться, то до писем внизу никогда не дойдет очередь.

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

Касательно того, что разработчики не могли протестировать алгоритм в реальных условиях соглашусь лишь частично: естественно они не могли на 100% знать точные потоки и их параметры. Однако, масштаб достаточно велик чтобы уже работал закон больших чисел из статистики. Есть ведь оценки сколько УК/ТСЖ/РСО зарегистрировано в стране, сколько домов, сколько квартир, сколько ЛС, сколько ПУ (да с той же реформы). Есть сведения самой ГИС сколько "сущностей" уже занесено и из какого региона. Соответственно, есть представление о соотношении между разными типами запросов и о времени суток когда они могут поступить. И можно создать на тестовом стенде тестовый поток запросов больше или равный производительности стенда (хотя маленький по абсолютной величине, если стенд маленький), по относительному составу достаточно приближенный к реальному. И масштабировать результат. Естественно, там будут колебания из-за того, что сведения нужно заносить по порядку, но это можно в некоторых пределах спрогнозировать и скомпенсировать.

Не думаю, что эта мысль прям гениальная. Вы же помните как я ничего не знаю о их внутренней кухне, просто по численности населения в часовых поясах, практически на коленке, прикинул часы когда система менее загружена? И что пиковая мощность системы должна быть больше среднесуточной примерно в 2 раза? Они такого расчета сделать не могут? Их взяли на работу после средней школы или у них не было теории вероятности и математической статистики в ВУЗе?

Допустим, они двоечники по статистике, но тогда они должны были хотя бы программирование хорошо изучить. И знать, что параметры самого алгоритма известны заранее и определяются в том числе теоретически без практических испытаний. Собственно, для этого достаточно прочитать пару книжек по теории алгоритмов. А практическая производительность уже может определиться с учетом оптимизаций, добавляемых средой разработки/компилятором. Полагаю, ни для кого не секрет, что если переписать программу на ассемблере, да еще и с учетом архитектуры конкретного процессора, то программа будет быстрее на 30-40%. И наоборот если не удачно использовать среду разработки, то операция может выполняться в 1000 раз дольше.

Для случаев, когда поток вычислений небольшой (компьютеры сейчас очень производительные по сравнению с временами ДОС когда все надо было уложить в 640Кб оперативки), а с программой работает человек незнание теории и правда не слишком важно (все же человек не слишком обращает внимание на задержки менее полсекунды). Но блин при проектировании системы в которую сливают данные со всей страны важна каждая микросекунда, поэтому программисты, ее делающие, просто обязаны в совершенстве владеть теорией алгоритмов и точно знать как работают встроенные алгоритмы оптимизации в среде разработки, с которой они работают.

Со знанием всего этого - распределение нагрузки уже не такая сложная задача.

[quote:15bv6m08]Завтра, 27 февраля, в 11:00 (мск) в конференц-зале состоится подведение итогов работы ГИС ЖКХ за 2017 год.
Они поделятся успехами и достижениями команды, а также обозначат вектор дальнейшего развития системы.
Планируется также выступления разработчиков ГИС ЖКХ об успешных кейсах на проекте.
даже трансляция будет[/quote:15bv6m08]Цитата из чата разработчиков интеграции. Ссылки на трансляцию пока не указано.

На Дельфи вроде бы все почти что "готовенькое" (ну, кроме правильного приведения к каноническому виду, я приведение сам запилил, хоть и не во всех деталях, но есть вроде вариант через 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 получил, на СМЭВ проверил, что базовая подпись верная, но за добавочную инфу  в подписи гис жкх не брался. Еще пока не идет поиск сертификата по назначению сертификата.
А, проверка подписи ответа от самого гиса тоже пока не сходится, но это не у меня одного так, просто все забили на проверку подписи ответа.

Через поддержку наверно еще слабее. Хотя бы прочитают ланитовцы и будет чуть меньше "приложите скриншоты что не работает". Формально они прислушиваются к предложениям, но нет никакой гарантии, что сделают "прям счас", могут тоже написать, что реализацию Вашего предложения запланировали на версию 100500, которая может быть выйдет через год. А если сделают "прям счас", то могут через пару недель переиграть.

Да, это не единое целое. Как бы "переданное в экспертноую группу" по идее должно туда попасть, но связки номеров не видно.

Кто же их знает... предположение, может они хотят, чтобы уведомили ГЖИ через ГИС, а на остальное чихать хотели? Или поняли что речь о сроках обработки уведомлений через ГИС? Ищут среди уведомлений по ГИС, не находят отправной точки и спрашивают снова.

Подозрение, что про такую идею нужно писать сразу в Ланит (у них вроде багтрекер есть [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] в свободной форме информацию следующего содержания: Фамилия Имя Отчество
E-mail
Контактный телефон
ОГРН
Наименование организации[/quote:z6xknwpl]Это цитировали из сообщения которое приходило, когда ИС регистрируется для интеграции.

[QUOTE]Елена 34 пишет:
Подскажите люди добрые, жилец оплатил 9070 руб. через банк, а в ГИСе стоит сумма 907 000 руб., я понимаю что банк не правильно выгрузил сумму платежа. Нам что делать? Обращаться в банк или самим можно как то исправить это?[/QUOTE]Кхм, это банк просто по требованиям нормативки указал сумму в копейках, а на практике все шлют в рублях и ГИС понимает как рубли. Одна из возможных причин - ИС банка не различила ГИС ЖКХ и ГИС ГМП (в ГИС ГМП как раз требование про копейки). С этим могут быть проблемы, так как банк может стать в позу что не может изменять введенное клиентом. На всякий случай, советую еще проверить формирование QR-кода если у Вас в квитанции он есть - по ГОСТУ в QR-коде тоже указывается сумма в копейках, но на практике все пишут в рублях. Еще вариант о разных рублях-валютах, 810 и 643, но тогда бы была разница суммы в 1000 раз, а не в 100 раз.

Пожалуйста. Наверно еще кому-то будет полезно.[QUOTE]andreas_2017 пишет:
Но всё равно не совсем понятно. Есть квитанция для жильцов, в них реквизиты платежного агента для оплаты. Потом платёжный агент перечисляет денежные средства УО. У платёжного агента я не нашёл возможности в ГИС вводить ПД (и это в принципе объяснимо).[/QUOTE]Да, и поэтому же он не сможет их сквитировать. А УО, в свою очередь не увидит у себя платежи, отправленные не по реквизитам УО, а по реквизитам платежного агента. Заметьте, я писал что платежный агент грузит платежи (что люди заплатили), а не платежные документы (что Вы начислили).
[QUOTE]andreas_2017 пишет:
Получается для ввода ПД я должен в шаблоне импорта ПД заменить реквизиты платёжного агента на реквизиты УО ? Но ГИС предполагает оплату через систему и получится что ПД в ГИС будет иметь реквизиты УО, а реальный ПД - реквизиты платёжного агента ???[/QUOTE]Да, именно так. По хорошему и в реальном тоже надо указать собственные реквизиты УО, чтобы 1) не было разночтения; 2) видеть у себя в ГИС все платежи. По антимонопольному законодательству Вы не можете указать своим плательщикам платить через определенного платежного агента и только через него. Смысл в том, что если кто-то захочет заплатить через ГИС (на сайте, а в перспективе и в любом банке), то предполагается, что платежные реквизиты должны браться из ГИС (точную ссылку на нормативку так сразу не скажу). При разнице реквизитов в ГИС и в бумажной квитанции использовать предполагается указанные в ГИС. По задумке идеологов ГИС, это должно помочь бороться с поддельными бумажными квитанциями. Другой довод они приводят - если деньги поступят напрямую на счет исполнителя услуги, посредник (платежный агент) не сможет их у себя на счете "крутить". Доводы признаны Минстроем, так что шансы на то, что в ГИС это пересмотрят близки к нулю. Вам важно чтобы все платежи шли через платежного агента?
Ну тогда наверно нужно, чтобы в ГИС платежный агент грузил все платежи, которые перечисляет Вам с Вашими реквизитами, даже если кто-то заплатил по квитанции с его реквизитами.
[QUOTE]andreas_2017 пишет:
Тут скорее косяк системы, который разработчики пока не разрешили.[/QUOTE]Идеологи ГИС не считают это косяком, считают плюсом ГИС, вот в чем фокус. dash2