Доброго всем дня! Есть небольшой вопрос, может кто делал такое! !!!Оплата ведется в разрезе документов расчетов!!! задача состоит вот в чем - есть определенные условия отсрочки по договору, и планирование поступления денег связанные с этими условиями отсрочки! Но планирование может быть просрочено, тогда вводится дополнительный документ, который переносит даты поступления денежных средств! так же есть оплаты, которые соответственно тоже должны вносить изменения в эти планируемые поступления, если дата оплаты раньше, то тогда план пост должно сместиться на дату прихода денег, если позже то тогда остаться на месте! также оплата может быть отменена, тогда план пост, должно вернуться обратно, на дату планирования! еще одно условие, что планирование поступления денег по одной отгрузке может быть разбито на несколько дат! КАК ЭТО РЕАЛИЗОВАТЬ В УТ 10.3????? Если в какой - нибудь типовой конфигурации такое реализовано, то хотя бы намекните!!

в УТ 11 есть графики оплат и в соответствии с ними заполняются этапы оплат в доках

+(1) помогло?

(2) ну я думаю что это немного не то...

(0) Делали что-то очень похожее на сие для УПП. В УПП ни тогда ни сейчас ничего даже рядом стоящего не было. Думаю и в УТ - нет.

(0) Документооборот Корп последние релизы смотри, Рус, Укр - без разницы

(4) То есть наше дело труба?) и собственно получилось!?
(5) Спасибо посмотрю!

(6) Не видел реально работающего процесса еще ни в одной конторе :)

(7) Не хочу хвастать, но у нас - работает ))

(7) я уже себе всю голову сломал на эту тему, вот неужели 1С об этом как - то не подумало?? забыло про планирование оплат
(8) принцип реализации то какой - хоть поделитесь!??

(8) адрес, состав семьи, графики движения, места отдыха в студию )

(9) в каждой массивной конфе есть попытки реализации плана оплат, но согласно политике типовый "мы даем вам инструмент для расширения возможностей, а не панацею на все случаи жизни" - это попытки в зародыше, но ведь это типовые и политика в этом контексте верна, правда)

(9) для каждого договора - документ устанавливающий этапы взаиморасчетов. Сроки этапов могут быть абсолютные, могут - от полного выполнения предыдущего этапа/этапов (с нюансами). Каждый платеж или реализация - вносит корректировки.
Это вкратце ))
А детально - этож целая статья получится ))

(12) не, к договору не пойдет, надо к документу (

(13) Т.е. в рамках одного договора, могут существовать разные графики исполнения??

(12) к каждой отдельно реализации!

(14) ну вообщем - то да

(13) ну в УТ аж с 2003 года документы ЗаявкаНаРасходованиеДенежныхСредств и ПланированиеПоступленияДенежныхСредств. Было в УТ 10.1, УТ.10.2, УТ 10.3.

(14) тут фишка в том, что это должно работать только для просроченных относительно договорных отношений реализаций

(17) они очень коряво работают... вот ППДС то точно!

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

У нас ППДСы создавались при проведении Реализации по нужным этапам оплаты.
Но гемор главный был потом, когда манагеры задолженность закрывали, а ППДС - нет.

(20) хотябы краткое описание ваше супермега блока, до которого УПП далеко, а в УТ 11 даже не планировалось

>> если дата оплаты раньше, то тогда план пост должно сместиться на дату прихода денег
т.е. считаем только плохие показатели, а хорошие нет? Когда вас спросят, а каков процент погашения долга до граничного срока?

Делали, внедрили, работает. Очень четко. С графиками, с переносами отсрочек, частичными оплатами и т.д.
Я надеюсь, что автору от этого полегчало?

(24) автору не полегчало))))

+(24) Запрограммировать - пол дела. Если не треть. А вот внедрить, чтобы все это скрупулезно вели обычно большая проблема. Мы этого добились с очень большим трудом, все-таки 30 менеджеров-баб это вам не фунт изюму.

(22) Я конечно понимаю, что вопрос содержит некую издевку, но тем не менее: ))
Есть договор, по которому клиент может платить в несколько этапов, а мы отгружать - тоже в несколько этапов.
Наступления каждого этапа может происходить как в момент полного выполнения предыдущих (например обещали оплатить 50% от суммы счета в два этапа 10% и 40%), так и абсолютно (отгружаем 12 марта, а если до этого не доплатили как должны были - то это сразу просроченная дебиторка). Этапы могут идти в произвольном порядке: отгрузка 10% - оплата 15% - оплата 45% - отгрузка 30% - оплата 40% - отгрузка 30% - отгрузка 40%. + учет возвратов, переносов оплат и т.п. + исполнение договора вперед, либо клиент платит раньше выполнения нами условий, либо отгружаем раньше выполнения клиентом условий (в этом самая жесть была, что считать дебиторкской/кредиторской задолженностью и как считать просрочку). Итоговый отчет по задолженности должен сходится с анализом 62 счета, тоже не тривиальная весчь. Ибо если отгрузили на 100 рублей, по договору клиент должен оплатить 300, чтобы ему еще на 200 отгрузили. После отгрузки задолженность в 300 по клиенту вроде есть, а на 62 счете - только 100.

(27) извини конечно, но какая-то каша + поверхностное знание БП

(28) Не извиню ))
Это не каша - это жизнь. Нормальная(работающая) реализация этапов взаиморасчетов. Объяснить в двух словах - возможно да, не совсем понятно. Но тому, кто сталкивался - смысл выделить возможно.
И что такое в данном контексте БП?

(29) Бухгалтерия Предприятия

(30)А она то тут причем?? Я честна ее вообще в глаза не видал ))

(31) а 62 счет откуда?

из УПП

(33) а в УПП не ведется бухгалтерия предприятия?

(27)не пойму зачем на 62 так все подробно видеть? взаиморасчтеы это больше упр. учет а бухгалтерия это его отражение так как нужно для отчетности.

В УТ 11 есть возможность отслеживать взаиморасчеты по этапам оплат.

(34) в упп ведется бухгалтерский учет, а не БП.
(35) на 62 счете и нет этих подробностей. В данном случае, нужно было сделать, чтобы "виртуальная" задолженность по договору, не входила в противоречие с задолженностью по данным бух.учета.

"В УТ 11 есть возможность отслеживать взаиморасчеты по этапам оплат." - что-то мне подсказывает, что это все равно обладает ограниченной функциональностью, но не поручусь, ибо не видел, строго имхо.
Возможно ТС - этого будет достаточно.

Есть решение: на основании даты счета (заказа) и личной отсрочки контрагента + 3 дня на раздумье. Потом отчет - есть заказ, есть отгрузка, + 3 дня на раскачку + отсрочка по договору = искомая дата.
Если искомая дата < текущая, то просрочена, если (искомая дата + 5 дней) < текущая, то в СБ.

(37) + надо будет только в корректировку заказа добавить возможность изменения даты оплаты в заказе, для истории.

(27) не договор, а конкретная отгрузка
(37) я говорю про перенос планируемых поступлений ДС, которое идет от реализации, а не от заказа...

закладка

(0) у Бита есть решение. Продам. стоит 350 тысяч рублей.

(4)Это почему же в УПП нет?
А актуализация бюджетирования с переносом транзакций?

(41) о_О, чуть со стула не упал, ну и как называется эта конфа!?

+(43) плюс еще задача состоит в том, что сам документ ППДС менеджеры даже не видят и заполняется он автоматически!

^

АП

^

У нас на базе УПП реализован учет условий оплаты отгрузок в договоре, возможно указывать несколько этапов с доп условиями. На данный момент занимаюсь реализацией похожей задачи, хочу завязать вся на документы "Заявка на расходование ДС" и "ППДС". Самый сложный момент на мой взгляд - это актуализация документов планирования (в отгрузке поменяли дату или сумму, пошла просрочка оплаты и т.д.). Что делать с незакрытым частично ППДС, как это максимально автоматизировать!? До этого я решал данную задачу в БП 1.6, там я делал всё через свой довольно сложный отчет - Платёжный календарь, рассчитывая фактические данные остатков взаиморасчетов, заявок на расходование и условий договоров, была довольно сложная увязка между договорами (генподрядная деятельность). Сейчас так не хочу реализовывать, но актуализация напрягает...

(5) Что я не ничего про условия оплаты не видел в Документооброте КОРП 1.2.2.6, хотя мне это очень нужно... Может поподробнее объясните?

(43) это надстройка.
Загуглить лень чтоли? Человек и так все уже рассказал.

делал такое в ут 10.3, платежный календпрь называется.

(48) вот в этом самая большая проблема - незакрытые частично, перенесенные и так далее...
(51) удачно!?