Конечно, это зависит от желаемой глубины охвата тестов, но я бы добавил ещё проверку на логическую непротиворечивость сформированного документа:
совпадает ли код ОКУД в правом верхнем углу (0401060) с видом документа "Платежное поручение" - а так же охватил бы другие виды документов - платежное требование, банковский ордер, инкассовое поручение, и т.д.
корректны ли даты - например, дата документа не может быть новее даты его обработки. Наоборот может, но если свыше 10 дней - то повод насторожиться )
корректны ли ИНН, КПП, сочетание БИК + счёт и т.д.
совпадает ли название банка из документа с названием банка, соответствующее БИКу, и, именно на дату формирования документа (т.е. в 2023 году банк был с формой ПАО, а, например, в 2013 - ОАО)
совпадает ли сумма прописью и сумма цифрами
проверку на заведомо некорректные сочетания ИНН юрлица (10 символов) с первыми цифрами расчётного счёта, который может быть только у физлица
платеж на валютный счёт физлица (пусть даже рублевый), но без кода валютной операции в назначении платежа {VO ... - хотя это скорее предупреждение а не ошибка.
непревышение максимальной длины назначения платежа
ну и т.д., тут десятки проверок могут быть.
Так же, я бы добавил проверку с учётом структуры самого документа. Не знаю как pdfbox, но библиотека iText позволяет вытаскивать информацию из pdf из определённого прямоугольника, заданного координатами - тут как раз можно проверять не только наличие даты "11.11.2023" из вашего примера, но что их две и они находятся на своих местах. Хотя тут, конечно, при выгрузке из разных банк-клиентов или наоборот, из 1С/SAP/... общая структура одинакова, но всё сдвинуто и задание координат довольно мучительно ))
Разумеется, всё зависит от задачи. В моём случае варианта хранения времени только в UTC было недостаточно. А с отображением, всё зависит от кейсов, как в ваших примерах.
Насчёт "условного словаря для расшифровки" - первоисточником, разумеется, являются законодательные акты государств, но едной базой куда все они рано или поздно стекаются (и откуда потом растекаются по различным библиотекам) является IANA TimeZone Database - https://www.iana.org/time-zones, либо можно посмотреть в сторону https://cldr.unicode.org/
на мой взгляд, потенциально проблемный. Хотя бы потому, что "+03:00" может означать не только Москву, но и Турцию, Белоруссию, Ирак и т.д. - и в этих странах могут быть свои нюансы по переводу зимнего/летнего времени, срокам действие этих переводов и пр.
Поэтому хранить временную зону только в виде смещения - крайне рисковано. Хранить в виде трёхбуквенной аббревиатуры (MSK) тоже нереально, та же EST подходит и под UTC+10 и UTC-5 и UTC+2
Я у себя храню дату/время с временной зоной в классе, с тремя публичными свойствами - "Время в UTC" (DateTime с DateTimeKind.Utc), "Временная зона" (string - "Europe/Moscow") и "Время в этой временной зоне" (DateTime с DateTimeKind.Unspecified).
При этом запись зоны в виде такой строки вполне понятна и при компиляции приложения под linux и под windows (при установленноых библиотеках Microsoft.ICU.ICU4C.Runtime) ну и в БД хранить проще :)
Банковские - да, но не персональные. В банк продавца попадают полное ФИО и номер телефона покупателя. И, в принципе, банк может делиться этой информацией с продавцом.
В своём банке подключаете услугу "Система быстрых платежей", регистрируете одну или несколько "торговых точек" - можно с одним и тем же адресом, контактным телефоном и пр. - отличающимся только названием. Для каждой торговой точки становится доступна генерация QR кодов для СБП нескольких видов - статического, динамического и подписки.
Статический - он фиксированный, его можно сделать с открытой суммой - т.е. покупатель сам будет вводить сумму при оплате, либо с заранее заданной (можно ли её изменить покупателю при оплате - сейчас не помню). Так же можно установить срок жизни это кода - через какое время по нему нельзя будет отправить платежи.
Динамический - я не пробовал, не скажу.
Подписки - страшная вещь для покупателя, не посоветовал бы на них подписываться, а если совсем никак, то обязательно устанавливать лимит по сумме списаний, если ваш банк (покупателя) это позволяет.
Когда покупатель оплачивает по СБП, вам на расчётный счёт сваливается сумма оплаты, ну и списывается комиссия банка.
Заводить несколько "торговых точек" может быть удобно для рекламных компаний - во входящих платежах видно по названию (и коду мерчанта) по какой торговой точке пришла оплата.
А, ещё можно делать возвраты покупателю, но я не пробовал, не подскажу.
Так же вам НСПК присваивает MCC код, который виден потом покупателю при оплате
При переводах c2b, банк который обслуживает бизнес вместе с входящим платежом получает и ФИО и номер 'банковского' телефона физика-плательщика. А если этот банк клиентоориентирован, то он ещё и делится этой информацией с бизнесом - и у организации после небольшой переписки с банком, все входящие платёжные поручения с поступлениями по СБП приобретают назначение платежа вида "[ID торговой точки] [Дата/время операции] [Полное ФИО плательщика] [Телефон плательщика]", например.
У Хоум Кредит в интернет-банке для физлиц похожая фигня — вставляешь логин из хранилки, переключаешь в неё для копирования пароля — возвращаешься, а поле для логина очищено. Но, зато работает обратная последовательность — сначала вставлять пароль, а затем логин — тогда нормально.
В вашем перечне «Требований… к финансовому договору» не хватает уместного, в данном случае, требования — предоставления сотрудником банка, подписывающим договор, должным образом заверенной доверенности на совершение данной операции :)
А по вопросу рекомендации банка… Если вы из провинции, то можно обратить внимание на местные, региональные банки. Многие из них заключают договор вклада по-старинке — три-четыре листа со всеми приложениями. И их содержание гораздо проще. И мобильный банк не навязывают. Правда, как правило, хоть какой-то контактный телефон всё же просят, хотя и не обязательно мобильный.
А какие теперь у вас основные RSS фиды существуют?
С головной страницы ссылка ведёт на «Хабр / Лучшие публикации за сутки», habr.com/rss/best
Если убрать "/best/", то переадресует на «Хабр / Интересные публикации», habr.com/rss/interesting
А «Все публикации»?
И пожелание для Клиент-Банка (для физических лиц) — для счастливых обладателей квалифицированной электронной подписи сделать возможным вести весь документооборот с банком дистанционно (ну, кроме тех случаем, когда закон требует чтоб сотрудник лично посмотрел в глаза клиента :)
Другие банки в ряде случаев обходятся и неквалифицированной ЭП — всё взаимодействие через Клиент-Банк.
При входе в «Личный кабинет акционера» с использованием учётной записи Госуслуг, запрашиваются права доступа на «Просмотр всех данных вашей учётной записи»:
Можете пояснить зачем? Зачем вам нужен мой СНИЛС, полис ОМС, права, военный билет, загранпаспорт, данные о детях и прочее?
Сравниваю со схожим сервисом E-voting от Национального расчетного депозитария — так он гораздо скромнее в своих запросах — требуется доступ лишь к ФИО и номеру паспорта:
А у вас, кстати, запрашиваются по первому пункту все контактные данные и идентифицирующая информация — что тоже в общем-то более чем немало.
Занятный момент.
С появлением Let's Encrypt всё больше хостеров включает SSL сертификат от них как бесплатную услугу, даже в простейших пакетах, типа сайта-визитки, идущего в комплект к покупке домена.
И некоторые, как оказалось, заказывают и получают эти сертификаты самостоятельно, без участия клиента.
Сейчас проверил парочку своих доменов, которые регистрировал через OVH, на вышеупомянутых сайтах по проверке Certificate Transparency — упс, сюрприз… Где-то с мая 2016 и по н.в. для них выпускаются сертификаты от Let's Encrypt. Причём заказывал их явно не я. Да там и по http ничего не отдаётся-то, кроме дефолтной заглушки.
openssl enc -d -base64 -A -in <Файлик с паролем в base64 из Groups.xml> -aes-256-cbc -K 4e9906e8fcb66cc9faf49310620ffee8f496e806cc057990209b09a433b66c1b -iv 000000000000000000000000000000
Они год или два назад сменили лицензию, https://www.bitvise.com/ssh-client-license — теперь Bitvise SSH Client can be used free of charge, in all types of environments, without limitation.
Our free and flexible SSH Client for Windows includes state of the art terminal emulation, graphical as well as command-line SFTP support, an FTP-to-SFTP bridge, powerful tunneling features including dynamic port forwarding through integrated proxy, and remote administration for our SSH Server.
Bitvise SSH Client can be used free of charge in environments of any type.
В автозапуске у пользователя указан старт этого клиента с заранее настроенным профилем, в котором прописывается подключение к нашему ssh серверу (с разными способами аутентификации) и настраиваются предоставляемые сервисы. По желанию: автозапуск remote desktop, кстати; терминал; мост ftp->sftp; socks прокси (очень удобно для многих применений); проброс портов от клиента к серверу и обратно и т.д. Так же есть настройки поддержания подключения, автоматического отключения, автозапуска программ при соединении и т.д. В общем — незаметная иконка в трее, ставшая уже почти незаменимой ))
Конечно, это зависит от желаемой глубины охвата тестов, но я бы добавил ещё проверку на логическую непротиворечивость сформированного документа:
совпадает ли код ОКУД в правом верхнем углу (0401060) с видом документа "Платежное поручение" - а так же охватил бы другие виды документов - платежное требование, банковский ордер, инкассовое поручение, и т.д.
корректны ли даты - например, дата документа не может быть новее даты его обработки. Наоборот может, но если свыше 10 дней - то повод насторожиться )
корректны ли ИНН, КПП, сочетание БИК + счёт и т.д.
совпадает ли название банка из документа с названием банка, соответствующее БИКу, и, именно на дату формирования документа (т.е. в 2023 году банк был с формой ПАО, а, например, в 2013 - ОАО)
совпадает ли сумма прописью и сумма цифрами
проверку на заведомо некорректные сочетания ИНН юрлица (10 символов) с первыми цифрами расчётного счёта, который может быть только у физлица
платеж на валютный счёт физлица (пусть даже рублевый), но без кода валютной операции в назначении платежа {VO ... - хотя это скорее предупреждение а не ошибка.
непревышение максимальной длины назначения платежа
ну и т.д., тут десятки проверок могут быть.
Так же, я бы добавил проверку с учётом структуры самого документа. Не знаю как pdfbox, но библиотека iText позволяет вытаскивать информацию из pdf из определённого прямоугольника, заданного координатами - тут как раз можно проверять не только наличие даты "11.11.2023" из вашего примера, но что их две и они находятся на своих местах. Хотя тут, конечно, при выгрузке из разных банк-клиентов или наоборот, из 1С/SAP/... общая структура одинакова, но всё сдвинуто и задание координат довольно мучительно ))
А посоветуйте, пожалуйста, что-то типа Pimeyes, но локальную - для поиска по коллекции фото на компьютере
Платные я не изучал, а из бесплатных оперсорсных - ABP Framework, https://abp.io/
А вы используете какой-то DDD+CRUD фреймворк или всё самописное?
Разумеется, всё зависит от задачи. В моём случае варианта хранения времени только в UTC было недостаточно. А с отображением, всё зависит от кейсов, как в ваших примерах.
Насчёт "условного словаря для расшифровки" - первоисточником, разумеется, являются законодательные акты государств, но едной базой куда все они рано или поздно стекаются (и откуда потом растекаются по различным библиотекам) является IANA TimeZone Database - https://www.iana.org/time-zones, либо можно посмотреть в сторону https://cldr.unicode.org/
Иногда может быть необходимо показать время какого-то события в том часовом поясе, в котором оно произошло, а не в том, в котором находится клиент.
То есть база данных хранит в UTC, человек сидит во Владивостоке, и читает новость, в которой временная метка вида "в 12 часов московского времени ..."
Вот ваш третий пункт:
"+180" = "+03:00" = TZ Москва
на мой взгляд, потенциально проблемный. Хотя бы потому, что "+03:00" может означать не только Москву, но и Турцию, Белоруссию, Ирак и т.д. - и в этих странах могут быть свои нюансы по переводу зимнего/летнего времени, срокам действие этих переводов и пр.
Поэтому хранить временную зону только в виде смещения - крайне рисковано. Хранить в виде трёхбуквенной аббревиатуры (MSK) тоже нереально, та же EST подходит и под UTC+10 и UTC-5 и UTC+2
Я у себя храню дату/время с временной зоной в классе, с тремя публичными свойствами - "Время в UTC" (DateTime с DateTimeKind.Utc), "Временная зона" (string - "Europe/Moscow") и "Время в этой временной зоне" (DateTime с DateTimeKind.Unspecified).
При этом запись зоны в виде такой строки вполне понятна и при компиляции приложения под linux и под windows (при установленноых библиотеках Microsoft.ICU.ICU4C.Runtime) ну и в БД хранить проще :)
Банковские - да, но не персональные. В банк продавца попадают полное ФИО и номер телефона покупателя. И, в принципе, банк может делиться этой информацией с продавцом.
В своём банке подключаете услугу "Система быстрых платежей", регистрируете одну или несколько "торговых точек" - можно с одним и тем же адресом, контактным телефоном и пр. - отличающимся только названием. Для каждой торговой точки становится доступна генерация QR кодов для СБП нескольких видов - статического, динамического и подписки.
Статический - он фиксированный, его можно сделать с открытой суммой - т.е. покупатель сам будет вводить сумму при оплате, либо с заранее заданной (можно ли её изменить покупателю при оплате - сейчас не помню). Так же можно установить срок жизни это кода - через какое время по нему нельзя будет отправить платежи.
Динамический - я не пробовал, не скажу.
Подписки - страшная вещь для покупателя, не посоветовал бы на них подписываться, а если совсем никак, то обязательно устанавливать лимит по сумме списаний, если ваш банк (покупателя) это позволяет.
Когда покупатель оплачивает по СБП, вам на расчётный счёт сваливается сумма оплаты, ну и списывается комиссия банка.
Заводить несколько "торговых точек" может быть удобно для рекламных компаний - во входящих платежах видно по названию (и коду мерчанта) по какой торговой точке пришла оплата.
А, ещё можно делать возвраты покупателю, но я не пробовал, не подскажу.
Так же вам НСПК присваивает MCC код, который виден потом покупателю при оплате
А что именно интересует? И с чьей позиции - продавца или покупателя?
При переводах c2b, банк который обслуживает бизнес вместе с входящим платежом получает и ФИО и номер 'банковского' телефона физика-плательщика. А если этот банк клиентоориентирован, то он ещё и делится этой информацией с бизнесом - и у организации после небольшой переписки с банком, все входящие платёжные поручения с поступлениями по СБП приобретают назначение платежа вида "[ID торговой точки] [Дата/время операции] [Полное ФИО плательщика] [Телефон плательщика]", например.
А по вопросу рекомендации банка… Если вы из провинции, то можно обратить внимание на местные, региональные банки. Многие из них заключают договор вклада по-старинке — три-четыре листа со всеми приложениями. И их содержание гораздо проще. И мобильный банк не навязывают. Правда, как правило, хоть какой-то контактный телефон всё же просят, хотя и не обязательно мобильный.
С головной страницы ссылка ведёт на «Хабр / Лучшие публикации за сутки», habr.com/rss/best
Если убрать "/best/", то переадресует на «Хабр / Интересные публикации», habr.com/rss/interesting
А «Все публикации»?
Другие банки в ряде случаев обходятся и неквалифицированной ЭП — всё взаимодействие через Клиент-Банк.
При входе в «Личный кабинет акционера» с использованием учётной записи Госуслуг, запрашиваются права доступа на «Просмотр всех данных вашей учётной записи»:
Можете пояснить зачем? Зачем вам нужен мой СНИЛС, полис ОМС, права, военный билет, загранпаспорт, данные о детях и прочее?
Сравниваю со схожим сервисом E-voting от Национального расчетного депозитария — так он гораздо скромнее в своих запросах — требуется доступ лишь к ФИО и номеру паспорта:
А у вас, кстати, запрашиваются по первому пункту все контактные данные и идентифицирующая информация — что тоже в общем-то более чем немало.
С появлением Let's Encrypt всё больше хостеров включает SSL сертификат от них как бесплатную услугу, даже в простейших пакетах, типа сайта-визитки, идущего в комплект к покупке домена.
И некоторые, как оказалось, заказывают и получают эти сертификаты самостоятельно, без участия клиента.
Сейчас проверил парочку своих доменов, которые регистрировал через OVH, на вышеупомянутых сайтах по проверке Certificate Transparency — упс, сюрприз… Где-то с мая 2016 и по н.в. для них выпускаются сертификаты от Let's Encrypt. Причём заказывал их явно не я. Да там и по http ничего не отдаётся-то, кроме дефолтной заглушки.
https://stephenhirst.azurewebsites.net/?p=6042
Продают они только SSH Server
Bitvise SSH Client can be used free of charge in environments of any type.
В автозапуске у пользователя указан старт этого клиента с заранее настроенным профилем, в котором прописывается подключение к нашему ssh серверу (с разными способами аутентификации) и настраиваются предоставляемые сервисы. По желанию: автозапуск remote desktop, кстати; терминал; мост ftp->sftp; socks прокси (очень удобно для многих применений); проброс портов от клиента к серверу и обратно и т.д. Так же есть настройки поддержания подключения, автоматического отключения, автозапуска программ при соединении и т.д. В общем — незаметная иконка в трее, ставшая уже почти незаменимой ))