подскажите как лучше сделать.
нужен мне отчёт по задолженности неких лиц, которые должны платить по графику.
график хранится в одном месте, сумма оплаты общая- в другом.
оплаты в регистре бухгалтерии. при этом задолженность в бухгалтерии формируется равными долями каждый месяц, а в графике может быть указано что платить должен раз в полгода по половинке.
и я вот думаю.
толи писать отчёт по тем данным что уже есть: т.е посмотрел туда, посмотрел сюда, поделил-умножил получил результат.
то ли сделать регистр накопления в которые заносить начисления по графику с минусом - выплаты с плюсом; и в любой момент в регистре актуальная инфа; но для этого надо лезть в конфу, дописывать движения и новые объекты создавать.

(1) По нормальному, сущности несущие избыточные данные должны создаваться при недостатке производительности. Если работа по первому варианту рельно затруднена, то да, второй.

(1) конфа для того и нужна, чтобы создавать отчёты в широком смысле. Так что всё ок.

спс

(0) Если отчет будет достаточно интенсивно использоваться - действительно, лучше склепать регистр.

(5) каждый день выгружаться, примерно 1500 записей.

если все данные есть в базе, зачем плодить лишние сущности? 1500 записей, это вообще ни о чем...

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

(6) Т.е. 1500 контрагентов, по которым надо рассчитать дебиторскую задолженность в соответствии с графиком? Да как-то не стоит тогда овчинка выделки. Движения, надо полагать, по ним не ежедневные, раз в месяц.

(9) при этом график меняется, сумма задолженности по графику тоже меняется.

(10) в этом мире всё меняется, всё изменяется...

(11) ;)

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

т.е. тебе оплатили, но ты всё равно формируешь долг ?

Мимими которые должны платить по графику.

график с суммами ?

(13) стесняюсь спросить, а бывает график платежей без сумм?...

(14) естественно

например, я тебе периодические оказываю услуги, сумма которые высчитываются по определенной формуле

в договоре указано, что каждого 5 числа следующего месяца ты обязан мне оплатить порядка 10 000 р
20 числа -- оставшуюся часть
если числа выпадают на выходной, то переносится на

zak555 ты обязан мне оплатить порядка 10 000 р

так это и есть сумма...

(16) по одному платежку сумму определили, а по второму ещё нет
но мне же всё равно изначально нужно знать, в какие дни планируешь мне платить...

стоимость второй оплаты будет ясна после того, в каком объёме примешь услугу (с 1 по 19)

(17) наверное в данной концепции понятие "график платежей" вырождается как класс? а ты не пробовал как-то проще работать?...

(18) когда объём услуг не определен, то суммы в графике не проставить...

но я у автор же не просто так спросил, что они автоматизируют - может там всё проще

(15) Ваши родственники или друзья со строительством не связаны?

(20) связаны
а что ?

(21) Логика очень знакомая ). Тогда понятна терминологическая разница в вашем восприятии. Большинство строителей так рассуждает.

(22) просто я видел много разных договоров

(23) Практично, конечно. Но иногда у строителей некоторые моменты далековато отходят от прочих областей. В принципе всё нормально, но если вдаваться в термины, может возникнуть некоторое непонимание.

(24) для было открытие, что строители начинают стройку без "детального" плана (рабочей документации)

(25) А зачастую ещё и без техники и рабочих ). Весёлые люди, что сказать.

(0) в типовых примерно так и написано - один регистр - один отчет

(13) вот так: должны заплатить мильон в год. График например 40 в январе/30 в мае/30в сентябре. Платят как попало. Задолженность начисляется в месяц по 1/12 от суммы. Сумма может поменяться в течерие года.
В явном виде сумма платежа за конкретный период не хранится, даты когда должен платить тоже в странном виде хранятся: номер дня и номер месяца .

Мимими даты когда должен платить тоже в странном виде хранятся: номер дня и номер месяца .

это же хорошо. можно посчитать в запросе