Расчет доходности реализации по ДС при частичной оплате

Александр, здравствуйте!

Основная причина проблемы в том, что Вы в Пивот выводите значения класса "Поступления.Факт.Разнесения", а в расчете сравниваете их с суммой полной реализации. В этом случае сам отчет необходимо строить либо на реализациях и уже по ним смотреть сколько доходности/оплаченности получается либо при расчете доходности использовать иной алгоритм. 

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

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

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

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

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

Почему Вы считаете, что мой вариант не выход?

Ведь при программировании алгоритма в этом случае можно получать сумму всей оплаты и пересчитывать доходность по всем разнесениям, либо по ФИФО, либо пропорционально сумме.

Допустим первый платеж сравнивается с суммой реализации и он меньше, применяем Ваш алгоритм. Потом приходит второй платеж и тут уже необходимо сравнивать сумму всех платежей по этой реализации и в них уже раскладывать доходность. И так далее. Основной минус этого решения - производительность... И что бы не нагружать транзакции сохранения лишними накладными расходами, можно сделать хранимую процедуру пересчета доходности по последним поступлениям (например за день) и каждую ночь (или по кнопке) её выполнять - 30-40 сек, но зато адекватные данные в аналитике.... :)

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

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

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

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

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

1. и 2. ХВ - это вычисление, которое хранится на классе. И оно одинаково для всех записей класса. Для того, что бы алгоритм работы был разным - проще всего в ХВ переопределить вызываемую процедуру. Либо вообще написать свой триггер, который будет делать то, что нам требуется и как требуется.

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

Доброе утро!

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

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

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

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

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

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

Да - всё, верно, необходимо начальную себестоимость каждый раз корректировать на сумму уже "погашенную" предыдущими платежами. Но вот реализовать это при построении отчета на лету, средствами вычисляемых атрибутов вряд ли получится... либо будет сильно тормозить из-за нетривиальности алгоритма. Поэтому и предлагаю решать задачу через триггер или ХВ с пользовательской функцией. Но в любом случае - тут надо будет немного кода на T-SQL написать, просто "взмахом мышки" в конфигураторе или дизайнере не обойтись.

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