Barsik написал:
1 - разделение задолженности между бюджетными периодами: к примеру, факт фактуры в платежном бюджете обновляется на основании поля "дата к оплате" и в условии платежа указали, что необходимо разбить платеж на 3 части (по 1/3 в конце каждого месяца). При этом реальные контировки (в т.ч. бюджетный период) у нас указываются в счетах затрат, а не в счетах задолженности. Вроде как по документу ясно, что нужно раскинуть суммы по трем периодам, но все-равно суммы списываются на один период. Есть ли какой-нибудь инструмент по аналогии сплиттинга, который бы раскидывал суммы по разным периодам или нет?
Насколько я знаю система не работает с условием платежа в части разбиения по частям, т.е. и не пытается проанализировать оплату по частям, - есть базовая дата и условие платежа, от них определяется
одна дата к оплате, эта дата и будет датой обновления в УБ для всей фактуры. Так что если хочется раскидывать, то это точно не к разбиениям оплаты в условиях платежа.
В свое время слышал от коллег по системе Oracle E-Bussines Suite что у них к фактуре можно выстроить график оплат, если бы подобное было бы реализовано в SAP в стандарте, то думаю от таких позиций графика оплат можно было бы SAP-у и раскидать ожидаемую оплату фактуры на 3 периода, а сейчас очень многие и придумывают схему с построением графика платежей и заявок на платеж на ДВС, чтобы реализовать все то что нельзя реализовать на обновлении в ПлБ фактур.
Barsik написал:
2 - автоперенос на новый период: в фактуре указали, что планируем оплатить в сентябре, а в реальности оплатили в ноябре. Как сделать так, чтобы система пересчитала на новый период? Или же ручные корректировки нужно выполнить?
Фактура обновляется до выравнивания платежом с 54 Типом значения (ТЗ) вид суммы 100 - оригинал, при выравнивании платежом 54 ТЗ уменьшается на выравниваемую сумму с видом суммы 200 - сокращено, и потребляется с ТЗ 57, вид суммы - 250 оплачено. Бюджетный период определяется от даты обновления в УБ, и на 54 и на 57 ТЗ правильней если в профиле обновления или настройках перезаписи профиля обновления эта дата стоит как даты оплаты. В результате система автоматом при выравнивании платежом пересчитывает как нужно БП на дату оплаты - возьмет пересчитанный с 57 ТЗ.