ТОРО: вопросы/проблемы и решения (стр. 5 )

Автоматическое деблокирование заказа ТОРО

Вопрос:

как настроить автоматическое деблокирование и сохранение заказа ТОРО при его печати?

Ответ:

Есть расширение IWO10009, которое позволяет выполнить проверки в момент сохранения и, если нужно, деблокировать заказ. Думаю не проблема проанализировать в нем был ли распечатан заказ (тем более, если используется своя программа печати) и соответственно принять решение о деблокировании.

ФМ для пересчета затрат по заказу ТОРО

Вопрос:

Подскажите, пожалуйста, сабж, если кто знает.

Ответ:

Как вариант, при выполнении каких-то действий, которые могут отразиться на плановых затратах, но которые не обновляются - сделать call transaction IW32 с определением затрат и сохранением.

Спасибо! Так и сделал. Работает.

Код:

include BDCRECXY. data AUFNR like aufk-AUFNR. start-of-selection. AUFNR = '000008000007'. perform bdc_dynpro using 'SAPLCOIH' '0101'. perform bdc_field using 'BDC_CURSOR' 'CAUFVD-AUFNR'. perform bdc_field using 'BDC_OKCODE' '/00'. perform bdc_field using 'CAUFVD-AUFNR' AUFNR. perform bdc_dynpro using 'SAPLCOIH' '3000'. perform bdc_field using 'BDC_OKCODE' '=KOER'. perform bdc_dynpro using 'SAPLCOIH' '3000'. perform bdc_field using 'BDC_OKCODE' '=BU'. perform bdc_field using 'BDC_CURSOR' 'CAUFVD-KTEXT'. call transaction 'IW32' using bdcdata mode 'E' update 'S'.

PM-CO перерасчет по актуальному тарифу

Вопрос:

В течение месяца вводятся подтверждения на заказ. Считаются, соответственно, сразу же фактические затраты на собственную обработку по установленному фактическому тарифу. Потом тариф контроллинг пересчитывает. Новые подтверждения добавляют затраты, рассчитанные по новому, а уже введенные не пересчитываются (остаются рассчитанными по старому тарифу). Мне нужно, чтобы уже введенные фактические затраты перерассчитались по последнему тарифу.
Как это можно сделать?

Ответ:

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

Вид затрат для услуг в заказе ТОРО

Вопрос:

Вопрос не знаю куда больше относится, ММ или ТОРО.
Пытаюсь понять, откуда берется вид затрат для операции заказа ТОРО с ключем PM03. Как я понимаю варианта 3:
1. Прописывается для конкретного пользователя в значениях по умолчанию (ДопИнфо->Параметры настройки -> Значения по умолчанию)
2. Прописывается в IMG через Создание профилей значений по умолчанию для обработки на стороне. Затем этот профиль присваивается комбинации Завод-Вид заказа.
3. В основной записи работ/услуг есть поле класс оценки. Если нажать кнопочку Эфадин:

Цитата:

With the aid of the valuation class (subject to certain other factors) the system is able to find the G/L accounts that are updated when services are entered.

Т. е. как я понял можно настроить автоматический выбор счета как для материалов через транзакцию OBYC. Для материалов использовали GBB. Для какой операции в OBYC прописывать вид затрат для услуг?

Или я ошибся и что-то неправильно понял?
Еще вопрос о приоритетах - если настороено все - что будет выбираться?
Самостоятельно выяснил, что пункт 1 (умолчания для пользователя) приоритетнее пункта 2 (профили значений по умолчанию).

Ответ:

Это полностью ММ (если речь идет о работах/услугах):
1. В настройке типа контировки (SPRO-MM-Закупки-Контировка-Ведение типов контирвки) для соответствующей контировки указываем Модификацию счета.
2. В осн. записи услуги/работы (AC03) определяем класс оценки для соответстующей услуги.
3. В настройке авт. проводок (OBYC) для кода операции GBB прописываем затратный счет: указываем модификацию оценки (обычно это номер завода, но если точно, то тр. OMWD), модификацию счета (п.1) и класс оценки (п.2) и соответственно сам затратный счет.

IW40 Список заказов ТОРО

Вопрос:

Использую данную транзакцию, настраиваю просмотр компонентов, выбираю просмотр Групп закупок. Результат - у одного материала группа закупок есть, у остальных нет. В технической информации вижу, что в ОЗМ группа закупок лежит в Таблице MARC, а в IW40 в структуре RIHRESB. Имя поля одинаковое. Вопрос - как попадает группа закупок из MARC в RIHRESB? Должен же быть стандарт.

Ответ:

Скорее всего там, где тип "L" группы нет, для, например "N" - есть.
Ведь группа закупок имеет смысл, если материал будет закупаться и сразу же списываться под этот заказ.
А вообще IW40 - это отчет построенный на логической базе AFI, данные читаются из RESB, так что если край нужно показать группу закупок, то копируем отчет, немного подправляем, и радуемся жизни.

Заказы и подзаказы ТОРО

Вопрос:

Ведём планирование ТМЦ через заказы ТОРО.... Скажите, как сделать так, чтобы затраты, собираемые в подзаказах ТОРО отображались в Головном заказе?!

Ответ:

Заходишь в основной заказ, далее по меню Дополнительная информация - Подзаказы - Обзор затрат или есть кнопочка Иерархия справа от номера заказа когда в него вошли. Еще есть тр. IW40 там можно посмотреть

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

Не работает расчет косвенных надбавок

Вопрос:

Калькуляция настроена
Схема калькуляции прописана в варианте оценки
Вариант оценки присвоен варианту калькуляции
Вариант калькуляции присвоен виду заказа

Ответ:

Проверь еще раз все по порядку:
1. Присвоение варианта калькуляции виду заказа - OIOF
2. Присвоение варианта оценки варианту калькуляции - OKP6
3. Присвоение схемы калькуляции варианту оценки (OKP6 или OKP8)

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

Спасибо, все заработало, но по прежнему при создании заказа подхватывается схема PP-PC1 - PP-PC Стандарт, хотя в OKP8 для варианта оценки 007, в закладке «Косвенные затраты» я установил свою MRMP01. Но это уже не беда, чудес не бывает, разберусь.

Поля сообщения в заказе

Вопрос:

Необходимо в заказе ТОРО использовать закладку сообшения вида M3 "Все мероприятия".
Сначала подключается вид сообщения к виду заказа "Ведение индикатора данных сообщений и заказов на одном экране". А как выбрать поля сообщения не помню.

Ответ:

spro-торо-обработка данных-сообщения-обзор для вида сообщения-структура экрана

Раскладка/Перенос затрат на заказы ТОРО

Вопрос:

Сначала сделали перенос затрат с заказа CO на МВЗ. Теперь хочу сделть перенос с этого МВЗ на заказ ТОРО. Система выдает ошибку : не найден отправитель и что вроде что не невозможно рассчитать на заказ ТОРО.
Причем с заказа СО на заказ ТОРО (напрямую) все проходит нормально.

Система запрещает делать операции Раскладка/Перенос затрат на заказы ТОРО (если они выступают в роли получателей), хотя расчет внутреннего заказа СО на заказ ТОРО (и наоборот) можно выполнить легко и непринужденно.

Нельзя никак разрешить данные операции путем настройки? Или только ломать SAP? Это, конечно, плохо, но, если очень хочется, то ведь можно? Или это вообще невозможно???

Ответ:

Транзакция BS12 - "Типы объектов: ведение". Выбираете нужный тип объекта (в вашем случае кажется ORI "PM/SM-заказ"). Жмете "Перейти к" - "Разрешенные операции". Ставите галочки напротив нужных операций (RKIU - "Фактическая раскладка", RKIV - "Фактическое распределение" и т. д.). Сохраняете.
Однако обратите внимание, что при входе в эту транзакцию (BS12) будет сообщение: BS 276 "Эта таблица ведётся со стороны SAP". You are maintaining a table which is usually maintained by SAP only. Changing this table may affect specific programs. То есть вы эти изменения делаете на свой страх и риск. Но если очень хочется...

Таблицы исторических заказов

Вопрос:

В каких таблицах лежат исторические заказы???
В AUFK ложится только номер заказа, его тип и номер объекта....все остальные поля незаполненные.

Ответ:

класс разработок IWO2, таблицы HIKO, HIMA, HIVG, PMCO, PMCO1, PMCO2 и. т.д.

Как отследить заменяемый компонент?

Вопрос:

В заказе ТОРО для операции указывается компонент, который мы устанавливаем. Как отследить компонент, который мы заменяем? Короче говоря, нужна отчетность что и на что заменяем.
Как вариант, можно, конечно, использовать спецификацию ЕО, заменять компоненты там, а затем отслеживать это через докумены изменений, но такое решение по некоторым причинам использовать не хотелось бы. Подскажите, какие еще возможны варианты?

Ответ:

Не буду касаться АБАПа в части screen-exit-ов, поскольку этих самых экзитов и в заказе и в ТМ/ЕО куча - и забабахать нужный анализ не проблема. Попробуем обойтись минимумом абапа (т. е. предположим что будет только отчет, отражающий нужную тебе инфу).

Интересно было бы конечно узнать как структуируется у тебя ЕО (я так понимаю компьютер, например) - и вообще структурируется ли?

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

Если ЕО структуируется через спецификацию (причем это будет что-то типа конструкторской спецификации, т. е. то из чего состояла эта ЕО на момент ввода в эксплуатацию/систему). Здесь тоже отпуски материалов на ЕО - это замены, но как определить к какому узлу относится тот или иной отпущенный материал? Ведь в заказе может быть куча материалов - какие-то из них это замена видеокарты, какие-то память, каки-то винт. Может имеет смысл классифицировать эти материалы (и те которые составляют спецификацию ЕО и те что будут отпускаться на замену): т. е. создать класс, скажем "Блоки ЕО", признак "Компьютер" и значения
признака "Видеокарта", "Память", "Винт" и т. д. Тогда по значениям признаков сможем собрать (в отчете) какие узлы (значения признаков) заменялись и на что (материалы).

Без спецификации будет проблематично определить первую замену.
Можно воспользоваться вариантом предложенным АлексО: т. е. заменяемый материал списываем с заказа. Здесь правда тоже встает проблема: к какому блоку относится заменяемый и заменяющий материалы(через использовании классификации проблема решается). Есть правда одно но: как быть с этим самым заменяемым материалом - оцениваемый он или нет (ведь такая операция, если материал оцениваем уменьшит сальдо на заказе и не только...), имеем мы право ложить его на склад или нет, и т. д. Если решить это но, можно вообще обойтись без спецификации: в одном заказе и то(заменяемое), и другое(заменяющее). Правда может стоит поднастроить доп. ВД для списания заменяемого материала с заказа, чтоб легче было анализировать и не путать со сторно отпусков на заказ.