Всем доброго дня!

Возникла такая проблема - создается регистр накопления.
У него ресурс - Количество, типа Число(25,18)

В виртуальных таблицах 1С не видит больше десятого знака.

То есть остаток на начало месяца = 2,123456789012345
Если проходит продажа 2,123456789012300, то запрос к РегистрНакопления..Остатки() вернет 2,1234567890 и типа
0,0000000000123 отправляет в минус. В результате разъезжаются партии наглухо.

Вопрос - сталкивался ли кто-то с таким и есть ли варианты решения кроме как умножить все на 10^9 и делить при выводе отчетом на экран?

Спасибо

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

(1) что-то не совсем уловлю.
Тогда будет 1 реквизит "ЦелоеКоличество" - Тип Число(7,0)
и 1 реквизит "ДробноеКоличество" - Тип Число(18,0)

так что ли?

(0) https://its.1c.ru/db/metod8dev/content/2665/hdoc

Если при выполнении операций над данными в запросах целесообразно изменить правила вычисления длин и точностей результатов, то для задания желаемой длины и точности необходимо использовать оператор ВЫРАЗИТЬ. Следует иметь в виду, что если необходимо изменить длину и точность результата какой-нибудь операции, то оператор ВЫРАЗИТЬ нужно применять к ее операнду. Тогда длина и точность результата операции будет вычислена по описанным выше правилам, исходя из длины и точности операнда, заданной оператором ВЫРАЗИТЬ. Например, если поле "Реквизит1" имеет тип "Число(8, 0)", то чтобы выражение Реквизит1 / 3 имело в дробной части 15 цифр необходимо записать:
ВЫРАЗИТЬ(Реквизит1 КАК Число(23, 15)) / 3

Точность 10 знаков после запятой в регистрах накопления

Можно и так. Главное написать библиотеку, чтоб умела делать арифметические операции над такими парами чисел.
P.S. предложение о текстовом представлении это не шутка. Я так делал в одной базе специальный тип данных для хранения пар чисел - допусков (+ и -). И писал модуль по работе с таким типом данных (сложение, сравнение на полное вхождение, процент перекрытия, обращение и т.п.). Данные хранил в виде строки в специально придуманном формате.

(3)
Выбрать
    КоличествоОстаток
Из РегистрНакопления..Остатки()

Или

Выбрать
    ВЫРАЗИТЬ(КоличествоОстаток КАК Число(25,18))
Из РегистрНакопления..Остатки()

возвращают одинаковый результат 2,12334567890

(0) если приемлемо - изменить единицы измерения

(7) ну просто умножать на миллиард и делить обратно?

(6) https://ibb.co/DzXMhvG

Вы может в реквизит данные присваиваете, у которого тип другой?

(9) где присвоение в п.6?

просто 2 документа
первый делает приход 2,123456789012345
второй делает расход 2,123456789012300

в итоге в разбивке по партиям получаю 2 партии: на одной 0,000000000000012345
а на второй -0,000000000000012300

(0) Криво сделаны партии, надо через отдельный справочник
Незначимые остатки в регистре обнулять

Для обдумывания могу пример без этих много цифер после запятой

Упаковка - 1 шт, состоит из 3 блистеров (в каждом по нескоко таблеток/капсул это неважно)
Дробная продажа разрешена

Пришла 1 упаковка... Продали 3 блистера (по 0.33 шт)... Остаток 1.00 - 0.99 = 0.01 - кого наипали?

(12)+ Есть два метода решения проблемы
1. Разные единицы измерения, везде в доках и регистрах хранить с единицей
И использовать разукомплектатацию - перед списанием первого блистера, списывать 1 уп. и ставить на приход 3 блистера

2. Все в базовых шт, при списании последнего блистера если остаток малый (меньше чем блистер) его тоже списывать
1 = 0.33 + 0.33 + 0.34

(10) Я вам вывел результат, со стороны SQL-запроса все ок.
То что разбивается неверно, это уже к логике работы.

Неправильно выбрана базовая единица измерений в товаре. Три знака после запитой более чем достаточно.
Будет единица измерения блистер 1 шт. Упаковка 3 блистера и никаких зависших 0,01 и прочей фигни.

Продаете по ампульно, капсульно, таблеточно соответственно основная единица буде таблетка.
будет блистер 5 таблеток и блистер 10 таблеток. упаковка 30 шт. и упаковка 50 шт. И никаких дробей в периоде никогда не получится.

(16) На предпоследней работе была единица человеко-месяцы (коммунальные услуги)
И да там 8 знаков после запятой точности не хватало ибо тариф  за человека в месяц уже изначально 2 знака после запятой
А человек мог 1 день только присутствовать по адресу...

(17) С дуру можно и не такое придумать. Есть базовая единица нормо/часы. Перевести тариф за час из человеко/месяц в нормо/часы вообще не вопрос учетчица или кто там Устанавливает ставку может про них и не знать установил там Ставку за месяц 30 тыс. программа в рубль/час пересчитала и забыла. Учетчики себе рисуют 8 или что там по факту вышло. все прозрачно и в пределах 2 знаков.

(18) >Перевести тариф за час из человеко/месяц в нормо/часы вообще не вопрос

Низзя
Потребуется точность КолвоЧасовВМесяце * ТочностьТарифаЧеловекоМесяц

(20) Даже у бюджетников это приказом по предприятию делается и 0,5 ставки учителя превращается в н часов.

(21) Ты квитанции за коммуналку видел?
Сколько например за вывоз ТКО платишь с человека?

Интересно, это SQL-сервер не может с типом DECIMAL(25,12) работать и суммировать как надо или 1С-ка родимая.

(23) 1С использует тип NUMERIC при работе с SQL

(0) >Количество, типа Число(25,18)
Сделай тип Число(38,18)

(22) Там нет разбивки почасовой, для частника просто фиксированная сумма. Для фирмы договор на вывоз контейнера раз в 2 недели а не тариф за месяц. В какие то месяцы это и 3 вывоза может быть соответственно тогда и сумма в 1,5 раза выше. Зп водителя мусоровоза и всех остальных от этого не зависит. Он сколько часов отработал столько и получит. А не в 1,5 раза больше в этот месяц.

(25) Если ты внимательно изучишь тему то выяснишь офигительные подробности про тарифы (стоимость вывоза 1 м3 ТКО).
И нормативы (сколько по замерам мусорит один человек за год) - которые по категориям жилья.

И дальше идет деление годового норматива в кубах на 12 (месяцев).
Но человек может часть месяца отсутствовать (уехал на отдых или в командировку) и не обязан платить за вывоз ТКО (да надо принести доказательства в виде билетов или справок).

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

(25) Кстати ТКО прикольная штука, там "покупают" в кубометрах а "продают" на полигон ТКО в тоннах ))