Добрый день!

Пока искал информацию по разбору корреспонденции на просторах интернета наткнулся на тр. J3RKPAI, но никак не смог найти какой-либо информации по ее функционалу и методиках использования.

Посмотрел по коду - также не нашел обращения к ней, к таблице и ракурсу, которые ей ведутся.

Подскажите документацию, в которой есть информация по J3RKPAI или может у кого был опыт ее применения.

Заранее спасибо.

http://sapforum.pro/forum/viewtopic.php ... 33#p212933

Возможно пригодится при решении задачи:
viewtopic.php?f=5&t=71676

Забудьте уже благополучно про транзакцию J3RKPAI.
Никак она не задействована в разборе корреспонденции.
Легко увидеть, что данная транзакция открывает ракурс, основанный на таблице J3RKPAI.
Эта таблица, кроме данного ракурса, вообще не имеет использования. НИГДЕ. Она мертвая.

Как и многие другие настройки в корреспонденции. SAP их просто сделал, а зачем - еще не придумал.
Например, в таблице J_3RKKRN есть признак ZINKRP, который может принимать значения P и N.
Значение N (запретить) успешно работает. Значение P (предпочесть) вообще никакого смысла не имеет, потому что нигде не обрабатывается.

И таких мест очень много.
Не обращайте внимания на такие настройки и двигайтесь дальше.

Спасибо за ответы.

У меня почему-то сложилось впечатление, что если есть стандартная транзакция, то она обязательно должна где-то использоваться.
Функционал приоритета именно пар счетов мог бы решить многие проблемы, поэтому так теплилась надежда, что оно все же работает, просто я не знаю как. Но увы...

P.S. Встречался с ситуациями, когда при отсутствии конкретной записи в J_3RKKRN с ZINK = P система не давала разобрать документ, поэтому, наверное, смысл все же есть.

Значит, Вы неверно трактовали такую ситуацию.
Все использования ZINKRP сводятся к подпрограмме READ_ZKRN.
И в ней значение P не выбирается.
Более того, там зато выбирается значение I, которое в J3RKKRN вообще никак проставлено быть не может, потому что домен J_3RKINKRP такого значения не содержит.
Значение P никак не анализируется и в Вашей "ситуации" причина была откровенно в другом. Все использование таблицы J_3RKKRN сводится к формированию таблицы запрещенных пар, loop по которой осуществляется в подпрограмме CHECK_KRP.

SELECT SINGLE *
FROM T001
WHERE BUKRS = P_BUKRS.
IF SY-SUBRC NE 0. MESSAGE E037 WITH 'T001'. ENDIF.
FREE: ZKRN_N, ZKRN_I.
SELECT *
FROM J_3RKKRN
INTO CORRESPONDING FIELDS OF TABLE ZKRN_N
WHERE KTOPL IN (T001-KTOPL, ' ') AND
BUKRS IN (T001-BUKRS, ' ') AND
ZINKRP = 'N' ORDER BY PRIMARY KEY.
DELETE ADJACENT DUPLICATES FROM ZKRN_N.
SELECT *
FROM J_3RKKRN
INTO CORRESPONDING FIELDS OF TABLE ZKRN_D
WHERE KTOPL IN (T001-KTOPL, ' ') AND
BUKRS IN (T001-BUKRS, ' ') AND
ZINKRP IS NULL ORDER BY PRIMARY KEY.
DELETE ADJACENT DUPLICATES FROM ZKRN_N.
SELECT * FROM J_3RKKRN
INTO CORRESPONDING FIELDS OF TABLE ZKRN_I
WHERE KTOPL IN (T001-KTOPL, ' ') AND
BUKRS IN (T001-BUKRS, ' ') AND
ZINKRP = 'I' ORDER BY PRIMARY KEY.
DELETE ADJACENT DUPLICATES FROM ZKRN_I.

С этим не спорю.

Но, вероятно, имеет значение не сам параметр J_3RKKRN-ZINKRP = P, а непосредственно наличие строки в таблице J_3RKKRN.
Учитывая, что при вводе строки параметр может принимать всего два значения P и N, а также то, что запрещать эту корреспонденцию нам не надо, то остается два варианта: ввести строку с ZINKRP = P или ее совсем не вводить.

Вот на "совсем не вводить" программа и отреагировала болезнено на мой взгляд.

Много лет назад уже перетерли эту тему и сварили варенье Приоритеты не работают. Только запреты. Это Россия

Я пишу о том же.
Но имплицит энхансмент и православный крест делают свое дело! Я вот научил систему работать с приоритетами, бебебе