До ТАПа у нас договор, который отъедет Бюджет обязательств через ДВС (Резервирование).
А ТАП это уже второй документ в цепочке, который, должен отражаться в Бюджете платежей и
контролироваться на непревышение лимита по платежам
и непревышение обязательств по договору (обеспечивается ссылкой на ДВС).

На основе ТАП, как раз, предполагалась печать заявки на платеж по договору с видом "Аванс".
Поэтому, на мой взгляд, и было бы логично так же регистрировать ПТ и на основании его печать заявку на платеж с видом "Постоплата".
Поэту если делать заявки на оплату через ДВС, то нужно туда заводить Аванс,
и делать модификацию ДВС для заявок на платеж по счету – добавлять туда поле ссылку на счет.
Как-то это все криво и геморно.

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


конечно, для нас всех было бы удобнее, если бы при создании ТП автоматически генерились бы некие позиции в регистре УБ, но исходим из того что есть.



не совсем поняла причем тут тогда аванс? и какая модификация ДВС имеется ввиду?

Вот смотрите, у нас есть "Заявка на платеж", документ, который готовиться для утверждения выплаты:
а) Аванса на основании условий договора
б) оплаты по принятому к учету вх.счету

Если делать постоплату через ДВС, то
1. Нужно как-то в ДВС делать ссылку на вх.счет (при этом, используется цепочка : договор-заказ-счет, которые отражаются в бюджете обязательств )
2. По ДВС-постоплаты все равно нужно делать ТП, чтобы заявка попала в АПП
Для единообразия лучше тогда и ТАП делать через ДВС (например Ассигнование к Резервированию).
Иначе получиться что один и тот же документ (Заявка на платеж) в одном случае регистрируется пользователем как ТАП (памятная позиция), в другом как ДВС и по нему все равно формируется ПТ (платежное требование). В общем, как-то все это не стройно, куча системных документов . Или накрывать этот ABAP-интерфейсом, который генерировал бы все эти проводки. И все равно будет некрасиво.

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

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


да, это так

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



Вот и странно, что такой документ (по сути, то же облиго) никак не отражается в УБ.

значит выбирайте самый наименее затратный по ресурсам вариант. Создание ДВС для ТП без всяких наворотов. Вам ДВС нужны только для контроля, отчетность на них строить не будете



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


ну это не единственная странность в сапе )) так что надо исходить из того что имеем и придумывать свои компромиссные решения - это наша работа )) как говорится "САП - все очень просто"

Вот такая еще пришла мысль:
Можно ли ТП смоделировать через документ FM- "требование выплаты" (тр. F871)?
По смыслу вроде подходит.
Можно ли по нему автоматически создать документ ТП?

я когда-то разбиралась с требованием выплаты в FM, там была пара ограничивающих моментов, я сейчас точно не помню что именно, я вечером постараюсь посмотреть.

Спасибо Delicia
Буду Вам очень признателен.

вообщем относительно генерации ТП через реквесты FM может возникнуть следующая проблема:
FM-кие требования в процессе всех редактирований и акцептований транслируются на временно сохраняемый/park doc FI док, и уже после всех согласований, например через стандартный специально предусмотренный для этого очень неплохой WorkFlow, временно сохраненный док FI проводится как реальная проводка.
Т.е. идея функционала такая, что в ряде случаев удобнее согласовывать и обсуждать освоение бюджета в разрезе FM-ких контировок еще на стадии, когда счета ГК могут быть неизвестны и не актуальны для принятия решения. По мере необходимости и приближения платежа, в FM-кий реквест добавляются необходимые данные по FI - после того как все всё согласовали - вуаля - FI док
А ТП в FI - это памятная позиция, она не может быть временно сохраненной. Т.е. конкретно для этой цели врядли FM реквесты будут тем что нужно.

Да, но если сделать при сохранении требования FM сразу формирования FI-документа (без предварительных сохранений), то можно сослаться на код ОГК с памятной позицией.
Это можно сделать - есть настройка, и я этого добился.
но у меня не получается добиться документа с одной памятной позиций - формируется реальный документ FI с двумя дополнительными памятными позициями по ОГК.

Эка невидаль

ДВС не подходят еще и потому что они все отражаются только в бюджете обязательств, а нам нужен бюджет платежей.

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

И вообще, какое назначение документа "Платежная инструкция" в УБ?

кто Вам такое сказал? )) ДВС будут отражаться там, где это необходимо, в зависимости от настроек

я сужу по транзакции перезаписи профиля обновления
там настройки только по бюджету обязательств

какой профиль смотрите?