Вход | Регистрация
 

Помогите придумать: регистр с информацией о графиках платежей. Как должен выглядеть?

Помогите придумать: регистр с информацией о графиках платежей. Как должен выглядеть?
Я
   Web00001
 
05.09.20 - 15:09
Доброго времени суток. Пишу рассрочку для 1С розницы. Необходимо сохранять информацию о событиях которые произойдут в будущем: график платежей, например на год вперед. И оперативно их отслеживать. То есть запросы которые покажут: 1. Общую задолженность клиентов магазину. 2. Просроченную задолженность. 3. Планируемые платежи в этом месяце. Эти запросы должны быть достаточно простыми, чтобы к примеру их можно было без проблем для производительности положить в динамический список. Как должен выглядеть такой регистр? Писать плановую дату платежа в измерение или писать события будущей датой? Или может быть какое-то другое решение?
   RomanYS
 
1 - 05.09.20 - 15:40
Для начала определиться с типом регистра оборотный или остатков.
Если писать "будущей датой" (использовать период регистра как дату платежа), то неудобно работать с просрочкой - понадобятся регламенты чтобы их постоянно переносить.
   Web00001
 
2 - 05.09.20 - 15:45
(1)Регистр остатков конечно был бы удобен. Можно одним простым движением увидеть, что нам должен клиент. Зачем что-то переносить?
   vde69
 
3 - 05.09.20 - 15:49
2 оборотных регистра

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

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


достоинсва такой системы - не будет проблемм с периодами регистратора (все равно когда документ сделан) и легкость сторнировачных и прочих "странных" записей
   RomanYS
 
4 - 05.09.20 - 15:53
(2) Регистр остатков удобен тем чтобы смотреть остатки (как ты сам заметил), и в таблице остатков период виден не будет.

>> Зачем что-то переносить?
Вчера ты ждал деньги, сегодня ты уже не ждешь что они придут вчера. Ты ждешь их сегодня, завтра или когда-то ещё. Ну и вообще график платежей (платёжный календарь) и дебиторка по срокам - это разные сущности и возможно требуют разных подходов
   RomanYS
 
5 - 05.09.20 - 15:58
(3) А зачем два одинаковых регистра? Один с двумя ресурсами "План" и "Факт" не логичнее?
   Web00001
 
6 - 05.09.20 - 15:59
(3)Я понял, что период ты считаешь использовать неразумным. и все записи должны лечь одной датой(датой проведения документа) Но чем в данном случае дата отличается от элемента справочника можно для тупых? Так же строятся отборы и тд
   RomanYS
 
7 - 05.09.20 - 16:00
(3) И как при такой структуре получить ожидаемые поступления с учетом просроченных? с начала базы из плана факт вычитать?
   Web00001
 
8 - 05.09.20 - 16:00
(6)Дата имеется ввиду измерение в регистре с типом "дата"
   RomanYS
 
9 - 05.09.20 - 16:02
(6) (8) Вроде есть/была рекомендация не использовать простые типы в качестве измерений регистров
   vde69
 
10 - 05.09.20 - 16:02
(5) нет...

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

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

кроме того иногда бывает нужно сделать отчет только по начислениям, и нельзя что-бы туда попадали например возвраты или корректировки...
   Web00001
 
11 - 05.09.20 - 16:04
(0)Получается, что бы оценить задолженность в целом нне надо будет выбрать ВСЕ долги из регистра "план" и вычесть из них ВСЕ платежи из регистра "факт"?
   vde69
 
12 - 05.09.20 - 16:04
(6) дата в виде справочника это корректная таблица оборотов даже в будующем, без проблемм связанных с перерасчетом итогов
   Web00001
 
13 - 05.09.20 - 16:04
(11)к (3)
   RomanYS
 
14 - 05.09.20 - 16:06
(10) Разделение по ресурсам (у плана свои у ресурса свои) или по измерению (перечисление.ПланФакт) так же легко позволяет отобрать данные в одном регистре.
   vde69
 
15 - 05.09.20 - 16:06
(11) да, именно так, при этом работаем с виртуальной таблицей "Обороты" без периодичности, по факту это будет работа с помесячными итогами
   vde69
 
16 - 05.09.20 - 16:08
(14) можно все свалить в один регистр, я так раньше делал (лет 10 назад)... теперь делаю в 2х разных - это намного удобнее... впрочем убеждать не буду...
   RomanYS
 
17 - 05.09.20 - 16:10
(16) И не убедишь :) ... уже был опыт переделывания регистра оборотов в БитФинанс на свой регистр остатков.
   vde69
 
18 - 05.09.20 - 16:15
(17) есть много реализаций схемы "план/факт", в сабже ключевой момент - начисления на год вперед, по этому все типовые механизмы основанные на периоде в виде даты или дают резкое ухудшении производительности (из-за работы сильно задним числом) или вообще не могут быть реализованы.

По этому нужно отдельное ссылочное измерение "месяц" и сразу отказаться от регистра остатков, все дальнейшее на усмотрение автора...
   RomanYS
 
19 - 05.09.20 - 16:31
(18) отсюда всю задачу ТС не видно. Там где я видел жесткую необходимость в планировании ДДС периодичности месяц было явно не достаточно.
Ну и немного странно слышать про производительность после (11).

>> сразу отказаться от регистра остатков
У меня в остатках тысяча платежей - я их возьму из таблицы остатков. Ты возьмёшь миллионы записей плана, соединишь с миллионом записей факта, отфильтруешь нулевые и получишь ту же тысячу записей. А через пять лет ты будешь оперировать десятками миллионами записей чтобы получить те же тысячи плановых платежей.
   vde69
 
20 - 05.09.20 - 16:36
(19) у тебя при записи документа текущей датой будут пересчитываться остатки на год вперед, а у меня только обороты за 1 месяц

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

Работает - хорошо. Чтобы выяснить что лучше можно смоделировать (19) и запустить на одинаковом железе. Не верю, что скорость будет сравнима :)
   Web00001
 
22 - 06.09.20 - 15:19
Я понял мысль vde69, берем два регистра в один пишем, план, во второй пишем факт из одного вычитаем второй, все готово. vde69 утверждает, что так как работаем с итогами, то быстродействие приемлемое. Я бы добавил туда третий регистр с остатками. И рассчитывал просрочки только по тем, по кому есть остатки что бы исключить ситуацию из (11): "А через пять лет ты будешь оперировать десятками миллионами записей чтобы получить те же тысячи плановых платежей". Я буду брать срез остатки, и по контрагентам оттуда уже рассчитывать просрочки, исключая миллионы ненужных записей. Звучит вроде бы логично. Но не могу понять, что предлагает RomanYS
   RomanYS
 
23 - 06.09.20 - 15:30
(22) 1. Разделить задачи фин. планирования (условно план-факт по месяцам), оперативного планирования ДДС (платежный календарь) и учета дебиторки.

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

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

Дебиторку и взаиморасчеты естественно в отдельном регистре/регистрах.
   vde69
 
24 - 06.09.20 - 16:26
(23) по поводу регистра остатков - ты не боишься, что он у тебя не будет закрываться?

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

ну либо тебе придется регламентом все расхождения между планом и фактом перекидывать на отдельный регистр, и этот регистр то-же должен быть оборотным а не остатков.
   vde69
 
25 - 06.09.20 - 16:28
(22) забудь про типовой механизм срез остатков, его нельзя делать... только в самом запросе делать план-факт... в противном случае будет (24)
   vde69
 
26 - 06.09.20 - 16:30
(25) +
если будет очень много договоров - то нужен третий регистр сведений "Активные договора" что-бы делать джойн с регистрами оборотов
   Конструктор1С
 
27 - 06.09.20 - 16:32
Очень сомнительно засовывать график платежей в регистр накопления. Исполнение графика может плясать в разные стороны: один вечный должник, другой на второй месяц погасит долг за весь год... Я бы график платежей сделал периодическим регистром сведений. Где период регистра это лишь версия графика, а месяц в измерении, срез последних показывает актуальный график. Исполнение графика сделал регистром накопления остатков. Когда возникает задолженность - приход, погашается - расход
   mistеr
 
28 - 06.09.20 - 16:45
(24) Не думаю, что в данной задаче (рассрочка в рознице) регистр не будет закрываться. Если долг не выплачен в течение какого-то периода, его списывают в убыток или передают в другой бизнес процесс, но из регистра рассрочки все равно списывают.
   vde69
 
29 - 06.09.20 - 18:20
(27) в регистре накопления график очень удобно корректировать, не нужно все пересчитывать...
   Конструктор1С
 
30 - 06.09.20 - 18:56
(29) каждый платеж придется заморочиться раскинуть по месяцам
 
 Рекламное место пустует
   RomanYS
 
31 - 06.09.20 - 18:57
(24) Не боюсь. Платежный календарь мониторит ответственный каждый день. Все остатки в регистре - это реальные деньги, которые ожидаются в конкретные сроки. Он не может не закрыться).
И ещё раз повторюсь, "план-факт" это немного другая задача и она вполне решается (3). Но пытаться из такого регистра собрать платежный календарь - идея сомнительная.
   Web00001
 
32 - 07.09.20 - 09:01
(22)По какой причине регистр накопления может не закрыться?


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.