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

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

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

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

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

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

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

Трудоемкость этой операции составляет 2 ч/часа. Цена 1 ч/часа = 1.350 рублей. Срок реализации - 1 день с момента оплаты.

Здравствуйте!

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

Если Вы готовы самостоятельно работать с кодом и инструментами конфигурирования, то мы здесь выложим основные рекомендации. Но все же разумнее будет заказать эту доработку у нас, если она для Вас необходима.

Сергей, здравствуйте, отвечаем на Ваш вопрос:

Поле Расчет вознаграждения на карточке оборудования осталось от предыдущей версии программы, данное поле нигде в расчетах не используется и его, по всей видимости, забыли убрать. В текущей конфигурации «Полиграфия и сувенирный бизнес» расчет вознаграждения (т.е. оплата труда сотрудникам-производственникам) реализован через KPI – ключевые показатели. На данный момент реализованы следующие показатели, в зависимости от которых можно рассчитывать зп и оценить эффективность производства:

·         Количество выполненных операций

·         Сумма выполненных операций (расчет по себестоимости)

·         Количество операций брака

·         Сумма материала брака (расчет по себестоимости)

·         Количество операций по факту выполнения

·         Количество отработанных часов по факту выполнения

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

Ссылка на работу KPI (видео-ролик по работе с показателями):

ftp://office.axistem.ru/video/webinar7_kpi_motivation_ppt.avi