These are chat archives for springjazzy/GIS_JKH_Integration

14th
Mar 2018
nekoal
@nekoal
Mar 14 2018 01:37
И правда мешанина какая-то.
nekoal
@nekoal
Mar 14 2018 01:44
@Mihdim "он может прийти и без платежки ЕРЦ, он может прийти и заплатить через банк поставщику напрямую" Именно для этого и делается платежка в ГИС, чтобы банк не тупо брал счет УК/РСО, не тупо списывал счет с квитанции, а брал из ГИС конкретный несквитированный ПД и по нему формировал платеж. Ну, по крайней мере, так предполагается когда всё у всех заработает. "поставщик через свою кассу" Это тоже мешанина - передать информацию об оплате должен тот, кто принимает платеж. То есть если принимает банк, то ЕРЦ и поставщик вообще ни при чем - это не считается платежом через кассу поставщика.
nekoal
@nekoal
Mar 14 2018 01:54
@Mihdim Если принимает конкретно кассир поставщика, то есть 2 варианта: 1) платежка ерц и ЛС ерц, тогда ерц прописывает поставщика платежным агентом, поставщик получает функцию платежного агента и поставщик может указать в платеже реквизиты ерц. ЕРЦ все увидит и сквитирует. Через опу, но по логике ГИСа. 2) платежка с реквизитами поставщика, тогда поставщик грузит через Supplier свои платежи, а для получения платежей принятых в ерц, поставщик прописывает ерц платежным агентом и ерц отправляет платежи в ГИС с реквизитами поставщика. В этом случае, ЛС будет поставщика, но при необходимости поставщик может делегировать права информационной системе ЕРЦ.
@Mihdim "И мы говорим про РСО" Это никак не отвечает на вопрос, кто же завел ЛС - РСО или ЕРЦ
nekoal
@nekoal
Mar 14 2018 02:04
@Mihdim "По крайне мере они видны будут и у ЕРЦ и у поставщика" это как раз похоже на случай с делегированием прав. Однако, то что они видны по делегированию, не значит что их можно сквитировать, так как по идее (я не проверял) в операции квитирования должны выбираться только ПД совпадающие по реквизитам с платежом. То есть увидеть по делегированию можно, но сомнительно что возможно сквитировать ПД с реквизитами ЕРЦ и платеж с реквизитами поставщика
nekoal
@nekoal
Mar 14 2018 02:11
а вот если будут ЛС ЕРЦ, ПД с реквизитами ЕРЦ, выставленная ЕРЦ и платеж с получателем ЕРЦ (в том числе загруженный ЕРЦ через Supplier), то они могут квитироваться ЕРЦ. И если будет ЛС поставщика + ПД на поставщика + платеж с получателем поставщиком + делегирование прав от поставщика к ЕРЦ + ЕРЦ как платежный агент поставщика + платежи принятые ЕРЦ не через Supplier, то тоже ЕРЦ может квитировать от имени поставщика
mkpmkp
@mkpmkp
Mar 14 2018 02:33
@sbukhtiyarov @springjazzy Смотрю.
mkpmkp
@mkpmkp
Mar 14 2018 03:38
ТП жжот

Вопрос

Метод "exportNotificationsOfOrderExecutionPaginalRequest"
Параметры:
...
DateFrom date Да 1..1 Нет "Дата нижней границы выборки"
...
Вопрос: DateFrom - это дата чего?

  • Дата совершения платежа
  • Дата размещения платежа
  • Дата обновления информации о платеже (например при аннулировании)

Ответ

DateFrom - дата нижней границы выборки - это дата с которой будет формироваться выборка до текущего момента времени (времени выполнения запроса).


Ланет должен быть разрушен!
Anton
@dudarkoas
Mar 14 2018 03:39
они бы ответили "че, ен можешь сам проверить?", но им нельзя так отвечать
mkpmkp
@mkpmkp
Mar 14 2018 03:40
мне нужен ОФИЦИАЛЬНЫЙ ответ для дальнейшего обращения
Anton
@dudarkoas
Mar 14 2018 03:41
один хер вне зависимости от ответа в "дальнейшем обращении" они могут пересесть на другие рельсы сказав, что оператор ошибся
mkpmkp
@mkpmkp
Mar 14 2018 03:41
потому что метод реализован предельно тупо - хочу заслать предложение для его детупизации
Anton
@dudarkoas
Mar 14 2018 03:42
ты сюда свое предложение напиши, мы его раскритикуем
mkpmkp
@mkpmkp
Mar 14 2018 03:44
хорошее предложение. щас сформулиру́ю
mkpmkp
@mkpmkp
Mar 14 2018 04:02

Метод "exportNotificationsOfOrderExecutionPaginalRequest"
Параметры:
...
DateFrom date Да 1..1 Нет "Дата нижней границы выборки"
...
Вопрос: DateFrom - это дата чего?

Допустим что ответили: DateFrom = "Дата совершения платежа";

Для осуществления квитирования (и контроля) необходимо выгружать из ГЖ все совершенные платежи.
В простейшем случае платежи выгружаются ежедневно за прошлый операционный день.
Но так как платеж может быть размещен за "прошлые" периоды (или аннулирован платеж, например, месячной давности), то простейший случай не работает - новые платежи не будут выгружены, аннулированные не будут учтены.
Придётся регулярно выгружать ВСЁ. С каждым днём объём выгружаемой информации будет расти.
Нужно иметь возможность получать каждый день некоторую ДЕЛЬТУ с изменениями за прошлые периоды.
Варианты:

  1. DateFrom - дата размещения платежа.

Тогда каждый день мы гарантированно забираем ВСЕ размещенные платежи. + забираем за ВЕСЬ период существования ГЖ аннулированые.
Получим полную картину с меньшими затратами.

  1. DateFrom - дата изменения платежа (аннулирован например старый / размещён первый раз новый / изменен (возможно станет можно))

Тогда вообще не надо выкачивать ВСЁ.
Ежедневно тянем дельты и всё.
Для контроля раз в год или по сбою тянем всё.

ЗЫ: То есть функционал метода надо сильно расширять. Иначе со временем утонем в массовых выгрузках.
Это сильно "навскидку". Но в процессе обсуждения может вылиться в рабочий механизм.

mkpmkp
@mkpmkp
Mar 14 2018 04:19
ГЖ на поверку вообще не учитывает что с системой работает больше 1 организации. Нет вообще никаких механизмов для совместной работы над данными.
Anton
@dudarkoas
Mar 14 2018 04:20
не увидел предложения
mkpmkp
@mkpmkp
Mar 14 2018 04:20
Узнать что данные для вас появились в прошлом, что данные аннулированы или изменены можно только регулярными выгрузками ВСЕЙ информации.
Anton
@dudarkoas
Mar 14 2018 04:21
откуда такое утверждение? )
пробовал аннулировать старую оплату и сделать выгрузку за короткий период
?
mkpmkp
@mkpmkp
Mar 14 2018 04:21
Надо предложить расширить функционал. И дать возможность выгружать данные по гораздо большему числу критериев. Критерии эти, соответственно, поддерживать.
@dudarkoas да пробовал - не видим
Anton
@dudarkoas
Mar 14 2018 04:22
ну так тебе сформулировать надо четче постановку, поменьше воды
mkpmkp
@mkpmkp
Mar 14 2018 04:23
постоянно аннулируем всякое. поэтому и вопрос
Anton
@dudarkoas
Mar 14 2018 04:23
при чем формулировать не как доработку, а как дефект
что при выгрузке за период не выгружаются оплаты аннулированные за этот промежуток времени, т.о. невозможно отследить процесс аннулирования сторонними поставщиками информации
mkpmkp
@mkpmkp
Mar 14 2018 04:24
размещаем всякое в прошлом тоже регулярно. ГЖ заявило что надо ждать 3 (три Карл!) дня до повторного размещения если запрос висит в статусе 1
!!! если я прошу данные за 13.03.2018 при том что банк аннулировал в этот день (Дата изменения платежа = 13.03.2018) данные за 12.03.2018, - я не увижу изменений за 12. Надо выгружать ВСЁ. Потому что аннулирован может быть любой платеж, за любой день.

при чем формулировать не как доработку, а как дефект

Задолбимся формулировать - вся система - дефект

nekoal
@nekoal
Mar 14 2018 04:47
если логически рассуждать, то какая дата выводится в ответе, то по ней и интервал в запросе. но где гис и где логика
mkpmkp
@mkpmkp
Mar 14 2018 04:49
@nekoal не понял. в ответе намекнули на то что это за дата?
nekoal
@nekoal
Mar 14 2018 04:51
я про то, что при формировании sql запроса если есть поле даты в части where то скорее всего оно будет включено и в части select
where надо полагать формируется из dateFrom
mkpmkp
@mkpmkp
Mar 14 2018 04:53
так там присутствуют 2 даты. дата размещения и дата платежа
И да - логически я и сам знаю ответ на свой вопрос. пугает что они даже ответить не смогли.
nekoal
@nekoal
Mar 14 2018 04:54
да, то есть дата изменения не фигурирует
mkpmkp
@mkpmkp
Mar 14 2018 04:54
как класс
отсутствует как класс
блин - типа "ДА" - отсутствует :-)
nekoal
@nekoal
Mar 14 2018 04:55
значит, если дорабатывать дату изменения возможно надо будет доставать из журнала изменений
они поленятся мне кажется
для новых бы конечно хватило и даты размещения
mkpmkp
@mkpmkp
Mar 14 2018 04:58
поленятся - это к бабке не ходи. следовательно ВСЕ будем тянуть ежедневно ВСЁ.
nekoal
@nekoal
Mar 14 2018 04:58
но нужно отдельный запрос аннулированных по дате изменения
mkpmkp
@mkpmkp
Mar 14 2018 04:58
можно запрашивать ТОЛЬКО аннулированные - это гораздо меньше информации
но на заре ГЖ мы на ПРОДЕ аннулироваль тысячами
nekoal
@nekoal
Mar 14 2018 05:00
плохо.. тогда может предложить им ограничить срок в течение которого можно аннулировать после размещения?
пару месяцев например
тогда и даты размещения хватит в принципе - за 2 месяца поменьше количество
и "зарю" не захватит
Anton
@dudarkoas
Mar 14 2018 05:02
@nekoal странные у вас предложения
нет бы нормально сделать, вы предлагайте костыль воткнуть
nekoal
@nekoal
Mar 14 2018 05:05
я конечно за нормальное решение, но по факту вопрос не ограничивается тем что мы захлебываемся от старых данных, система тоже все больше будет тупить. Поэтому я вообще за ограничение срока хранения данных. Ограничение срока аннулирования вполне приемлемо с этой точки зрения
пару месяцев наверно достаточно, чтобы платеж дошел до адресата
заметьте, что аннулирование других типов данных я не предлагаю
nekoal
@nekoal
Mar 14 2018 05:18
если сделать дату изменения, то прикинем как: или нужно выбирать из журнала изменений (тут будет долго считываться) или из индексированного поля самой таблицы (тут будет долго записываться за счет обновления индекса при каждой записи). Подобрать баланс будет непросто. Если сейчас выборка по дате платежа/размещения и надо грузить ВСЁ, то чтений гораздо больше, но если сделать дату изменения, то чтений будет примерно равное количество с записями.
Алексей Бугров
@Jenstel33rus_twitter
Mar 14 2018 05:41
@mkpmkp DateFrom - дата создания платежа в системе https://helpdesk.dom.gosuslugi.ru/browse/HCSINTEGRS-4143?
doazet
@doazet
Mar 14 2018 05:42
@Jenstel33rus_twitter у меня каждый раз нестыковка, почему ты тут Алексей, а там Владимир >_<
Алексей Бугров
@Jenstel33rus_twitter
Mar 14 2018 05:43
@doazet у дьявола много имен :smile: :smile: :smile: :smile:
mkpmkp
@mkpmkp
Mar 14 2018 05:45
@Jenstel33rus_twitter это хорошо. ловим только аннулирования...
nekoal
@nekoal
Mar 14 2018 06:20
как раз об этом думал, если добавлять в индекс по дате создания в системе, то время обновления индекса будет малое, так как не придется из середины что-то таскать в конец, просто допишутся новые данные в конец
в итоге ланитовцы похоже рассудили так же))
в который раз убеждаюсь - если хочешь разобраться как что-то работает, вообрази самый ленивый способ как сделать
Алексей Бугров
@Jenstel33rus_twitter
Mar 14 2018 06:25
@nekoal да на это вообще пофиг, ибо у меня, например, ночью все платежи обновляются... у него может статус поменять, банк может аннулировать платеж и мне надо это отловить, пересопоставить, аннулировать квитирование и сквитировать заново...
nekoal
@nekoal
Mar 14 2018 06:26
ну это с точки зрения своей ИС
mkpmkp
@mkpmkp
Mar 14 2018 06:27
прикиньте объем (объёб) данных, которые все со временем будут ежедневно тянуть...
nekoal
@nekoal
Mar 14 2018 06:28
ночь там может быть менее загружена, а в ГИС грузят в любое время суток, то есть при обработке каждого платежа надо индекс обновить, потому что вдруг его через секунду кто-то запросит на чтение. А объем для обновления не маленький в рамках ГИС
тупо дописывать в конец индекса - быстрее
Алексей Бугров
@Jenstel33rus_twitter
Mar 14 2018 06:37
@nekoal а обещали запрос еще по изменениям сущностей, в частности по платежам сделают либо в фильтре еще параметр типа "DateChange", который будет вовзращать только изменения после конкретной даты, либо можно уже щас тупо статусами отлавливать, например, забирать только аннулированные но пока у меня за 45 минут справляется с выгрузкой всего, так что норм, да и актуальность нужна за последние полгода, дальше врятли что могут аннулировать или поменять
mkpmkp
@mkpmkp
Mar 14 2018 06:43
@Jenstel33rus_twitter признаться я думал что DateFrom - это дата платежа. Прям камень с плеч.
Алексей Бугров
@Jenstel33rus_twitter
Mar 14 2018 06:43
А вообще им давно пора подумать насчет запросов только с обновленными данными, как в NSI, чтобы можно было получать только GUID сущности и дату последнего изменения... было бы очень удобно, запросил разок, сверил даты правки, если менялось что-то после того как ты у себя последний раз сохранил - перечитал обратно к себе с последними правками... а то щас приходится все гонять
@mkpmkp изначально может так и задумывалось, но есть возможность заливать задним числом, поэтому ты бы часть просто терял, думая, что за эту дату ты все прочитал уже...
@mkpmkp а с датой создания очень удобно, всегда знаешь по какую именно дату/время ты к себе все забрал
mkpmkp
@mkpmkp
Mar 14 2018 06:46
Хоть тут порядок. Причем в документации не написано что это за дата. ТП на вопрос не отвечает.
Алексей Бугров
@Jenstel33rus_twitter
Mar 14 2018 06:51
@mkpmkp в ТП сидят реальные ТП, уже проверено не раз... им по ошибкам надо неделю доказывать, что ошибка на самом деле имеет место быть и прям досканально показывать где именно, взять хоть проблему с перебором ИЖКУ в ЕЛС
@mkpmkp https://helpdesk.dom.gosuslugi.ru/browse/HCSINTEGRS-4406 вот пример хороший
kolodinivan
@kolodinivan
Mar 14 2018 07:11
раскатал))
mkpmkp
@mkpmkp
Mar 14 2018 07:26
@Jenstel33rus_twitter да... я с ними уже не могу вежливо разговаривать. мои коворкеры не одобряют мой стиль общения с ТП
Последнее письмо - немного постарался оскорбить...
image.png
Алексей Бугров
@Jenstel33rus_twitter
Mar 14 2018 07:32
@mkpmkp это уже нормально, потому что реально пригорает, неделю ждешь ответа и получаешь вот такое...
Anton
@dudarkoas
Mar 14 2018 07:40
зря ты так про эдуардов
у первой линии есть инструкции для ответов, если в инструкции нет ответа, то пытаюся найти тот, что ближе всего по смыслу, если не нашли шлют на вторую линюю
но интеллектуальностью поиск не отличается, это да )
doazet
@doazet
Mar 14 2018 07:55
@dudarkoas ща его за эдуардов забанят >_<
Nikita
@springjazzy
Mar 14 2018 08:29
Целый пласт для исследовательской работы использование уменьшительно-ласкательного имени в переносном смысле в зависимости от региона. У нас Алеша. Где-то Антон. Теперь Эдуард..
ХЗ откуда это..
NadyaTomsk
@NadyaTomsk
Mar 14 2018 08:55
@springjazzy Алеша и Эдуард совсем разные по смыслу. Алеша - свой и любимый всеми дурачок:) Эдуард - эстонский жираф, который или тупой, или просто пока смысл не добрался до мозга:)
Anton
@dudarkoas
Mar 14 2018 08:56
@NadyaTomsk эдуард обычно используется из-за производного имени эдик, что используется как созвучное к слову педик
Nikita
@springjazzy
Mar 14 2018 08:56
фигасе..
Спасибо за этимологический ликбез ))
Алексей Бугров
@Jenstel33rus_twitter
Mar 14 2018 09:00
пора менять имя....
Anton
@dudarkoas
Mar 14 2018 09:01
А имя "Лёха" произносят иногда через "о", что, возможно, тоже как-то характеризует его использование
Anatoly V.
@DrShtopor_twitter
Mar 14 2018 09:02
А имя "Антон" иногда произносят через Г.
Без намёков на присутствующих, доводилось мне работать с одним таким Антоном на букву Г, поэтому и знаю)
Anton
@dudarkoas
Mar 14 2018 09:04
не через, а с
@DrShtopor_twitter про "толик-в-жопе-нолик" тоже все знают
Anatoly V.
@DrShtopor_twitter
Mar 14 2018 09:10
Фантазия русского народа огромна, а уж что касается жопы, то просто безгранична)
Mihdim
@Mihdim
Mar 14 2018 09:37
В итоге по дате платежа DateFrom: т.е если были загружены платежа все за 10.03.2018, а 11.03.2018 аннулировали платеж из другой ИС, то при запросе за 11.03.2018 я не получу данные по аннулированному платежу. так? И чтобы мне иметь актуальные данные по аннулированным платежам, то надо запрашивать повторно за все даты, в которые грузил платежи в гис?
mkpmkp
@mkpmkp
Mar 14 2018 09:38
точно
как тут выяснилось DateFrom - дата РАЗМЕЩЕНИЯ. От аннулирования она не изменится.
mkpmkp
@mkpmkp
Mar 14 2018 09:55
Добро пожаловать в реальный мир, господа. Я покажу Вам насколько глубока кроличья нора.
nekoal
@nekoal
Mar 14 2018 10:10
копирайтеры плачут))
doazet
@doazet
Mar 14 2018 11:10
@mkpmkp
Я покажу Вам насколько глубока кроличья нора.
это ты так слово "жопа" красиво заменил?
fonLeyb
@fonLeyb
Mar 14 2018 13:15
Всем здравствуйте.
Кто что знает по загрузке задолженностей?
Каким образом сейчас ГИС их обрабатывает, аккумулирует / не аккумулирует?
rebyata
@potryasayushche_twitter
Mar 14 2018 13:41
Товарищи, сменился руководитель одной УК. Новый получил ЭЦП, зарегался на госуслугах, сделали его новым директором, старого удалили, дали доступ в ГИС (как админ и уполномоченный спец-ст). Но в ГИСе при входе по логину и паролю только обращения и аналитика. Не сталкивались? Или сперва в ГИС нужно зайти с помощью сертификата?
Алексей Бугров
@Jenstel33rus_twitter
Mar 14 2018 13:43
@potryasayushche_twitter в ГИСе отдельная настройка прав
rebyata
@potryasayushche_twitter
Mar 14 2018 13:43
Вкладки Администрирование нету
Конечно, возможно, что новый дир не подтвердил по почте доступ к ГИСу. Но божиться, что подтверждал.
Mihdim
@Mihdim
Mar 14 2018 13:46
@potryasayushche_twitter там в 3 группы надо добавить 2 админа и уполномоченный спец-ст
@potryasayushche_twitter на этом форуме в поиске вбейте "Инструкция как добавить права сотрудникам" и проверьте
rebyata
@potryasayushche_twitter
Mar 14 2018 13:48
Админ в ЕСИА , админ и специалист в ГИС.
Mihdim
@Mihdim
Mar 14 2018 13:50
@potryasayushche_twitter ну тогда не знаю. этого было достаточно когда подключались: Администратор организации в ГИС ЖКХ, Уполномоченный специалист организации в ГИС ЖКХ, Администраторы профиля организации.
rebyata
@potryasayushche_twitter
Mar 14 2018 13:51
@Mihdim Читанул. Все так же делал. Кроме повторного входа по ЭЦП. Значит, в этом проблема.