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

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

[blokva]

Цитата:

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

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

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

[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". Или ты что-то другое имеешь в виду?

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

[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

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

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

[Geo]

Цитата:

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

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

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

Цитата:

Сообщение от Raven Melancholic

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

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

[Raven Melancholic]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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