Коллеги, знаю, что подобные проблемы уже "обсасывались" на форуме со всех сторон, но в существующих темах решения пока не нашла. Может быть (а скорее всего так и есть), я что-то делаю неправильно или не так понимаю.

Из банка приходит выписка в формате MT940. После NTRF пишется номер платежного поручения. После прогона FF.5 этот номер попадает в FEBEP-CHEKT. Насколько я понимаю, чтобы выровнять платеж со счетом по средствам платежного поручения, ранее сформированного АПП, номер этого платежного поручения должен попадать и в FEBEP-XBLNR, но он туда не попадает.

Не знаю, нужно ли что-нибудь настраивать в DMEE для MT940, т.к. ранее настраивала только Multicash. Если надо, то как определить, какое форматное дерево им используется? На всякий случай прикладываю скрин FF.5, может быть там что-то не так указываю. Пробовала как написано в ноте 114713 указать для XBLNR интервал 'ZR1000000000 to ZR1999999999', но это тоже не помогло.

Писец как тупанула . Да, все верно, диапазон-то у меня от 0 до 999...999. Спасибо .

Вопрос возник по диапазону в полях XBLNR в FF_5
А проставление диапазона с буквами ZR-еще актуально?

Нота 114713:
Validity
This document is not restricted to a software component or software component version

Plank, не понимаю ответ. У нас работает без ZR.
То есть - уже не актуально?

Значит уже сломали...
Программа RFEBBU10:
CONCATENATE 'ZR' numc10 INTO char16.В стандарте 29 алгоритм без 'ZR' не работает.

Очень странно. Но ничего не сломано. Стандарт.
Ладно-будем смотреть код.

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

Покажите пример номера п/п, который формирует АПП (что лежит в PYORDP?) и пример номера, который вы указывете после 'ZR'.
Где у вас в выписке лежит номер п/п?

Номер ПП с АПП - Pryodp-0000009952.
ZR0000000001..ZR0999999999
МТ940-тэг 61

Работает и с ZR и без ZR. Но результат меня все равно не радует. По прежнему берется также и номер ПП с тега 86, хотя в 86 тэге как раз и не номер ПП, а просто номер или фактуры, или договора или контракта валютного и этот номер совпадает с номером существующего и еще не проведенного платежного поручения.
viewtopic.php?f=5&t=81877

Программа RFEBBU10

Если tfilter пустой, 029 алгоритм не работает. Если в tfilter нет диапазона номеров, начинающегося с 'ZR', в который попадает номер п/п, то 029 алгоритм не работает.
Непонятно, почему у вас работает без 'ZR' и нет Z* доработок...

На счет номера из 86 поля, то для борьбы с этим и придумали диапазон номеров 'ZR'.

Доброго вечера, коллеги!

прошу совета: настроила 29 алгоритм для разноски исходящих платежей.
При загрузке БВ система подтягивает лишние платежки :

в выписке МТ940 номер п\п 00051
в FEBEP в результате загрузки : INTAG = 29 , CHECT=00051

а FEBCL 3 позиции : SELFD=PYORD , SELVON=0000000001

SELFD=PYORD , SELVON=0000000002
SELFD=PYORD , SELVON=0000000051

:61:2309250925DT12300,00NTRF00051//2034965712 - строка БВ

Как такое возможно ? где может быть ошибка ?

Ну проще всего отладить в RFEBBU10, где пойдет интерпретация по 029.
Там внутри есть подпрогамма шпихер ту пуфер, где куски назначения, спец поля и попадания (hits) по серч стрингам (edges) объединяются, а дальше проверяется, входят ли эти куски в tfilter, при этом ко всем этим кускам спереди цепляется ZR, ну это баян.
Могу предположить, что есть 2 попадания. Это могло быть попадание куска назначения, спец поля (их, если помню, 2 - это chect и kidno, а также хитсы по регексу из серч стрингов). Все попадания проверяются на только цифры (выполнено) и на наличие в pyordp (выполнено).
Дальше идет формирование FEBCL по селвону. Но это чисто по памяти, где-то мог и приврать.

Как-то так

Известная тема. Счетчик платежек скручен в 0. описано здесь