Мне кажется, что в самой идее подобных исследований в российской действительности есть глубокое противоречие. Функционал и юзабилити ДБО конкретного банка играют значимую роль лишь для малого и микробизнеса. А он по определению не очень платежеспособен, чтобы платить за подобный анализ. Для среднего и крупного в обслуживающем и/или кредитующем банке важны вообще другие параметры.
Спасибо, поигрался. Быстро, но… зачем это всё, если можно загнать все нужные данные в Postgres (или любую RDBMS) и там делать то, что Datatable никогда не сумеет?
Слабо представляю себе профессионального разработчика, для которого наличие русскоязычного инструмента администрирования БД будет решающим фактором.
На самом деле, если выбирать из бесплатных РСУБД, то у PG просто нет конкурентов.
Надо еще смотреть на поколение, не обязательно "+" на x86. У меня 213+, он на QoriQ. Он только вышел на момент покупки и брал я его с сомнением. Но до сих пор быстрый как по работе всех файловых сервисов и GUI и сейчас, в 2019 году.
Что-то о нужном кадре ведь всегда помнишь :) Место, камеру, объектив, примерный период съемки и оценку (от «ах» до «жаль удалить»). Сочетанием этих критериев все быстро ищется. Но исходники у меня на Syno тоже раскиданы по каталогам YYYY / YYYY-MM. Иногда полезно чисто с файловой точки зрения.
У каждого свой сценарий работы с отснятым материалом. Я предпочитаю снимать в RAW и быстро раскидывать в Capture One (не принципиально, любой каталогизатор-процессор RAW) по четырем категориям вручную исходя из ценности и потенциала кадра. Остальное идет в корзину. А каталогизатор еще и раскидывает по геотегам, условиям съемки и пр. Далее обработка и настроенный экспорт изображений с оценкой 4 и 5 в jpeg. Первые — для периодического просмотра и воспоминаний, вторые — показывать друзьям в инста и фб:) Это — удобно.
А зачем вам столько облаков? Покупаете подписку на Office 365, получаете бонусом 1Tb на OneDrive и заливаете свои фото туда тем же Hyper Backup или Cloud Sync. Сортировать скриптами на Syno фото — костыль. Либо Automator на вашем маке пусть разбирает, он много что умеет анализировать из того же EXIF, либо вообще в Capture One вести всё и использовать его теговую систему для поиска и сортировки.
Это предусмотрено Жилищным кодексом и есть постановление Пленума ВС РФ на этот счет. Денежные средства, внесенные на основании платежного документа, содержащего указание на расчетный период, засчитываются в счет оплаты жилого помещения и коммунальных услуг за период, указанный в этом платежном документе.
В случае когда наниматель (собственник) не указал, в счет какого расчетного периода им осуществлено исполнение, исполненное засчитывается за периоды, по которым срок исковой давности не истек (часть 1 статьи 7 ЖК РФ и пункт 3 статьи 199, пункт 3 статьи 3191 ГК РФ).
Но помнить и не надо, если поставщик услуг не забизабывает указать PaymPeriod в своём QR-коде.
Да, практические все коммунальщики забывают указать КПП в своих QR. Хотя всего-то надо добавить PayeeKPP. Надеюсь, что с их стороны это всего лишь наплевательство при тестировании (Сбер же такое проглатывает, так что и так сойдет).
Какая кошмарная денормализованная схема данных! Такое нельзя показывать, тем более в образовательных статьях. Почему не выделены отдельные сущности Артист, Альбом и Песня? Почему первичный ключ (Артист, Песня)? Во вселенной автора не бывает одноименных песен в разных альбомах (сборниках)?
Конкретно этот QR будет работать только при оплате через Сбер. Потому что автор забыл указать обязательный реквизит КПП получателя. Но Сбер его магически берет откуда-то Похоже, тянет его в таких случаях из каких-то своих справочников. Что поднимает чудесный вопрос на основани чего он вносит изменения в распоряжение клиента на перевод средств, когда должен был бы просто отказать…
А еще в этом QR полностью отсутствует инфа для ГИС ЖКХ с платежным периодом, ЕЛС и прочим.
Насчет механизма установки банка по умолчанию — он предусмотрен в протоколах обмена. Насчет ПСБ не скажу, но у Росбанка и Альфы прямо в мобильном ПО можно установить эти банки как банки по умолчанию. Думаю, что остальные реализуют так же.
Тарификация C2С через СБП в рамках одного банка — классный вопрос! Потому как о Me2Me в доках определенно говорится, что обращения в СБП для запроса инфы куда приземлять — нет. Значит, и тарификация исключительно по тарифам банка. Думаю, для С2С простая логика: при использовании сервиса «перевод клиенту банка» по номеру телефона — получаешь тариф внутри банка, а при «перевод в другой банк» по номеру телефона — получаешь тариф СБП.
У СБП другая идеология, в ней действия по приему платежа со стороны получателя не требуются. Есть свои плюсы, своим минусы.
По вопросу получения денег на карты разных банков — механизм есть. СБП предусматривает возможность установки получателем средств банка по умолчанию. Его наличие у получателя контролируется в рамках протокола обмена и, если он есть, то перевод приземляется на указанный банк. Если банка по умолчанию нет, то отправитель уточнят банк получателя в офлайне (например, по телефону) и выбирает его в момент отправки платежа из всего списка участников СБП.
Первоначально планировалось отдавать в этом случае отправителю список банков, обслуживающих счета получателя, но отказались по очевидным причинам (банковская тайна).
Спасибо, поигрался. Быстро, но… зачем это всё, если можно загнать все нужные данные в Postgres (или любую RDBMS) и там делать то, что Datatable никогда не сумеет?
На самом деле, если выбирать из бесплатных РСУБД, то у PG просто нет конкурентов.
Денежные средства, внесенные на основании платежного документа, содержащего указание на расчетный период, засчитываются в счет оплаты жилого помещения и коммунальных услуг за период, указанный в этом платежном документе.
В случае когда наниматель (собственник) не указал, в счет какого расчетного периода им осуществлено исполнение, исполненное засчитывается за периоды, по которым срок исковой давности не истек (часть 1 статьи 7 ЖК РФ и пункт 3 статьи 199, пункт 3 статьи 3191 ГК РФ).
Но помнить и не надо, если поставщик услуг не
забизабывает указать PaymPeriod в своём QR-коде.А еще в этом QR полностью отсутствует инфа для ГИС ЖКХ с платежным периодом, ЕЛС и прочим.
Тарификация C2С через СБП в рамках одного банка — классный вопрос! Потому как о Me2Me в доках определенно говорится, что обращения в СБП для запроса инфы куда приземлять — нет. Значит, и тарификация исключительно по тарифам банка. Думаю, для С2С простая логика: при использовании сервиса «перевод клиенту банка» по номеру телефона — получаешь тариф внутри банка, а при «перевод в другой банк» по номеру телефона — получаешь тариф СБП.
Но коллеги из банков первой волны ответят лучше.
По вопросу получения денег на карты разных банков — механизм есть. СБП предусматривает возможность установки получателем средств банка по умолчанию. Его наличие у получателя контролируется в рамках протокола обмена и, если он есть, то перевод приземляется на указанный банк. Если банка по умолчанию нет, то отправитель уточнят банк получателя в офлайне (например, по телефону) и выбирает его в момент отправки платежа из всего списка участников СБП.
Первоначально планировалось отдавать в этом случае отправителю список банков, обслуживающих счета получателя, но отказались по очевидным причинам (банковская тайна).