При интерпретации выписки 029 алгоритмом получается следующее. Хотя в выписке следующий текст:
:61:1303250325DB7000NTRF14//RU1OTPC130841929
Т.е., по идее, должен быть только PYORD 14.
А еще при выравнивании в FEBAN сначала попадает на экран ввода условий выбора, а не проводит сразу. Это тоже можно как-нибудь изменить?

На форуме не нашла, но нашла в ноте 114713 в описании алгоритма, что не стоит использовать "low number ranges". Спасибо.
Как-то можно указать АПП, чтобы из 10 стандартных диапазонов она НЕ использовала первый? Или его просто нужно удалить?

UPDATE
Просто забила статус для 00 интервала на 0999...99, программа перескочила на интервал 01. Смущает, что при создании платежки номер 01000...00 в FBN2 текущий номер отобразился как 1000000049.

лучше с номера, больше текущего номера года. А то модуль раздербанивания RFEBKA00 из текстули в таблице наплодит корявых позиций. В текстах часто попадаются даты, поэтому появление в FEBCL позиций с PYORD = 2013 будет вам долго нервы портить.

Столкнулись с такой ситуацией когда номер платжного поручения = 2013. Теперь в таблице FEBCL появляется вторая запись с PYORD = 2013 к основной. А при выравнивании в FEBAN система выдает экран ввод условий выбора. Как с этим бороться, до каких пор он будет лепить эту вторую платежку с PYORD = 2013 к основной??

Создайте ракурс ведения к FEBCL и силами сапорта убивайте паразитные записи, пока текущий номер платежки PYORD не превысит 2013. Потом убейте ракурс ведения от греха подальше.

Аналогичная ситуация возникла. Только причины немного другие.
Есть ПП, например 6966. Приходит это ПП через МТ940 с неструктурированным 86 полем. Грузим через FF_5.
В назначении платежа в 86 поле указаны номера счетов, договора и тд.и в том числе там есть цифры, например 6193. И у нас есть такая платежка 6193, по которой еще не проведена выписка. Очень большие объемы платежей.
И соответственно, система берет ПП =6966 с поля 61, как и положено записывает в FEBCL. И также находит в 86 поле значение 6193 и также записывает его в FEBCL. И получается две записи.
Можно взять диапазон номеров начинающийся с 100000000, тогда я думаю такие ситуации будут исключены.
Но вопрос в том, почему система берет с 86 поля какие-то значения? Может есть какая-либо настройка по этому полю, которую можно отключить? Или это баг?

Думаю, это не баг, а фича. Так как возможны ситуации, при которых юзеру так бы и хотелось чтобы система отрабатывала. Просто в вашем конкретном случае такая комбинация играет против вас. Поэтому в такой систуации стоит оценить, насколько целесообразно кодить обработку таких случаев. Возможно, при крайне редком подобном расположении звезд более рациональным будет написать инструкцию для юзера, при какой-то еще частоте - для саппорта (которому для обработки подобных инцидентов НЕ убили ракурс FEBCL), ну а если реально такое часто возникает - тогда да, искать точку выхода на обработку 86 поля и отрубать ее.

Возникает часто. Но мы сейчас обходим с помощью стандарта, в видимом режиме проводим выписку по правильной платежке.
Я и не хотела лезть в код. Мой вариант сделать диапазон с 10000000.....
Может еще какие варианты есть.

И потом я надеялась, что кто то уже разбирался с обработкой 86 поля, и подскажет логику

Ну, если бухгалтерия и кто там у вас главный по договорам (из моей практики договора - самая ничейная тема, одного хозяина не найти) не удавятся за нумерацию, их проще организационно растащить по разным диапазонам, чтобы не пересекались. И тогда со временем проблема сама рассосется, как со скрученными счетчиками RYORD и годами от рождества христова.

А причем здесь договора? Я хотела поменять диапазон не в договорах, а в платежках