Количество знаков после запятой для количества в Закупке.

[dimit]

Руководство по логистике: "В поле Десятичные знаки введите количество знаков после запятой, т.е. точность, с которой измеряется количество товара в данных единицах. Впрочем, максимальная точность, с которой Microsoft Business Solutions–Axapta приводит все вещественные параметры в отчетах, запросах и экранных формах – 0.01, поэтому значения поля более 2 отразятся только на точности
внутренних расчетов. Поле Десятичные знаки принимается во внимание при округлении количества в ходе обработки складских проводок, планирования, расчета спецификаций, потребления производства и т.д."

А как быть если пришло 6,386 тонны по цене 1563,23??? В форме и в накладной сумма получается 9989,04 а должна быть 9982,79 Меняем количество знаков после запятой для всех номенклатур? Или у меня просто не работает?

[KiselevSA]

Настройте EDT Qty для работы с определенным количеством знаков после запятой

[Sada]

Здается мне кто-то покапался в коде и гденить поставил округление в большую сторону .

[mazzy]

Цитата:

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

[B]максимальная точность, с которой Microsoft Business Solutions–Axapta приводит все вещественные параметры в отчетах, запросах и экранных формах – 0.01

Нет, это ложное утверждение.

Контрпример - курс задается с 4мя знаками.
Правила округления ФИНАНСОВЫХ показателей задаются при настройке валют
Правила округления КОЛИЧЕСТВЕННЫХ показателей задаются при настройке единиц измерения.

Правила отображения на экране и в отчетах задаются в EDT.

[Deep Dreamer]

Была аналогичная проблема, когда номенклатуру начали считать чуть ли не в миллиметрах...
Лезем в EDT Qty и ставим то количество знаков, которое надо - и больше не паримся - так уж наша умная Аксаптушка устроена, что во всей системе использует Qty и начнёт нормально считать. Только смотрите, чтобы Ваши пользователи штуки не начали половинами считать

[KiselevSA]

И еще на счет суммы: чистую сумму по строке вы можете вести вручную, ту, которая нужна. При этом, конечно, цена по строке в форме закупки исчезнет, но сумма накладной сойдется, да и в проводки попадет корректное значение.

[YaHooka]

Цитата:

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

А как быть если пришло 6,386 тонны по цене 1563,23???

А в кг. нельзя ввести? и ввести общую сумму?

[mazzy]

Цитата:

Сообщение от Deep Dreamer

Только смотрите, чтобы Ваши пользователи штуки не начали половинами считать

Да что ж это такое?
Либо я чего не понимаю, либо одно из двух.

Еще раз:

Цитата:

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

Правила округления КОЛИЧЕСТВЕННЫХ показателей задаются при настройке единиц измерения.

Посмотрите наконец в единицы измерения.

[AlexArh]

mazzy
Задаются-то они, задаются. Только на что это влияет?

Пример: Axapta 3 SP5 FP2. Демо база.
1. Добавляется новая единица измерения - тонна, кол-во десятичных знаков - 3. Новая единица измерения назначается "по умолчанию" номенклатуре "Шуруп 13 мм"
2. Для этой номенклатуры оформляется закупка, в строке которой указывается кол-во 6,386 т. То что на экране мы вместо 6,386 видим 6,39 уже неприятно, хотя и не смертельно.
3. Указываем цену 1563,23 р/т
4. Получаем читстую сумму 6,39 * 1563,23 = 9989,04 вместо 6,386 * 1563,23 = 9982,79

В чем тогда смысл того, что мы указали эти 3 знака? Или нужна какая-то дополнительная настройка?

[mazzy]

Цитата:

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

mazzy
Задаются-то они, задаются. Только на что это влияет?

Боже... Вы читать умеете?
Способ представления от способа хранения отличаете?

Цитирую сам себя:

Цитата:

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

Правила округления ФИНАНСОВЫХ показателей задаются при настройке валют
Правила округления КОЛИЧЕСТВЕННЫХ показателей задаются при настройке единиц измерения.
Правила отображения на экране и в отчетах задаются в EDT.

Установите 3 знака и посмотрите в базу любой неаксаптовской смотрелкой (Аксапта всегда будет применять правило ОТОБРАЖЕНИЯ на экране)

[AlexArh]

mazzy
Не кипятитесь, пожалуйста. Читать я умею.
В том-то и дело, что чистая сумма не ОТОБРАЖАЕТСЯ, а РАСЧИТЫВАЕТСЯ исходя из количества, округленного до 2-ух знаков. И по большому счету, мне без разницы как именно Axapta хранит информацию - мне нужен правильный результат. А в данном случае при печати счета, накладной и др. документов выводиться сумма, РАССЧИТАННАЯ от 2-ух знаков в количестве.

PS.
Кажется разобрался.
Проблема в том, что у стандартного типа данных Qty параметр NoOfDecimals установлен в Авто.
Хотя в описании сказано, что "NoOfDecimals determine the number of decimals when a value displays on a form or a report", то есть параметр должен влиять только на ПРЕДСТАВЛЕНИЕ, на самом деле он влияет именно на ХРАНЕНИЕ величины. Для того чтобы в этом убедиться достаточно, ввести несколько значений в таблицу, меняя настройки NoOfDecimals, и, как сказал mazzy, "посмотреть в базу любой неаксаптовской смотрелкой" (например Query Analyzer). Значение параметра "Авто" равносильно округлению до второго знака. Поэтому в закупке округление до третьего знака и не работало - количество округлялось типом данных до 2-ух знаков до того, как начинала работать настройка единиц измерений.

[mazzy]

Цитата:

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

mazzy
Не кипятитесь, пожалуйста. Читать я умею.
В том-то и дело, что чистая сумма не ОТОБРАЖАЕТСЯ, а РАСЧИТЫВАЕТСЯ исходя из количества, округленного до 2-ух знаков.

Где и как?
Эксперимент - лучшее средство проверки теории.

1. Берем стандартную Аксапту (Сумма в валютах округляется по умолчанию до 2х знаков)
2. Устанавливаем в настройке единиц измерения 3 знака.
3. Создаем заказ.
4. Создаем строку заказа
5. Находим RecID - подставляем этот номер в job (см. скриншот)

Еще раз: вы путаете отображение с хранением!
Рассчитывается то, что хранится. Сама Аксапта никаких лишних поползновений при расчете не делает.

Другое дело, что нормальными средствами ПОЛЬЗОВАТЕЛЬ не может ввести в Аксапту число в котором знаков больше, чем ОТОБРАЖАЕТСЯ на экране (даже если введет вместо числа формулу 1003/1000). Но это вовсе не означает, что сумма РАССЧИТЫВАЕТСЯ исходя из числа отображаемых знаков.

[KiselevSA]

Я предлагаю другой метод проверки: введите чистую сумму такую, как вам надо (9982,79). Посмотрите, что станет с ценовыми показателями.

[mazzy]

Цитата:

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

Я предлагаю другой метод проверки: введите чистую сумму такую, как вам надо (9982,79). Посмотрите, что станет с ценовыми показателями.

Кому предлагаете?
Куда посмотреть?

На всякий случай: Правила округления хранимых цен задаются в тех же валютах. Правила отображения задаются в EDT.

[KiselevSA]

Цитата:

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

Кому предлагаете?
Куда посмотреть?

На всякий случай: Правила округления хранимых цен задаются в тех же валютах. Правила отображения задаются в EDT.

Я предложил пример, при котором в форме (да и в таблице PurchLine) вообще не будет цены.
А по поводу округления: закупаю 7 штук на сумму 10 (ввожу вручную). Какая должна быть цена? )))

[mazzy]

Цитата:

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

Я предложил пример, при котором в форме (да и в таблице PurchLine) вообще не будет цены. ;)

Вы не ответили на вопрос: кому вы предложили?

Цитата:

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

А по поводу округления: закупаю 7 штук на сумму 10 (ввожу вручную). Какая должна быть цена? )))

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

Про округление цен:
По идее надо смотреть, что написано в поле "Округление цены" на закладке Округление для валюты.
Если там 0, то будет округлять до 2х знаков.
Если там 0.0001, то будет округлять до 4х знаков.

См. метод Currency::price()

Что-то как-то тяжко идет. Видимо, еще раз повторить надо:
Повторяю:

Цитата:

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

Правила округления ФИНАНСОВЫХ показателей задаются при настройке валют
Правила округления КОЛИЧЕСТВЕННЫХ показателей задаются при настройке единиц измерения.
Правила отображения на экране и в отчетах задаются в EDT.

[KiselevSA]

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

[mazzy]

Цитата:

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

Сергей. Я же не спорю с правилами настройки. Я предложил вариант решения проблемы точности при указаных параметрах настройки количества и цены: при этом рахождение с инвойсом поставщика сведется к одной сотой валютной единицы.

А... Понятно

Цитата:

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

Я предлагаю другой метод проверки: введите чистую сумму такую, как вам надо (9982,79). Посмотрите, что станет с ценовыми показателями.

В буржуйских документах цена будет равна 0.
В российских документах цена посчитается, но если, исходя из цифр документа, посчитать количество * цена, то получится другая сумма
Ситуация усугубится, если заказ вводится в валюте, а печатается в рублях.

[KiselevSA]

Цитата:

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

А... Понятно


В буржуйских документах цена будет равна 0.
В российских документах цена посчитается, но если, исходя из цифр документа, посчитать количество * цена, то получится другая сумма
Ситуация усугубится, если заказ вводится в валюте, а печатается в рублях.

Имеено поэтому в печатной форме счета-фактуры (первичная валюта не совпадает с рублем) пришлось отстаивать метод обратного счета для налогов и цен