Проблема в расчете плановой калькуляции. Если в ТЧ добавлять изделие и ПФ, входящий в это изделие, то в плановых затратах идет задвоение движений по ПФ. Видимо считает в составе изделия и отдельно.

Аналитикам сказал не включать ПФ в калькуляцию. ХЗ - правильно это или может ошибка в релизе ЕРПУХ?

Его почти никто не использует, так как там есть вопросы к расчету

(0) Калькуляция по идее работает по логике настроенных спецификаций (буквально как при подборе и заполнении, алгоритм в модуле менеджера ресурсных спецификаций), включая настройки назначения и подбора. Если по стандартному алгоритму раскрывается изделие по спецификациям, то дополнительно спецификацию на ПФ не нужно включать в калькуляцию, по-хорошему ее алгоритм подтянуть должен (НЯП).

(1) Любопытно. ) В моем скромном кейсе тоже не получилось без радикальных изменений спецификаций, проще оказалось отчет набросать.

(1) я также аналитику сказал. видимо не используют, раз такая фигня.

(0) блок производства в ЕРП и ЕРПУХ одинаковый

На данный момент в Плановых калькуляциях вообще лучше больше одной строки не делать, т.к. идут ошибки и движения могут задваиваться.

(0) Индусы засунули в регистры ПлановыеТрудозатраты, ПлановыеМатериальныеЗатраты, ПлановыеПрочиеЗатраты измерение КлючПартии. Им забыли рассказать что УникальныйИдентификатор не может быть измерением регистра накопления. Теперь реквизит просто пустого типа, а подсистема встала раком. Ждем когда индусов заменят китайцами.

(6)  Им забыли рассказать что УникальныйИдентификатор не может быть измерением регистра накопления - почему не может?

(7) ко мне вопрос или к разработчикам платформы? Реквизитом может, измерением нет. Но разработчикам ERP это не мешает). В итоге бага с непонятным решением

(8) Чот я первый раз такое слышу. В РС можно. Вот у меня перед глазами такой РС (все работает). А почему в РН нельзя? Может от релиза зависит?

(6) УникальныйИдентификатор - это строка. ЕМНИП, не рекомендуется делать измерения примитивных типов. Но "не рекомендуется" не значит - нельзя.

(6) Интересно, почему только в плановые РН. Глянул. Их двигает только док ПлановаяКалькуляция2_2

Вот тут, по-моему без поллитра не разберёшься )))

(11) Этот тот случай когда УникальныйИдентификатор именно УникальныйИдентификатор а не Строка(36), такой тип тоже есть в 1с но использовать его можно не везде. В Итоге измерение 3х регистров имеет пустой (незаполненный) тип.
ЗЫ. Правда есть сомнения что в умножениях плановых затрат (а именно на это жалуются пользователи) виновато это поле.

(11) В целом кажется это история о том как из одного простого (а-ля эксель) документа сделать космолет и потерять им управление.

(12) Я в коде покопался (перед тем как сообщение тут написал). При разузловании нет проверки, что изделие уже было добавлено в таблицу для движений.

Такое ощущение, что толком документ этот не тестировали при разработке.

УИ может быть измерением РС, реквизитом РС, реквизитом РН, измерением РН не может
(10)

УникальныйИдентификатор - это строка

уи это уи, строка это строка

логика работы из (0) правильная

Продукт состоит из
Материал1
Полуфабрикат1
Полуфабрикат2

Полуфабрикат1 состоит из
Материал1
Полуфабрикат2

все должно участвовать в соответствии с нормами расхода, перемножаться на разных уровнях в разных пропорциях

калькуляция рассчитывается для того, что в ней указано, иначе там не должно быть ТЧ, а только реквизит. Так можно посчитать ПФ1 + ПФ2 в контексте расчета калькуляции для какого то продукта, при этом ПФ2 может входить в состав ПФ1 и он обязательно должен быть учтен. Но если в этой ситуации в ПФ2 будет входить ПФ1, то уже получится зацикливание, этого допускать нельзя

(15) Это тоже так задумано? :)
https://iimg.su/i/khQ1ff

Впрочем пока лишь подтверждаю что замножаются трудозатраты если в калькуляции один и тот же полуфабрират идет на несколько изделий.

(16) ну да - там же не стоит галка "Запрет незаполненных значений"_)

(15) Объясняю в чем проблема.
Изделие 1 - Полуфабрикат 1 (10 шт)
Изделие 2 - Полуфабрикат 1 (5 шт)

Так вот беда в том что индусы в регистры из (6) забыли добавить измерение Изделие. В итоге на этапе оценки стоимости в регистре остается только запись Полуфабрикат 1 (15шт - 1000р) и никакой привязки к изделию.
В отчеты разумеется выводится, просто нет никакой возможности узнать куда сколько пошло.
Изделие 1 - Полуфабрикат 1 (15 шт)
Изделие 2 - Полуфабрикат 1 (15 шт)

Примерно так сейчас в типовой.

(18) Позвольте, но это тогда не "замножение", а суммирование.
А то я задумался над "замножением трудозатрат" из #16 )

Ну а коль суммирование - это ж совсем другое дело. Мы же не факт смотрим, а план, который в данной ситуации как удава меряем в попугаях, т.е. в полуфабрикатах. Раз планируется выпуск ОБОИХ изделий, то и план должен давать 15 ПФ.
Спланируйте только Изделие 1 и план выдаст 10 ПФ.

(18) они не забыли добавить, они объединяли с ИБ, сделанной на 8.7, там то в РН все нормально с уникальным идентификатором, вот и просыпалось чуть чуть на землю. а в (15) я говорил о другом - о методике вложенного расчета

(15) тогда понятно. видимо аналитики не так поняли смысл документа.

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

(18) Функционал "для галочки"? Ну, такого много в типовых.