email используется, как логин только по одной причине — уникальность.
Как email, так и номер телефона уникальны только в конкретный момент времени. А так, что домены, что телефоны вполне могут менять своих "владельцев". Поэтому жёстко завязываться на email как на уникальный идентификатор мне кажется не очень корректным.
Не так давно я переносил свою почту с .net домена на .ru, ну и менял емейлы во всех своих регистрациях. Так некоторые сервисы, оказывается, не предусматривают возможноть смены логина-почты... Что наши, что зарубежные. Где-то менял через поддержку, а кто-то (тот же СОГАЗ) предлагает только завести новую учётку
предприятие достаточно серьезное чтобы ему не доверять, а значит никаких авансов поставщикам
К сожалению, есть масса организаций, которым совершенно не интересны хотелки серьезных предприятий. И это не только различные монополии - водоканалы, Природа, и прочие коммунальщики, но и самые обычные бюджетные и не только организации - которые не будут осаждать страничку серьезного предприятия на госзакупках, а к которым само это предприятие будет приходить, кланяться, рисовать закупку у единственного источника - и на условиях этой организации. И вместо постоплаты в течение NNN дней с момента подписания акта и при соблюдении кучи условий, это наше серьезное предприятие начинает платить 100% аванс в течение трёх дней с даты выставления счёта, например.
И таких организаций весьма много - местные газеты, районные поликлиники и т.д. Чем мельче - тем ярче это может проявляться. Пример - в небольшом населённом пункте ежедневный медосмотр персонала перед сменой - тут или соглашайся на условия местной районной поликлиники, или гоняй персонал за десятки километров в ближайший крупный город.
Шаг в сторону от крупного города - и наше серьезное предприятие как клиент никому особо и не нужно настолько, чтобы подписываться на его условия - с раскрытием информации, всякими крючкотворными странными оговорками в договоре, постоплатами, банковскими гарантиями, обеспечительными платежами и т.д.
Доступ к самым современным технологиям получат абсолютно все клиенты интернет-банка.
Клиенты, скорее, получают доступ не к самым современным технологиям, а лишь к современному интерфейсу. И то не всегда и не везде. В том же АЗОНе кликнешь по ссылке "Пользователи" - и в открывшемся окне видишь привет из дизайна тех самых 90х ))
Конечно, это зависит от желаемой глубины охвата тестов, но я бы добавил ещё проверку на логическую непротиворечивость сформированного документа:
совпадает ли код ОКУД в правом верхнем углу (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 ничего не отдаётся-то, кроме дефолтной заглушки.
Как email, так и номер телефона уникальны только в конкретный момент времени. А так, что домены, что телефоны вполне могут менять своих "владельцев". Поэтому жёстко завязываться на email как на уникальный идентификатор мне кажется не очень корректным.
Не так давно я переносил свою почту с .net домена на .ru, ну и менял емейлы во всех своих регистрациях. Так некоторые сервисы, оказывается, не предусматривают возможноть смены логина-почты... Что наши, что зарубежные. Где-то менял через поддержку, а кто-то (тот же СОГАЗ) предлагает только завести новую учётку
К сожалению, есть масса организаций, которым совершенно не интересны хотелки серьезных предприятий. И это не только различные монополии - водоканалы, Природа, и прочие коммунальщики, но и самые обычные бюджетные и не только организации - которые не будут осаждать страничку серьезного предприятия на госзакупках, а к которым само это предприятие будет приходить, кланяться, рисовать закупку у единственного источника - и на условиях этой организации. И вместо постоплаты в течение NNN дней с момента подписания акта и при соблюдении кучи условий, это наше серьезное предприятие начинает платить 100% аванс в течение трёх дней с даты выставления счёта, например.
И таких организаций весьма много - местные газеты, районные поликлиники и т.д. Чем мельче - тем ярче это может проявляться. Пример - в небольшом населённом пункте ежедневный медосмотр персонала перед сменой - тут или соглашайся на условия местной районной поликлиники, или гоняй персонал за десятки километров в ближайший крупный город.
Шаг в сторону от крупного города - и наше серьезное предприятие как клиент никому особо и не нужно настолько, чтобы подписываться на его условия - с раскрытием информации, всякими крючкотворными странными оговорками в договоре, постоплатами, банковскими гарантиями, обеспечительными платежами и т.д.
Клиенты, скорее, получают доступ не к самым современным технологиям, а лишь к современному интерфейсу. И то не всегда и не везде. В том же АЗОНе кликнешь по ссылке "Пользователи" - и в открывшемся окне видишь привет из дизайна тех самых 90х ))
Посмотрите в сторону
Rectangle()в itext. Текстовые блоки я по заданным координатам из .pdf вытаскивал, по примеру из https://stackoverflow.com/questions/48597948/text-extraction-from-a-pdf-using-itext7-how-to-improve-its-performanceВозможно аналогично можно графику получать...
Конечно, это зависит от желаемой глубины охвата тестов, но я бы добавил ещё проверку на логическую непротиворечивость сформированного документа:
совпадает ли код ОКУД в правом верхнем углу (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 ничего не отдаётся-то, кроме дефолтной заглушки.