Все что сказано применимо к новому FEBAN ноября прошлого года.
29й алгоритм корректно с новым фебаном на тот момент не работал.
Основное требование при внедрении нового ФЕБАНА - свободные 100+ часов работы АБАПера.
Ибо кривое косое нечто. Я даже не понимаю как оно должно работать по мнению SAP, у нас на контроле качества они обтекали, когда мы рассказывали все его ошибки. На вопрос почему ж вы не обращались - ответили, обращались, вы признали проблему, ничего не сделали. С ноября прошлого года перестали проверять ноты и принялись ломать его.
Очень плохо работает с тапами и тп, стандартный инструмент присвоения который там есть похоже не приспособлен для их присвоения, без интерпретационного алгоритма. Если по интерпретационному алгоритму подтянулся ТАП, какие либо действия по его изменению и вы его обратно присвоить не сможете, надо будет перезаходить в транзакцию. Работа с динамическими таблицами там ужасная, и лечить про это индусам по техподдержке не получается.
Исходя из этого в подломе есть особенности - механизм присвоения документов для выравнивания там опирается на табличку FEBEP и для корректной работы надо будет пихать в FEBEP много всего на этапе загрузки выписки. Там есть вкладка операции, при смене операции прога проходит через FEB_BADI, в этот момент можно встроить свои алгоритмы.
В принципе внедрили на настоящий момент - довольно удобный инструмент, интерфейс гибкий и позволяет обрабатывать входящие платежи удобнее FB05 старого фебана. Позволяет легко подхватывать позиции для присвоения. Если платите по кредиторке - инструмент тоже подходящий.
Для чего он не подходит - для массовой обработки. Массовой обработки там нет, только попозиционная. У нас на проекте есть процесс с массовой обработкой выписки, в итоге 2 фебана работают. Постоянными параметрами можно регулировать какая транзакция вылезет по коду FEBAN. Можно на FEBAN подвесить старую, а на FEB_BSPROC новую.
Я не знаю что в нотах по нему за последние полгода год, но когда мы начинали это была транзакция из серии "доработать напильником"
|
|