Форум

[QUOTE]МихаилИгоревич пишет:
Хочу попросить вас уже заняться делом и совместить 1С и ГИС ЖКХ, через веб сервис.[/QUOTE]
Предлагаю в этой теме обсуждать всё, что касается работы с ГИС ЖКХ в среде 1С. Прошу откликнуться всех, кто уже работает в 1С с ГИС ЖКХ.

[B]Тема заведена для обмена опытом в области работы с файлами формата XLSX (в разных средах программирования и разными средствами). Особенно интересен случай, когда MS Office Excel на компьютере вообще не установлен. Предлагается обсуждать только бесплатные решения.[/B]
=====================================
Начать хотелось бы со среды Visual FoxPro (VFP), в которой программирую я сам, но могут быть рассмотрены самые разные общедоступные средства для среды Windows (открытые DLL-библиотеки).
-----------------------------------------------------------
[QUOTE]Basil пишет:
[QUOTE]AlcorVol пишет:
Интересно, использовали ли тот же проект ([URL=https://vfpx.codeplex.com/wikipage?title=XLSXWorkbook]https://vfpx.codeplex.com/wikipage?title=XLSXWorkbook[/URL]), что и я осваиваю сейчас?[/QUOTE]
Нет, я по старинке: createobject('excel.application')
А с этим проектом скорее всего не получится. Я его попробовал: открыл шаблон ПД, заполнил одну ячейку и сохранил. После этого данный шаблон в excel открывается с ошибками.[/QUOTE]
Итак, речь идёт о проекте VFPxWorkbookXLSX для VFP. Ввиду того, что проект - открытый, можно программный код модифицировать. Так что, есть надежда справиться с какими-то неприятностями. Вот конкретный пример. Попробовал почитать (на основе примера readXLSXfile.prg) файл со списком помещений и ЛС для МКД, выгруженный из ГИС ЖКХ в ЛК. Почти всё почти сразу получилось. За исключением одного нюанса: в книге - два открытых (visible) листа: "Идентификаторы помещений ГИСЖКХ" и "ЕЛС". Однако название первого оказалось обрезанным до 30 символов: "... ГИСЖК". Найти причину (и устранить ошибку) получилось довольно быстро. Метод (процедура) CreateWorkingCursors создаёт временные таблицы (курсоры), в которые выгружает всю информацию книги. Для списка листов создаётся курсор xl_sheets:
    CREATE CURSOR xl_sheets (workbook I, sheet I, shname C(30),  ... )
Заменяем [B]shname C(30)[/B] на [B]shname C(40)[/B] - и всё заработало, как надо. Кстати, имена листов тут уже оказываются перекодированными из UTF-8 в 1251. Чего не скажешь о значениях полей. Но функция STRCONV() легко решает эту задачу:
    lcValue = strconv(lcValue, 11)

Заполнять ячейки я пока не пробовал. [B]Basil[/B] говорит, что у него нечто нечитаемое получается. Возможно, дело как раз в перекодировках (обратная 1251 -> UTF-8 делается так : lcValue = strconv(lcValue, 9) ). Может быть, дело и в чём-то другом. Поэтому попросил бы Basil'а прислать мне на email: [I]alcor <собака> vologda <точка> ru[/I] тестовый XLSX-файл и программку. Хотел бы поэкспериментировать и сам. Как добавлять строки в шаблон - пока не разобрался. Похоже, что писать можно в любую ячейку любой строки методом SetCellValue. Даже если такой строки ещё и не было. Какие тут у тебя мысли, Basil?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Водоканал: [B]Вся вода[/B] (и та, что остаётся холодной, и подогреваемая), а также [B]Водоотведение[/B]. Всё - в кубометрах.
Теплосеть: [B]Отопление[/B] и ... правильно: [B]Подогрев воды[/B]! Всё - в Гигакалориях.

Пусть мне кто-нибудь скажет, что нет такой услуги, как "Подогрев воды". Сразу отвечу анекдотом про Вовочку, который так кончается:
- Что ты, Вовочка! Нет такого слова!
- Ну как же так, Марь Иванна?.. Ж*па-  [B]есть[/B], а слова - [B]нет[/B]...

Короче, вопрос у меня ко всем такой: как в ГИС ЖКХ отразить эту услугу, которой как бы [B]нет[/B], но которая всё равно [B]есть[/B]?

Уважаемые форумчане (а также разработчики ГИС ЖКХ)!

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

Если кто-то с этим не согласен, то можно заглянуть в Гражданский Кодекс РФ (ст. 522 и 319), а также ознакомиться с судебной практикой:
[URL=http://zakoniros.ru/?p=8905]http://zakoniros.ru/?p=8905[/URL]
Цитата оттуда:
[quote:uo0ccy0k]Поскольку у ответчика имелась перед истцом задолженность за более ранние периоды, суды трех инстанций на основании части 3 статьи 522 ГК РФ обоснованно признали правильными действия энергосберегающей компании по зачету поступивших денежных средств в счет погашения задолженности за предыдущие периоды[/quote:uo0ccy0k]

Что скажут на это многоуважаемые разработчики ГИС ЖКХ?  ;)

<Дискуссия перенесена сюда>

[QUOTE]two_oceans пишет:
Ну, если речь только об обмене информацией по HTTPS, то есть пара идей работающих почти на любой Win: 1) XmlHttp объекты -  защищенное соединение устанавливать умеют, куки и прочие заголовки авторизации можно отловить и использовать. Часто использую, чтобы перенести данные с сайта на сайт - при запуске из VBScript нет ограничения к каким доменам соединяться. Вот насчет ГОСТа и ЕСИА не пробовал, но войти на ГИС программно и загружать прямо в личный кабинет - звучит неплохо, хотя конечно не спaсает от XLSX; 2) OpenSSL - с версии 1.0.0 поддерживает ГОСТ встроенно (то есть работает без отдельного установленного криптопровайдера) и еще можно подключить библиотеки для поддержки ГОСТ через криптопровайдера (если установлен) плюс работает не только на Windows и API используется очень широко. Глобальный минус в том, что сертификаты и ключи нужно конвертировать в другой формат. В общем, есть над чем подумать.[/QUOTE]
Спасибо за инфо! Но я из Visual FoxPro, на котором пишу, никогда ни с какими Web-штучками не работал. Не приходилось просто. И до 2017 года - вряд ли успею освоить это дело. Поэтому остаётся сосредоточиться (пока) на формировании XLSX-файлов по шаблонам и анализе ответных файлов (типа списка лицевых счетов). Вчера попробовал просто читать эти XLSX-файлы. Вроде бы, всё прекрасно получается. На очереди - формирование.
[quote:13sxtcf2]Да, теперь мне стало понятнее, почему хотите грузить XML вручную - загружать будут другие. :)[/quote:13sxtcf2]
Не думайте обо мне слишком плохо! Я всегда стараюсь реализовать максимально возможную автоматизацию всех процессов. Но в данной конкретной ситуации у меня просто не остаётся выбора...  :( Да и кто сказал, что SOAP-интерфейс работает без ошибок? Или там в корне иная ситуация?..
[QUOTE]Дамир пишет:
Я вот тоже очень хочу, чтобы грузили 'другие' хотя бы XLSX-файлами (их порождать программно мы научились).
Вопрос ответственности: в условиях "ГИС готова на 100% и все работает" - ежели платежки таки НЕ загрузятся, то кто будет виноват?
Отвечу - криворукие программисты РКЦ.
А вот ежели УК (УО) самостоятельно обломятся при загрузке XLSX-ов на сайт - тут... точно НЕ ГИС, но и НЕ РКЦ.
ГИС-овцы сменили виновных - раньше виновны во всем были 'источники информации' (УК, ТСЖ... но НЕ Росреестр, ФНС).
Щас - РКЦ, которым еще плюсом запретили интеграцию XLSX-файлами[/QUOTE]
Как тут можно что-то кому-то "запретить" - мне не совсем понятно. Мои клиенты работают без всяких РКЦ, хотя попыток насоздавать таких (и затащить туда все УК силком) у нас было немало. А если всякие загрузки идти не будут - всегда можно предъявить ГЖИ загружаемые файлы и ответы от ГИС ЖКХ. Надеюсь, штрафов не будет, если XLSX-файлы были сформированы корректно.