Вопрос – ответ. Временные данные по ALE

Вопрос:

Есть две SAP HCM системы, требуется из одной в другую передавать временные данные (отсутствия/присутствия/замещения). Сделать это нужно через ale стандартными средствами. Расширение HRMD_A не предлагать, это банально, да и в стандартном решении есть вроде как ветка по передаче временных данных в SAP систему из внешней системы учета времени. По сути одна внешняя система учета времени реализована на базе SAP HCM TM модуля.

Ответ:

Немного изучив данный вопрос, нашел два способа (для себя). Пока не было времени попробовать на деле, но:

  1. Мы можем передавать временные данные из CATS. В этом и заключалась идеология общего табеля рабочего времени. С помощью программы RPTEXTPT и настроенного ALE для объекта PTManagerExtAttAbs осуществляется передача данных через буферные таблицы PTEX*. То есть в одной системе мы ведем данные в CATS, а другую они попадают в живые инфотипы с помощью этой программы. Если у нас CATS не используется, то нужно решить вопрос с формированием буферных таблиц из инфотипов, чтобы построить цепочку: инфотипы системы 1 -> буферная таблица системы 1 -> ALE -> инфотипы системы 2. Как произвести такую запись стандартными средствами пока не нашел.
  2. Второй способ, это формирование текстовых файлов на сервере в общих папках и их дальнейшая загрузка в инфотипы либо напрямую в инфотипы, либо через IDOC. Загрузчик можно реализовать в виде фонового задания LSMW. Выгрузка осуществляется через инструменты экспорта, транзакция PU12.
  3. Про расширение IDOC было обозначено в вопросе, поэтому не обсуждаем.

Это то, что пришло в голову в части стандартных решений. У кого есть что добавить – прошу!

Спасибо за хитрый вопрос 🙂


Change Pointers (Указатели изменений)

Поговорим сегодня об указателях изменений. Указатели изменений это такая штука, которая регистрирует изменения объектов, которые вам нужно передать по ALE в другую систему. Например, поменяли инфотип в HR, система создает указатель изменения на этот табельный номер и инфотип, а затем отправляет только измененные данные. Это позволяет увеличить производительность систем и сократить объемы передаваемой информации между системами. Иначе говоря, пропадает необходимость отправлять каждый раз все данные по всем табельным номерам.

Настраиваются указатели изменений очень просто.

1. Транзакция BD61 – активировать указатели изменений по всей системе
2. Транзакция BD50 – Активировать указатели изменений для конкретного вида сообщений (объекта). Например, данные по HR относятся к HRMD_A.
3. Программа RBDMIDOC – Запланируйте программу RBDMIDOC для периодической отправки объектов (IDOC) по ALE. Программа считывает таблицы указателей, создает IDOC и помещает в ALE слой для отправки в другие системы.

Периодически таблицу с указателями изменений желательно чистить. Это можно делать вручную (транзакция BD22) или с помощью запланированной в фоне программы RBDCPCLR.

Если вам нужно определить на уровне полей, какое изменение должно вызывать создание документа изменения, то в транзакции SE11 выбираем элемент данных, переходим на закладку “Прочие характеристики” (Further characteristics) и ставим галочку “Документ изменений” ( Change document). Теперь изменение поля с таким элементом данных во всех инфотипах будет вызывать создание документа изменения, и его отправку по ALE.


Техническая проверка документов проводок

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


Изменение содержимого IDOC

Travel Management интересная штука. Когда вы делаете проводку в FI систему, то оно не проверяет на период, открыт ли он. И ваш IDOC с авансовым отчетом может успешно уйти из HR и потеряться в FI. И никто об этом не узнает, если только не нажмет кнопочку проверки в транзакции управления прогонами PRRW. Так и сегодня отправили мой авансовый в FI и забыли. А он на дошел. В таком случае сторнировать нельзя, так как HR считает, что документ уже проведен.

Вот и приходится искать обходные пути. Либо удалять и заново создавать, утверждать у начальства и пр. Либо поменять всего лишь дату проводки в IDOC для FI документа. Я решил пойти вторым путем. В BD87/WE02 открываем нужный нам IDOC. Разворачиваем до уровня сегмента и нажимаем два раза на листочек рядом с названием сегмента. Теперь через меню меняем нужное нам поле и сохраняем. Сам IDOC при этом копируется, получает новый статус.

Осталось самое маленькое – отправить этот исправленный IDOC заново. Просто так этого не сделать, так как установленный статус 32 (отредактирован) не даст. Для этого меняем статус на 30 с помощью программы RC1_IDOC_SET_STATUS.

Вот и все.


Добавление фильтра в модель распределения BD64

Появилась маленькая задачка: нужно отфильтровать передачу кредиторов по группе. В стандартной системе есть для вида IDOC CREMAS, есть только БЕ и закупочная организация. Надо добавить в фильтр группу кредиторов. Делается на раз.

Транзакция BD65. Проверяем, что нужное нам поле есть для нашего IDOC и присвоено сегменту IDOC. То есть, система будет знать, где поле искать.

Транзакция BD59. Добавляем для CREMAS поле KTOKK:

KTOKK E1LFA1M 1 KTOKK 132 4

Вуаля. Теперь в модели распределения в BD64, если щелкнуть на фильтр для типа сообщения, то появится нашел поле с группой кредиторов.

Более подробно про интеграцию и ALE можно почитать в рубрике Интеграция: https://saphr.ru/integration/