two_oceans пишет: В целом поддерживаю. Хотя мне кажется такой упор на ЛК немного излишен. Поясню почему: оставим проблему защиты между ЛК и самой ГИС, чтобы получить доступ в ЛК все также придется устанавливать криптопровайдер и настраивать браузер. <...> Однако в остальном, по предложениям улучшения ЛК только "ЗА".
Возможно, обмен файлами через ЛК - и не самый лучший вариант. Просто он ближе всего к имеющемуся уже варианту с шаблонами. Потому от него и плясал.
Цитата
Второй и третий вариант с моей точки зрения предпочтительней. Второй вариант мне видится так: оффлайн-клиент, который бы принимал заданный тип данных передаваемых данных из заданной папки (несложно понаделать отдельных папок для ЛС, платежек, показаний ПУ...) в формате XML (но вообще можно и DBF CVS преобразовывать). Более точно: перечислял файлы в папках по таймеру, предварительно контролировал корректность данных в файле (что не закинули ЛС в папку ПУ), а дальше скажем сортировал правильные файлы - в папку на отправку, неправильные в папку ошибок. <...>
Ну, это уже не интерактивный вариант, а что-то типа "резидентного монитора": отслеживает содержимое входных папок, обрабатывает, раскидывает по папкам ответы. Тоже довольно симпатично. Пусть это будет вариант (2а).
Цитата
Конечно, можно сделать и интерактивный вариант (то есть вместо автоматического приема XML производить какие-то действия вручную в пользовательском интерфейсе, но тогда придется обучать пользователей).
Ну, будет не сложнее, чем научить работать в ЛК. Особенно, если интерфейс похожим сделать.
Цитата
Есть конечно заморочки по установке всей этой "прелести" на Windows XP - требует dotNet 2.0 с определенным обновлением и установки корневого сертификата Росстата. Да, я тоже думал что установить сертификат минутное дело, пока на одном компьютере не промучился с этим минут 40 - сертификат ставился неизвестно в какое хранилище...
Очень ценное замечание! Конечно же, всё должно работать на всей современной линейке Windows - от XP до 10-ки.
Цитата
Третий вариант - все вышеперечисленное в оффлайн-клиенте можно завязать на функцию в DLL (передавать имя файла для обработки, имя папки для перечисления, собственно данные XML либо ссылку на объект их содержащий), то есть задача в целом сводится к второму варианту. Вызываете функцию, а дальше пошла кипеть работа.
Ну, я имел в виду DLL для посылки информации напрямую в ГИС ЖКХ, но и такой DLL (вариант 3а) тоже неплохо смотрится.
Цитата
P.S. После прочтения ссылки на хабр, я стал получше представлять механику и даже подумывал в отдельной теме разобрать поэтапно что и как бы хотелось от такой платформы (ну или оффлайн-клиента). В частности, хотелось бы наверно добавить установку через интернет - по примеру Контур.Веб-диск - со страницы скачиваешь и ставишь маленькую программку (компонент, дающий права сайту устанавливать любые программы), далее обновляешь страницу и понеслось - анализ, что установлено на компьютере, каких версий, список что нужно дополнительно установить или обновить, убираешь ненужное, нажимаешь кнопку - автоскачивание и установка,перезапуск браузера, результат. Как считаете, нужно отдельной темой или тут продолжить?
Да я думаю, что можно и тут, и в отдельной теме. Хотя всё это и напоминает делёжку шкуры неубитого медведя. С другой стороны, чем больше будет замечаний и встречных предложений - тем лучше. С нами ведь не советовались, когда основные концепции ГИС ЖКХ принимали. Я считаю, что те средства, которые были предоставлены конечному пользователю (УО) - просто безобразны. Ни одна госструктура не вела ещё себя столь нагло. Требуете отчётности - дайте простые, понятные каждому средства её предоставления - какие файлы и какого формата нужно сформировать. И как их отправить. А не интерфейс в виде Web-сервисов. Ввиду сильного подозрения на присутствие тут чьих-то коммерческих интересов, мне кажется, что бодаться разработчики будут до последнего, типа: не хотите сами работать с SOAP - обращайтесь к коммерческим ИС. Но вода камень точит. Будем бодаться и мы.
Цитата
К сожалению, с VFP не работал. Если будут вопросы по Excel.Application - могу подсказать некоторые моменты...
Спасибо!
Отправлено спустя 4 минуты 44 секунды:
Цитата
Programmer пишет: А сертификаты я установил правильно? И еще. Почему у меня видны на флэшке 8 файлов, а у моего коллеги - нет?
Уважаемые господа, давайте не будем смешивать темы! Здесь всё-таки обсуждаются предложения по взаимодействию с ГИС ЖКХ. Не могли бы Вы конкретные вопросы по сертификатам обсудить в отдельной теме? Заранее - спасибо!
С третьей стороны, а ну вдруг как навалимся все вместе и сделаем - посрамим ГИС. Для определения, что нам реально нужно, а что излишество и роскошь. Если сомнения, что сможем.. в конце концов, уже есть бесплатный клиент Росстата, можно расковырять в каком виде хранятся шаблоны для загрузки в него.
Это было бы интересно, конечно. Если бы не одно но. ГИС ЖКХ постоянно меняет версии форматов. Если бы они отвечали сами за сопровождение "умного клиента" на стороне УО, это было бы для конечного пользователя незаметно. А так - придётся каждый раз всё переделывать. Мне кажется, что версии будут меняться ещё много-премного раз.
На вопросы про сертификаты ответил в новой теме: [url:460dd5r0]http://forum.burmistr.ru/viewtopic.php?f=147&t=5548[/url:460dd5r0] Если кратко, как захотите - так и сделаете. Закрытый ключ - это не обязательно флешка. OpenSSL обычно вообще глубоко все равно что стоит в системном хранилище сертификатов. С одной стороны - тоже своего рода проблема, с другой - нет побочных эффектов, как у хранилища "Личные".
Цитата
AlcorVol пишет: ГИС ЖКХ постоянно меняет версии форматов. Если бы они отвечали сами за сопровождение "умного клиента" на стороне УО, это было бы для конечного пользователя незаметно. А так - придётся каждый раз всё переделывать. Мне кажется, что версии будут меняться ещё много-премного раз.
Те же шаблоны Экселя тоже переделывают, от этого никуда не деться, все равно придется реагировать на изменения. Если все спроектировать достаточно умно, с учетом возможных "откровений", то все переделывать не придется. Все-таки в ГИС такие же люди, ничего сверхестественного не придумают. Такая вот битва экстрасенсов. Мне бы хотелось, чтобы автоматика обновления шаблонов смогла проанализировать изменения шаблонов (чтобы из новой версии форматов определить название нового поля, название формата данных в поле и обязательность поля, вывести примечание человеку - не нужно искусственного интеллекта) и предложить какие-то действия "ответственному за шаблоны" (например добавить поле в шаблон или убрать из шаблона), если действий достаточно - кликает ОК и все счастливы , если недостаточно, то звонит программисту и программист что-то чуть подправляет, например добавляет действие или корректирует алгоритм анализа.
Цитата
Ну, я имел в виду DLL для посылки информации напрямую в ГИС ЖКХ, но и такой DLL (вариант 3а) тоже неплохо смотрится.
Согласен, однако я не могу представить 1 мега-супер-ультра DLL, выполняющую все функции сразу. Даже если от клиента отрезать все не связанное с отправкой (например шуршание в папках в 2a) и принимать в DLL ссылку на XML текст, все равно останется много "модулей" с различным назначением. С одной стороны, эти файлы - та самая "каша из топора", с другой - объединять все вместе как-то экстремально - кто его знает, что там другие программисты натворили "внутре". С третьей - в качестве СКЗИ (средство криптографической защиты информации) сертифицируют конкретные бинарные файлы, так что или берем что уже сертифицировано кем-то в составе другого СКЗИ или придется сертифицировать улучшенную DLL как СКЗИ. Без сертификации к нам могут нагрянуть с нежданной проверкой. С учетом возможного распараллеливания отправки имеет смысл написать DLL как "общую" с учетом Thread Locale Storage (TLS), как системные библиотеки Windows - данные каждого потока хранятся в отдельной памяти, но адрес как бы один и тот же. Правда подобрать базовый адрес свободный "от xp до 10" будет непросто. Моя среда программирования "из коробки" TLS увы не поддерживает, сделать наверно можно, но придется долго читать "как" и долго колдовать.
Конечно, можно сделать и интерактивный вариант (то есть вместо автоматического приема XML производить какие-то действия вручную в пользовательском интерфейсе, но тогда придется обучать пользователей).
Ну, будет не сложнее, чем научить работать в ЛК. Особенно, если интерфейс похожим сделать.
Ещё подумал - а ведь если интерфейс похожий, то надо при изменении ЛК менять программу, это однако похуже шаблонов будет. Утром мелькнула идея попробовать для проверки сделать "резидентный монитор" на VBScript + XmlSigned класс, а для интерфейса добавить нечто среднее между нормальной программой и веб-штучками - HTA. Либо сосредоточится на Криптопро + stunnel + DLL (Delphi/Pascal) подписания и отправки + DLL для отчетов (отдельно, чтобы проще заменять, может быть тоже нужно разбить - включая обновление, анализ новой версии, формирование и проверку шаблона), пока без технологии "общей". Конечно, к этому накрутятся всякие конфигурации. Это то, в чем можно получить какие-то результаты в обозримом будущем.
вполне можно было бы обеспечить поддержку не одного формата, а нескольких (XML, DBF, CSV и т.п.) .
Цитата
Причём, мне кажется, что реализовать всё это им - почти ничего не стОит. Не миллиарды, точно.
День работы с перерывом на обед и перекуры
Цитата
min6666 пишет: Вся страна пользуется MS Office, процентов 99 из них пользуются крякнутым офисом. Давайте напугаем народ оупенофисом до кучи.
Это сильное преувеличение. Очень многие пытаются выдерживать лицензионную чистоту. Но дело даже не в этом. Libre вполне себе справляется с открытием и сохранением в xlsx, проблемы только с форматированием (а для обмена информацией форматирование не должно иметь значения), и, разумеется, с макросами (они тоже не нужны). На всю страну требовать использование какого-то конкретного, тем более платного, продукта - абсурд. Общепринятые открытые стандарты и форматы обмена для того и придумываются, чтобы было универсально и максимально удобно для как можно большего числа участников обмена.
Цитата
AlcorVol пишет: Просто для примера: я программист, но в штате никаких УК/ТСЖ не состою. Тем не менее, по моей программе работают несколько УК, пара десятков ТСЖ, а также небольшой расчётный центр - со своими УК и ТСЖ. Стараюсь программировать так, чтобы свои программисты в штате УО как раз не требовались. (Это не реклама, а просто информация. И вообще, мои интересы не простираются дальше Вологды и окрестностей. Более того: клиентов уже такое количество, что новые как-то даже не очень радуют. Работы хватает.)
У меня история та же, только география отличается. И новым людям тоже, наверное, пару лет отказываю.
Колллеги, чем предлжения разработчикам ГИС об изменениях будут дальше от существующих схем, тем меньше вероятность того, что их хотя бы прочитают.
two_oceans пишет: Ещё подумал - а ведь если интерфейс похожий, то надо при изменении ЛК менять программу, это однако похуже шаблонов будет.
Не совсем понял. Я имел в виду самостоятельное интерактивное приложение, интерфейс которого (GUI) по стилю напоминает стиль работы юзера в ЛК. А если будут меняться сами форматы структуры данных (как сейчас шаблоны меняются), то это, конечно, в программе клиента (УО), осуществляющей подготовку XML-файлов, учитывать придётся.
Цитата
Утром мелькнула идея попробовать для проверки сделать "резидентный монитор" на VBScript + XmlSigned класс, а для интерфейса добавить нечто среднее между нормальной программой и веб-штучками - HTA. Либо сосредоточится на Криптопро + stunnel + DLL (Delphi/Pascal) подписания и отправки + DLL для отчетов (отдельно, чтобы проще заменять, может быть тоже нужно разбить - включая обновление, анализ новой версии, формирование и проверку шаблона), пока без технологии "общей". Конечно, к этому накрутятся всякие конфигурации. Это то, в чем можно получить какие-то результаты в обозримом будущем.
Успехов! А я пока продолжу с XLSX-шаблонами ковыряться. Пора бы отложить в сторону писанину на форуме, а заняться делом.
Колллеги, чем предложения разработчикам ГИС об изменениях будут дальше от существующих схем, тем меньше вероятность того, что их хотя бы прочитают.
И поэтому я с самого начала предложил вариант, максимально близкий к действующему: загрузка файлов из ЛК со сменой формата XLSX -> XML (простой, но эквивалентный по содержимому). Образцы для подражания есть: форматы сведений для сдачи отчётности в налоговую и ПФР.
AlcorVol пишет: И поэтому я с самого начала предложил вариант, максимально близкий к действующему: загрузка файлов из ЛК со сменой формата XLSX -> XML.
Ну по чесноку — по-моему, это наименее утопичный вариант. Только не «со сменой формата», а с дополнением. Пытаюсь поставить себя на место разрабов ГИСа. Поскольку xlsx это «усложнённый» xml, то (навскидку) дополнительной работы для его обработки должно быть немного. Опять же, поскольку это универсальный формат, то реализовать его обработку было бы интересно с программерской точки зрения (сужу по себе). Однако отказываться от xls-шаблонов я бы не стал — в случае ручного заполнения данных «блондинкой» (а на них тоже надо ориентироваться), вероятность накосячить в Excel-е меньше.
На всю страну требовать использование какого-то конкретного, тем более платного, продукта - абсурд. Общепринятые открытые стандарты и форматы обмена для того и придумываются, чтобы было универсально и максимально удобно для как можно большего числа участников обмена.
Нужен формат, понятный не только ГИСу, но и пользователям. Решение задачи начинается с изучения исходных данных, а исходные данные таковы, что эксель знают все, кто пользуется ПК. Главная проблема в том, что для начислений используются разные ИС - от самописных до конфиг под 1С от разных разработчиков, эта сфера не стандартизирована. Отсюда невозможность нажатием на кнопку получить понятный ГИСу пакет данных. Загнать всех под одну программу для начислений? Но для этого операторам и расчетчикам придется не только переучиваться, но и переносить все ИБ в новую программу. Это может привести к массовым увольнениям, как во времена подсадки бухгалтеров на 1С увольнялись опытные специалисты.
min6666 пишет: Главная проблема в том, что для начислений используются разные ИС - от самописных до конфиг под 1С от разных разработчиков, эта сфера не стандартизирована. Отсюда невозможность нажатием на кнопку получить понятный ГИСу пакет данных.Загнать всех под одну программу для начислений? <...>
Нет, не так. Не надо всех в одну программу загонять. Достаточно предоставить простой и понятный формат файлов обмена информацией с ГИС ЖКХ. Настолько простой, что практически каждый программист был бы в состоянии такие файлы в любой из используемых расчётных программ быстренько подготовить. И XML тут подходит гораздо больше, чем XLSX. Альтернатива (не совсем удачная и громоздкая): общедоступная бесплатная DLL-библиотека для работы с XLSX-файлами.
Отправлено спустя 2 минуты 42 секунды:
Цитата
andrewk пишет: Однако отказываться от xls-шаблонов я бы не стал — в случае ручного заполнения данных «блондинкой» (а на них тоже надо ориентироваться), вероятность накосячить в Excel-е меньше.
Да, соглашусь. Неаккуратно написал. Не замена, а дополнение.
min6666 пишет: Нужен формат, понятный не только ГИСу, но и пользователям. Решение задачи начинается с изучения исходных данных, а исходные данные таковы, что эксель знают все, кто пользуется ПК.
Не спорю. Только не понимаю, какой из этого ты хочешь сделать вывод. Да, практически все более менее умеют работать в Excel. Но Excel умеет открывать и сохранять xml, csv, ods и с натяжкой dbf. Всё это, в том числе xls, могут открывать и сохранять и другие продукты. Так почему всех вынуждать это делать именно в Excel?
Цитата
min6666 пишет: Главная проблема в том, что для начислений используются разные ИС - от самописных до конфиг под 1С от разных разработчиков, эта сфера не стандартизирована. Отсюда невозможность нажатием на кнопку получить понятный ГИСу пакет данных.
Ну так для этого и публикуются стандарты обмена: форматы файлов, поля, правила заполнения... Это же всё обычная ситуация, сколько раз проходили: обмен с органами соцзащиты, с кучей платёжных агентов... — у всех всё разное, однако договаривались, настраивали, дорабатывали.
Upd: пока я сочинял ответ, то же самое написал AlcorVol постом выше)
Не надо всех в одну программу загонять. Достаточно предоставить простой и понятный формат файлов обмена информацией с ГИС ЖКХ. Настолько простой, что практически каждый программист был бы в состоянии такие файлы в любой из используемых расчётных программ быстренько подготовить. И XML тут подходит гораздо больше, чем XLSX.
Ага. Программист такой написал обработку, а пользователь такой чего-то там накосячил в программе, ГИС не может прочитать и выдает ошибку, пользователь в одномерном массиве, естественно, найти и исправить ошибку не может и начинает процедуру выноса мозга программиста. Не будите лихо.
min6666 пишет: Программист такой написал обработку, а пользователь такой чего-то там накосячил в программе, ГИС не может прочитать и выдает ошибку, пользователь в одномерном массиве, естественно, найти и исправить ошибку не может и начинает процедуру выноса мозга программиста.
Вы, вообще, внимательно все мои предложения читали? Или опять через три строки на четвёртую? Я везде предполагаю, что в ответ ГИС ЖКХ посылает тоже XML-файлы. И программа эти ответы тоже обрабатывает. Если есть диагностики об ошибках - оператор программы это увидит. Если Вам всё, что тут обсуждается, не интересно (или не нравится), то просто держите свой скепсис при себе.
min6666 пишет: Главная проблема в том, что для начислений используются разные ИС - от самописных до конфиг под 1С от разных разработчиков, эта сфера не стандартизирована. Отсюда невозможность нажатием на кнопку получить понятный ГИСу пакет данных. Загнать всех под одну программу для начислений? Но для этого операторам и расчетчикам придется не только переучиваться, но и переносить все ИБ в новую программу. Это может привести к массовым увольнениям, как во времена подсадки бухгалтеров на 1С увольнялись опытные специалисты.
Но согласитесь, как будет удобно, когда появится единый формат. Некий единый информационный стандарт.
Но согласитесь, как будет удобно, когда появится единый формат. Некий единый информационный стандарт.
Удобно, конечно. Маяковский лет сто как тому писал про стандартизацию:
Цитата
Подходи, рабочий! Обсудим, дай-ка, что это за вещь такая гайка? Что гайка?! Ерунда! Малость! А попробуй-ка езжай, ежели сломалась. Без этой вещи, без гайки той — ни взад, ни вперед. Становись и стой! Наконец отыскали гайку эту... Прилаживают... Никакой возможности нету!.. Эта мала, та велика, — словом, не приладишь ее никак. И пошли пешком, как гуляки праздные. Отчего? Оттого, что гайки разные. А если гайки одинаковые ввесть, сломалась — новая сейчас же есть. И нечего долго разыскивать тут: бери любую — хоть эту, хоть ту! И не только в гайке наше счастье. Надо всем машинам одинаковые части, а не то, как теперь — паровоз и паровоз, — один паровозом, а другой, как воз. Если это поймет рабочего разум — к Коммуне на паровозах ринемся разом.
min6666 пишет: Удобно, конечно. Маяковский лет сто как тому писал про стандартизацию:
Опять флуд в этой теме? Ведь просил же Вас уже. Мне что - теперь модератора вежливо кое о чём попросить?.. Козьму Пруткова помните? "Если у тебя есть фонтан, ..."
two_oceans пишет: Ещё подумал - а ведь если интерфейс похожий, то надо при изменении ЛК менять программу, это однако похуже шаблонов будет.
Не совсем понял. Я имел в виду самостоятельное интерактивное приложение, интерфейс которого (GUI) по стилю напоминает стиль работы юзера в ЛК. А если будут меняться сами форматы структуры данных (как сейчас шаблоны меняются), то это, конечно, в программе клиента (УО), осуществляющей подготовку XML-файлов, учитывать придётся.
А я не про форматы, а про то, что они и сайт частенько меняют - перетаскивают форму с одного раздела на другой без всякого предупреждения. То есть периодически придется синхронизировать вид приложения с текущим видом сайта.
Цитата
Успехов! А я пока продолжу с XLSX-шаблонами ковыряться. Пора бы отложить в сторону писанину на форуме, а заняться делом.
Как раз о том же подумал, да и другой работки подкинули. Поэтому сокращаю время на форуме и ищу наметки в Интернете. Вот что вчера нашел: [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. Кроме каноникализации там еще и декларации функций майкрософтовского криптопровайдера - как получить хэш и подпись и чего с ними потом делать.
Цитата
Коллеги, чем предложения разработчикам ГИС об изменениях будут дальше от существующих схем, тем меньше вероятность того, что их хотя бы прочитают.
Согласен, но с другой стороны сколько можно ждать "милости от природы", поэтому наиболее далекие от существующих схем предлагаю сделать совместными усилиями - я вот практически решился написать DLL для подписи XML. Тема достаточно интересная в плане множества других применений XML. Ранее думал, что моего кунг-фу не хватит, но оказалось программисты ФГИС это не придумали, есть международный стандарт - сразу стало легче. Остается вопрос реализовать подписание как в ГИС ЖКХ и остановиться или реализовать формат полностью. В частности, сертификат, можно указывать многими способами. О полном формате нашел вводную статью: [url:3nv6tnms]http://minichden.narod.ru/articles/xmldsig.htm[/url:3nv6tnms]. По этому вопросу - мне нужно будет как-то проверить результат. Пилить в C# только ради проверки нет никакого смысла. Может быть, если у кого есть рабочая схема подписи, я предоставлю "самодельные" тестовые сертификаты и вы ими подпишите несколько файлов?
Цитата
Поскольку xlsx это «усложнённый» xml, то (навскидку) дополнительной работы для его обработки должно быть немного.
Обоснование понятно. Однако, как мне кажется это может иметь обратный эффект: SOAP, это то же XML, так что с ним программисты ГИС уже "наигрались" и реализовывать еще что-то промежуточное между SOAP и XLSX будет слишком похоже, при дополнительной необходимости отражать изменения на еще один формат, и потому не так уж привлекательно. Однако даже если сделают возможность грузить SOAP через ЛК без кучи регистраций в качестве ИС и тестирований, тоже будет достаточно забавно.
Цитата
Да, практически все более менее умеют работать в Excel. Но Excel умеет открывать и сохранять xml, csv, ods и с натяжкой dbf.
Вот честно говоря, насчет xml не уверен, с таким же успехом html можно дополнить в список. Сам формат Эксель конечно умеет открывать и сохранять, но при этом при создании/сохранении файла в Экселе в тегах столько специфичного для Экселя "мусора" - всяческие стили офисного пакета, форматы, формулы и т.д. - что ни одна уважающая себя система не будет этот хлам обрабатывать без дополнительного "очищающего" конвертера. Из-за такого "мусора" в тегах я даже FrontPage давно перестал использовать для редактирования веб-страниц.
Почему бы не сделать так? 1. Из ПО УО формируется банальный TXT такого формата: Реквизит=Значение; Реквизит=Значение; ... Реквизит=Значение@ ЭЦП 2. Из распространяемого для всех желающих бесплатного ПО ГИСа эти файлы выгружаются "туда". В ПО ГИСа должны быть (например) такие настройки: а) "папка на диске пользователя, где хранится МКД", допустим C:\MKD, тогда протоколы импорта будут сохраняться в C:\MKD_PROTO. б) "папка на диске пользователя, где хранится ПУ", допустим C:\PU, тогда протоколы импорта будут сохраняться в C:\PU_PROTO. И т. д...
Почему не CSV? Потому что там порядок вывода значений надо выдерживать, а при таком формате TXT - не надо, да и программисту гораздо проще TXT заполнить таким образом, чем XML.
Попробую ответить "с точки зрения разработчиков ГИС ЖКХ". 1. Протокол SOAP - это всего лишь передача XML-файлов по протоколу HTTP. Всё. Больше там ничего нет. Пример обмена можно посмотреть . Пример использования этого применительно к ГИС ЖКХ - . В этом свете разговоры про "Не надо нам SOAP, дайте нам обычный XML" - вызывают некоторое недоумение. Желание передавать SOAP-запросы по HTTP не напрямую, а через личный кабинет, который работает через тот же HTTP - вызывает ещё большее недоумение, когда оно возникает у программиста (а для остальных есть XSLT). 2. Идея о том, что "Всю криптозащиту информации в процессе взаимодействия с ГИС ЖКХ должен взять на себя ЛК" - неудачная. Дело в том, что при входе в личный кабинет стороны (Алиса и Боб) устанавливают защищенный канал связи, но у этого канала есть важный недостаток: Алиса не может доказать третьим лицам (суду, например), что получила от Боба какую-то информацию. Чтобы Алиса могла это доказать, Боб должен подписать информацию своим приватным ключом, а приватный ключ, разумеется, должен оставаться на компьютере Боба, на то он и приватный. 3. Идея про "Дайте нам свою DLL, дальше мы как-нибудь сами" - это отговорки. Протокол SOAP - открытый. И вот с этой точки - пожалуйста, сами, если можете. А если не можете, то и говорить не о чем. А DLL - это очень, очень плохая идея: [*:2unhxjve]Непонятная DLL, работающая с криптографией и имеющая доступ к приватным ключам - это не безопасно.[/*:m:2unhxjve] [*:2unhxjve]DLL привязывает нас к платформе Windows.[/*:m:2unhxjve] [*:2unhxjve]Интерфейс, предоставляемый DLL - это чистый C. Даже не C++. Работать с ним из современных языков программирования неудобно.[/*:m:2unhxjve] [*:2unhxjve]DLL выполняется в адресном пространстве чужого процесса. Если в результате процесс падает, не всегда понятно, по чьей вине это произошло. Нет внятного разграничения зон ответственности.[/*:m:2unhxjve] [*:2unhxjve]В DLL наверняка были бы ошибки. Распространение DLL с исправлениями этих ошибок - задача нетривиальная.[/*:m:2unhxjve] 4. Идея о том, что каждая УК должна иметь своё решение по взаимодействию с ГИС ЖКХ, мне совершенно не близка. Она напоминает девяностые годы, когда каждая компания писала свою бухгалтерию. А потом пришла 1С, и все поняли, что бухгалтерию дешевле купить, чем делать самим. То же самое, на мой взгляд, должно произойти и в сфере ЖКХ: разработкой софта должны заниматься специализирующиеся на этом компании, а УК должны управлять домами. 5. Один из примеров реальных проблем с ГИС ЖКХ - то, что сплошь и рядом один дом (с одним почтовым адресом, сквозной нумерацией квартир и т.п.) числится в Росреестре (а значит, и в ГИС ЖКХ) как несколько зданий. Этим следовало бы заняться ещё вчера, и никакой XSLT этому не мешает.
Programmer пишет: Почему бы не сделать так? 1. Из ПО УО формируется банальный TXT такого формата: Реквизит=Значение; Реквизит=Значение; ... Реквизит=Значение@ ЭЦП
Преимущество формата XML - в том, что он стандартный. А к тому, что написали Вы, сразу возникает куча вопросов, на которые нет готовых ответов: 1. Как быть, если Значение содержит точку с запятой, кавычки, символ равенства, перевод строки? 2. В какой кодировке должен быть этот TXT? Допустим ли Byte Order Mark в начале? 3. В каком виде должна быть ЭЦП? Как она должна отделяться от данных? 4. Как быть, если нужно работать со структурированной информацией? Ну, например, реквизит "адрес" состоит из названия улицы, номера дома и номера квартиры. 5. Как быть, если нужно передать не один объект, а массив?
Цитата
Programmer пишет: 2. Из распространяемого для всех желающих бесплатного ПО ГИСа эти файлы выгружаются "туда".
Почему Вы считаете, что это ПО кто-то должен разработать для Вас _бесплатно_? А бесплатное ПО бухучёта Вам, случайно, не нужно? Нет, я понимаю, что неплохо было бы, чтобы оно было, но сразу возникнут вопросы: - А почему только под Windows? - А почему с Win95 не работает? - А почему такой кривой формат исходных данных, хочу CSV/XML/OOXML/OpenXML/DBF? - А почему интерфейс такой корявый?
К бесплатному часто предъявляют такие требования. С платным софтом проще: любой каприз за Ваши деньги.
Sergey Cheban пишет: Почему Вы считаете, что это ПО кто-то должен разработать для Вас _бесплатно_? А бесплатное ПО бухучёта Вам, случайно, не нужно?
Оно то конечно в целом правильно.. Но вот, к примеру, ФНС уже лет 15 разрабатывает бесплатное ПО для заполнения налоговых деклараций. Или Росстат бесплатно принимает статотчётность через свой сайт сбора. А могли бы и денюшку за всё это попросить.
Sergey Cheban пишет: Попробую ответить "с точки зрения разработчиков ГИС ЖКХ". Протокол SOAP - это всего лишь передача XML-файлов по протоколу HTTP. Всё. Больше там ничего нет. В этом свете разговоры про "Не надо нам SOAP, дайте нам обычный XML" - вызывают некоторое недоумение.
Прежде всего, спасибо за оппонирование! А то здесь только "несогласные" (с ГИС ЖКХ) собрались. Просто даже спорить не с кем. И вот - появился хоть один, кто "согласен". Некоторое недоумение, однако, вызывает у меня тот факт, что Вы путаете вопросы. Давайте разделим проблемы:
(а) Формат данных; (б) Их передача.
По поводу (а). Формат XLSX не предназначен, вообще говоря, для автоматизированного (не ручного) заполнения. И это очень плохо. Сформировать эквивалентный по содержимому XML-файл из программы намного проще. (Подозреваю, что эта задача по силам даже многим старшеклассникам, интересующимся программированием.) Если Вы программист - не можете с этим не согласиться. Никто не предлагает "заменить SOAP на XML". Не надо смешивать (а) и (б)!
По поводу (б). Если из ЛК допускается загружать XLSX-файлы, то почему нельзя столь же безопасным и защищённым образом загружать файлы других форматов, самый близкий из которых "по духу" - это XML? Вы можете внятно ответить на этот вопрос? Если бы это было реализовано, то для УО всё было бы намного проще. Ввиду того, что ЛК уже априори считается как бы "сертифицированным объектом", отпадает куча проблем (необходимость испытаний на стенде и т.д.) Необходимость наличия у оператора ЛК ЭЦП (если надо - усиленной, квалифицированной) никто под сомнение не ставит.
Разумеется, все форматы загружаемых (и получаемых в ответ) файлов должны быть описаны. Тут проблем не вижу никаких.
Цитата
Sergey Cheban пишет: Идея о том, что каждая УК должна иметь своё решение по взаимодействию с ГИС ЖКХ, мне совершенно не близка.
Вам - не близка, но многим здесь близка. И совершенно не обязательно от каждой УО требовать наличия своего ПО. Один программист (или небольшая фирма) в состоянии предоставить такое ПО многим УК/ТСЖ. Сейчас на рынке присутствуют множество разработчиков, по программам которых УО работают. Вопрос лишь в некоторых доработках для ГИС ЖКХ.
Цитата
Sergey Cheban пишет: Почему Вы считаете, что это ПО кто-то должен разработать для Вас _бесплатно_?
Если у УК уже есть какое-то ПО в сфере ЖКХ, то доработки (в случае простого формата файлов обмена) будут или недорогими, или вообще не принесут дополнительных накладных расходов - в случае наличия соответствующего долговременного договора о сопровождении ПО. Включение в процесс обмена информацией с ГИС ЖКХ специальных агентов по занесению информации (коммерческих ИС) значительно сей процесс усложняет и удорожает. И к тому же, с ними тоже как-то обмениваться информацией надо. А это тоже - форматы, протоколы, формирование файлов, анализ ответов и т.д. и т.п. Получается для программиста почти то же самое, но вовлекается коммерческий посредник. Только и всего.
И ещё. Никто не требует, чтобы бухгалтерские программы были бесплатными. Это нонсенс. Точно так же, не бывает бесплатных программ в сфере ЖКХ для УО. Но здесь - с нас пытаются взять деньги за сам процесс размещения информации, практически не предоставляя бесплатной альтернативы. Поясню на понятном примере, бухгалтерском. Государство требует от компаний сдачи некоторых сведений (формы налоговой отчётности, отчётность в ПФР и другие фонды). Заметим, что формат этих сведений - как раз XML. И в каждой программе бухучёта формирование таких файлов предусмотрено. Есть фирмы-посредники, которые на коммерческой основе помогут вам загрузить эти сведения в соответствующие государственные информационные системы. Но у бухгалтера тут есть выбор! Он может просто сбросить XML-файлы на флэшку - и лично явиться в налоговую или ПФР. Кроме того, вы можете сдать отчётность в ФНС в личном кабинете налогоплательщика, никуда не ходя! Смотрите, к примеру, здесь:
Почему ФНС не усматривает никаких сложностей с загрузкой отчётности в ЛК (при наличии усиленной КЭП)? Почему трудности возникают только у суперквалифицированных разработчиков ГИС ЖКХ?..
Короче говоря, если государство от кого-то требует какой-то отчётности, то оно должно позаботиться о простоте и удобстве предоставления сведений. Существует ли такая простая альтернатива для ГИС ЖКХ? И если нет, то по какой, спрашивается, причине?.. Короче, куда тут ни ткни - везде просматривается неявное желание принудительно отправить УО прямиком в лапы посредника. Что не может не вызвать совершенно оправданных вопросов, недоумения и даже возмущения.
Хотя Вы как-то высказывались в пользу разрабов, но "суперквалифицированных" надо писать в кавычках.
Отправлено спустя 2 минуты 49 секунды:
Цитата
AlcorVol пишет: Короче, куда тут ни ткни - везде просматривается неявное желание принудительно отправить УО прямиком в лапы посредника. Что не может не вызвать совершенно оправданных вопросов, недоумения и даже возмущения.
Полностью с Вами согласен! Да и требование к MS слишком у них завышены, в доле, скорее всего.
Programmer пишет: Да и требование к MS слишком у них завышены, в доле, скорее всего.
Ну, я бы - без наличия сведений о "долевом участии" - не стал бы никого заранее тут обвинять. Я обвиняю разработчиков ГИС ЖКХ лишь в том, что они выбрали формат для загрузки файлов в ГИС, очень мало подходящий для автоматизированного заполнения. Что как бы "намекает".
AlcorVol пишет: Я обвиняю разработчиков ГИС ЖКХ лишь в том
Не смог удержаться, вставлю свои 2 коп. Вот мы с тобой всё в одном - и заказчик и постановщик и кодер. А там - команда. И обвинять всех скопом имхо неправильно. Я б, например, обвинял конкретно товарища Горбунова.
Basil пишет: И обвинять всех скопом имхо неправильно. Я б, например, обвинял конкретно товарища Горбунова.
Никого там по имени не знаю. И кто за что отвечает - мне тоже не очень интересно. Для меня это именно команда. Мне безразлично, кто проектные решения принимал. Но я вижу, что они - крайне неудобны для меня и моих УО. Пусть разбираются внутри сами. Государство - как "генеральный заказчик" - здесь просто обязано порядок навести. Если, конечно, действительно хочет какие-то сведения в ГИС получить.
Sergey Cheban пишет: Почему Вы считаете, что это ПО кто-то должен разработать для Вас _бесплатно_?
Потому, что это надо им, а не мне.
Надо это - жильцам, которые платят деньги УК, а не государству (государству они, впрочем, тоже платят налоги, но за поддержание порядка, а не за формирование квитанций).
Почему жильцам это надо? Фактически, эту потребность создали сами же УК: не все, но многие из них в управлении домом проявляют, хм, творческий подход. То оказываемую услугу как-нибудь не так назовут, то с метражом ошибутся, то тарифы начнут произвольно менять, то документы на управление домом не в порядке окажутся, то ОСС нарисуют, то платёж потеряют,то ещё что-нибудь. Ну вот вам, УК, от государства компьютер, который проверяет корректность вашего творчества. И вполне естественно, что этот компьютер заканчивается там, где начинается сеть.
Sergey Cheban пишет: Почему Вы считаете, что это ПО кто-то должен разработать для Вас _бесплатно_? А бесплатное ПО бухучёта Вам, случайно, не нужно?
Оно то конечно в целом правильно.. Но вот, к примеру, ФНС уже лет 15 разрабатывает бесплатное ПО для заполнения налоговых деклараций. Или Росстат бесплатно принимает статотчётность через свой сайт сбора. А могли бы и денюшку за всё это попросить.
На мой взгляд, государство _обязано_ бесплатно предоставить удобный открытый интерфейс к своим сервисам. Всё остальное - опционально. ФНС, конечно, молодцы, что дают бесплатное ПО, но это вовсе не их обязанность. А вот личные кабинеты на сайте - это то, что ведомства делать должны.
По поводу (а). Формат XLSX не предназначен, вообще говоря, для автоматизированного (не ручного) заполнения. И это очень плохо. Сформировать эквивалентный по содержимому XML-файл из программы намного проще. (Подозреваю, что эта задача по силам даже многим старшеклассникам, интересующимся программированием.) Если Вы программист - не можете с этим не согласиться.
Никто не предлагает "заменить SOAP на XML". Не надо смешивать (а) и (б)!
Читаю: "Не отменяя Web-сервисов, организовать обмен аналогичной информацией в рамках личного кабинета УО. Можно "зашить" SOAP-протокол прямо в личный кабинет, а можно и как-то иначе сделать - лишь бы сама информация была того же формата, что и в SOAP-протоколе (XML-файлы). Все ответы ГИС ЖКХ - также в формате XML". Как ещё можно это понимать?
По поводу (б). Если из ЛК допускается загружать XLSX-файлы, то почему нельзя столь же безопасным и защищённым образом загружать файлы других форматов, самый близкий из которых "по духу" - это XML? Вы можете внятно ответить на этот вопрос?
К сожалению, для внятного ответа у меня просто не хватает данных: я хоть и программист, но с ГИС ЖКХ не работал никогда. По идее, технических проблем быть не должно. Но этот вопрос не кажется мне принципиальным, поскольку для автоматической/автоматизированной передачи информации существует SOAP.
Цитата
AlcorVol пишет: Если бы это было реализовано, то для УО всё было бы намного проще. Ввиду того, что ЛК уже априори считается как бы "сертифицированным объектом", отпадает куча проблем (необходимость испытаний на стенде и т.д.)
Вот это, похоже, ключевой вопрос. Насколько я понимаю, для УО практически ничего не стало бы проще. Ну да, удалось бы сэкономить пару дней на изучение того, что такое SOAP и с чем его едят. А все остальные проблемы остались бы. Например, необходимость испытаний на стенде - осталась бы: вы ведь не стали бы скармливать "боевому" личному кабинету сформированный вашим софтом XML, не убедившись как-то в его корректности, правда? Какие-то тесты всё равно понадобились бы. С XLS _формально_ проще: этот формат человекочитаемый, поэтому создателям документов проще проверить их корректность.
Sergey Cheban пишет: Идея о том, что каждая УК должна иметь своё решение по взаимодействию с ГИС ЖКХ, мне совершенно не близка.
Вам - не близка, но многим здесь близка. И совершенно не обязательно от каждой УО требовать наличия своего ПО. Один программист (или небольшая фирма) в состоянии предоставить такое ПО многим УК/ТСЖ. Сейчас на рынке присутствуют множество разработчиков, по программам которых УО работают. Вопрос лишь в некоторых доработках для ГИС ЖКХ.
Ну и где они, эти доработки? Да и присутствие на рынке _множества_ разработчиков мне кажется вредным для дела. Десятка систем вполне хватило бы для конкуренции. Ну ок, пусть два десятка (в расчёте на то, что половина со временем сдохнет). А больше - зачем? Сейчас вместо десятка сильных команд разработчиков мы имеем множество слабых.
Цитата
AlcorVol пишет: Если у УК уже есть какое-то ПО в сфере ЖКХ, то доработки (в случае простого формата файлов обмена) будут или недорогими, или вообще не принесут дополнительных накладных расходов - в случае наличия соответствующего долговременного договора о сопровождении ПО. Включение в процесс обмена информацией с ГИС ЖКХ специальных агентов по занесению информации (коммерческих ИС) значительно сей процесс усложняет и удорожает. И к тому же, с ними тоже как-то обмениваться информацией надо. А это тоже - форматы, протоколы, формирование файлов, анализ ответов и т.д. и т.п. Получается для программиста почти то же самое, но вовлекается коммерческий посредник. Только и всего.
Насколько я понимаю, любой разработчик "какого-то ПО" может либо оказывать услуги по размещению информации в ГИС ЖКХ в рамках "долговременного договора о сопровождении ПО", либо доработать софт так, чтобы размещением информации могла заниматься сама УК. Привлекать к этому кого-то третьего (кроме самой УК и разработчика её софта) - не надо. Хороший разработчик сделает в своём продукте интеграцию с ГИС ЖКХ. А от плохого надо уходить к хорошему, а не привлекать кого-то третьего в качестве "агента по занесению информации". Может, я чего-то не понимаю?
Цитата
AlcorVol пишет: И ещё. Никто не требует, чтобы бухгалтерские программы были бесплатными. Это нонсенс. Точно так же, не бывает бесплатных программ в сфере ЖКХ для УО. Но здесь - с нас пытаются взять деньги за сам процесс размещения информации, практически не предоставляя бесплатной альтернативы.
Я пока что не очень понимаю, чем Вам SOAP не угодил в качестве бесплатной альтернативы. Разработчики ГИС ЖКХ, помнится, на каком-то из вебинаров рассказывали про героя, который сумел подключиться к системе через SOAP за месяц.
Вот, как раз ими я и намерен заняться. Уже начал даже.
Цитата
Sergey Cheban пишет: Да и присутствие на рынке _множества_ разработчиков мне кажется вредным для дела. Десятка систем вполне хватило бы для конкуренции. Ну ок, пусть два десятка (в расчёте на то, что половина со временем сдохнет). А больше - зачем? Сейчас вместо десятка сильных команд разработчиков мы имеем множество слабых.
Извините, но эти вопросы решаются только рынком. А не Вашими личными соображениями на тему, что было бы полезно, а что вредно. И сколько команд разработчиков тут требуется.
Цитата
Sergey Cheban пишет: Насколько я понимаю, любой разработчик "какого-то ПО" может либо оказывать услуги по размещению информации в ГИС ЖКХ в рамках "долговременного договора о сопровождении ПО", либо доработать софт так, чтобы размещением информации могла заниматься сама УК. Привлекать к этому кого-то третьего (кроме самой УК и разработчика её софта) - не надо.
Я - разработчик. Но разрабатывать "коммерческую ИС" не собираюсь. Буду дорабатывать софт для УК, ориентируясь на формирование и передачу файлов. Пока - в XLSX-формате. УК/ТСЖ тоже не хотят становиться "ИС". Их вполне устроила бы загрузка файлов в ЛК.
Цитата
Sergey Cheban пишет: Хороший разработчик сделает в своём продукте интеграцию с ГИС ЖКХ.
Статус ИС почти никому на практике не нужен. Каждое ТСЖ - самостоятельная информационная система? Маразм!
Цитата
Sergey Cheban пишет: Я пока что не очень понимаю, чем Вам SOAP не угодил в качестве бесплатной альтернативы. Разработчики ГИС ЖКХ, помнится, на каком-то из вебинаров рассказывали про героя, который сумел подключиться к системе через SOAP за месяц.
Слава героям, смотрел этот вебинар. Но должны быть (о чём я подробнейшим образом писал ранее) и другие, более традиционные и простые решения. Практически полная безальтернативность - это очень нехорошо.
Цитата
Sergey Cheban пишет: Например, необходимость испытаний на стенде - осталась бы: вы ведь не стали бы скармливать "боевому" личному кабинету сформированный вашим софтом XML, не убедившись как-то в его корректности, правда?
Нет, неправда. Если в документе есть ошибки, то ГИС должна возвратить файл с диагностиками. Что она сейчас, кстати, и делает для XLSX-файлов. Никакой трагедии.
two_oceans пишет: В целом поддерживаю. Хотя мне кажется такой упор на ЛК немного излишен. Поясню почему: оставим проблему защиты между ЛК и самой ГИС, чтобы получить доступ в ЛК все также придется устанавливать криптопровайдер и настраивать браузер. <...> Однако в остальном, по предложениям улучшения ЛК только "ЗА".
Возможно, обмен файлами через ЛК - и не самый лучший вариант. Просто он ближе всего к имеющемуся уже варианту с шаблонами. Потому от него и плясал.
Цитата
Второй и третий вариант с моей точки зрения предпочтительней. Второй вариант мне видится так: оффлайн-клиент, который бы принимал заданный тип данных передаваемых данных из заданной папки (несложно понаделать отдельных папок для ЛС, платежек, показаний ПУ...) в формате XML (но вообще можно и DBF CVS преобразовывать). Более точно: перечислял файлы в папках по таймеру, предварительно контролировал корректность данных в файле (что не закинули ЛС в папку ПУ), а дальше скажем сортировал правильные файлы - в папку на отправку, неправильные в папку ошибок. <...>
Ну, это уже не интерактивный вариант, а что-то типа "резидентного монитора": отслеживает содержимое входных папок, обрабатывает, раскидывает по папкам ответы. Тоже довольно симпатично. Пусть это будет вариант (2а).
Цитата
Конечно, можно сделать и интерактивный вариант (то есть вместо автоматического приема XML производить какие-то действия вручную в пользовательском интерфейсе, но тогда придется обучать пользователей).
Ну, будет не сложнее, чем научить работать в ЛК. Особенно, если интерфейс похожим сделать.
Цитата
Есть конечно заморочки по установке всей этой "прелести" на Windows XP - требует dotNet 2.0 с определенным обновлением и установки корневого сертификата Росстата. Да, я тоже думал что установить сертификат минутное дело, пока на одном компьютере не промучился с этим минут 40 - сертификат ставился неизвестно в какое хранилище...
Очень ценное замечание! Конечно же, всё должно работать на всей современной линейке Windows - от XP до 10-ки.
Цитата
Третий вариант - все вышеперечисленное в оффлайн-клиенте можно завязать на функцию в DLL (передавать имя файла для обработки, имя папки для перечисления, собственно данные XML либо ссылку на объект их содержащий), то есть задача в целом сводится к второму варианту. Вызываете функцию, а дальше пошла кипеть работа.
Ну, я имел в виду DLL для посылки информации напрямую в ГИС ЖКХ, но и такой DLL (вариант 3а) тоже неплохо смотрится.
Цитата
P.S. После прочтения ссылки на хабр, я стал получше представлять механику и даже подумывал в отдельной теме разобрать поэтапно что и как бы хотелось от такой платформы (ну или оффлайн-клиента). В частности, хотелось бы наверно добавить установку через интернет - по примеру Контур.Веб-диск - со страницы скачиваешь и ставишь маленькую программку (компонент, дающий права сайту устанавливать любые программы), далее обновляешь страницу и понеслось - анализ, что установлено на компьютере, каких версий, список что нужно дополнительно установить или обновить, убираешь ненужное, нажимаешь кнопку - автоскачивание и установка,перезапуск браузера, результат. Как считаете, нужно отдельной темой или тут продолжить?
Да я думаю, что можно и тут, и в отдельной теме. Хотя всё это и напоминает делёжку шкуры неубитого медведя. С другой стороны, чем больше будет замечаний и встречных предложений - тем лучше. С нами ведь не советовались, когда основные концепции ГИС ЖКХ принимали. Я считаю, что те средства, которые были предоставлены конечному пользователю (УО) - просто безобразны. Ни одна госструктура не вела ещё себя столь нагло. Требуете отчётности - дайте простые, понятные каждому средства её предоставления - какие файлы и какого формата нужно сформировать. И как их отправить. А не интерфейс в виде Web-сервисов. Ввиду сильного подозрения на присутствие тут чьих-то коммерческих интересов, мне кажется, что бодаться разработчики будут до последнего, типа: не хотите сами работать с SOAP - обращайтесь к коммерческим ИС. Но вода камень точит. Будем бодаться и мы.
Цитата
К сожалению, с VFP не работал. Если будут вопросы по Excel.Application - могу подсказать некоторые моменты...
Спасибо!
Отправлено спустя 4 минуты 44 секунды:
Цитата
Programmer пишет: А сертификаты я установил правильно? И еще. Почему у меня видны на флэшке 8 файлов, а у моего коллеги - нет?
Уважаемые господа, давайте не будем смешивать темы! Здесь всё-таки обсуждаются предложения по взаимодействию с ГИС ЖКХ. Не могли бы Вы конкретные вопросы по сертификатам обсудить в отдельной теме? Заранее - спасибо!
С третьей стороны, а ну вдруг как навалимся все вместе и сделаем - посрамим ГИС. Для определения, что нам реально нужно, а что излишество и роскошь. Если сомнения, что сможем.. в конце концов, уже есть бесплатный клиент Росстата, можно расковырять в каком виде хранятся шаблоны для загрузки в него.
Это было бы интересно, конечно. Если бы не одно но. ГИС ЖКХ постоянно меняет версии форматов. Если бы они отвечали сами за сопровождение "умного клиента" на стороне УО, это было бы для конечного пользователя незаметно. А так - придётся каждый раз всё переделывать. Мне кажется, что версии будут меняться ещё много-премного раз.
На вопросы про сертификаты ответил в новой теме: [url:460dd5r0]http://forum.burmistr.ru/viewtopic.php?f=147&t=5548[/url:460dd5r0] Если кратко, как захотите - так и сделаете. Закрытый ключ - это не обязательно флешка. OpenSSL обычно вообще глубоко все равно что стоит в системном хранилище сертификатов. С одной стороны - тоже своего рода проблема, с другой - нет побочных эффектов, как у хранилища "Личные".
Цитата
AlcorVol пишет: ГИС ЖКХ постоянно меняет версии форматов. Если бы они отвечали сами за сопровождение "умного клиента" на стороне УО, это было бы для конечного пользователя незаметно. А так - придётся каждый раз всё переделывать. Мне кажется, что версии будут меняться ещё много-премного раз.
Те же шаблоны Экселя тоже переделывают, от этого никуда не деться, все равно придется реагировать на изменения. Если все спроектировать достаточно умно, с учетом возможных "откровений", то все переделывать не придется. Все-таки в ГИС такие же люди, ничего сверхестественного не придумают. Такая вот битва экстрасенсов. Мне бы хотелось, чтобы автоматика обновления шаблонов смогла проанализировать изменения шаблонов (чтобы из новой версии форматов определить название нового поля, название формата данных в поле и обязательность поля, вывести примечание человеку - не нужно искусственного интеллекта) и предложить какие-то действия "ответственному за шаблоны" (например добавить поле в шаблон или убрать из шаблона), если действий достаточно - кликает ОК и все счастливы , если недостаточно, то звонит программисту и программист что-то чуть подправляет, например добавляет действие или корректирует алгоритм анализа.
Цитата
Ну, я имел в виду DLL для посылки информации напрямую в ГИС ЖКХ, но и такой DLL (вариант 3а) тоже неплохо смотрится.
Согласен, однако я не могу представить 1 мега-супер-ультра DLL, выполняющую все функции сразу. Даже если от клиента отрезать все не связанное с отправкой (например шуршание в папках в 2a) и принимать в DLL ссылку на XML текст, все равно останется много "модулей" с различным назначением. С одной стороны, эти файлы - та самая "каша из топора", с другой - объединять все вместе как-то экстремально - кто его знает, что там другие программисты натворили "внутре". С третьей - в качестве СКЗИ (средство криптографической защиты информации) сертифицируют конкретные бинарные файлы, так что или берем что уже сертифицировано кем-то в составе другого СКЗИ или придется сертифицировать улучшенную DLL как СКЗИ. Без сертификации к нам могут нагрянуть с нежданной проверкой. С учетом возможного распараллеливания отправки имеет смысл написать DLL как "общую" с учетом Thread Locale Storage (TLS), как системные библиотеки Windows - данные каждого потока хранятся в отдельной памяти, но адрес как бы один и тот же. Правда подобрать базовый адрес свободный "от xp до 10" будет непросто. Моя среда программирования "из коробки" TLS увы не поддерживает, сделать наверно можно, но придется долго читать "как" и долго колдовать.
Конечно, можно сделать и интерактивный вариант (то есть вместо автоматического приема XML производить какие-то действия вручную в пользовательском интерфейсе, но тогда придется обучать пользователей).
Ну, будет не сложнее, чем научить работать в ЛК. Особенно, если интерфейс похожим сделать.
Ещё подумал - а ведь если интерфейс похожий, то надо при изменении ЛК менять программу, это однако похуже шаблонов будет. Утром мелькнула идея попробовать для проверки сделать "резидентный монитор" на VBScript + XmlSigned класс, а для интерфейса добавить нечто среднее между нормальной программой и веб-штучками - HTA. Либо сосредоточится на Криптопро + stunnel + DLL (Delphi/Pascal) подписания и отправки + DLL для отчетов (отдельно, чтобы проще заменять, может быть тоже нужно разбить - включая обновление, анализ новой версии, формирование и проверку шаблона), пока без технологии "общей". Конечно, к этому накрутятся всякие конфигурации. Это то, в чем можно получить какие-то результаты в обозримом будущем.
вполне можно было бы обеспечить поддержку не одного формата, а нескольких (XML, DBF, CSV и т.п.) .
Цитата
Причём, мне кажется, что реализовать всё это им - почти ничего не стОит. Не миллиарды, точно.
День работы с перерывом на обед и перекуры
Цитата
min6666 пишет: Вся страна пользуется MS Office, процентов 99 из них пользуются крякнутым офисом. Давайте напугаем народ оупенофисом до кучи.
Это сильное преувеличение. Очень многие пытаются выдерживать лицензионную чистоту. Но дело даже не в этом. Libre вполне себе справляется с открытием и сохранением в xlsx, проблемы только с форматированием (а для обмена информацией форматирование не должно иметь значения), и, разумеется, с макросами (они тоже не нужны). На всю страну требовать использование какого-то конкретного, тем более платного, продукта - абсурд. Общепринятые открытые стандарты и форматы обмена для того и придумываются, чтобы было универсально и максимально удобно для как можно большего числа участников обмена.
Цитата
AlcorVol пишет: Просто для примера: я программист, но в штате никаких УК/ТСЖ не состою. Тем не менее, по моей программе работают несколько УК, пара десятков ТСЖ, а также небольшой расчётный центр - со своими УК и ТСЖ. Стараюсь программировать так, чтобы свои программисты в штате УО как раз не требовались. (Это не реклама, а просто информация. И вообще, мои интересы не простираются дальше Вологды и окрестностей. Более того: клиентов уже такое количество, что новые как-то даже не очень радуют. Работы хватает.)
У меня история та же, только география отличается. И новым людям тоже, наверное, пару лет отказываю.
Колллеги, чем предлжения разработчикам ГИС об изменениях будут дальше от существующих схем, тем меньше вероятность того, что их хотя бы прочитают.
two_oceans пишет: Ещё подумал - а ведь если интерфейс похожий, то надо при изменении ЛК менять программу, это однако похуже шаблонов будет.
Не совсем понял. Я имел в виду самостоятельное интерактивное приложение, интерфейс которого (GUI) по стилю напоминает стиль работы юзера в ЛК. А если будут меняться сами форматы структуры данных (как сейчас шаблоны меняются), то это, конечно, в программе клиента (УО), осуществляющей подготовку XML-файлов, учитывать придётся.
Цитата
Утром мелькнула идея попробовать для проверки сделать "резидентный монитор" на VBScript + XmlSigned класс, а для интерфейса добавить нечто среднее между нормальной программой и веб-штучками - HTA. Либо сосредоточится на Криптопро + stunnel + DLL (Delphi/Pascal) подписания и отправки + DLL для отчетов (отдельно, чтобы проще заменять, может быть тоже нужно разбить - включая обновление, анализ новой версии, формирование и проверку шаблона), пока без технологии "общей". Конечно, к этому накрутятся всякие конфигурации. Это то, в чем можно получить какие-то результаты в обозримом будущем.
Успехов! А я пока продолжу с XLSX-шаблонами ковыряться. Пора бы отложить в сторону писанину на форуме, а заняться делом.
Колллеги, чем предложения разработчикам ГИС об изменениях будут дальше от существующих схем, тем меньше вероятность того, что их хотя бы прочитают.
И поэтому я с самого начала предложил вариант, максимально близкий к действующему: загрузка файлов из ЛК со сменой формата XLSX -> XML (простой, но эквивалентный по содержимому). Образцы для подражания есть: форматы сведений для сдачи отчётности в налоговую и ПФР.
AlcorVol пишет: И поэтому я с самого начала предложил вариант, максимально близкий к действующему: загрузка файлов из ЛК со сменой формата XLSX -> XML.
Ну по чесноку — по-моему, это наименее утопичный вариант. Только не «со сменой формата», а с дополнением. Пытаюсь поставить себя на место разрабов ГИСа. Поскольку xlsx это «усложнённый» xml, то (навскидку) дополнительной работы для его обработки должно быть немного. Опять же, поскольку это универсальный формат, то реализовать его обработку было бы интересно с программерской точки зрения (сужу по себе). Однако отказываться от xls-шаблонов я бы не стал — в случае ручного заполнения данных «блондинкой» (а на них тоже надо ориентироваться), вероятность накосячить в Excel-е меньше.
На всю страну требовать использование какого-то конкретного, тем более платного, продукта - абсурд. Общепринятые открытые стандарты и форматы обмена для того и придумываются, чтобы было универсально и максимально удобно для как можно большего числа участников обмена.
Нужен формат, понятный не только ГИСу, но и пользователям. Решение задачи начинается с изучения исходных данных, а исходные данные таковы, что эксель знают все, кто пользуется ПК. Главная проблема в том, что для начислений используются разные ИС - от самописных до конфиг под 1С от разных разработчиков, эта сфера не стандартизирована. Отсюда невозможность нажатием на кнопку получить понятный ГИСу пакет данных. Загнать всех под одну программу для начислений? Но для этого операторам и расчетчикам придется не только переучиваться, но и переносить все ИБ в новую программу. Это может привести к массовым увольнениям, как во времена подсадки бухгалтеров на 1С увольнялись опытные специалисты.
min6666 пишет: Главная проблема в том, что для начислений используются разные ИС - от самописных до конфиг под 1С от разных разработчиков, эта сфера не стандартизирована. Отсюда невозможность нажатием на кнопку получить понятный ГИСу пакет данных.Загнать всех под одну программу для начислений? <...>
Нет, не так. Не надо всех в одну программу загонять. Достаточно предоставить простой и понятный формат файлов обмена информацией с ГИС ЖКХ. Настолько простой, что практически каждый программист был бы в состоянии такие файлы в любой из используемых расчётных программ быстренько подготовить. И XML тут подходит гораздо больше, чем XLSX. Альтернатива (не совсем удачная и громоздкая): общедоступная бесплатная DLL-библиотека для работы с XLSX-файлами.
Отправлено спустя 2 минуты 42 секунды:
Цитата
andrewk пишет: Однако отказываться от xls-шаблонов я бы не стал — в случае ручного заполнения данных «блондинкой» (а на них тоже надо ориентироваться), вероятность накосячить в Excel-е меньше.
Да, соглашусь. Неаккуратно написал. Не замена, а дополнение.
min6666 пишет: Нужен формат, понятный не только ГИСу, но и пользователям. Решение задачи начинается с изучения исходных данных, а исходные данные таковы, что эксель знают все, кто пользуется ПК.
Не спорю. Только не понимаю, какой из этого ты хочешь сделать вывод. Да, практически все более менее умеют работать в Excel. Но Excel умеет открывать и сохранять xml, csv, ods и с натяжкой dbf. Всё это, в том числе xls, могут открывать и сохранять и другие продукты. Так почему всех вынуждать это делать именно в Excel?
Цитата
min6666 пишет: Главная проблема в том, что для начислений используются разные ИС - от самописных до конфиг под 1С от разных разработчиков, эта сфера не стандартизирована. Отсюда невозможность нажатием на кнопку получить понятный ГИСу пакет данных.
Ну так для этого и публикуются стандарты обмена: форматы файлов, поля, правила заполнения... Это же всё обычная ситуация, сколько раз проходили: обмен с органами соцзащиты, с кучей платёжных агентов... — у всех всё разное, однако договаривались, настраивали, дорабатывали.
Upd: пока я сочинял ответ, то же самое написал AlcorVol постом выше)
Не надо всех в одну программу загонять. Достаточно предоставить простой и понятный формат файлов обмена информацией с ГИС ЖКХ. Настолько простой, что практически каждый программист был бы в состоянии такие файлы в любой из используемых расчётных программ быстренько подготовить. И XML тут подходит гораздо больше, чем XLSX.
Ага. Программист такой написал обработку, а пользователь такой чего-то там накосячил в программе, ГИС не может прочитать и выдает ошибку, пользователь в одномерном массиве, естественно, найти и исправить ошибку не может и начинает процедуру выноса мозга программиста. Не будите лихо.
min6666 пишет: Программист такой написал обработку, а пользователь такой чего-то там накосячил в программе, ГИС не может прочитать и выдает ошибку, пользователь в одномерном массиве, естественно, найти и исправить ошибку не может и начинает процедуру выноса мозга программиста.
Вы, вообще, внимательно все мои предложения читали? Или опять через три строки на четвёртую? Я везде предполагаю, что в ответ ГИС ЖКХ посылает тоже XML-файлы. И программа эти ответы тоже обрабатывает. Если есть диагностики об ошибках - оператор программы это увидит. Если Вам всё, что тут обсуждается, не интересно (или не нравится), то просто держите свой скепсис при себе.
min6666 пишет: Главная проблема в том, что для начислений используются разные ИС - от самописных до конфиг под 1С от разных разработчиков, эта сфера не стандартизирована. Отсюда невозможность нажатием на кнопку получить понятный ГИСу пакет данных. Загнать всех под одну программу для начислений? Но для этого операторам и расчетчикам придется не только переучиваться, но и переносить все ИБ в новую программу. Это может привести к массовым увольнениям, как во времена подсадки бухгалтеров на 1С увольнялись опытные специалисты.
Но согласитесь, как будет удобно, когда появится единый формат. Некий единый информационный стандарт.
Но согласитесь, как будет удобно, когда появится единый формат. Некий единый информационный стандарт.
Удобно, конечно. Маяковский лет сто как тому писал про стандартизацию:
Цитата
Подходи, рабочий! Обсудим, дай-ка, что это за вещь такая гайка? Что гайка?! Ерунда! Малость! А попробуй-ка езжай, ежели сломалась. Без этой вещи, без гайки той — ни взад, ни вперед. Становись и стой! Наконец отыскали гайку эту... Прилаживают... Никакой возможности нету!.. Эта мала, та велика, — словом, не приладишь ее никак. И пошли пешком, как гуляки праздные. Отчего? Оттого, что гайки разные. А если гайки одинаковые ввесть, сломалась — новая сейчас же есть. И нечего долго разыскивать тут: бери любую — хоть эту, хоть ту! И не только в гайке наше счастье. Надо всем машинам одинаковые части, а не то, как теперь — паровоз и паровоз, — один паровозом, а другой, как воз. Если это поймет рабочего разум — к Коммуне на паровозах ринемся разом.
min6666 пишет: Удобно, конечно. Маяковский лет сто как тому писал про стандартизацию:
Опять флуд в этой теме? Ведь просил же Вас уже. Мне что - теперь модератора вежливо кое о чём попросить?.. Козьму Пруткова помните? "Если у тебя есть фонтан, ..."
two_oceans пишет: Ещё подумал - а ведь если интерфейс похожий, то надо при изменении ЛК менять программу, это однако похуже шаблонов будет.
Не совсем понял. Я имел в виду самостоятельное интерактивное приложение, интерфейс которого (GUI) по стилю напоминает стиль работы юзера в ЛК. А если будут меняться сами форматы структуры данных (как сейчас шаблоны меняются), то это, конечно, в программе клиента (УО), осуществляющей подготовку XML-файлов, учитывать придётся.
А я не про форматы, а про то, что они и сайт частенько меняют - перетаскивают форму с одного раздела на другой без всякого предупреждения. То есть периодически придется синхронизировать вид приложения с текущим видом сайта.
Цитата
Успехов! А я пока продолжу с XLSX-шаблонами ковыряться. Пора бы отложить в сторону писанину на форуме, а заняться делом.
Как раз о том же подумал, да и другой работки подкинули. Поэтому сокращаю время на форуме и ищу наметки в Интернете. Вот что вчера нашел: [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. Кроме каноникализации там еще и декларации функций майкрософтовского криптопровайдера - как получить хэш и подпись и чего с ними потом делать.
Цитата
Коллеги, чем предложения разработчикам ГИС об изменениях будут дальше от существующих схем, тем меньше вероятность того, что их хотя бы прочитают.
Согласен, но с другой стороны сколько можно ждать "милости от природы", поэтому наиболее далекие от существующих схем предлагаю сделать совместными усилиями - я вот практически решился написать DLL для подписи XML. Тема достаточно интересная в плане множества других применений XML. Ранее думал, что моего кунг-фу не хватит, но оказалось программисты ФГИС это не придумали, есть международный стандарт - сразу стало легче. Остается вопрос реализовать подписание как в ГИС ЖКХ и остановиться или реализовать формат полностью. В частности, сертификат, можно указывать многими способами. О полном формате нашел вводную статью: [url:3nv6tnms]http://minichden.narod.ru/articles/xmldsig.htm[/url:3nv6tnms]. По этому вопросу - мне нужно будет как-то проверить результат. Пилить в C# только ради проверки нет никакого смысла. Может быть, если у кого есть рабочая схема подписи, я предоставлю "самодельные" тестовые сертификаты и вы ими подпишите несколько файлов?
Цитата
Поскольку xlsx это «усложнённый» xml, то (навскидку) дополнительной работы для его обработки должно быть немного.
Обоснование понятно. Однако, как мне кажется это может иметь обратный эффект: SOAP, это то же XML, так что с ним программисты ГИС уже "наигрались" и реализовывать еще что-то промежуточное между SOAP и XLSX будет слишком похоже, при дополнительной необходимости отражать изменения на еще один формат, и потому не так уж привлекательно. Однако даже если сделают возможность грузить SOAP через ЛК без кучи регистраций в качестве ИС и тестирований, тоже будет достаточно забавно.
Цитата
Да, практически все более менее умеют работать в Excel. Но Excel умеет открывать и сохранять xml, csv, ods и с натяжкой dbf.
Вот честно говоря, насчет xml не уверен, с таким же успехом html можно дополнить в список. Сам формат Эксель конечно умеет открывать и сохранять, но при этом при создании/сохранении файла в Экселе в тегах столько специфичного для Экселя "мусора" - всяческие стили офисного пакета, форматы, формулы и т.д. - что ни одна уважающая себя система не будет этот хлам обрабатывать без дополнительного "очищающего" конвертера. Из-за такого "мусора" в тегах я даже FrontPage давно перестал использовать для редактирования веб-страниц.
Почему бы не сделать так? 1. Из ПО УО формируется банальный TXT такого формата: Реквизит=Значение; Реквизит=Значение; ... Реквизит=Значение@ ЭЦП 2. Из распространяемого для всех желающих бесплатного ПО ГИСа эти файлы выгружаются "туда". В ПО ГИСа должны быть (например) такие настройки: а) "папка на диске пользователя, где хранится МКД", допустим C:\MKD, тогда протоколы импорта будут сохраняться в C:\MKD_PROTO. б) "папка на диске пользователя, где хранится ПУ", допустим C:\PU, тогда протоколы импорта будут сохраняться в C:\PU_PROTO. И т. д...
Почему не CSV? Потому что там порядок вывода значений надо выдерживать, а при таком формате TXT - не надо, да и программисту гораздо проще TXT заполнить таким образом, чем XML.
Попробую ответить "с точки зрения разработчиков ГИС ЖКХ". 1. Протокол SOAP - это всего лишь передача XML-файлов по протоколу HTTP. Всё. Больше там ничего нет. Пример обмена можно посмотреть . Пример использования этого применительно к ГИС ЖКХ - . В этом свете разговоры про "Не надо нам SOAP, дайте нам обычный XML" - вызывают некоторое недоумение. Желание передавать SOAP-запросы по HTTP не напрямую, а через личный кабинет, который работает через тот же HTTP - вызывает ещё большее недоумение, когда оно возникает у программиста (а для остальных есть XSLT). 2. Идея о том, что "Всю криптозащиту информации в процессе взаимодействия с ГИС ЖКХ должен взять на себя ЛК" - неудачная. Дело в том, что при входе в личный кабинет стороны (Алиса и Боб) устанавливают защищенный канал связи, но у этого канала есть важный недостаток: Алиса не может доказать третьим лицам (суду, например), что получила от Боба какую-то информацию. Чтобы Алиса могла это доказать, Боб должен подписать информацию своим приватным ключом, а приватный ключ, разумеется, должен оставаться на компьютере Боба, на то он и приватный. 3. Идея про "Дайте нам свою DLL, дальше мы как-нибудь сами" - это отговорки. Протокол SOAP - открытый. И вот с этой точки - пожалуйста, сами, если можете. А если не можете, то и говорить не о чем. А DLL - это очень, очень плохая идея: [*:2unhxjve]Непонятная DLL, работающая с криптографией и имеющая доступ к приватным ключам - это не безопасно.[/*:m:2unhxjve] [*:2unhxjve]DLL привязывает нас к платформе Windows.[/*:m:2unhxjve] [*:2unhxjve]Интерфейс, предоставляемый DLL - это чистый C. Даже не C++. Работать с ним из современных языков программирования неудобно.[/*:m:2unhxjve] [*:2unhxjve]DLL выполняется в адресном пространстве чужого процесса. Если в результате процесс падает, не всегда понятно, по чьей вине это произошло. Нет внятного разграничения зон ответственности.[/*:m:2unhxjve] [*:2unhxjve]В DLL наверняка были бы ошибки. Распространение DLL с исправлениями этих ошибок - задача нетривиальная.[/*:m:2unhxjve] 4. Идея о том, что каждая УК должна иметь своё решение по взаимодействию с ГИС ЖКХ, мне совершенно не близка. Она напоминает девяностые годы, когда каждая компания писала свою бухгалтерию. А потом пришла 1С, и все поняли, что бухгалтерию дешевле купить, чем делать самим. То же самое, на мой взгляд, должно произойти и в сфере ЖКХ: разработкой софта должны заниматься специализирующиеся на этом компании, а УК должны управлять домами. 5. Один из примеров реальных проблем с ГИС ЖКХ - то, что сплошь и рядом один дом (с одним почтовым адресом, сквозной нумерацией квартир и т.п.) числится в Росреестре (а значит, и в ГИС ЖКХ) как несколько зданий. Этим следовало бы заняться ещё вчера, и никакой XSLT этому не мешает.
Programmer пишет: Почему бы не сделать так? 1. Из ПО УО формируется банальный TXT такого формата: Реквизит=Значение; Реквизит=Значение; ... Реквизит=Значение@ ЭЦП
Преимущество формата XML - в том, что он стандартный. А к тому, что написали Вы, сразу возникает куча вопросов, на которые нет готовых ответов: 1. Как быть, если Значение содержит точку с запятой, кавычки, символ равенства, перевод строки? 2. В какой кодировке должен быть этот TXT? Допустим ли Byte Order Mark в начале? 3. В каком виде должна быть ЭЦП? Как она должна отделяться от данных? 4. Как быть, если нужно работать со структурированной информацией? Ну, например, реквизит "адрес" состоит из названия улицы, номера дома и номера квартиры. 5. Как быть, если нужно передать не один объект, а массив?
Цитата
Programmer пишет: 2. Из распространяемого для всех желающих бесплатного ПО ГИСа эти файлы выгружаются "туда".
Почему Вы считаете, что это ПО кто-то должен разработать для Вас _бесплатно_? А бесплатное ПО бухучёта Вам, случайно, не нужно? Нет, я понимаю, что неплохо было бы, чтобы оно было, но сразу возникнут вопросы: - А почему только под Windows? - А почему с Win95 не работает? - А почему такой кривой формат исходных данных, хочу CSV/XML/OOXML/OpenXML/DBF? - А почему интерфейс такой корявый?
К бесплатному часто предъявляют такие требования. С платным софтом проще: любой каприз за Ваши деньги.
Sergey Cheban пишет: Почему Вы считаете, что это ПО кто-то должен разработать для Вас _бесплатно_? А бесплатное ПО бухучёта Вам, случайно, не нужно?
Оно то конечно в целом правильно.. Но вот, к примеру, ФНС уже лет 15 разрабатывает бесплатное ПО для заполнения налоговых деклараций. Или Росстат бесплатно принимает статотчётность через свой сайт сбора. А могли бы и денюшку за всё это попросить.
Sergey Cheban пишет: Попробую ответить "с точки зрения разработчиков ГИС ЖКХ". Протокол SOAP - это всего лишь передача XML-файлов по протоколу HTTP. Всё. Больше там ничего нет. В этом свете разговоры про "Не надо нам SOAP, дайте нам обычный XML" - вызывают некоторое недоумение.
Прежде всего, спасибо за оппонирование! А то здесь только "несогласные" (с ГИС ЖКХ) собрались. Просто даже спорить не с кем. И вот - появился хоть один, кто "согласен". Некоторое недоумение, однако, вызывает у меня тот факт, что Вы путаете вопросы. Давайте разделим проблемы:
(а) Формат данных; (б) Их передача.
По поводу (а). Формат XLSX не предназначен, вообще говоря, для автоматизированного (не ручного) заполнения. И это очень плохо. Сформировать эквивалентный по содержимому XML-файл из программы намного проще. (Подозреваю, что эта задача по силам даже многим старшеклассникам, интересующимся программированием.) Если Вы программист - не можете с этим не согласиться. Никто не предлагает "заменить SOAP на XML". Не надо смешивать (а) и (б)!
По поводу (б). Если из ЛК допускается загружать XLSX-файлы, то почему нельзя столь же безопасным и защищённым образом загружать файлы других форматов, самый близкий из которых "по духу" - это XML? Вы можете внятно ответить на этот вопрос? Если бы это было реализовано, то для УО всё было бы намного проще. Ввиду того, что ЛК уже априори считается как бы "сертифицированным объектом", отпадает куча проблем (необходимость испытаний на стенде и т.д.) Необходимость наличия у оператора ЛК ЭЦП (если надо - усиленной, квалифицированной) никто под сомнение не ставит.
Разумеется, все форматы загружаемых (и получаемых в ответ) файлов должны быть описаны. Тут проблем не вижу никаких.
Цитата
Sergey Cheban пишет: Идея о том, что каждая УК должна иметь своё решение по взаимодействию с ГИС ЖКХ, мне совершенно не близка.
Вам - не близка, но многим здесь близка. И совершенно не обязательно от каждой УО требовать наличия своего ПО. Один программист (или небольшая фирма) в состоянии предоставить такое ПО многим УК/ТСЖ. Сейчас на рынке присутствуют множество разработчиков, по программам которых УО работают. Вопрос лишь в некоторых доработках для ГИС ЖКХ.
Цитата
Sergey Cheban пишет: Почему Вы считаете, что это ПО кто-то должен разработать для Вас _бесплатно_?
Если у УК уже есть какое-то ПО в сфере ЖКХ, то доработки (в случае простого формата файлов обмена) будут или недорогими, или вообще не принесут дополнительных накладных расходов - в случае наличия соответствующего долговременного договора о сопровождении ПО. Включение в процесс обмена информацией с ГИС ЖКХ специальных агентов по занесению информации (коммерческих ИС) значительно сей процесс усложняет и удорожает. И к тому же, с ними тоже как-то обмениваться информацией надо. А это тоже - форматы, протоколы, формирование файлов, анализ ответов и т.д. и т.п. Получается для программиста почти то же самое, но вовлекается коммерческий посредник. Только и всего.
И ещё. Никто не требует, чтобы бухгалтерские программы были бесплатными. Это нонсенс. Точно так же, не бывает бесплатных программ в сфере ЖКХ для УО. Но здесь - с нас пытаются взять деньги за сам процесс размещения информации, практически не предоставляя бесплатной альтернативы. Поясню на понятном примере, бухгалтерском. Государство требует от компаний сдачи некоторых сведений (формы налоговой отчётности, отчётность в ПФР и другие фонды). Заметим, что формат этих сведений - как раз XML. И в каждой программе бухучёта формирование таких файлов предусмотрено. Есть фирмы-посредники, которые на коммерческой основе помогут вам загрузить эти сведения в соответствующие государственные информационные системы. Но у бухгалтера тут есть выбор! Он может просто сбросить XML-файлы на флэшку - и лично явиться в налоговую или ПФР. Кроме того, вы можете сдать отчётность в ФНС в личном кабинете налогоплательщика, никуда не ходя! Смотрите, к примеру, здесь:
Почему ФНС не усматривает никаких сложностей с загрузкой отчётности в ЛК (при наличии усиленной КЭП)? Почему трудности возникают только у суперквалифицированных разработчиков ГИС ЖКХ?..
Короче говоря, если государство от кого-то требует какой-то отчётности, то оно должно позаботиться о простоте и удобстве предоставления сведений. Существует ли такая простая альтернатива для ГИС ЖКХ? И если нет, то по какой, спрашивается, причине?.. Короче, куда тут ни ткни - везде просматривается неявное желание принудительно отправить УО прямиком в лапы посредника. Что не может не вызвать совершенно оправданных вопросов, недоумения и даже возмущения.
Хотя Вы как-то высказывались в пользу разрабов, но "суперквалифицированных" надо писать в кавычках.
Отправлено спустя 2 минуты 49 секунды:
Цитата
AlcorVol пишет: Короче, куда тут ни ткни - везде просматривается неявное желание принудительно отправить УО прямиком в лапы посредника. Что не может не вызвать совершенно оправданных вопросов, недоумения и даже возмущения.
Полностью с Вами согласен! Да и требование к MS слишком у них завышены, в доле, скорее всего.
Programmer пишет: Да и требование к MS слишком у них завышены, в доле, скорее всего.
Ну, я бы - без наличия сведений о "долевом участии" - не стал бы никого заранее тут обвинять. Я обвиняю разработчиков ГИС ЖКХ лишь в том, что они выбрали формат для загрузки файлов в ГИС, очень мало подходящий для автоматизированного заполнения. Что как бы "намекает".
AlcorVol пишет: Я обвиняю разработчиков ГИС ЖКХ лишь в том
Не смог удержаться, вставлю свои 2 коп. Вот мы с тобой всё в одном - и заказчик и постановщик и кодер. А там - команда. И обвинять всех скопом имхо неправильно. Я б, например, обвинял конкретно товарища Горбунова.
Basil пишет: И обвинять всех скопом имхо неправильно. Я б, например, обвинял конкретно товарища Горбунова.
Никого там по имени не знаю. И кто за что отвечает - мне тоже не очень интересно. Для меня это именно команда. Мне безразлично, кто проектные решения принимал. Но я вижу, что они - крайне неудобны для меня и моих УО. Пусть разбираются внутри сами. Государство - как "генеральный заказчик" - здесь просто обязано порядок навести. Если, конечно, действительно хочет какие-то сведения в ГИС получить.
Sergey Cheban пишет: Почему Вы считаете, что это ПО кто-то должен разработать для Вас _бесплатно_?
Потому, что это надо им, а не мне.
Надо это - жильцам, которые платят деньги УК, а не государству (государству они, впрочем, тоже платят налоги, но за поддержание порядка, а не за формирование квитанций).
Почему жильцам это надо? Фактически, эту потребность создали сами же УК: не все, но многие из них в управлении домом проявляют, хм, творческий подход. То оказываемую услугу как-нибудь не так назовут, то с метражом ошибутся, то тарифы начнут произвольно менять, то документы на управление домом не в порядке окажутся, то ОСС нарисуют, то платёж потеряют,то ещё что-нибудь. Ну вот вам, УК, от государства компьютер, который проверяет корректность вашего творчества. И вполне естественно, что этот компьютер заканчивается там, где начинается сеть.
Sergey Cheban пишет: Почему Вы считаете, что это ПО кто-то должен разработать для Вас _бесплатно_? А бесплатное ПО бухучёта Вам, случайно, не нужно?
Оно то конечно в целом правильно.. Но вот, к примеру, ФНС уже лет 15 разрабатывает бесплатное ПО для заполнения налоговых деклараций. Или Росстат бесплатно принимает статотчётность через свой сайт сбора. А могли бы и денюшку за всё это попросить.
На мой взгляд, государство _обязано_ бесплатно предоставить удобный открытый интерфейс к своим сервисам. Всё остальное - опционально. ФНС, конечно, молодцы, что дают бесплатное ПО, но это вовсе не их обязанность. А вот личные кабинеты на сайте - это то, что ведомства делать должны.
По поводу (а). Формат XLSX не предназначен, вообще говоря, для автоматизированного (не ручного) заполнения. И это очень плохо. Сформировать эквивалентный по содержимому XML-файл из программы намного проще. (Подозреваю, что эта задача по силам даже многим старшеклассникам, интересующимся программированием.) Если Вы программист - не можете с этим не согласиться.
Никто не предлагает "заменить SOAP на XML". Не надо смешивать (а) и (б)!
Читаю: "Не отменяя Web-сервисов, организовать обмен аналогичной информацией в рамках личного кабинета УО. Можно "зашить" SOAP-протокол прямо в личный кабинет, а можно и как-то иначе сделать - лишь бы сама информация была того же формата, что и в SOAP-протоколе (XML-файлы). Все ответы ГИС ЖКХ - также в формате XML". Как ещё можно это понимать?
По поводу (б). Если из ЛК допускается загружать XLSX-файлы, то почему нельзя столь же безопасным и защищённым образом загружать файлы других форматов, самый близкий из которых "по духу" - это XML? Вы можете внятно ответить на этот вопрос?
К сожалению, для внятного ответа у меня просто не хватает данных: я хоть и программист, но с ГИС ЖКХ не работал никогда. По идее, технических проблем быть не должно. Но этот вопрос не кажется мне принципиальным, поскольку для автоматической/автоматизированной передачи информации существует SOAP.
Цитата
AlcorVol пишет: Если бы это было реализовано, то для УО всё было бы намного проще. Ввиду того, что ЛК уже априори считается как бы "сертифицированным объектом", отпадает куча проблем (необходимость испытаний на стенде и т.д.)
Вот это, похоже, ключевой вопрос. Насколько я понимаю, для УО практически ничего не стало бы проще. Ну да, удалось бы сэкономить пару дней на изучение того, что такое SOAP и с чем его едят. А все остальные проблемы остались бы. Например, необходимость испытаний на стенде - осталась бы: вы ведь не стали бы скармливать "боевому" личному кабинету сформированный вашим софтом XML, не убедившись как-то в его корректности, правда? Какие-то тесты всё равно понадобились бы. С XLS _формально_ проще: этот формат человекочитаемый, поэтому создателям документов проще проверить их корректность.
Sergey Cheban пишет: Идея о том, что каждая УК должна иметь своё решение по взаимодействию с ГИС ЖКХ, мне совершенно не близка.
Вам - не близка, но многим здесь близка. И совершенно не обязательно от каждой УО требовать наличия своего ПО. Один программист (или небольшая фирма) в состоянии предоставить такое ПО многим УК/ТСЖ. Сейчас на рынке присутствуют множество разработчиков, по программам которых УО работают. Вопрос лишь в некоторых доработках для ГИС ЖКХ.
Ну и где они, эти доработки? Да и присутствие на рынке _множества_ разработчиков мне кажется вредным для дела. Десятка систем вполне хватило бы для конкуренции. Ну ок, пусть два десятка (в расчёте на то, что половина со временем сдохнет). А больше - зачем? Сейчас вместо десятка сильных команд разработчиков мы имеем множество слабых.
Цитата
AlcorVol пишет: Если у УК уже есть какое-то ПО в сфере ЖКХ, то доработки (в случае простого формата файлов обмена) будут или недорогими, или вообще не принесут дополнительных накладных расходов - в случае наличия соответствующего долговременного договора о сопровождении ПО. Включение в процесс обмена информацией с ГИС ЖКХ специальных агентов по занесению информации (коммерческих ИС) значительно сей процесс усложняет и удорожает. И к тому же, с ними тоже как-то обмениваться информацией надо. А это тоже - форматы, протоколы, формирование файлов, анализ ответов и т.д. и т.п. Получается для программиста почти то же самое, но вовлекается коммерческий посредник. Только и всего.
Насколько я понимаю, любой разработчик "какого-то ПО" может либо оказывать услуги по размещению информации в ГИС ЖКХ в рамках "долговременного договора о сопровождении ПО", либо доработать софт так, чтобы размещением информации могла заниматься сама УК. Привлекать к этому кого-то третьего (кроме самой УК и разработчика её софта) - не надо. Хороший разработчик сделает в своём продукте интеграцию с ГИС ЖКХ. А от плохого надо уходить к хорошему, а не привлекать кого-то третьего в качестве "агента по занесению информации". Может, я чего-то не понимаю?
Цитата
AlcorVol пишет: И ещё. Никто не требует, чтобы бухгалтерские программы были бесплатными. Это нонсенс. Точно так же, не бывает бесплатных программ в сфере ЖКХ для УО. Но здесь - с нас пытаются взять деньги за сам процесс размещения информации, практически не предоставляя бесплатной альтернативы.
Я пока что не очень понимаю, чем Вам SOAP не угодил в качестве бесплатной альтернативы. Разработчики ГИС ЖКХ, помнится, на каком-то из вебинаров рассказывали про героя, который сумел подключиться к системе через SOAP за месяц.
Вот, как раз ими я и намерен заняться. Уже начал даже.
Цитата
Sergey Cheban пишет: Да и присутствие на рынке _множества_ разработчиков мне кажется вредным для дела. Десятка систем вполне хватило бы для конкуренции. Ну ок, пусть два десятка (в расчёте на то, что половина со временем сдохнет). А больше - зачем? Сейчас вместо десятка сильных команд разработчиков мы имеем множество слабых.
Извините, но эти вопросы решаются только рынком. А не Вашими личными соображениями на тему, что было бы полезно, а что вредно. И сколько команд разработчиков тут требуется.
Цитата
Sergey Cheban пишет: Насколько я понимаю, любой разработчик "какого-то ПО" может либо оказывать услуги по размещению информации в ГИС ЖКХ в рамках "долговременного договора о сопровождении ПО", либо доработать софт так, чтобы размещением информации могла заниматься сама УК. Привлекать к этому кого-то третьего (кроме самой УК и разработчика её софта) - не надо.
Я - разработчик. Но разрабатывать "коммерческую ИС" не собираюсь. Буду дорабатывать софт для УК, ориентируясь на формирование и передачу файлов. Пока - в XLSX-формате. УК/ТСЖ тоже не хотят становиться "ИС". Их вполне устроила бы загрузка файлов в ЛК.
Цитата
Sergey Cheban пишет: Хороший разработчик сделает в своём продукте интеграцию с ГИС ЖКХ.
Статус ИС почти никому на практике не нужен. Каждое ТСЖ - самостоятельная информационная система? Маразм!
Цитата
Sergey Cheban пишет: Я пока что не очень понимаю, чем Вам SOAP не угодил в качестве бесплатной альтернативы. Разработчики ГИС ЖКХ, помнится, на каком-то из вебинаров рассказывали про героя, который сумел подключиться к системе через SOAP за месяц.
Слава героям, смотрел этот вебинар. Но должны быть (о чём я подробнейшим образом писал ранее) и другие, более традиционные и простые решения. Практически полная безальтернативность - это очень нехорошо.
Цитата
Sergey Cheban пишет: Например, необходимость испытаний на стенде - осталась бы: вы ведь не стали бы скармливать "боевому" личному кабинету сформированный вашим софтом XML, не убедившись как-то в его корректности, правда?
Нет, неправда. Если в документе есть ошибки, то ГИС должна возвратить файл с диагностиками. Что она сейчас, кстати, и делает для XLSX-файлов. Никакой трагедии.
Мы получили Вашу заявку, скоро наши менеджеры свяжутся с Вами. Спасибо!
Мы получили Вашу заявку, скоро наши менеджеры свяжутся с Вами. Спасибо!
Спасибо, мы скоро свяжемся с Вами!
Мы получили Вашу заявку, скоро наши менеджеры свяжутся с Вами. Спасибо!
Мы получили Вашу заявку, скоро наши менеджеры свяжутся с Вами. Спасибо!
Статья 14.1.3. Осуществление предпринимательской деятельности по управлению многоквартирными
домами без лицензии
Осуществление предпринимательской деятельности по управлению многоквартирными домами с нарушением
лицензионных требований, за исключением случаев, предусмотренных статьей 13.19.2 настоящего Кодекса,
влечет наложение административного штрафа на должностных лиц в размере от пятидесяти тысяч до ста
тысяч рублей или дисквалификацию на срок до трех лет; на юридических лиц - от двухсот пятидесяти
тысяч до трехсот тысяч рублей.
2.Управляющая организация, товарищество и кооператив обязаны раскрывать следующие виды
информации:
а) общая информация об управляющей организации, товариществе и кооперативе, в том числе об основных
показателях финансово-хозяйственной деятельности (включая сведения о годовой бухгалтерской
отчетности, бухгалтерский баланс и приложения к нему, сведения о доходах, полученных за оказание
услуг по управлению многоквартирными домами (по данным раздельного учета доходов и расходов), а
также сведения о расходах, понесенных в связи с оказанием услуг по управлению многоквартирными
домами (по данным раздельного учета доходов и расходов), сметы доходов и расходов товарищества или
кооператива, отчет о выполнении смет доходов и расходов товарищества или кооператива);
б) перечень многоквартирных домов, управление которыми осуществляет управляющая организация,
товарищество и кооператив, с указанием адреса и основания управления по каждому многоквартирному
дому, перечень многоквартирных домов, в отношении которых договоры управления были расторгнуты в
предыдущем году, с указанием адресов этих домов и оснований расторжения договоров управления,
перечень многоквартирных домов, собственники помещений в которых в предыдущем году на общем собрании
приняли решение о прекращении их объединения в товарищества для совместного управления общим
имуществом в многоквартирных домах, а также перечень многоквартирных домов, в которых членами
кооперативов в предыдущем году на их общем собрании приняты решения о преобразовании кооперативов в
товарищества;
в) общая информация о многоквартирных домах, управление которыми осуществляет управляющая
организация, товарищество и кооператив, в том числе характеристика многоквартирного дома (включая
адрес многоквартирного дома, год постройки, этажность, количество квартир, площадь жилых и нежилых
помещений и помещений, входящих в состав общего имущества в многоквартирном доме, уровень
благоустройства, серия и тип постройки, кадастровый номер (при его наличии), площадь земельного
участка, входящего в состав общего имущества в многоквартирном доме, конструктивные и технические
параметры многоквартирного дома), а также информация о системах инженерно-технического обеспечения,
входящих в состав общего имущества в многоквартирном доме;
г) информация о выполняемых работах (оказываемых услугах) по содержанию и ремонту общего имущества в
многоквартирном доме и иных услугах, связанных с достижением целей управления многоквартирным домом,
в том числе сведения о стоимости указанных работ (услуг) и иных услуг;
д) информация об оказываемых коммунальных услугах, в том числе сведения о поставщиках коммунальных
ресурсов, установленных ценах (тарифах) на коммунальные ресурсы, нормативах потребления коммунальных
услуг (нормативах накопления твердых коммунальных отходов);
е) информация об использовании общего имущества в многоквартирном доме;
ж) информация о капитальном ремонте общего имущества в многоквартирном доме. Эти сведения
раскрываются управляющей организацией по решению общего собрания собственников помещений в
многоквартирном доме на основании договора управления в случаях, когда управляющей организации
поручена организация проведения капитального ремонта этого дома, а также товариществом и
кооперативом, за исключением случаев формирования собственниками помещений в многоквартирном доме
фонда капитального ремонта на счете специализированной некоммерческой организации, осуществляющей
деятельность, направленную на обеспечение проведения капитального ремонта общего имущества в
многоквартирном доме (региональный оператор);
з) информация о проведенных общих собраниях собственников помещений в многоквартирном доме,
результатах (решениях) таких собраний;
и) отчет об исполнении управляющей организацией договора управления, отчет об исполнении смет доходов
и расходов товарищества, кооператива за год;
к) информация о случаях привлечения управляющей организации, товарищества и кооператива, должностного
лица управляющей организации, товарищества и кооператива к административной ответственности за
нарушения в сфере управления многоквартирным домом с приложением копий документов о применении мер
административного воздействия, а также сведения о мерах, принятых для устранения нарушений,
повлекших применение административных санкций.
Статья 5.62. Дискриминация
3.Дискриминация, то есть нарушение прав, свобод и законных интересов человека и гражданина в
зависимости от его пола, расы, цвета кожи, национальности, языка, происхождения, имущественного,
семейного, социального и должностного положения, возраста, места жительства, отношения к религии,
убеждений, принадлежности или непринадлежности к общественным объединениям или каким-либо социальным
группам, - влечет наложение административного штрафа на на юридических лиц - от пятидесяти тысяч до
ста тысяч рублей.
Спасибо!
С вами свяжется наш менеджер и поможет вам в регистрации
Спасибо!
С вами свяжется наш менеджер и поможет вам в регистрации
Спасибо!
Ваше сообщение отправлено !
Ваша заявка принята!
Мы получили Вашу заявку, скоро наши менеджеры свяжутся с Вами. Спасибо!
Мы получили Вашу заявку, скоро наши менеджеры свяжутся с Вами. Спасибо!
Мы получили Вашу заявку, скоро наши менеджеры свяжутся с Вами. Спасибо!
Для улучшения работы сайта и его взаимодействие с пользователями мы используем файлы cookie.
Продолжая пользоваться сайтом, вы соглашаетесь с использованием файлов cookie.
Вы всегда можете отключить файлы cookie в настройках браузера.
Подпишись на рассылку новостей ЖКХ, а также наших статей!
С другой стороны, чем больше будет замечаний и встречных предложений - тем лучше. С нами ведь не советовались, когда основные концепции ГИС ЖКХ принимали. Я считаю, что те средства, которые были предоставлены конечному пользователю (УО) - просто безобразны. Ни одна госструктура не вела ещё себя столь нагло. Требуете отчётности - дайте простые, понятные каждому средства её предоставления - какие файлы и какого формата нужно сформировать. И как их отправить. А не интерфейс в виде Web-сервисов. Ввиду сильного подозрения на присутствие тут чьих-то коммерческих интересов, мне кажется, что бодаться разработчики будут до последнего, типа: не хотите сами работать с SOAP - обращайтесь к коммерческим ИС. Но вода камень точит. Будем бодаться и мы. 
Мне бы хотелось, чтобы автоматика обновления шаблонов смогла проанализировать изменения шаблонов (чтобы из новой версии форматов определить название нового поля, название формата данных в поле и обязательность поля, вывести примечание человеку - не нужно искусственного интеллекта) и предложить какие-то действия "ответственному за шаблоны" (например добавить поле в шаблон или убрать из шаблона), если действий достаточно - кликает ОК и все счастливы 
, если недостаточно, то звонит программисту и программист что-то чуть подправляет, например добавляет действие или корректирует алгоритм анализа.
Утром мелькнула идея попробовать для проверки сделать "резидентный монитор" на VBScript + XmlSigned класс, а для интерфейса добавить нечто среднее между нормальной программой и веб-штучками - HTA. Либо сосредоточится на Криптопро + stunnel + DLL (Delphi/Pascal) подписания и отправки + DLL для отчетов (отдельно, чтобы проще заменять, может быть тоже нужно разбить - включая обновление, анализ новой версии, формирование и проверку шаблона), пока без технологии "общей". Конечно, к этому накрутятся всякие конфигурации. Это то, в чем можно получить какие-то результаты в обозримом будущем.
