Архив метки: ALE

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

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

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

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

Читать далее

Вопрос — ответ. 6

Вопрос:

Есть две 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 CREMAS есть только БЕ и закупочная организация. Надо добавить в фильтр группу кредиторов. Делается на раз.

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

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

KTOKK E1LFA1M 1 KTOKK 132 4

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