Продолжу рассказ о возможностях платформы Ultima Businessware. Сегодня — о нашем средстве для подготовки специальной отчетности. Средство это действительно возникло как ответ на необходимость оперативно получать отчет в привычном для руководителей высшего звена виде. И первые отчеты сделанные с его помощью были P&L и Balance.
Для лучшего понимания этой статьи очень полезно прочитать мою статью о устройстве системы и небольшую вводную из документации у нас на сайте.
На всякий случай попробую коротко повторить необходимый минимум.
Данные о измеримых показателях мы храним в так называемых итогах. В каком-то смысле это аналог куба из OLAP. Или регистра для знакомых с 1С. У итога есть измерения и переменные. Итоги изменяют свое значение транзакциями, которые генерируются документами. Все транзакции сохраняются, и можно вычислить состояние итога на любой момент времени. Транзакция в свою очередь содержит измерения и дельту для каждой из переменных.
На основе описания итога система может построить произвольный отчет. Данные можно сгруппировать по измерениям (или связанным справочникам), а каждая переменная раскладывается на 4 компоненты: Входящий и исходящий остаток (значение переменной на начало и конец периода) и дебет и кредит (сумма положительных и отрицательных дельт).
Например, в системе есть итог Реализация с измерениями клиент, товар, склад и переменными количество и сумма.
Соответственно, из него мы знаем, сколько товара какому клиенту и с какого склада продали и по какой цене (если быть точным, то и с какой себестоимостью и с какой прибылью). Второй важный итог — Затраты с измерением статья затрат и переменной сумма. В простейшем случае этих двух итогов достаточно, чтобы построить отчет о прибылях и убытках (P&L).
Отчет о прибылях и убытках имеет совершенно конкретный вид в МСФО. Соответственно, требуется средство для преобразования данных из итогов в заданный вид. Это, конечно, легко сделать с помощью печатной формы, но мы захотели иметь возможность разворачивать статьи этого отчета. А для этого у нас уже есть форма анализа итогов! Это значит, надо описать, какие преобразования надо провести с итогами и как объединить переменные и измерения различных итогов. Великолепно с такой реляционной алгеброй справляется SQL, но мы хотели дать возможность настраивать такие отчеты самим пользователям системы. Этот механизм мы назвали виртуальными итогами.
Итак, вот пример описания отчета о прибылях и убытках:
Да, этот отчет описывается на синтетическим языком. Как показала практика, в текстовом виде это делать удобнее, чем в любом (придуманном нами) конструкторе.
Итак, поскольку мы описываем новый итог, то в начале перечисляются измерения и переменные этого итога.
Dim соответственно dimension название измерения, далее в скобках указывается справочник, из которого берутся значения для данного измерения и наконец локализация.
Аналогично описываются переменные, тут она одна — Amount.
Примитивный отчет о прибылях и убытках должен иметь вид
Итого:
Доход:
Расход:
Соответственно в группу Доход мы включаем дебет составляющую переменной Amount итогов Sale (Реализация) и Expense(Затраты).
В группу расход попадают все положительные затраты.
И наконец группа Прибыль состоит из (суммы) двух групп Расход (с обратным знаком) и доход.
В результате, система генерирует такую форму для настройки отчета:
И вот такой будет результат:
Однако, мы ведь добавили измерения к этому итогу, давайте посмотрим, какие документы сформировали эти цифры:
Аналогично, можем дробить отчет по статьям затрат и прочим измерениям.
Для упрощения синтаксиса пришлось пойти по большое число соглашений. Например, по умолчанию измерения сопоставляются просто по совпадению наименований.
Рассмотрим более сложный пример. Есть итог, на котором происходит конвертация валюты и, соответственно копится убыток от операций конвертации. Этот убыток мы (как топ-менеджеры) хотим рассматривать как статью затрат убытки от конвертации. Однако, в итоге конвертация нет ни одно из измерений нашего итога. Не беда, из можно задать:
Зафиксировав таким образом статью затрат мы можем увидеть убыток от операций по конвертации на соответствующей строчке статьи затрат.
Синтаксис позволяет накладывать фильтры. Например, можно сделать группу «Баланс поставщиков» в которую будут входить только контрагенты, лежащие в папке поставщики. Фильтр задается ключевым словом filter и далее задается измерение и условие фильтрации.
Однако, иногда встречаются условия, невыразимые в рамках этого простого языка запросов и тогда его можно расширить за счет предикатов. Предикат в данном случае — формулируемое разработчиком выражение на SQL которое можно интегрировать в язык описания виртуального итога. Для примера — создать группу по итогу с балансами контрагентов, куда попадут только те, у кого есть неоплаченные заказы с учетом товарных кредитов и отсрочек платежа.
Я не ставлю целью подробно описать весь механизм и синтаксис языка в этой статье (для этого есть документация). Однако, надеюсь пролить свет на возможности системы и удобство разработки. Описанные механизмы позволяют обходится без сторонних средств анализа данных, что значительно сокращает бюджет внедрения. Но главное — оперативный и скольугодно детализированный доступ к данным у аналитиков и руководства компанией. Это реальное конкурентное преимущество!
Для лучшего понимания этой статьи очень полезно прочитать мою статью о устройстве системы и небольшую вводную из документации у нас на сайте.
На всякий случай попробую коротко повторить необходимый минимум.
Данные о измеримых показателях мы храним в так называемых итогах. В каком-то смысле это аналог куба из OLAP. Или регистра для знакомых с 1С. У итога есть измерения и переменные. Итоги изменяют свое значение транзакциями, которые генерируются документами. Все транзакции сохраняются, и можно вычислить состояние итога на любой момент времени. Транзакция в свою очередь содержит измерения и дельту для каждой из переменных.
На основе описания итога система может построить произвольный отчет. Данные можно сгруппировать по измерениям (или связанным справочникам), а каждая переменная раскладывается на 4 компоненты: Входящий и исходящий остаток (значение переменной на начало и конец периода) и дебет и кредит (сумма положительных и отрицательных дельт).
Например, в системе есть итог Реализация с измерениями клиент, товар, склад и переменными количество и сумма.
Соответственно, из него мы знаем, сколько товара какому клиенту и с какого склада продали и по какой цене (если быть точным, то и с какой себестоимостью и с какой прибылью). Второй важный итог — Затраты с измерением статья затрат и переменной сумма. В простейшем случае этих двух итогов достаточно, чтобы построить отчет о прибылях и убытках (P&L).
Отчет о прибылях и убытках имеет совершенно конкретный вид в МСФО. Соответственно, требуется средство для преобразования данных из итогов в заданный вид. Это, конечно, легко сделать с помощью печатной формы, но мы захотели иметь возможность разворачивать статьи этого отчета. А для этого у нас уже есть форма анализа итогов! Это значит, надо описать, какие преобразования надо провести с итогами и как объединить переменные и измерения различных итогов. Великолепно с такой реляционной алгеброй справляется SQL, но мы хотели дать возможность настраивать такие отчеты самим пользователям системы. Этот механизм мы назвали виртуальными итогами.
Итак, вот пример описания отчета о прибылях и убытках:
// dimensions and variables
dim AgentID (Agent): ru(Контрагент)
dim CostItemID (CostItem): ru(Статья затрат)
dim OfficeID (Office): ru(Офис)
dim FrcID (FRC): ru(ЦФО)
var Amount: ru(Сумма)
// calculated groups
group Income: ru(Доходы)
var Amount
total Expense: -Amount.Sub
total Sale: -Amount.Sub
end
group Outcome: ru(Расходы)
var Amount
total Expense: Amount.Add
end
group Profit: ru(Прибыль)
no details
var Amount
group Income: Amount
group Outcome: -Amount
end
Да, этот отчет описывается на синтетическим языком. Как показала практика, в текстовом виде это делать удобнее, чем в любом (придуманном нами) конструкторе.
Итак, поскольку мы описываем новый итог, то в начале перечисляются измерения и переменные этого итога.
Dim соответственно dimension название измерения, далее в скобках указывается справочник, из которого берутся значения для данного измерения и наконец локализация.
Аналогично описываются переменные, тут она одна — Amount.
Примитивный отчет о прибылях и убытках должен иметь вид
Итого:
Доход:
Расход:
Соответственно в группу Доход мы включаем дебет составляющую переменной Amount итогов Sale (Реализация) и Expense(Затраты).
В группу расход попадают все положительные затраты.
И наконец группа Прибыль состоит из (суммы) двух групп Расход (с обратным знаком) и доход.
В результате, система генерирует такую форму для настройки отчета:
И вот такой будет результат:
Однако, мы ведь добавили измерения к этому итогу, давайте посмотрим, какие документы сформировали эти цифры:
Аналогично, можем дробить отчет по статьям затрат и прочим измерениям.
Для упрощения синтаксиса пришлось пойти по большое число соглашений. Например, по умолчанию измерения сопоставляются просто по совпадению наименований.
Рассмотрим более сложный пример. Есть итог, на котором происходит конвертация валюты и, соответственно копится убыток от операций конвертации. Этот убыток мы (как топ-менеджеры) хотим рассматривать как статью затрат убытки от конвертации. Однако, в итоге конвертация нет ни одно из измерений нашего итога. Не беда, из можно задать:
group Outcome: ru(Расходы)
var Amount
total Expense: Amount.Add
total Convertation: Amount
value CostItemID: 192
value OfficeID: none
value FrcID: none
value AgentID: none
end
Зафиксировав таким образом статью затрат мы можем увидеть убыток от операций по конвертации на соответствующей строчке статьи затрат.
Синтаксис позволяет накладывать фильтры. Например, можно сделать группу «Баланс поставщиков» в которую будут входить только контрагенты, лежащие в папке поставщики. Фильтр задается ключевым словом filter и далее задается измерение и условие фильтрации.
Однако, иногда встречаются условия, невыразимые в рамках этого простого языка запросов и тогда его можно расширить за счет предикатов. Предикат в данном случае — формулируемое разработчиком выражение на SQL которое можно интегрировать в язык описания виртуального итога. Для примера — создать группу по итогу с балансами контрагентов, куда попадут только те, у кого есть неоплаченные заказы с учетом товарных кредитов и отсрочек платежа.
Я не ставлю целью подробно описать весь механизм и синтаксис языка в этой статье (для этого есть документация). Однако, надеюсь пролить свет на возможности системы и удобство разработки. Описанные механизмы позволяют обходится без сторонних средств анализа данных, что значительно сокращает бюджет внедрения. Но главное — оперативный и скольугодно детализированный доступ к данным у аналитиков и руководства компанией. Это реальное конкурентное преимущество!