Как выглядит этот номер?

обычный порядковый номер

Payment order № 1
и т.д.
ничего особенного...

и каждый день у вас счетчик начинает с 1, да? Точнее сказать - каждый прогон начинается с 1? Точнее даже сказать - каждый прогон у вас начинает нумерацию с той цифирки, которую Вы поставите после последнего тире в запросе печати ОНД?

нет, почему каждый прогон должен начинаться с единицы?
мне не понятна связь запроса печати ОНД и нумерации платежных поручений.
Объект FI_PYORD буферизован. Каждый прогон начинается с последнего номера из буфера памяти.
разве не так стандарт работает?

и сколько живет этот буфер?

Связь прямая - в стандарте при вызове программы генерации ОНД, если не стоит никаких ФМников в 05 и 06 моментах в ракурсе V_TFPM042FB, у вас номера платежек будут равны номерам выгружаемых строк проводок в носителе, и начинаться эта нумерация будет с цифирки после тире при вызове программы печати ОНД. Поставите 1 - будет идти начиная с 1, поставите 99 - первая выгруженная строка будет иметь номер 99. Во всяком случае - у меня это так работает, вмешательства в алгоритм присвоения номеров, кроме моих собственных экзерсисов в моменте 05, не обнаружено. Или мы говорим о разных алгоритмах присвоения PYORD разным получателям.

сколько живет буфер могу сказать только на собственном опыте - пока не исчерпается очередная порция считанных в буфер номеров.
Но в хелпе написано. что если у объекта FI_Pyord включена буферизация, то возможны недокументированные пропуски. И они действительно осуществуют. Но вот в какой момент они возникают мне до конца не понятно.
Под программой генерации ОНД понимается программа SAPFPAYM? Номер платежного поручения я беру из FPAYH-DOC1R.
И текстовый файл у меня формируется корректно, разве что номера платежек с ведущими нулями, но это меня устраивает.

Для печати платежных поручений я использую z-разработку (т.к. нет стандартного формуляра)
а Вы из какого поля берете номер платежного поручения для ОНД?

Длина поля DOC1R - 24 символа, реально заполнены из них 20-22, в зависимости от реализации. Это поле содержит в себе полный индекс БЕ+номер документа+номер позиции в предложении (номер строки в REGUH по ключу БЕ-Дата-Номер прогона)+еще что-то. Номер документа может существовать в трех инстанциях - реальный номер продуктивного прогона из объекта RF_BELEG, служебный номер вид F* для позиций, сохраненных в предложении по платежам, служебный номер вида О* - для позиций, сохраненных в предложении по платежам, если по ним было изменений реквизитов. Каким из этих номеров Вы пользуетесь? В какой момент у вас генерится медиум (ОНД)?

Я использую алгоритм интерпретации номера из RF_BELEG, мой номер платежки - это последние 5 цифр соответствующего номера БУ документа проводки платежа. Именно это величину я и закладываю в PYORD.

Добрый день,

Вы как-то очень сложно идете, просто добавьте замещением или OpenFI событием запись номера платежки в одно из полей финансового документа выписки, например, текст заголовка. Типично на проектах вижу это так реализованным.

Взять из FEBEP-CHECT номер можно. В АПП лезть не надо, там иная логика. АПП должна платить и делать платежки, в том числе повторно, если в первый раз что-то обломалось, а не хранить информацию для отображения в отчетности. Брать надо из таблиц выписки.

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

Этот номер надо сперва сгенерировать. Причем так, чтобы он не дублировался внутри года. Так, чтобы его прочитал медиум и поставил в форму пп. Так, чтобы этот же номера зафиксировался в бух.документе. И (как вишенка на торте) - так, чтобы программы книги покупок и продаж могли его прочитать, желательно стандартно

И насчет "Что там в итоге банк сделает с номерами фактически отработанных платежек" - дада, причем в выписке Вашего контрагента, с которым (сюрприз-сюрприз) по книгам покупок-продаж будет проведена сверка.

Тут есть вопросы? Это счетчик FI_PYORD, имеет смысл разделять по БЕ если платит более одной и по году. Дублироваться не дублируется.


А почему он должен не прочитать? DME функциональный модуль с альфа-преобразованием можно в дерево вставить, это если есть проблемы.


Если мы грузим стандартные форматы SAP (Multicash и иже с ними) SAP забьет этот номер в нужное поле. Далее это значение можно положить в CHAR поле фин. документа используя один из всем известных способов.


Откуда они читать то его будут? Стандарт САП не предполагает запись в документы фактур этого номера. Ручками-с. Или постобработкой своей.


Номера платежек и в Вашей выписке и в выписке контрагента одинаковые.

В общем, не понял. Где затык то?

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

И это означает, что в книгах должны быть расставлены номера платежек именно те. которыми оплачивались релевантные обороты. Теги: #налоговый #агент #уплатандсвбюджет, дальше думаю сами все поймете.

Это вопрос опыта, в первый раз сложно. Любой BLщик нормальный все это на автомате делать может, отвлекаясь только на особенности данного конкретного заказчика. Когда пару раз все косяки соберешь, уже дальше проще. Хотя те, кто нормально помучился с платежами и позапускал их, обычно хочет расширять экспертизу