Доброго времени суток.

Есть необходимость реализовать хранение графика платежей с возможностью получать актуальные данные графика на дату (график может правится с течением времени по согласованию сторон).
Сразу напрашивается регистр сведений подчиненный регистратору с периодичностью по позиции регистратора, но есть проблема:
Предполагаются следующие измерения регистра: Контрагент, Проект, Месяц (начисление платежей ежемесячное).

А проблема в том, что если в будущем график платежей правится, и например срок выплат сокращается (было 12 записей графика, стало 6 записей графика), то при получении срезу последних имеем следующую картину:
6 записей нового графика
6 записей старого графика

Все из-за измерения "Месяц"

Коллеги, есть совет как лучше реализовать регистр сведений?
Или может есть другие, более правильные варианты решения?

(0) Делай оборотный регистр накопления.
2 ресурса - НадоВыплатить и Выплачено.
Самое тупоеи действенное ИМХО решение этой задачи

(1) Документом фактической выплаты пишешь в ресурс Выплачено
Корректировками правишь значение НадоВыплатить
Измерения Контрагент, Проект, Месяц меня устраивают

(2) Хотя в случае оборотного РН от измерения Месяц можно отказаться, но есть кейсы где оно пригодится, пусть будет

(1) (2) (3)
Спасибо за ответ.

Но решение не совсем подходит. Полагаю, что я не все необходимое описал в задаче.

Так как это только ГРАФИК платежей, то он скорее является неким ПЛАНОМ.
т.е. это еще не фактическое начисление задолженности, оно то как раз делается регламентно, ежемесячно по данному графику (его актуальному состоянию).

Поэтому это точно не регистр накоплений (если я все правильно понимаю).

А даже если его и использовать, то если мы исправляем изначальные условия договоренностей (например изначально договорились выплачивать 12 месяцев, а потом передоговорились доп соглашением на 6 месяцев) то каким образом будут выглядеть движения доп соглашения? Полностью закроют старые движения и откроют новые? А как тогда отличить закрытие выплатой от закрытия доп соглашением? Вводить хоз операцию? Сложно как то выходит.

(2) В принципе, можно было бы использовать оборотный регистр с
Измерения
Контрагент
Проект
Месяц
Ресурс
Сумма

Но есть еще один момент, в регистре на данный момент хранится еще дата платежа. И если оборотный регистр можно было бы использовать для хранения изменений по суммам (старнировать\наращивать сумму в зависимости от изменений), то хранить изменения даты платежа не получится.

Если бы 1С это позволял хранить в ресурсе РС табличку, то было бы круто :) [если что, я знаю про хранилище значений, но это уже совсем)))]

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

И тогда всегда можно получать актуальную табличку графика платежей. Но только дополнительно необходимо вытаскивать саму табличку из справочника.

(5) Зачем дату платежа хранить в РН?
Взаиморасчеты хранишь отдельно.
План - график - отдельно.
Не стоит изобретать супер регистр где будет всё.

Хотя можешь сделать как во расчеты с клиентами в УТ подобных - больше ресурсов и больше движений с разными датами

(6) Стесняюсь спросить, но где тогда хранить плановую дату платежа?
Делать движение на эту дату? Ну, тогда актуальность даты платежа не получишь. А в случае с РН при смене даты платежа доп соглашением придется полностью сторнировать старую запись на старую дату и формировать новую, на новую дату.

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

Фактическое начисление задолженности делается документом начисления задолженности на дату документа и в свой регистр накопления (расчеты по займам).
Фактическое списание задолженности делается документом списания задолженности на дату документа и в тот же регистр накопления (расчеты по займам).

А вот ПЛАН платежей, согласованный договором\доп соглашением, с актуальностью плана на дату как хранить - в этом суть вопроса.

(8) Каждое изменение плана графика - отдельной хоз операцией.
тогда да, РС, но измерений больше: Контрагент, Проект, Месяц, версия графика
Ну и общую процедуру для получения актуальной версии графика

Смотри - сам график платежей он имеет в самом начале какой то корневой документ. Там договор лизинга, займа или что еще угодно.
Любая сущность, которая меняет первоначальные настройки, да и сами первоначальные настроки - создают служебный справочник - ВерсияГрафика, которая однозначно связана с самым главным доком.
И этот справочник при записи пишет в РС.
Если упрощенно - то в конфе которая была целиком и полностю на графиках и учете их отклонений построена - принцип был именно такой.

(9) (10)
Спасибо, буду думать, какой вариант лучше использовать.

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