При передачи данных из HR в FI посредствам ALE происходит некорректная запись данных в 1 ИТ.

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

Исходящий idoc содержит новую запись 1ИТ. Передает ее в FI, входящий idoc обрабатывается и создает новую запись в FI в таблице РА0001, при этом предыдущая запись не ограничивается.
Получается 2 записи в таблице РА0001 для которых ENDDA = 31.12.9999, что вызывает динамическую ошибку при запуске РА20.

Кто знает как лечить? Помимо написания BADi обработки входящего idoc....

Может быть была нота на эту тему?

P/S Настройки PLOGI и 1 ИТ в двух системах одинаковы...

P/S Настройки PLOGI и 1 ИТ в двух системах одинаковы...

Временная привязка для ИТ0001 в системе с FI точно равна 1?.

да, 1

Такая ситуация возможно только в одном случае: на принимающей стороне пользователи изменяют данные.

Логика приёма IDoc'ов достаточно "тупая":

1. принимающая сторона сперва удаляет у себя записи с ключами аналогичными IDoc-сообщению,
2. затем создают новые с информацией, которая пришла в IDoc.

Перечисленные действия выполняются напрямую в БД, поэтому если на принимающей стороне запись ИТ была изменена, т. п.1 не выполняется и после п.2 появляется "задвоение".

Не совсем так.

Я проверяла передачу данных и никто их не менял.
Все дело как раз в том, что приходит новая запись с другими параметрами, которых нет в принимающей системе.
И она ничего не удаляет, а делает новую запись.

Каким способом передаёте информацию? Вручную или указателями изменений?

Если вручную (транзакция PFAL), то проверьте способ распределения ("Режим переноса" на экране выбора).
Судя по всему вы выбираете U "Обновление" - в таком случае система отправитель считывает данные как они есть, а получатель принимает и сохраняет в том виде как они пришли.

Попробуйте режим I - "Вставить" - в таком случае принимающая сторона принудительно сперва удаляет имеющиеся данные, и только потом сохраняет полученные. Подробнее см. справку.

Если передаёте через указатели изменений, то у вас где-то пошла рассинхронизация. Начните всё заново.

PS
Я бы использовал передачу по указателям изменений.

Через pfal как раз проблем нет... се верно.
Ошибки возникают только при передаче информации через указатели изменений.

Лан, буду писать Badi

Нет чтобы разобраться - сразу ABAP!!!

Попробуйте весь процесс начать заново - это должно "синхронизировать" состояние систем отправителя и получателя.

1. Остановить фоновое задание для обработки указателей изменения
2. Снести указатели изменения (транзакция BD22)
3. Провести первичное распределение основных данных согласно ноте Note 363187 - HR-CA-ALE: Initial distribution w. HRMD_A/HRMD_ABA (hint)
4. Запустить фоновое задание для обработки указателей изменения

если и это не поможет - я бы в поддержку написал.

Проблема в том, что по указателям изменений должно приходить ДВЕ записи, а не одна: старая запись с ограниченной датой действия и новая - с бесконечной. У вас же приходит только одна - вторая - запись. Логично, что старая не "ограничивается".

Может, у вас какие-то фильтры на указатели изменений? Напр., по изменению дат действия указатели не генерируются/не передаются.

Не совсем так:
САП сначала удалят все что попадает между датами BEGDA-ENDDA из сегмента E1PITYP, а потом вставляет записи из сегментов которые находятся под E1PITYP.
Если любая из дат в существующих записях на принимающей стороне за пределами BEGDA-ENDDA из сегмента E1PITYP, то такая запись не будет удалена.

Это механизм распределения основных данных управления персоналом. Но разве документы изменений по тем же правилам тиражируются? По идее, зачем гнать всю запись целиком и что-то там удалять/вставлять, когда можно только перенести изменение одного поля? Что-то у меня пробел в этом вопросе.

Документы изменений не тиражируются. Они лишь являются сигналом к генерации IDoc'ов.


Идей может быть много
Но реализация одна - факт.
И реализация эта состоит в том (как уже было сказано выше), что принимающая система тупо удаляет записи инфотипа в периоде BEGDA-ENDDA из сегмента E1PITYP и тупо создаёт записи, которые пришли в сегментах E1Pnnnn.

Я уже писала в поддержку.
Попросили сами посмотреть систему.
Я видела реализацию этой проблемы на одном предприятии именно через АВАР...
Вероятно так оно и есть и стандарт не предусматривает логической работы)

В чем проблема то? Можно пример по-подробнее:
Что в ИТ1 в обоих системах до изменения,
Менялся ли ИТ1 на стороне FI руками?
какие сегменты содержит IDoc и какие в них BEGDA-ENDDA
Что в ИТ1 в обоих системах после изменения,

В идеале перешлите ЕЕ полностью с помощью PFAL, а после сделайте изменение в ИТ1.

Когда я сталкивался с подобной проблемой, то причина была как раз в том, что юзер-экзит подставлял кривые BEGDA-ENDDA.
Так что советую не спешитьс АБАПом...

Виноват, протупил. Хотя ковырялся в этих потрохах, но, видимо, голова уже туго соображает - интеграция уже в печени сидит...