База УТ.
При реализации товаров услуг, мы заносим в воображаемый регистр Информацию:
Контрагент, Договор, Сумма
При поступления денег от клиентов, сумма закрывается.

Но как бы организовать отслеживание просрочек долга по дате, если мы на момент отгрузки, мы можем определить дату поступления денег исходя из даты отгрузки и допустимого числа дней отсрочки, указанной в договоре. Но вот хочется продумать куда эту дату воткнуть, чтобы в отчетах не просчитывать каждый раз разность дат для выявления просрочки. Чтобы в регистр всё сохранялось, а потом уже запросом из регистра можно было вытащить просрочки.

велосипед изобретаем?

(1)ну нет у нас этого. чтоб с учетом производственного календаря считалось.

(2)не понял,а сейчас считается бз учета выходных и праздничных дней?

кури систему взаиморасчетов по док-ам расчетов

(0) Ищи "Платежный календарь"

(4) абалденный совет ...

эм...
а что, в ут такого нет?

справочник.ДоговорыКонтрагентов: http://screencast.com/t/1WUEwk1Bgy

(3)отчет криво написан. там вообще берут дату и умножают на коэффециент...
(3)ну я то считаю но я не хочу это рассчитывать внутри отчета
(5)вижу. мне бы хотелось просто при проведении документа заполнять регистр какой-нибудь и потом простую выборку отчетом доставать оттуда данные. а как спроектировать пока не придумал.

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

похоже два регистра надо завести. оборотных. а потом выборку делать показывая разницу дат.

(6) чем не устраивает?

(0) Регистр взаиморасчёты, ресурсы "Сумма задолженности", "Сумма по срокам".
Реализация делает 2 записи. В ресурс "Сумма задолженности" датой отгрузки, в ресурс "Сумма по срокам" датой оплаты. Документы оплаты при зачёте задолженности пишут в оба ресурса. Теперь отчёт по остаткам ресурса "Сумма по срокам" всегда показывает просрочку, по остаткам "Сумма задолженности" - общий долг.

+(12) (с) УТ 11

(8) я же тебе сказал - посмотри как делается платежный календарь - именно регистр.
(11) Пробовал сам вести по документам расчетов? Я таких не встречал - это у буха семь пядей во лбу должно быть.

(14) 3 года ведем

Измерения:
Организация
Контрагент
ДоговорКонтрагента
Документ
ДатаОбязательств

Ресурсы:
Сумма

(15) Значит бухи у вас и правда с мозгами (молодцы).

(17) Смысл держать тупых бухов? Кстати, ввод учета по док-ам расчетов - была их инициатива. Все подводные камни и трудности их не испугали. И нормально ведут, не без допила, конечно.

(0) Вообще-то все украдено до нас. Раз речь про просроченные платежи, то значит речь про ведение расчетов в разрезе по документам. В которых можно хранить дату, до которой нужно оплатить.

(16)получается у них один только регистр? а я хотел два регистра делать и сравнивать их остаточные суммы и отбор по датам делать в запросе, просто в одном регистре будет "ДатаОбязательств", а в другом "ДатаФактическойОплаты"

Продам за 3000 рублей.

(18) >>Смысл держать тупых бухов?
Хороший конечно вопрос :)

>>Кстати, ввод учета по док-ам расчетов - была их инициатива.
Я же говорю - повезло с бухами.

(20) разумеется один.

(20) Зачем два регистра одинаковой структуры? Почему не сделать один регистр с двумя ресурсами как я описываю в (12)?

(12) Плохой вариант. Не посчитаешь, на сколько дней просрочено.

(25) Никто не запрещает на общих основаниях вести в регистре измерение "ДокументЗадолженности".

(26) А нахрена тогда вторая сумма?

(27) Остатки по этой сумме - суть просроченная задолженность на нужную дату без каких-либо расчётов.

(28) Это и так крайне тупо считается как остатки на дату с фильтром по дате оплаты документа расчетов. Нахрена огород городить?

(24)а потому что Даты в регистре имеют разный смысл. одна дата - дата факт. а другая дата - дата предполагаемая.

(29) Представь, в документе расчётов нет даты оплаты... Она расчитывается в момент проведения и не пишется как реквизит в документ. Опять таки, при изменении условий договора - достаточно перепровести документы. Документ расчётов не один, а много, разной структуры. В т.ч. какая-нибудь корректировка задолженности. Получение даты оплаты из измерения - приводит к офигенскому росту количества использованных таблиц в запросе. На существенных объёмах (скажем по 1000 документов расчётов в день по одному договору) всё это может не по детски тормозить..
А кроме того, если ты захочешь получить отчёт не на дату, а по периодам задолженности, поимеешь кучу проблем, которых нет в моём варианте.

+(31) ну а кроме того, может быть такая штука как разные условия оплаты по разным товарным группам по одному договору. За молоко надо платить через 7 дней, а за консервы через 30. В результате по одной накладной - разные сроки оплаты. Дробить накладные - нифига не красиво.

Короче, мне эта методика в УТ 11 понравилась..

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

(32) Что за чушь? Ты при оплате накладной указываешь, что это за молоко, а не за консервы? Как?

(30) Не слушаешь, что тебе говорят :) уже давно бы нашел пример реализации.Сделай регистр как в (16) и не парься...

(34) Ты упёрся? Ты изучил УПП 10 летней давности и считаешь, что это верх совершенства по учёту взаиморасчётов? Ты лучше минусы в методике опиши кроме "огород городить", это будет более предметный разговор.. :)

(36) Минусы очень простые — две суммы, которые должны быть одинаковые, если не считать, что они по разным периодам, а на самом деле по разным причинам они могут оказаться разными. И что прикажешь делать в этом случае, какой сумме доверять?

(32) Ого!

(37) Этот минус любой системы, где используется более чем одна таблица. Все типовые конфигурации ему подвержены :) Например, частенько данные по проводкам не соответствуют данным по регистрам. В той же УПП регистры "ВзамиорасчётыСКонтрагентами" и "ВзамиорасчётыСКонтрагентамиПоДокументамРасчётов" необоснованно не совпадают между собой..
Короче, да, это минус. Но это минус не данной методики, а многорегистровой системы вообще. При этом обеспечить соответствие двух сумм в одном регистре - проще чем в разных регистрах, как и гораздо проще найти причины несоответсвтий.

А что делать с работой задним числом (выписка например)

(40) Любая система автоматического зачёта задолженности требует восстановления последовательности в том или ином виде.

(31) При изменении условий договора перепроведение накладной является ошибочным решением.

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

При этом просрочка могла существовать до переноса срока и перестает ею быть после переноса.
Поэтому определение просрочек только по документам оплаты явно недостаточный метод.

Предлагаемое тобой решение выглядит сомнительным.

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

(42) Если требуется история дат оплаты, тогда, думаю, как нельзя лучше подойдет периодический регистр сведений.

(35)да я всё понял. так и сделаю как в 30. Задачу не сейчас решать буду но решение уже найдено. в ветке более, чем достаточно инфы.

(43) Это не "мои лишние навороты" :) Я на авторство методики не претендую, я лишь очень упрощённо описал суть методики учёта взаиморасчётов в УТ 11. Каких-то сущесвтенных минусов, по сравнению с системами использующимися в типовых конфах сейчас, я не увидел. Зато потенциал вижу хороший. Убеждать кого-то в чём-то и доказывать кому-либо что-либо считаю бессмысленным..

(46) Открыл УТ 11.

1. Дата платежа заполняется в документе.
2. Истории даты платежа нет.
3. Дата платежа заполняется в шапке, никаких разделений молока и консервов.
4. Для получения срока просрочки нужно брать дату платежа из документа.

Спрашивается, как все это противоречит сказанному мною ранее?

(47) Методология УТ плохо продумана и выглядит определенно примитивной. Факт.

(47) К чему вопрос? Я не утверждаю, что в УТ реализована система учёта взамиорасчётов совершенная во всех отношениях. Я лишь утверждаю, что методика описанная в (12), которая в т.ч. применяется в УТ 11,  имеет право на то, чтобы её рассматривали как альтернативу методике учёта взаиморасчётов по документам расчётов. Лично мне она кажется более перспективной. Я вижу кучу возможностей в такой методике, которые не реализуются в классической схеме. При этом, всё, что реализуется в классической схеме на эту методику накладывается точно так же. При этом я не утверждал, что все эти плюсы уже реализованы в УТ.
И уж тем более, я не утверждал, что то что сказано тобой ранее чему-то там противоречит.

(16)А где он есть? в ут "ПлатежныйКалендарь" только отчет. в нашей. сейчас выкачиваю последнюю версию УТ.