Я и хотел, чтобы машина изначально считала то, что изначально нужно. А пока используется подход "так считает машина, что мы сделаем". Я не говорю о множестве подходов к начислению процентов, как учили в институте (начисление в начале периода, в конце, с ежемесячным начислением, ежедневным, непрерывным и т.п.)
Да и было бы здорово запретить проходить тест 2 раза, а ответы не показывать до окончания конкурса. Честно, сказать, я плохо прошел его первый раз, а затем подсмотрел ответы в том json, который вписан прямо в html iframe-а и нехитрым образом угадал все ответы, хотя в принципе и так их запомнил. Также можно было представиться любым пользователем, к примеру, @asdflkja;fdskj;akjd;2kj и пройти неуспешно тест, а затем пройти со своим хабранеймом уже на отлично.
чет-нечет округление это же для случая, когда после знака, до которого нужно округлить, идёт 5,а дальше нули. А здесь вопрос не в методике округления отдельно взятого числа, а в накопительном эффекте периодических начислений
А какие основания для того, чтобы определять? Бухгалтерия ежемесячно насчитала и сложила и что её делать с этими копейками? Попробуйте банку недоплатить проценты по кредиту сказав, что я определил копейки округлять именно так.
Да, в целях расчёта по налогам суммами до рубля пренебрегают, но как быть с банковскими процентами?
В данной статье я предлагаю сразу определяться с методом расчёта процентов, чтобы ни у кого не было разночтений при расчёте процентов.
Вы вовсе не поняли суть проблемы. Округлять можно по любому правилу с точностью до копеек. Но бывают ситуации, к примеру, человек получил займ от компании 100 000 рублей на 2 года под 1% годовых, через 2 года он возвращает сумму процентов в размере 2 000 рублей, а бухгалтерия, которая ежемесячно начисляла проценты, говорит, что нужно 2000 рублей и 3 копейки. Вот кто из них прав?
Также дополню, что в договорах нужно указывать как именно нужно производить расчёт процентов, так как ежемесячное начисление приводит к "обрезанию хвостов" чисел. А вот, к примеру, Ваш контрагент может начислять проценты по иному - раз в год (иностранная компания допустим), получается разница и нужно для надёжности обкладываться письмами по сверке начислений и т.п.
А про "социально ответственное", которым Вы окрестили так называемое "банкирское округление", оно же относится только к той ситуации, когда после знака, до которого нужно округлить идёт 5 ,а дальше нули. Но это не вопрос накопительной ошибки из-за округлений, а просто отдельный технический момент отдельно взятого округления.
Видимо, поэтому Microsoft решила похоронить VBA и теперь нужно делать облачные надстройки. По проблеме кодировки на поверхности даже на StackOverflow пишут, что с кодировкой в текстах макросов VBA проблемы и никто, видимо, не собирается их исправлять.
Хотел сделать эту облачную надстройку, но пока руки не дошли. Правда начало небольшое есть, там проект надо сделать на JS (код проекта очень похож на программирование веб страницы, можно писать с использованием React, собирать webpack-ом). Публиковать зато можно после проверок и регистрации в магазине надстроек, как-то деполить в корпоративное сети и по отдельности тоже, вроде, можно.
В принципе да, там та же проблема. Она заключается в том, что мы когда умножаем сумму долга на ставку мы используем числа с заданной точностью либо (но так делать в промышленных системах нельзя) с плавающей точкой. Полученное число означает сумму процентов за определённый период (день, месяц и др.) Только вот вопрос какие значения суммировать округлённые или без округления?
Да суммы начислений в таблицах 2 и 3 одинаковые. Просто там подход немного другой: в таблице 2 начисляются проценты за период с начала действия договора и затем вычисляется разница в накопленных процентах, а в варианте 3 начисляются проценты за каждый период в отдельности и только потом вычисляется разница между округленными значениями накопленной суммой процентов с начала периода по текущий период и накопленной суммой процентов на начало текущего периода. Разница в целом только техническая нужна для удобства реализации начислений в тех случаях, когда подразумевается, что ставка может меняться, да и общий срок договора больше нескольких лет.
Только минус этого подхода в том, что нужно иметь все предыдущие суммы начисленных процентов. Я считаю, что есть несколько подходов к округлению, нужно просто это вписывать в договор как отдельное условие
В принципе да, там та же проблема. Она заключается в том, что мы когда умножаем сумму долга на ставку мы используем числа с заданной точностью либо (но так делать в промышленных системах нельзя) с плавающей точкой. Полученное число означает сумму процентов за определённый период (день, месяц и др.) Только вот вопрос какие значения суммировать округлённые или без округления?
Видимо, неправильно меня поняли.
Я имел ввиду, сколько дней календарных в периоде приходится на високосные года.
Теперь я понял, что вы высчитывали в п.2.и 3 первого Вашего комментария.
Эта функция нужна мне была для расчёта процентов по займам, где за базу берётся фактическое количество дней в году. То есть если мы выдали займ 01.12.2020, а вернём 01.12.2021, то мы должны проценты следующим образом:
1. Сумма процентов 2020 = СуммаЗайма * %*(30 дней/366)
2. Сумма процентов 2021 = СуммаЗайма*%*(335 дней/365)
3. Сумма процентов = Сумма процентов 2020 + Сумма процентов 2021
Просто хотелось это упаковать в одну формулу: =СуммаЗайма * Процент*(LEAP_DAYS(ДатаНачала, ДатаОкончания)/366+NON_LEAP_DAYS(ДатаНачала, ДатаОкончания)/365)
Я и хотел, чтобы машина изначально считала то, что изначально нужно. А пока используется подход "так считает машина, что мы сделаем". Я не говорю о множестве подходов к начислению процентов, как учили в институте (начисление в начале периода, в конце, с ежемесячным начислением, ежедневным, непрерывным и т.п.)
Квиз опять с ответами?
Да и было бы здорово запретить проходить тест 2 раза, а ответы не показывать до окончания конкурса. Честно, сказать, я плохо прошел его первый раз, а затем подсмотрел ответы в том json, который вписан прямо в html iframe-а и нехитрым образом угадал все ответы, хотя в принципе и так их запомнил. Также можно было представиться любым пользователем, к примеру, @asdflkja;fdskj;akjd;2kj и пройти неуспешно тест, а затем пройти со своим хабранеймом уже на отлично.
чет-нечет округление это же для случая, когда после знака, до которого нужно округлить, идёт 5,а дальше нули. А здесь вопрос не в методике округления отдельно взятого числа, а в накопительном эффекте периодических начислений
А какие основания для того, чтобы определять? Бухгалтерия ежемесячно насчитала и сложила и что её делать с этими копейками? Попробуйте банку недоплатить проценты по кредиту сказав, что я определил копейки округлять именно так.
Да, в целях расчёта по налогам суммами до рубля пренебрегают, но как быть с банковскими процентами?
В данной статье я предлагаю сразу определяться с методом расчёта процентов, чтобы ни у кого не было разночтений при расчёте процентов.
Вы вовсе не поняли суть проблемы. Округлять можно по любому правилу с точностью до копеек. Но бывают ситуации, к примеру, человек получил займ от компании 100 000 рублей на 2 года под 1% годовых, через 2 года он возвращает сумму процентов в размере 2 000 рублей, а бухгалтерия, которая ежемесячно начисляла проценты, говорит, что нужно 2000 рублей и 3 копейки. Вот кто из них прав?
Также дополню, что в договорах нужно указывать как именно нужно производить расчёт процентов, так как ежемесячное начисление приводит к "обрезанию хвостов" чисел. А вот, к примеру, Ваш контрагент может начислять проценты по иному - раз в год (иностранная компания допустим), получается разница и нужно для надёжности обкладываться письмами по сверке начислений и т.п.
А про "социально ответственное", которым Вы окрестили так называемое "банкирское округление", оно же относится только к той ситуации, когда после знака, до которого нужно округлить идёт 5 ,а дальше нули. Но это не вопрос накопительной ошибки из-за округлений, а просто отдельный технический момент отдельно взятого округления.
Что это за округление такое?
Ну да, там же utf-8, а надо смотреть в кодировке 1251
Видимо, поэтому Microsoft решила похоронить VBA и теперь нужно делать облачные надстройки. По проблеме кодировки на поверхности даже на StackOverflow пишут, что с кодировкой в текстах макросов VBA проблемы и никто, видимо, не собирается их исправлять.
Хотел сделать эту облачную надстройку, но пока руки не дошли. Правда начало небольшое есть, там проект надо сделать на JS (код проекта очень похож на программирование веб страницы, можно писать с использованием React, собирать webpack-ом). Публиковать зато можно после проверок и регистрации в магазине надстроек, как-то деполить в корпоративное сети и по отдельности тоже, вроде, можно.
Посмотрю, можно ли пересохранить в другой кодировки. У меня под Win11 работает с этими параметрами.
На гитахбе немного изменил код, устанавливающий надстройку. Вроде теперь должна устанавливаться корректно, если у кого не устанавливалась
хм. Странно. У меня Win 10 Office 2021 x64, но с кодировкой всё в порядке.
Попробую дома на Win 11, возможно в этом дело.
Здесь не про вероятность, ошибка не будет стремиться к нулю.
В принципе да, там та же проблема. Она заключается в том, что мы когда умножаем сумму долга на ставку мы используем числа с заданной точностью либо (но так делать в промышленных системах нельзя) с плавающей точкой. Полученное число означает сумму процентов за определённый период (день, месяц и др.) Только вот вопрос какие значения суммировать округлённые или без округления?
С чего Вы взяли, что начисление суммы процентов за 3 года, к примеру, должны равняться сумме начислений за 36 месяцев?
Да суммы начислений в таблицах 2 и 3 одинаковые. Просто там подход немного другой: в таблице 2 начисляются проценты за период с начала действия договора и затем вычисляется разница в накопленных процентах, а в варианте 3 начисляются проценты за каждый период в отдельности и только потом вычисляется разница между округленными значениями накопленной суммой процентов с начала периода по текущий период и накопленной суммой процентов на начало текущего периода. Разница в целом только техническая нужна для удобства реализации начислений в тех случаях, когда подразумевается, что ставка может меняться, да и общий срок договора больше нескольких лет.
Только минус этого подхода в том, что нужно иметь все предыдущие суммы начисленных процентов. Я считаю, что есть несколько подходов к округлению, нужно просто это вписывать в договор как отдельное условие
В принципе да, там та же проблема. Она заключается в том, что мы когда умножаем сумму долга на ставку мы используем числа с заданной точностью либо (но так делать в промышленных системах нельзя) с плавающей точкой. Полученное число означает сумму процентов за определённый период (день, месяц и др.) Только вот вопрос какие значения суммировать округлённые или без округления?
Я имел ввиду, сколько дней календарных в периоде приходится на високосные года.
Теперь я понял, что вы высчитывали в п.2.и 3 первого Вашего комментария.
Эта функция нужна мне была для расчёта процентов по займам, где за базу берётся фактическое количество дней в году. То есть если мы выдали займ 01.12.2020, а вернём 01.12.2021, то мы должны проценты следующим образом:
1. Сумма процентов 2020 = СуммаЗайма * %*(30 дней/366)
2. Сумма процентов 2021 = СуммаЗайма*%*(335 дней/365)
3. Сумма процентов = Сумма процентов 2020 + Сумма процентов 2021
Просто хотелось это упаковать в одну формулу:
=СуммаЗайма * Процент*(LEAP_DAYS(ДатаНачала, ДатаОкончания)/366+NON_LEAP_DAYS(ДатаНачала, ДатаОкончания)/365)