Доброго времени суток. Пишу рассрочку для 1С розницы. Необходимо сохранять информацию о событиях которые произойдут в будущем: график платежей, например на год вперед. И оперативно их отслеживать. То есть запросы которые покажут: 1. Общую задолженность клиентов магазину. 2. Просроченную задолженность. 3. Планируемые платежи в этом месяце. Эти запросы должны быть достаточно простыми, чтобы к примеру их можно было без проблем для производительности положить в динамический список. Как должен выглядеть такой регистр? Писать плановую дату платежа в измерение или писать события будущей датой? Или может быть какое-то другое решение?

Для начала определиться с типом регистра оборотный или остатков.
Если писать "будущей датой" (использовать период регистра как дату платежа), то неудобно работать с просрочкой - понадобятся регламенты чтобы их постоянно переносить.

(1)Регистр остатков конечно был бы удобен. Можно одним простым движением увидеть, что нам должен клиент. Зачем что-то переносить?

2 оборотных регистра

1. План
контрагент
договор
Месяц(из справочника периоды, ни в коем случае не дата)

2.Факт - аналогичный


достоинсва такой системы - не будет проблемм с периодами регистратора (все равно когда документ сделан) и легкость сторнировачных и прочих "странных" записей

(2) Регистр остатков удобен тем чтобы смотреть остатки (как ты сам заметил), и в таблице остатков период виден не будет.

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

(3) А зачем два одинаковых регистра? Один с двумя ресурсами "План" и "Факт" не логичнее?

(3)Я понял, что период ты считаешь использовать неразумным. и все записи должны лечь одной датой(датой проведения документа) Но чем в данном случае дата отличается от элемента справочника можно для тупых? Так же строятся отборы и тд

(3) И как при такой структуре получить ожидаемые поступления с учетом просроченных? с начала базы из плана факт вычитать?

(6)Дата имеется ввиду измерение в регистре с типом "дата"

(6) (8) Вроде есть/была рекомендация не использовать простые типы в качестве измерений регистров

(5) нет...

ресурсов и так может быть много, например

Основная сумма, Сумма процентов, Сумма пени, и т.д. при чем у плана и факта это будет разные ресурсы.

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

(0)Получается, что бы оценить задолженность в целом нне надо будет выбрать ВСЕ долги из регистра "план" и вычесть из них ВСЕ платежи из регистра "факт"?

(6) дата в виде справочника это корректная таблица оборотов даже в будующем, без проблемм связанных с перерасчетом итогов

(11)к (3)

(10) Разделение по ресурсам (у плана свои у ресурса свои) или по измерению (перечисление.ПланФакт) так же легко позволяет отобрать данные в одном регистре.

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

(14) можно все свалить в один регистр, я так раньше делал (лет 10 назад)... теперь делаю в 2х разных - это намного удобнее... впрочем убеждать не буду...

(16) И не убедишь :) ... уже был опыт переделывания регистра оборотов в БитФинанс на свой регистр остатков.

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

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

(18) отсюда всю задачу ТС не видно. Там где я видел жесткую необходимость в планировании ДДС периодичности месяц было явно не достаточно.
Ну и немного странно слышать про производительность после (11).

>> сразу отказаться от регистра остатков
У меня в остатках тысяча платежей - я их возьму из таблицы остатков. Ты возьмёшь миллионы записей плана, соединишь с миллионом записей факта, отфильтруешь нулевые и получишь ту же тысячу записей. А через пять лет ты будешь оперировать десятками миллионами записей чтобы получить те же тысячи плановых платежей.

(19) у тебя при записи документа текущей датой будут пересчитываться остатки на год вперед, а у меня только обороты за 1 месяц

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

(20) У меня не будет пересчитывать ничего вперёд, плановая дата в измерениях так же как и у тебя. Только не месяц, а более детально. Все движения пишутся текущей датой - датой документа.

Работает - хорошо. Чтобы выяснить что лучше можно смоделировать (19) и запустить на одинаковом железе. Не верю, что скорость будет сравнима :)

Я понял мысль vde69, берем два регистра в один пишем, план, во второй пишем факт из одного вычитаем второй, все готово. vde69 утверждает, что так как работаем с итогами, то быстродействие приемлемое. Я бы добавил туда третий регистр с остатками. И рассчитывал просрочки только по тем, по кому есть остатки что бы исключить ситуацию из (11): "А через пять лет ты будешь оперировать десятками миллионами записей чтобы получить те же тысячи плановых платежей". Я буду брать срез остатки, и по контрагентам оттуда уже рассчитывать просрочки, исключая миллионы ненужных записей. Звучит вроде бы логично. Но не могу понять, что предлагает RomanYS

(22) 1. Разделить задачи фин. планирования (условно план-факт по месяцам), оперативного планирования ДДС (платежный календарь) и учета дебиторки.

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

Вторую я бы решал регистром остатков, где плановая дата будет сидеть в реквизите измерения. Измерением будет или заявка или что-аналогично, при отсутствии аналогов служебный справочник или документ платежная позиция. Если достаточно детализации по месяцам - можно просто справочник месяцев, как предлагает vde69, правда кому нужен платежный календарь по месяцам не очень представляю

Дебиторку и взаиморасчеты естественно в отдельном регистре/регистрах.

(23) по поводу регистра остатков - ты не боишься, что он у тебя не будет закрываться?

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

ну либо тебе придется регламентом все расхождения между планом и фактом перекидывать на отдельный регистр, и этот регистр то-же должен быть оборотным а не остатков.

(22) забудь про типовой механизм срез остатков, его нельзя делать... только в самом запросе делать план-факт... в противном случае будет (24)

(25) +
если будет очень много договоров - то нужен третий регистр сведений "Активные договора" что-бы делать джойн с регистрами оборотов

Очень сомнительно засовывать график платежей в регистр накопления. Исполнение графика может плясать в разные стороны: один вечный должник, другой на второй месяц погасит долг за весь год... Я бы график платежей сделал периодическим регистром сведений. Где период регистра это лишь версия графика, а месяц в измерении, срез последних показывает актуальный график. Исполнение графика сделал регистром накопления остатков. Когда возникает задолженность - приход, погашается - расход

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

(27) в регистре накопления график очень удобно корректировать, не нужно все пересчитывать...

(29) каждый платеж придется заморочиться раскинуть по месяцам

(24) Не боюсь. Платежный календарь мониторит ответственный каждый день. Все остатки в регистре - это реальные деньги, которые ожидаются в конкретные сроки. Он не может не закрыться).
И ещё раз повторюсь, "план-факт" это немного другая задача и она вполне решается (3). Но пытаться из такого регистра собрать платежный календарь - идея сомнительная.

(22)По какой причине регистр накопления может не закрыться?