1. Есть регистр накопления(остатки) "Заказы поставщикам". У него условно два регистратора: Заказ поставщику, Приходная накладная. В регистре у количества точность три знака после запятой.
2.Заказ поставщика заполняется в ед. измерения поставщика, а при проведении, в регистр количество пишется в базовых единицах(умножается на коэффициент пересчета).
3. Есть функция заполнения приходной накладной текущими остатками по регистру. При заполнении происходит обратный пересчет из базовых единиц в единицы поставщика. Но из-за округления при пересчетах туда-обратно не совпадает количество на остатках и в приходной.
Как быть?
Есть простой вариант - увеличить точность(количество знаков после запятой) у ресурса Количество в регистре до 9 знаков.
Есть более трудоемкий вариант - заполнять приходную накладную базовыми единицами и добавить(для пользователей) колонку с единицами поставщика.
Кто может подсказать, кто сталкивался, какие проблемы могут возникнуть при реализации простого варианта - увеличение количества знаков после запятой в ресурсе Количество? Какие подводные камни могут всплыть?

Добавить измерение ЕдиницаИзмерения в РН, и не пересчитывать. Остатки соответственно пересчитать, закрыть период и написать бумажку на мониторе: "Заказы поставщикам и приходные накладные до 13.05.2013 не проводить!".

(1)Рассматривается и такой вариант, но по трудоемкости он на третьем месте :)

Может лучше в РН хранить в "атомах" , то бишь неделимых минимальных единицах?

(3) Это как? А в базовая единица разве не является этой самой неделимой?

(4) см (0) у ТС: "...в регистр количество ... (умножается на коэффициент пересчета). "

(4) Если базовая тонна, а заказ поставщику на килограммы - тогда базовая не является неделимой. Должно быть наоборот.

(6) +100
и я о том же

+(6) а ТС видимо граммы или караты хочет

(8) тут случай сложнее, килограммы в п/метры

Аа! Было такое в практике: учет металлопроката?

(9) закупают в килограммах, в регистре хранится в метрах

(10) Не совсем... но наверное похоже. Чем завершилась практика?

(12) купил в кило = храни в кило = весовой товар.
на отпуск в п/м = кг* к-т пересчета (указан в сортаменте завода-изготовителя)

+(12) кладовщик наверное весами пользуется при отгрузке и приемке, а не с рулеткой бегает...

Другая тема, с чем столкнулся: золото (проволока). Вот здесь гемморой...

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

Кто-нть может просветить по теме: Какие проблемы могут возникнуть если в одном регистре количество с точностью 9 знаков п. з., а в остальных - 3 по стандарту? Помогите ленивому одинеснику, ведь самый простой вариант - он же всегда самый гениальный, я же правильно говорю?

(16) А как инвентаризацию делаете: в тоннах или штуках или кило?

От штуки можно отпилить куууусочек
От тонны тоже мона отхваить в пределах точности весов = кило точно мона :)))

(17)ХЗ если честно, но скорее в тех, в каких потребляет производство. В данном случае  - п/м

(18)Самое интересное как закупщики определяют коэфф пересчета. Вот это для меня загадка...:))

А кладовщик приходует в тоннах. Не завидую...
Есть св-во матералов? при одной температуре (приемке) Длина1 а при другой (отпуске) Длина2<Длина1. В результате: недогруз?

закупщики определяют коэфф пересчета = должны быть ТУ и стандарт на продукцию, по идее

должны быть ТУ и стандарт =должны быть ТУ или стандарт

(21)Ага, что-то подобное уже всплывало в разговорах, в подробности пока не вдавался. Недавно здесь работаю...

как хорошо что это все не у меня...

(20) Когда-то  работал в мясной фирме: там была супер-единица: полутуша! На шашлык кладовщик всегда мог отчикать! Скоко попросишь (от одной-двух и т.д.)!!! :))))

(26) базовая единица

(26) не говорите мне про шашлык, после майских выходных

(28) Мутит? :)))))))

нет, еще выходных хочется :)

(30) кубинос солидарос! :)))))))))

(26) а мне вот плохо, что такого раньше не попадалось - когда было с кем посоветоваться :(

В общем, как видно, принципиальных возражений против первого варианта нет?

up

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

(35) согласен что результат не гарантирован на 100%, но переводить весь регистр на учет в единицах поставщика из-за проблемы, которая возникает не так уж и часто, как-то стремно.
Тем более регистр с данными за пару лет...

Хотелось бы услышать еще мнения...

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