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

[Ivanhoe]

Присоединюсь, проблем будет много. Причем "в одном месте" это так просто не поправишь.

[IKA]

Бизнес построен таким образом. что большинство товара состоит из упаковок, которые состоят из коробок поменьше. Поэтому по каждой номенклатуре указывается сколько коробок у упаковке.
Например, если упаковка Товара1 состоит из 6 коробок и продали 1 упаковку и 2 коробки, то пользователь должен вводить 1.2 , а не 1.33.
Сейчас это так и реализовано . что когда пользовватель вводит 1.2, то это кол-во пересчитывается в кол-во упаковок и получается 1.33(3), кот попадает в стд поле аксапты Qty(например, на в строках заказа).
Ест-но возникают тут же проблемы с округлением, кот решено нивелировать количеством знаков после запятой. В текущей системе(кот до аксы была) использовалось округление до 5 и "работало хорошо".
Меня последствия беспокоят.
Не думаю, что требование такое уж редкое, поэтому, если есть проверенные практикой варианты реализации, расскажите.

[S.Kuskov]

Цитата:

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

Например, если упаковка Товара1 состоит из 6 коробок и продали 1 упаковку и 2 коробки, то пользователь должен вводить 1.2 , а не 1.33.

У вас не десятичная система счисления?

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

[IKA]

Цитата:

Сообщение от S.Kuskov

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

Нет, тк если продали 15 упаковок и 2 коробки, то всем понятно, что продали. А 92 (=15*6+2) коробки - не имеет смысла ни для работников склада ни для клиентов компании.

Причем, 6 - это только один из примеров. Тут в ходу также упаковки по 12 коробок внутри , по 60, по 15 и тд. Теперь продать если: 15 упаковок(по 12) и 7 коробок превратятся превратятся в 187.

[S.Kuskov]

Цитата:

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

Нет, тк если продали 15 упаковок и 2 коробки, то всем понятно, что продали. А 92 (=15*6+2) коробки - не имеет смысла ни для работников склада ни для клиентов компании.

Так продавать (впрочем как и покупать) можно не обязательно в складских еденицах измерения. Заводите в заказы строки в "удобных для человека" еденицах измерения, а складские проводки будут создаваться в еденицах измерения "удобных для системы".

Если продали 15 упаковок и 2 коробки, заведите две строки. Не подходит?

[mnt_dx]

Цитата:

Сообщение от S.Kuskov

Если продали 15 упаковок и 2 коробки, заведите две строки. Не подходит?

+1

[ice]

Цитата:

Сообщение от S.Kuskov

Так продавать (впрочем как и покупать) можно не обязательно в складских еденицах измерения. Заводите в заказы строки в "удобных для человека" еденицах измерения, а складские проводки будут создаваться в еденицах измерения "удобных для системы".

Если продали 15 упаковок и 2 коробки, заведите две строки. Не подходит?

скорее всего так было в старой системе вот и перенесли 1 в 1 в Ax, потому что переубедить не смогли

[IKA]

Я вполне понимаю, почему не смогли переубедить.
Вы же не вводите 1.7 кг как две строки(одну на1 кг, вторую в 700гр).

Собственно, для пользователя, что в 1 кг - 1000гр то же самое , что в 1 упаковке - 12 коробок.
Или вот еще пример:
Если в 1 футе - 12 дюймов и продали кусок материи длиной в 3фута и 7 дюймов, это в аксапте тоже как 2 строки заказа вводить? Как если бы мы 2 куска материи продавали один длиной в 3 фута и один в 7 дюймов??? Абсурд. И на складе уж тем более никто не поймет, что такое 3.583 фута(=3' 7") и как их отрезать! Собственно, как и 42 дюйма(=3' 7") не имеют практич смысла.

Цитата:

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

Например, если упаковка Товара1 состоит из 6 коробок и продали 1 упаковку и 2 коробки, то пользователь должен вводить 1.2 , а не 1.33.

А если упаковка состоит из 30 коробок и продали 1 упаковку и 20 коробок, то пользователь должен вводить 1.20.
При этом система упорно не различает 1.2 и 1.20.
Нехорошая, негодная система.

Хотя, если подумать и вводить число в строковое поле, а потом разбирать, то можно отличить 1.2 и 1.20. Шутка удалась лишь наполовину (

[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 коробок, а не одна целая упаковка =).

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