Как хранить результаты расчётов за период? #764094

Есть предположим условный кредит. Пользователь делает расчёт процентов за произвольный период. Как лучше хранить результат, чтобы исключать из расчёта уже расчитанные дни? Вариант хранения расчёта за каждый день отдельно в регистре накопления имеет недостатки в виде набега лишних копеек в итогах и при закрытии.

Храни дни в регистре сведений, кто тебе запрещает?

считаем за период, бъём на дни, пишем в РС, считаем итог за период - получаем разбег в копейках.

а! или ты имел в виду про то даты? да, есть такой вариант

просто может есть более красивое решение

А хранить рассчитанные суммы - мысль в голову не приходила?

поподробнее? в чём отличие от регистра накопления?

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

нюню. что из тебе непонятно?

рассчитывай по дням и храни дата-сумма. В чем проблема?

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

Ты или трусики надень, или крестик сними... Округляй расчёты так, чтобы ничего не набегало.

"я не тактик, я стратег"

Тогда иди и делай. И не просто иди, а иди, иди, иди, иди....

+1 "заставь дурак богу молиться, так он и лоб расшибет"©

Для начала период начисления процентов какой?

период определяется графиком. расчёт может охватывать произвольный период, не связанный с периодом начисления.

И как древесина? Качественная?

+ Хорошо долбится?

нормально. я конечно понимаю, что моё непонимание вызывает столько восторга и позволяет почесать своё ЧСВ, но в замен всё-таки хотелось получить более конкретные рекомендации.

Так может сначала про принципы начисления и расчета процентов в т.ч. сложных почитать? От этого все непонимание и происходит. К примеру "округление по банковскому" или иначе "банковское округление" стандартный термин уже много много лет.

От даты оплаты начинай новый расчет погрешности. Вообще не понятна проблема. Ты программист или экономист. Если первый, то иди к экономистам и спрашивай формулы расчета. Для примера возьми у них Excel  с расчетом.

формулы примитивные, посчитать не проблема - считают целиком за период: Ставка * ДнейВПериоде / ДнейВГоду * База. я же не про то как считать спрашиваю, а про то, как организовать хранение этих расчётов.

Да вот так как считают так и храни. Пусть дадут расклад за большой период по одному кредиту. На листочке. Вот так как у них будет написано, так и храни.

и тут мы возвращаемся к вопросу в

вот отсюда "формулы примитивные, посчитать не проблема" и начинаются у Вас проблемы )) эти примитивные формулы еще правильно применять нужно к примеру если ставка месячная, то для расчета часто берут некий "стандартный месяц" в (365.2425/12) дней

проблемы от таких советчиков, у которых спрашиваешь как хранить, а они говорят, что считаешь неправильно.

Проблема округления это не проблема программы и БД. Это проблема организационная.

+100500 просто если "считать правильно", то проблемы типа пропадают прикинь да?

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

прикинь - я считаю по формулам из экселя. ты предлагаешь мне пойти и объяснить экономистам что они считают не правильно, да?

Ну если у тебя есть Excel, который уже посчитал. То просто скопируй, то что он насчитал в 1С.

а эти формулы в экселе тоже "программист" рисовал? по объяснениям "экономистов" ?

я не понял, вопрос в как-то непонятно сформулирован? уточняю - вторая строка: "Как лучше хранить результат, чтобы исключать из расчёта уже расчитанные дни? "

Блин мне бы давали Excel для реализации в 1С. Везет тебе, завидую. А то скажут зарплата посчиталась не правильно исправляй... И не скажут ни сотрудника, ни вид расчета, ни месяц, но должен сделать вчера...

как хочешь так и храни

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

почему тебя это беспокоит?

а ты зачем вообще приходил?

как бы правильно будет "зачем Вы пришли, когда я тут уже давно сидел" :)

какбе в этой ветке первый я :)

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

>> Тогда будет проблема только при перекрытии новыми расчетами уже сделанных именно... всего 3 часа понадобилось

это системная проблема, она была изначально заложена в Ваше решение

а можно выключить капитана-очевидность?

не изображать

если я тебя задолбал, почему ты ещё здесь? мазохизм?

Мне любопытно когда все таки дойдет. Что если тот кто говорит/спрашивает/объясняет не телепат, и тот кто пытается слушать/понять тоже не телепат. То как можно объяснить что то не используя правильных слов? ЗЫ Но большой опыт "телепатии" дает некий навык, понять что дело бесполезное, просто кого то поменять нужно

так ты вопроса не понял? вроде в всё выяснили

дык выяснили что то к полусотне постов? и еще что то выяснится к 100, 200, 1000 постам? или нормальный понятный любому (специалисту) вопрос, или все исходные данные "с картинками" без этого никак не понять что там хочется и зачем

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

Ты бы тоже слез с пьедестала на минуту и расписал бы пример полностью, чтобы проблема была всем видна.

слезаю пользователь 10 числа делает расчёт с 1.01 по 10.01. другой пользователь делает расчёт в конце месяца с 1.01 по 31.01. необходимо во втором расчёте учесть уже существующий расчёт - т.е. период сделать с 11.01 по 31.01. да, я могу в запросе соединиться с регистром и сдвинуть даты. спрашивал об альтернативных вариантах.

Можно в независимом регистре хранить полный период, покрытый всеми предыдущими расчетами. После расчета его актуализировать.

главной фишки не понял )) если периоды при расчетах перекрываются то новый расчет дает другие совсем отличные от старого циферки для этого перекрывания... :-D и ТС хочет циферки брать из старого расчете и как то подогнать циферки из нового чтобы "все сошлось"

была похожая идея - хранить последнюю дату последнего периода. вроде разрывов не должно быть >>и ТС хочет циферки брать из старого расчете и как то подогнать циферки из нового чтобы "все сошлось" вот придумывать за меня не нужно. подгонять я пока ничего не собираюсь. но проблема такая есть - в списке вопросов к обсуждению обозначена.

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

ни там ни там. в моём случае настройками определяется учитывать фактические оплаты или считать по плановому графику.

и выкать мне не нужно

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

+ но вообще ситуация пересечения периодов двух расчетов это нонсенс если период пересчитывается это означает что "старый условный кредит" закрыт полностью и сейчас считаем некий "новый кредит" а его низзя всучить задним числом ))

речь не об пересчёте периода, а о том, что нужно исключить возможность посчитать два раза один период.

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

+ договор/кредит и 2 даты это все измерения, в ресурс что угодно засунуть