Решение проблемы связанной с 4мя символами после запятой

[lmz]

Добрый день, имеется такая проблема, например цены в Opencart задаются все без налога, цена товара в админке 1.8800, при добавление туда налога 21% цена получается 2.2748 , цена на фронте для клиента показывается как 2.27, при покупке одной штуки товара все ок, но если покупается например 25 шт, то вместо того чтоб цене быть правильной с точки зрения фронта 56.75, в счете выводится 56.87, главный вопрос эта ерунда как-то решается кроме как на фронте показывать все четыре знака после запятой? Нужно такое решение чтоб он работал не с четырьмя знаками после запятой, а только с двумя во всех подсчетах и везде на сайте, пускай он подобные цены округляет 2.2748 и отсекает эти 48 чтоб они в подсчетах не фигурировали в данном случае чтоб 1.88 при 21% была ровно 2.27 без хвостов остальных, и все totals и прочие считали это как 2.27 а не 2.2748, надеюсь не запутал  Спасибо за ответ!

Змінено 24 березня 2023 користувачем lmz

[SergeTkach]

Типа вот так -- https://ibb.co/0r4sGzL

 

Вот получил в корзине -- https://ibb.co/s1Fv7Mk

 

Это я сделал в catalog/controller/checkout/cart.php

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

 

Было:

 

$unit_price = $this->tax->calculate($product['price'], $product['tax_class_id'], $this->config->get('config_tax'));
					
$price = $this->currency->format($unit_price, $this->session->data['currency']);
$total = $this->currency->format($unit_price * $product['quantity'], $this->session->data['currency']);

 

Стало:

 

$product['price'] = $this->currency->format($product['price'], $this->session->data['currency'], '', false);
					
$unit_price = $this->tax->calculate($product['price'], $product['tax_class_id'], $this->config->get('config_tax'));
					
$price = $this->currency->format($unit_price, $this->session->data['currency']);
$total = $this->currency->format($unit_price * $product['quantity'], $this->session->data['currency']);

 

То есть, надо не просто брать цену, а прогонять ее через $this->currency->format() с указанием четвертого параметра false

[lmz]

Тут нужно решение которое будет идти от ядра /system/library, каждую модель/контроллер править это утопия, либо готовый модуль-фикс купить тоже ок, там просто все одно за другое цепляется и везде идет округление то в большую сторону то в меньшую за счет round() и пляска это повсюду, даже если 1 товар стоит 2.27 а ниже пишет цена без налога 1.88, хотя это 1.87 (налог 21%), получается что нужно чтоб не было никаких округлений нигде не в какую сторону

Змінено 24 березня 2023 користувачем lmz

[Xelen]

24.03.2023 в 08:39, lmz сказал:

Добрый день, имеется такая проблема, например цены в Opencart задаются все без налога, цена товара в админке 1.8800, при добавление туда налога 21% цена получается 2.2748 , цена на фронте для клиента показывается как 2.27, при покупке одной штуки товара все ок, но если покупается например 25 шт, то вместо того чтоб цене быть правильной с точки зрения фронта 56.75, в счете выводится 56.87, главный вопрос эта ерунда как-то решается кроме как на фронте показывать все четыре знака после запятой? Нужно такое решение чтоб он работал не с четырьмя знаками после запятой, а только с двумя во всех подсчетах и везде на сайте, пускай он подобные цены округляет 2.2748 и отсекает эти 48 чтоб они в подсчетах не фигурировали в данном случае чтоб 1.88 при 21% была ровно 2.27 без хвостов остальных, и все totals и прочие считали это как 2.27 а не 2.2748, надеюсь не запутал  Спасибо за ответ!

 

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

 

у меня установлен Instant Product Editor. прямо из списка задаю ценю с налогом 2,27. захожу в карточку товара в админке, там цена 1.8760, а не 1.8800

 

на фронте 2,27. в корзине 25 штук - 56.75€

50 шт - 113,50

вроде все верно?

 

короче, надо цены немного занижать, чтобы срабатывало, это и делают всякие редакторы товаров в админке.

 

[Xelen]

а, вообще, вы неправильно налог считаете.

в любом калькуляторе 2,27 / 1,21  даст 1,876033 . вам надо вводить именно это число в админке, а не 1,88

тогда можно и без расширений

[lmz]

Цена приходит из хмла, цена товару 1.88 эта цена без налога, при добавление налогового класса цена становится 2.2748, и из-за этого при покупки 25 шт товара цена выходит 56,87, но клиент на фронте видит цену 2.27 и цена должна быть ему 56,75 (да это копейки но для бухгалтерии и для клиента это непонятно)

 

Если ты в супермаркете купишь макароны за 2.27 в количестве 25шт ты ведь заплатишь 56.75, а не 56.87

2.2748 - таких денег нету как эти 0.0048 их нельзя заплатить, их не должно быть, поэтому суть вопроса в том чтоб в расчетах было только два знака после запятой то что можно заплатить, пусть товар стоит 1.88 и пусть он будет с налогом 2.27 без каких либо остатков которые нельзя заплатить и которые считаются при большом количестве товару, это можно решить малой кровью? или лопатить весь движок надо?

 

Ваше решение хорошее насчет цены чтоб была 1.8760, но на сайте есть так-же и юридические лица которые не платят налога, и с ними получается очередная пляска с этими округлениями, надо чтоб та цена что видна клиенту это 2.27 чтоб при покупки любого количества оставалась правильная цена на основе этих 2.27 а не 2.2748.

[Xelen]

25.03.2023 в 13:39, lmz сказал:

Ваше решение хорошее насчет цены чтоб была 1.8760, но на сайте есть так-же и юридические лица которые не платят налога, и с ними получается очередная пляска с этими округлениями, надо чтоб та цена что видна клиенту это 2.27 чтоб при покупки любого количества оставалась правильная цена на основе этих 2.27 а не 2.2748.

 

если честно, так и не поняла, в чем проблема с юриками. 1.8760 - это и есть правильная цена, просто 4 значения после нуля, а не 2. А на сайте это все равно округляется визуально. Полное же число не показывается, с четырьмя значениями после нуля. Приведите реальный пример проблемы в этом случае.

У меня на проектах из 1С подается именно такая стоимость, ни у кого нет проблем, а вот если округлять до 2 чисел после запятой, то и получается больше, чем должно, при большом количестве.

 

[lmz]

27.03.2023 в 17:02, Xelen сказал:

 

если честно, так и не поняла, в чем проблема с юриками. 1.8760 - это и есть правильная цена, просто 4 значения после нуля, а не 2. А на сайте это все равно округляется визуально. Полное же число не показывается, с четырьмя значениями после нуля. Приведите реальный пример проблемы в этом случае.

У меня на проектах из 1С подается именно такая стоимость, ни у кого нет проблем, а вот если округлять до 2 чисел после запятой, то и получается больше, чем должно, при большом количестве.

 

 

Юридическое лицо покупая товар который по 1.8760 (на сайте это будет 1.88), покупая его в количестве 100 шт, клиент заплатит 187,6 а не 188, тобишь ваше решение помогает только для частных лиц для которых будет круглая цена рассчитана при которой 21% будет давать четкие числа, но для юридического лица все тоже самое выходит  у него цена то снова плавает.

[Xelen]

28.03.2023 в 11:24, lmz сказал:

Юридическое лицо покупая товар который по 1.8760 (на сайте это будет 1.88), покупая его в количестве 100 шт, клиент заплатит 187,6 а не 188, тобишь ваше решение помогает только для частных лиц для которых будет круглая цена рассчитана при которой 21% будет давать четкие числа, но для юридического лица все тоже самое выходит  у него цена то снова плавает.

 

Теперь понятно. Но, фактически 187,6 и есть верная цена. А,  с точки зрения налоговой, будет ошибкой продать за 187,6?

Если нет, то я бы цену без налога выводила до 4 числа после запятой.

Просто иначе не очень ясно, что вам делать.

Проще говоря, в этом случае, вы хотите юридическим продавать 100 штук ровно по 1.88 (с округлением), а физическим по 1.876 (без округления).

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

Я бы выводила юрикам до 4 числа и все.

[lmz]

28.03.2023 в 19:22, Xelen сказал:

 

Теперь понятно. Но, фактически 187,6 и есть верная цена. А,  с точки зрения налоговой, будет ошибкой продать за 187,6?

Если нет, то я бы цену без налога выводила до 4 числа после запятой.

Просто иначе не очень ясно, что вам делать.

Проще говоря, в этом случае, вы хотите юридическим продавать 100 штук ровно по 1.88 (с округлением), а физическим по 1.876 (без округления).

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

Я бы выводила юрикам до 4 числа и все.

 

суть вопроса в том что всегда и везде считалось бы только 2 цифры после запятой, а не 4ре, нам не нужны эти десятые части цента которые портят сумму при множественной покупке и клиент на фронте видит только 2 цифры после запятой (показывать ему 4ре уж очень мусорно выглядят цены), если нам приходит цена из хмла и она там 1.88 без налога то для юридических это ровная цена уже, для частников это будет 2.27 без каких либо хвостов, абсолютно не имеет значения куда эта цена будет округляться в большую сторону или меньшую, главное чтоб цена была ровной при покупке 100 штук 227.00 а не 227,48, сейчас в опенкарте 4 знака после запятой, и из-за этих постоянных хвостов в цене при множественных покупках цены пляшут, это не решается стандартными возможностями опенкарта, и не решается только перебивкой таблиц всех где есть цена с decimal 15,4 на decimal 15,2, скорей всего эта фигня вообще только костылями решается, я находил на официальном форуме ветку еще созданную в 2012 году по этому вопросу, так толком никто там ничего путевого не дал

[Xelen]

31.03.2023 в 00:18, lmz сказал:

 

суть вопроса в том что всегда и везде считалось бы только 2 цифры после запятой, а не 4ре, нам не нужны эти десятые части цента которые портят сумму при множественной покупке и клиент на фронте видит только 2 цифры после запятой (показывать ему 4ре уж очень мусорно выглядят цены), если нам приходит цена из хмла и она там 1.88 без налога то для юридических это ровная цена уже, для частников это будет 2.27 без каких либо хвостов, абсолютно не имеет значения куда эта цена будет округляться в большую сторону или меньшую, главное чтоб цена была ровной при покупке 100 штук 227.00 а не 227,48, сейчас в опенкарте 4 знака после запятой, и из-за этих постоянных хвостов в цене при множественных покупках цены пляшут, это не решается стандартными возможностями опенкарта, и не решается только перебивкой таблиц всех где есть цена с decimal 15,4 на decimal 15,2, скорей всего эта фигня вообще только костылями решается, я находил на официальном форуме ветку еще созданную в 2012 году по этому вопросу, так толком никто там ничего путевого не дал

 

найдете универсальное решение, напишите тут, мне тоже интересно.

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

Поэтому я вам предлагала более простое решение

[bogdan281989]

Не дочитал суть, сообщение удаляю, мое решение не поможет

[chukcha]

тут проблема совсем в другом

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

Если вас не интересует  бух/налог отчетность
то все действия нужно производить с уже округленными суммами


 

[chukcha]

как варинат

tax->calculate

возвращать round($result, 2)

[buslikdrev]

28.03.2023 в 11:24, lmz сказал:

клиент заплатит 187,6 а не 188

Вам жалко 0,4 за оптовую покупку?

[chukcha]

31.03.2023 в 11:56, buslikdrev сказал:

Вам жалко 0,4 за оптовую покупку?

Не.. в основном это начинает колбасит покупателя
который включает калкулятор, а него на 0,4 не сходится.
и.. там же еще есть, что у покупателя есть своя бухгалтерия, которая пересчитает и не будет совпадать по НДС.

[lmz]

31.03.2023 в 11:56, buslikdrev сказал:

Вам жалко 0,4 за оптовую покупку?

 

у нас жалоба пришла от клиента, он купил товар стоимостью 1.8800 (без налога), а с налогом(+21%) он 2.2748, но на фронте цена товару 2.27, ну так вот он купил 25шт товара видя цену 2.27, цена должна быть 56.75 для него, а по факту ему цена вышла 56.87, ну и типа претензия что мы нае**** , и он прав он же видит 2.27, я уже выше писал ты когда придешь в магазин макароны стоят 2.27 и ты купишь 25 пачек, ты что заплатишь что-ли 56.87 или все-таки 56.75, блин а 4 знака после запятой на сайте показывать какой-то реальный бред, отсюда вопрос был чтоб цены были только 2х значение не нужны эти 0.0048 это не деньги, их нельзя заплатить и они портят цену при множественной покупке, нам нужно чтоб все такие округления были только либо 2.27 или 2.28 без разницы главное без этих долей копеек, так то я понимаю что с точки зрения математики * 21% будет именно 2.2748 но таких цен нету нигде, не в одном магазине, это хрень какая-то  да если один товар покупают то пофиг, а вот если магазин по оптовым покупкам увы, но оказалось проблема это реализовать, еще могут посыпаться платежные модули и фиг знает что.

Змінено 31 березня 2023 користувачем lmz

[buslikdrev]

31.03.2023 в 22:27, lmz сказал:

1.8800 (без налога), а с налогом(+21%) он 2.2748, но на фронте цена товару 2.27

Это нужно смотреть в корзине и модуле оформления. Как понимаю там просто отсекает, а не округляет.

Ответ вам дали выше, вам лишь нужно изучить всё это дело и изменить на нужное. Или нанять того, кто посидит подумает, пообщается с вами, напишет модификатор для внесения правок в 30ти местах.