Выгружаем многостраничный PDF спул

Всем привет!

Сегодня день ABAP. Понадобилось мне выгрузить многостраничый запрос в спул в формате PDF. Не нашел ни одного стандартного решения для этого, поэтому пришлось тряхнуть стариной и написать минипрограммку. Суть простая. Вот такой спул выгружается в виде отдельных PDF файлов в указанный каталог. Никаких проверок внутри нет, так что используем на свой страх и риск. Мне оно надо только раз в год, поэтому приспичило и пришлось нарисовать. За красоту кода ругать бессмысленно 🙂

multi_pages_spool

Читать далее


Окончание учетного период для суммированного учета рабочего времени (СУРВ)

Маленькая операция для оценки времени на проверку окончания учетного периода при суммированном учете рабочего времени. Поводом для изменения является окончание календарного года или увольнение. А дальше в оценке времени уже анализируется баланс рабочего времени, формируются виды оплаты в своем правиле.

Программа SAPFP51T

*&———————————————————————*
*& Form OP_ENDP
*&———————————————————————*
* Проверяем окончание учетного период для сумм учета (СУРВ)
*———————————————————————-*

Читать далее


Как свести BW с ума. Экстрактор 0HR_PY_1_CE

Скажите, а как вы закрываете год от изменений?

Возможно я забыл что-то, но пока единственный централизованный способ, который знаю, это изменение даты обратного расчета в управляющей записи единицы расчета. Только вот поменять ее нельзя без удаления и повторного создания единицы расчета. А BW это не нравится. Вот вырезка из ноты:

The payroll control record is used to define payroll results as being «final» and this is the basis for the delta process with payroll results.
Caution: Deletion and new creation of control record is not recommended in a productive system and might cause inconsistencies on BI side.

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

Note 1162627 — Payroll Extracotor 0HR_PY_1_CE


Экстрактор 0HR_PT_2 еще граната

Так, товарищи. Печальная новость — найдена еще одна недокументированная граната экстрактора 0HR_PT_2. Точнее не так, она документирована, но специфично. В табличке V_T569R есть два модификатора (05 и 06), которые определяют временное окно, в котором BW экстрактор ищет данные для загрузки. Если вы только стартанули или нужно сделать полную загрузку данных, то нужно модификатор 05 (самая ранняя дата перерасчета) установить на дату старта (или когда у вас появились данные в системе).

Если вы уже сделали полную загрузку, отработали годик, а потом вам нужно перезагрузить весь объем данных, то увы, система выдаст данные только в указанном временном окне. Поэтому алгоритм таков:

  1. Перед полной загрузкой (или инициализацией дельты) меняем дату на самую раннюю в табличке V_T569R
  2. Как закрыли год от изменений, то меняем дату на начало следующего года
  3. При перезагрузке см. пункт 1.

Investigation efforts: 1 час.


Странности экстрактора 0HR_PT_2

Этот экстрактор настоящая редиска. Он выгружает данные из ERP системы по видам времени. Но делает
это весьма специфично в части определения периода выгрузки. В частности, сегодня я столкнулся с тем, что если у вас заведено какое-либо длительное отсутствие (декрет, например), на несколько лет вперед, а графика рабочего времени нет на будущие периоды, то всем привет. В США есть отсутствие «Компенсация работникам по нетрудоспособности» (Worker’s Compensation). Работник числится в компании, но выплаты ему делает государство до его реабилитации при несчастном случае. Так вот, дата выхода работника неизвестна, поэтому мы вводим отсутствие без ограничения срока. Понятно, что графики до 9999 года не сгенерированы, и система вываливается с предупреждением, что персональный график не найдет на какой-то там год.

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