Колеги, добрый день.

Во время интеграт теста, вылезла очень интересная ошибочка. Точнее даже 2.
Кореспонденция полностью настроена и работает (Активирована онлайн).

1) Когда делаеют CO11N, в FI, прилетает материальный документ: (скрины кликабельные)


Все, вреде бы, просто. 6 строчек, 3 простых пары.
Но после прогона J3RKKRS, система выдает следующую картину:


Пару со строки 3 и 4, система сама, по не понятному мне признаку разделила на 2 пары, + подставила счет....

Может, кто-то сталкивался с таким? Какие могут быть причины, и как решить такую беду?

(Все необходимые настройки по кореспонденции выполнены. Пробовал прописывать правила кореспонденции, с приоритетными и запрещенными счетами. Если пара "которую придумала система" - запрещенная, то J3RKKRS просто пишет что невозможно обработать документ, где есть эта пара (Хотя её там быть не должно).

2) Есть хитрые операции по учету на забалансе материалов.
Документ имеет следующий вид:

И такие документы не хотят обрабатываться J3RKKRS, автоматически. Для U* и Z* счетов настроены приоритеты. Пробовал прописывать правила кореспонденции с приоритетными счетами - не помогло. Может, кто-то поделиться опытом или знанием, как это побороть. (При ручном режиме, 0 строки между собой нормально сводяться).

Благодарю всех, кто откликнеться.

По первой задаче:
а. Тут уже много раз умные люди писали, что приоритетные пары не работают. Настройка такая есть, но она не обрабатывается, а обрабатываются только запреты. Можно поискать на форуме, есть разборы кода.
б. Вашу задачу надо решать подбирая приоритеты счетов (тр J3RKPAC). Можно совместить такой подбор с запретом корреспонденции.

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

Спасибо. Если приоритеты счетов и запреты наше все - то будем копать.

При разборе корреспонденции система наполняет позиции по дебету и по кредиту (две разных таблицы), после чего выполняет сортировку по убыванию приоритета, суммы и позиции (ФМ J_3RK_KORRSCH_MOVE5_KRP_ALL).
Позиция 4 имеет, очевидно, максимальный приоритет и пошла обрабатываться первой.
Позиции 2 имеет больший приоритет, по сравнению с 3, поэтому пошла сразу к позиции 4.
Позиция 3 имела меньший приоритет и ей досталось то, что оставалось от 4 после связи с 2.

Тут процесс суровый и долгий - баловаться приоритетами, как уже написано выше.
Повышение приоритета счета из позиции 3 сразу решит проблему, но может выстрелить на других проводках.
Также 100% сработает запрет корреспонденции по счетам из позиции 2 и 4, но это только если они и правда никогда не могут вступать в связь, то есть опять может выстрелить на других проводках.

Спасибо. Буду раставлять приоритеты по Вашему совету.

Коллеги, проблему решил настройкой приоритетов счетов.

Самое главное! Приоритет 9000 больше чем приоритет 8000. Для меня это было не очевидно... Через что было потрачено больше времени чем хотелось бы...

Поздравляю)
Но если бы Вы внимательно читали мой ответ, то увидели, что я писал про descending и даже указал имя ФМ)

Добрый день. Если можно еще вопросик по корреспонденции.
Чудеса продолжаються
Я все четко настроил на системе DEV. Перенес все настройки на QAS. И о магия... На качестве корреспонденция работает с ошибками. Полез в настройки. Все идентично.
Полез в дебаг, и вижу что при работе ФМ J_3RK_KORRSCH_MOVE5_KRP_ALL данные с таблицы J_3RKPAC вытягиваются с разной сортировкой в DEV и QAS:
Кликабельно.
Одинаковый код в DEV и QAS

Разная сортировка таблицы Priority


Через то, что сортировка в этой таблице разная, у меня по разному выбирается приоритет при сборе корреспонденции. Это вообсче законно? И как это побороть? Абаперы в недоумении, базис разводит руками...

Можно дописать, конечно же "логическую" сортировку по счету ГК, и тогда все будет отрабатывать корректно, но абапер, да и здравый смысл, против такой затеи. Может Вы сталкивались с такими чудесами?

Куда смотреть? На первой картинке идентичные куски кода.
На второй картинке начинка выбранной J таблицы приоритетов. Вообще всех. Это сырье, потом по ней будет луп с поиском по маске.
Когда мы говорим про сортировку, то имеется в виду сортировка позиций BSEG, а не сортировка позиций из J*PAC.
Какой смысл сортировать таблицу J*PAC?
В ней записи вообще хоть как могут лежать, это вообще не важно. Важно то, когда наткнется система в лупе на нужную маску и выйдет из этого лупа.
Приглядитесь, дубли могли закрасться.
Например, 0037*, 003*, 00371* или вообще прямое указание номера счета.
В разных системах они запросто могут быть разными.
На кого система наткнется первым, тот и водит. В разной системе это может быть разный результат.

Вот как себя ведет поиск приоритета.

FORM GET_PRIORITY USING P_TABLE_ALL_SAKNR
CHANGING P_TABLE_ALL_PRIORITY.
CLEAR P_TABLE_ALL_PRIORITY.
LOOP AT PRIORITY.
IF P_TABLE_ALL_SAKNR CP PRIORITY-SAKNR.
P_TABLE_ALL_PRIORITY = PRIORITY-PRIORITY.
EXIT.
ENDIF.
ENDLOOP.
ENDFORM. " GET_PRIORITY

Таким образом, вообще не важно, какие позиции в таблице и как они расположены.
Важно, когда система наткнется на паттерн.
И вот если только у Вас по разным маскам по идентичным счетам лежат разные приоритеты, вот только тут я соглашусь, что может быть проблема.
Например, задан конкретный приоритет для счета 37010101, а также строка с маской 0037*, уже с другим приоритетом.
И Вам хотелось бы, чтобы первым попался точный счет. Вот тут возможны некоторые флуктуации, но такая проблема решается неявным расширением в начале get_priority, а именно - долбить внутреннюю таблицу точным запросом по номеру счета, а не по паттерну. И при удачном результате выходить не дожидаясь лупа. В целом нетрудно.
Все остальное - это аутоимунные переживания. Ну не имеет никакого значения, как отсортированы записи в таблице PRIORITY.

Была у нас проблема с выбором приоритетов.
В тесте и в продуктиве при абсолютно одинаковых настройках по разному отрабатывала корреспонденция.
На сколько я помню, таблица с приоритетами буферизируется.
Проблему решили принудительной сортировкой в ENHANCMENTE где-то в районе ФМ J_3RK_KORRSCH_MOVE5_KRP_ALL.
Может быть у вас тоже самое.

Как связано одно с другим?

"Например, 0037*, 003*, 00371* или вообще прямое указание номера счета.
В разных системах они запросто могут быть разными."

Чтобы во всех системах выборка была одинаковой, мы делали принудительную сортировку

SORT PRIORITY BY SAKNR DESCENDING.

В этом случае сначала будет счет 00371*, если его нет, то 0037* и т.д.

Так вы меняете последовательность на обратную. Это другое дело.

Я думаю тут сап ступил, наверно так должно было быть в стандарте.

С другой стороны, если бы они не изобретали велики и вместо + использовали в масках ? как все остальные, то это бы работало без сортировок