[Constantus]

Приветствую, Форумчане!
УПП 1.2, писанная/переписанная.

Поступила номенклатура "Шланг красивый" 20 метров на сумму 700 денег
Начали его по-кусочкам расходовать в производство
0.008 м по 0,28 денег
0.123 м по 4.30(5) денег //уже проблемы с округлением по сумме

В РН "Учет затрат" документом "Распределение материалов на выпуск" легли записи по расходу и приходу аналогично
0.008 м по 0,28 денег
0.123 м по 4.30 денег

Если всё это просуммировать, то после окончательной реализации (списании) итог
Шланг 20 м на сумму 701.40

Т.е. в результате этого округления накопились лишние 1.40 денег

После проведения документа "Расчет себестоимости выпуска" (типа закрытия месяца) эта разница никак не списалась и во всех отчетах висит остаток по сумме в 1.40 денег

Что было сделано неправильно, что осталась эта разница? И как теперь это можно исправить? Может есть какие-то настройки? дело в том, что таких позиций немного (штук 5), остальные вроде списались под ноль по сумме.
Подскажите как с этим можно справиться?

[Constantus]

Если рассмотреть РН "УчетЗатрат", то упрощенно с суммированием он выглядит так:

+ 20 700 (поступление)
- 20 701,4 (затраты)
+ 20 701.4 (затраты на выпуск)
- 20 701,4 (расчет себестоимости выпуска)

Грубо говоря, не гасится своеобразная "курсовая разница по округлению" :-)

[Макс1С]

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

[Constantus]

Макс1С @ Вчера, 16:10 ,

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

И почему эта проблема вспыхнула не со всеми номенклатурами, а только с какой-то горсткой...

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Решение

Всё оказалось значительно проще.

Есть константа в "Расчете себестоимости" - "Граница погрешности СЛУ"
Там стояло значение "1.00"

Т.е. все погрешности по округлению меньше "1.00" программа распределяла, остальными игнорировала. Поставили "1.50" (4.00) - усё пройшло чудово