Нетривиальный SAP Query

Всем привет.

Есть типовая задача – отчет по принятым сотрудникам. Нужно отразить, где сегодня находятся все активные сотрудники и дату их приема. Звучит просто, когда у человека нет перемещений, он принят после даты старта системы. Если же человек перемещался, дата приема может храниться в 41 ИТ или отдельным мероприятием (техническая загрузка), то при выборе периода “Весь период” на селекционном экране логического базы данных, система выведет все записи, включая перемещения и пр.

Есть несколько вариантов решения, которые мне приходят на ум.

Один вариант и самый простой – сделать дополнительное поле, в котором рассчитывать дату первичного приема (читать ее из 0041 или 0000 по видам мероприятий). Тогда выбор даты на селекционном экране устанавливаем в “Сегодня”. Система все инфотипы прочитает begda <= sy-datum <= endda, а наш допполе само по себе прочитает дату приема.

Второй вариант, это сделать в инфонаборе вывод endda для всех инфотипов, которые нам интересны. После чего на селекционном экране ставить период “Весь период”, а нужные нам инфотипы фильтровать endda = 31.12.9999, и вариантом скрыть эти поля. Тогда система 0000 или 0041 ИТ будет читать за все периоды, а тот же 0001 будет брать только на сегодня.

Ваши варианты без разработки всего отчета на ABAP? 🙂

11 thoughts on “Нетривиальный SAP Query

  • Все эти танцы нежизнеспособны.
    Вся стройная картина валится на этапе придумывания бизнес-требований типа

    “показать названия орг.единиц через слеш, начиная со второй от корня, но пропуская те, где в ИТ1222 чего-нибудь особенное”,

    “отчет формировать на любую дату, но фамилию всегда показывать на текущую дату”

    “не показывать принятых на след.день после увольнения”
    и т.п. и т.п…

  • вот еще ходовое:
    в поле “примечания” показать ФИО сотрудника, находящегося в “декрете”, на место которого принят этот сотрудник.

  • Calm, очень легко эти требования реализуются тем же апабом для пользовательских полей в 0001 инфотипе.

    Расширяем P0001_AF через CI_P0001_AF, пишем свой ФМ (строго определенного интерфейса) который будет выводить данные для каждой строки 0001 инфотипа в зависимости от этих дат (благо они всегда передаются в это ФМ, так уж устроен SAP QUERY на основе PNP/PNPCE). Единственное что не возможно сделать это вывести безразмерные величины в итоговый ALV sap query потому что там надо строго определять длину ибо от нее строится каталог полей ALV. Но по-честнаку этого и в обычном отчете тоже не сделать 🙂 нормально.

  • Фильтрацияю того что надо выводить и не надо выводить делаю обычно через реализацию маркеров. Эти маркеры обычно складываю в одно поле, по типу фасета, на экран не выводятся, фильтруются ALV вариантами. Да геморно, НО если для таких отчетов есть строгие бизнес-требования, то все не так печально.

    Но если уж вообще честно, квери не для таких фильтраций 🙂

  • Да, и Вит, все таки в стандарте есть поле которое сразу выводит дату приема на работу оно в инфонаборе для 0000 инфотипа есть. SYHR_A_P0000_AF_HIREDATE

  • Блин меня понесло, но допишу еще, чтобы рулить расчетом даты приема есть признак ENTRY и бадишка “HRPAD00_ENTRY_LEAVE”, если все настроить корректно то дата приема будет считаться при любых раскладах правильно.

  • >> очень легко эти требования реализуются тем же апабом
    Абапом – это всё понятно. Это ж абап.

    >>HRPAD00_ENTRY_LEAVE
    Хорошее бади, только почему-то не вызывался у меня в ФМе HR_99S_HIRE_FIRE

    >>Единственное что не возможно сделать это вывести безразмерные величины в итоговый ALV sap query потому что там надо строго определять длину
    Угу. Зато в эксель все безразмерное прекрасно экспортируется.
    Не видел ни одного пользователя, который _выходные_ данные отчета разглядывает в ALV.

    >>Но если уж вообще честно, квери не для таких фильтраций
    +100500 🙂
    Квери, это инструмент, который облегчит выборку. если нет возможности использовать абап (организационно или финансово).
    Костыль костылем. Начиная с пресловутого названия орг.единицы.

  • В общем, коллеги. Как мы все понимаем, те архитекторы которые выбирают квери для реализации требований конечного пользователя по конкретным отчетам скорее всего выбирают не правильную технологию.

    Если бы ко мне приходили и спрашивали я бы отговаривал от кверей.

  • >> почему-то не вызывался у меня в ФМе HR_99S_HIRE_FIRE
    Мой косяк был в том, что не достаточно устанавливать выходной параметр ENTRYDATES.
    А необходимо менять даты в таблице ENTRY_DATES, всё работает чётко.

    Видимо где-то анализируется параметр, а где-то таблица.

  • На одном из проектов, на квери было две спеки.
    ЗаАБАПили порядка 700 полей.
    Заказчик делал готовые наборы данных, получая кучу полезной отчетности.

  • Все правильно, это идеальный вариант когда заабапить 700 полей дешевле чем абапить 500+ отчетов.

Добавить комментарий