Алгоритм расчета общей суммы

[kashperuk]

Граждане форумчане,

Помогите составить алгоритм рассчета общей суммы.
Вкратце опишу проблему на примере:

Формируется отчет, в котором выводятся строки документа с указанием кол-ва, цены и суммы по строке. По этим суммам рассчитывается итоговая сумма документа.
Фиксированно кол-во по строке и исходная сумма (в отчет не попадает).
Все суммы округляются до 2ого знака после запятой.

Цена (расчетная) рассчитывается как Сумма (исходная) / Кол-во
Сумма (расчетная) рассчитывается как Цена (расчетная) * Кол-во

Пример:


Итого, 9 копеек разницы.

Необходимо:
Менять цену так, чтобы свести к минимуму расхождение общей суммы.

[EVGL]

Цифры 3.34 и 6.63 заранее известны?
Если да, то сравнивайте расчетную и исходную накопленные суммы по каждой строке:

Delta1 = 3,34 - decRound(3,34/10, 2) = 3,34 - 3,30 = 0,04
decRound(Delta1/10, 2) = decRound(0,004, 2) = 0 => коррекция невозможна

Delta2 = 3,34 + 6,63 - 3,30 - 6,60 = 0,07
decRound(Delta2/10, 2) = decRound(0,007, 2) = 0,01 => коррекция = +0,01 => цена = 0,67

[kashperuk]

Quote:

Originally Posted by EVGL

Цифры 3.34 и 6.63 заранее известны?

Да, конечно.
Известно кол-во по строке, правильная (до округления) сумма по строке, и, соответственно, правильная (без округления) общая сумма.

[EVGL]

Тогда см. предыдущий пост. Возможно, надо будет еще обработку последней строки вставить, чтобы оставшаяся ошибка включалась в последнюю расчетную сумму (если это возможно, что последняя "Сумма расчетная" != "Цена расчетная" * "Количество").

Проще говоря:
10 ----- 0,67 ----- 6,67 (!= 6,70) ----- 6,63

[petr]

Quote:

Менять цену так, чтобы свести к минимуму расхождение общей суммы.

А что это значит? Вы имеете ввиду, что в первом случае цена расчетная 0,33 но вы будете выводить в отчет 0,34 чтобы потом при расчете суммы (расчетной) получалось 3,4 а в общей сумме 10, что ближе к 9,97 чем 9,9?

[kashperuk]

Да. То есть разница между 10.00 и 9.97 будет уже 0.03, а не 0.07.
То есть пытаемся уменьшить общее отклонение итоговой суммы

[mazzy]

Quote:

Originally Posted by kashperuk

Формируется отчет, в котором выводятся строки документа с указанием кол-ва, цены и суммы по строке. По этим суммам рассчитывается итоговая сумма документа.

...

Итого, 9 копеек разницы.

По-моему, уже сказали. Но еще раз:
суммы всегда храняться с большим числом знаков.
суммы всегда отображаются в отчете с округлением.

Рассчитывать итоговую сумму по НЕОРУГЛЕННЫМ суммам - большая методическая ошибка.
Перед выводом, перед записью в БД, любая сумма должна быть округлена при помощи Currency::amount(...) или Currency::amountCur(...). Это правило.

Кстати, любое количество также должно быть округлено перед выводом и перед записью в БД.

[EVGL]

Тот алгоритм, который я описал, используется в русской книге продаж в случае "НДС по оплате" с несколькими оплатами к одной накладной. Нетрудно видеть, что ошибка в моем алгоритме <= 0,01 * Среднее_количество_по_строке ~ 0,10 в вашем случае.

[petr]

Ну тогда вам в математический справочник. Идея, насколько я помню такая:
У вас есть числа A1, A2, An (в вашем примере это 3,34 и 6,63). Вам надо найти такие числа B1, B2, Bn (в вашем случае это сумма округлвения), чтобы выполнялось два условия. 1-ое условие: (А1/Х1 - В1)*100 - целое число. (Х1 - это кол-во для первой строки 10). Второе условие: Сумма (В1*Х1 + В2*Х2 + Вn*Хn) - (А1 + А2 + Аn) стремиться к нулю (причем по модулю). Т.е. задача на минимизацию. Я думаю такие задачи решаютмя в численных методах, или может еще в каком разделе математики.

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

[EVGL]

Quote:

Originally Posted by mazzy

По-моему, уже сказали. Но еще раз:
суммы всегда храняться с большим числом знаков.
суммы всегда отображаются в отчете с округлением.

Рассчитывать итоговую сумму по НЕОРУГЛЕННЫМ суммам - большая методическая ошибка.
Перед выводом, перед записью в БД, любая сумма должна быть округлена при помощи Currency::amount(...) или Currency::amountCur(...). Это правило.

Кстати, любое количество также должно быть округлено перед выводом и перед записью в БД.

Это Вы к чему, собственно говоря? У Ивана не только все суммы, а все цены до второго знака округлены. В этом и проблема.

[mazzy]

Quote:

Originally Posted by kashperuk

Известно кол-во по строке, правильная (до округления) сумма по строке, и, соответственно, правильная (без округления) общая сумма.

Quote:

Originally Posted by EVGL

У Ивана не только все суммы, а все цены до второго знака округлены.

Разве?

[EVGL]

Quote:

Originally Posted by mazzy

Разве?

А что, не заметно, что везде два знака после запятой?
Задача-то типовая: восстановить цену по сумме.

[kashperuk]

Вот немного усложненный пример, на котором можно думать



Расхождение в этом случае = 11.29

2 mazzy:
Да оно так и хранится.
Проблема в том, что цены округлены до второго знака тоже.
и бухгалтерия не хочет видеть более 2 знаков в цене.
А соответственно возникают расхождения.

P.S. Именно, EVGL правильно говорит

[Михаил Андреев]

Quote:

Originally Posted by kashperuk

Проблема в том, что цены округлены до второго знака тоже.
и бухгалтерия не хочет видеть более 2 знаков в цене.

Чего? А почему не до целых гривен?
Посмотрите настройку валюты на закладке Округление. Обычно достаточно там настроить: цены округлять до сотой доли единицы валюты и т.д.
Или, речь о закупках?
Откуда такая забавная задачка?

[petr]

to Михаил Андреев, mazzy
Да вполне нормальная задача. Посмотрите как получаются отклонения в основной валюте, это практически тоже самое. Только там никто разницу не оптимизирует, а просто она кидается на счет расхождений в основной валюте и все.

А kashperuk хочет в своем отчете эту разницу немного оптимизировать, т.е. уменьшить

[mazzy]

Quote:

Originally Posted by EVGL

А что, не заметно, что везде два знака после запятой?
Задача-то типовая: восстановить цену по сумме.

В том то и дело, что ВИДНО.
Не факт, что так и ХРАНИТСЯ.
Аксапта всегда ПОКАЗЫВАЕТ округленные суммы, а ХРАНИТ как записал программист.

Quote:

Originally Posted by kashperuk

Да оно так и хранится.

Точно-точно?

Quote:

Originally Posted by kashperuk

и бухгалтерия не хочет видеть более 2 знаков в цене.

Ну и пусть ВИДИТ!

Если же вопрос не о представлении, а о ХРАНЕНИИ.
У цен свое правило округления задается в параметрах валют.
У цен свой тип, для которого можно настроить свое количество знаков после запятой.

Но тогда у бухов будет расхождение с контрагентами, которые работают с двумя знаками после запятой в цене

Если цена округляется, то согласен с EVGL, будут нестыковки либо в цене каждой строчки, либо в общем НДСе в зависимости от того, в каком направлении будет выполняться расчет (от цены к общей сумме или от общей суммы к цене)

[EVGL]

Мой вариант: 0.33 --- 0.67 --- 0.23 --- 2.10 => 271.50. Да, хреново.
0.33 --- 0.67 --- 0.24 --- 2.05 => 280.75 гораздо лучше.

[EVGL]

Самый тупой вариант - это на каждом шаге попробовать изменить цену на -0,01 и +0,01 соответственно, посмотреть, что будет. Т.е. порядка 2^(количество_строк -1) итераций.

[kashperuk]

Есть, кстати, еще одно условие, усложняющее в значительной мере алгоритм
Цена не должна уменьшаться/увеличиваться более, чем на 10% от своего начального значения.

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

Спасибо всем за участие. Продолжение следует...

[petr]

Quote:

Спасибо всем за участие.

Я думаю, что спасибом тут не отделаться. Надо будет выложить получившийся алгоритм.