проблема у нас в том, что клиринг проходит в 21:00, а не в 23:59, как ждет клиент
Это в текущем сценарии важно когда проходит клиринг, потому что цена просрочки - 15 000 рублей. В модифицированном сценарии цена просрочки на день из-за особенностей клиринга будет порядка десятых долей процента от суммы платежа, на фоне комиссий за перевод она не будет так выделяться.
Так что никаких сложностей с 3 часами не требуется, просто проверяем в полночь была ли оплата и если её не было - платим со второго продукта за первый.
Можно даже ещё проще сделать, и всегда в полночь платить со второго продукта за первый, а клиент пусть закрывает задолженность исключительно по второму.
поэтому нам придется провести реструктуризацию части задолженности в BNPL и перенести её в кредит
Это вы уже делаете, только без “части”. Ну и реструктуризация - больно громкое слово для простейшей транзакции, перекидывающей фиксированную сумму с одного счёта на другой.
нет. тут мы получаем дополнительно 1 сложный продукт без экономического обоснования только для решения минорного кейса не закрывать первый продукт при просрочке […] Вопрос прежний: - Вы, действительно, считаете, что для обработки кейса, который составляет доли процента, надо настолько переделать текущий продукт?
Вот именно в этом и проблема. Для клиента экономическое обоснование есть, а для вас выгода от такого подхода отрицательная. Потому вы так и не делаете, хотя если в какой-то момент регуляторы дадут по рукам - сразу же окажется, что продукт не такой и сложный.
Да, я считаю что “ловить” клиентов на особенностях клиринга - неправильно, и надо расчёт переделать.
PS вы специально вместо цитат используете маркированные списки, чтобы ваши сообщения было читать сложнее?
то есть, каждому клиенту BNPL открываем продукт с лимитом кредитования, выставляем лимит рубль, и, если он допустил просрочку, то поднимаем лимит и переводим просроченную часть сюда
Не вижу смысла разрешать клиенту пользоваться этим продуктом как обычной кредитной картой, а потому и манипуляции с кредитным лимитом тут излишни.
а первый договор закрываем?
Это ровно то что вы делаете сейчас, а моё предложение прямо противоположное.
делаем срок оплаты через 3 часа
Не понял причём тут 3 часа.
если клиент не оплатил до 23:59, то вешаем просрочку на недоплаченную сумму и шлем просрочку в БКИ?
Не вполне понимаю что вы имеете в вижу под “вешаем просрочку на недоплаченную сумму”. Вроде звучит логично, но такое ощущение что где-то тут недопонимание.
если клиент оплатил до 23:59, то закрываем продукт с лимитом
Не вижу смысла его закрывать, это ж потом снова открывать через месяц придётся. Пусть висит открытый, но с нулевой задолженностью (нулевая задолженность - нормальное состояние кредитной карты).
Я задам вопрос - Вы, действительно, считаете, что для обработки кейса, который составляет доли процента, надо настолько переделать текущий продукт?
В том-то и дело, что переделки тут минимальны:
не закрывать первый продукт при просрочке;
не открывать второй продукт если он уже открыт;
держать второй продукт открытым пока открыт первый;
изменить сумму автоматического кредита с полной суммы остатка по первому продукту на сумму просрочки по нему.
Второй с банком, где уже это требуется, где клиент может получить отказ […]
Сейчас при автоматическом превращении одного продукта в другой он тоже может получить отказ? Если да, то как это вообще работает? Если нет, то почему в моём варианте это становится проблемой?
За 6 недель будут начислены проценты. Готов ли клиент их платить? На какую сумму открывать?
Пока клиент платит по первому продукту в срок - кредит в банке у него нулевой, проценты на нулевую сумму тоже нулевые. Не вижу проблем.
Если не закрывать при этом BNPL - договор, то он уходит в просрочку, открывается договор с банком. На какую сумму?
На сумму просрочки, разумеется, я же именно с этого предложения и начал ветку.
Если на сумму просрочки, то получается, что клиент в 2 раза больше должен?
А сейчас пре превращении BNPL - договора в кредитный клиент тоже в два раза больше должен становится, или всё-таки банк выкупает задолженность по этому договору? Почему вы вообще решили, что в предложенном мною решении что-то должно измениться кроме переводимой суммы?
Зависит исключительно от сопровождающей макулатуры. Если лишних бумаг удастся избежать - то можно и сразу оба продукта открыть, если бумаги неизбежны, но их можно отложить - очевидно, имеет смысл откладывать.
А если клиент ушел в просрочку на месяц, то закрывать этот договор или оставлять оба?
С одной стороны, математически красивее и технически проще оставлять оба. С другой, при просрочке на месяц биться за лояльность клиента уже нет особого смысла, и тут уже можно сделать как сделано сейчас.
Я так понял, предлагалось переносить недоплату в этот самый стандартный другой продукт. Что выглядит совершенно логично, прозрачно и не требует никакой нагрузки на бухгалтерию сверх той что уже есть, но не даёт возможности “нагреть” забывчивого клиента, из-за чего так никто и не делает.
Это Вы вообще про что? Вы банки грабите что ли? И чтоб не отвлекать персонал, делаете это после работы
Ну, это как раз понятно про что. Есть много примеров цифровой инфраструктуры, которые принципиально не могут быть обновлены в то время, когда ими кто-то пользуется.
В этой ветке обсуждается как перенести в доменную модель те данные, которые пришли по HTTP в контроллер WEB API. Добавление dto в доменный слой напрямую ничего не исправит, потому что всё ещё требуется как-то перенести данные из dto слоя api в dto доменного слоя, а значит задача свелась к самой себе.
В СТО ещё как рассматривается движение тел с ускорением, в конце концов ускорение - всего лишь вторая производная координаты по времени. Гулите релятивистское равноускоренное движение.
Но для объяснения парадокса оно тоже не требуется, достаточно понимания что преобразования Лоренца применимы только к переходам между ИСО.
На Земле в аварию попал или землятрясение, упал подвернул ногу из-за сильных перегрузок. А улетающий в ракете равномерно неспеша близнец ускоряется и не испытывает почти перегрузок. Но почему-то у последнего замедляется время.
У первого перегрузки были направлены в разные стороны и скомпенсировали друг друга, а у второго они были направлены в одну сторону и действовали долго.
Но, вообще говоря, там нет прямой зависимости от перегрузок, если составить точную формулу - в ней будет интеграл по мировой линии, и собственное ускорение будет лишь одним из множителей под знаком интеграла. Так что если вы попытаетесь придумать какую-нибудь особо хитрую и запутанную ситуацию - ответом наверняка будет “надо считать”.
А если оба близнеца в противоположные стороны полетят с одинаковым ускорением, у кого замедлится время?
В симметричной ситуации и решение тоже будет симметричным.
Такое ощущение, что вы не туториал написали (как указано в тегах), а ответный комментарий к чужому сообщению. Явно с кем-то спорите, но вот с кем?
Также статье остро не хватает введения, где было бы сказано какую вообще задачу вы решаете.
Второй закон термодинамики (упрощенная формулировка): энергия оценивается количеством и качеством. В замкнутой системе процесс может идти только в направлении снижения качества энергии.
Нету в термодинамике такого понятия, как качество энергии. Прежде чем на него ссылаться - неплохо было бы его ввести.
А как вы тогда тут обсуждаете технические детали конкретных продуктов, если в Яндексе не работаете?
Я вот думал что в статье написаны факты, а оказалось что просто домыслы. Не надо так делать!
У вас уже два “новых” продукта. Вам не требуется создавать третий, вам надо изменить то как работает первый.
Это в текущем сценарии важно когда проходит клиринг, потому что цена просрочки - 15 000 рублей. В модифицированном сценарии цена просрочки на день из-за особенностей клиринга будет порядка десятых долей процента от суммы платежа, на фоне комиссий за перевод она не будет так выделяться.
Так что никаких сложностей с 3 часами не требуется, просто проверяем в полночь была ли оплата и если её не было - платим со второго продукта за первый.
Можно даже ещё проще сделать, и всегда в полночь платить со второго продукта за первый, а клиент пусть закрывает задолженность исключительно по второму.
Это вы уже делаете, только без “части”. Ну и реструктуризация - больно громкое слово для простейшей транзакции, перекидывающей фиксированную сумму с одного счёта на другой.
Вот именно в этом и проблема. Для клиента экономическое обоснование есть, а для вас выгода от такого подхода отрицательная. Потому вы так и не делаете, хотя если в какой-то момент регуляторы дадут по рукам - сразу же окажется, что продукт не такой и сложный.
Да, я считаю что “ловить” клиентов на особенностях клиринга - неправильно, и надо расчёт переделать.
PS вы специально вместо цитат используете маркированные списки, чтобы ваши сообщения было читать сложнее?
Не вижу смысла разрешать клиенту пользоваться этим продуктом как обычной кредитной картой, а потому и манипуляции с кредитным лимитом тут излишни.
Это ровно то что вы делаете сейчас, а моё предложение прямо противоположное.
Не понял причём тут 3 часа.
Не вполне понимаю что вы имеете в вижу под “вешаем просрочку на недоплаченную сумму”. Вроде звучит логично, но такое ощущение что где-то тут недопонимание.
Не вижу смысла его закрывать, это ж потом снова открывать через месяц придётся. Пусть висит открытый, но с нулевой задолженностью (нулевая задолженность - нормальное состояние кредитной карты).
В том-то и дело, что переделки тут минимальны:
не закрывать первый продукт при просрочке;
не открывать второй продукт если он уже открыт;
держать второй продукт открытым пока открыт первый;
изменить сумму автоматического кредита с полной суммы остатка по первому продукту на сумму просрочки по нему.
Любая кредитная карта (которая и правда кредитная) работает таким образом. Ставка по кредиту, разумеется, не нулевая.
Первый - на сумму рассрочки, второй - на сумму просрочки по первому. Откуда взялся второй договор на просрочку?
Сейчас при автоматическом превращении одного продукта в другой он тоже может получить отказ? Если да, то как это вообще работает? Если нет, то почему в моём варианте это становится проблемой?
Пока клиент платит по первому продукту в срок - кредит в банке у него нулевой, проценты на нулевую сумму тоже нулевые. Не вижу проблем.
На сумму просрочки, разумеется, я же именно с этого предложения и начал ветку.
А сейчас пре превращении BNPL - договора в кредитный клиент тоже в два раза больше должен становится, или всё-таки банк выкупает задолженность по этому договору? Почему вы вообще решили, что в предложенном мною решении что-то должно измениться кроме переводимой суммы?
Зависит исключительно от сопровождающей макулатуры. Если лишних бумаг удастся избежать - то можно и сразу оба продукта открыть, если бумаги неизбежны, но их можно отложить - очевидно, имеет смысл откладывать.
С одной стороны, математически красивее и технически проще оставлять оба. С другой, при просрочке на месяц биться за лояльность клиента уже нет особого смысла, и тут уже можно сделать как сделано сейчас.
В том, чтобы не штрафовать клиента на все 15 000 ₽ за опоздание на 15 минут.
На тот же самый, на который он открывается сейчас.
То происходит то же самое, что и при погашении кредита копейка в копейку с просрочкой платежа - сумма кредита остаётся ненулевой.
С точки зрения буквы закона вы, возможно, выкрутились - но вот с точки зрения клиента это ничем принципиально от штрафа не отличается.
Я так понял, предлагалось переносить недоплату в этот самый стандартный другой продукт. Что выглядит совершенно логично, прозрачно и не требует никакой нагрузки на бухгалтерию сверх той что уже есть, но не даёт возможности “нагреть” забывчивого клиента, из-за чего так никто и не делает.
token ring к токовым петлям отношения не имеет, это разные технологии, притом разных уровней
Ну, это если работы над инфраструктурой и правда запланированные, а не партизанские…
Ну, это как раз понятно про что. Есть много примеров цифровой инфраструктуры, которые принципиально не могут быть обновлены в то время, когда ими кто-то пользуется.
В этой ветке обсуждается как перенести в доменную модель те данные, которые пришли по HTTP в контроллер WEB API. Добавление dto в доменный слой напрямую ничего не исправит, потому что всё ещё требуется как-то перенести данные из dto слоя api в dto доменного слоя, а значит задача свелась к самой себе.
Вот уж точно не в Main надо регион устанавливать! У вас же есть метод OnHandleCreated как раз для инициализации дескриптора окна.
В СТО ещё как рассматривается движение тел с ускорением, в конце концов ускорение - всего лишь вторая производная координаты по времени. Гулите релятивистское равноускоренное движение.
Но для объяснения парадокса оно тоже не требуется, достаточно понимания что преобразования Лоренца применимы только к переходам между ИСО.
У первого перегрузки были направлены в разные стороны и скомпенсировали друг друга, а у второго они были направлены в одну сторону и действовали долго.
Но, вообще говоря, там нет прямой зависимости от перегрузок, если составить точную формулу - в ней будет интеграл по мировой линии, и собственное ускорение будет лишь одним из множителей под знаком интеграла. Так что если вы попытаетесь придумать какую-нибудь особо хитрую и запутанную ситуацию - ответом наверняка будет “надо считать”.
В симметричной ситуации и решение тоже будет симметричным.
Такое ощущение, что вы не туториал написали (как указано в тегах), а ответный комментарий к чужому сообщению. Явно с кем-то спорите, но вот с кем?
Также статье остро не хватает введения, где было бы сказано какую вообще задачу вы решаете.
Нету в термодинамике такого понятия, как качество энергии. Прежде чем на него ссылаться - неплохо было бы его ввести.
WinRT API основано на технологии COM, к .NET оно прямого отношения не имеет