Коллеги, добрый день!
Возник вопрос, как в новом FEBAN выровнять ТАП с выпиской?
В поиске документов ТАП не находится..
Кто практиковал новый FEBAN?

У нас был новый feban, выравнивание с ТАПом делали. Правда, был Z, который сам их же при этом и создавал, а потом наполнял таблицы с авизо. Но по факту выравнивание работало. А через что пытаешься на ТАП выйти?

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

Ну потому что памятная позиция - это какбэ и не позиция вовсе, а так, заметка на полях А вот деньги в фебане - они вполне себе материальны, под них ищутся проводки по алгоритму.

По идее - твой ТАП должен быть уже оплачен к моменту проката фебана, или должно быть авизо, и алгоритм попытается найти соот. реалььную проводку. Ситуация, когда реальные движения денег должны выравниваться с нерелевантными для баланса проводками (а ТАП это принципиально забалансовая позиция) немного нетипична, и сап по умолчанию ее не осуществляет.

Фактически это понятно.. Но по системе проводка же должна родиться на основании выписки, соответственно должен закрыться ТАП, далее проводка по авансу.
Тут скорее вопрос работы FEBAN, какой смысл тогда Неизвестной операции? С известными понятно, там алгоритмы, по неизвестной должен выполняться просто поиск руками...

Но могу ошибаться.

?? Если проводки рождаются только на основе FEBAN, зачем нужен ТАП? Единственное известное мне (согласующееся со здравым смыслом) применение ТАПа - это оплата через АПП, и в таком случае в FEBAN генерится только первая область, вторая подтягивается поиском по алгоритму на основании проводки. которую сгенерировала АПП. Или у Вас какой-то другой сценарий?

Мы точно про одно говорим? Я говорю про ТАП дебитору. На проекте он используется как счёт на оплату.

По оффтопу, а если апп без проводок, почему бы не генерить платежки через ТАП кредитору? =)

Верно все, очень многие используют ТАП дебитору для последующей печати счета на предоплату и отправки его клиенту. Потом каждый кочевряжится как может. Кто-то, например, вторую область делает через технический 62 (будет Дт 51т Кт 62т/76т), а уже потом спец по участку его разносит, при этом подтаскивает ТАП дебиторский в FB05, в результате чего ТАП выравнивается, закрывается Т-счет и делается проводка по кредиту нормального 62/76. Лично для меня тот факт, что дебиторский ТАП можно подтянуть в FB05 для последующего выравнивания, - это весомый аргумент в пользу того, что памятная позиция - это вообще-то не такой уж бесхозный сапа кусок. Потому я тут с -TT- не очень согласен. Нормальная эта позиция, да памятная, но выравнивается и подтягивается в выравнивание, как и все остальные. В том числе и по номеру документа.

Я думаю, что тут главная загвоздка в том, что когда FEBAN запускает проводку с выравниванием, он рубится на коде ОГК F. Например, у нас номер ТАПа в авизо был, но на экране (номер не помню, там еще указывается AGKON и т.д.) критериев поиска ОП зарубалось. Такое ощущение, что сап не умеет туда ставить код F. Да и как ему это уметь? Если в правиле проводки второй области стоит "выравнивание лицевого счета", то код ОГК там не предусмотрен. Вот и все. А указывать можно только в проводке по лицевому счету, но без выравнивания.

JohnnyBGood, попробуй начать проводку, а потом, когда система остановится и будет ругаться на номер документа, убедись, что не указан код F в ограничениях. При выравнивании ТАПа ведь указывать нужно именно код позиции, а не целевой и не что-то еще. А там он именно F. Пробей F и попробуй завершить операцию в видимом режиме. Уверен, позиция найдется. Дальше останется понять, как засунуть туда UMSKZ.

А еще такой вопроос. Контрагент точно нормальный в проводку уходит? Может, он даже и контрагента не видит? Если с контрагентом все ок, то ставлю на код ОГК.

Привет!
Внедряю эту гадость в который раз, новые ноты сделали его уже чуть более юзабельным. Обязательно нужно поставить все с тегом FEB_BSPROC или обновиться на последний Support Package.

При условии что система обновлена:

ТАП может не находиться в новом фебане на вкладке присвоение в двух случаях:
1) Он выравнен
2) На нем стоит метка о созданном платежном поручении. В этом случае он в новый фебан может быть подтянут только интерпретационным алгоритмом.

Поиск на вкладке "присвоение" делать так:
1) БЕ обязательно
2) Код ОГК - указать общий код ОГК памятных позиций, не целевой.
3) Контрагент

Этого достаточно, будет находить. Но если АПП используете, то вручную найти нельзя будет, только нормально использовать 29й алгоритм.

Платеж-то какой? Входящий или исходящий? Если входящий, должно находить нормально, ноты поставьте только и правильно ищите.

Yozhhhhh, благодарю за детальные рассуждения, почитал, подумал.
Ситуация оказалась банальна, в доп. импорте позиций необходимо вывести поле "Код ОГК".
Если внести туда F, то все ок... "выравнивание лицевого счета" - в целом, так видимо и есть, рубиться на коде F, которого нет.



Если так не делать, то система выводит все, что без кода ОГК.

Собственно, Azzie так и сказал в п.2 (у нас SP последний)


Да, вот эту тему я и указал в начале. Ошибся, не 28ой, а 29ый.
Правда, через стандартную операцию делал, но к ней он и привязан.

Ну и славно)

Azzie верно раписал схему с исходящими платежами, но к входящим все это неприменимо. 29 алгоритм в случае с входящими платежами беспомощен. В случае с исходящими он берет документ из REGUH/REGUP за счет того, что ТАП прогонялся через F110. Вы же не гоняете дебиторские тапики через программу платежей. Так что только номер документа и онли он.

Не совсем, алгоритм не лезет в REGUP/REGUH, он берет запись из PYORDP где есть связка между номером платежки и фин. документом, и создает запись в FEBCL. Так, например, когда в FEB_BSPROC и FEBAN сделать проводку, запись в PYORDP пропадет, и если есть нужда сторнировать и перепровести эту проводку, позицию ТАП уже нужно будет искать через кнопку "Дополнить Импорт Позиций". Ну или подработать немного прогу, чтобы возращать запись в PYORDP при сторно.

А по входящим платежам да, идет поиск по открытым позициям, разделяя их на ОГКшные и нет через селекцию.

Вот, поэтому и отрабатывает в операции...