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

Если выяснится что вопрос не совсем в ту ветку, то попрошу модеров перенести.

Если делать с прицелом на FM, то можно на документах выделения средств.
Я планирую сделать генерацию документа выделения средств, с позициями на каждый срок платежа, на основании условий договора (DMS) и ММ-контракта (спецификация, где есть суммы по бюджетным адресам). ТАП создается со ссылкой на ДВС.
Такую схему можно использовать и при отсутствии FM и платежных бюджетов.
Знаю, что графики платежей делают прямо в DMS и без DMS, на ДВС.

В целом понятно.
А почему сразу не сделать ТАП?

Как пользователь увидит общую сумму по договору и частичные платежи? Не будет "единого места правды".
Конечно можно и на ТАП, с Z-отчетом...

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

больше встречал решение на ДВС, на основании которых формируется ТАП.

Plank, не возникало идеи формировать прогноз по выплате (план расчетов) на основании цепочки MM без ДВС? по сути ДВС являются аналогами документов заявка MM, заказу на поставку? Какие могут быть подводные камни, кроме НДС конечно?

Налоги, кредиты, займы, депозиты, ценные бумаги, благотворительность, ... - все через технические ММ заказы? Конечно можно, но как-то некрасиво.
Кроме того ММ заказ превращается в прообраз договора, а Логистам нужен более гибкий механизм для заказов, один заказ не должен равняться спецификации на полную сумму договора, а если делать несколько заказов, то опять теряется картина мироздания для казначея.
В общем, для каждого потребителя информации в системе свой инструмент...

да, согласен с прочими платежами, где регистрация задолженности идет через FI. в этом смысле единый документ ДВС для казначея будет лучшим вариантом.

но у решения ТАП через ДВС есть и свои минусы:
1. Каким образом организовать потребление предшевствующих документов? полностью оторвать цепочку ДВС->ТАП от цепочки MM-FI? тогда прийдем к варианту отдаленному от стандарта. при этом у многих предпрятий в РФ наблюдается тенденция к контролю БО. при оторванной цепочке ДВС->ТАП от MM->FI можем получить несоответствие статьи ДДС в СФ и платеже, никакое обновление в данном случае не поможет.
Если генерить ДВС на основании документов MM, кто будет потреблять ДВС? если документы MM, ок., тогда какого предшевственника будет потреблять ТАП?

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

3. использование механизма "пассивного" сплитинга для VOBELNR и KNBELNR для сопоставления СФ и платежа, будет работать для авансов немного по-другому. для VOBELNR будем получать не конкретный платеж, а документ выравнивания, что неудобно.

Не нужно разрывать цепочку. На один и тот же ДВС можно делать ссылку как в ТАПе, так и в документах MM и FI. FM позволяет одновременно ссылаться на ДВС и в авансе, и счете-фактуре без всяких проблем.

При реализации через ДВС можно использовать и ТП.

1. позиция ДВС не может потребляться дважды как и любой предшественник. Если позиция ДВС на 1000 у.е. и ее потребила позиция заказа MM на 1000 у.е., открытая сумма будет = 0. ТАП уже создать нельзя будет. Если только разрешать превышение суммы по ДВС, как контролировать тогда созданные ТАП, а обновление FM?

2. можно. но лучше оплачивать СФ, если в ТП нет необходимости.

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

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

А вы пробовали =)?
У меня все прекрасно потребляется: и ТАП и счет-фактура ссылаются на ДВС без всякого разрешенного превышения. На прошлом проекте ссылались одновременно на ТАП и на Заказ на поставку.

Да вы правы. действительно этот так. Спасибо. вопрос снимается. контроль идет в разрезе орг-экономической операции RMBE - заказ, AZAF - тап, RFBU - СФ. То есть по каждой орг-операции не может быть превышения...

TO: Alex2000
1. Вы ушли от темы, начиналась она с графика платежей, а вы уже про БО.
2. ABAP автоматического зачета авансов (последствий обработки ТАП) и с-ф, которые указали при создании ТАП, занимает два дня (теперь один, так как кое чему научился ). Так что все оплачиваемые фактуры, выравниваются автоматически при разноске БВ.
3. Не знаю, почему неудобно?

1. График платежей не может сам по себе существовать. Как минимум при принятии решении об инструментах его реализации необходимо думать об АПП, как максимум и о БО и о БП и об обновлении платежей. наверно поэтому ушел.
2. может быть вы и правы трудоемкость действительно невелика, если есть связка. и возможно это более простой путь, нежели контролировать оплату по факту или аванс на стадии создания платежного поручения, если еще и платежи по факту будут без авансового кода ОГК, то и п.3 решится сам собой.
3. "пассивный" сплитинг на KNOBELNR и VOBELNR позволяет решить извечную проблему сопоставления СФ и платежей (хотя и стандартные J отчеты уже появились давно). Если идет оплата по факту то СФ (KNOBELNR) сопоставляются однозначно какждый платеж (VOBELNR). для выравнивания СФ с авансом сопоставляется документ перерасчетам аванса, при платеже через ТАП мы технически каждый платеж делаем авансовым, и в VOBELNR будем получать не платеж и не перерасчет аванса, а документ выравнивания платежа с СФ, что потребует дополнительного ABAPа чтобы развернуть док. выравнивания до платежа.

Пример из попытки реализации.
Есть цепочка договор-заказ-ТАП-выписка(платеж). Для реализации графика платежей решил использовать ДВС. Но, если говорить о том, что заказ и ТАП могут ссылаться на РС, то сразу же столкнулся вот с какой проблемой . Если у меня договор и заказ (позиции в обоих документах одинаковы) состоят из 20 позиций, график платежей (он же РС) состоит из 3 позиций (30%-50%-20%), то как мне оформить контировки на РС в заказе и перекрыть 20-ть позиций 3-мя позициями РС (ровно по суммам они не бьются). Либо разрывать поток ММ-FI и делать это как то иначе?

Мне кажется тему неплохо было бы перенести это обсуждение в подфорум FI-FM.

По существу вопроса: сейчас тоже будем решать подобную задачу (вылезла сразу на 2-х проектах) - но у нас РС будет реализовывать график выполнения работ и услуг (или правильно назвать график обязательств). Думаю что в заказе каждая из 20-ти позиций должна иметь свою ФП, которую если получится, то определять во время создания позиции заказа деривацией из бухгалтерских/экономических/логистических аналитик, затем сравнивать с ФП указанной в позиции РС, которая проставляется в позицию заказа, если ФП не будут совпадать, то выдавать пользователю ошибку что он пытается провести расход на ФП не соответствующий ФП указаной в РС. Если же деривацией не определится ФП, то только тогда копировать ее из позиции РС при ее указании в позиции заказа. В таком случае, пользователь будет понимать как ему распределять на 20-ть позиций заказа 3 позиции РС.
Поговорю с разработчиком, если технически реализуемо, то сделаем Z-ку в которой будут, с левой стороны отражаться позиции РС со своими ФП, с правой стороны позиции заказа с ФП, определенными деривацией, и Z-ка будет по FIFO осуществлять массовое присвоение позиций РС в позиции заказа при равенстве ФП или когда в позиции заказа не будет стоять ФП. Понятное дело в Z-ке предусмотрим, для удобства просмотра и проверки до начала массового присвоения, группировку с удобным упорядочиванием (на первый взгляд: по бюджетному периоду (квартал или месяц), по ФП) и проставлением галок что присваивать, а что не присваивать.