forum.clarionlife.net

Всем привет !

Неоднократно поднималась тема передачи данных в параметрах REAL с потерей точности.
Прозвучали конкретные рекомендации. Можно я ещё раз их проговорю и покажу реализацию ?

Предположим мы хотим получить некие данные с точностью 2 и 3 знака после десятичной точки (цена и кол-во).
Вроде бы все вызовы в стиле NumFormat(10 / 3) дают ожидаемые значения.
Это правильное решение для работы с параметрами REAL ? Спасибо !

Один нескромный вопрос: а почему не используете Digital?

Губин Игорь писал(а): 20 Декабрь 2025, 17:02 Один нескромный вопрос: а почему не используете Digital?

Что есть у нас "Digital" ? Если DECIMAL - так он может передаваться в процедуру только по адресу ...

Игорь Столяров писал(а): 20 Декабрь 2025, 17:23 Что есть у нас "Digital" ? Если DECIMAL - т

Да, виноват... Но так в процедуре можно присвоить переданное значение и обратно. Лично я так и делаю. Передаю Real, присваиваю переданное значение Decimal, а вся математика и логика работают уже на DECIMAL

Никаких проблем при передаче параметров с real, ни по значению, ни по адресу, я не наблюдал. Что такое потеря точности?

А, понял, прямо в вызове деление пишете. Я на автомате выражение с делением всегда в round заключаю.

finsoftrz писал(а): 20 Декабрь 2025, 17:39 Никаких проблем при передаче параметров с real

Это понятно. Если есть возможность посмотреть - вот здесь я всё расписал с примерами.
Читать нужно первый пост в теме: viewtopic.php?t=5315&start=15

Ну а решение с "беcпроблемными параметрами REAL" я попробовал найти здесь.

finsoftrz писал(а): 20 Декабрь 2025, 17:52 А, понял, прямо в вызове деление пишете

Не обязательно. См. первый пост в: viewtopic.php?t=5315&start=15
Подставлять всегда и везде костыль на автомате - это решение. Но если честно - так себе ...

finsoftrz писал(а): 20 Декабрь 2025, 17:52 А, понял, прямо в вызове деление пишете. Я на автомате выражение с делением всегда в round заключаю.

В любых операциях. Возможна ещё погрешность в логике. 0.1 > 0.999999999999...

Игорь Столяров писал(а): 20 Декабрь 2025, 17:55

finsoftrz писал(а): 20 Декабрь 2025, 17:52 А, понял, прямо в вызове деление пишете

Не обязательно. См. первый пост в: viewtopic.php?t=5315&start=15
Подставлять всегда и везде костыль на автомате - это решение. Но если честно - так себе ...

Любите Вы ярлыки навешивать. Если работаете с real, то ОБЯЗАНЫ использовать round в итогах цепочки расчетов (не после каждой арифметической операции). Причем не только при наличии умножения или деления, но и при наличии сложения или вычитания. Например, если суммируем real поля в кьюшке, то после всех суммирований тоже надо делать round на итоговые значения (не на каждое суммирование).
Плюсы real мы обсуждали уже - скорость работы на 2 порядка быстрее и унифицированность хранения значений. DECIMAL не всегда корректно работает, может неявно округлить значение, когда это не надо делать, сталкивался как-то с такой проблемой.

finsoftrz писал(а): 20 Декабрь 2025, 19:20 то после всех суммирований тоже надо делать round на итоговые значения (не на каждое суммирование)

К сожалению, в этом случае накапливается погрешнось в REAL.
И как следствие итог по колонке может не соответствовать сумме показанных значений в колонке (например НДС в УПД).
С DECIMAL такого в принципе быть не может. Ну или округлять каждое значение в REAL перед суммированием.

Игорь Столяров писал(а): 20 Декабрь 2025, 19:54

finsoftrz писал(а): 20 Декабрь 2025, 19:20 то после всех суммирований тоже надо делать round на итоговые значения (не на каждое суммирование)

К сожалению, в этом случае накапливается погрешнось в REAL.
И как следствие итог по колонке может не соответствовать сумме показанных значений в колонке (например НДС в УПД).
С DECIMAL такого в принципе быть не может. Ну или округлять каждое значение в REAL перед суммированием.

Погрешность накапливается очень в мелких значениях, поэтому такой проблемы не встречал. В конкретном примере надо, конечно, результат расчета суммы в строке явно округлять, иначе вылезет погрешность в строке, не в итоге. Если очень напрягает писать round, можно навесить простенький шаблон для округления всех real в заданной структуре.
Я, конечно, понимаю, что во многом дело привычки, и decimal как раз и добавили, чтобы неявно автоматизировать округления. Как сложилось, так сложилось, менять подход смысла нет.

Вот еще вопросы, как определять DECIMAL.
1. В приходах и возвратах товаров поставщику у нас цена с 4 знаками после запятой, в отгрузках с 2. Это одно и тоже поле в структуре данных.
2. Количество товара может вводится как в целых (для штучных), так и с 3 знаками после запятой (весовые, мерные товары).
3. Округление может быть по правилам, отличающимся от того, как это делает DECIMAL. Например, 1.455 надо округлить до 1.45 или до 1.46.

Проблема с лишним округлением у меня как-то всплыла при сложных расчетах, где использовались real. Делалась сложная обработка большого массива данных, и в итоге вылезла погрешность где-то в копейку. Выяснилось, что влепил лишний round, где его делать не надо. Убрал, проблема ушла. А что делать при DECIMAL, который все неявно округляет? Я понимаю, что можно где-то использовать real, где-то DECIMAL. С другой стороны, один базовый тип данных, никаких трудно находимых проблем. ХЗ, я привык, как привык.

По закону в РФ для всех документов используется национальная валюта.
Т.е. стоимость к расчёту и налог в каждой строке в любом случае должен быть показан в копейках.

А с ценой можно манипулировать. Лидер хит-парада здесь типографии с огромными тиражами и
дешёвыми этикетками за штуки.

Использовать увеличение разрядности цены для подгонки стоимости приходных накладных для коррекции
налогов по документу, которые типовая конфигурация 1С расчитывает от стоимости документа - не панацея.

Про беспроблемность REAL и ошибки в копейку Вы уже говорили, возможно Вам удобней не видеть проблем.
Сейчас нет цели убеждать. С чем согласен - это скорость DECIMAL, как производного типа данных.

Игорь Столяров писал(а): 20 Декабрь 2025, 20:45 Использовать увеличение разрядности цены для подгонки стоимости приходных накладных для коррекции
налогов по документу, которые типовая конфигурация 1С расчитывает от стоимости документа - не панацея.

Откуда эти слухи? Типовые рассчитывают НДС по каждой строке, это регламентируется законодательно. У них были варианты считать НДС из цены или на цену. Последнее используется, в основном, у бюджетников. У обычных коммерческих организаций цена полная с НДС, так как иначе запутаешься. У нас в приходах используется специальный режим, при котором вводится не цена, а сумма. Цена считается автоматически с 4 разрядами в дробной части как сумма/количество. Этого всегда хватало, чтобы сходился НДС (хотя есть возможность откорректировать общий НДС вручную). Некоторые писали, что лучше делать цену с 5 знаками в дробной части, 4 знаков может не хватить в каких-то ситуациях с весовыми товарами, но я лично не сталкивался.