Sap hr настроить статусы резидентности

Подробный мануал «Как создать инфо-тип PA в SAP HR» или «Как приручить SAP?» (часть 1)

SAP – довольно распространенная система на крупных предприятиях не только запада, но и стран постсоветского пространства. Существует много сплетен и обсуждений, как позитивных, так и негативных по поводу SAP. И негативные отзывы связаны в основном, не столько со сложностью системы, сколько с интуитивно не понятным интерфейсом и отсутствием доступной литературы (книг, инструкций) на понятном русском языке.

Этой статьей я хочу дать начало доступным инструкциям по некоторым аспектам SAP, с которыми часто возникают проблемы у начинающих SAP’ёров. Данная статья будет посвящена созданию инфо-типов администрирования персонала (PA) для модуля SAP HR. Если данная инструкция Вам понравится и будет полезна, дорогой читатель, то, надеюсь, она будет не последней.

Скоро будет год, как я работаю на должности внутреннего консультанта SAP на проекте по внедрению модуля SAP HR очень крупного предприятия в Украине. SAP изучал с нуля: «гугл», скачанные курсы и советы внешних консультантов. Поэтому в данной статье я попытаюсь пошагово и доступно показать, как создавать инфо-типы PA для таких же новичков, каким и я был год назад (хоть и сейчас тоже далеко не «гуру»).

1. Для начала запускаем транзакцию PM01 – создаем инфо-тип. Пользовательские инфо-типы требуется создавать на 9-ку (предварительно советую проверить свободный номер для инфо-типа). Также в блоке «Подобъекты» радио-кнопка должна стоять на «Структура PS». Далее нажимаем кнопку «Сгенерировать объекты».

Система предлагает нам создать структуру для нашего инфо-типа. Соглашаемся.

2. Создаем нашу структуру. Стандартные поля (напр. BEGDA, PERNR) создавать не нужно, они автоматически привяжутся к инфо-типу. По рекомендации SAP поля нужно называть на ZZ*. Также определяем типы данных для наших полей согласно типов существующих полей в системе (напр. PLANS, который автоматом поставит тип данных NUMC и длиной в 8 символов), либо сами выбираем тип данных (напр. CHAR), нажав на кнопку «Тип компонента», задаем ему длину и даем краткое описание нашему полю.

Ещё один полезный совет. Если для какого-либо поля требуется средство поиска (как например стандартное средство поиска для выбора даты, при нажатии на пиктограмму, появляющуюся справа от поля), переходим на вкладку «Справка/проверка знач. ввода», где нажимаем на «ключик» и кнопку «Средство поиска». В 90% случаев требуемые средства поиска есть в стандарте, как например, поиск шт. должности по орг. структуре, как показано на скриншоте.

Активируем нашу структуру. При возникновении окошка показанного ниже не пугаемся, а нажимаем «Нет».

3. После этого нажимаем «Назад». Соглашаемся на несколько сообщений, после чего система предлагает заполнить табличку (T582A), где хранятся характеристики нашего инфо-типа. Нам нужно создать запись для своего инфо-типа, для этого советую скопировать уже существующий.

Сохраняем. Если нам потребуется изменить эти данные, то заходим в транзакцию SM30, где вызываем ракурс ведения V_T582A.

4. Наш инфо-тип создан. Его можно уже создать для человека в PA30, и использовать по назначению, если Ваш инфо-тип простой, и не требует никаких «подтягиваний» значений, операций после внесения данных и т.д.

На этом все инструкции обычно заканчиваются, и оказывается, что у нас инфо-тип не очень и простой, и что делать далее не понятно. Так, что я продолжу углубляться в данную тему.
В транзакции PM01, в блоке подобъекты есть ещё несколько строк, которые нам понадобятся:
а) Пул модулей (MPXXXX0, где ХХХХ – наш инфо-тип), где уже сгенерированы include-программы:
— *10 – Глобальные данные;
— *20 – PBO-логика;
— *30 – PAI-логика;
— *40 – подпрограммы,
где «*» — «MPXXXX».

Нам, в основном, потребуется PBO-логика (Process Before Output) и PAI (Process After Input). В PBO описываем все, что происходит с момента запуска ИТ до вывода его на экран (например мы подтянем действующую шт. должность человека, по которому создаем ИТ в поле zzold_pos). В PAI описываем все то, что будет происходить после нажатия «Enter», когда мы уже ввели информацию (напр., если нам надо посчитать, сколько осталось времени до даты zznew_date c текущей).

б) Экран. Нам, для нашего инфо-типа, потребуется экран 2000 – это экран для ввода и просмотра, тот что появляется в транзакции PA30. 3000 – для вывода записей ИТ списком (в PA30 пиктограмма в виде «горки с солнышком». 4000 и 5000 – для быстрого и пакетного ввода ИТ. Здесь мы затронем только 2000 экран, т.к. для быстрого и пакетного ввода потребуется отдельная инструкция, и наверно в несколько раз больше этой.

5. Для начала зайдем в 2000 экран, там выбираем радио-кнопкой «Редактор форматов». В нём мы сможем «рисовать» экран нашего ИТ. У нас уже созданы все поля из созданной нами структуры. Рисуем, наводим красоту.

При выборе поля открывается ещё одно окошко, с параметрами поля. Тут есть несколько нюансов. Во-первых, заполняем атрибуты. Здесь можно настроить обязательно ли это поле для заполнения, или отметить, что это поле только для вывода, либо же сделать текст выделенным (рисует его синим). Во-вторых, первое поле напротив надписи «Группы» должно быть обязательно заполнено. Значение «006», говорит о том, что данное поле видимо всегда. «Погуглив» можно найти, какие требуется вносить значения в эти 4 поля, например, для отображения поля только после нажатия на Enter. Это очень важный момент, для созданных уже полей там будет «006», но если вы создадите новое поле, и не заполните группу, то не увидите новое поле на экране, и с этим можно долго мучаться.

Следующим шагом будет выбор радио-кнопкой строки «Логика выполнения», где мы для нашего экрана пропишем логику выполнения.
В открывшемся окне все уже сгенерировано, а нам остается только прописывать дополнительную логику. Тут тоже есть Process Before Output и Process After Input. В модуле PXXXX, где ХХХХ – наш инфо-тип, мы можем писать все, что позволяет нам ABAP. Ниже пример кода в этом модуле, где мы при создании инфо-типа по человеку подтягиваем его штатку, и из 1000 ИТ по штатной должности подтягиваем описывающий текст.

Кроме того, в PAI тоже можно создать свой модуль, в котором можно описать логику, после того, как мы заполнили данные и нажали Enter.

Здесь мы смотрим, не изменили ли мы штатную должность, и читаем из 1000 ИТ описывающий текст по новой штатной должности.

Ниже скриншот, как выглядит созданный инфо-тип.

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

Источник

Настройка пользовательских статусов и статусных схем¶

Создание пользовательских статусов¶

Для создания пользовательских статусов создана таблица /TRL/XDE_CUST_ST . Ведение таблицы возможно с помощью транзакции SM30 и ракурса ведения /TRL/XDE_CUST_ST , либо с помощью отдельной транзакции /TRL/XDE_CUST_STATE .

В таблице нужно ввести следующие поля:

• Направление документооборота (DIRECTION);
• Код статуса (STATE);
• Пиктограмма статуса (SICON);
• Описание статуса (DESCR).

Если в статусной схеме будут использоваться коды статусов, которые не существуют в данной таблице, возникнет ошибка.

Создание пользовательских статусных схем¶

Каждая статусная схема имеет свой идентификатор и может присваиваться разным отправлениям по различным условиям. Для ведения настроек статусных схем существует кластер ракурсов /TRL/XDE_ROUTE (транзакция SM34 ), который можно вести через отдельную транзакцию /TRL/XDE_ROUTES .

Ниже приведены условия, которыми можно ограничить применение статусной схемы:

• Направление документооборота;
• Код оператора;
• Балансовая единица;
• Операторский тип документа;
• Код операции.

Перечисленные поля не являются обязательными для заполнения. Если поле не заполнено, оно не будет учитываться при сравнении.

В случае использования пакетной отправки вместо типа документа в поле /TRL/XDE_ROUTE-OED_DOC_TYPE нужно вписать значение «PACKAGE». Другие записи данной таблицы с пустым значением или указанием подходящего типа документа при работе с пакетной отправкой будут игнорироваться.

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

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

Таблица 429 Параметры для ФМ ¶

Параметр	Тип параметра	Обязательный	Технический тип	Описание
IT_META_NEW	Importing	/TRL/XDE_T_METADATA	Метаданные в новом формате
IT_META_OLD	Importing	/TRL/XDE_T_MTD	Метаданные в старом формате
IS_HEADER	Importing	/TRL/XDE_HEADER	Заголовок документа
EV_RESULT	Exporting	ABAP_BOOL	Результат проверки (true/false)

Таким образом, можно создать пользовательский функциональный модуль и реализовать в нем необходимые проверки. Если такой модуль вернет значение «false», то статусная схема применена не будет.

Если поле /TRL/XDE_ROUTE-FUNCTION не будет заполнено, то проверка вызова функционального модуля всегда будет возвращать значение «true».

Если поле /TRL/XDE_ROUTE-FUNCTION будет содержать несуществующий или неактивный ФМ, работа будет прервана.

Объект полномочий позволяет применять статусы из статусной схемы в соответствии с полномочиями пользователей. За основу пользовательского объекта полномочий может быть взят стандартный объект /TRL/XDE_E , созданный для этих целей, который проверяет поле XDE_STATE . Если статусная схема содержит несколько статусов и пользователь имеет полномочия на всю цепочку статусов, то будет установлен максимально возможный по полномочиям статус.

Если применяется пользовательская статусная схема и у пользователя есть полномочия на все статусы, то будет установлен максимально возможный пользовательский статус, но не следующий стандартный xDE статус.

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

Для отмены пользовательского статуса имеется кнопка Откат кастомного статуса , которая сбрасывает статус документа на предыдущий стандартный xDE статус.

Для дальнейшего движения по пользовательской статусной схеме необходимо использовать кнопки Согласовать , Отклонить , Удалить , Аннулировать , Подписать и Отправить . Другие операции будут запрещены.

Например, входящий документ в статусе I был переведен в пользовательский статус CR2 с помощью кнопки Отклонить . Чтобы перевести его в следующий статус CR3 , нужно повторно нажать Отклонить . Таким образом, смена статусов происходит с помощью нескольких последовательных нажатий кнопок для одной и той же операции.

© Copyright 2020, TerraLink Revision 38151d59 .

Источник

SAP ALE инструкция по настройке

Скажу сразу — не люблю писать подробные инструкции. Они расслабляют мозг и формируют класс ленивых консультантов. Профи должен «взять нюх» и найти решение. Поэтому эта небольшая инструкция будет направляющей, а не разжевывающей. Постараюсь дать ссылки и так далее. Хочу сказать спасибо всем, кто откликнулся и помог с материалами или советами. Отдельное спасибо Юрию Сычеву за помощь. Писать я буду со своей колокольни, так как не считаю себя ALE специалистом. Комментарии и правки только приветствуются. Поехали.

Всегда изучение чего-то нового в SAP начинайте с SAP Library, затем IMG, а потом можно и форумы посмотреть (рекомендую SDN). Не первый раз обращаю внимание, что многие часы я тратил зря, когда нужно было внимательно прочитать вышеуказанные материалы. Курсы по сапу я давно уже не открывал, просто отпала необходимость.

Основные понятия в SAP ALE

Для настройки и понимания ALE нужно запомнить два ключевых понятия:
ALE — Application Link Enabling. Технология передачи данных.
IDOC — Intermediate Document. Объект, который передается по ALE.

Все очень упрощенно. Есть бумажка (IDOC), ее нужно передать. На бумажке пишут письмо с информацией (заголовок, содержимое), указывают куда отправить. Почтальон копирует письмо (если несколько получателей) и отправляет. Отправители и получатели это партнеры в терминах системы. Письмо — IDOC. IDOC во всех системах имеет одинаковую структуру. Она очень большая и избыточная, но отправитель записывает только те поля, которые у него есть (или он считает, что только они нужны). Система отправитель с помощью фильтров отсеивает лишнюю информацию, а остальное отправляет на почту.

Почтальон, это модель распределения (тр. BD64), который знает куда отправить информацию. В модели распределения структура простая: отправитель — получатель. Может быть несколько отправителей, несколько получателей. Модель получается таковой, что отправитель всегда знает кто есть получатель. Я точно знаю кто ты — получатель (партнер, логическая система). То есть, я могу отправить Ване, а Ваня может переслать Феде. Или я могу сразу отправить Феде. Как хочу, как разрешает топология сети.

Для HR основной бумажкой (IDOC) является формат HRMD_A. Для каждой версии системы идет свой базовый тип, на основании которого строится этот самый HRMD_A. Это можно посмотреть в транзакции WE82. Найдите тип сообщения HRMD_A. Структуру IDOC можно посмотреть в транзакции WE30. Выбираете там тип документа для своей системы (у меня это HRMD_A07). Внутри будет структура сегментов, которая, если приглядеться, повторяет номера инфотипов. Это и есть та самая избыточность. При отправке данных заполняются только нужные сегменты (инфотипы). Остальное просто не включается в IDOC. Поэтому данные оргменеджмента и кадров будут в одном IDOC, если их не отфильтровать.

Изучив структуру, IDOC нужно понять, как же его отправить. Для этого надо определить отправителей и получателей. Здесь следующая иерархия (САП любит каждый чих запихивать в иерархические последовательности):

RFC путь. Транзакция SM59 поможет создать логические соединения до систем (по сути адрес сервера и манданта, с которым надо будет соединиться).

WE21 порт. Создаем надстройку над RFC в виде дополнительного логического объекта — порт. Все что нужно, это указать RFC соединение. Порт выбираем Transactional RFC.

WE20 партнер (логическая система). По сути это и есть наш отправитель/получатель. Здесь важно отметить следующее. Это первый фильтр высокого уровня. При создании партнера нужно определить какие виды IDOC могут через него проходить. Во входящих и исходящих параметрах нужно добавить все виды IDOC согласно направлениям, какие вы планируете настроить. Например, для HR системы отправителя нужно указать в исходящих вид документа HRMD_A07 (наш базовый вид) и указать порт (куда отправлять). Все это делается для логической системы (тип LS).

Осталось связать отправителей и получателей. Заходим в BD64. Это модели распределения. Создаем новую модель от отправителя к получателю. Нажимаем добавить вид сообщения и заполняем поля. Вид сообщения — HRMD_A. Банально, но это почти все. Теперь нам нужно получателю сказать, что мы ему хотим что-то отдавать. Для этого нажимаем в меню редактирования — модель — распределить. И указываем в какую систему отправить эту настройку. Система передаст информацию в ту систему. Теперь модель распределения в обоих системах будет одинакова. Не забудьте в системе получателе настроить порты, логические системы.

Чтобы нам не отправлять все, вся и всем, есть понятие фильтров. Два раза щелкнув на строке с фильров (под видом сообщения в модели распределения), можно открыть окно фильтров. Здесь мы указываем какие именно сегменты можно отдавать в эту систему получатель. Для каждого вида документа (IDOC) будет свой набор фильтров. Посмотрите, там все просто.

SAP ALE особенности для модуля HR

С точки зрения HR фильтров есть маленькие хитрости. Юрий Сычев подсказывает, что можно указать OM соединения сверху вниз, чтобы система сама сгенерировала обратные (снизу вверх). Таким образом будет меньше ошибок при формировании оргструктуры, когда система получатель получит дочерний объект, а старшего пока нет (не доехал еще) и начнет ругаться, что не может создать соединение. Поэтому фильтры делаем так:

Отдельно данные OM (инфотипы 1000-1999), отдельно данные PA (0000-0999) + (2000-9999).
Отдельно передаем связи сверху вниз.
Все это можно разграничить фильтрами.

Если вам нужно отдать информацию по табельникам в другие системы, то минимальный минимум это 0000, 0001, 0002, 0003 инфотипы. Плюс 0009, 0290, если нужно в FI для формирования кассовых ордеров.

Запуск интеграции через SAP ALE

Вроде все настроили, осталось проверить и отдать первый кусок данных. Сначала отдаем штатку, потом людей. Отправка HR данных делается одной транзакцией: PFAL. Указываете корневую О-шку, путь анализа, систему получателя и отправить. Система сформирует пачку IDOC и поставит их в очередь для отправки в логические системы. Если в настройках порта вы поставили галочку отправлять немедленно, то обработка начнется сразу же.

За ходом обработки можно смотреть в наглядной форме в транзакции BD87. Система покажет сколько и чего отправлено, принято, какие статусы. Там же можно встать на группу IDOC и нажать кнопку Обработать. Это протолкнет обработку зависших документов. Документы могут зависнуть из-за того, что в системе кто-то что-то блокирует из основных данных.

В системе получатели также можно запустить BD87 и посмотреть, что приехало. Если появились ошибки, то разверните ошибочный узел и увидите причины. Там же можно перезапустить обработку. Если два раза щелкнуть на строку состояния документов, то провалитесь в транзакцию WE05, где можно посмотреть содержимое IDOC и статус обработки каждого сегмента высокого уровня. Это поможет быстро найти причину ошибок (не хватает объектов, заблокированные записи и так далее).

Для автоматизации передачи данных есть механизм указателей (Change Pointer). Суть проста — как только что-то изменили в инфотипе, то изменение упаковывается в IDOC и отправляется всем получателям по модели распределения. Активировать это можно в транзакции BD61. В ракурсе V_TBDA2 отмечаем виды IDOC, для которых нужно генерировать указатели изменений. Указатели изменений будут формироваться в табличке BDCP/BDCPV. Чтобы из них сварганить IDOC нужно запланировать программу RBDMIDOC. Старые указатели (тестовые, например), можно удалить транзакцией BD22.

Литература и подсказки по SAP ALE

Много деталей осталось за кадром, весь САП здесь не опишешь. Но, глобально копать тут:
SAP Library
SPRO: SAP Netweaver -> Application Server -> IDOC Interface / Application Link Enabling (ALE) или тоже самое по транзакции SALE. Внимательно читайте хелпы к каждому пункту, там все разжевано!

Область меню в SAP:
BALM — распределение основных данных (отправить основные данные принудительно)
BALA — распределение данных для приложений (отправить какие-нить документы принудительно)

Источник