Коротко — ключевая мысль:
- Регистр расчётов хорош для вычислений (ежедневные/периодические начисления, алгоритмы), но не для учёта первичных фактов (выдачи траншей, платежи, движения остатка). Факты лучше хранить в регистрах накопления (или в документах, которые двигают регистры накопления). Информационные регистры — для версий графиков, условий и справочных данных, к которым будут ссылаться виды расчёта.
Дальше — подробный план и рекомендации по вашему сценарию (займы с траншами, проценты, пени, платежи, реструктуризация).
1) Роль регистров в решении
- Регистр накопления (movements/остатики): хранит факты движения денежных/тело займа — транши, погашения, реестры платежей. На его основании можно получать остаток на любую дату. Это обязателен для корректного расчёта процентов по фактически выданной сумме.
- Информационный регистр: хранит графики, версии графиков, историю изменений условий (ставка, срок, параметры реструктуризаций). Это «неизменяемые» условия/версии для расчёта и аналитики.
- Регистр расчётов: выполняет алгоритмы начисления (проценты, пени) на основе базы (остатка, графика, ставок) и может сохранять результаты расчётов (для отчётности/проведения). Часто используют как «выполняющий» механизм: пересчитал — получил сумму для проводки/постинга в регистр накопления.
2) Предлагаемая архитектура (рекомендую)
- Документы:
- Документ «Выдача транша» — делает проводку в регистр накопления «Остатки по займу (тело)» (увеличивает остаток).
- Документ «Платёж по займу» — уменьшает тело/погашает проценты/пени согласно правилам распределения.
- Документ «Реструктуризация» — создаёт новую версию графика/условий в информационном регистре, возможно делает коррекции в накоплении (если меняются суммы).
- Информационные регистры:
- Графики платежей (версии). Храните упорядоченные версии, дату начала действия версии.
- Условия займа (изменения ставки, периода, правил начисления пени).
- Регистры накопления:
- Остаток по займу (по датам) — основной источник баланса, создаётся движениями от документов.
- Регистр движения денежных средств/платежей (аналитика по оплатам).
- Регистр учёта начисленных процентов/пеней (если хотите фиксировать начисления как факты проводок).
- Регистр расчётов:
- Делаете расчётные виды: «Процент», «Пени», «Начисление на тело» и т.д.
- В качестве базы (Базовый период) указываете регистр накопления «Остаток по займу» и/или информационные регистры (график, ставка) — чтобы расчёт мог ссылаться на остаток и на действующую ставку.
3) Почему не хранить транши в регистре расчётов
- Регистры расчётов ориентированы на вычисление значений в периодах, при этом часто предполагается, что при изменении базы вы можете «вытеснять» периоды. Если вам нужны исходные факты (датированные транши, платежи) — их надо хранить как движения в регистре накопления или в документах. Иначе рискуете потерять историю или получать некорректные результаты при ретроспективных изменениях.
4) Настройка регистра расчётов — ключевые моменты
- Измерения: «Займ» как измерение — правильно; но можно добавить измерения «Валюта», «Счёт» и т.п. если нужно.
- Ресурсы: создавайте ресурсы для типов начисления (СуммаПроцентов, СуммаПеней), а не только «Сумма» в общем виде — так удобнее различать результаты.
- Базовый период: включайте, если ваши виды расчёта должны ссылаться на регистр-основу (например, остаток по займу). Базовый регистр должен быть регистром накопления, содержащим движения/остатки по датам.
- Период действия (вытеснение): полезен для хранения условий с интервалом действия (например, ставка 10% с 01.01 — 30.06, потом 12%). Для фактов (траншей) — не используйте вытеснение; для условий — используйте.
- График в настройках регистра расчётов: если ваши расчёты используют периодизацию (ежедневно/ежемесячно) — укажите график. Но если расчёт не зависит от рабочих/нерабочих дней, график можно не учитывать — или хранить в отдельном регистре и ссылаться на него в алгоритме. Часто проще задать расчёт с шагом «день» и не привязывать к праздникам, если правила начисления не учитывают праздники.
5) Алгоритм расчёта процентов и пени (примерный)
- Баланс на дату = результат регистра накопления (включая транши и погашения).
- Процент за период = balance_on_day * rate/365 * количество_дней.
- Делать расчёт по дням (period = день) — даёт точный результат при траншах в середине периодов.
- В регистре расчётов — создать вид «Процент», базовый период — регистр накопления с остатком; формула использует остаток на каждый день и ставку из регистра условий.
- Пени = overdue_amount * penaltyRate/365 * overdue_days.
- Overdue вычисляется как разница между суммой по графику (инф. регистр) и суммой реальных платежей (регистр накопления).
- При реструктуризации: создаёте новую версию графика, отмечаете дату вступления в силу. Пересчитываете с даты реструктуризации (пересчитать начисления и, при необходимости, сделать корректирующие проводки в регистре начисленных процентов).
6) Хранить результаты расчётов или пересчитывать «на лету»
- Для скорости и аудита часто сохраняют результаты расчётов (например, в регистр накопления «Начисленные проценты» при проведении документа «Начисление процентов»). Тогда расчётный регистр используется как «оператор вычислений», а итог фиксируется документом.
- Если не сохранять — придётся пересчитывать при получении отчёта; это нормально при небольших объёмах, но при большом числе договоров и расчётов по дням может быть медленно.
7) Обработка изменений и ретроктивных корректировок
- Если документ с датой в прошлом меняет балансы или ставки, необходимо:
- Пересчитать начисления с даты изменения.
- Сделать корректирующие проводки: либо сторнировать ранее сохранённые начисления и заново провести, либо записать корректирующие записи.
- Желательно иметь механизм пакетной перерасчёта (фоновые задания) и журнал пересчётов.
- Избегайте «перезаписи» старых фактов простым заменением в регистре расчётов — используйте накопления/версии, чтобы была история.
8) Частые подводные камни и рекомендации
- Не храните первичные факты (транши, платежи) в регистре расчётов — используйте регистры накопления.
- Включение «Период действия» для сумм — опасно, если суммы часто корректируются задним числом; это усложнит историю и вытеснение.
- Учитывайте порядок применения платежа (пени -> проценты -> тело) — реализуйте алгоритм в документе «Платёж».
- Ручные корректировки и «бэкдейт» документов требуют чёткой политики: блокировка периодов, журнал операций, автоматический пересчёт.
- Производительность: ежедневный расчёт по большому пулу займов — тяжёлый по ресурсам. Делайте расчёт только за требуемый интервал (с даты последнего расчёта или с даты изменения).
- Округления: храните расчёты с высокой точностью, округляйте при проводке; контролируйте суммарные погрешности.
- Тестирование: покройте сценарии: выдача нескольких траншей, частичные платежи, реструктуризация, изменение ставки в прошлом, массовое закрытие договоров.
9) Практический пример процесса (с шагами)
- Выдача транша (дата D1):
- Документ «Выдача транша» → регистр накопления «Остатки» плюс движение по денежному регистру.
- Начисления (ежедневно/помесячно):
- БЭКГРАУНД: запускаем процедуру расчёта процентов для периода (например, с последней даты расчёта по сегодня). Регистр расчётов считывает остатки по дням (регист накопления) и ставки (инф. регистр) и формирует суммы процентов.
- Результат: либо формируется документ «Начисление процентов», который постит движения в регистр накопления «Начисленные проценты», либо результат кэшируется в регистре расчётов (если нужно хранить).
- Платёж:
- Документ «Платёж» читает актуальные начисления (и график), распределяет платёж по пени/процент/тело и делает движения в регистрах накопления.
- Реструктуризация (дата R):
- Создаётся новая версия графика; запускается перерасчёт процентов и пеней с даты R. Если начисления за уже прошедшие дни изменились — делаются корректирующие проводки.
10) Ответ на ваш конкретный вопрос про текущую настройку
- Одномерное измерение «Займ» + ресурс «Сумма» — это слишком упрощённо:
- Для фактов (транш/платёж) лучше регистр накопления. Регистр расчётов использовать с ресурсами для разных видов начислений и базовым периодом, который ссылается на регистр накопления (остаток).
- Период действия включайте для условий (ставки, версии графика), но не для фактических сумм траншей.
- График как информационный регистр — правильно. Для расчёта пеней привязывайтесь к графику и регистру платежей.
Итоговая рекомендация:
- Сохраните концепцию: документы + регистры накопления (факты), информационные регистры (графики/версии), регистр расчётов — как «механизм» вычислений. Пересмотрите настройки: база расчётов должна ссылаться на регистр накопления, ресурсы регистра расчётов разделите по типам начислений; период вычислений выберите «день» для точности при траншах; период действия используйте для условий/ставок, а не для траншей.
Если хотите, могу:
- предложить конкретную структуру регистров (перечень измерений и ресурсов) с примерами;
- описать пример алгоритма расчёта процентов и пеней в формате псевдокода (1С:Enterprise);
- нарисовать последовательность действий для реструктуризации с шагами пересчёта и корректирующих проводок.
Что предпочитаете — структура регистров, алгоритм расчёта или пример кода?