Округление до 5 позиций в ед.изм

[Maxim Gorbunov]

Цитата:

Сообщение от IKA

Сейчас это так и реализовано . что когда пользовватель вводит 1.2, то это кол-во пересчитывается в кол-во упаковок и получается 1.33(3), кот попадает в стд поле аксапты Qty(например, на в строках заказа).

А в InventSum у вас что хранится? 1.33? Или всё же есть отдельные поля для упаковок и коробок?

[IKA]

На данный момент 1.33(3).
Точней, 1.33333, тк на Unit большинства номенклатур установлено округление до 5 знаков + поле(display method), кот переводит это в Упаковки/Коробки .
Метод основан на том, что при определенной точности округления , зная возможный максимум коробок в упаковке(например, товаров с больше 100 коробок в упаковке не бывает), можно из получаемого real установить точное целое количество упаковок и коробок.
т.е по сути: если наше число x, то это результат округления до 5 любого числа в диапазоне от x-0.000005 до x+ 0.000005.(отбросим целую часть, тк с ней все ясно, это целое кол-во упаковок) Соответственно, нужно, чтобы неравенству: x-0.000005 <= y/(количество корВУпак) < x+ 0.000005 не могло удовлетворять два целых y. То есть 1<(0.00001)*(количество корВУпак). Отсюда уже выводим сколько нужно знаков после запятой(в примере выше было 5) при заданном количестве корВУпак.

Проблема только в том. что из-за многочисленных пересчетов могут накапливаться погрешности, что также на данный момент неплохо нивелируется большой точностью. Именно поэтому важно, чтобы стандартный функционал поддержки округления, установленный для Unit, работал, т.е нигде "случайно" не обрезались данные. И именно поэтому я создала этот топик.

Мне кажется. что добавлять везде в системе дополнительно 2 поля чревато. То есть просто для сохранения историч данных это хорошо, но полагаться на их значения невозможно, тк можно легко упустить инициализацию поля в ком-нить стд куске кода, что скажется потом и на InventSum в том числе..

[ALES]

Цитата:

Сообщение от IKA

(отбросим целую часть, тк с ней все ясно, это целое кол-во упаковок)

Отсюда следует ,что единица учета коробка т.к. если продать из двух упаковок (60 коробок) по 30 коробок из каждой, физически будет ноль целых упаковок и 60 коробок, а не одна целая упаковка =).

Цитата:

Сообщение от ALES

Отсюда следует ,что единица учета коробка т.к. если продать из двух упаковок (60 коробок) по 30 коробок из каждой, физически будет ноль целых упаковок и 60 коробок, а не одна целая упаковка =).

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