Единицы измерения и настройка пересчета ед.изм.

[kashperuk]

Хотелось бы содать эту тему в свете появившегося интереса к ней со стороны моей персоны.

Итак:
1. Хотелось бы послушать и посмотреть, какие единицы измерения заданы у вас в системе (можно в виде файликов/скриншотов/комментариев)
2. Хотелось бы послушать то же самое про настройки пересчета ед.изм. (здесь очень интересует еще и использование поля "Дополнительное кол-во").
3. Хотелось бы узнать, есть ли что-то в ед.изм., что по вашему мнению можно было бы улучшить, и если да, то что и как.
4. Как вы считаете, интерфейс указания настроек пересчета ед.изм. можно как-то улучшить, чтобы было более понятно, что и во что конвертится, и сколько чего для этого надо? если да, то как

Большое спасибо

[mazzy]

Цитата:

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

здесь очень интересует еще и использование поля "Дополнительное кол-во"

Ох, это большая тема....

Цитата:

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

3. Хотелось бы узнать, есть ли что-то в ед.изм., что по вашему мнению можно было бы улучшить, и если да, то что и как.

1.
Пересчет в зависимости от складской аналитики.
например, сыпучие материалы - пересчет тонны/кубометры сильно зависит от характеристик партии.

2.
Пересчет в зависимости от внешних условий.
Например, бензин - пересчет тонны/литры сильно зависит не только от партии, но и от температуры.
С трудом понимаю как это сделать более-менее вменяемо. Те варианты, которые видел на проектах совершенно невменяемы при возвратах, коррекциях, пересчетах себестоимости.

Цитата:

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

4. Как вы считаете, интерфейс указания настроек пересчета ед.изм. можно как-то улучшить, чтобы было более понятно, что и во что конвертится, и сколько чего для этого надо? если да, то как

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

[Vals]

Цитата:

1. Хотелось бы послушать и посмотреть, какие единицы измерения заданы у вас в системе (можно в виде файликов/скриншотов/комментариев)

Есть ОКЕИ - Общероссийский классификатор единиц измерения - стандарт на применение и обозначение единиц измерения.

[blokva]

Цитата:

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

...
2.
Пересчет в зависимости от внешних условий.
...

Не только от внешних но и от внутренних, например древесина (да и не только), вернее ее объем, как основная ЕИ сильно зависит от собственной влажности.
Можно сказать, что ЕИ должны иметь воможность пересчета в зависимости от физических характеристик, как самого материала, так и окружающей среды. Кстати набор этих характеристик можно задавать отдельной складской аналитикой, поэтому предложение mazzy выглядит достаточно перспективным.

[kashperuk]

Спасибо за комментарии, попробую их донести до нужных людей.
Все таки еще раз хотелось бы сделать ударение на вопросе №1.

Кто использует "Доп. кол-во"? Если да, то для чего?
Кто указывает температуры в ед.изм? Покажите, как именно
Покажите, как именно указыаете перевод метрических единиц.

Кто-то настраивает это с помощью мастера? Или он бесполезен? Или наоборот, все настраивают ед.изм. только с помощью мастера?
Спасибо

[kashperuk]

Какая запись кажется вам более корректной и почему?

1/1000 * x [mm] = y [m]     vs   mm * 1000 = m
9/5 * x + 32 [C] = y [F]    vs   f * 9/5 + 32 = c

[egorych]

Цитата:

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

Какая запись кажется вам более корректной и почему?

1/1000 * x [mm] = y [m]     vs   mm * 1000 = m

А тут ничего не напутано?
ИМХО умножение всегда предпочтительней - деление часто вносит неточность в зависимости от хрен знает чего!

[Atar]

Цитата:

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

Какая запись кажется вам более корректной и почему?

1/1000 * x [mm] = y [m]     vs   mm * 1000 = m
9/5 * x + 32 [C] = y [F]    vs   f * 9/5 + 32 = c

Более корректным кажется:

Цитата:

m = mm * 1000 или m = 1000 * mm

и

Цитата:

y[F] = 9/5 * x + 32[C]

Так оно со школы привычнее, особенно первое

[EVGL]

Цитата:

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

Ох, это большая тема....
1.
Пересчет в зависимости от складской аналитики.
например, сыпучие материалы - пересчет тонны/кубометры сильно зависит от характеристик партии.

Присоединяюсь двумя руками! Мы для вертикального решения сделали зависимость от конфигурации по всей системе, пришлось дополнить до 200 вызовов UnitConvert::qty() и UnitConvert::value(). Зависимость от партии, полагаю, будет сделать безумно сложно: она известна совсем не везде, в расчет спецификации номер партии не "проникает". К сожалению, зависимость от аналитики нельзя сделать "по чуть-чуть": либо та или иная аналитика учитывается всегда и везде, во всех удаленных уголках системы, включая сводное планирование и ЕС-овский "Интрастат", либо пересчету единиц становится нельзя доверять.

"Доп. кол-во", как правило, бесполезно, поэтому комментировать не буду (у нас пока было немного клиентов, которым нужны Фаренгейты). Мастер - бесполезен. Улучшение интерфейса - бесполезно.



А вообще - обращайтесь, если что. Эти единицы измерения - моя любимая тема стала. Как, например, насчет того, что при коэффициенте пересчета порядка 1 E(-16) на точность начинает влиять (не лучшим образом) внутреннее представление вещественных чисел Аксапты? В результате встроил в пересчет единиц постоянный множитель, чтобы сдвинуть все маленькие вещественные коэффициенты "влево".

Как насчет того, что для интеграции с внешними системами приходится конвертировать единицы измерения и использовать для этого "внешние коды" в Аксапте? Если Вы попробуете настроить это, то с удивлением обнаружите, что можно сделать соответствие только 1:1, а 1:N настроить уже не получится. Например: "kg" в AX -> "kg" внешний, а также "кг" в AX -> "kg" внешний. Второе соответствие (синоним) настроить уже не удастся.

Как насчет зависимых от языка кодов единиц, чтобы для единицы "001" на сербском счете печаталось "кг", а на английском - "kg"?

[gigz]

спасибо за развернутый ответ

интересно замечание про внешние коды. я так понял что, проблема в том, что не поддерживается "внешние коды 1:N единицы измерения", а не наоборот. если это так, то в каком сценарии это может понадобиться?

[EVGL]

Цитата:

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

спасибо за развернутый ответ

интересно замечание про внешние коды. я так понял что, проблема в том, что не поддерживается "внешние коды 1:N единицы измерения", а не наоборот. если это так, то в каком сценарии это может понадобиться?

Сценарий: в штаб-квартире, собирающей электронные отчеты, есть короткий "нормализованный" список единиц. На отдельном заводе есть экзотические единицы "Бобина" и "Рулон". Им обеим соответствует "Рулон" в штаб-квартире. Завод противится введению укороченного справочника единиц, поскольку они видят определенные отличия "бобины" от "рулона" на своем предприятии и требуют конкретизации.

Проблема технически решается элементарно: индекс \Data Dictionary\Tables\ExtCodeValueTable\Indexes\ExtCodeIdx разбавляется полем ExtCodeValueAlias, редактирование самого поля разрешается (на кой ляд оно вообще нужно, если содержит всегда то же самое, что и ExtCodeValue ?!).

[petr]

Цитата:

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

Как насчет зависимых от языка кодов единиц, чтобы для единицы "001" на сербском счете печаталось "кг", а на английском - "kg"?

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

[EVGL]

Цитата:

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

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

И то верно, был неправ. Действительно, в поле описания можно забить полные названия на всех доступных языках, покуда хватит места, а в текстах сохранять переведенные коды.

[Vals]

Цитата:

полные названия на всех доступных языках

В единицах измерения есть интересное поле, которым мало кто пользуется, а в большинстве случаев пренебрегают - Код по ОКЕИ (Сейчас обратил внимание, что оно соответствует конф. ключу Россия).
В справочниках единиц измерения, каждой единице сопоставляется цифровой код. Используется он для однозначной трактовки ЕИ в разных странах и т.д.

P.S. Кстати, а почему в таблице не отображается поле UnitSystem (Метрическая, Англо-американская, Обе), а по умолчанию стоит метрическая?
Поделитесь, что на него завязано?

[EVGL]

Очевидно, поле используется в мастере для первоначальной настройки. И все.

Что касается "кода по ОКЕИ", то использовать его для разных стран нельзя по той причине, которую Вы указали: конф. ключ и только восточноевропейское приложение. В 2009 EE можно, правда, рискнуть: включить русский ключ и выключить все русские параметры, чтобы, типа, были все русские преимущества и никаких русских недостатков.

[Logger]

Цитата:

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

Как, например, насчет того, что при коэффициенте пересчета порядка 1 E(-16) на точность начинает влиять (не лучшим образом) внутреннее представление вещественных чисел Аксапты?

Это что же вы такое считаете что такие коэффициенты лезут ???

Кстати, по поводу внутреннего представления. С появлением в X++ типа int64 мы поимели целочисленный тип, который не влезает в аксаптовский real - как-то это непривычно выглядит. Обычно привыкаешь, что целый тип заведомо должен влезать в вещественный. Может real тоже имеет смысл расширить в будущих версиях Аксапты ?

[EVGL]

Цитата:

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

Это что же вы такое считаете что такие коэффициенты лезут ???

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

Вот мои изыскания 3-х летней давности:

Цитата:

Axapta speichert alle numerische Daten in Feldern vom Typ „,numeric(28, 12)“ in der SQL-Datenbank. D.h. eine Zahl kann nur mit maximal 12 Nachkommastellen gespeichert werden. Die interne Darstellung von Axapta erlaubt angeblich 16 Dezimalstellen jeglicher Art.

Vorschlag: ein globaler Parameter (Multiplikator) im DAX, so dass alle Faktoren in der Form
Faktor * Multiplikator gespeichert werden können. (Natürlich lassen sich alle Umrechnungsfaktoren automatisiert neu aufbauen.)

Beispiel:
30 000 m = 1 Rolle
Faktor (Axapta) = 0,000033333333|3333333
Multiplikator = 1000000
Faktor (gespeichert) = 3,333333333333

Прошу прощения за автоматизированный перевод, лень мозги напрягать:

Цитата:

Axapta сохраняет все данные в числовых полей типа "numeric(28, 12)" в базе данных SQL. То есть ряд можно только до 12 десятичных знаков хранятся. Внутреннее представление Axapta якобы позволили 16 десятичных знаков в какой бы то ни было

Предложение: глобальный параметр (множитель) в DAX, с тем, что все факторы, в виде
* Множителя может быть сохранен. (Конечно, все коэффициенты автоматизированной восстановить.)

Пример:
30 000 м = 1 рулон
Фактор (Axapta) = 0,000033333333|3333333
Multiplier = 1000000
Фактор (хранится) = 3,333333333333

Ок, я уже сам забыл: речь идет даже не о 16, а о том, что из 16 как минимум 4 знака на SQL съедаются сразу. Итоговая точность может быть и того меньше в зависимости от исходных данных (см. пример выше - от периодической дроби осталось только 8 значащих мест в мантиссе).

Проверил в 2009 - все то же самое: numeric(28, 12).

См. также Real Data Type - No of decimals

[Geo]

Цитата:

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

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

Имхо надо сделать возможность использования единиц измерения в складских операциях (делается-то просто, вроде бы), и тогда внешние условия можно учитывать созданием единиц, эти условия учитывающих. Скажем, приходовать бензин в "Литр 25 градусов", а расходовать с того же склада - в "Литр -30 градусов". Можно попроще: "Литр летний", "Литр зимний". При этом, конечно, эти литры будут специфичны для номенклатуры - бензина.
Мне кажется, разброс параметров номенклатуры на практике вряд ли будет столь велик, чтобы создать проблемы с излишне большим числом единиц измерения и пересчетов между ними.

[EVGL]

Цитата:

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

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

Не больше, чем разброс рациональных чисел от нуля до единицы.

[Raven Melancholic]

Цитата:

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

Имхо надо сделать возможность использования единиц измерения в складских операциях (делается-то просто, вроде бы)

Если бы вендор сделал это (или как вариант, возможность пересчета хотя бы по номенклатурным аналитикам - по складским понятно, что это непросто и неоднозначно), то было бы неплохо. Самим делать модификацию не так просто (точнее даже непросто не саму модификацию делать, а поддерживать в дальнейшем сервис паки и переходы на другие версии).
В свое время (у нас была еще Ax3.0 SP2), оценивали объем модификаций для пересчета в зависимости от номенклатурных аналитик. Получилось, что нужно модифицировать около 140 мест, причем это прямые вызовы пересчета, кроме них в полутора десятках мест нет аналитики, её пришлось бы протягивать через несколько вызовов.

Цитата:

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

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

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

Цитата:

Не больше, чем разброс рациональных чисел от нуля до единицы.

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