Работоспособность стенда - https://docs.google.com/spreadsheets/d/1nsXtcD5E5ZaCysFPu6mPLF7fEPY2Zcri3iPgPhS44aY/edit?usp=sharing
И правда мешанина какая-то.
@Mihdim "он может прийти и без платежки ЕРЦ, он может прийти и заплатить через банк поставщику напрямую" Именно для этого и делается платежка в ГИС, чтобы банк не тупо брал счет УК/РСО, не тупо списывал счет с квитанции, а брал из ГИС конкретный несквитированный ПД и по нему формировал платеж. Ну, по крайней мере, так предполагается когда всё у всех заработает. "поставщик через свою кассу" Это тоже мешанина - передать информацию об оплате должен тот, кто принимает платеж. То есть если принимает банк, то ЕРЦ и поставщик вообще ни при чем - это не считается платежом через кассу поставщика.
@Mihdim Если принимает конкретно кассир поставщика, то есть 2 варианта: 1) платежка ерц и ЛС ерц, тогда ерц прописывает поставщика платежным агентом, поставщик получает функцию платежного агента и поставщик может указать в платеже реквизиты ерц. ЕРЦ все увидит и сквитирует. Через опу, но по логике ГИСа. 2) платежка с реквизитами поставщика, тогда поставщик грузит через Supplier свои платежи, а для получения платежей принятых в ерц, поставщик прописывает ерц платежным агентом и ерц отправляет платежи в ГИС с реквизитами поставщика. В этом случае, ЛС будет поставщика, но при необходимости поставщик может делегировать права информационной системе ЕРЦ.
@Mihdim "И мы говорим про РСО" Это никак не отвечает на вопрос, кто же завел ЛС - РСО или ЕРЦ
@Mihdim "По крайне мере они видны будут и у ЕРЦ и у поставщика" это как раз похоже на случай с делегированием прав. Однако, то что они видны по делегированию, не значит что их можно сквитировать, так как по идее (я не проверял) в операции квитирования должны выбираться только ПД совпадающие по реквизитам с платежом. То есть увидеть по делегированию можно, но сомнительно что возможно сквитировать ПД с реквизитами ЕРЦ и платеж с реквизитами поставщика
а вот если будут ЛС ЕРЦ, ПД с реквизитами ЕРЦ, выставленная ЕРЦ и платеж с получателем ЕРЦ (в том числе загруженный ЕРЦ через Supplier), то они могут квитироваться ЕРЦ. И если будет ЛС поставщика + ПД на поставщика + платеж с получателем поставщиком + делегирование прав от поставщика к ЕРЦ + ЕРЦ как платежный агент поставщика + платежи принятые ЕРЦ не через Supplier, то тоже ЕРЦ может квитировать от имени поставщика
@sbukhtiyarov @springjazzy Смотрю.
ТП жжот
Вопрос
Метод "exportNotificationsOfOrderExecutionPaginalRequest"
Параметры:
...
DateFrom date Да 1..1 Нет "Дата нижней границы выборки"
...
Вопрос: DateFrom - это дата чего?
- Дата совершения платежа
- Дата размещения платежа
- Дата обновления информации о платеже (например при аннулировании)
Ответ
DateFrom - дата нижней границы выборки - это дата с которой будет формироваться выборка до текущего момента времени (времени выполнения запроса).
Ланет должен быть разрушен!
они бы ответили "че, ен можешь сам проверить?", но им нельзя так отвечать
мне нужен ОФИЦИАЛЬНЫЙ ответ для дальнейшего обращения
один хер вне зависимости от ответа в "дальнейшем обращении" они могут пересесть на другие рельсы сказав, что оператор ошибся
потому что метод реализован предельно тупо - хочу заслать предложение для его детупизации
ты сюда свое предложение напиши, мы его раскритикуем
хорошее предложение. щас сформулиру́ю
Метод "exportNotificationsOfOrderExecutionPaginalRequest"
Параметры:
...
DateFrom date Да 1..1 Нет "Дата нижней границы выборки"
...
Вопрос: DateFrom - это дата чего?
Допустим что ответили: DateFrom = "Дата совершения платежа";
Для осуществления квитирования (и контроля) необходимо выгружать из ГЖ все совершенные платежи.
В простейшем случае платежи выгружаются ежедневно за прошлый операционный день.
Но так как платеж может быть размещен за "прошлые" периоды (или аннулирован платеж, например, месячной давности), то простейший случай не работает - новые платежи не будут выгружены, аннулированные не будут учтены.
Придётся регулярно выгружать ВСЁ. С каждым днём объём выгружаемой информации будет расти.
Нужно иметь возможность получать каждый день некоторую ДЕЛЬТУ с изменениями за прошлые периоды.
Варианты:
- DateFrom - дата размещения платежа.
Тогда каждый день мы гарантированно забираем ВСЕ размещенные платежи. + забираем за ВЕСЬ период существования ГЖ аннулированые.
Получим полную картину с меньшими затратами.
- DateFrom - дата изменения платежа (аннулирован например старый / размещён первый раз новый / изменен (возможно станет можно))
Тогда вообще не надо выкачивать ВСЁ.
Ежедневно тянем дельты и всё.
Для контроля раз в год или по сбою тянем всё.
ЗЫ: То есть функционал метода надо сильно расширять. Иначе со временем утонем в массовых выгрузках.
Это сильно "навскидку". Но в процессе обсуждения может вылиться в рабочий механизм.
ГЖ на поверку вообще не учитывает что с системой работает больше 1 организации. Нет вообще никаких механизмов для совместной работы над данными.
не увидел предложения
Узнать что данные для вас появились в прошлом, что данные аннулированы или изменены можно только регулярными выгрузками ВСЕЙ информации.
откуда такое утверждение? )
пробовал аннулировать старую оплату и сделать выгрузку за короткий период
?
Надо предложить расширить функционал. И дать возможность выгружать данные по гораздо большему числу критериев. Критерии эти, соответственно, поддерживать.
@dudarkoas да пробовал - не видим
ну так тебе сформулировать надо четче постановку, поменьше воды
постоянно аннулируем всякое. поэтому и вопрос
при чем формулировать не как доработку, а как дефект
что при выгрузке за период не выгружаются оплаты аннулированные за этот промежуток времени, т.о. невозможно отследить процесс аннулирования сторонними поставщиками информации
размещаем всякое в прошлом тоже регулярно. ГЖ заявило что надо ждать 3 (три Карл!) дня до повторного размещения если запрос висит в статусе 1
!!! если я прошу данные за 13.03.2018 при том что банк аннулировал в этот день (Дата изменения платежа = 13.03.2018) данные за 12.03.2018, - я не увижу изменений за 12. Надо выгружать ВСЁ. Потому что аннулирован может быть любой платеж, за любой день.
при чем формулировать не как доработку, а как дефект
Задолбимся формулировать - вся система - дефект
если логически рассуждать, то какая дата выводится в ответе, то по ней и интервал в запросе. но где гис и где логика
@nekoal не понял. в ответе намекнули на то что это за дата?
я про то, что при формировании sql запроса если есть поле даты в части where то скорее всего оно будет включено и в части select
where надо полагать формируется из dateFrom
так там присутствуют 2 даты. дата размещения и дата платежа
И да - логически я и сам знаю ответ на свой вопрос. пугает что они даже ответить не смогли.
да, то есть дата изменения не фигурирует
как класс
отсутствует как класс
блин - типа "ДА" - отсутствует :-)
значит, если дорабатывать дату изменения возможно надо будет доставать из журнала изменений
они поленятся мне кажется
для новых бы конечно хватило и даты размещения
поленятся - это к бабке не ходи. следовательно ВСЕ будем тянуть ежедневно ВСЁ.
но нужно отдельный запрос аннулированных по дате изменения
можно запрашивать ТОЛЬКО аннулированные - это гораздо меньше информации
но на заре ГЖ мы на ПРОДЕ аннулироваль тысячами
плохо.. тогда может предложить им ограничить срок в течение которого можно аннулировать после размещения?
пару месяцев например
тогда и даты размещения хватит в принципе - за 2 месяца поменьше количество
и "зарю" не захватит
@nekoal странные у вас предложения
нет бы нормально сделать, вы предлагайте костыль воткнуть
я конечно за нормальное решение, но по факту вопрос не ограничивается тем что мы захлебываемся от старых данных, система тоже все больше будет тупить. Поэтому я вообще за ограничение срока хранения данных. Ограничение срока аннулирования вполне приемлемо с этой точки зрения
пару месяцев наверно достаточно, чтобы платеж дошел до адресата
заметьте, что аннулирование других типов данных я не предлагаю
если сделать дату изменения, то прикинем как: или нужно выбирать из журнала изменений (тут будет долго считываться) или из индексированного поля самой таблицы (тут будет долго записываться за счет обновления индекса при каждой записи). Подобрать баланс будет непросто. Если сейчас выборка по дате платежа/размещения и надо грузить ВСЁ, то чтений гораздо больше, но если сделать дату изменения, то чтений будет примерно равное количество с записями.
@mkpmkp DateFrom - дата создания платежа в системе https://helpdesk.dom.gosuslugi.ru/browse/HCSINTEGRS-4143?
@Jenstel33rus_twitter у меня каждый раз нестыковка, почему ты тут Алексей, а там Владимир >_<
@doazet у дьявола много имен :smile: :smile: :smile: :smile:
@Jenstel33rus_twitter это хорошо. ловим только аннулирования...
как раз об этом думал, если добавлять в индекс по дате создания в системе, то время обновления индекса будет малое, так как не придется из середины что-то таскать в конец, просто допишутся новые данные в конец
в итоге ланитовцы похоже рассудили так же))
в который раз убеждаюсь - если хочешь разобраться как что-то работает, вообрази самый ленивый способ как сделать
@nekoal да на это вообще пофиг, ибо у меня, например, ночью все платежи обновляются... у него может статус поменять, банк может аннулировать платеж и мне надо это отловить, пересопоставить, аннулировать квитирование и сквитировать заново...
ну это с точки зрения своей ИС
прикиньте объем (объёб) данных, которые все со временем будут ежедневно тянуть...
ночь там может быть менее загружена, а в ГИС грузят в любое время суток, то есть при обработке каждого платежа надо индекс обновить, потому что вдруг его через секунду кто-то запросит на чтение. А объем для обновления не маленький в рамках ГИС
тупо дописывать в конец индекса - быстрее
@nekoal а обещали запрос еще по изменениям сущностей, в частности по платежам сделают либо в фильтре еще параметр типа "DateChange", который будет вовзращать только изменения после конкретной даты, либо можно уже щас тупо статусами отлавливать, например, забирать только аннулированные но пока у меня за 45 минут справляется с выгрузкой всего, так что норм, да и актуальность нужна за последние полгода, дальше врятли что могут аннулировать или поменять
@Jenstel33rus_twitter признаться я думал что DateFrom - это дата платежа. Прям камень с плеч.
А вообще им давно пора подумать насчет запросов только с обновленными данными, как в NSI, чтобы можно было получать только GUID сущности и дату последнего изменения... было бы очень удобно, запросил разок, сверил даты правки, если менялось что-то после того как ты у себя последний раз сохранил - перечитал обратно к себе с последними правками... а то щас приходится все гонять
@mkpmkp изначально может так и задумывалось, но есть возможность заливать задним числом, поэтому ты бы часть просто терял, думая, что за эту дату ты все прочитал уже...
@mkpmkp а с датой создания очень удобно, всегда знаешь по какую именно дату/время ты к себе все забрал
Хоть тут порядок. Причем в документации не написано что это за дата. ТП на вопрос не отвечает.
@mkpmkp в ТП сидят реальные ТП, уже проверено не раз... им по ошибкам надо неделю доказывать, что ошибка на самом деле имеет место быть и прям досканально показывать где именно, взять хоть проблему с перебором ИЖКУ в ЕЛС
@mkpmkp https://helpdesk.dom.gosuslugi.ru/browse/HCSINTEGRS-4406 вот пример хороший
раскатал))
@Jenstel33rus_twitter да... я с ними уже не могу вежливо разговаривать. мои коворкеры не одобряют мой стиль общения с ТП
Последнее письмо - немного постарался оскорбить...
@mkpmkp это уже нормально, потому что реально пригорает, неделю ждешь ответа и получаешь вот такое...
зря ты так про эдуардов
у первой линии есть инструкции для ответов, если в инструкции нет ответа, то пытаюся найти тот, что ближе всего по смыслу, если не нашли шлют на вторую линюю
но интеллектуальностью поиск не отличается, это да )
@dudarkoas ща его за эдуардов забанят >_<
Целый пласт для исследовательской работы использование уменьшительно-ласкательного имени в переносном смысле в зависимости от региона. У нас Алеша. Где-то Антон. Теперь Эдуард..
ХЗ откуда это..
@springjazzy Алеша и Эдуард совсем разные по смыслу. Алеша - свой и любимый всеми дурачок:) Эдуард - эстонский жираф, который или тупой, или просто пока смысл не добрался до мозга:)
@NadyaTomsk эдуард обычно используется из-за производного имени эдик, что используется как созвучное к слову педик
фигасе..
Спасибо за этимологический ликбез ))
пора менять имя....
А имя "Лёха" произносят иногда через "о", что, возможно, тоже как-то характеризует его использование
А имя "Антон" иногда произносят через Г.
Без намёков на присутствующих, доводилось мне работать с одним таким Антоном на букву Г, поэтому и знаю)
не через, а с
@DrShtopor_twitter про "толик-в-жопе-нолик" тоже все знают
Фантазия русского народа огромна, а уж что касается жопы, то просто безгранична)
В итоге по дате платежа DateFrom: т.е если были загружены платежа все за 10.03.2018, а 11.03.2018 аннулировали платеж из другой ИС, то при запросе за 11.03.2018 я не получу данные по аннулированному платежу. так? И чтобы мне иметь актуальные данные по аннулированным платежам, то надо запрашивать повторно за все даты, в которые грузил платежи в гис?
точно
как тут выяснилось DateFrom - дата РАЗМЕЩЕНИЯ. От аннулирования она не изменится.
Добро пожаловать в реальный мир, господа. Я покажу Вам насколько глубока кроличья нора.
копирайтеры плачут))
@mkpmkp
Я покажу Вам насколько глубока кроличья нора.
это ты так слово "жопа" красиво заменил?
Всем здравствуйте.
Кто что знает по загрузке задолженностей?
Каким образом сейчас ГИС их обрабатывает, аккумулирует / не аккумулирует?
Кто что знает по загрузке задолженностей?
Каким образом сейчас ГИС их обрабатывает, аккумулирует / не аккумулирует?
Товарищи, сменился руководитель одной УК. Новый получил ЭЦП, зарегался на госуслугах, сделали его новым директором, старого удалили, дали доступ в ГИС (как админ и уполномоченный спец-ст). Но в ГИСе при входе по логину и паролю только обращения и аналитика. Не сталкивались? Или сперва в ГИС нужно зайти с помощью сертификата?
@potryasayushche_twitter в ГИСе отдельная настройка прав
Вкладки Администрирование нету
Конечно, возможно, что новый дир не подтвердил по почте доступ к ГИСу. Но божиться, что подтверждал.
@potryasayushche_twitter там в 3 группы надо добавить 2 админа и уполномоченный спец-ст
@potryasayushche_twitter на этом форуме в поиске вбейте "Инструкция как добавить права сотрудникам" и проверьте
Админ в ЕСИА , админ и специалист в ГИС.
@potryasayushche_twitter ну тогда не знаю. этого было достаточно когда подключались: Администратор организации в ГИС ЖКХ, Уполномоченный специалист организации в ГИС ЖКХ, Администраторы профиля организации.
@Mihdim Читанул. Все так же делал. Кроме повторного входа по ЭЦП. Значит, в этом проблема.