Доброго времени суток. Ситуация следующая. Приходит клиент и берет товар в долг. Мы оформляем ему график платежей на несколько месяцев\лет вперед.  То есть в регистр падают записи всегда, от текущей даты на какое то время вперед. Теперь возникает два вопроса:
1. Нормально ли с точки зрения итогов такое использование и если нет, то чем чревато?
2. Как получить текущее значение долга, кроме как остатки на дату ТекущаяДата() + МногоЛет?

1. ненормально, ибо при каждой записи будут считаться итоги до конца будущего

(1)Если от текущей, это можно пережить.

(0) Фигня какая-то...
График платежей - это регистр сведений. Причем регистр, который может пересчитываться и перезаполняться при изменении условий (сокращение сроков, досрочное погашение, реструктуризация и т.п.).

>> Как получить текущее значение долга

Как текущее значение может измениться от того, что будет в будущем? Ерунда какая-то.

ИМХО, у вас какое-то странное понимание задачи.
Вы уж признавайтесь. Что вы там строите? Платежный календарь, бюджет ДДС или что-то еще?....

(3)График платежей это регистр накопления добавленный мной. Перечитайте (0) до момента, когда поймете что там написано, а не то, что вы себе придумали.

(0)
1. Чревато увеличением таблицы регистра.
2. Взаиморасчеты никак не связаны с графиком платежей.
Долг возник сегодня, вот на сегодня его и сомтрите.


(4) Ну так переделейте на регистр сведенний.

(0) (4)
Четко для себя осознайте предназначение РС и РН!

ЗЫ сегодня я одному буху, которая практиковалась кодить в 1с77 но бросила в связи с приходом 1с8 рассказал что я видел конфу товарищей кторые на справочниках построили зарплату в 1с77 в далеком 2000м.
Она долго смеялась...

(0) Посмотри как в УТ11 это реализовано.
И не путай долг, который образуется сразу и полностью, с графиком обязательных платежей, т.е. просроченным долгом и тд )

(5)Пришел человек сегодня 22.03 и взял товару на 50 000. 10 000 отдал сразу, еще 40 сказал отдаст в 4месяцев. Получаем следующее:
Долг 22.04  + 10 000
Долг 22.05  + 10 000
Долг 22.06  + 10 000
Долг 22.07  + 10 000

(5)То есть надо видеть при необходимости и долг весь и пропущенный если такой имеется на определенную дату. В данную архитектуру это вписывается идеально - вся информация есть и одном регистре.
(6) Это случилось, давно. Мне нужен регистр накопления. Или приведи лучшее решение, вместо привычного стеба.

(8) Пиз.ец....

Посомтри что ли как в типовых реализовано, тот же учет отсрочки.

(7)Где конкретно посмотреть?

(10) В конфигураторе

(11)Тогда уж лучше молчать, чем говорить, если сами не в курсе.

Обычно проблема с архитектурой решения. Сделать так можно, но лучше не надо.

(8) Мне просто интересно, как вы акт сверки построите за 2 квартал в вашем случае.

(14) Он планирует два регистра вести: один Взаиморасчеты, а другой свой с таким вот графиком платежей.

(4) (12) дерзкий ты малый.... Но я тебе подскажу решение - пишешь - заплачу за решение N рублей. И находишь кто тебе за эти деньги сделает. Сам в это время - продолжаешь троллить местных

+(16) Программирование - в принципе не твое. Иди в менеджеры, так думать не надо

Сделай в УТ 11 реализацию с заполненым графиком платежей! посмотри движения по регистру , конфигуратор даже открывать не надо.

Пишешь в регистр:
Период   Долг    Платеж
22.03   +40000  +  0
22.04    0      + 10 000
22.05    0      + 10 000
22.06    0      + 10 000
22.07    0      + 10 000

В чем проблема то?

(15) Нахрена два регистра? чтоб жизнь медом не казалась?

"График платежей это регистр накопления"(Web00001) Что-то я сильно торможу: если это регистр накопления, то кто/что мешает получать остатки на нужную дату? Неверно спроектирован регистр?

(0)
1. Укажи конфу свою.
2. Укажи жлеательно вид деятельности.
3. Не огрызайся тут. Будь вежлив с теми кто даже троллит.

И народ потянется.

Прошу прощения про пост с РС и РН.
Не поленился зашел в УТ 3.0 Каз это аналог УТ 11.0.
ТАм есть РН - РасчетыСКлиентамиПоДокументам

В нем есть измерение - ДатаПлатежа.
Вот вам и решение. Думаю дальше копать не нужно.

(21) "В нем есть измерение - ДатаПлатежа. Вот вам и решение."
Даа, только что хотел это написать.

Все ветку можно закрывать.

Полагаю что в тот РН пишется на одну дату (период) но несколько записей с разными датами ДатаПлатежа.

Вот вам и не придется писать в будущий период.

(22) Это бредовое измерение, придется распределять, да еще и последовательность отслеживать...
(23) Тож бред. Внимательно посмотри на (18)

Что вас так пугает запись в будущий период?

Поддержу автора темы, ничего не вижу плохого формировать движения в регистр накопления будущей датой. Ведь такой механизм активно используют методисты 1С. Действительно, например, в УТ11, если посмотреть как реализованы движения документа "Распределение РБП", "Заказ клиента", "Начисление бонусов" и так далее. Так почему нельзя использовать механизм, который использует 1С.

Чего далеко ходить - документы в ЗУПе, например, кадровые документы - большинство из них составляются заранее, до дня события (т.е. они пишут движения в будущие, относительно даты документа).

(24) А что там смотреть?

При продаже раскидываем по датам.
А при погашении строго по датам и закрываем.
А остатки по датам как раз и покажут что погасил что просрочил вплоть до копейки.

Уходить в будущие периоды не возбраняется если базы легкие и данных не много. А там где базы здоровенные и уход далеко в глубь в будущее тормозит получение актуальных остатков.

(28) Зачем городить еще одно измерение? когда уже есть ПЕРИОД в регистре? Потом мучиться раскидывать по этому измерению, отслеживать последовательность.
Потом получить какие то остатки на дату по дате... ппц...
Когда можно обойтись одним регистром и дополнительным  ресурсом. Смотрим в регистр Ут11 "Расчеты с клиентами "

(30) Полностью не осознал назначение этих двух регистров.
И задачу не понял. УТ11 эти оба регистра есть.
Мы автору ветки указали пальцем что это решено уже. А ты предлагаеь как он ломать и придумывать велосипед.

Расчеты с клиентами это для общего расчета на актуальную дату. А как раз РасчетыСКлиентамиПоДокументам  предназначен для случая с (0).

Если я в суждениях ошибаюсь кто-нибудь отдерните меня. Ибо я в типовых сильно не копаюсь.

(30) Да просто нету как таковой задачи в (0)
Городить второй регистр или нет, уже будет ясно после конкретных поставленных задач.

Одним регистром как минимум (причем малой кровью) уже получим долг клиента на дату и сумму которую он должен оплатить на эту дату. Это минимум который необходим из (0).
Ну а дальше полет фантазии, хоть стопятьсот регистров...

(0) каждому самодельному регистру задают самодельную логику обработки значений. То что это регистр остатков, а не только оборотов - это тоже всего лишь проблема логики и алгоритмов. А с программной точки зрения без разницы есть ли у регистра настоящая ТА по текущему времени проведения документа или это виртуальная ТА в позиции окончательного планируемого расчета по договору.

(32) а почему остальные участники дискусса начали сравнивать твое решение с УТ-11? У вас в основе разработки какая конфигурация?

(32) ой, перепутался в номерах постов - где ТС, где остальные :) - все потерялись куда-то

(35) Все уже все разрешили, это ты потерялся)

Все понятно, всем спасибо.