Форма 125 и кредитные карты

[Miosota]

Уважаемые коллеги, не нашла в форуме (может плохо искала) ответ на свой вопрос, поэтому задаю в новой теме...
Как по срокам в 125 форме (а отсюда вытекает как в ликвидные берете) остаток задолженности по кредитным картам (сч.45509).
Думаю, что принцип работы примерно одинаковый, у нас такой:
клиент должен погасить до 10 числа каждого месяца 10% от суммы выбранного остатка на 1-е число.
Т.е. каждого 10-го числа месяца запускается программа, которая смотрит какой был остаток на 1-е число, берет от него 10%, смотрит, гасил ли клиент что-то. Если гасил, то сравнивает сумму погашения с этими 10%, если она меньше, то 10-го числа выносит оставшуюся непогашенную часть от 10% на просрочку.
При этом клиент может в течение месяца выбирать-гасить-выбирать-гасить и каждое 1-е число у меня будет новый остаток.
У меня есть несколько вариантов:

1. не заморачиваться и брать все как овердрафт до востребования - при этом я буду завышать свои нормативы ликвидности, что мне не оч.нравится.
2. строить 1-го числа на коленке график исходя из того, что клиент будет именно по этому графику все гасить и больше ничего не выбирать - т.е. 10% от остатка на 01.12.10 в первый месяц, 10% от остатка на 01.01.10 во второй месяц и т.д. до окончания срока действия карты. И если клиент будет гасить досрочно, то убирать это гашение с первых по графику дат, а на первое число следующего месяца строить новый график.
3. строить 1-го числа на коленке график как во втором варианте, до 10-го числа все делать так, как в первом варианте, а с 11-го числа каждый день на коленке строить график исходя из остатка за предыдущий день - но это очень сложно в реализации и не совсем корректно

[CAP]

Miosota, 1. Почему на коленке? Если программа в состоянии определить срок погашения каждой суммы, то значит в системе есть вся необходимая инфа и есть алгоритм ее обработки. Почему бы ту же программу не приспособить для расчета формы 125?
2. Адекватный вариант 2.
3. Может есть возможность не брать в ликвидные вообще эти остатки?
4. А зачем Вам каждый день строить какие-то графики? Вы каждый день считаете форму 125?

[Miosota]

CAP,

Почему на коленке? Если программа в состоянии определить срок погашения каждой суммы

Графика в программе, где учитываются эти кредиты - нет. Поэтому нужно писать отдельный алгоритм для отчета. Т.е. задавать программе: бери вот эту сумму, ставь в этот и этот столбик, а если было гашение, то вычитай отсюда.

4. А зачем Вам каждый день строить какие-то графики? Вы каждый день считаете форму 125?

Я каждый день считаю нормативы, а отчет по ним у меня строится на данных 125 формы (она у меня для контроля разбита по всем группам риска и контролируются отклонения с балансом каждый день, чтобы потом в конце месяца все косяки не разгребать).

3. Может есть возможность не брать в ликвидные вообще эти остатки?

нельзя, для 125 все равно как-то нужно разбивать, т.к. ПОСы без просрочки берем туда.

[CAP]

Miosota, Графика в программе, где учитываются эти кредиты - нет. А как же каждого 10-го числа месяца запускается программа, которая смотрит... Почему бы эту программу не приспособить для отчета и не запускать при его подготовке?

Я каждый день считаю нормативы, а отчет по ним у меня строится на данных 125 формы Такая технология мне кажется странной. Может, что-то поменять в консерватории с учетом периодичности расчетов? В нормативах то всего 3 срока: д/в, до 30 дней и свыше года. Не то, что в 125-ой.

[Miosota]

CAP,

Почему бы эту программу не приспособить для отчета и не запускать при его подготовке?

разные механизмы в разных программах, эту программу нельзя приспособить, а только новую написать можно. И кроме того, она смотрит только на текущую дату, а график вперед не разбивает же.

Такая технология мне кажется странной. Может, что-то поменять в консерватории с учетом периодичности расчетов?

Нет смысла, т.к. в программе стоит контроль на сумму остатков по всем датам по балансовому счету с остатком по балансовому счету в балансе. И еще контроль на превышение срока балансового счета и срока в программе. Если отслеживать только до 30 дней, то весь этот контроль будет не видно и в конце месяца столкнешься с проблемой поиска косяков за весь месяц + с тем, что на внутримесячные даты по ликвидности неправильно что-то посчитал из-за этих же косяков. Поясню, что косяки возникают как из-за человеческого фактора (неправильный ввод графика, указание конечной даты, например, ошибка в цифрах года или месяца), так и из-за программных сбоев (не пролонгировался вклад).

В целом мне понятно Ваше мнение, я вот тоже больше ко второму варианту расчета склоняюсь.
Вот странно, вроде почти все банки кредитные карты выпускают, а дискутируем только мы с Вами. Как остальные-то все это дело учитывают?..

[Miosota]

....

[Yulya]

Miosota,
Вот странно, вроде почти все банки кредитные карты выпускают, а дискутируем только мы с Вами. Как остальные-то все это дело учитывают?..
у нас карты не кредитные, а овердрафтные (что по сути то же самое)
по договору клиент обязан погасить задолженность не позднее 30 числа месяца, следующего за месяцем выдачи (например, задолженность возникла 2 ноября, должна быть погашена до 30 декабря). Поэтому на 1-ое число всю сумму остатков на 45509 по 1,2 к.к. решено включать в 8989, а на внутримесячные даты никуда не включаю, т.к. просто нереально определить, какая часть задолженности когда должна быть погашена
Может и Вам так же: на 1-ое число брать в 8989 10% от остатка на 45509 (ну или до 10 числа), а на остальные даты ничего не брать в расчет?

[CAP]

Miosota, эту программу нельзя приспособить, а только новую написать можно. Я просто хотел сказать, что если есть механизм контроля сроков каждой задолженности, то не должно быть проблем рассчитать график их погашения.

в программе стоит контроль на сумму остатков по всем датам по балансовому счету с остатком по балансовому счету в балансе. И еще контроль на превышение срока балансового счета и срока в программе. Если отслеживать только до 30 дней, то весь этот контроль будет не видно и в конце месяца столкнешься с проблемой поиска косяков за весь месяц Не понял, почему. Ну какая методически разница с этими контролями, отслеживать 2 срока (просрочка и до 30 дней), или 8 сроков из формы 125? А время меньше уйдет. Да и лишняя информация только мешает обычно.

[Miosota]

Yulya,

у нас карты не кредитные, а овердрафтные (что по сути то же самое)

к сожалению, немного разные вещи:
1. овердрафтная карта - это обычная дебетовая карта, когда ты можешь держать на ней и свои деньги тоже,но при этом, рассчитавшись сверх лимита, залазиешь в карман к банку, и тогда появляется твой овредрафт; а на кредитной карте денег твоих нет изначально и быть не может
2. у овердрафтной карты (как Вы и говорите) есть только 1 срок погашения. Сколько не выбери - должен все вернуть к определенному сроку.
у кредитной - есть несколько сроков гашения: например,по 10% каждый месяц от остатка на 1-е число каждого месяца в течения срока действия карты + оставшуюся сумму задолженности к окончанию срока действия карты

Соответственно, как Вы предлагаете, сделать не могу, т.к. в соответствии с договором клиент должен погасить образовавшуюся задолженность не за один раз, а как бы "графиком", т.е. идет разбивка по нескольким датам в течение срока действия карты.


CAP,

Я просто хотел сказать, что если есть механизм контроля сроков каждой задолженности, то не должно быть проблем рассчитать график их погашения.

Есть механизм отслеживания остатка на конкретную дату - 1 число, а не того, как клиент выбирал - гасил - выбирал.
Но если отталкиваться именно от этого механизма, то думаю, что построить раз в месяц график, отталкиваясь от остатка на 1 число вполне реально. Поставила задачу программистам, посмотрим, что скажут

Не понял, почему. Ну какая методически разница с этими контролями

У меня слишком большой портфель, чтобы отслеживать 2 срока вручную. А автоматически можно проверить лишь насколько то, что ввел исполнитель, соответствует логике:
1. конечная дата - не больше и не меньше балансового счета
2. превышает ли срок в программе по счету текущую дату (на случай, если забыли пролонгировать или неверно дату указали)
3. вообще ввели ли график и полностью ли это сделали (программа суммирует конечную сумму (сроком свыше 3 лет) всех кредитов по определенному лицевому счету и сверяет его остаток с обороткой

Т.е. не имея данных по п.3, а имея только данные по срокам до 30 дней, я не смогу осуществить контроль.

В общем, в целом весь алгоритм работает так и отталкиваться приходится от того, что есть.

[Yulya]

Miosota,
спасибо, за ликбез по кредитным картам , у нас они только в проекте, и я не думала, что отличие от овердрафтных настолько принципиальное

Соответственно, как Вы предлагаете, сделать не могу
да, мой вариант подойдет только с точки зрения расчета норматива Н3 (8989), а для составления 125 формы явно не годится

[CAP]

Miosota, Т.е. не имея данных по п.3, а имея только данные по срокам до 30 дней, я не смогу осуществить контроль. Да почему? Вы делайте до 30 дней, до года, свыше года. С итогом на общую сумму.

[Miosota]

CAP,

Да почему? Вы делайте до 30 дней, до года, свыше года. С итогом на общую сумму.

Такое возможно, но подход с завязкой на разбивку по срокам 125-й формы существовал изначально и есть сейчас, никто не будет его ломать, увы... поэтому приходится работать с тем, что есть.