AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 04.09.2007, 15:14   #1  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
Алгоритм расчета общей суммы
Граждане форумчане,

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

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

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

Пример:


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

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

Последний раз редактировалось kashperuk; 04.09.2007 в 15:18. Причина: картинку вставил
За это сообщение автора поблагодарили: petr (2).
Старый 04.09.2007, 15:20   #2  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цифры 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

Последний раз редактировалось EVGL; 04.09.2007 в 15:27.
Старый 04.09.2007, 15:21   #3  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
Цитата:
Сообщение от EVGL Посмотреть сообщение
Цифры 3.34 и 6.63 заранее известны?
Да, конечно.
Известно кол-во по строке, правильная (до округления) сумма по строке, и, соответственно, правильная (без округления) общая сумма.
Старый 04.09.2007, 15:32   #4  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Тогда см. предыдущий пост. Возможно, надо будет еще обработку последней строки вставить, чтобы оставшаяся ошибка включалась в последнюю расчетную сумму (если это возможно, что последняя "Сумма расчетная" != "Цена расчетная" * "Количество").

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

Последний раз редактировалось EVGL; 04.09.2007 в 15:35.
Старый 04.09.2007, 16:02   #5  
petr is offline
petr
Участник
Соотечественники
 
557 / 201 (8) ++++++
Регистрация: 30.05.2005
Адрес: Швейцария
Цитата:
Менять цену так, чтобы свести к минимуму расхождение общей суммы.
А что это значит? Вы имеете ввиду, что в первом случае цена расчетная 0,33 но вы будете выводить в отчет 0,34 чтобы потом при расчете суммы (расчетной) получалось 3,4 а в общей сумме 10, что ближе к 9,97 чем 9,9?
Старый 04.09.2007, 16:06   #6  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
Да. То есть разница между 10.00 и 9.97 будет уже 0.03, а не 0.07.
То есть пытаемся уменьшить общее отклонение итоговой суммы
Старый 04.09.2007, 16:13   #7  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от kashperuk Посмотреть сообщение
Формируется отчет, в котором выводятся строки документа с указанием кол-ва, цены и суммы по строке. По этим суммам рассчитывается итоговая сумма документа.

...

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

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

Кстати, любое количество также должно быть округлено перед выводом и перед записью в БД.
__________________
полезное на axForum, github, vk, coub.
Старый 04.09.2007, 16:17   #8  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Тот алгоритм, который я описал, используется в русской книге продаж в случае "НДС по оплате" с несколькими оплатами к одной накладной. Нетрудно видеть, что ошибка в моем алгоритме <= 0,01 * Среднее_количество_по_строке ~ 0,10 в вашем случае.
Старый 04.09.2007, 16:18   #9  
petr is offline
petr
Участник
Соотечественники
 
557 / 201 (8) ++++++
Регистрация: 30.05.2005
Адрес: Швейцария
Ну тогда вам в математический справочник. Идея, насколько я помню такая:
У вас есть числа 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) стремиться к нулю (причем по модулю). Т.е. задача на минимизацию. Я думаю такие задачи решаютмя в численных методах, или может еще в каком разделе математики.

Подумаю вечерком, может что сам еще вспомню, но тут скорее надо литературу по этой теме искать или знакомых математиков трясти.
За это сообщение автора поблагодарили: kashperuk (3).
Старый 04.09.2007, 16:19   #10  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от mazzy Посмотреть сообщение
По-моему, уже сказали. Но еще раз:
суммы всегда храняться с большим числом знаков.
суммы всегда отображаются в отчете с округлением.

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

Кстати, любое количество также должно быть округлено перед выводом и перед записью в БД.
Это Вы к чему, собственно говоря? У Ивана не только все суммы, а все цены до второго знака округлены. В этом и проблема.
Старый 04.09.2007, 16:21   #11  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от kashperuk Посмотреть сообщение
Известно кол-во по строке, правильная (до округления) сумма по строке, и, соответственно, правильная (без округления) общая сумма.
Цитата:
Сообщение от EVGL Посмотреть сообщение
У Ивана не только все суммы, а все цены до второго знака округлены.
Разве?
__________________
полезное на axForum, github, vk, coub.
Старый 04.09.2007, 16:23   #12  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от mazzy Посмотреть сообщение
Разве?
А что, не заметно, что везде два знака после запятой?
Задача-то типовая: восстановить цену по сумме.
Старый 04.09.2007, 16:24   #13  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
Вот немного усложненный пример, на котором можно думать



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

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

P.S. Именно, EVGL правильно говорит
Миниатюры
Нажмите на изображение для увеличения
Название: example2.PNG
Просмотров: 793
Размер:	7.0 Кб
ID:	2913  
Старый 04.09.2007, 16:30   #14  
Михаил Андреев is offline
Михаил Андреев
Участник
Компания АМАНД
Лучший по профессии 2009
 
1,284 / 239 (10) ++++++
Регистрация: 09.11.2001
Адрес: Химки, Московская область
Цитата:
Сообщение от kashperuk Посмотреть сообщение
Проблема в том, что цены округлены до второго знака тоже.
и бухгалтерия не хочет видеть более 2 знаков в цене.
Чего? А почему не до целых гривен?
Посмотрите настройку валюты на закладке Округление. Обычно достаточно там настроить: цены округлять до сотой доли единицы валюты и т.д.
Или, речь о закупках?
Откуда такая забавная задачка?
__________________
Михаил Андреев
https://www.amand.ru
Старый 04.09.2007, 16:33   #15  
petr is offline
petr
Участник
Соотечественники
 
557 / 201 (8) ++++++
Регистрация: 30.05.2005
Адрес: Швейцария
to Михаил Андреев, mazzy
Да вполне нормальная задача. Посмотрите как получаются отклонения в основной валюте, это практически тоже самое. Только там никто разницу не оптимизирует, а просто она кидается на счет расхождений в основной валюте и все.

А kashperuk хочет в своем отчете эту разницу немного оптимизировать, т.е. уменьшить
Старый 04.09.2007, 16:33   #16  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от EVGL Посмотреть сообщение
А что, не заметно, что везде два знака после запятой?
Задача-то типовая: восстановить цену по сумме.
В том то и дело, что ВИДНО.
Не факт, что так и ХРАНИТСЯ.
Аксапта всегда ПОКАЗЫВАЕТ округленные суммы, а ХРАНИТ как записал программист.

Цитата:
Сообщение от kashperuk Посмотреть сообщение
Да оно так и хранится.
Точно-точно?

Цитата:
Сообщение от kashperuk Посмотреть сообщение
и бухгалтерия не хочет видеть более 2 знаков в цене.
Ну и пусть ВИДИТ!

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

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

Если цена округляется, то согласен с EVGL, будут нестыковки либо в цене каждой строчки, либо в общем НДСе в зависимости от того, в каком направлении будет выполняться расчет (от цены к общей сумме или от общей суммы к цене)
__________________
полезное на axForum, github, vk, coub.
За это сообщение автора поблагодарили: kashperuk (3).
Старый 04.09.2007, 16:38   #17  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Мой вариант: 0.33 --- 0.67 --- 0.23 --- 2.10 => 271.50. Да, хреново.
0.33 --- 0.67 --- 0.24 --- 2.05 => 280.75 гораздо лучше.
За это сообщение автора поблагодарили: kashperuk (3).
Старый 04.09.2007, 16:43   #18  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Самый тупой вариант - это на каждом шаге попробовать изменить цену на -0,01 и +0,01 соответственно, посмотреть, что будет. Т.е. порядка 2^(количество_строк -1) итераций.
Старый 04.09.2007, 17:11   #19  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
Есть, кстати, еще одно условие, усложняющее в значительной мере алгоритм
Цена не должна уменьшаться/увеличиваться более, чем на 10% от своего начального значения.

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

Спасибо всем за участие. Продолжение следует...
Старый 04.09.2007, 17:17   #20  
petr is offline
petr
Участник
Соотечественники
 
557 / 201 (8) ++++++
Регистрация: 30.05.2005
Адрес: Швейцария
Цитата:
Спасибо всем за участие.
Я думаю, что спасибом тут не отделаться. Надо будет выложить получившийся алгоритм.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Алгоритм расчета отчета весьма сложноват glibs DAX: Прочие вопросы 0 20.03.2009 12:08
Корректировка суммы налога в закупке ymv2000 DAX: Функционал 4 26.10.2006 09:19
!!!HELP!!! ???Проблемы расчета больничного??? rus_stas DAX: Функционал 4 22.02.2005 17:46
Алгоритм расчета З/П nicko DAX: Функционал 2 26.02.2004 08:21
Русская локализация Axapta 3 ? SlavaK DAX: Администрирование 59 01.07.2003 22:38
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 12:19.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.