Как посмотреть содержимое любой таблицы в SAP

С одной стороны мне нравится, когда у клиента все секурно – нигде не подкопаться, полномочия на пятерочку, служба внутренней безопасности работает на ура. С другой, когда я вижу открытые косяки у консультантов по базису и HR, хочется им сделать бяку. Сегодня мы смотрим способы просмотра любых таблиц в системе SAP ERP. Сразу оговорюсь, что не все способы могут работать в вашей системе из-за различий в версиях, настройках, волшебства.

Начнем с самых очевидных и всем широко известных способов. Открыть SE16 (SE16N), SM30 умеет каждый стажер. Это скучно и неинтересно.

SE38->RK_SE16N позволяет запустить ту же SE16N. Или SA38, которую часто оставляют для пользователей запускать отчеты без транзакций.

SE37->RS_TABLE_LIST_CREATE позволяет запустить SE16 интерфейс. Аналогично ФМ START_SE16N и еще куча других. Все не заблокируют.

Читать далее


Полномочия SAP

Друзья, я решил заняться этим сайтом, сделать его удобнее, привлекательнее и информативнее.  Для начала я собрал все заметки про полномочия SAP, SAP HCM в одном месте для вашего удобства. Справа вы увидите новую категорию “Полномочия SAP HCM” https://saphr.ru/sap-permissions/, милости прошу осмотреться и вспомнить что-то старенькое или забытое новенькое. В настоящий момент в категории 25 заметок.


Виды полномочий в SAP HCM – разбираюсь сам

Сейчас я себе вынесу моск. Вы посидите рядом, посмотрите, покрутите пальцем у виска в мой адрес. Я пока разберусь для себя, что же все-таки входит в полномочия HR, какие они бывают.

Основные и привычные нам полномочия, которые определяются объектами полномочий. Наиболее известные это PLOGI, P_PORGIN, S_TCODE. С ними все понятно, все умеют работать. Задаем поля, определяем какие полномочия на какие объекты присваиваются. Из важного только то, что внутри одного объекта полномочий все поля читаются системой как логическое “И”: если инфотип 0008 И доступ на “чтение”, то разрешить чтение. Один и тот же объект можно повторять в одной роли, тогда система будет читать объекты в одной или многих ролях по принципу “ИЛИ”. Если в объекте 1 есть доступ на чтение ИТ0008 или в объекте 2 есть доступ на запись ИТ0008, то дать ИЛИ чтение, ИЛИ запись. В зависимости от того, что делает пользователь. Поэтому нужно аккуратно назначать множество ролей, так как в одной роли могут быть расширенные полномочия на что-то, когда в другой сокращенные. В итоге система даст полномочия по расширенной роли, ибо работает принцип “у кого-то в роли есть такие полномочия = ИЛИ”.

Транзулька OOAC (ключики):
ADAYS – определяет сколько дней после перевода сотрудника можно его видеть. Например, если поставить число 10 дней (календарных), то на 11 день вы не сможете его увидеть согласно вашим полномочиям. Если проще, то был человек в разделе персонала А, у вас в роли права на раздел персонала А. Его перевели в Б. На Б у вас нет полномочий. Если стоит 0 дней, то вы сразу же после перевода (в ИТ0001 поменяется раздел персонала) перестанете его видеть. Если поставить больше нуля, то после истечения этого количества дней вы перестанете его видеть. Параметр работатает только для тех инфотипов, которым поставили галочку в поле T582A-VALDT. И только для объекта P_ORGIN.

APPRO включает и выключает работу инфотипа 130. Этот инфотип позволяет ограничивать доступ к данным на период закрытия заработной платы, например.

DFCON – определяет как системе реагировать на уволенных и несписочных сотрудников, у которых в ИТ0001 в поле штатная должность стоят все девятки. Работает только при включенных контекстных полномочиях (об этом дальше). Есть следующие варианты:

1 – смотреть на организационную единицу, по умолчанию отклонить доступ

2 – не смотреть на организационную единицу, по умолчанию отклонить доступ

3 – смотреть на организационную единицу, по умолчанию предоставить доступ

4 – не смотреть на организационную единицу, по умолчанию предоставить доступ

Когда у вас есть S в 0001 ИТ, то система штатно отрабатывает по профилю структурных полномочий и выходит на объект P (лицо, оно же табельный номер). Если мы уволили человека, или он находится в несписке, то обычно мы храним только организационную единицу. В зависимости от того, как мы хотим назначать доступы, нужно выбрать 1 или 3.

Если нам все равно на организационную единицу, мы хотим таким людям назначить действие по-умолчанию, то это варианты 2 или 4.

INCON включает или выключает структурные полномочия и использование объекта полномочий P_ORGINCON

Читать далее


Персонализация настроек пользователя

Есть в САП любопытный зверек в ролях полномочий, который отвечает за персональные параметры пользователя. Если нам нужно что-то массово присваивать пользователям, а затем дать возможность изменять индивидуально, то персонализация это наш конек. Параметры пользователя массово по бизнес-функции не присвоить. Объекты полномочий индивидуально на уровне пользователя тоже не изменить. Остается городить свои таблички либо воспользоваться механизмом персонализации настроек пользователя.

Некоторые приложения уже начали его использовать. Суть в том, что мы на уровне роли можем определить специализированные параметры, которые по-умолчанию будут заданы пользователям, у которых есть роль. Если нужно переопределить на уровне пользователя, то в SU01 мы это можем сделать. Очень удобно на мой взгляд.

Сам объект персонализации определяется в транзакции PERSREG. Это могут быть простые данные, так и табличные. Очень удобно хранить зависимые от пользователя настройки для расширений отчетов, например.
sap roles personalisation

Читать далее


О ролях полномочий (организационные уровни)

Роли полномочий. Все консультанты старше К1 должны знать и уметь. Аксиома от Поцелуева.

Организационные уровни – переменные, которые можно централизованно задавать для всей роли, не прописывая в каждом объекте полномочий. Сама переменная определяется в отчете PFCG_ORGFIELD_CREATE. Запускаем, указываем техническое имя переменной объекта полномочий, который необходимо сделать организационным уровнем (например, PESRK). Если ошиблись, то удалить можно отчетом PFCG_ORGFIELD_DELETE. Организационный уровень позволяет задать значение PERSK на уровне всей роли, и изменить его также в одном месте. Это удобно в HR ролях, где мы часто прописываем множество объектов P_ORGIN.

Ниже представлена простая роль из двух объектов полномочий.

Теперь мы переходим в меню Goto -> Org Levels.

Как видно, появился наш новый организационный уровень (PERSK по умолчанию не является таковым в стандартной поставке). Задаем нужное нам значение и сохраняем. Прошу!

Таким образом мы легко заполнили одинаковые поля во всей роли.