Спасибо! Посоветуйте еще, что проще реализовать: считать на каждое разнесение доходность с учетом предыдущих платежей или остаточную себестоимость? В ХВ можно что-то сложное писать с селектами?

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

Доброе утро!

И все равно мне непонятно:

1. По Вашему алгоритму получается, что при каждом следующем поступлении ДС доходность будет рассчитываться с учетом ранее поступивших ДС, т.е. я не буду иметь возможности увидеть доходность каждого поступления в отдельности.

2. Т.к. я не программист, как-то смутно представляю реализацию проверки: первое это поступление ДС или последующие (типа проверка наличия поступления по данной реализации с меньшей датой).

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

Вот если бы на пивоте можно было просуммировать все поступления и уже эту сумму сравнить. Но, по-моему, это нельзя сделать?

Хм. Если я правильно Вас понял:

1. ХВ хранится в каждом разнесении и его значение отличается от других.

2. Как-то надо нахимичить алгоритм расчета доходности по каждому разнесению с учетом ранее поступивших ДС по этой же реализации по аналогии с моим алгоритмом.

3. В пивот выводить значение этого поля из разнесения с максимальной датой.

Тогда как мне потом получить доходность по второму поступлению, если эти поступления в разных учетных периодах? Или в каждом поступлении делать два ХВ, один для каждого поступления в отдельности, а второй накопительный с учетом ранее поступивших ДС?

Спасибо за оперативный ответ!

Заметьте, я сравниваю ДС с полной суммой накладной одновременно с/стью, но сравнить мне больше не с чем.

"Я бы выбрал путь добавления в разнесение ХВ (или своего триггера), и при регистрации поступления рассчитывал бы эту самую доходность по этому поступлению именно в момент сохранения" - это не выход, т.к. в случае оплаты _меньше_ с/с-сти по каждому поступлению в отдельности в сумме будет оплачено все равно _больше_ с/с-сти, и доходность все равно будет неправильная. При формировании отчета на конкретную дату это сработает, так же как работает и мой вариант. Но если в период попадут оба поступления, то получится то же самое. Мне обязательно надо считать и доходность по неполностью оплаченным реализациям. Если бы не это требование, вопроса бы не было. Тут в том-то и проблема, как учесть именно такой вариант, когда реально ДС больше с/с-ти. Может, что посоветуете с алгоритмом?