Алгоритмы глобальных стандартных переменных в SAP BW

Когда мы в SAP Query Designer рисуем отчеты, то часто прибегаем к помощи стандартных переменных. Сегодня я озадачился получением фонда рабочего времени за последние 12 месяцев для вычисления среднего значения. В системе нигде не описана математика стандартных переменных, а иногда хочется посмотреть на стандарт, скопировать и поправить под себя. Например, измерение 0CALMONTH «Календарный месяц» содержит интересную переменную 0CML3CM «Последние 3 месяца включая текущий». А мне нужно сделать такое же, только не включая текущий. Надо делать свое (хотя нашел в гугле переменную 0CML3LM, но ее у меня почему-то нет, а как добавить пока не умею). Так вот, рассказываю…

Читать далее


Дружим HR с BW

Сегодня день цепочек — я настраивал цепочки для автоматической загрузки данных из ERP системы в BW. Цепочка, это последовательность команд, которые надо выполнить, чтобы счастье случилось. Озарившая меня идея заключается в том, что расчет заработной платы можно организовать так:

  1. Делаем модель процессов (тр. PEST) для расчета заработной платы. 
  2. В модель встраиваем шаг проводок. 
  3. После шага проводок делается минипрограмма, которая вызывает событие (EVENT) в BW системе. 
  4. Запуск цепочки в BW указываем при возникновении события (стандартная функциональность в планировщике заданий).
Таким образом сразу же после проводок у нас запустится обновление BW с уже актуальными результатами расчета. Единственное, что я сейчас пока не знаю, как научить систему автоматически передавать созданные документы проводок в целевую систему. PUST создает сами документы, но их нужно еще деблокировать и отправить. Надо поискать программку, уверен, такая есть. 

BW: грузим время бочками

Привет.

Сегодня мы будем грузить время из ERP системы в BW. Для этого нам понадобится экстрактор 0HR_PT_2 «Actual personnel times», который можно найти в транзакции RSA5 на стороне ERP системы. Экстрактор глупый и работает просто. В кластере ракурсов VC_T557I есть настройка видов времени для отчетности. Это те самые виды времени (виртуальные), которые мы можем увидеть в SAP Query для временных инфотипов, так и в BW. Суть их в том, чтобы объединить данные из ERP системы (инфотипы, кластер) и выдать в одном формате, унифицированно. Если вы откроете любой вид времени, то в нем увидите возможность определить его через виды присутствий/отсутствий, виды времени из оценки времени и виды оплаты из оценки времени (табличка ZL). Если со всеми характеристиками все понятно, то в с закорючкой «Payroll hours/days» не очень. Это две дополнительные колонки. Только сегодня я познал истину, что это такое.

Рассказываю! Колонки Days/Hours считывают время из соответствующих полей инфотипа 2001 или 2002 (дни/часы). Значения в экстракторе выдаются в поле DUR_ACTUAL «Actual time». А колонки Payroll hours/days выдают информацию из полей Payroll инфотипа (расчетные дни/часы). И эти значения выдаются в поле DUR_VALUE «Acct-relevant time». Таким образом, нужно помнить, что правила подсчета отсутствий/присутствий повляют на результат, который выдает экстрактор в BW.

А во всем остальном никаких изысков, данные передаются один в один по каждому календарному дню.


Оценка персонала в SAP HR

Поговорим про оценку персонала в SAP HR. Чуть-чуть. Я еще только учусь, поэтому за что купил, за то продал.

Есть задача настроить хранение данных по оценке персонала в системе. Сама форма оценки достаточно стандартная: несколько разделов, в каждом разделе несколько вопросов и простая шкала оценки от одного до пяти. Решение состоит из двух частей: настройка шаблона (логики, полей) и настройка печатной формы (PDF или BSP).

Шаг номер раз. Настраиваем шкалы оценки персонала. Кластер ракурсов VC_T77SK. Примеры уже есть и очень наглядные.
Шаг номер два. Настраиваем шаблон в транзакции OOAM. Сначала создаем группу с общими свойствами шаблона. Например, годовая оценка, квартальная оценка — две группы; годовая постановка целей — другая группа. На уровне группы мы задаем общие параметры в виде колонок и участников. Колонка — по сути способ оценки/измерения. Например, колонка FAPP — Final Appraisal позволяет задавать только результат оценки. Колонка OBJL — Target задает конкретные целевые показатели, OBJ0 — Objectives — цели. Товарищи ГУРУ, если я ошибся, то поправляйте. Начинающих не бьют!
Шаг номер три. Теперь нужно создать сам формуляр уровнем ниже и все его узлы (разделы и вопросы из бумажки). На каждом уровне можно определить какая шкала и способ оценки (читай колонка) будут работать.
Шаг номер четыре. Больше всего я промучился со статусами. Они привязаны таким образом, что для определенных колонок должна соблюдаться строгая последовательность статусов. Например, если речь идет о постановке целей, то нельзя пропустить статус планирование (Planning). На последней закладке в Status Flow и определяется что за чем идет. Для каждого статуса отмеченного галочкой и затененного (обязательный статус) указывается вид кнопки и следующий статус для перехода. Таким образом и выстраивается процесс: создает анкет, планирование, процесс оценки, пересмотр, утверждение.
Шаг номер пять. Поток операций. Для каждого шага по уму бы надо указать событие потока операций и настроить сами потоки, чтобы система автоматически рассылала участникам «письма счастья» с напоминаниями что и когда нужно сделать. Плюс это сильно облегчит жизнь в части автоматизации процесса и контроля статуса.

Читать далее


Report to Report Interface (BW RRI)

Всем привет! Дошли мои глаза и руки до блога. Убив день на выяснение отношений с RRI хочу поделиться опытом начинающего. В BW есть такая штука, как переход из одного отчета в другой. По сути, детализация или раскрытие информации в ином ракурсе. Например, есть у меня отчетик, где колонки — счета главной книги, строки — МВЗ. В центре суммы, разумеется. Я хочу получить расшифровку по видам оплаты. Иными словами, чтобы у меня запустился другой отчет, где уже соблюдены установленные фильтры (период, МВЗ) и в разрезе по видам оплаты.

Элементарно, Ватсон. Идем в транзакцию RSBBS на стороне BW и создаем соответствие параметров отчета-отправителя — фильтрам отчета-получателя. А мучился я с тем, что у меня в обоих отчетах используется иерархия по МВЗ (0COSTCENTER). И при переходе в отчет-получатель, система не разворачивала иерархию и не работала по узлам иерархии (только по конкретному МВЗ). Вылечилось изменением типа передачи с Generic на InfoOject. Теперь красота!

Вот шаги:

Читать далее