Как изменить логику расчета факта в разделе [Планирование]
Glossary Item Box
Общие сведения
Функциональность bpm'online sales позволяет планировать объемы продаж компании и анализировать фактическое достижение целей. Используя раздел [Планирование], можно формировать различные планы по ключевым срезам, данные о которых внесены в систему, и рассчитывать фактически полученные значения. Это позволяет анализировать выполнение продаж по выбранному периоду и оценивать эффективность отдела продаж в целом на основе сводных таблиц раздела [Планирование].
Подробнее возможности раздела описаны в статье "Раздел [Планирование]" документации пользователя.
Описание кейса
В разделе [Планирование] изменить логику расчета факта: производить расчет на основании счетов, а не продаж.
К СВЕДЕНИЮ
Исходные коды модуля и хранимой процедуры, полученные в результате выполнения кейса, можно скачать по ссылке.
Алгоритм выполнения кейса
1. Скопировать исходный код модуля построения плана
Для этого необходимо в разделе [Конфигурация] ([Configuration]) ввести название схемы ForecastBuilder в строку поиска (рис. 1, 1). После двойного клика по строке результата поиска (рис. 1, 2) в дизайнере модуля (см. "Дизайнер модуля") откроется схема модуля.
Рис. 1. — Строка поиска в разделе [Конфигурация] ([Configuration])
К СВЕДЕНИЮ
Поскольку найденная схема находится в предустановленном пакете, то перед ее открытием появится предупреждение о невозможности сохранения результата после внесения изменений. Подробнее о предустановленных пакетах описано в статье "Структура и состав пакетов".
Затем нужно скопировать весь исходный код модуля из вкладки [Исходный код] ([Source Code]) (рис. 2) и сохранить, например, в текстовом файле. .
Рис. 2. — Копирование исходного кода схемы модуля
2. Создать замещающий модуль построения плана
Для этого необходимо в разделе [Конфигурация] ([Configuration]) выбрать пользовательский пакет и на вкладке [Схемы] ([Schemas]) выполнить команду [Добавить] ([Add]) — [Замещающий клиентский модуль] ([Replacing Client Module]) (рис. 3). Создание замещающего клиентского модуля подробно описано в статье "Создание клиентской схемы".
Рис. 3. — Создание замещающего модуля
Для созданной схемы модуля в свойстве [Родительский объект] ([Parent object]) нужно установить значение "ForecastBuilder" (рис. 4). После этого автоматически будут применены значения всех свойств схемы, взятые из родительского модуля.
Рис. 4. — Свойства схемы модуля
Во вкладке [Исходный код] ([Source Code]) схемы нужно добавить исходный код родительской схемы, скопированный на предыдущем шаге, и сохранить схему.
3. Изменить метод открытия страницы плана
В исходном коде созданной схемы модуля ForecastBuilder необходимо заменить значения массива valuePairs в методе openForecastPage() класса Terrasoft.configuration.BaseForecastsViewModel на значения, соответствующие схеме объекта [Счет] ([Invoice]). Исходный код изменений приведен ниже (предыдущие значения закомментированы).
... openForecastPage: function(moduleId, operation) { ... var valuePairs = [ { name: "EntitySchemaUId", value: "bfb313dd-bb55-4e1b-8e42-3d346e0da7c5" //value: "ae46fb87-c02c-4ae8-ad31-a923cdd994cf" }, { name: "EntitySchemaName", value: "Invoice" //value: "Opportunity" } ]; ... }, ...
Значение идентификатора EntitySchemaUId можно получить, выполнив следующий SQL-запрос к базе данных bpm'online (рис. 5):
select lower(UId), Name from SysSchema Where name = 'Invoice' and ExtendParent = 0
Рис. 5. — Результат выполнения запроса
После внесения изменений, схему необходимо сохранить.
5. Внести изменения в хранимую процедуру tsp_RecalculateForecastFact
Хранимая процедура tsp_RecalculateForecastFact выполняет пересчет значений фактов за выбранный временной период. Выполнение и применение изменений в хранимых процедурах подробно описывается в статье "Как изменить хранимую процедуру (среда SQL Server Management Studio)" документации MSDN.
ВАЖНО
При составлении и выполнении SQL-запроса к базе данных следует быть предельно внимательным. Выполнение неправильно составленного SQL-запроса может привести к необратимому повреждению существующих данных и нарушению работы системы.
Поскольку для подсчета значений нужно использовать счета, а не продажи, то в процедуре необходимо внести следующие изменения (предыдущие значения закомментированы).
1. Изменить значение, хранящееся в переменной @CompletedId.
--SET @CompletedId = '{60D5310C-5BE6-DF11-971B-001D60E938C6}' SET @CompletedId = '{698D39FD-52E6-DF11-971B-001D60E938C6}'
В этой переменной хранится идентификатор статуса полностью оплаченного счета. Значение переменной можно получить, выполнив следующий SQL-запрос к базе данных bpm'online (рис. 6):
select Id, Name from InvoicePaymentStatus where Name = 'Paid'
Рис. 6. — Результат выполнения запроса
2. Изменить запрос, результат которого сохраняется в переменной @MaxDueDate.
--SET @MaxDueDate = (SELECT Convert(Date, MAX(DueDate), 104) FROM Opportunity o WHERE o.StageId = @CompletedId) SET @MaxDueDate = (SELECT Convert(Date, MAX(StartDate), 104) FROM Invoice o WHERE o.PaymentStatusId = @CompletedId)
В запросе выполняется поиск самого нового счета среди всех оплаченных счетов.
3. Изменить выражение подзапроса, хранящееся в переменной @SQLText. Именно в этом подзапросе реализована логика расчета факта и потенциала.
--Исходное значение /*SET @SQLText = N' SELECT (SELECT SUM(ISNULL(fiv.[Value], 0)) FROM [ForecastItemValue] fiv WHERE fiv.[ForecastItemId] = @P5 AND fiv.[PeriodId] = @P6 AND fiv.[ForecastIndicatorId] = @P7 ) PlanAmount, (SELECT SUM(ISNULL(o.[Amount], 0)) FROM [Opportunity] o WHERE o.[StageId] = @P1 AND o.[DueDate] >= @P2 AND o.[DueDate] < @P3 AND o.' + @ColumnName + N' = @P4 ) FactAmount, (SELECT SUM(ISNULL(o.[Amount], 0) * ISNULL(o.[Probability], 0) / 100) FROM [Opportunity] o INNER JOIN [OpportunityInStage] ois ON ois.[OpportunityId] = o.[Id] INNER JOIN [OpportunityStage] os ON os.[Id] = ois.[StageId] WHERE os.[End] = 1 AND ois.[DueDate] >= @P2 AND ois.[DueDate] < @P3 AND ois.[Historical] = 0 AND o.' + @ColumnName + N' = @P4 ) PotentialAmount'*/ --Новое значение SET @SQLText = N' SELECT (SELECT SUM(ISNULL(fiv.[Value], 0)) FROM [ForecastItemValue] fiv WHERE fiv.[ForecastItemId] = @P5 AND fiv.[PeriodId] = @P6 AND fiv.[ForecastIndicatorId] = @P7 ) PlanAmount, (SELECT SUM(ISNULL(o.[Amount], 0)) FROM [Invoice] o WHERE o.[PaymentStatusId] = @P1 AND o.[StartDate] >= @P2 AND o.[StartDate] < @P3 AND o.' + @ColumnName + N' = @P4 ) FactAmount, (SELECT SUM(ISNULL(o.[Amount], 0)) FROM [Invoice] o INNER JOIN [InvoicePaymentStatus] os ON os.[Id] = o.[PaymentStatusId] WHERE os.[FinalStatus] = 0 AND o.[StartDate] >= @P2 AND o.[StartDate] < @P3 AND o.' + @ColumnName + N' = @P4 ) PotentialAmount'
Для применения изменений нужно запустить выполнить SQL-сценарий (клавиша F5).
В результате расчет фактов и потенциалов будет выполнятся не по продажам (рис. 7), а по счетам (рис. 8).
Рис. 7. — Результат расчета фактов по продажам
Рис. 8. — Результат расчета фактов по счетам
Исходные коды модуля и хранимой процедуры, полученные в результате выполнения кейса, можно скачать по ссылке.