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

[IKA]

На осн ед. изм товара можно указать количество цифр после запятой.

Мы собираемся во всю использовать этот функционал (нужно округлять до 5 знаков)
На сколько он надежно работает?
На первый взгляд пока проблем не замечено, но Оч боюсь, что где-нибудь потом обнаружится баг, что в где-нибудь в стандартных пересчетах результаты случайно до 2 позиций округляются, и тогда округление до 5 в других местах потеряет смысл.

AX2009

[mazzy]

с количеством сложностей вроде нет
сложности начинаются, если ваши дробные единицы имеют стоимость/цену меньше копейки. в финансах начинаются "необъяснимые" для бухгалтерии явления. прежде вего в СФ и накладной.

[gl00mie]

Цитата:

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

На осн ед. изм товара можно указать количество цифр после запятой. Мы собираемся во всю использовать этот функционал (нужно округлять до 5 знаков)

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

Цитата:

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

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

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

[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 коробки, заведите две строки. Не подходит?

Цитата:

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

[mnt_dx]

IKA, а разве можно в накладной писать 1.2 - это не соответствует единице измерения "Коробка", это будет "1 коробка 2 штуки". Например, на услуги пишут 1.5 часа, а не 1.30.

[IKA]

Именно так тут в накладной и пишут. Есть две колонки : упаковки и коробки.
В данном случае будет: продано: 1 упаковка и 2 коробки, а не 1.33333(3) упаковки

[Raven Melancholic]

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

• В первую очередь, стоит узнать, в каких единицах измерения представлен прайс?
• Отличается ли прайс для коробок и для упаковок?
• В каких единицах заказывают покупателя?
• Заказывают ли они Х коробок и У упаковок?

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

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

ИМХО, проще в какой-нибудь форме типа "Создание строк заказа" сделать две колонки - "Коробки" и "Упаковки", а далее пусть система сама создаст ДВЕ строки: первая - на коробки, вторая - на упаковки.

[Maxim Gorbunov]

Ок. Тогда представьте следующую ситуацию.

Допустим, в упаковке у вас 10 коробок. Предположим, что было два прихода: первый из 1 упаковки и 3 коробок, а второй из 1 упаковки и 8 коробок. Тогда в InventSum у вас будет храниться 3.1, то есть 3 упаковки и 1 коробка, что, очевидно, не соответствует реальному количеству на складе, которое равно 2 упаковкам и 11 коробкам.

Кстати, заметьте относительно вашего примера про футы и дюймы, что в системах длина обычно хранится именно как 42 дюйма и лишь для отображения переводится в 3'7".

[IKA]

Количество коробок в упаковке не меняется у товара.
Если товар по-другому расфасован, то считается другим товаром.

[S.Kuskov]

Цитата:

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

Количество коробок в упаковке не меняется у товара.
Если товар по-другому расфасован, то считается другим товаром.

Maxim Gorbunov написал о другом. Он акцентировад ваше внимание и внимание участников дискуссии на то, что в вашем учёте 1 упаковка из 10 коробок никак не отличается от 10 коробок россыпью. Т.е. анализируя свои складские остатки, вы не можете сказать сколько у вас целых упаковок, а сколько начатых, вы можете только сосчитать общее количество коробок и прикинуть сколько это будет в упаковках.

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

[Maxim Gorbunov]

Цитата:

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

Количество коробок в упаковке не меняется у товара.
Если товар по-другому расфасован, то считается другим товаром.

Вы, наверное, ещё собираетесь написать, что закупаете товар только упаковками, а не отдельными коробками. Но задумайтесь о том, что приход - это не только закупка. Приходом также является и возврат из заказа, и излишки при инвентаризации.