Страницы: 1
RSS
Пресловутая копейка: некорректное округление при расчете НДС
 
Уважаемые форумчане! Добрый день!
Не раз использовал наработки и идеи форума при работе с Excel, однако столкнулся с проблемой и ни как не могу ее решить. Описание в файле.
Если не затруднит, можете взглянуть что к чему. Элементарные математические действия и тупик..........
P.S. Пытался найти решение по форуму, но как я понял решения не найдено. Если это не так, поделитесь ссылкой.
 
Цитата
Сергей Ольховой написал:
Если не затруднит, можете взглянуть что к чему
Скажу свои соображения - когда предлагают кота в мешке заглядывать не хоца.
Вы создали тему. Так раскройте хоть как-то суть в сообщении. Хоть какой-то намек на саму проблему. Не надо заставлять потенциальных помощников в обязательном порядке скачивать файл и смотреть его. Этим Вы заставляете делать выбор из двух вариантов: либо плюнуть и ничего не скачивать и идти мимо, либо скачать и только после этого понять, можно ли помочь. Если помочь не получится(не по силам вопрос) - пустая трата времени. Теперь внимание, вопрос: какой вариант по-Вашему чаще будут выбирать? :)

P.S. Как-то плохо искали, кстати. Поищите еще по запросу: числа не сходятся - формат ячеек. Точнее направить на мысли смогу после устранения замечаний модератора.
Изменено: The_Prist - 28.03.2017 15:58:28
Даже самый простой вопрос можно превратить в огромную проблему. Достаточно не уметь формулировать вопросы...
 
Глубоко Уважаемые мною гуру!
Прошу прощения! Не со зла! Просто как объяснить словами....... Но попробую.
Итак, имеем цену контракта с НДС 400 рублей которая складывается из 4-х смет по 100 рублей. Это так скажем данность. Я понимаю, что нужно на чистую цену работ накрутить НДС и будет счастье, т.е. так положено, Но имеем то что имеем. Теперь, если вычислить итоговый ндс от 400 рублей то получим 400/1,18=338,98 руб - стоимость без НДС и 338,98*0,18=61,02 руб - НДС. НО! теперь произведем расчет по каждой смете в 100 рублей: 100/1,18=84,75 - стоимость без НДС и 84,75*0,18=15,26 (либо 15,25, т.е. как округлить). Т.е., получается по 4 сметам: без НДС - 84,75*4=339 рублей и НДС 15,26*4=61,04 (либо 15,25*4=61) руб. Вот и гуляют копеечки. Как быть? ФУХ!!!
P.S. Может тему назвать "Некорректное округление при расчете НДС" ? Но как ее поменять не знаю.
 
Цитата
Sergio76 написал:
Прошу прощения! Не со зла!
ну это уж слишком пафосно. Я лишь написал, что ни из названия темы, ни из сообщения вообще неясно, в чем проблема. Это является проблемой для большинства, т.к. скачивать файл только чтобы понять можно Вам помочь или нет никто не жаждет. А когда проблема перед глазами(хотя бы тезисно, увлекаться тоже не надо) -то все проще, человек хоть примерно поймет имеет смысл качать файл и пытаться вникнуть глубже или нет. Вот и все.

По факту: выделите ячейки с суммами(все, включая итоговые) -правая кнопка мыши - Формат ячеек. Вкладка Число - категория Числовой. Поставьте 11 знаков после запятой. Сравните. И поймете, куда девается копейка и откуда она берется...
Вы вручную вводите числа с двумя знаками после запятой, а в ячейке знаков после запятой поболе будет.

Обычно в таких случаях используется функция ОКРУГЛ для тех ячеек, где это необходимо.
Изменено: The_Prist - 28.03.2017 17:12:42
Даже самый простой вопрос можно превратить в огромную проблему. Достаточно не уметь формулировать вопросы...
 
Расчет НДС выполняется по формулам: сумма расчета и сумма после ручного ввода никогда не совпадут.
Если Вы должны непременно представить электронный документ, воспользуйтесть возможностью EXCEL предоставлять "точность, как на экране".
При этом следует помнить, что полученный файл "реанимировать" к предыдущему состоянию будет невзможно.
 
The_Prist,
Спасибо!
Я в принципе так и думал, и форум почитал, и на сколько я понял это пока не решенный вопрос получается. Даже надстроечку Plex замучал с функцией "точность", но не выходит. Эх!
 
Мотя,
Согласен! НО! Получается что 400/1,18=338,98 а в приложенном Вами файлике, Excel округлил значение до 339. Но к сожалению это не так.
 
Цитата
Sergio76 написал:
Получается что 400/1,18=338,98 а Excel округлил значение до 339.
Если Ваша цель - электронный отчет для руководства, то какое это имеет значение?  
Умному руководителю "никогда не придет в голову" проверять расчет на калькуляторе!  
Но если он был когда-то бухгалтером... :D :D :D
 
так подходит?
 
К сожалению нет. Потому что получается, что 3483691,59/1,18=2952281,00 (ну либо ,01) а в приложенном файле 2952281,02. Повторюсь слегка, я конечно понимаю, что как я делаю, это делать не правильно, можно конечно и свитер через ноги одевать, не удобно, муторно но можно. Так и тут, нужно накручивать НДС на стоимость без НДС и получать ИТОГО с НДС. Но к сожалению пробую решить именно обратную задачу, да еще и так, чтобы и по горизонтали цифры бились и по вертикали. О как!
 
Sergio76, Я в подобных случаях поступаю так:
Нахожу наибольшее из получившихся от деления чисел "Стоимость в руб. без НДС" и корректирую его на разницу в копейках, которая возникает от округлений. Это число всё равно меньше "Стоимости в руб. с НДС" не точно в 1,18 раз (из за округлений), поэтому небольшая коррекция именно наибольшего из прочих чисел даёт в принципе корректный результат. Он так же будет отличаться от суммы с НДС примерно в 1,18 раза, а суммы при этом сойдутся копейка в копейку.
 
Когда мне надоели возмущения бухгалтерии по поводу копеек в выписываемых счетах, я в табличной части документов установил размерность для "Цена" и "НДС" -
"число десятичных знаков" = 5. Для "Сумма" - 3 десятичных знака.
В итоговой части как и полагается - 2 десятичных знака.
С ЭТОГО момента от бухгалтерии не слышал ни одной претензии к копейкам в счетах.
 
Виктор Косенков,
Доброе утро! В принципе так и приходится делать! Но это все как говорится от лукавого!
Valera2,
Сейчас взглянем!  
 
Sergio76, Ау!
Пошёл и пропал. Может помощь  нужна? Ау!
 
Тоже сталкивался с этой проблемой. Но! Вопрос - методологии, а не вычислений!
Правило такое: на каждую составную часть НДС накручивается, округляется до копеек. Кстати, последняя фенечка: когда просто стоял ОКРУГЛ до двух знаков (т.е. копеек, то опять (но уже исключительно редко) обнаружились копеечные ошибочки). Анализ показал, что из-за погрешности вычислений EXCEL там, где должно было получиться 0,375, вычисления дают 0,3749999 и округляется до 0,37, хотя должно бы до 0,38. Поэтому теперь сначала округляю до 3-х знаков, потом еще до 2-х:
Код
=ОКРУГЛ(ОКРУГЛ(A1*0.18;3);2)
Пока погрешностей не отлавливал. Хотя, только что в голову мысль пришла, что лучше не до 3-х, а побольше поставить: знаков этак до 9...

К сути:
Итак, для каждой составной части НДС должен вычисляться от суммы! А для результата - нет!!! Для результата НДС должен суммироваться из значений НДС составных частей!
Вот эта методология верная! Погрешностей не будет. Если проверять так, то все всегда сойдется и ничего не потеряется!

Тот, кто проверяет вычислением НДС от общей суммы, поступает неверно методологически. Эта проверка только на грубую ошибку в частях. К копейкам такой проверкой придираться признак непрофессионализма.
Следствие из третьего закона Чизхолма:
"Даже если ясность изложения исключает неверное толкование, все равно найдется кто-то, кто поймет Вас неправильно."
 
Цитата
PerfectVam написал:
для каждой составной части НДС должен вычисляться от суммы
Нормативная база для такого расчёта НДС есть в стране?
 
Готов пересмотреть позицию, если мое предложение противоречит какому-то нормативному акту.
Бывают, конечно, акты, которые противоречат здравому смыслу. Но "техника безопасности" написана кровью... Поэтому обычно в нормативных актах противоречия все-таки удалены.
Мое предложение непротиворечиво. Исходит из того, что все расчеты должны быть в копейках, а не в их долях (никто еще никому не заплатил полкопейки). А если тому, кто получил составной счет, платить надо в разные места по каждой позиции, то это придется!

Но, повторяю: если мне укажете нормативный документ, устанавливающий иное - готов углубиться и проверить.
Следствие из третьего закона Чизхолма:
"Даже если ясность изложения исключает неверное толкование, все равно найдется кто-то, кто поймет Вас неправильно."
 
Доброго дня форумчане!
Цитата
Valera2 написал:
Пошёл и пропал. Может помощь  нужна? Ау!
))) Нее, не пропал, здоровьем кошки занимался! К сожалению вариант с 4 знаками после запятой, не устроит (к стати не меня).......
PerfectVam,
Попробовал и так сделать, с округлением до 9 знаков, все равно какая-то "петрушка" получается. Пример во вложении. Нормативной базы для такого рода расчетов по НДС, на сколько мне известно, нет.
Цитата
PerfectVam написал:
на каждую составную часть НДС накручивается
Вот тут согласен на все 100!!!!!! Но увы, нужно в данном случае идти от обратного.
Цитата
PerfectVam написал:
Для результата НДС должен суммироваться из значений НДС составных частей!
Возможно, НО! В приложенном файле посмотрите что получаем. По вертикали просуммировава, да, вроде все в порядке, однако, по горизонтали, значения не сходятся: 84,75+15,26 ну ни как 100 не дают.........
 
кто понимает C++, то по алгоритму банки делают так - там часть кода (большого листинга примеров), касательно round half even (banker's rounding)... у вас без всяких округлений (и с форматом ячейки хотя бы 5 знаков после зпт - получается 15.25500... т.е., когда тысячные (например) доли, которые не вписываются в номинал минимальной единицы денег, [вобщем следующий разряд за минимальным номиналом], - то если сумма попадает как раз на 1/2 от номинала [минимальной единицы денег]... - там у них своя логика расчёта... и по-моему, они берут floor (т.е. нижнее значение для округления) - это вроде бы особенность банковских расчётов... да и вполне возможно, применимо ко всем расчётам в деньгах... не знаю хорошо C++, но что-то у меня предчувствие, что с деньгами всегда так... и будет ваше 100.00 [Стоимость в руб. с НДС], где 15,25 НДС... и, как вам подсказали ранее, НДС считается на штуки, а не оптом по всему... поэтому 15,25*4=61
Цитата
PerfectVam написал: Для результата НДС должен суммироваться из значений НДС составных частей!
p.s. вобщем, если хотите - верьте банкам... и читайте на другом языке  :)... если не поверите моему предчуствию...
(я C++ хорошо не знаю...)  
Изменено: JeyCi - 03.04.2017 19:43:32
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
там, кстати, линк на статью есть (в начале того листинга - можно по алгоритмам на нормальном английском прочитать вместо C++) - оказывается этот round-half-even algorithm - округляет до ближайшего чётного
Цитата
half-way values are rounded toward the nearest even number. Thus, 3.5 will round up to 4 and 4.5 will round down to 4.
хотя и уточняют
Цитата
In the case of data sets that feature a relatively large number of "half-way" values (financial records provide a good example of this), the round-half-even algorithm performs significantly better than the round-half-up scheme in terms of total bias. However, in the case of data sets containing a relatively small number of "half-way" values – such as real-world values being applied to DSP algorithms – the overhead involved in performing the round-half-even algorithm in hardware does not justify its use (see also the filter examples shown later in this paper).
т.е. банковский вариант нам не совсем подходит...
но всё равно, что-то на моей памяти крутится алгоритм, описанный мной (в #19)...  
Изменено: JeyCi - 04.04.2017 13:57:20
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
НДС от конечной суммы 100 рассчитывается 100/1,18*0,18=15,2542373 при округл дает 15,26
а если от обратного смета 1 без ндс =84,75*0,18=15,255 тоже сводится 15,26... Но в данном случае где-то была ручная запись без формул и тут только копипаст, без формул... формулы лишь выявляют неточности статистики.
«В начале было Слово, и Слово было у Бога, и Слово было Бог»
В оригинальном тексте на древнегреческом языке на месте «Слова» стоит «ὁ Λόγος (Логос)». Еще оно переводится как «ум», «основа», «утверждение», «разумение», «значение», «доказательство»...
 
Марина Русалева,  с какой целью Вы поднимаете темы, которым сто лет?  На форуме полно свежих.
 
Марина Русалева,
спасибо!
вы открыли мне глаза (скорее всего не мне одному), никогда бы в жизни не подумал что такое возможно

извините, а в чем ваш вопрос? что не можете решить?
Программисты - это люди, решающие проблемы, о существовании которых Вы не подозревали, методами, которых Вы не понимаете!
Страницы: 1
Наверх