Форум

Давайте рассмотрим схемы размещения информации в ГИС ЖКХ с точки зрения небольших управляющих организаций (малые УК и ТСЖ), которых по России - многие тысячи. Они обычно не стремятся идти ни в какие РКЦ, а предпочитают использовать собственные (или недорогие сторонние) программы учёта и расчётов в сфере ЖКХ. Что им предлагается? Во-первых, ручной ввод информации в ЛК. Понятно, что таким способом можно занести дома, договора и - с неслабыми усилиями! - даже лицевые счета. Но ежемесячная загрузка показаний приборов учёта и ПД таким способом уже практически невозможна. Напоминает скорее изощрённое издевательство.

Второй способ - заполнять XLSX-шаблоны и загружать их в ЛК. Тоже нехорошо! Во-первых, потому что во всех инструкциях говорится, что на компьютере должен быть непременно установлен MS Office (Excel). Не какой-нибудь там бесплатный Libre Office, заметим, а платный продукт корпорации Microsoft! Во-первых, это не совсем патриотично. А во-вторых, платные решения тут вообще выглядят странно. Мы платим налоги в бюджет, бюджет выделяет миллиарды на ГИС ЖКХ, а его разработчики предлагают нам заплатить ещё-что-то из своего кармана заокеанской фирме. Ну, как это вам, господа?.. По-моему, нашими налогами уже заранее всё оплачено, не так ли?

Далее. В принципе, можно было бы организовать автоматическое заполнение шаблонов из расчётной программы. Спрашивается: почему разработчики ГИС ЖКХ не предлагают таких общедоступных программных средств? Техподдержка упорно повторяет, что заполнять нужно всё только в MS Excel руками - и никак иначе! И в этом - ещё одна странность. Предположим, однако, что мы с этой проблемой как-то справились и заполнили XLSX-файлы по шаблону автоматически, из программы. Почему они загружаются с такой скоростью, что ответа иногда приходится ждать часами и сутками? Неужели их обработка столь для ГИС ЖКХ трудоёмка? Если так, то почему вообще был выбран такой странный, громоздкий формат данных, как XLSX? Да, он подходит для ручного заполнения, но для автоматического - как-то не очень годится...

Разработчики тут же вам ответят: используйте интеграцию через Web-сервисы, по протоколу SOAP! (Там у них почему-то всё быстро работает.) Но - извините! - для этого каждой управляющей организации нужно не просто разработать или купить программу, которая реализовала бы такое взаимодействие. Каждая УО должна будет ещё и пройти тестирование - и только после этого будет иметь право что-то загружать.

Ну, если не хотите так, - ответят разработчики, - тогда идите на поклон к уже оттестированным коммерческим информационным системам. ОК, спасибо! Круг замкнулся. С нас опять хотят деньги. И не только эти деньги. Придётся обсуждать с коммерческой ИС форматы выгрузки данных и протоколы обмена этой информацией, а также реализовать эти форматы и протоколы в собственной расчётной программе.

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

- Не отменяя Web-сервисов, организовать обмен аналогичной информацией в рамках личного кабинета УО. Можно "зашить" SOAP-протокол прямо в личный кабинет, а можно и как-то иначе сделать - лишь бы сама информация была того же формата, что и в SOAP-протоколе (XML-файлы). Все ответы ГИС ЖКХ - также в формате XML.

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

Формирование и анализ ответных XML-файлов - это задача на порядок более простая, чем программная обработка (официально не одобряемая, вдобавок) файлов формата XLSX. Сформировать XML-файл в программе и проанализировать XML-ответ - с этим справится практически любой программист. Больших финансовых затрат со стороны УО в этом случае не предвидится. (Возможно, это как раз и противоречит основной идее, легшей в основу концепции разработчиков.)

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

И совсем не случайно я везде пишу про деньги. Основная проблема сферы ЖКХ - это рост тарифов и неплатежи населения (а вовсе не пресловутые оффшоры, куда якобы УО переводят наши с вами рубли-копейки). Если внедрение ГИС ЖКХ наложит на УО существенные дополнительные расходы, ситуация только усугубится, так как население будет вынуждено оплачивать и их. Любые предлагаемые решения должны быть недорогими, а в идеале - бесплатными, так как разработка ГИС ЖКХ была уже оплачена из бюджета, формируемого нами. А пока - ситуация плачевна. Многие УК уже успели набрать дополнительный персонал, отвечающий исключительно за ввод данных в ГИС ЖКХ. За что боролись-то?.. Разве это было главной целью?

P.S. ----------------------------------------------------------------
Кстати, хочу слегка дополнить свои предложения. Кроме решения, когда все протоколы инкапсулируются в ЛК, могут существовать ещё по меньшей мере два варианта решений:

- Самостоятельное интерактивное приложение для загрузки XML-файлов. Бесплатное и общедоступное, разумеется.

- Столь же общедоступная DLL-библиотека для работы с ГИС ЖКХ, берущая на себя все заботы по организации информационного обмена и криптозащите.

P.P.S. ---------------------------------------------------------------
Ещё маленькое уточнение. Говоря о том, что "информация должна быть того же формата, что и в SOAP-протоколе", я имел в виду, конечно, только сам формат (XML), а вовсе не содержимое. Содержимое XML-файла в данном случае должно (на содержательном уровне, а не буквально) соответствовать содержимому заполненных XLSX-шаблонов, а вовсе не "структуре электронных сообщений в формате XML" для Web-сервисов ГИС ЖКХ.
----------------------------------------------------------------------

Куда пишем

В Космос! Представителям разумных цивилизаций. Хотя, есть слухи, что разработчики сюда тоже заглядывают. Я уже писал им на integration@dom.gosuslugi.ru, в июне. Ни ответа, ни привета. Надеюсь, что здесь действеннее получится - за счёт большей публичности.
----------------------------------------------------------------------------------------------------------
Кстати, хочу слегка дополнить свои предложения. Кроме решения, когда все протоколы инкапсулируются в ЛК, могут существовать ещё по меньшей мере два варианта решений:

- Самостоятельное интерактивное приложение для загрузки XML-файлов. Бесплатное и общедоступное, разумеется.

- Столь же общедоступная DLL-библиотека для работы с ГИС ЖКХ, берущая на себя все заботы по организации информационного обмена и криптозащите.

В техподдержке не сидят разработчики - поэтому и говорят всякую чушь. Я заполняю шаблоны программно. Кста, нужно попробовать заполнение в Libre.
По поводу скорости. Начал грузить ПД с августа. Дома по 60/90 квартир. Время загрузки одного файла занимало не более 2 минут. Правда, сейчас - отдельная песня. Вчера грузил октябрь, обработка полного файла выдала любимую системную ошибку. Порезал на куски по 10 ЛС. Всё загрузилось, каждый кусок грузился секунд 30. Так что тут дело уже не в формате, а в том, что ВСЯ ГИС последний месяц (а может и больше) работает, мягко говоря, нестабильно.
Мне кажется, что они рассматривали загрузку шаблонами как временное решение, и теперь сами дико удивляются, почему многие желают пользоваться только шаблонами.

Честно, Вы пишите очень много страшных слов Вы их разложите по полочкам, а уж массовость отправки, мы гарантируем в любом направление

На то программистский раздел и создан, чтобы "страшные слова" писать. А если Вы отправите мои предложения (с дополнениями) куда следует, то буду Вам премного благодарен. Можно разработчикам, можно во всякие министерства, имеющие отношение к ЖКХ, можно Медведеву и Путину. (В ЕС и ООН, пожалуй, не стоит.)

Точный текст, пожалуйста. Откуда начинать копировать, не совсем понятно и начинаем флешмоб

Какими средствами? В какой среде программируете?
Спасибо, ценная инфо. Загружались ПД? Правильно ли я понимаю, что если в доме 200 квартир, то загружать нужно 20-тью кусками?..
Ну, разумеется, так и есть! Сильно подозреваю, что тайной целью было сделать большинство УО рабами коммерческих ИС.

Отправлено спустя 7 минуты 40 секунды:
Точный текст - это всё сообщение целиком (дополнения я уже приписал). Там - ни убавить, ни прибавить. Если кому-то что-то где-то непонятно будет, то ничего страшного. Вполне понятных мест достаточно, чтобы врубиться в суть. Правда, я сомневаюсь уже в необходимости флэш-мобов (не любят наши власти никаких "информационных атак"). Давайте подождём немного. Вдруг какая-то реакция и без этого последует. (Можно просто продублировать вышеперечисленным адресатам, если есть такая возможность.)

С точки зрения лично моей профессиональной деятельности, AlcorVol изложил все ОЧЕНЬ КРАСИВО! А тем, кто не очень понимает, о чем идет речь, скажу - если все это внедрят, то нам будет значительно легче (и приятней) работать с ГИС. Но кто это будет внедрять? Разработчики из ЛАНИТА, которые, мягко говоря, не очень компетентны в этих вопросах, которые кроме XLSX ничего не знают? Даже если предложение AlcorVol дойдет до адресата, толку от этого, скорее всего, не будет.

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

Как и Вы, пишу на фоксе.
Да, ПД. У меня не было сильного желания экспериментировать, да и ситуация когда-то должна исправиться (август и сентябрь по всем домам загружались с первого раза одним файлом). После первой неудачной попытки попробовал 15 ЛС - не загрузились, после этого порезал по 10.

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

Если кому интересно. Разрабатываю программы в среде Delphi с использованием BDE. "Веб - штучки" реализовываю с помощью библиотеки SYNAPSE . Формирование XLS - библиотека XLSFIle (75000 ячеек в "чистую" секунду; при выборке из баз, конечно, медленнее, но скорость все равно приличная.) с последующей ONLINE - конвертацией в XLSX. Платежный документ после такой конвертации не заливается. Для платежного документа компонентами Delphi сразу в XLSX. Скорость чуть быстрей черепашьей. В данный момент пытаюсь изучить SOAP, но не знаю, с чего начать.

Прекрасный повод перейти на "ты"! Но до получения согласия воздержусь.
Интересно, использовали ли тот же проект (https://vfpx.codeplex.com/wikipage?title=XLSXWorkbook), что и я осваиваю сейчас?
Спасибо, понял.
Согласен на 100%! Причём, мне кажется, что реализовать всё это им - почти ничего не стОит. Не миллиарды, точно.

ЛЮДИ ДОБРЫЕ! Правильно ли я понимаю, что в XML в случае с ГИС - содержится та же информация (или примерно та же), что и в XLSX - шаблонах. Спасибо!

Еще привлекает CSV своей простотой, низкими трудозатратами и скоростью вывода.

XML-файлы внутри XLSX-файла (который представляет собой ZIP-упакованный каталог с подкаталогами) содержатся. Но формат и смысл их там совершенно другой, отличный от тех XML-файлов, которые передаются по протоколу SOAP в ГИС ЖКХ.

А вот это похоже на XML? (a.xml в a.zip, так как xml сайт не принимает).

Действительно. Могли бы разрабы использовать этот формат. Если с умом продумать иерархию.

Так и вижу работников УК с калькуляторами и листами бумаги, расчерченными в таблицы. Вся страна пользуется MS Office, процентов 99 из них пользуются крякнутым офисом. Давайте напугаем народ оупенофисом до кучи. Ну, чтобы бесплатно и патриотично, можно госзакупку на корвалол сделать, чтобы по два пузырька на МКД выдавать бесплатно.


Даешь штатного программиста в каждую УК и каждое ТСЖ!
Ура, товарищи!

Отправлено спустя 10 минуты 19 секунды:
Про разметку интересуетесь или про содержание?

Про разметку. Содержание накипело в процессе смены версий шаблонов ГИСом.

Самый что ни на есть натуральный хml.

Не вопрос.
Нет, я по старинке: createobject('excel.application')
А с этим проектом скорее всего не получится. Я его попробовал: открыл шаблон ПД, заполнил одну ячейку и сохранил. После этого данный шаблон в excel открывается с ошибками.

Они всё уже продумали. Формат XML уже используется в SOAP-протоколе.

Эх! Знать бы как это все оформить. Где, конкретно, прочитать об этом? Я работаю в УК с FTP, POP, SMTP, IMAP, работал успешно с GET и PUT запросами. А SOAP - это совершенно другое, новое для меня, и освою ли я это...

ЛК -> Регламенты и инструкции -> Взаимодействие с внешними системами ->
Регламент и форматы информационного взаимодействия внешних информационных систем с ГИС ЖКХ
Если GET/PUT освоили, то и тут справитесь.

Отправлено спустя 18 минуты 15 секунды:
Min6666, для юмора и флуда на форуме специальные разделы есть. Корвалол с валидолом мне не требуются, спасибо. Очень жаль, что Вы не врубились в суть обсуждаемого предмета.
Просто для примера: я программист, но в штате никаких УК/ТСЖ не состою. Тем не менее, по моей программе работают несколько УК, пара десятков ТСЖ, а также небольшой расчётный центр - со своими УК и ТСЖ. Стараюсь программировать так, чтобы свои программисты в штате УО как раз не требовались.
(Это не реклама, а просто информация. И вообще, мои интересы не простираются дальше Вологды и окрестностей. Более того: клиентов уже такое количество, что новые как-то даже не очень радуют. Работы хватает.)

Если Вам очень захочется продолжить обсуждение в стиле тролля, то очень попросил бы Вас перенести разговор в раздел ФЛУД - viewforum.php?f=64. Если будет время, то отвечу там.

Отправлено спустя 19 минуты 48 секунды:
Это печально. Я как раз писать ещё не пробовал. Но читается всё хорошо. Пригодится хотя бы для того, чтобы всякие ИДы домов и помещений к себе скачать и в БД проставить.

Добавил в свои предложения ещё P.P.S.:
---------------------------------------------------------------
Ещё маленькое уточнение. Говоря о том, что "информация должна быть того же формата, что и в SOAP-протоколе", я имел в виду, конечно, только сам формат (XML), а вовсе не содержимое. Содержимое XML-файла в данном случае должно (на содержательном уровне, а не буквально) соответствовать содержимому заполненных XLSX-шаблонов, а вовсе не "структуре электронных сообщений в формате XML" для Web-сервисов ГИС ЖКХ.
---------------------------------------------------------------

Это чтобы разработчики поняли меня правильно (если, конечно, вообще читать будут).

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

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

Отправлено спустя 47 минуты 26 секунды:
К сожалению, с 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

two_oceans! ОЧЕНЬ ИНТЕРЕСНО, КРАСИВО! Но кто в ГИСе будет этим заниматься. Там ведь люди (в отличии от Вас) не творческие, у них принцип: "работает так (работает ли?) - и ладно" и на фига им эти заморочки.

Отправлено спустя 32 минуты 19 секунды:
У меня есть вот что:
1. Файл
8CAE88BBFD404A7A53630864F9033606E1DC45E2.cer
установлен в "Доверенные корневые центры сертификации".
Выдал: "Головной удостоверяющий центр".

2. Шесть файлов: header.key, maska.key, maska2.key, name.key, primary.key, primary2.key, котрые тупо записаны на флэшку. Я их вижу и могу свобдно копировать. С помощью КриптоПро установлены в "Личное". В диспетчере сертификатов там просматривается фамилия директора УК.

Подскажите, пожалуйста, что с этим дальше делать в части организации SOAP? И нужна ли мне эта флэшка каждый день для работы SOAP, или достаточно установленных сертификатов? Спасибо!

Ну, эта тема и начиналась - а вдруг почитают? Вдруг флешмоб сделаем и подействует волшебным образом. Чем конструктивнее критика, тем больше вероятность что-то изменить. По крайней мере, хотелось бы в это верить.
С другой стороны, чисто для себя привести мысли в порядок и разобрать как "первое приближение" того, что я хочу сделать в итоге. Статьи на хабре про CentOS с намеком на кроссплатформенность, это хорошо, но после прочтения у меня всегда ощущение, что "сварили кашу из топора". Использовали подручные средства, какие только нашли беглым взглядом, и в итоге половина нужны только для приготовления других средств. Хотелось бы выделить необходимый минимум средств и уйти от "в файле конфигурации пишем то-то", "повторяем в следующем", чтобы указав параметр один раз он действовал для всего комплекса, а не просто для конкретной утилиты. Вместе с тем, как-то автоматизировать обновление шаблонов, чтобы не пришлось все менять на каждой версии. Кстати про шаблоны, меня реально раздражает, когда в примере SOAP для ГИС сначала скажем идет тег с ns2: потом в него вложен ns12: в него ns6: Уж с порядком вложения могли бы изначально определиться.

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

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

Далее надо организовать тестовые стенды, настроить канал, и пробовать формировать запросы. В документации это все описано. При работе с SOAP ключ(флешка) нужен практически всегда (за исключением ряда запросов, которые можно отправлять без подписи). Для тестирования желательно сформировать тестовые ключи( хотя никто не запрещает тестироваться на "боевых")

portal-gkh! А сертификаты я установил правильно? И еще. Почему у меня видны на флэшке 8 файлов, а у моего коллеги - нет?

К сожалению, мало информации для полного ответа на Ваши вопросы. Если под сертификатом Вы имеете ввиду сертификат ключа Вашего ЮЛ, то он устанавливается в "Personal". Стандартно на флэшке 6 файлов (для контейнера КриптоПро).