Преобразования в ALE

Про настройку ALE мы немного уже поговорили в прошлый раз. Теперь обсудим возможности этого самого ALE, а в будущем и интеграции. Сегодня я разбираюсь в преобразованиях в ALE, которые позволяют на лету менять данные по заранее определенным алгоритмам.

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

Вся настройка преобразования IDOC в ALE заключается в трех простых пунктах меню в IMG. Запускаем транзакцию SALE и спускаемся до нужных нам настроек.

Читать далее


Вопрос — ответ. Временные данные по 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.

Вот и все.