Добрый вечер!
Выписка вводится вручную. Вид последующей обработки = 4
Вторая область проводок формируется в транзакции FEBAN.

Вопрос 1 : если банковская выписка проводится вручную, то никаких алгоритмов интерпретации не используется, верно?
как же тогда возможно автоматическое выравнивание?

Вопрос 2: почему заполненное в FF67 поле FEBMKK-KUNNR (дебитор) не переносится в FEBAN в поле FEBEP-AVKON ? Что нужно сделать, чтобы переносилось.

Вопрос 3: Если платеж исходящий, то в FF67 заполняется поле FEBMKK-PYORD. А если платеж входящий, то какое поле нужно использовать для
сохранения номера платежного поручения для входящего платежа?

Вопрос 4: как в дальнейшем в созданном документе платежа сохранить номер платежного поручения в поле Ссылка (BKPF-XBLNR)

спасибо за помощь

Интерпретация - это объяснение программе, какой смысл вы вкладываете в значение поля референс при таком-то коде операции. 12345 - это что? Номер вашей платежки? Номер вашего СД-счета, выставленного покупателю? Номер вашего ФИ-документа, который вы хотите выровнять. Так что, интерпретация по любому нужна. Возьмите FB05. Там есть выбор критериев выравнивания. Вот, если на пальцах, то интерпретация - это выбор критерия выравнивания. А зачем вам дебитор, если вы хотите делать выравнивание? Настройте на номер документа, который ваш дебитор оплачивает. Иначе с дебитором вы будете выдавать несчастному юзеру список открытых позиций, из которых надо руками выбирать нужную. А какую полезную информацию несет номер входящей платежки? Единственное зачем этот номер нужен - удовлетворить амбиции некомпетентного законодателя, который затребовал этот номер в налоговых расшифровках. Вам как получателю платежа нужно определить даже не плательщика, а позицию выставленного к оплате счета. Если у вас ничего не поломано, то номер фактуры из SD наследуется в BKPF-XBLNR. Если ваш плательщик сообщает это значение в качестве референса для получателя платежа (а себе ему удобнее использовать собственный номер платежки), то это позволяет даже в электронной выписке выровнять позицию автоматом, если конечно сумма платежа совпадает с суммой счета. ломать - не строить? А зачем? почему именно в это поле? По падонски можно конечно наабапить экзит, который будет апдейтить поле в заголовке выравниваемого документа. Но это только из области вредных советов.

И таких падонков пруд пруди, кстати, по России-матушке.
Возможно, это тупо удобно потом для расширения отчетов по отдельным позициям. Может, что-то еще.
По-хорошему, конечно, номер платежки удобнее добывать через документ второй области из febep. Может, если афтар предложит подобную альтернативу юзверям, то их и такое устроит. Но если, к примеру, для разноски используется какой-нибудь технический 62 счет (типа промежуточной второй области), а потом все это добро разгребает бухгалтер на участке, то тогда, может, и удобно. Просто жалко такое ценное поле, как ссылка, тратить на такую чревоугодную цель.

спасибо большое, Sedlo!

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

Поле "Ссылка" это ведь классика для сохранения номера первичного документа, разве не так?
Для входящего платежа - платежное поручение и есть первичный документ.
А где по опыту удобно хранить номер исходящей платежки?

Ну дык а что делать, если для описания национальной практики внедрежа лучше всего подходит падонско-луркоязное наречие (а командно-матерный запрещен правилами форума). Насколько я понял ТС, номер входящей платежки нужно сначала набить в ручную выписку, а потом куда-то присунуть в ФИ-документ. Я бы в позиции документа с тем же PYORDом поиграл. Но т.к. он несколько для другого предназначен, может и на какой-нибудь из XREFов пришлось бы поменять. Падонство - так падонство

Прошу прощения, я вас неправильно понял. Я решил, что вы хотите переписать значение XBLNR не в выравнивающем платеже, а в выравниваемом счете к оплате. В платеже - вроде и нормально.
Исходящие платежки сидят в позиции кредитора в поле PYORD. Когда разносите выписку хоть ручную хоть электронную, FB05, в которую лезут и ФФ67 и ФЕБАН, не позволяет выровнять ни по какому другому аргументу кроме как по номеру платежки.

Для авансов исходящих и исходящих платежей прописала алгоритм интерпретации 029.

Для ввода БВ ввожу значения полей:
Transaction
Value date (подозреваю, что можно автоматически заполнить данными на входе)
Amount
Customer number
Bank reference
Allocation number

Выходит, что поле Pyord не обязательно заполнять, можно обойтись и полем Bank reference если используется 029 алгоритм.
я ничего не настраивала специально, номер PYORD сохраняется в поле Text позиции платежного документа.
где это настраивается?

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

Это для бухгалтера важно, аванс это или вдогонку платеж, а для распознавания - без разницы. Если вы в этом вашем САПе создали платежку, значит этот ваш САП должен знать по какому поводу. Вот если АПП не используется, и платежки готовятся и нумеруются вне системы - тогда другое дело. это важное поле
из моей практики, это поле - генератор хаоса
ну не без этого
вот это имхо лишнее, но оппонентов у меня много, и у них тоже свои аргументы.
да
вот не помню, использовал или нет. Я ручную выписку крайний раз больше 10 лет назад настраивал, и то в качестве факультатива к электронной.
это проще протестировать, но скорее всего да.
вот так на вскидку не помню, скорее какой-то общий алгоритм все что не интерпретируется кидает в Текст позиции
лично я не встречал ни одной операции, где номер контрагента был бы достаточным для выравнивания параметром. В тех же авансах, если по уму, у вас все равно должен быть какой-то исходящий документ, который будет оплачивать плательщик (не обязательно он будет покупателем - может быть и альтернативный). Так что даже к входящему авансу должен быть какой-то SD-заказ, из которого вылупляется ТАП, у которого номер в BKPF-XBLNR...

Поле Customer оставила пустым для входящего платежа, заполнила только поле Bank refer. номером бумажного счета - автоматич. выравнивание не работает.
Заполнила дебитора, опять не работает. Похоже потому, что оплата не на всю сумму.
Алгоритм интерпретации 021.
это обычное дело для частичных входящих платежей?


Для авансов входящих ТП не создаем (возможно и зря).

спасибо,darkduck
А если следующая ситуация:
1 платеж 40%, выравнивание частичной оплатой не автоматическое
2 платеж 60% .Возможно ли на втором этапе выравнивание автоматическое, если неоплаченный остаток совпадает с суммой платежа?

Sedlo, Вы пишете что дата валютирования - генератор хаоса. а поле Customer вообще лишнее
Транзакция FF67

1)На входе "заголовок" выписки уже содержит две даты Дата выписки, дата проводки (позиций выписки).
дата валютирования появляется при вводе позиций.
Разве может дата валютирования от даты проводки отличаться? имхо нет, не могу придумать такую ситуацию.
Вопрос: зачем тогда SAP требует вводить дату валютирования, если она совпадает с датой проводки позиций выписки.

2)аванс полученный. Про него ничего не известно кроме дебитора и договора. ТАП для входящих авансов не формируем. выравнивать ничего не нужно автоматически. Специалист по вводу БВ знает и контрагента и договор и будет его вводить в FF67. В FEBAN отражается только номер договора, дебитор канул в лету....как заcтавить FEBAN считать уже введенные данные по контрагенту?

3)кредит полученный. В FF67 я ввела кредитора-банк в поле vendor, FEBAN конечно его не прочитал. В FEBAN нет ничего похоже на поле Vendor, только Customer. В какое поле нужно вводить кредитора в FEBAN? поле Customer предлагает только дебиторов.

спасибо за помощь!

Я не уверен на 100%, но, возможно, feban учитывает "ссылку на платеж". Проверьте сами.

Это историческое наследие тех времен, когда банки занимались ручной обработкой огромного числа документов, сопровождающих платежки. Документы перевозились т.н. рейсами. Позиция выписки за "сегодня" может содержать дату валютирования "вчера", т.к. во вчерашнюю выписку последний рейс не попал. При таких раскладах FEBAN не особо нужен. FF67 в коде операции можно настроить на проводку без выравнивания. А дальше все равно процедурам выравнивания банковская выписка как таковая уже не нужна.
В [s]таблице[/s] структуре FEBMKK, к которой обращается ручная выписка, есть и KUNNR и LIFNR. Возможно, ваши настройки как-то повлияли на то что вендор потерялся.