Добрый день.

Помогите разобраться с ситуацией. На Завод1(БЕ1) производится ПФ и передается на Завод2(БЕ2) для дальнейшей переработки через 79 счет. Т.е. нет никакой купли\продажи внутри КЕ между двумя БЕ. В планировании, для целей калькуляций, в управлении переносом настроена передача с завода на завод данных о калькуляции. Есть дифференциация на заводе производителе и она передается при калькулировании цены на заводе2 в дифференциацию2 по элементам затрат.
Настроен РМ и Фактическая дифференциация. При фактическом производстве и попытке перемещении материала с Завода1(БЕ1) на Завод2(БЕ2) в ММ выпадает ошибка, что вид затрат 31030000 ПФ собственного производства не присвоен схеме элементов. Это настораживает, ведь сумма с\с этого ПФ должна быть дифференцирована и не требует присвоения какому-то одному элементу затрат через виз затрат списания. Если же присвоить этот ВЗт одному из элементов, то система при прогоне фактической калькуляции почему-то всю сумму фактической с\с на Завод2(БЕ2) не раскладывает по элементам, как в плане, а отражается одной общей суммой в элементе, которому присвоен недавно ВЗт.

Хотелось бы получить факт дифференциацию не только на заводе производителе, но и на заводе потребители, а ещё более важно - разложить эту факт дифференциацию по элементам в том материале, в состав которого этот ПФ и включается.

Спасибо заранее за подсказки.

1VK, я не нашел там ответа на свой вопрос...
Почему при перемещении с БЕ1 на БЕ2 (в рамках одной КЕ и одной схемы элементов) не передается фактическая дифференциация? При этом плановая калькуляция подхватывает дифференциацию второго завода и переносит её к себе без проблем?

В хелпе четкого описания работы факт дифференциации для случая двух заводов нет.

Да действительно, в случае перемещения между двумя БЕ дифференциация перемещаемого материала сворачивается в элемент, которому присвоен вид затрат данного материала. К сожалению эта логика зашита в программе...
Есть несколько способов ее обойти:
Способ 1 (стандартный, но муторный): BADI GET_DEFCCS.
Способ 2 (легкий но нестандарт и требует тестирования): неявный ENHANCEMENT в конце метода ctyorg_change (инклюд LMLCCS_UPDATEF07) с присвоением параметру ed_answer значения `NO`.
Способ 3 (самый правильный, но маловероятный): Заставить SAP добавить настройку для БЕ при перемещении между которыми не должна сворачиваться дифференциация, ну или на худой конец, чтобы добавили стандартный экзит туда где это можно програмно будет задать. Если получится пройти этим способом, то большая просьба - не забыть про коллег и выложить решение сюда...

Кстати, тут еще стоит обратить внимание на дифференциацию многоуровневых отклонений - нота Note 1334661 - Cost component split collapsed during company code change...

Ну я думаю, если вы будете делать оценку себестоимости с точки зрения концерна, то так оно и будет. В этом смысле такая настройка в САПе имеется.

Тут ведь как. Если вы уж выделили две БЕ, значит вы хотите помимо консолидированной отчетности иметь отчетность по каждой БЕ в отдельности. Вот САП и трактует эти БЕ как отдельные юридические лица. Иначе не делите на БЕ используйте другие орг. единицы.

Хотя, конечно, несоответствие плановой и фактической калькуляции тут есть, но я думаю, что на БЕ2 этот материал можно и как сырье скалькулировать. все равно симметричность подхода к планированию себестоимости и калькуляции фактической себестоимости безусловно нарушена. САПу здесь минус поставим.

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

funtik, спасибо. Будем им писать...

Manag, что значит если выделили две БЕ, то две раздельные отчетности? БЕ, БЕ-шками, а КЕ, КЕ-шками... мухи отдельно, котлеты должны быть тоже отдельно! В ракурсе бухучета и его правил идет всё как надо, одной суммой, по нужным счетам. Но на уровне анализа затрат зачем тогда делают одну КЕ? А?

Чтобы оценку концерна можно было бы сформировать, например.

Здравствуйте.
А кто-нибудь пробовал решать обратную задачу?
Очень хочу настроить один вид движения, который при перемещении внутри завода не тащил бы дифференциацию
с отправителя, а клал бы всю сумму в элемент получателя по GBB VBR, но не хватает мозгов.

Транзакция OKTZ. В основных данных элемента затрат есть крыжик "Сведение элемента". Разве он не для этого?

Manag, здравствуйте!
Я не нашла в OKTZ эту галку. Но мне явно нужна привязка к виду движения.
Если материал создали не с тем элементом и уже оприходовали, а потом одумались и создали правильный материал, мне нужен вид движения типа 309, но чтобы элемент из старого, неправильного материала не тянулся.

Что-то я не понимаю зачем вам это нужно. Галка, о которой я говорю, управляет тем, что когда вы используете полуфабрикат на следующем уровне производства, то вы можете либо передать его стоимость в себестоимость следующего уровня по принципу "элемент в элемент", либо включить ее в один элемент в соответствии с видом затрат, которым полуфабрикат списывается в производство. Это не зависит от того, каким видом движения вы его списываете и действует точно также и на обратные виды движения.

Нашла я галку, стоит она у нас на каждом элементе. И это правильно.
Manag, если помните, Вы уже помогали мне с изменением дифференциации покупных материалов, спасибо Вам большое. Мой вопрос - продолжение той проблемы. На старте проекта насоздавали кучу покупных ОЗМ не с тем элементом, загрузили остатки, теперь разгребаем. Создаём новую ОЗМ, с правильным элементом. Вопрос: как перенести остаток с ОЗМ на ОЗМ в правильный элемент? Весь год мы этим вопросом не мучились, использовали 309 вид движения и из ОЗМ в ОЗМ двигали. И тут через год нас угораздило глянуть дифференциацию новых хороших ОЗМ - сами понимаете, что мы там увидели. Одномоментно решили вопрос деблокированием плановых калькуляций (ещё раз спасибо!!!) и изменением дифференциации остатков на начало месяца. Теперь думаем, как исключить повторение этой ошибки - вдруг ещё что придётся перевести из ОЗМ в ОЗМ.