new_year

Форум

ГлавнаяЗагрузка платежей в ГИС

Загрузка платежей в ГИС

RSS
Загрузка платежей в ГИС
 
Уважаемые коллеги по не счастью! Кто знает как идет загрузка платежей в систему. Мы как оператор по приему платежей (платежный агент) имеем: реквизиты организации, ЛС и сумму платежа. Как все это передается в ГИС? подскажите в какую сторону "копать"?
 
Цитата
skad888 пишет:
Уважаемые коллеги по не счастью! Кто знает как идет загрузка платежей в систему. Мы как оператор по приему платежей (платежный агент) имеем: реквизиты организации, ЛС и сумму платежа. Как все это передается в ГИС? подскажите в какую сторону "копать"?

Тут все плохо... Руками или SOAP. :x Шаблонов пока нет...
 
Цитата
portal-gkh пишет:
Тут все плохо... Руками или SOAP. :x Шаблонов пока нет...

SOAP - это я понимаю интеграция? программные решения уже есть? 1с например?
 
Цитата
skad888 пишет:
Цитата
portal-gkh пишет:
Тут все плохо... Руками или SOAP. :x Шаблонов пока нет...

SOAP - это я понимаю интеграция? программные решения уже есть? 1с например?

Да, интеграция. К сожалению, информации о готовых тиражных программных решениях для платежных агентов с интеграцией у меня нет. Про 1С тоже не слышал.
 
А я вчера попыталась привязать платежи Сбербанка, которые они начали выкладывать в ГИСе, к лицевым счетам... не получилось...
 
Цитата
Юлия Т. пишет:
А я вчера попыталась привязать платежи Сбербанка, которые они начали выкладывать в ГИСе, к лицевым счетам... не получилось...

Привязывали, но только руками, так как автомат (автоматическое квитирование) у них не работает. Сейчас бросили это занятие. При том, жильцы жалуются, что у них в личных кабинетах ГИС непогашенная задолженность по ЖКУ висит. ... Либо нужно автомат чинить, либо убрать нафиг информацию о задолженности... Руками привязывать тысячи документов - это бред...
 
Цитата
portal-gkh пишет:
Привязывали, но только руками
А как руками? Я там поискала где чего нажимать - не нашла, кроме автоквитирования ничего...
 
Цитата
Юлия Т. пишет:
Цитата
portal-gkh пишет:
Привязывали, но только руками
А как руками? Я там поискала где чего нажимать - не нашла, кроме автоквитирования ничего...



 
Понятно, буду пробовать, пока платежей не так много. А куда девать платежи, которые между организациями и к плате за жилье или коммунальные услуги не имеют отношения? Оставлять без идентификации или их как-то можно удалять?
 
Цитата
Юлия Т. пишет:
Понятно, буду пробовать, пока платежей не так много. А куда девать платежи, которые между организациями и к плате за жилье или коммунальные услуги не имеют отношения? Оставлять без идентификации или их как-то можно удалять?

Оставляем, удалить их нет возможности.
 
Цитата
Юлия Т. пишет:
А куда девать платежи, которые между организациями и к плате за жилье или коммунальные услуги не имеют отношения? Оставлять без идентификации или их как-то можно удалять?
На второй картинке отметить "Отсутствует возможность сопоставления...". Статус платежа поменяется на "Нет возможности сквитировать".
 
Цитата
skad888 пишет:
Цитата
portal-gkh пишет:
Тут все плохо... Руками или SOAP. :x Шаблонов пока нет...
SOAP - это я понимаю интеграция? программные решения уже есть? 1с например?
Немного не в том форуме вопрос, это ближе к банкам. Если вы платежный агент всех функций для банков не понадобится, но по составу данных все же банки ближе к платежным агентам чем УК. При этом банки работают только через СМЭВ (тоже интеграция на основе SOAP, но немного другие требования), поэтому шаблонов только для платежей вообще не предполагается. Вообще мне казалось кто-то упоминал, что в каком-то шаблоне (ПД?) есть и раздел для платежей. Если как платежный агент проводите все через определенный банк и банк отправляет сведения о платежах в ГИС, то можно попробовать договориться с банком, чтобы информация передавалась от банка (через доп. соглашение и делегирование полномочий).

Для банков есть решения. Например, комплекс iD-Банк, на нем работает больше половины банков. Изначально предполагался для ГИС ГМП и СМЭВ, но были новости что допилили под ГИС ЖКХ. Проблема в том, что банки покупали VipNet Coordinator ы (250-500 тыс. рублей), заключали контракт с Ростелекомом на установку и техподдержку и связываются через координаторы, по каналам СМЭВ. Соответственно если такого координатора нет, то комплекс для банков не подойдет. Потому что, как я понимаю, формат конверта SOAP для СМЭВ отличается от формата SOAP при прямой работе с серверами ГИС.
Как работает комплекс на практике не знаю, не сталкивался. В теории очень красиво сделано - центральная платформа с веб-интерфейсом и базой данных, генерирующая SOAP конверт с подписью. К ней присоединяются адаптеры из ИС клиента в XML и модуль отправляющий подписанный SOAP по каналам СМЭВ. Эту бы платформу да по приемлемой цене. :lol:
 
Цитата
two_oceans пишет:
. Если как платежный агент проводите все через определенный банк и банк отправляет сведения о платежах в ГИС, то можно попробовать договориться с банком, чтобы информация передавалась от банка (через доп. соглашение и делегирование полномочий)..

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

Да. банки работают через СМЭВ, используя ее как транспорт. Пакеты ГИС ЖКХ инкапсулируются в пакеты СМЭВ. Цена у платформы действительно не маленькая. Но это не решает проблему создания обмена с ГИС по SOAP. СМЭВ только транспорт.
 
01 декабря 2016 г. в Санкт-Петербурге на семинаре по ГИС ЖКХ разработчики сайта обещали подготовить шаблон для платежей, которые проходят через кассы УК, РСО, но судя по всему, заби(ы)ли.
 
Цитата
portal-gkh пишет:
Другая ситуация с банковским платежным агентом
Ясно, в таких тонкостях не разбирался. Собственно и цель ГИС в открытости, так что "общей суммой" немного неправильно.
Цитата
portal-gkh пишет:
Да. банки работают через СМЭВ, используя ее как транспорт. Пакеты ГИС ЖКХ инкапсулируются в пакеты СМЭВ. Цена у платформы действительно не маленькая. Но это не решает проблему создания обмена с ГИС по SOAP. СМЭВ только транспорт.
Соглашусь, не решает, но дальше уже можно потратить еще больше и заказать банковский комплекс в минимальной комплектации (так как платежному агенту скорее всего не нужны: документооборот со службой приставов для ареста счетов и проверка физлица по всем открытым данным для выдачи кредита, включенные в полную версию комплекса для банков). Выгрузить из своей ИС xml файл (неподписанный как я понимаю, так как платформа его подпишет при отправке) и скормить его комплексу также не особо проблемно. Повторюсь, как работает на практике не знаю (например, не потребуется ли все же еще одна подпись в инкапсулированном пакете), но теоретически задачу решает.

Вот только для небольшого платежного агента "игра не стоит свеч" просто потому что выйдет дорого (наверно ближе к миллиону за все или даже больше). Даже если Vipnet координатор заменить на Vipnet клиент(8-9 тыс.) на отдельном сервере, заключить соглашение с оператором Р-СМЭВ (то есть без техподдержки Ростелекома), купить банковский комплекс в минимальной комплектации и его поддержку, то все равно наберется круглая сумма. Итого: хотя решения как бы и есть, но нужно решение "без лишних наворотов", строго под нужный функционал.
 
спасибо за информацию. qws с ГИСом все как обычно: функционала - НЕТ, ПО - НЕТ, инструкций -НЕТ ничего не работает, а ответственность ЕСТЬ
 
Цитата
two_oceans пишет:
.. Выгрузить из своей ИС xml файл...

90% трудоемкости при разработке обмена с ГИС по SOAP приходится именно на это... Оставшиеся 10 % - подпись, транспорт. Готовых тиражных решений для платежных агентов, как я уже писал, пока нет (по крайней мере я о них не слышал). IDbank, конечно, можно рассматривать, но у него существующие шлюзы рассчитаны на взаимодействие с банковскими АБС. Так что для своей ИС еще придется пилить. Ну и по деньгам он соответственно стоит. Можно, конечно, еще и банковскую АБС рассматривать в качестве ИС платежного агента. Но это чисто теоретически....
 
Все так. И переходники при такой схеме несомненно придется пилить. С другой стороны, скорее всего ИС можно будет подогнать под один из переходников АБС. В некотором смысле это даже вызов - если в другой ИС лучший формат, то почему не использовать в своей ИС такой формат.
Мне кажется не стоит отдавать 90% трудоемкости на выгрузку xml. Конечно, такое распределение будет если пользоваться .Net, это да. Но для приземленных пользователей других языков, с С# несовместимых, все с точности наоборот - xml можно сляпать в строки десятком способов не используя парсеры, ноды и т.п. Если не вдаватся в дебри, понятийной сложности для среднего программиста не представляет.
А вот над правильной каконикализацией сляпанного и подписью придется покорпеть и здорово загрузиться терминами и алгоритмами. Можно в самом теге подписи сразу каноничный xml сляпать, но от каноникализации самого сообщения это не особо спасает. А уж сколько проблем с эксклюзивностью... одна ГИС требует включения всех пространств, другая наоборот отказывается принимать если пространства объявлены. Или операционно включаете каноникализацию в выгрузку xml? Тогда конечно 90%.
 
Цитата
two_oceans пишет:
,А вот над правильной каконикализацией сляпанного и подписью придется покорпеть и здорово загрузиться терминами и алгоритмами. ,.

Для подписи можно найти готовые библиотеки. Нет смысла изобретать велосипед.... А сформированный xml, конечно, должен быть канонизирован, и для этого тоже можно подобрать инструментарий.
 
Цитата
Для подписи можно найти готовые библиотеки. Нет смысла изобретать велосипед.... А сформированный xml, конечно, должен быть канонизирован, и для этого тоже можно подобрать инструментарий.
Почему-то мне кажется что не пробовали найти? Если исключить .Net и Java (тянет зависимости), а также выполнение OpenSSL в отдельном процессе (не аккуратно), то таки придется изобретать.
1) Теоретически, да, библиотеки есть (для cades как отдельные программы, так и встроенная утилита крипто-про есть, openssl тоже его поддерживает, для xades в открытом доступе пустота). Вот только ни одного полного исходника подписи xades я так и не нашел. Дизассемблить? Может конечно плохо искал, не спорю, но обычно выкладывают только кусочки - саму процедуру подписи, например, которая откровенно не заведется без соответствующего окружения. А какое было окружение - молчок, интуитивно понятно должно быть? Много сообщений на форумах, когда не получается что-то запустить, но когда получилось - правильного варианта исходника не пишут. Даже если ограничиться Delphi - у кого-то в основе модуль JwaWinCrypt, у кого-то WCrypt2 исходный, есть даже WCrypt2 модифицированный с константами крипто-про. В связи с этим у одного код с Pointer(), у кого-то с @, причем противоположный вариант в их окружении не работает. А есть еще версии адаптированные под 64-разрядные операционные системы и неадаптированные. Подбирать окружение методом тыка? Ничем не лучше написания с нуля.

Причем, судя по всему эта процедура подписи везде скопипастена, так как недочеты все те же: при открытии сертификата сообщения об ошибках фиксированной строкой (ага, все одинаково их сформулировали, так я и поверил!), чуть дальше в коде при подписи берутся как должно из системных описаний. Копипастят и даже не исправляют недочеты.
2) Сравните подписи для ГИС и СМЭВ и найдете кучу отличий в способе передачи сертификата, квалифицирующих свойств сертификата, даты подписания, расположения подписи. То есть какая попало подпись по ГОСТ тоже не подойдет, нужно или задавать параметры универсальной процедуре или пилить под конкретную ГИС. С параметрами пока не видел, значит пилить.
3) Инструментарий каноникализации реально есть только в .Net (причем не всяком, только 4.5 и выше, как в требованиях демки ГИС) и, наверно, в Java. Все остальные в пролете - в старых MSXML каноникализация формально есть, но уже не соответствует текущему стандарту и не пройдет проверку подписи в ГИС/СМЭВ. То же касается встроенных исходников Delphi. Это называется "можно подобрать инструментарий"? Аж из 2 разных фреймворков, так как OpenSSL здесь не поможет.
Вот только, если хоть бы одна библиотека будет использовать .Net или Java, то потянет зависимость для всего программного пакета. Все больше склоняюсь к варианту выпилить каноникализацию из .Net. Нашел скомпилированную программку каноникализации на основе .Net, можно отследить зависимости, но скорее всего выпилить будет не так просто.Вот и выходит, что вроде есть библиотеки, а вроде и нет. Наверно дискуссию лучше в разделе программного обеспечения продолжить. Возвращаясь к теме - всё как и с решениями для платежных агентов - вроде и есть, а вроде и нет.
 
Цитата
two_oceans пишет:
Вот и выходит, что вроде есть библиотеки, а вроде и нет. Наверно дискуссию лучше в разделе программного обеспечения продолжить. Возвращаясь к теме - всё как и с решениями для платежных агентов - вроде и есть, а вроде и нет.

Тем не менее, реализованные проекты интеграции по SOAP с ГИС ЖКХ (транспорт СМЭВ), сделанные в том числе на почти стандартных библиотеках (Java с косметическими изменениями) существуют. Цель реализовать весь обмен внутри одного фреймворка не ставилась.
 
Я вот ломаю голову не первую неделю. Банки разослали письма,что будут грузить платежи. ( ну некоторое банки) попыталась найти специалистов в банках, которые занимаются ГИСом. Безрезультатно.
Теперь допустим: банк принял платежи от нежилья ( жилье у нас через ркц) и каким то волшебным образом разместил платежи. В свою очередь мы тоже разносим платежи, которые поступили к нам в кассу, прошли взаимозачетами. Ну вроде бы должно быть так.
А как банк поймет по платежному поручению, за что платит ООО "Дубок", если в тексте платежки написано: Оплата по договору, оплата по счету,
Получится, я надеюсь,что этот платеж разносит банк, а банк даже не знает об этом. Или я решаю,что банк платеж не увидел, а банк его как разувидел и разместил в ГИС. Чё ж делать то?

Отправлено спустя 1 минуту 10 секунды:
мне бы лучше было, если б банки вообще ничего не заносили.
 
Цитата
Ялиса пишет:
Я вот ломаю голову не первую неделю. Банки разослали письма,что будут грузить платежи. ( ну некоторое банки) попыталась найти специалистов в банках, которые занимаются ГИСом. Безрезультатно.
Теперь допустим: банк принял платежи от нежилья ( жилье у нас через ркц) и каким то волшебным образом разместил платежи. В свою очередь мы тоже разносим платежи, которые поступили к нам в кассу, прошли взаимозачетами. Ну вроде бы должно быть так.
А как банк поймет по платежному поручению, за что платит ООО "Дубок", если в тексте платежки написано: Оплата по договору, оплата по счету,
Получится, я надеюсь,что этот платеж разносит банк, а банк даже не знает об этом. Или я решаю,что банк платеж не увидел, а банк его как разувидел и разместил в ГИС. Чё ж делать то?

Отправлено спустя 1 минуту 10 секунды:
мне бы лучше было, если б банки вообще ничего не заносили.

вроде здесь viewtopic.php?f=133&t=7766 тут обсуждалась проблема "мусорных платежей" в ГИС. Проблема в том что Банки валят в ГИС все платежи без разбора.
 
Цитата
Ялиса пишет:
попыталась найти специалистов в банках, которые занимаются ГИСом. Безрезультатно.
В каких банках искали? (мы ряд контактов установили)
 
ЕМБ, СКБ, нет контактов.Если есть,киньте в личку
Я сама платежей наших банков еще не видела. У нас разные виды деятельности, есть те работы,которые не нужны ГИСу.
 
Цитата
skad888 пишет:

вроде здесь viewtopic.php?f=133&t=7766 тут обсуждалась проблема "мусорных платежей" в ГИС.
Могу еще рыбное место подсказать. Только там самая дискуссия полтора-два года назад была, сейчас малоактивно.
Цитата
skad888 пишет:
Проблема в том что Банки валят в ГИС все платежи без разбора.
С банками работать можно. Мы с февраля вышли на средний уровень 96% квитируемых фактов оплаты (по размещенным фактам оплаты, включая частично и предварительно сквитированные).
Сложнее всего у банков обстоят дела с каналами оплаты для бизнеса (с расчетных счетов) - ими в банках занимаются отдельные подразделения и там требования ГИС ЖКХ практически у всех банков по сути не реализованы или реализованы очень примитивно. И федеральное казначейство там же.

Отправлено спустя 3 минуты 29 секунды:
Цитата
Ялиса пишет:
ЕМБ, СКБ, нет контактов.Если есть,киньте в личку
Свердловская область? По этим не подскажу, с ними не пересекался.
 
свердловская. Дело в том,что население меня не беспокоит, там все через расчетный центр. Меня платежи по нежити волнуют.
 
Чет мы впали в ступор и не можем из него вылезти....
Мы РСО, через нашу кассу идут платежи только по нашим квитанциям. Соответственно, мы должны размещать информацию по оплатам.
В функциях организации добавили "Оператор по приему платежей". Важно или нет, не знаю, но по этой функции статус "Заявлено организацией", а по остальным - "Подтверждено". Причем это и на рабочей базе и на втором тестовом сервере (на первый тестовый уже не ходим). При попытке закинуть оплату (интеграцией) возникает ошибка " AUT011009: Операция не разрешена". Судя по всему, не хватает каких-то настроек. Но вот каких - мы х.з.... Может кто столкнулся с такой бедой?? Попытался руками завести оплату - вроде как завелась
 
Цитата
Мы РСО, через нашу кассу идут платежи только по нашим квитанциям. Соответственно, мы должны размещать информацию по оплатам.
В функциях организации добавили "Оператор по приему платежей". Важно или нет, не знаю, но по этой функции статус "Заявлено организацией", а по остальным - "Подтверждено".
Статус должен быть "Подтверждено". Однако, как я понимаю, в свой адрес можно грузить платежи и без этой функции. В правах, которые делегированы своей информационной системе должны быть разрешены операции с платежами. Если Вы размещаете только платежи в свой адрес принятые в свою кассу, то при интеграции нужно использовать метод загрузки платежей со словом Supplier. Однако будьте внимательны - он запрашивает гораздо меньше реквизитов и потому этим методом легко наделать дублей платежа - ГИС не хватает реквизитов для выявления дублей.
#1
0 0
Уважаемые коллеги по не счастью! Кто знает как идет загрузка платежей в систему. Мы как оператор по приему платежей (платежный агент) имеем: реквизиты организации, ЛС и сумму платежа. Как все это передается в ГИС? подскажите в какую сторону "копать"?
#2
0 0
Цитата
skad888 пишет:
Уважаемые коллеги по не счастью! Кто знает как идет загрузка платежей в систему. Мы как оператор по приему платежей (платежный агент) имеем: реквизиты организации, ЛС и сумму платежа. Как все это передается в ГИС? подскажите в какую сторону "копать"?

Тут все плохо... Руками или SOAP. :x Шаблонов пока нет...
#3
0 0
Цитата
portal-gkh пишет:
Тут все плохо... Руками или SOAP. :x Шаблонов пока нет...

SOAP - это я понимаю интеграция? программные решения уже есть? 1с например?
#4
0 0
Цитата
skad888 пишет:
Цитата
portal-gkh пишет:
Тут все плохо... Руками или SOAP. :x Шаблонов пока нет...

SOAP - это я понимаю интеграция? программные решения уже есть? 1с например?

Да, интеграция. К сожалению, информации о готовых тиражных программных решениях для платежных агентов с интеграцией у меня нет. Про 1С тоже не слышал.
#5
0 0
А я вчера попыталась привязать платежи Сбербанка, которые они начали выкладывать в ГИСе, к лицевым счетам... не получилось...
#6
0 0
Цитата
Юлия Т. пишет:
А я вчера попыталась привязать платежи Сбербанка, которые они начали выкладывать в ГИСе, к лицевым счетам... не получилось...

Привязывали, но только руками, так как автомат (автоматическое квитирование) у них не работает. Сейчас бросили это занятие. При том, жильцы жалуются, что у них в личных кабинетах ГИС непогашенная задолженность по ЖКУ висит. ... Либо нужно автомат чинить, либо убрать нафиг информацию о задолженности... Руками привязывать тысячи документов - это бред...
#7
0 0
Цитата
portal-gkh пишет:
Привязывали, но только руками
А как руками? Я там поискала где чего нажимать - не нашла, кроме автоквитирования ничего...
#8
0 0
Цитата
Юлия Т. пишет:
Цитата
portal-gkh пишет:
Привязывали, но только руками
А как руками? Я там поискала где чего нажимать - не нашла, кроме автоквитирования ничего...



Screenshot_98.jpg (116.41 КБ)
Screenshot_99.jpg (75.51 КБ)
Screenshot_100.jpg (83.07 КБ)
#9
0 0
Понятно, буду пробовать, пока платежей не так много. А куда девать платежи, которые между организациями и к плате за жилье или коммунальные услуги не имеют отношения? Оставлять без идентификации или их как-то можно удалять?
#10
0 0
Цитата
Юлия Т. пишет:
Понятно, буду пробовать, пока платежей не так много. А куда девать платежи, которые между организациями и к плате за жилье или коммунальные услуги не имеют отношения? Оставлять без идентификации или их как-то можно удалять?

Оставляем, удалить их нет возможности.
#11
0 0
Цитата
Юлия Т. пишет:
А куда девать платежи, которые между организациями и к плате за жилье или коммунальные услуги не имеют отношения? Оставлять без идентификации или их как-то можно удалять?
На второй картинке отметить "Отсутствует возможность сопоставления...". Статус платежа поменяется на "Нет возможности сквитировать".
#12
0 0
Цитата
skad888 пишет:
Цитата
portal-gkh пишет:
Тут все плохо... Руками или SOAP. :x Шаблонов пока нет...
SOAP - это я понимаю интеграция? программные решения уже есть? 1с например?
Немного не в том форуме вопрос, это ближе к банкам. Если вы платежный агент всех функций для банков не понадобится, но по составу данных все же банки ближе к платежным агентам чем УК. При этом банки работают только через СМЭВ (тоже интеграция на основе SOAP, но немного другие требования), поэтому шаблонов только для платежей вообще не предполагается. Вообще мне казалось кто-то упоминал, что в каком-то шаблоне (ПД?) есть и раздел для платежей. Если как платежный агент проводите все через определенный банк и банк отправляет сведения о платежах в ГИС, то можно попробовать договориться с банком, чтобы информация передавалась от банка (через доп. соглашение и делегирование полномочий).

Для банков есть решения. Например, комплекс iD-Банк, на нем работает больше половины банков. Изначально предполагался для ГИС ГМП и СМЭВ, но были новости что допилили под ГИС ЖКХ. Проблема в том, что банки покупали VipNet Coordinator ы (250-500 тыс. рублей), заключали контракт с Ростелекомом на установку и техподдержку и связываются через координаторы, по каналам СМЭВ. Соответственно если такого координатора нет, то комплекс для банков не подойдет. Потому что, как я понимаю, формат конверта SOAP для СМЭВ отличается от формата SOAP при прямой работе с серверами ГИС.
Как работает комплекс на практике не знаю, не сталкивался. В теории очень красиво сделано - центральная платформа с веб-интерфейсом и базой данных, генерирующая SOAP конверт с подписью. К ней присоединяются адаптеры из ИС клиента в XML и модуль отправляющий подписанный SOAP по каналам СМЭВ. Эту бы платформу да по приемлемой цене. :lol:
#13
0 0
Цитата
two_oceans пишет:
. Если как платежный агент проводите все через определенный банк и банк отправляет сведения о платежах в ГИС, то можно попробовать договориться с банком, чтобы информация передавалась от банка (через доп. соглашение и делегирование полномочий)..

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

Да. банки работают через СМЭВ, используя ее как транспорт. Пакеты ГИС ЖКХ инкапсулируются в пакеты СМЭВ. Цена у платформы действительно не маленькая. Но это не решает проблему создания обмена с ГИС по SOAP. СМЭВ только транспорт.
#14
0 0
01 декабря 2016 г. в Санкт-Петербурге на семинаре по ГИС ЖКХ разработчики сайта обещали подготовить шаблон для платежей, которые проходят через кассы УК, РСО, но судя по всему, заби(ы)ли.
#15
0 0
Цитата
portal-gkh пишет:
Другая ситуация с банковским платежным агентом
Ясно, в таких тонкостях не разбирался. Собственно и цель ГИС в открытости, так что "общей суммой" немного неправильно.
Цитата
portal-gkh пишет:
Да. банки работают через СМЭВ, используя ее как транспорт. Пакеты ГИС ЖКХ инкапсулируются в пакеты СМЭВ. Цена у платформы действительно не маленькая. Но это не решает проблему создания обмена с ГИС по SOAP. СМЭВ только транспорт.
Соглашусь, не решает, но дальше уже можно потратить еще больше и заказать банковский комплекс в минимальной комплектации (так как платежному агенту скорее всего не нужны: документооборот со службой приставов для ареста счетов и проверка физлица по всем открытым данным для выдачи кредита, включенные в полную версию комплекса для банков). Выгрузить из своей ИС xml файл (неподписанный как я понимаю, так как платформа его подпишет при отправке) и скормить его комплексу также не особо проблемно. Повторюсь, как работает на практике не знаю (например, не потребуется ли все же еще одна подпись в инкапсулированном пакете), но теоретически задачу решает.

Вот только для небольшого платежного агента "игра не стоит свеч" просто потому что выйдет дорого (наверно ближе к миллиону за все или даже больше). Даже если Vipnet координатор заменить на Vipnet клиент(8-9 тыс.) на отдельном сервере, заключить соглашение с оператором Р-СМЭВ (то есть без техподдержки Ростелекома), купить банковский комплекс в минимальной комплектации и его поддержку, то все равно наберется круглая сумма. Итого: хотя решения как бы и есть, но нужно решение "без лишних наворотов", строго под нужный функционал.
#16
0 0
спасибо за информацию. qws с ГИСом все как обычно: функционала - НЕТ, ПО - НЕТ, инструкций -НЕТ ничего не работает, а ответственность ЕСТЬ
#17
0 0
Цитата
two_oceans пишет:
.. Выгрузить из своей ИС xml файл...

90% трудоемкости при разработке обмена с ГИС по SOAP приходится именно на это... Оставшиеся 10 % - подпись, транспорт. Готовых тиражных решений для платежных агентов, как я уже писал, пока нет (по крайней мере я о них не слышал). IDbank, конечно, можно рассматривать, но у него существующие шлюзы рассчитаны на взаимодействие с банковскими АБС. Так что для своей ИС еще придется пилить. Ну и по деньгам он соответственно стоит. Можно, конечно, еще и банковскую АБС рассматривать в качестве ИС платежного агента. Но это чисто теоретически....
#18
0 0
Все так. И переходники при такой схеме несомненно придется пилить. С другой стороны, скорее всего ИС можно будет подогнать под один из переходников АБС. В некотором смысле это даже вызов - если в другой ИС лучший формат, то почему не использовать в своей ИС такой формат.
Мне кажется не стоит отдавать 90% трудоемкости на выгрузку xml. Конечно, такое распределение будет если пользоваться .Net, это да. Но для приземленных пользователей других языков, с С# несовместимых, все с точности наоборот - xml можно сляпать в строки десятком способов не используя парсеры, ноды и т.п. Если не вдаватся в дебри, понятийной сложности для среднего программиста не представляет.
А вот над правильной каконикализацией сляпанного и подписью придется покорпеть и здорово загрузиться терминами и алгоритмами. Можно в самом теге подписи сразу каноничный xml сляпать, но от каноникализации самого сообщения это не особо спасает. А уж сколько проблем с эксклюзивностью... одна ГИС требует включения всех пространств, другая наоборот отказывается принимать если пространства объявлены. Или операционно включаете каноникализацию в выгрузку xml? Тогда конечно 90%.
#19
0 0
Цитата
two_oceans пишет:
,А вот над правильной каконикализацией сляпанного и подписью придется покорпеть и здорово загрузиться терминами и алгоритмами. ,.

Для подписи можно найти готовые библиотеки. Нет смысла изобретать велосипед.... А сформированный xml, конечно, должен быть канонизирован, и для этого тоже можно подобрать инструментарий.
#20
0 0
Цитата
Для подписи можно найти готовые библиотеки. Нет смысла изобретать велосипед.... А сформированный xml, конечно, должен быть канонизирован, и для этого тоже можно подобрать инструментарий.
Почему-то мне кажется что не пробовали найти? Если исключить .Net и Java (тянет зависимости), а также выполнение OpenSSL в отдельном процессе (не аккуратно), то таки придется изобретать.
1) Теоретически, да, библиотеки есть (для cades как отдельные программы, так и встроенная утилита крипто-про есть, openssl тоже его поддерживает, для xades в открытом доступе пустота). Вот только ни одного полного исходника подписи xades я так и не нашел. Дизассемблить? Может конечно плохо искал, не спорю, но обычно выкладывают только кусочки - саму процедуру подписи, например, которая откровенно не заведется без соответствующего окружения. А какое было окружение - молчок, интуитивно понятно должно быть? Много сообщений на форумах, когда не получается что-то запустить, но когда получилось - правильного варианта исходника не пишут. Даже если ограничиться Delphi - у кого-то в основе модуль JwaWinCrypt, у кого-то WCrypt2 исходный, есть даже WCrypt2 модифицированный с константами крипто-про. В связи с этим у одного код с Pointer(), у кого-то с @, причем противоположный вариант в их окружении не работает. А есть еще версии адаптированные под 64-разрядные операционные системы и неадаптированные. Подбирать окружение методом тыка? Ничем не лучше написания с нуля.

Причем, судя по всему эта процедура подписи везде скопипастена, так как недочеты все те же: при открытии сертификата сообщения об ошибках фиксированной строкой (ага, все одинаково их сформулировали, так я и поверил!), чуть дальше в коде при подписи берутся как должно из системных описаний. Копипастят и даже не исправляют недочеты.
2) Сравните подписи для ГИС и СМЭВ и найдете кучу отличий в способе передачи сертификата, квалифицирующих свойств сертификата, даты подписания, расположения подписи. То есть какая попало подпись по ГОСТ тоже не подойдет, нужно или задавать параметры универсальной процедуре или пилить под конкретную ГИС. С параметрами пока не видел, значит пилить.
3) Инструментарий каноникализации реально есть только в .Net (причем не всяком, только 4.5 и выше, как в требованиях демки ГИС) и, наверно, в Java. Все остальные в пролете - в старых MSXML каноникализация формально есть, но уже не соответствует текущему стандарту и не пройдет проверку подписи в ГИС/СМЭВ. То же касается встроенных исходников Delphi. Это называется "можно подобрать инструментарий"? Аж из 2 разных фреймворков, так как OpenSSL здесь не поможет.
Вот только, если хоть бы одна библиотека будет использовать .Net или Java, то потянет зависимость для всего программного пакета. Все больше склоняюсь к варианту выпилить каноникализацию из .Net. Нашел скомпилированную программку каноникализации на основе .Net, можно отследить зависимости, но скорее всего выпилить будет не так просто.Вот и выходит, что вроде есть библиотеки, а вроде и нет. Наверно дискуссию лучше в разделе программного обеспечения продолжить. Возвращаясь к теме - всё как и с решениями для платежных агентов - вроде и есть, а вроде и нет.
#21
0 0
Цитата
two_oceans пишет:
Вот и выходит, что вроде есть библиотеки, а вроде и нет. Наверно дискуссию лучше в разделе программного обеспечения продолжить. Возвращаясь к теме - всё как и с решениями для платежных агентов - вроде и есть, а вроде и нет.

Тем не менее, реализованные проекты интеграции по SOAP с ГИС ЖКХ (транспорт СМЭВ), сделанные в том числе на почти стандартных библиотеках (Java с косметическими изменениями) существуют. Цель реализовать весь обмен внутри одного фреймворка не ставилась.
#22
0 0
Я вот ломаю голову не первую неделю. Банки разослали письма,что будут грузить платежи. ( ну некоторое банки) попыталась найти специалистов в банках, которые занимаются ГИСом. Безрезультатно.
Теперь допустим: банк принял платежи от нежилья ( жилье у нас через ркц) и каким то волшебным образом разместил платежи. В свою очередь мы тоже разносим платежи, которые поступили к нам в кассу, прошли взаимозачетами. Ну вроде бы должно быть так.
А как банк поймет по платежному поручению, за что платит ООО "Дубок", если в тексте платежки написано: Оплата по договору, оплата по счету,
Получится, я надеюсь,что этот платеж разносит банк, а банк даже не знает об этом. Или я решаю,что банк платеж не увидел, а банк его как разувидел и разместил в ГИС. Чё ж делать то?

Отправлено спустя 1 минуту 10 секунды:
мне бы лучше было, если б банки вообще ничего не заносили.
#23
0 0
Цитата
Ялиса пишет:
Я вот ломаю голову не первую неделю. Банки разослали письма,что будут грузить платежи. ( ну некоторое банки) попыталась найти специалистов в банках, которые занимаются ГИСом. Безрезультатно.
Теперь допустим: банк принял платежи от нежилья ( жилье у нас через ркц) и каким то волшебным образом разместил платежи. В свою очередь мы тоже разносим платежи, которые поступили к нам в кассу, прошли взаимозачетами. Ну вроде бы должно быть так.
А как банк поймет по платежному поручению, за что платит ООО "Дубок", если в тексте платежки написано: Оплата по договору, оплата по счету,
Получится, я надеюсь,что этот платеж разносит банк, а банк даже не знает об этом. Или я решаю,что банк платеж не увидел, а банк его как разувидел и разместил в ГИС. Чё ж делать то?

Отправлено спустя 1 минуту 10 секунды:
мне бы лучше было, если б банки вообще ничего не заносили.

вроде здесь viewtopic.php?f=133&t=7766 тут обсуждалась проблема "мусорных платежей" в ГИС. Проблема в том что Банки валят в ГИС все платежи без разбора.
#24
0 0
Цитата
Ялиса пишет:
попыталась найти специалистов в банках, которые занимаются ГИСом. Безрезультатно.
В каких банках искали? (мы ряд контактов установили)
#25
0 0
ЕМБ, СКБ, нет контактов.Если есть,киньте в личку
Я сама платежей наших банков еще не видела. У нас разные виды деятельности, есть те работы,которые не нужны ГИСу.
#26
0 0
Цитата
skad888 пишет:

вроде здесь viewtopic.php?f=133&t=7766 тут обсуждалась проблема "мусорных платежей" в ГИС.
Могу еще рыбное место подсказать. Только там самая дискуссия полтора-два года назад была, сейчас малоактивно.
Цитата
skad888 пишет:
Проблема в том что Банки валят в ГИС все платежи без разбора.
С банками работать можно. Мы с февраля вышли на средний уровень 96% квитируемых фактов оплаты (по размещенным фактам оплаты, включая частично и предварительно сквитированные).
Сложнее всего у банков обстоят дела с каналами оплаты для бизнеса (с расчетных счетов) - ими в банках занимаются отдельные подразделения и там требования ГИС ЖКХ практически у всех банков по сути не реализованы или реализованы очень примитивно. И федеральное казначейство там же.

Отправлено спустя 3 минуты 29 секунды:
Цитата
Ялиса пишет:
ЕМБ, СКБ, нет контактов.Если есть,киньте в личку
Свердловская область? По этим не подскажу, с ними не пересекался.
#27
0 0
свердловская. Дело в том,что население меня не беспокоит, там все через расчетный центр. Меня платежи по нежити волнуют.
#28
0 0
Чет мы впали в ступор и не можем из него вылезти....
Мы РСО, через нашу кассу идут платежи только по нашим квитанциям. Соответственно, мы должны размещать информацию по оплатам.
В функциях организации добавили "Оператор по приему платежей". Важно или нет, не знаю, но по этой функции статус "Заявлено организацией", а по остальным - "Подтверждено". Причем это и на рабочей базе и на втором тестовом сервере (на первый тестовый уже не ходим). При попытке закинуть оплату (интеграцией) возникает ошибка " AUT011009: Операция не разрешена". Судя по всему, не хватает каких-то настроек. Но вот каких - мы х.з.... Может кто столкнулся с такой бедой?? Попытался руками завести оплату - вроде как завелась
#29
0 0
Цитата
Мы РСО, через нашу кассу идут платежи только по нашим квитанциям. Соответственно, мы должны размещать информацию по оплатам.
В функциях организации добавили "Оператор по приему платежей". Важно или нет, не знаю, но по этой функции статус "Заявлено организацией", а по остальным - "Подтверждено".
Статус должен быть "Подтверждено". Однако, как я понимаю, в свой адрес можно грузить платежи и без этой функции. В правах, которые делегированы своей информационной системе должны быть разрешены операции с платежами. Если Вы размещаете только платежи в свой адрес принятые в свою кассу, то при интеграции нужно использовать метод загрузки платежей со словом Supplier. Однако будьте внимательны - он запрашивает гораздо меньше реквизитов и потому этим методом легко наделать дублей платежа - ГИС не хватает реквизитов для выявления дублей.
Сейчас на форуме: 6 пользователей
6 пользователей сейчас на форуме

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

Подпишись на рассылку новостей ЖКХ, а также наших статей!

Спасибо, вы успешно подписались на рассылку!