Форум

[QUOTE]AlcorVol пишет:
[QUOTE]two_oceans пишет:
Ещё подумал - а ведь если интерфейс похожий, то надо при изменении ЛК менять программу, это однако похуже шаблонов будет.[/QUOTE]
Не совсем понял. Я имел в виду самостоятельное интерактивное приложение, интерфейс которого (GUI) по стилю напоминает стиль работы юзера в ЛК. А если будут меняться сами форматы структуры данных (как сейчас шаблоны меняются), то это, конечно, в  программе клиента (УО), осуществляющей подготовку XML-файлов, учитывать придётся.[/QUOTE]
А я не про форматы, а про то, что они и сайт частенько меняют - перетаскивают форму с одного раздела на другой без всякого предупреждения. То есть периодически придется синхронизировать вид приложения с текущим видом сайта.
[quote:3nv6tnms]Успехов! А я пока продолжу с XLSX-шаблонами ковыряться. Пора бы отложить в сторону писанину на форуме, а заняться делом. :)[/quote:3nv6tnms]Как раз о том же подумал, да и другой работки подкинули. Поэтому сокращаю время на форуме и ищу наметки в Интернете. Вот что вчера нашел:
[url:3nv6tnms]http://www.clevercomponents.com/articles/article022/soapsecurity.asp[/url:3nv6tnms] Пример на Дельфи как подписывать XML, на ГОСТ нужно изменить пару деталей и так как функция подписания по ГОСТу уже найдена, я уже знаю каких деталей. С приведением к каноничному - мрак (самодельные примеры не учитывают всех вывертов стандарта, если будет XML без вывертов, то сработают, но есть предчувствие что это не сработает в самый неподходящий момент). С кодировкой base64 виду чуть лучше - она везде есть, но исходник пока не нашел. Ничего, найду, где-то он мне уже встречался.
[url:3nv6tnms]http://forum.foxclub.ru/read.php?29,562055[/url:3nv6tnms] "Возможна ли каноникализация XML средствами VFP". Специально для пилящих SOAP на VFP. Кроме каноникализации там еще и декларации функций майкрософтовского криптопровайдера - как получить хэш и подпись и чего с ними потом делать.
[quote:3nv6tnms]Коллеги, чем предложения разработчикам ГИС об изменениях будут дальше от существующих схем, тем меньше вероятность того, что их хотя бы прочитают.[/quote:3nv6tnms]Согласен, но с другой стороны сколько можно ждать "милости от природы", поэтому наиболее далекие от существующих схем предлагаю сделать совместными усилиями - я вот практически решился написать DLL для подписи XML. Тема достаточно интересная в плане множества других применений XML. Ранее думал, что моего кунг-фу не хватит, но оказалось программисты ФГИС это не придумали, есть международный стандарт - сразу стало легче. Остается вопрос реализовать подписание как в ГИС ЖКХ и остановиться или реализовать формат полностью. В частности, сертификат, можно указывать многими способами. О полном формате нашел вводную статью: [url:3nv6tnms]http://minichden.narod.ru/articles/xmldsig.htm[/url:3nv6tnms].
По этому вопросу - мне нужно будет как-то проверить результат. Пилить в C# только ради проверки нет никакого смысла. Может быть, если у кого есть рабочая схема подписи, я предоставлю "самодельные" тестовые сертификаты и вы ими подпишите несколько файлов?
[quote:3nv6tnms]Поскольку xlsx это «усложнённый» xml, то (навскидку) дополнительной работы для его обработки должно быть немного.[/quote:3nv6tnms]Обоснование понятно. Однако, как мне кажется это может иметь обратный эффект: SOAP, это то же XML, так что с ним программисты ГИС уже "наигрались" и реализовывать еще что-то промежуточное между SOAP и XLSX будет слишком похоже, при дополнительной необходимости отражать изменения на еще один формат, и потому не так уж привлекательно. Однако даже если сделают возможность грузить SOAP через ЛК без кучи регистраций в качестве ИС и тестирований, тоже будет достаточно забавно.
[quote:3nv6tnms]Да, практически все более менее умеют работать в Excel. Но Excel умеет открывать и сохранять xml, csv, ods и с натяжкой dbf. [/quote:3nv6tnms]Вот честно говоря, насчет xml не уверен, с таким же успехом html можно дополнить в список. Сам формат Эксель конечно умеет открывать и сохранять, но при этом при создании/сохранении файла в Экселе в тегах столько специфичного для Экселя "мусора" - всяческие стили офисного пакета, форматы, формулы и т.д. - что ни одна уважающая себя система не будет этот хлам обрабатывать без дополнительного "очищающего" конвертера. Из-за такого "мусора" в тегах я даже FrontPage давно перестал использовать для редактирования веб-страниц.

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

[QUOTE]AlcorVol пишет:
[quote:ea5i84pf]Конечно, можно сделать и интерактивный вариант (то есть вместо автоматического приема XML производить какие-то действия вручную в пользовательском интерфейсе, но тогда придется обучать пользователей).[/QUOTE]
Ну, будет не сложнее, чем научить работать в ЛК. Особенно, если интерфейс похожим сделать.[/quote:ea5i84pf]Ещё подумал - а ведь если интерфейс похожий, то надо при изменении ЛК менять программу, это однако похуже шаблонов будет. dash2 Утром мелькнула идея попробовать для проверки сделать "резидентный монитор" на VBScript + XmlSigned класс, а для интерфейса добавить нечто среднее между нормальной программой и веб-штучками - HTA. Либо сосредоточится на Криптопро + stunnel + DLL (Delphi/Pascal) подписания и отправки + DLL для отчетов (отдельно, чтобы проще заменять, может быть тоже нужно разбить - включая обновление, анализ новой версии, формирование и проверку шаблона), пока без технологии "общей". Конечно, к этому накрутятся всякие конфигурации. Это то, в чем можно получить какие-то результаты в обозримом будущем.

[QUOTE]AlcorVol пишет:
Но на практике - не всё так гладко. Жители большинства МКД в Вологде сейчас платят Водоканалу и Теплосети напрямую, минуя УК. На что имеют, кстати, полное право по законодательству: см. ст.155 ЖК РФ, "прямые расчёты". И заметим, что к "прямому управлению" это никакого отношения не имеет! Просто дом так решил: будем платить РСО напрямую. УК печатает, таким образом, два дополнительных отдельных ПД: для Водоканала и Теплосети, с соответствующими реквизитами получателей (и даже с QR-кодами).[/QUOTE]Маразм чистейший. В ЖК я не силен, но чисто по-человечески, считаю, [U][B]странно[/B][/U] что жители платят теплосети и водоканалу за услугу которую, те [B][U]не оказывают[/U][/B]. Какие прямые платежи, если услуга не оказывается? Решал бы так: Объявил УО как поставщика горячей воды, напечатал третью платежку на УО, а из платежек водоканала и теплосети убрал связанные услуги. Та же теплосеть при отоплении берет за гигакалории, но не за воду(теплоноситель наверняка утекает)! За теплоноситель она сама с водоканалом договаривается и восполняет потери. По аналогии и УО должна сама договориться с поставщиками - что требуется для "приготовления горячей воды", в конце концов какую-то амортизацию бойлеров учесть, УО виднее что еще.
Если просто так сделать не получится, то наверно можно принять какой-то нормативный акт городского уровня и им отмахиваться от недовольных.

[QUOTE]portal-gkh пишет:
XSD - простым языком - описание структуры XML -файла. Имея XSD,  можно создать корректный XML-файл (или формально проверить корректность существующего). Их много, потому, что в ГИС (я правильно понимаю, что речь про нее идет) используется много видов XML-файлов.[/QUOTE]Спасибо. Теперь бы еще найти "как", в смысле не задействуя Java и .Net :)
[QUOTE]portal-gkh пишет:
Пожалуйста (без блока с ЭЦП)[/QUOTE]Спасибо, если обрамить как код будет еще замечательнее. И это как я понимаю не результирующий XML, а с кодом на Java, вставляющим дату и guid. На хабре ([URL=https://habrahabr.ru/post/300856/]https://habrahabr.ru/post/300856/[/URL]) есть обобщенный вид блока подписи, действия как получить значения для него тоже подробно расписаны. Правда смущает, что для старой версии ГИС. Может ли кто пояснить изменился ли вид блока подписи с тех пор? Вроде бы стандарт XAdES-BES международный, но вдруг? После беглого обзора осталось неясно, как (куда) вот это прилеплять к запросу. Предполагаю, сразу после закрытия конверта SOAP </soapenv:Envelope>?[code:1vrtpupk]<ds:Signature Id="xmldsig-{signature_id}" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411"/>
<ds:Reference Id="xmldsig-{signature_id}-ref0" URI="#{signed_id}">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr3411"/>
<ds:DigestValue>{digest1}</ds:DigestValue>
</ds:Reference>
<ds:Reference Type="http://uri.etsi.org/01903#SignedProperties" URI="#xmldsig-{signature_id}-signedprops">
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr3411"/>
<ds:DigestValue>{digest3}</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue Id="xmldsig-{signature_id}-sigvalue">
{signature_value}
</ds:SignatureValue>
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>
{x590_cert}
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
<ds:Object><xades:QualifyingProperties Target="#xmldsig-{signature_id}" xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" xmlns:xades141="http://uri.etsi.org/01903/v1.4.1#"><xades:SignedProperties Id="xmldsig-{signature_id}-signedprops"><xades:SignedSignatureProperties><xades:SigningTime>{signing_time}</xades:SigningTime><xades:SigningCertificate><xades:Cert><xades:CertDigest><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr3411"/><ds:DigestValue>{digest2}</ds:DigestValue></xades:CertDigest><xades:IssuerSerial><ds:X509IssuerName>{x509_issuer_name}</ds:X509IssuerName><ds:X509SerialNumber>{x509_sn}</ds:X509SerialNumber></xades:IssuerSerial></xades:Cert></xades:SigningCertificate></xades:SignedSignatureProperties></xades:SignedProperties></xades:QualifyingProperties></ds:Object>
</ds:Signature>[/code:1vrtpupk]В фигурных скобках подстановки, переводы строк важны, пробелов в конце строк нет, ds:Object без переводов строк - разрывает движок форума.
Насчет других языков нашел [URL=https://msdn.microsoft.com/en-us/library/system.security.cryptography.xml.signedxml.aspx?cs-save-lang=1&cs-lang=vb#code-snippet-1]SignedXml Class[/URL] от Майкрософт, но пока не разбирался подойдет ли к ГОСТу. Там С, С++, С#, VB. Если подойдет к ГОСТ и VBScript, то будет забавно написать "резидентный монитор" на VBScript - соединение там легко реализуется, работа с XML тоже должна быть.

.Net  Java популярные, потому что для них сами разработчики из КриптоПро выкладывали примерный код для работы со СМЭВ. Потом пример растащили и адаптировали под другие ФГИС. Оно понятно, чем с нуля на другом языке писать, многим проще "перестроится" и сочинять из готового примера.
Где-то находил код, как подписывать цифровой подписью на Дельфи, обращаясь к библиотекам КриптоПро через майкрософтовский криптопровайдер (такая вот загогулина, зато без .Net). Построение/разбор XML для Дельфи тоже вроде есть. Конкретно под ГИС на Дельфи не видел, наверно придется допилить. Находил программку, как нормализировать xml файл в форму c14n по правилам СМЭВ (представьте себе, не каждый XML "одинаково полезен" и воспринимается СМЭВ  - с ума сойти). Еще знаю, кто-то пишет на python интеграцию с ГИС, так что полагаю возможно все. Вопрос какого качества готовые части и сколько придется "допиливать" до получения приемлемого результата.

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

На вопросы про сертификаты ответил в новой теме:
[url:460dd5r0]http://forum.burmistr.ru/viewtopic.php?f=147&t=5548[/url:460dd5r0]
Если кратко, как захотите - так и сделаете. Закрытый ключ - это не обязательно флешка. OpenSSL обычно вообще глубоко все равно что стоит в системном хранилище сертификатов. С одной стороны - тоже своего рода проблема, с другой - нет побочных эффектов, как у хранилища "Личные".[QUOTE]AlcorVol пишет:
ГИС ЖКХ постоянно меняет версии форматов. Если бы они отвечали сами за сопровождение "умного клиента" на стороне УО, это было бы для конечного пользователя незаметно. А так - придётся каждый раз всё переделывать. Мне кажется, что версии будут меняться ещё много-премного раз.[/QUOTE]Те же шаблоны Экселя тоже переделывают, от этого никуда не деться, все равно придется реагировать на изменения. Если все спроектировать достаточно умно, с учетом возможных "откровений", то все переделывать не придется. Все-таки в ГИС такие же люди, ничего сверхестественного не придумают. Такая вот битва экстрасенсов. :D Мне бы хотелось, чтобы автоматика обновления шаблонов смогла проанализировать изменения шаблонов (чтобы из новой версии форматов определить название нового поля, название формата данных в поле и обязательность поля, вывести примечание человеку - не нужно искусственного интеллекта) и предложить какие-то действия "ответственному за шаблоны" (например добавить поле в шаблон или убрать из шаблона), если действий достаточно - кликает ОК и все счастливы sasd , если недостаточно, то звонит программисту и программист что-то чуть подправляет, например добавляет действие или корректирует алгоритм анализа.
[quote:460dd5r0]Ну, я имел в виду DLL для посылки информации напрямую в ГИС ЖКХ, но и такой DLL (вариант 3а) тоже неплохо смотрится.[/quote:460dd5r0]Согласен, однако я не могу представить 1 мега-супер-ультра DLL, выполняющую все функции сразу. Даже если от клиента отрезать все не связанное с отправкой (например шуршание в папках в 2a) и принимать в DLL ссылку на XML текст, все равно останется много "модулей" с различным назначением. С одной стороны, эти файлы - та самая "каша из топора", с другой - объединять все вместе как-то экстремально - кто его знает, что там другие программисты натворили "внутре". С третьей - в качестве СКЗИ (средство криптографической защиты информации) сертифицируют конкретные бинарные файлы, так что или берем что уже сертифицировано кем-то в составе другого СКЗИ или придется сертифицировать улучшенную DLL как СКЗИ. Без сертификации к нам могут нагрянуть с нежданной проверкой.
С учетом возможного распараллеливания отправки имеет смысл написать DLL как "общую" с учетом Thread Locale Storage (TLS), как системные библиотеки Windows - данные каждого потока хранятся в отдельной памяти, но адрес как бы один и тот же. Правда подобрать базовый адрес свободный "от xp до 10" будет непросто. Моя среда программирования "из коробки" TLS увы не поддерживает, сделать наверно можно, но придется долго читать "как" и долго колдовать.

[QUOTE]Programmer пишет:
У меня есть вот что:
1. Файл
8CAE88BBFD404A7A53630864F9033606E1DC45E2.cer
установлен в "Доверенные корневые центры сертификации".
Выдал: "Головной удостоверяющий центр".[/QUOTE]Это краеугольный камень единого пространства доверия сертификатов ГОСТ. Если подробнее, как все это примерно работает - Головной удостоверяющий центр (ГУЦ) выдал сертификат сам себе, но в дальнейшем этот сертификат практически не используется, небольшое исключение - подчиненные УЦ (удостоверяющие центры) ГУЦ, на текущий момент их 2 (УЦ 1 ИС ГУЦ, УЦ 2 ИС ГУЦ), считая с 1 истекшим сертификатом у них целых 6 сертификатов. Такие тонкости можно посмотреть на [URL=https://e-trust.gosuslugi.ru/MainCA]https://e-trust.gosuslugi.ru/MainCA[/URL] (у меня браузер предупреждает что сайт недоверенный, такие пироги).
Когда другой удостоверяющий центр посылает документы на аккредитацию, у него тоже имеется только самоподписанный корневой сертификат. После аккредитации, УЦ 1 ИС ГУЦ или УЦ 2 ИС ГУЦ выпускает сертификат на тот же открытый ключ, что и был указан в корневом сертификате. Это называется кросс-сертификат, благодаря нему нет необходимости ставить отдельный корневой сертификат для каждого аккредитованного УЦ, так как по цепочке доверия дойдет до корневого ГУЦ (уже доверенного благодаря установке в корневые сертификаты). Важно отметить, 1) если у какой-то компании тоже есть головной и подчиненные УЦ, то каждый подчиненный получает свой кросс-сертификат отдельно, головной УЦ компании не включается в цепочку, так как в кросс-сертификате стоит запрет на подчиненные УЦ, 2) если отсутствует (не установлен на компьютере и не включен в проверяемую цифровую подпись) сертификат УЦ 1(2) ИС ГУЦ , который выдал кросс-сертификат, то цепочка не дойдет до ГУЦ и выйдет ошибка. Поэтому на практике вместе с кросс-сертификатом прилагается еще и сертификат УЦ 1(2) ИС ГУЦ (ставятся в Промежуточные центры сертификации) либо многие УЦ поставляют свой корневой сертификат вместо кросс-сертификата. У неаккредитованных такого выбора нет - они всегда поставляют свой корневой, так как кросс-сертификата нет. Итого, сертификат ГУЦ в многих случаях просто пылится в сторонке. Отдельный вопрос, что мало все это поставить 1 раз, нужно еще и регулярно проверять списки отзыва для каждого УЦ.
[QUOTE]Programmer пишет:
2. Шесть файлов: header.key, maska.key, maska2.key, name.key, primary.key, primary2.key, котрые тупо записаны на флэшку. Я их вижу и могу свобдно копировать. С помощью КриптоПро установлены в "Личное". В диспетчере сертификатов там просматривается фамилия директора УК.

Подскажите, пожалуйста, что с этим дальше делать в части организации SOAP? И нужна ли мне эта флэшка каждый день для работы SOAP, или достаточно установленных сертификатов? Спасибо![/QUOTE]Похоже, сертификата директора в виде отдельного файла нет, всё в контейнере закрытого ключа. Все зависит от того, как именно будет организован обмен. Закрытый ключ необходим для подписи и шифрования, но возможно его перевести в другую форму и не использовать флешку (см. шаг 3). Наиболее вероятно какое-либо решение на основе OpenSSL (в статьях ссылка на МагПро, который использует его), тогда общий обзор...
Шаг 1 (при любой реализации). нужно будет вытащить сертификат из закрытого контейнера или из "Личное" (экспорт сертификата - без закрытого ключа). Без закрытого ключа потому, что в КриптоПро не реализован экспорт закрытого ключа по соображениям безопасности (можно только копировать в другой контейнер, но не в файл), а стандартное средство Microsoft делает это неправильно. Поэтому доставать закрытый ключ придется отдельно. Должен получиться сертификат в формате DER (расширение файла CER).
Шаг 2. Если используется OpenSSL, то нужно (для удобства) преобразовать сертификат из DER в PEM (расширение или PEM или CRT) средствами OpenSSL, потому что понимаются оба формата, но по умолчанию принят формат PEM и если использовать DER нужно указывать в параметрах формат входного файла сертификата для каждой команды, что несколько утомительно. PEM формат - кодировка base64 от содержимого DER формата плюс строки разделители начинающиеся /заканчивающиеся 5 дефисами, обычно его можно посмотреть обычным блокнотом. Блокнот может испортить переводы строк, но для исправления тоже есть утилиты.

Шаг 3. Извлечение закрытого ключа. В принципе, шаг зависит от реализации - есть возможность настроить обращение к обычному КриптоПро и использование флешки (добавив DLL от КриптоПро и дописав параметры или настроив файл конфигурации), но частенько закрытый ключ извлекают на жесткий диск, а флешку возвращают например в бухгалтерию или в сейф. Это не очень-то безопасно - исчезновение флешки заметить проще чем копирование файла закрытого ключа по сети на сторону. На Ваше усмотрение. Я тестировал для немного другого случая и за неделю до истечения сертификатов, поэтому извлекал.

У другого российского криптопровайдера есть утилита для экспорта сертификата вместе с закрытым ключом, но у меня так и не получилось экспортировать сертификаты этого года с ее помощью и прочитать в OpenSSL, попробовал позапрошлогодние из архива - без проблем. Так что скорее всего придется считывать закрытый ключ сторонней утилитой из тех самых файликов на флешке в формат PEM. Внимание, ключ сохраняемый утилитой незашифрован  и его надо хранить так же осторожно, как и саму флешку! Его можно зашифровать паролем позже средствами OpenSSL, но тогда при каждом подписании нужно вводить пароль либо зашивать пароль в программу отправки. (Средствами OpenSSL не предусмотрено запоминание пароля). Большинство решений по автоматизации оставляет файл без шифрования, но с различными ограничениями прав доступа к нему.
В статье на хабре есть исходники утилиты и есть готовая версия. Использование просто [code:1xf1y3b6]privkey.exe f:\abcdefgh.000 1234> c:\privkey.pem[/code:1xf1y3b6] где f:\abcdefgh.000 путь к папке на флешке, где лежат 6 файликов, 1234 пароль, privkey.pem - файл, куда запишется вывод программы. Так как запишется вывод программы, то нужно проверить что там не сообщение об ошибке, а реально закрытый ключ. У закрытого ключа начало "-----BEGIN PRIVATE KEY-----", ошибка может означать опечатку в пароле (не удалось проверить открытый ключ), в имени папки или что у флешки другое имя диска (не найден контейнер).

Шаг 4. Объединение закрытого ключа и сертификата (необязательно). Обычно OpenSSL при подписании ожидает, что сертификат и закрытый ключ находятся в одном файле. Если в предыдущих шагах получилось 2 разных файла, то нужно либо указывать отдельно файл с закрытым ключом, либо объединить - добавить закрытый ключ в файл сертификата. Если в Шаге 3 решили оставить флешку и заменить параметрами, то здесь тоже нужно пропустить и использовать параметры. Формат PEM позволяет объединять их при помощи любого текстового редактора (я простым блокнотом пробовал). Просто выделить все из одного файла, из другого и сохранить под новым именем. Естественно объединенный файл нужно хранить осторожно как и отдельный файл закрытого ключа. Для каких-то реализаций (в моем случае - собственный "самопальный" УЦ) может потребоваться извлечение открытого ключа и объединение с закрытым в ключевую пару, но это уже отдельная история.
[quote:1xf1y3b6]Далее надо организовать тестовые стенды, настроить канал, и пробовать формировать запросы. В документации это все описано. <...> Для тестирования желательно сформировать тестовые ключи( хотя никто не запрещает тестироваться на "боевых")[/quote:1xf1y3b6]Именно. Зачем формировать тестовые ключи, я так и не понял. Наверно, чтобы не ждать изготовления "боевых" ключей? Если они уже есть, тестовые не обязательны. Документацию пока не читал подробно, даже не знаю стоит ли - некоторые изменения до сих пор там не отражены. :)
[quote:1xf1y3b6]Шесть файлов: header.key, maska.key, maska2.key, name.key, primary.key, primary2.key[/quote:1xf1y3b6] у меня называются masks.key masks2.key в остальном тоже самое.[quote:1xf1y3b6] Почему у меня видны на флэшке 8 файлов, а у моего коллеги - нет?[/quote:1xf1y3b6] Вероятно 7 и 8 файлы это сертификат (CER) и запрос на сертификат (REQ или CSR). Иногда еще бывает печатная форма заявления (DOC, RTF) или печатная форма сертификата (PDF). Это зависит от УЦ - некоторые позволяют генерировать запрос на сертификат самостоятельно. Запрос - это по сути сертификат без информации, добавляемой в УЦ и без подписи УЦ. В этом случае контейнер закрытого ключа не содержит сертификата, потому что его еще не выпустили. Затем из УЦ присылают готовый сертификат и при установке сертификата появляется выбор - установить сертификат в закрытый контейнер или оставить их по отдельности. Конечно есть случаи, когда бухгалтерия хранит на флешке какие-нибудь фотографии и прочую постороннюю информацию.

[QUOTE]Programmer пишет:
two_oceans! ОЧЕНЬ ИНТЕРЕСНО, КРАСИВО! Но кто в ГИСе будет этим заниматься. Там ведь люди (в отличии от Вас) не творческие, у них принцип: "работает так (работает ли?) - и ладно" и на фига им эти заморочки.[/QUOTE]Ну, эта тема и начиналась - а вдруг почитают? Вдруг флешмоб сделаем и подействует волшебным образом. Чем конструктивнее критика, тем больше вероятность что-то изменить. По крайней мере, хотелось бы в это верить.
С другой стороны, чисто для себя привести мысли в порядок и разобрать как "первое приближение" того, что я хочу сделать в итоге. Статьи на хабре про CentOS с намеком на кроссплатформенность, это хорошо, но после прочтения у меня всегда ощущение, что "сварили кашу из топора". Использовали подручные средства, какие только нашли беглым взглядом, и в итоге половина нужны только для приготовления других средств. Хотелось бы выделить необходимый минимум средств и уйти от "в файле конфигурации пишем то-то", "повторяем в следующем", чтобы указав параметр один раз он действовал для всего комплекса, а не просто для конкретной утилиты. Вместе с тем, как-то автоматизировать обновление шаблонов, чтобы не пришлось все менять на каждой версии. Кстати про шаблоны, меня реально раздражает, когда в примере SOAP для ГИС сначала скажем идет тег с ns2: потом в него вложен ns12: в него ns6: Уж с порядком вложения могли бы изначально определиться.

С третьей стороны, а ну вдруг как навалимся все вместе и сделаем - посрамим ГИС. Для определения, что нам реально нужно, а что излишество и роскошь.
Если сомнения, что сможем.. в конце концов, уже есть бесплатный клиент Росстата, можно расковырять в каком виде хранятся шаблоны для загрузки в него. Среди них есть отчеты с переменным количеством строк - например, отчет по разрешениям на строительство - номер каждого передается отдельной строкой. Адрес сайта для обновления отчетов меняется в настройках, к сертификату тоже жестких ограничений нет, так что подменить шаблоны не вопрос. Отчеты уже в XML. Попробовать затолкать SOAP или близкое к тому - уже будет редактор XML/SOAP.
С автоотправкой сложнее. Интерфейс сайта для приема из клиента тоже реально настроить - это позволит использовать другую авторизацию на самой ГИС и запрашивать разные страницы в зависимости от "кода отчета". Проблема, что: 1 ) скорее всего алгоритм подписания не совпадает (тут надо дополнительно думать, может быть тоже исправлять на сайте), 2) отчеты предоставляются периодически и за каждый период только 1 отчет (хотя ничто нам не мешает сделать тысячу одинаковых шаблонов отчета с разными кодами на 1 неделю), 3) подозреваю, что ответ на отчет из Росстата гораздо короче, чем отвечает ГИС.

По поводу того, что ГИС грузит по 10 ЛС, но отказывается обработать 200 ЛС, полагаю это как раз ограничение синхронной обработки. У любого обработчика, запускаемого веб-сервером есть предельное время исполнения. Поэтому что за 30 секунд успеет обработаться - ОК, что не успеет - ошибка. Длинные файлы должны оставляться на асинхронную обработку. SOAP отвечает быстрее именно поэтому - синхронные запросы успевают обработаться, на асинхронные сразу выдается - "в обработке, ждите", не дожидаясь обработки. Даже если она завершится через 2 секунды.

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

Второй и третий вариант с моей точки зрения предпочтительней. Второй вариант мне видится так: оффлайн-клиент, который бы принимал заданный тип данных передаваемых данных из заданной папки (несложно понаделать отдельных папок для ЛС, платежек, показаний ПУ...) в формате XML (но вообще можно и DBF CVS преобразовывать). Более точно: перечислял файлы в папках по таймеру, предварительно контролировал корректность данных в файле (что не закинули ЛС в папку ПУ), а дальше скажем сортировал правильные файлы - в папку на отправку, неправильные в папку ошибок. Желательно чтобы если в файле несколько записей, они тоже разделялись - допустим из 15 записей, 14 верных записей на отправку, 1 неверная в ошибки, а не весь файл в ошибки. Далее идет процесс отправки - обертка в SOAP, подписание/шифрование (тут конечно грабли, что перед подписанием как бы положено показывать подписываемое), установление защищенного соединения, отправка (если асинхронный сервис, то сохранение полученного идентификатора и проверка по таймеру, обработался ли) и сохранение ответного XML. Параллельно формирование протокола и перемещение исходного запроса вместе с дополнительными данными (протоколом например) по папкам, соответствующим статусу запроса (отправка, ошибки, ожидает обработки, обработан), чтобы в исходном перечислении не путались. Мне такой вариант ближе и понятнее как программисту - на отладку пользовательского интерфейса уходит чрезвычайно много времени.
Похожий вариант - сортировка записей одного файла на правильные и ошибочные уже реализована в ПО для загрузки данных внешних ИС (данные избирателей) в ГАС "Выборы". Для дальнейшей обработки там используются буферные таблицы. Так что, идею революционной не назовешь.
Конечно, можно сделать и интерактивный вариант (то есть вместо автоматического приема XML производить какие-то действия вручную в пользовательском интерфейсе, но тогда придется обучать пользователей). Примером такого может стать оффлайн-клиент Росстата - позволяет загрузить XML из файла либо ввести на основе шаблона вручную, произвести контроль правильности заполнения, заполненный отчет можно выгрузить в XML файл (на выбор подписанный либо неподписанный) для отправки вручную через систему электронного документооборота либо ввести логин и пароль на сайте росстата и отправить автоматически подписанный прямо из клиента (в этом случае так же клиент по таймеру проверяет статус обработки отчета). Кроме того, есть функция автоматического обновления шаблонов и самого клиента с сайта Росстата. Основные вопросы очень даже продуманы, то есть программисты ГИС просто могли бы взять основу у Росстата, поменять шаблоны  и систему авторизации. Итого - идея тоже не революционная.
Есть конечно заморочки по установки всей этой "прелести" на Windows XP - требует dotNet 2.0 с определенным обновлением и установки корневого сертификата Росстата. Да, я тоже думал что установить сертификат минутное дело, пока на одном компьютере не промучился с этим минут 40 - сертификат ставился неизвестно в какое хранилище - вроде как и установлен, но в хранилище корневых его нет. Потом начальное обновление всех шаблонов - тоже полчаса (но можно указать только нужные). Также при обновлении версии программы в нестандартной конфигурации с некоторой вероятностью база данных становится несовместимой - на одном компьютере можно переключаться между разными базами (например нам это нужно, чтобы сдавать отчеты от разных отделов ОМСУ - ФИО, должность и телефон  ответственного намертво прописывается в данных организации, переключить базу проще чем все поля править), но при обновлении программа обновляет только одну базу данных, указанную на момент обновления, на все остальные начинает ругаться что они устарели. База данных кстати - Firebird(Interbase).Но все это можно перетерпеть, так как программа БЕСПЛАТНАЯ.
Третий вариант - все вышеперечисленное в оффлайн-клиенте можно завязать на функцию в DLL (передавать имя файла для обработки, имя папки для перечисления, собственно данные XML либо ссылку на объект их содержащий), то есть задача в целом сводится к второму варианту. Вызываете функцию, а дальше пошла кипеть работа.
P.S. После прочтения ссылки на хабр, я стал получше представлять механику и даже подумывал в отдельной теме разобрать поэтапно что и как бы хотелось от такой платформы (ну или оффлайн-клиента). В частности, хотелось бы наверно добавить установку через интернет - по примеру Контур.Веб-диск - со страницы скачиваешь и ставишь маленькую программку (компонент, дающий права сайту устанавливать любые программы), далее обновляешь страницу и понеслось - анализ, что установлено на компьютере, каких версий, список что нужно дополнительно установить или обновить, убираешь ненужное, нажимаешь кнопку - автоскачивание и установка,перезапуск браузера, результат. Как считаете, нужно отдельной темой или тут продолжить?

[SIZE=85px][COLOR=greenpt]Отправлено спустя 47 минуты 26 секунды:[/COLOR][/SIZE]
[quote:2dhrp2ml]Это печально. Я как раз писать ещё не пробовал. Но читается всё хорошо. Пригодится хотя бы для того, чтобы всякие ИДы домов и помещений к себе скачать и в БД проставить.[/quote:2dhrp2ml]К сожалению, с VFP не работал. Если будут вопросы по Excel.Application - могу подсказать некоторые моменты. Встроенная справка от Майкрософт - ни о чем, только название посмотреть (это конечно тоже полезно, но недостаточно). Во многих случаях указано, что параметр или свойство - Object или вообще Variant, но попробуй догадайся какого типа объект туда передавать без реального примера. Ни считывание значения ячейки, ни открытие текстового файла я бы "не осилил" без примеров, на одной только справке.
Как я уже писал, Excel.Application и его дочерние объекты работают быстрее при вызове изнутри. Вообще если извне к чему-то обращаетесь желательно (как мне кажется ускоряет) каждый уровень иерархии в отдельную переменную (чтобы дважды не вычислялось например что за объект Excel.Workbooks("111.xls").Sheets(2) можно объект листа в отдельную переменную)  и заменять обращение к дефолтным свойствам на наименование свойства. Например, Sheets(2).Cells(1,2) это ячейка, при попытке прочитать значение, Эксель неявно обращается к свойству ячейки .Value (свойству указанному по умолчанию для объекта, голубенький маленький кружок в списке свойств) и все работает, но на это тоже тратится время и полностью правильно будет не срезать углы и с самого начала запрашивать Sheets(2).Cells(1,2).Value

[QUOTE]AlcorVol пишет:
для себя я могу эту проблему решить за час[/QUOTE]Тест, Тест. Почти решил (надо еще поменять указатели на тему, а то публикует в теме "эмоции пост", откуда пересадил форму). Честно сказать удивился немного - на форму быстрого ответа нужно 44,5 Кб кода из 128 Кб страницы.

[QUOTE]AlcorVol пишет:
[quote:ps39hydh]Примерно такие же сведения нужны ОМСУ для начисления субсидий - что было начислено от УО/РСО/РКЦ за полгода и что в итоге задолженности нет. Про то, итог на какую дату, вопрос остается открытым...[/QUOTE]
Но как-то "на местах" он сейчас всегда решается. У нас для начисления субсидий, а также ЕДК "льготникам", проживающим по адресу ЛС, требуется, чтобы у плательщика "не было задолженности".  Моя программа поступает так: начисления данного месяца не учитываются, а платежи, поступившие в этом месяце - учитываются. Вроде бы, это всех устраивает. Кроме злостных неплательщиков, конечно же. (Здесь следует заметить, что и суммы льгот (ЕДК) считают у нас как раз УО/РСО/ЖКРЦ=РКЦ.)
Короче говоря, все сальдо (и - возможно - сведения о [B][I]просроченной[/I][/B] задолженности) должна передавать в ГИС расчётная организация. В моём случае - УК/ТСЖ.[/quote:ps39hydh]Критерий отсутствия задолженности логичный, хотя что одно считаем, другое не считаем, когда-нибудь может вызвать неожиданные последствия. Выше написал как решается "на местах" - берут справки у УК. По закону о муниципальных услугах ОМСУ такие справки [B][U]требовать[/U][/B] не может, гражданин может представить на [I]добровольной[/I] основе. :D Фактически же, если не представишь - очень вероятно, что задолженность все-таки проскользнет по переданным данным и законно же откажут. Хотя с этим тоже закавыка - переданные из УК файлы Экселя не подписаны ЭП (по крайней мере пока), то есть юридически не обоснование.
Численность проживающих в основном у нас была выровнена во время попытки создать РКЦ. Опять же на деле справочка о составе семьи решает: уже есть случаи когда в одной РСО (после переездов, реорганизаций) по адресу числится 2 человека, в другой РСО/УК по тому же адресу 3 человека. Это еще одна проблема, МУП которое выдает справки о составе семьи вообще непонятно в чем ведет учет (по телефону внятно объяснить не смогли, надо ехать), даже отчеты в Эксель выгрузить не могут, заполняют вручную по минимуму. И от обмена между ОМСУ и МУП никак не открутиться, все же подчиненное учреждение.
Сейчас льгота учитается программой отдела субсидий исходя из полного начисления и соотношения числа льготников к числу жителей. Опять же будут "грабли", если УК передадут неполное начисление в ГИС, скажем с учетом льготы или переплаты. Вот как ни хочется уйти от Экселевских файлов, а видимо опять все к ним выйдет - данных ГИС будет недостаточно для 100% уверенности.
[QUOTE]AlcorVol пишет:
[quote:ps39hydh]Про переплаты мне тоже непонятно - как будет отражаться переплата за "доГИСовский" период: как фиктивный суммарный платеж (фиктивный в том смысле что по факту его банк не передавал), отрицательное начисление или просто УК проквитирует какое-то количество месяцев.[/QUOTE]
По-моему, разработчики пока не очень даже парились про "доГИСовский период". Типа, "до нас ничего не было и быть не могло".  :D[/quote:ps39hydh]Это печально. В соседней теме проскользнуло, что в ГИС отрицательных начислений не может быть, разве что нулевые, одним вариантом меньше. Видимо все же УК проквитует сколько-то месяцев, но тогда не факт, что сальдо будет сходиться к новому году, переплаты может хватить еще дольше.

По поводу банка, возможно мысль правильная, но в другом направлении. Возможно Вам удасться пройти по критериям каких-нибудь платежных агентов, и банк сможет эти данные отправить. Законодательство в этой области довольно неясное, на первый взгляд противоречащее, нужно учитывать кто под какой закон попадает, так что утверждать наверняка я не возьмусь. На банкирском форуме до хрипоты спорили про платежных агентов. В детали спора я признаться не вникал, понял только, что банк не является таким, зато банк является агентом по переводу платежей и что при каких-то условиях может передавать данные о платежах с терминалов, которые не в собственности банка. Попробуйте потянуть за эту ниточку в разговоре со своим банком.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 3 минуты 41 секунды:[/COLOR][/SIZE]
[QUOTE]portal-gkh пишет:
им можно отправить это требование в виде предложения по улучшению системы[/QUOTE]Почему-то мне кажется, что его запланируют на уже легендарную версию 11.

[QUOTE]Basil пишет:
[QUOTE]AlcorVol пишет:

Да, согласен. Ну, и итоговое сальдо расчётов ещё.[/QUOTE]
А с сальдо ничего не выйдет. Для сальдо нужен биллинг, а биллинга в ГИС не будет.   ;)[/QUOTE]Полагаю, что выйдет, если использовать сумму, уже проквитированную УО/РСО/РКЦ. Такой вот "ручной биллинг".

Примерно такие же сведения нужны ОМСУ для начисления субсидий - что было начислено от УО/РСО/РКЦ за полгода и что в итоге задолженности нет. Про то, итог на какую дату, вопрос остается открытым - пока я не уловил всех тонкостей. Сейчас, как я понимаю, люди договариваются с УК и им пишут справку, что задолженности нет при ненулевом сальдо. Просто потому что в текущем месяце платят за предыдущий и оттягивают до последнего, а значит сальдо нулевое может быть только после того, как человек заплатил и до того как выставили следующее начисление. Либо придется фильтровать начисления по дате и не учитывать, те из них, которые после заданной даты. Если все проквитированы - считать что задолженности нет. Тут полагаю и вылезут грабли кто за какие месяцы квитирует. Ну и это все конечно если с доступом получится.

Про переплаты мне тоже непонятно - как будет отражаться переплата за "доГИСовский" период: как фиктивный суммарный платеж (фиктивный в том смысле что по факту его банк не передавал), отрицательное начисление или просто УК проквитирует какое-то количество месяцев.

[QUOTE]AlcorVol пишет:
Я, видимо, каких-то старых вебинаров насмотрелся.[/QUOTE]На всякий случай, еще проверю, может уже переиграли все.
[QUOTE]AlcorVol пишет:
Бардак этот ещё долго будет продолжаться, КМК. Ребята решили "объять необъятное".  :D Кстати, а "Город"-то какой?  ;) Я вот совсем не скрываю, что в Вологде живу и работаю.[/QUOTE]Ну в Вологде наверно немало программистов. Могу сказать регион - Иркутская область. А у меня городок маленький, по данным о месте работы в техподдержке ОМСУ, имени, знакомству с термином "ГИС ЖКХ" и городу можно уже сузить до одного человека. В свете законов о хранении данных за три года может потом будут атата делать за нелестные отзывы о ГИС. :D Хотя конечно, и по нику найдут если захотят.

[QUOTE]AlcorVol пишет:
Программы, написанные на VFP - это вовсе не "консольные", а полноценные Windows-приложения.[/QUOTE]Тогда прошу извинить. У меня почему-то ассоциируется со консольными программами от ПФР и налоговой. По ссылке перешел, в разделе "Other Open Source VFP Projects" нашелся проект VFPTweetAPI, скачал архив, в папке prgs есть libhttprequest.prg, там как раз работа с веб запросами к Twitter, в том числе создание объекта MsXml2.XmlHttp и его использование c аутентификацией OAuth. Обычно еще делается создание других объектов с той же функциональностью (названий наверно 6-8 в зависимости от версии Windows и установленнных программ) в случае если указанный объект отсутствует в системе, но чтобы начать разбираться наверно подойдет. [QUOTE]AlcorVol пишет:
Иначе пришлось бы переписывать старый, отлаженный в течение многих лет код. [/QUOTE] Поддержка старых версий - замечательное свойство. Но, наверно, ровно до тех пор, как придется старый код трогать. Как правило смотрю на код, не тронутый несколько лет, и начинаю переписывать некоторые части с нуля. Не потому что непонятно, а потому что вижу - можно убрать лишнее, что уже никогда не выполняется/не используется или из 4 похожих процедур можно сделать одну или проект уже видится как другая концепция и т.д.
Недавний пример: на 1 страничке было 12 форм, в том числе календарик для ввода даты в остальные формы, все работало нормально. Казалось бы - отлаженный код, через пару лет скопировал календарик (с переделкой стилей) на другую страничку, а он внезапно начал неправильно дни показывать. Исправил, но не могло же это из-за стилей произойти, теперь вот ощущение, что надо исходную страничку переделать с нуля, разделив на несколько частей и протестировав работу каждой независимо. Повод тоже есть - убрать конфликт библиотек.
[QUOTE]burmistr пишет:
А по рекламе - смысла нет. Форум никак не продвигается кроме рассказов на семинарах. В основном поток с поисковиков идет.[/QUOTE]ОК.

[QUOTE]AlcorVol пишет:
Пусть банк ничего и не квитирует. Пусть он просто в ГИС реквизиты ПД и сумму платежа передаёт. Спрашивается: какого чёрта на основании этого ГИС ЖКХ будет помечать ПД как "оплаченный"? ГИС историю взаимоотношений плательщика и УО знает?.. А если не знает, то это просто, как бы - извините! - не её свинячье дело. Все отношения с плательщиками/неплательщиками - это дело бухгалтерии управляющей организации. Разве не так?..[/QUOTE]Все верно. Как я понял из записи семинара РКЦ (на ютубе канал авторов ГИС ЖКХ), банки в ГИС ЖКХ только передают данные, что платеж [B][U]принят[/U][/B] от физического лица. В обмен на [B]незамедлительную[/B] передачу данных с банков сняли проверку доставки платежа до счета получателя (УО/РСО/РКЦ). Бухгалтерия УО/РСО/РКЦ должна проверить, что деньги [B][U]действительно дошли[/U][/B] до счета УО/РСО/РКЦ и только после этого сквитовать начисление. Тем не менее, статус предварительного квитирования по реквизитам оплаченного начисления возможно нужен для банка - чтобы нельзя было оплатить начисление дважды, такое предварительно сквитированное начисление вероятно скрывается для банка, а для УО/РСО/РКЦ это не должно иметь никакого эффекта. Если имеет эффект - это по любому глюк ГИС, потому что ГИС (пока?) не имеет данных о поступлении на счет УО/РСО/РКЦ.

По истории взаимоотношений, как я понимаю долги за прошлые периоды (и пени?) тоже нужно как-то выставлять в ГИС, тогда банки смогут показать их гражданину для оплаты и предварительное квитирование тоже будет работать корректнее. А так, какая разница, какое начисление сквитовалось, если сумма та же? Я так понимаю, если человек оплатил последний месяц, а за прошлые долг, то по сравнению с ситуацией где он оплатил часть прошлого долга, а последний месяц не оплачен, наоборот пени будет больше?

Из личного опыта - у нас пока банк в квитанции об оплате (через платежную систему "Город") показывает какие-то взятые с потолка цифры долга/переплаты, местные УК/РСО говорят, что в платежную систему "Город" ничего не передавали и советуют игнорировать эти цифры и платить "как обычно" (тариф посчитал сам, сказали что правильно). Вот откуда что берется?

[QUOTE]Дамир пишет:
уже работают 1102 системы интеграции с ГИС ЖКХ, еще 344 системы проходят тестирование интеграционного взаимодействия[/QUOTE]А ожидаемое количество ИС из которых передавать данные тут оценивали в примерно 20-30 тысяч. То есть хоть как-то соединиться пытаются максимум 7,5%. От "все работает" это отличается как небо и земля, даже если просто брать нагрузку на систему. При 7% такие перебои, спрашивается что будет при 100%? [QUOTE]Programmer пишет:
Так как в банки ПО спускалось централизованно[/QUOTE]Да, точнее они уже были подключены с 2013 года к ГИС ГМП для передачи платежей в бюджет и больше половины банков для этого использовали платформу одного производителя. Производитель ввел новые форматы для ГИС ЖКХ - и вуаля, сотни ИС подключены.
[SIZE=85px][COLOR=greenpt]Отправлено спустя 3 минуты 22 секунды:[/COLOR][/SIZE]
[QUOTE]Екатерина_2014 пишет:
Не переживайте, думаю и через неделю ничего не изменится.[/QUOTE]Такими темпами выработается олимийское спокойствие.

[QUOTE]AlcorVol пишет:
Что такое УЦ - я не понял  :) , но stunnel точно может много самых разных туннелей пасти.[/QUOTE]Спасибо, действительно пригодится. УЦ - удостоверяющий центр, выдающий сертификат ключа проверки электронной подписи. Обычно мы пользуемся УЦ Федерального Казначейства (ОМСУ бесплатно, а чтобы была "ложка дегтя" требуют кучу документов), но вот беда, для подготовки заявки используется специальная программа, в которой весьма сложно сделать нестандартный сертификат (например для сервера при использовании криптотоннеля или для электронной почты). Понятно, что "самопальный" УЦ не аккредитован и его сертификаты [B][U]не подойдут[/U][/B] для работы с федеральными системами, однако для шифрования между головной организацией и филиалами или защиты внутренней почты - именно то, что нужно. На организацию, аккредитацию и сертификацию УЦ по подсчетам на форуме КриптоПро нужно около 6 миллионов рублей, поэтому аккредитация окупается только при выпуске 4000 и более сертификатов в год. Есть и промежуточный вариант - заключить договор с аккредитованным УЦ на удаленное рабочее место выпуска сертификатов. Тоже дорого, но подешевле чем собственный аккредитованный УЦ. Если выпускать много сертификатов, то и дешевле чем покупать по одному. В итоге, я пока "самопальный" планирую для нестандартных сертификатов.[QUOTE]AlcorVol пишет:
А вот ещё кое-что интересненькое. Для меня - тёмный лес. Но тебе, Костя, - точно всё понятно будет: [URL=https://habrahabr.ru/post/300856/]https://habrahabr.ru/post/300856/[/URL] - как раз на тему ГИС ЖКХ, stunnel, OpenSSL, ГОСТ. Это ничего, что я уже на "ты"? :)[/QUOTE]Спасибо еще раз, просмотрел по диагонали пока, там для CentOS, а не для Windows, но пример подробный, пригодится. Все нормально, похоже что я младше, у меня считая со школьными учебными программами едва 18 лет программирования.
[QUOTE]AlcorVol пишет:
Моя среда - Visual FoxPro. А мой стиль - скорее, ДОСовский (20+летний "багаж" кода крепко держит). ООП - только в редких случаях, как сейчас, при работе с XLSX.[/QUOTE]Примерно так и думал про Visual FoxPro. Против консольных программ ничего против не имею, но недавно столкнулся с парой глюков. Есть диск со старой программой разметки диска, она как бы с доса без загрузки Windows отрисовывавает оконный интерфейс. Лет десять назад вроде работало быстро (на старых компьютере). Месяц назад под рукой не оказалось другого для разметки запустил эту прогу на относительно недавнем компьютере и был просто шокирован как тормозит отрисовка окон. После появления/исчезновения очередного окна пару минут ровняется край окна. Выходит, что времена меняются, на отрисовку окна в в браузере уйдет меньше полсекунды. Да, попробовали недавно - 1С Бухгалтерию пробно запустили в браузере через Apache, и похоже это работает быстрее чем запуск обычного приложения-клиента.
[QUOTE]AlcorVol пишет:
Главная цель автоматизации: как можно реже отрывать задницу от уютного кресла.  :) Всякие удобства для бухгалтеров УК - лишь мелкий побочный эффект.  :D[/QUOTE]Правильный подход. У нас такого добиться сложно - некоторые отделы по телефону просто говорят "зайди к нам" или "зайди к нам, прямо сейчас" не указывая вообще в чем проблема. В половине случаев я мог проблему решить удаленно, но им кажется "в глаза" рассказать надежнее.
[QUOTE]AlcorVol пишет:
Если [B][I]Час Икс[/I][/B] ещё на полгодика отодвинут, то возможно, и SOAP освоить успею.[/QUOTE]Хорошо бы. :)
[QUOTE]burmistr пишет:
глядишь через пару апдейтов яндекса сюда другие программеры по ГИСу подтянутся)))[/QUOTE]А если порекламить, то еще быстрее. :D И надо побольше создать тем, с примерами кода. Если серьезно, то апдейты яндекса могут занять приличное количество времени. В админке Яндекс.Вебмастера после попытки исправления ошибки мне предлагают подождать пару недель. При этом робот ежедневно чего-то проверяет.
[QUOTE]AlcorVol пишет:
Всё же крайне неудобно, что "Быстрого ответа" в форумах "второго уровня" нет.[/QUOTE]Присоединяюсь. Хотя, продолжая тему про веб, чисто для себя я могу эту проблему решить за час (большая часть времени - на сравнение чего не хватает). У меня есть программка Proxomitron, представляет собой прокси сервер. Любую страницу проходящую через программу (по HTTP) можно пропустить через набор правил (регулярные выражения) - удалить рекламу, гугловские счетчики, кнопки социальных сетей или наборот что-то добавить на страницу (форму быстрого ответа например), поменять служебные заголовки. Изменения будут видны только тем, кто к программке подключен, так что это не взлом сайта. Однако, этого достаточно, чтобы вытянуть произвольные доступные данные или реконструировать скрытые функции. С HTTPS правда не все так гладко - для поддержки нужны библиотеки из OpenSSL, но свежие версии не подходят - одну из основных функций в библиотеке переименовали, нужно пропатчить на новое название в Proxomitron либо добавить старое название в библиотеку.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 39 минуты 10 секунды:[/COLOR][/SIZE]
[QUOTE]Ирина В. пишет:
Да смотрела эту ересь. В остальном благодарю, как раз сегодня хотела звонить программисту РКЦ по вопросу нашего взаимодействия, теперь понимаю, что пусть, пока, человек спокойно изучает милый ГИС.[/QUOTE]Если не звонили раньше, наверно будет все же лучше позвонить, уточнить что изучать ГИС в РКЦ начали и что по оплате. Чтобы потом не оказалось что друг на друга понадеялись. Если уже звонили, то хорошо бы посматривать не появился ли запрос на доступ из ИС и тогда позвонить уточнить что это именно ИС РКЦ.

[QUOTE]Ирина В. пишет:
[QUOTE]two_oceans пишет:
Свою ГИС тут устроить хотите, а программистов шарахаетесь?[/QUOTE]Пожалуйста, объясните, УК, ТСЖ, РСО оплачивают дополнительно Вашу работу? В ГИСе, они дают Вам доступ как ИС или..?[/QUOTE]По оплате нет. Я пока ничего не внедрил. Предыдущая программа не моя, платят ли за нее сейчас, я не уверен. Вообще кажется, что вопрос наверно адресован не мне.
Насчет ИС тоже не все так просто - прежде чем ей дать права, ее нужно сначала зарегистрировать и протестировать. По сути тоже сумасшествие - как я понимаю, не предусмотрено написание ИС с нуля "по ходу пьесы", надо тестировать, то что уже готово, после корректировок перетестировать перед реальной работой, зато ГИС добавляет, что захочет, куда захочет и когда захочет. То есть, ориентируясь на обещания спецификации, что будут доступны такие-то данные после получения таких-то прав, мне нужно написать ИС. Потом получить сертификаты, настроить канал, зарегистрировать в ГИС, протестировать что я правда сумею обработать данные (если мне их предоставят) на тестовом сервере ГИС, запросить права доступа у кого-то. И только потом может выясниться, что на рабочем-то ГИС у меня на самом деле прав не хватает и все усилия были зря. Потому что обещания спецификации на деле не вступили в силу, из-за глюка системы или множества других ситуаций.  dash2

[quote:2vmg91us]5Tyx01287600114[/quote:2vmg91us]Подумал еще, конец "1287600114" очень похоже на отметку времени, набросал скрипт 1.js [code:2vmg91us]var t=1287600114;
var dt=new Date(t*1000);
dtS=dt.toLocaleString();
WScript.echo(dtS);[/code:2vmg91us] результат - в привычном виде это "21 октября 2010 г. 02:41:54", похоже на время изготовления или установки.

[QUOTE]AlcorVol пишет:
Пока почти ничего в этом не понимаю, хотя и использовал уже stunnel при организации отправки всяких документов по емейлу прямо из программы. [/QUOTE]Со stunnel пока вплотную не разбирался, но в том направлении еще планирую сделать УЦ на OpenSSL для внутреннего пользования, уже почти определился, что должно быть в корневом квалифицированном сертификате по ГОСТу (сомнения что записать в сведения о средстве УЦ). Что меня смущает в stunnel - в конфигурациях показаны настройки только для одного порта и рекомендация положить конфиг в папку Windows. Итого, с одного компа - один туннель? Или все же будет работать и в других папках и тогда возможно много туннелей?
[QUOTE]AlcorVol пишет:
Ввиду того, что моя программа работает просто как Win-приложение, нужно долго изучать, каким образом я мог бы использовать такие средства.  :) [/QUOTE]Полагаю, это зависит от среды программирования, возможно уже есть готовый модуль. В общем случае, кажется, нужно системную OLE библиотеку подключить и вызвать CoInitialize, тогда можно будет создавать ActiveX объекты из приложения с помощью CreateObject, в том числе и XmlHttp. Либо вынести соответствующее место в отдельный VBScript и запускать по необходимости, но тут скорее всего антивирусы будут интересоваться приложением.
[QUOTE]AlcorVol пишет:
У меня даже свой домен уже несколько лет, как имеется.[/QUOTE]Продляете и не используете?
[QUOTE]AlcorVol пишет:
Да, WebDAV-ом я интересовался уже когда-то. Но больше абстрактного интереса тоже дело не пошло.  :) А вообще-то эта штучка была бы мне полезна. У некоторых УК бухгалтерия и жил.участки бывают разнесены территориально, единой локальной сети нет. Вот и приходится колдовать с передачей данных на флэшке и их корректным слиянием... Потом Вас ещё поспрашиваю, если Вы не против. [/QUOTE]Конечно спрашивайте. С чем сталкивался: 1) веб-сервер для DAV- можно использовать Apache из "комплекта" XAMPP в котором уже есть DAV модуль; 2) веб-сервер (не только Apache) помимо прочего позволяет при публикации вкладывать папки находящиеся в реально разных местах и перенаправлять запросы к определенной папке на другой сервер (обратный прокси). Получается несколько папок на нескольких серверах перенаправить (с вложением в одну) и подключить как 1 диск. Если поразбираться, скорее всего и криптотуннель возможно организовать средствами Apache+OpenSSL; 3) на семерке бывает отключена/остановлена служба Веб-клиент и без нее не подключается сетевой диск WebDAV.[QUOTE]AlcorVol пишет:
В крайнем случае - удалённый доступ через Ammyy Admin. Ну, и телефон, конечно.[/QUOTE]Ужас какой. Хотя надо сказать бухгалтерия бухгалтерии рознь, некоторые самостоятельно выполняют длинющие инструкции, даже настраивают Vipnet. :shock:
[QUOTE]AlcorVol пишет:
Ну, у меня есть УК  и с 10-15 тыс. ЛС. Грузить придётся всё раздельно по домам.  :([/QUOTE]Тогда реально SOAP нужен - один раз допустим загрузка из XLSX, чтобы загрузить счета. А потом? Интересно, месяца-то хватит чтобы все начисления XLSX по домам за прошлый месяц загрузить?
[QUOTE]AlcorVol пишет:
P.S. Был бы рад познакомиться с Вами поближе.[/QUOTE]Очень приятно, а меня Константин. На "ты" конечно проще. У меня разница по времени 5 часов с Москвой, поэтому бывает сложно выбрать взаимно-удобное время.
[QUOTE]portal-gkh пишет:
Например, экспортируем приборы учета через SOAP - метод exportMeteringDeviceData - "Получить перечень ПУ" возвращает MeteringDeviceRootGUID GUIDType - поле "Идентификатор ПУ в ГИС ЖКХ" и выглядит примерно так: 03775bea-d5c9-4028-9ccf-3f7d207d94f3
Тот же прибор, полученный через "Экспорт ПУ" в виде XLSX , в поле "Номер прибора учета в ГИС ЖКХ" может выглядеть примерно так: 5Tyx01287600114[/QUOTE]Конечно, я не читал спецификацию именно по ПУ, но поспекулирую. "Меня терзают смутные сомнения", что "Идентификатор ПУ в ГИС ЖКХ" (GUID почти наверняка формируется случайно - машиночитаемый, человеку бесполезен) и не должен совпадать с "Номер прибора учета в ГИС ЖКХ"(по виду похоже - формируется по правилам и чего-то должен сказать человеку, знающему правила). Ну примерно как MAC-адрес сетевой (человеку практически бесполезен, хотя содержит данные о производителе сетевой) и IP-адрес (используется в том числе человеком при настройке соединений) в принципе не должны совпадать и было бы логично в SOAP поискать что-то возвращающее Номер по GUID или наоборот. "RootGUID" еще интереснее, может быть под корнем дальше более детальные данные можно вытянуть.

[QUOTE]Rembo пишет:
[SIZE=150px]К вопросу о модераторе по ГИС :)[/SIZE][SIZE=150px] Вот здесь задание будущему модератору :)[/SIZE]
В теме общаются два подозрительных типа, явно не работники  УО или  ТСЖ  :)
Задача 1. Разобраться о чем они говорят и насколько  подозрительны и опасны  :)
Задача 2. Спрогнозировать в данной теме риск внезапного появления  коммерческого предложения по оказанию услуг по ГИС ЖКХ  :)[/QUOTE]Боюсь-боюсь, насквозь подозрительный "не работник УО или ТСЖ". :D Но опасность буду отрицать - я всего лишь программист. По дальнейшему тексту можете догадаться, что работаю муниципальном учреждении, техподдержка при ОМСУ. Да и как вообще провести четкую границу - сотрудники УК тоже не в сферическом вакууме живут и одновременно являются жильцами, а у меня периодически возникает желание создать ТСЖ. :) Свою ГИС тут устроить хотите, а программистов шарахаетесь?
По поводу второго - маловероятно, у нас в организации только я могу направлением интеграции заниматься, у остальных коллег квалификации увы не хватает, так что мне будет сильно напряжно поддерживать внешних клиентов в условиях постоянного изменения шаблонов. Даже если клиенты сами будут шаблоны обновлять, платформу с нуля за 2 месяца будет сложно написать, а потом скорее всего уже все как-то приспособятся вносить данные и продавать будет поздно. Тем не менее для внутренних клиентов платформу наверняка придется делать в следующем году, но пока у меня нет даже полного списка какие именно данные нужны, ждем-с разъяснений министерств. ГИС ЖКХ там лишь одна из кучи ГИС, но если делать платформу, то и ее надо бы прихватить. Учитывая, что я один, даже если я смогу платформу сделать, в плане дальнейшей поддержки мне наверно будет проще организовать покупку у кого-то. Ведь если сделаю, то мне дадут премию один раз, а "головная боль" поддержки будет постоянная.

Небольшое отступление, как я вообще во все это ввязался. Лет пять назад была идея создания РКЦ в городе, УК и РСО города добровольно- принудительно перевели на работу в определенной программе (поделка на Delphi, но видно, что программисты вложили туда много труда, сделана качественно, но современным требованиям "с веб-штучками" уже не соответствует), проплатили полгода поддержки, согласовали данные по площадям квартир, проживающих, но дальше не срослось - зам. мэра по ЖКХ, который был инициатором, стал мэром соседнего города (и там он все-таки сделал РКЦ). Сейчас часть УК перешло на 1С, часть продолжает работать на той программе, данные в той программе передаются в формате Экселя. Это крайне неудобно - по обмену в отдел жилищных субсидий ОМСУ приходит 8 файлов Экселя УК и РСО, причем порядок и набор колонок в них разный (плюс программа выгружает разные услуги в разные колонки), разное написание адреса и т.д. В каждом файле данные примерно по 50 тыс. ЛС, а нужны примерно 2 тыс. получателей субсидию. Вручную открывать 8 страниц и там искать нужное - вариант так себе. В середине года меня попросили все это изучить и "что-нибудь сделать" для автоматизации обмена (ясно, что не за отдельную денюжку).
Первая идея - оживить прошлую программу вполне реализуема, но никаких действий в ней уже пару лет не ведется, перешли на другую программу (точнее новую нам спустили из "губернии", одна радость что бесплатно). По факту получится загрузка Экселя в старую программу, потом ручками по мере надобности в новую. Плюс нужно преобразование для файлов, выгруженных из 1С - порядок колонок не тот. Итого - не очень идея.
Вторая идея - создать базы данных Microsoft Access, программку сливающую данные из Экселевских выгрузок и локальный веб-сайт чтобы упростить поиск. Вполне себе идея, но не избавляет от того, что данные в Экселе и данные указаны на определенную дату.
Третья идея - прикрутить к базам той программы и базам данных 1С переходник, выдающий только нужные данные по запросу в реальном времени в чем-то подобном SOAP или AJAX через локальные сайтики УК/РСО. А у нас соответственно локальный сайтик, запрашивающий оттуда данные и выдающий по итогам запросов сводную печатную табличку по конкретному ЛС. Излишне говорить, что пилить собственный межведомственный обмен, даже упрощенный до AJAX трудозатратно - по детальной расшифровке механизма вышло минимум 14 этапов для асинхронного запроса (а если заморачиваться с официальными аккредитациями, сертификациями и т.д. еще и финансово затратно.. миллионов на несколько). Технически решение тоже нестабильно - отключится интернет у любой УК и уже сводная в реальном времени не получится.
Четвертая идея - если все данные будут в ГИС ЖКХ, то логично организовать обмен с ГИС и вытаскивать оттуда. Собственно, изучая идею, я сюда и попал. Вообще пока похоже, что хотя данные ЛС в ГИС и будут, по факту они будут недоступны.  dash2  С конкретной реализацией пока не спешу, собираю все необходимое - вдруг шаблоны утрясутся, данные станут доступны и все волшебно заработает.   :D А если те самые данные в итоге будут недоступны, то вообще смысл идеи теряется.  :(  Идея загружать начисленные субсидии в ГИС тоже пока висит в воздухе - нужна поддержка со стороны новой программы
Пятая идея - обмен данных по почте - электронной или обычной. Слишком долго из-за ручной обработки запроса на стороне УК (прием 1 человека по нормативам - 15 минут), не подойдет.

Пока с доступом к данным все печально - решил "со стороны гражданина" проверить в ГИС квартиру, в которой живу (муниципальная, основной квартиросъемщик бабушка 85 лет, попытки уговорить сменить на меня заканчиваются истерикой) и опробовать передачу показаний, зашел в свой личный кабинет и... правильно, ничего не увидел. Квартиру по справочнику находит, но потом говорит, что типа в Росреестре меня знать не знают и у меня не прав (вообще без понятия зарегистрированы ли муниципальные квартиры в Росреестре, наверно выписку запрошу). Вот ..., платить значит права есть. Могли бы адрес прописки с Гослуслуг или ФМС подтянуть и сверить. Как-то совсем тупо выходит, если информацию грузить заставляют, а в итоге просмотреть ее нельзя. Молчу про то, что бабушка в Госуслугах не зарегистрирована. Сколько таких бабушек по стране?

[QUOTE]Rembo пишет:
Отправлено спустя 10 минуты 29 секунды:
А мне ГИС начинает нравиться все больше и больше, напоминает игру. Начинаешь играть с 10 жизнями но полным дураком  :) По мере продвижения по джунглям теряешь жизни, залечиваешь раны и укусы животных, но становишься сильнее и мудрее. Кто придет к финишу первым обретет знания вселенной, любовь красавицы и крупный выигрыш[/QUOTE]Как оптимистично все расписали. Простите за пессимизм, но по такой аналогии... в таких играх еще и частенько лимит времени есть. Если не уложиться в заданное время, то выползает неуязвимый монстр и всех сжирает.

Мне нравится, что раздел отдельный, не нужно по разным темам искать были ли ответы.
[QUOTE]AlcorVol пишет:
никогда ни с какими Web-штучками не работал. Не приходилось просто. И до 2017 года - вряд ли успею освоить это дело.[/QUOTE]Если брать нацеленность на конкретный результат это скорее всего так и есть. Два месяца на интеграцию конечно маловато.
В общем случае, XmlHttp наверное одна из самых гениальных идей по доставке данных. Позволяет основной странице (программе, скрипту) остаться именно пустым интерфейсом с набором действий, а все данные загружать дополнительными запросами по HTTP(S) через маленькую вспомогательную страничку (без интерфейса, меню, логотипов - чистая "крокозябра" из данных). Аналогично можно наоборот отправить данные на такую вспомогательную страничку и получить ответ о результате обработки (по сути именно то, что нужно для "интеграции"). Таймаут обычно несколько секунд (можно увеличить при желании), так что результат известен почти сразу. Это я бы сказал "вызывает привыкание" и порой трудно удержаться от использования направо и налево. Если перетаскивать большее количество новостей с сайта на сайт, даже приходится специально вставлять задержки между запросами, чтобы защита от DDOS и роботов не блокировала запросы.
Ещё одна интересная Web-штучка: WebDAV - это расширение HTTP(S), позволяющее изменять файлы на сервере. Можно опубликовать общую папку на веб-сервере, при этом разрешить к ней доступ по WebDAV с паролем, на другом конце мира ввести пароль, подключить как сетевой диск в Windows и работать из любого приложения с этим диском. Для приложения это будет отличаться от локального диска только скоростью работы. По FTP аналогично, но там нужно еще пару шагов сделать. Без WebDAV по "обычному" HTTP(S) тоже возможно подключить сетевой диск, но доступ будет только чтение.
[QUOTE]AlcorVol пишет:
Не думайте обо мне слишком плохо![/QUOTE]Не думаю о Вас плохо, ни в коем разе. Это всегда сложный вопрос - соблюсти баланс между временем затраченным программистом на написание/тестирование, временем обработки действия программой, потребляемыми программой ресурсоами и временем затраченным пользователем на действия вручную.Заметнее всего это на программах которые пишутся для автоматизации собственных действий - пока отлаживаешь программа десятки раз повторяет действия и времени уходит больше, чем на разовое выполнение действий вручную. Тем не менее выигрыш все же есть - программе потом все равно, что запускаешь в полусонном или больном состоянии, а вот с ручным порядком действий в подобной ситуации можно натворить разного. Возвращаясь к соотношению времени, если нужно уложиться в 2 месяца, понятно что ручная загрузка "необходимое зло". А вот без временнОго лимита конечно SOAP привлекательнее в смысле автоматизации.
[QUOTE]AlcorVol пишет:
Да и кто сказал, что SOAP-интерфейс работает без ошибок? Или там в корне иная ситуация?..[/QUOTE]Увы и ах.. Почитал вчера чат, где программисты делятся проблемами интеграции. Похоже SOAP-интерфейс ГИС ЖКХ отвечает гораздо быстрее, но при этом очень велика вероятность, что выдаст в ответ ошибку. Те же самые грабли про "недостаточно прав" актуальны и там, что впрочем и не удивительно - система та же самая, вид сбоку. С обновлениями форматов видимо все еще ужаснее. Даже если вчера запрос проходил без ошибок, никакой гарантии, что этот же запрос пройдет без ошибок сегодня или завтра. В записи семинара для РКЦ слышал, что с 10.х.х.х можно не обновлять форматы, если используемые поля не затронуты при смене версии. Однако похоже, что с этим либо не навели еще порядка либо изменения затрагивают всех.
[QUOTE]AlcorVol пишет:
Как тут можно что-то кому-то "запретить" - мне не совсем понятно. Мои клиенты работают без всяких РКЦ[/QUOTE]А вот так, изначально функции РКЦ просто не было предусмотрено в ГИС ЖКХ, вместо этого РКЦ официально сказали регистрироваться, указывая функцию как информационная система (ИС), под другие функции не подошли. А если они ИС, то им положено работать по SOAP. :) Это прям очень рекомендовали если число лицевых счетов больше тысячи и обсмеяли тех, кто пытается миллион лицевых счетов через Эксель загрузить (в перспективе - ежемесячно). Сам я интерфейс личного кабинета ИС не видел, но вполне можно ожидать, что просто уберут кнопки для загрузки XLSX в личном кабинете при указании функции ИС. То есть вроде как и не запретили, но выбор "широчайший". Сейчас хотят ввести (или даже уже ввели) статус РКЦ отдельно, но похоже там различия будут в сторону увеличения прав для РКЦ по сравнению с ИС, а не увеличения свободы выбора. [QUOTE]AlcorVol пишет:
Надеюсь, штрафов не будет, если XLSX-файлы были сформированы корректно.[/QUOTE]Кто бы еще представил критерий проверки правильности. Не будут же каждый файл отдавать на экспертизу. Надеюсь, не сбудутся предчувствия, что в суровой действительности правильность формирования будут проверять загрузкой в ГИС. :( Если загрузится - скажут "чего раньше не загрузили", если не загрузится - скажут "неправильно сформирован".

[QUOTE]Programmer пишет:
Этим способом я формирую платежный документ, так как после первого способа и импорте выходит ошибка о неверном составе столбцов. Остальные шаблоны пока формируются первым способом.[/QUOTE]Довольно странно, что одно не работает, при работе остального, хотя конечно в такой поэтапной схеме ошибки могут оказаться в любом месте: при подготовке данных для XLSFile, в XLSFile, в конверторе и при обработке. Замечал что OLE-сервер Excel работает гораздо быстрее при обращении из самого Экселя и как черепаха при вызове извне. То есть иногда быстрее работает если написать макрос VBA, подтягивать и подготавливать все данные в Экселе, чем сформировать данные извне и только сохранять через объект Экселя.
[QUOTE]Programmer пишет:
Что касается интеграции, то хотелось бы ее допилить, но в ГИС очень слабая документация на эту тему. Дай Бог, чтобы так работало.[/QUOTE]Нашел чат, где обсуждают проблемы по интеграции.. после получасового чтения думаю, лучше б не находил :shock:

[QUOTE]AlcorVol пишет:
Да, неплохо было бы заставить разработчиков ГИС предоставить какой-нибудь API, который полностью взял бы на себя задачу установления соединения (защищённого) и обмена информацией (XML-файлы). И чтобы работал везде - от Win XP до Win 10.[/QUOTE]Ну, если речь только об обмене информацией по HTTPS, то есть пара идей работающих почти на любой Win: 1) XmlHttp объекты - защищенное соединение устанавливать умеют, куки и прочие заголовки авторизации можно отловить и использовать. Часто использую, чтобы перенести данные с сайта на сайт - при запуске из VBScript нет ограничения к каким доменам соединяться. Вот насчет ГОСТа и ЕСИА не пробовал, но войти на ГИС программно и загружать прямо в личный кабинет - звучит неплохо, хотя конечно не спaсает от XLSX; 2) OpenSSL - с версии 1.0.0 поддерживает ГОСТ встроенно (то есть работает без отдельного установленного криптопровайдера) и еще можно подключить библиотеки для поддержки ГОСТ через криптопровайдера (если установлен) плюс работает не только на Windows и API используется очень широко. Глобальный минус в том, что сертификаты и ключи нужно конвертировать в другой формат. В общем, есть над чем подумать.
[QUOTE]AlcorVol пишет:
У меня ситуация вот какая. Я - независимый ИП-программист. По моей программе работают несколько УК и много ТСЖ. В штате ни у кого не состою. Внедрение обеспечивает супруга, которая также ведёт сама несколько ТСЖ. Так что, в ЛК [B][I]сам[/I][/B] не работаю :) Если что надо - жену прошу посмотреть. Вот, говорит, что и у неё сообщение выскакивает. Но работать можно.[/QUOTE]Спасибо за информацию, впечатление такое, что там технически невозможно ГОСТ использовать, но, кажется у кого-то сообщения не выскакивает (на Win8+). Да, теперь мне стало понятнее, почему хотите грузить XML вручную - загружать будут другие. :)

[QUOTE]AlcorVol пишет:
[QUOTE]two_oceans пишет:
Мысль конечно очень интересная, но в чем тогда автоматизация?[/QUOTE]В том, что все файлы я могу [U]из своей программы[/U] автоматом сформировать. И ответные файлы в ней же проанализировать.[/QUOTE] Возможно в Вашем случае это имеет смысл, частичная автоматизация несомненно лучше чем никакой. Я вот тоже "самоделкин", но в глобальном плане если бы было единое решение, это сэкономило бы кучу наших человеко-часов на более полезные разработки.
[QUOTE]AlcorVol пишет:
Пусть разработчики как угодно общение из личного кабинета с ГИС ЖКХ организуют. Это их проблемы. Сейчас ведь как-то шифруют и XLSX-файлы туда-сюда пересылают? Вот, пусть сами и занимаются всеми этими "обёртками" и протоколами.  :)[/QUOTE]Относительно обмена информацией между личным кабинетом и ГИС соглашусь - не наши проблемы. А так, мне постоянно при входе в личный кабинет выдает предупреждение про ФСБ, что шифрование не ГОСТу. Уже вроде бы все по инструкции сделал, никак победить не могу. Как бы где-то не аукнулось. У Вас как в этом плане, выдает сообщение?
[QUOTE]AlcorVol пишет:
У меня отдельная платёжка - для [U]группы услуг[/U] (в общем случае). Например, для Водоканала - вода и водоотведение. Разве такая уж редкая ситуация? Как тут быть?..
А то, что невозможно по дому (и даже квартире) сопоставить один и тот же "Ид.Услуги" получателю платежа (договору) - это лишний раз показывает, до какой степени сыра концепция ГИС ЖКХ... Дополнительный кошмар. Не система, а д...мо какое-то.   :shock:[/QUOTE]Согласен, сырая система. Непонятно почему вообще ушли от закрепления цифры за определенным видом услуг, ну или было бы логичнее первая цифра вид услуги, еще 2 порядковый номер. Как быть - не готов ответить :)
[QUOTE]AlcorVol пишет:
Было бы совсем замечательно, если бы сюда и разработчики ГИС ЖКХ подтянулись.[/QUOTE]Не так давно искал информацию в интернете по ГИС, на банкирском [URL=http://bankir.ru/dom/forum/%D0%B4%D0%B5%D0%BF%D0%B0%D1%80%D1%82%D0%B0%D0%B­C%D0%B5%D0%BD%D1%82-%D1%82%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D0%B9­/%D0%B0%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D0%B7%D0%B­0%D1%86%D0%B8%D1%8F/74723-%D1%83%D0%BD%D0%B8%D1%84%D0%BE-%D0%B3%D0%B8%D1%81-%D0%B3%D0%BC%D0%BF]форуме[/URL] увидел сообщения директора iDSystems, [URL=http://id-sys.ru/novosti/vse-novosti.html]почитал[/URL] подробнее, в новостях апреля 2016 "iDSystems, как участник рабочей группы Минкомсвязи и ЦБ, а также пилотного проекта...". Люди явно приближенные к разработчикам ГИС ЖКХ (а еще у них в предложении для банков видел платформу именно для отправки сообщений по СМЭВ). У банкиров директор, в основном про следующие версии ГИС ГМП рассказывает, но и про ГИС ЖКХ (правда с точки зрения банков) информация проскальзывала.

[quote:21ey3vr1]Вспомним, что XML-файлы - это стандартный формат для подачи сведений в налоговую инспекцию и ПФР.[/quote:21ey3vr1]Собственно, SOAP тоже "сильно похож" на XML. Если Вы уже можете выгрузить в XML, то там и до SOAP рукой подать - нужна "платформа" для дополнительной обертки, подписания и отправки. Может быть, тогда всем миром напишем петицию, чтобы какое-нибудь министерство купило права на такую платформу и нам предоставило ее бесплатно (или выбор: кто сможет сам настроить - бесплатно, кто не сможет для тех консультация за денюжку)?

Или Вы предлагаете выгружать XML и загружать вручную как сейчас загружают шаблоны? Мысль конечно очень интересная, но в чем тогда автоматизация? А если убрать ручной этап, то всё равно потребуется некий "почтовый формат" обертки с указанием отправителя, получателя, что за файл, какая версия формата, шифрованием и ЭЦП по ГОСТ и т.д. = по сути то же самое, что в сейчас через SOAP. Маловероятно, что удастся убедить идеологов ГИС ЖКХ реализовать 2 похожих формата.
[quote:21ey3vr1]Изучаю сейчас всякие средства (API) для работы с XLSX-файлами из программы. Иначе - просто непонятно, как процесс автоматизировать.[/quote:21ey3vr1]Если имеется ввиду API самого Экселя, то с ним лучше всего работать из... Экселя через встроенный VBA. Если обращаться откуда-то извне как к ActiveX объекту приложения (даже из VBScript), то Эксель начинает сильно грузить процессор. Если у Вас хранится информация в какой-либо базе данных, то ее можно вытащить в Эксель через ODBC (при необходимости установить драйвер и добавить имя для источника) - либо средствами самого Экселя либо опять же через VBA (ADODB.Connection).

[SIZE=85px][COLOR=greenpt]Отправлено спустя 8 минуты 50 секунды:[/COLOR][/SIZE]
[QUOTE]AlcorVol пишет:
Скорее всего, мне тут подойдёт трактовка этих "-nn" как идентификатора платёжного документа. Но нужно будет посмотреть на практике, что получится.[/QUOTE]Можно и так интерпретировать, если для каждой услуги отдельная платежка. Только не забудьте, что у одной и той же услуги может быть разный nn в разных квартирах одного дома (у кого-то даже в разных комнатах), не говоря уж о разных домах.