Фссп Тест V 2.0
Коллеги, а кто то начал тестироваться с ФССП на СМЭВ 3?Чтобы что-то тестировать, надо сначала это что-то реализовать. А чтобы это реализовать, надо сначала разобраться с форматами документов, которые при обмене через СМЭВ3 объявлены непосредственно имеющими юридическую силу. А в форматах запросов мы видим феерическое - обязательное поле Data под названием 'запрашиваемые сведения' типа DVarchar3000Type. И комментарий 'перечень сведений, которые необходимо предоставить в ответе на электронный запрос'.
Перечень требуемых сведений произвольной строкой в 3000 знаков - об автоматическом исполнении заросов без анализа человеком можно забыть. Нейросети и искусственный интеллект пока находятся в стадии научных изысканий, до прикладного применения еще как до Африки ползком. А костылями по ключевым словам это поле анализировать - слишком большой риск. Игнорировать поле как 'незначимое', опираясь только на тип запроса и порядок его обработки, оговоренный в 'Соглашении об электронном взаимодействии' нельзя - электронный документ имеет юридическую силу целиком, а не только в части определенных реквизитов, и любые хотелки, которые в поле Data напишет пристав, имеют значение. За неисполнение - штраф от 50000 до 100000. При объеме порядка сотен тысяч запросов в день их обработка становится настолько трудоемкой либо рискованной, что банку это просто невыгодно.
- Aug 26, 2017 - Есть ли возможность предоставить программу 'ФССП тест v. 2.0' для ознакомительного использования. Федеральная служба судебных.
- Посмотреть сообщение. Есть ли возможность предоставить программу 'ФССП тест v. 2.0' для ознакомительного использования.
Тест для 4 класса по главе 4 к учебнику Матвеевой Н.В. (MyTestX версия 10.2.0.3).
Какой-нибудь умник из отдела по особо значимым производствам напишет туда отсебятину, и потом не докажешь суду при рассмотрении дела об административке в отношении банка, что это поле банк в полной мере не анализирует, ибо дорого. ФССП кусает руку, которую перед этим пожимали, с удовольствием - месяц назал со Сбера слупили миллион, например. Выгоднее получается вернуться к бумажному обмену, если старый способ совсем отключат - затраты на обработку бумажного запроса будут близки к обработке такого 'электронного документа', но зато будет хотя бы ограничитель сверху на количество, так как ресурсы ФССП на марание бумаги и почтовые расходы тоже не безграничны. Получается такой паритет сил между ФССП (по генерации) и банками (по ответам).
В электронном обмене по форматам СМЭВ3 паритета нет - ФССП может дешево генерировать непригодный для полностью автоматического исполнения поток бреда, а банкам надо тратиться на исполнение такого произвола и держать штат, сопоставимый со Сбером, либо принимать риски, которые никому не нужны. В старом альбоме форматов для прямого подключения такого идиотизма не было. Все существенные поля имели строгую классификацию и закрытые перечни значений. Поэтому переход на СМЭВ3 и буксует, ничего не готово, так как готово быть просто не может при такой форме документов. Если бы при разработке формата документов хорошенько подумали о затратах на их обработку на стороне банков, все было бы быстрее. А поскольку товарищи в погонах плевать хотели на чьи-либо еще интересы кроме своих собственных, такое взаимодействие вряд ли кому-то кроме них нужно.
Банк - коммерческая организация, и всегда выберет путь с минимально возможными затратами (и рисками). Обмен СМЭВ3 в существующем виде - явно не тот путь. А где ни будь определена дата перехода на СМЭВ 3.0?
Я кроме этого документа ничего не нашел. 'ПРИЛОЖЕНИЕ № 12 к протоколу заседания подкомиссии по использованию информационных технологий при предоставлении государственных и муниципальных услуг Правительственной комиссии по использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 25 июля 2016 г. № ' п.3 Предложение об отключении сервисов в СМЭВ 2.0 и сроки будут выноситься на заседание Подкомиссии. Минкомсвязь России с августа 2017 г.
Обеспечит вывод из эксплуатации СМЭВ 2.0. Вид сведений Соответствующий идентификатор сервиса в СМЭВ 2, взамен или на основании которого разработан данный ВС SID000363/SID0003899/SID0003582/SID0003924/SID0003980/ SID0003981 SID0003899,SID0003582, SID0003924, SID0003980, SID0003981 SID000363, SID0003899 (SID0003582, SID0003924, SID0003980, SID0003981) только ТЕСТ???
Запускаются ТРИ НОВЫХ СЕРВИСА и во всех присутствует SID0003981. Подскажите в каком из новых сервисов(Видов сведений) мы можем получить информацию по наличию задолженностей физ.лица. Заранее Спасибо!
Коллеги, согласно требованиям ФССП, теперь подпись необходимо формировать с меткой времени в соответствии со спецификацией Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) и со спецификацией CAdES-T (ETSI TS 101 733 «CMS Advanced Electronic Signatures (CadES). Как я понимаю, что для наложения метки времени, необходимо использовать TSP-сервер для формирования метки времени. Какой TSP-сервер необходимо использовать? Кто как решил эту проблему?Тоже интересует данный вопрос. Кто уже настроил, как, где и что купили?
Коллеги, согласно требованиям ФССП, теперь подпись необходимо формировать с меткой времени в соответствии со спецификацией Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) и со спецификацией CAdES-T (ETSI TS 101 733 «CMS Advanced Electronic Signatures (CadES). Как я понимаю, что для наложения метки времени, необходимо использовать TSP-сервер для формирования метки времени. Какой TSP-сервер необходимо использовать? Кто как решил эту проблему?Коллеги, добрый день! Вопрос еще актуален, кто-нибудь может поделиться полезной информацией? Федор Евгеньевич, какими средствами реализовали наложение этой подписи? Это открепленная подпись?
Может быть подскажете куда копнуть (ссылочку)?Добрый день. Это отсоединенная подпись. Подпись делали с помощью КриптоПРо JCP 1.0.54, дополнительно реализовали модуль по получению метки времени по rfc3161.
В КриптоПРо JCP 2 вроде как это штука уже встроена, но не проверяли. Дополнительно, у организации у которой Вы приобретаете ЭП (далее УЦ), необходимо запросить URL адрес TSP сервера удостоверяющего центра. Необходимо у УЦ уточнить, смогут ли они предоставлять n-ное количество меток времени в сутки (например, если ФССП присылает Вам в сутки 500 000 документов, то УД готов держать такую нагрузку), иначе необходимо найти другой УЦ. Для тестирования можно использовать тестовый сервер. Коллеги, кто-нибудь уже прошел совместное тестирование с Red Soft? Можете поделиться аутентичными тестовыми постановлениями, которые Red Soft присылает в ходе тестирования?
У нас пока есть только самое первое постановление типа 'О розыске и аресте'. У нас разработчики несколько опасаются отлаживаться на постановлениях, сочиненных самостоятельно по документации, так как выяснилось, что в недокументированном разделе OIpExtension есть важные атрибуты вроде LimitAmount и IpId, которые напрочь отсутствуют в примерах, опубликованных на сайте ведомства. Может вы с нами что-то попробуете? Проекты с ФССП России сложные, но вполне успешно реализуемыеУважаемый Андрей Олегович! Будь лично моя воля, ФАС и Прокуратура уже разбирались бы, по какой причине проекты с ФССП столь успешно реализуемы компанией, занимающей по странному стечению обстоятельств соседние офисы с генподрядчиком ФССП. А заодно и с тем, почему в приказе ФССП №248 есть замечательный атрибут 'Произвольные структурированные данные', и как такой документ с явным административным произволом прошел экспертизу на коррупциогенность.
А пока лучше проходите мимо. Ваши поделки на недо-СУБД 'Ред База Данных', которая при обычных объемах обмена запросами-ответами с ФССП требует каждый месяц полной выгрузки и повторной загрузки всех данных, в нашем банке, скорее всего, не будут внедряться больше никогда. У нас уже один раз ваш id-bank потерял промбазу из-за разрушения структуры хранения таблиц на диске без возможности восстановления при самом обычном использовании, больше нам такие риски не нужны.
Регламент обмена с ФССП и требования законодательства об исполнительном производстве в части оперативности обработки - слишком жесткие для того, чтобы использовать ПО, у которого восстановление БД из архивной копии является рутинной операцией. Уважаемый Андрей Олегович! Будь лично моя воля, ФАС и Прокуратура уже разбирались бы, по какой причине проекты с ФССП столь успешно реализуемы компанией, занимающей по странному стечению обстоятельств соседние офисы с генподрядчиком ФССП.Давайте, обратитесь в ФАС и Прокуратуру.
Мы хорошо работаем, поэтому хорошо и получается. Думаю, что мы и ФАС и Прокуратуре это сможем убедительно доказать. Это наш основной бизнес, а офисы у нас уже давно не соседние. Выписку из ЕГРЮЛ посмотрите по компаниям, а лучше Контур-Фокус. А пока лучше проходите мимо. Ваши поделки на недо-СУБД 'Ред База Данных', которая при обычных объемах обмена запросами-ответами с ФССП требует каждый месяц полной выгрузки и повторной загрузки всех данных, в нашем банке, скорее всего, не будут внедряться больше никогда.
Фссп Тест V 2.0 Скачать
У нас уже один раз ваш id-bank потерял промбазу из-за разрушения структуры хранения таблиц на диске без возможности восстановления при самом обычном использовании, больше нам такие риски не нужны. Регламент обмена с ФССП и требования законодательства об исполнительном производстве в части оперативности обработки - слишком жесткие для того, чтобы использовать ПО, у которого восстановление БД из архивной копии является рутинной операцией.Ну что же. Если в банке нет желания читать документацию, эффективно работать с вендором и выполнять его рекомендации, то да. Конечно виноваты мы. Если банк активно отказывается от использования кластеризации, если требования (не рекомендации, а требования) к оборудованию не выполняются, если не налажена работа по автоматизации штатных процедур контроля целостности и обслуживанию системы УБД, то да, опять же виноваты мы. Наша система работает в четверти российских банков и других финансовых институтах.
В ряде банков есть недовольства по работе системы. Но там ровно такие же подходы. Вы поставили - ваши проблемы. А то, что места на устройствах хранения данных, например, 'внезапно заканчивается', то это проблемы iDБанк, конечно-же, а не криворуких админов банка.
Корпоративная вежливость же. Администраторы не всегда качественно выполняют свою работу.
Так корректней, да? Возвращаясь к количеству - катастрофы по потере данных были в двух банках. В одном случае смотрим начало предпредыдущего абзаца со слов 'Если в банке нет.'
, во втором - RAID массив был разрушен при незавершенном развертывании пассивной ноды. К чести команды сопровождения, данные были восстановлены без потерь в обоих случаях. В остальных ста с лишним банках как-то проблем нет. Ну или есть те, которые возникают в силу недостаточного знания основ системного администрирования (СУБД тут не причём). Если в банке нет желания читать документацию, эффективно работать с вендором и выполнять его рекомендации, то да.
Конечно виноваты мы. Если банк активно отказывается от использования кластеризации, если требования (не рекомендации, а требования) к оборудованию не выполняются, если не налажена работа по автоматизации штатных процедур контроля целостности и обслуживанию системы УБД, то да, опять же виноваты мы. Наша система работает в четверти российских банков и других финансовых институтах. В ряде банков есть недовольства по работе системы.Нет, и правда постоянная проблема с этим ПО. Раз в месяц-два требуется выполнять процедуру бэкап-рестор, занимающую кучу времени (пара-тройка дней простоя гарантирована), иначе процедура перенесения данных в архив настолько замедляется (вообще не переносятся данные), что база пухнет как на дрожжах.
Только что в очередной раз через это прошли, проклиная кривизну разработки. Коллеги, а ввиду последнего письма о переносе сроков, кто-нибудь приблизился к работе через СМЭВ 3? Мы за 9 месяцев бесконечных мытарств и регулярных обновлений iDBank, наконец, смогли пройти эмуляционное тестирование, радостно написали об этом в поддержку, и те не менее радостно нас послали, заявив нам необходимо работать через требования 1.1 и 2.0, а через 3.1 работать нереально. И что нам еще раз надо как-нибудь пройти какое-нибудь тестирование. IdBank с такими форматами работать не собирается, а я сейчас думаю, что со всем этим делать. Нет, и правда постоянная проблема с этим ПО. Раз в месяц-два требуется выполнять процедуру бэкап-рестор, занимающую кучу времени (пара-тройка дней простоя гарантирована), иначе процедура перенесения данных в архив настолько замедляется (вообще не переносятся данные), что база пухнет как на дрожжах.
Только что в очередной раз через это прошли, проклиная кривизну разработки.Постоянно над этим работаем. Мы, поставляя решение на рынок, гарантировали обработку до 200 000 запросов в сутки. На сегодня это, к превеликому сожалению, совершенно недостаточно. При развёртывании системы в нормальном, рекомендованном нами системном окружении, мы гарантируем разбор до 500 000 запросов в сутки.
Любому из банков мы готовы предоставить на время сервер, который гарантированно обеспечит разбор любой очереди. За это время можно будет наладить собственное системное окружение до, хотя бы, приближенного к тому, что мы рекомендуем.
Вам необходимо нанесение жидких обоев? Цена работы у нас порадует вас. Чтобы узнать сколько стоит нанесение жидких обоев вы можете. ℹ Поклейка жидких обоев выполняется профессионалами по доступным ценам. ✓ Где в минимальные сроки найти опытных специалистов и как. Профессиональная оклейка стен жидкими обоями. Жидкие обои цена за квадратный метр. Цена работы от 250 руб. Жидкие обои — не новый материал и он существует на рынке отделочных. Подготовки поверхности стены, что еще снижает стоимость самих работ. Жидкие обои отзывы.
Сервер предлагаем не ахти какой. Платформа SuperMicro SYS-5028R-WR 3.5' SAS/SATA 1G 2P 1 Процессор Intel Xeon E5-2609 v4 LGA 2011-3 20Mb 1.7Ghz (CM901S R2P1) 1 Память DDR4 Crucial CT32G4RFD4213 32Gb DIMM ECC Reg PC4-17000 CL15 2133MHz 2 Накопитель SSD Plextor PCIe 512GB Plextor M8Pe Gamer SSD PX-512M8PeY PCIe Gen3x4 with NVMe, 2300/1300, IOPS 260/250K, MTBF 2.4M, MLC, 512MB, HHHL Adapter, NVMe 1.2, Retail 2 Жесткий диск Seagate Original SAS 3.0 4Tb ST4000NM0025 Enterprise Capacity (7200rpm) 128Mb 3.5' 2 На таком мы разбираем 10.15-ти миллионные очереди за приемлемое время. Стоимость такого или подобного сервера на сегодня - в районе 300 000 рублей. Если в банке нет возможности купить подобное оборудование, то надо обратить внимание только на то, чтобы оперативная база лежала на максимально быстрых носителях, была глубиной не более пары недель, вести разбор со включенной сортировкой, позволяющей сначала формировать ответы на самые ранние запросы (FIFO). Если этого не делать, то база, конечно же, будет раздуваться при переносе в архив. И её, конечно, надо сжимать периодически.
А уж сжатие подразумевает и проведение контроля. Постоянно над этим работаем. Мы, поставляя решение на рынок, гарантировали обработку до 200 000 запросов в сутки.
Фссп Тест V. 2.0
На сегодня это, к превеликому сожалению, совершенно недостаточно. При развёртывании системы в нормальном, рекомендованном нами системном окружении, мы гарантируем разбор до 500 000 запросов в сутки. Любому из банков мы готовы предоставить на время сервер, который гарантированно обеспечит разбор любой очереди. За это время можно будет наладить собственное системное окружение до, хотя бы, приближенного к тому, что мы рекомендуем. Сервер предлагаем не ахти какой: Платформа SuperMicro SYS-5028R-WR 3.5' SAS/SATA 1G 2P 1 Процессор Intel Xeon E5-2609 v4 LGA 2011-3 20Mb 1.7Ghz (CM901S R2P1) 1 Память DDR4 Crucial CT32G4RFD4213 32Gb DIMM ECC Reg PC4-17000 CL15 2133MHz 2 Накопитель SSD Plextor PCIe 512GB Plextor M8Pe Gamer SSD PX-512M8PeY PCIe Gen3x4 with NVMe, 2300/1300, IOPS 260/250K, MTBF 2.4M, MLC, 512MB, HHHL Adapter, NVMe 1.2, Retail 2 Жесткий диск Seagate Original SAS 3.0 4Tb ST4000NM0025 Enterprise Capacity (7200rpm) 128Mb 3.5' 2 На таком мы разбираем 10.15-ти миллионные очереди за приемлемое время.
Стоимость такого или подобного сервера на сегодня - в районе 300 000 рублей. Если в банке нет возможности купить подобное оборудование, то надо обратить внимание только на то, чтобы оперативная база лежала на максимально быстрых носителях, была глубиной не более пары недель, вести разбор со включенной сортировкой, позволяющей сначала формировать ответы на самые ранние запросы (FIFO). Если этого не делать, то база, конечно же, будет раздуваться при переносе в архив.
И её, конечно, надо сжимать периодически. А уж сжатие подразумевает и проведение контроля.Объясните, как бэкап и обратный рестор изменяет количество данных в системе? Ещё раз обращу внимание на проблему: идёт архивация, запускается ежедневно, отрабатывает сначала быстро, потом всё медленнее и медленнее, приходится перезапускать сервисы томката, на время помогает. В какой-то момент задача запускается, делает вид что работает, на деле ничего не происходит. Перезапускай - не перезапускай, всё равно получишь ноль. Единственный пока рабочий вариант - сделать бэкап рабочей базы и из этого бэкапа рестор, тогда опять начинает шустро работать и за дней 5 -7 переносит около 3 млн.
Записей в архив. Сейчас, к примеру, после очередного бэкап-рестора, задача архивации отрабатывает за 3-4 часа, старых записей - 200 штук (единиц, не тысяч) за вчерашний день. Но довольно скоро эта цифра будет увеличиваться и увеличиваться, пока система опять не станет раком. Где здесь проблемы железа?
Если бы с железом были проблемы, система бы просто не справлялась с таким объёмом данных. Я вижу только кривизну разработки - может не ту платформу выбрали для своей 'ред база данных', может ещё что-то. Утечки памяти после рекомендованных обновлений тоже ловили. Так что не про железо речь, железом вы пытаетесь заткнуть дыру в разработке.