15 октября, понедельник 22:25
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

CREDIT. Начисление %% на траншевые кредитные линии

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • CREDIT. Начисление %% на траншевые кредитные линии

    Очень хочется, что - бы при начислении %% на траншевые кредитные линии формировалась одна проводка на всю линию, а не на каждый транш. Как-то я писал заявку в Кворум, но ...

    Вижу 3 варианта как это сделать без помощи ребят с Кожевнической:
    1. Переписать алгоритм начисления и подготовки документов полностью ... Что-то не тянет.

    2. Оставить "родное" начисление по траншам, а переписать формирование документов. Тогда можно группировать записи из CredPerc по принадлежности к одной к/л. Создавать новую запись в CredPerc с номером к/л, на которую "вешать" проводки. Записи по траншам так-же цеплять к этой новой записи и "сливать" в архив.
    Тут встает проблема с написание отката для этой "новой" записи. Что-бы при возврате на статус "Расчитана" записи по траншам "доставались" из архива ...

    3. Потправить напильничком начисление %%, что - бы в CredPerc уже попадала суммарная по траншам запись. В качестве номера договора можно указывать специальный "технический" транш. Для мультивалютных к/л (каковые у нас есть (сам напильничком дорабатывал)) необходимо иметь технический транш на каждую валюту.

    Может у кого есть мнение по данному вопросу или опыт реализации подобной возможности ?

  • #2
    RedPank Идея красивая, правильная... К сожалению реализация 144-П (инструкция, в которой изначально появились транши) мало-мало не такая, какой изначально мыслилась, отсюда и проблемы в работе с договорами этого типа (начисление процентов, резервирование, долгосрочные линии "до востребования"... да много чего). С самого начала говорилось о том, что существует ОДИН договор кредитной линии, по которому должны отражаться ВСЕ операции за исключением истории выдачи/погашения ссудной задолженности отдельных траншей. Но Кворум сделал упор на то, что при таком подходе нужно много чего поломать/задвоить и реализовал так, как реализовал (более того, до сих пор не удается доказать предыдущий постулат об одном договоре с клиентом ). Бороться в одиночку тяжело, и мы на некоторые нюансы перестали обращать внимание... Корректным, вероятно, было бы хранение суммарных операций по договору в отдельной таблице - аналоге CrLim, а всю разбивку в траншах

    Комментарий


    • #3
      sprut Бороться в одиночку тяжело ...


      Возьмемся за руки друзья!
      Возьмемся за руки друзья!
      Что-б не пропасть по одиночке!




      Я сначало взялся за реализацию по п. 2, но быстро забрел в тупик ...
      Сейчас пробую п. 3.

      Комментарий


      • #4
        А вообще кого-нибудь интересует работа с кредитными линиями "в целом",а не как с группой мало связанных траншей ???

        Может у кого есть наработки и/или идеи по этому поводу ???

        Доделать "под себя" малой кровью не получается. Слишком много завязок на кредитные договора (CredCont) в кредитном модуле. В том числе и в паскалевском коде ... :-((

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

        Вообще я в транше (т.е. в трансе, прошу прощения). Количество этих самых траншей в некоторых договорах уже достигло запредельных величин ...

        Комментарий


        • #5
          Добился!
          Сейчас установлю и посмотрю как пользователи проценты начислять будут ...

          1. Базовые ф-ии оставляем. Операции начисления по каждому траншу остаются. Но при начислении %% по к/л они сразу "сливаются" в архив и заменяются сумарной операцией по к/л. - связь через квитанции.
          2. Переписываем алгоритм подготовки так, что-бы он умел работать с операциями по к/л. (Легко сказать! Алгоритм переписал полностью, так-как в Кворумоском разобраться не смог)
          3. Не удалось добраться только до кнопки "Вернуть". Пришлось "повесить" операцию возврата документов на F12. (Стандартная процедура зачем-то проверяет есть ли кредитный договор с таким номером. А договора - то нет ... "Больной перед смертью потел ?" - "Потел !" - "Это оч-е-е-е-нь, очень хорошо ...")
          При возврате операция не переходит на статус Рассчитанные, а удаляется вместе с операциями по траншам. Пришлось пойти на это так-как до кнопки "Удалить" тоже не добрался
          4. Добавляем обработку операции credPercOperation в KvitManager.
          5. Добавляем обработку CredPercOperation в проц. вызываемые по ALT-B и CTRL-P

          Ну вот вроде и все ...

          Комментарий

          Пользователи, просматривающие эту тему

          Свернуть

          Присутствует 1. Участников: 0, гостей: 1.

          Обработка...
          X