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

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

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

Если это просто нездоровый интерес, что у нас было 10 лет назад, то при выполнении заказа в примечании (либо на уровне заголовка либо на уровне позиций) ручками пишем: Заменили АБВГ-1 1902 г.в. на ЕПРСТ-99 2005 г.в.

А если нужно получать какую-то формализованную отчетность, то нужно смотреть какую именно и в каком формате и уже отсюда искать варианты решения вопроса.

Проявление нездорового интереса действительно возможно было бы пресечь комментариями в длинных текстах.
В том то и дело, что речь идет об отчете вида:
Дата
Что сняли
Что установили
Кстати, одна из причин того, почему не хотелось бы использовать документы изменений (см. первый пост), заключается в том, что реальная дата монтажа комплектующего может не совпадать с датой занесения изменений в систему.

это polus, забыл залогиниться.

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

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

А почему не по-простому: заменяемый материал списывается с заказа.
И собираем отчетом по видам движений...

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

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

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

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

Без спецификации будет проблематично определить первую замену.

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

Я бы сделал так.

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

По крайней мере, сохраняется логичность и структура данных : и заменяемый и заменяющий материал присвоены операции, а та в свою очередь заголовку заказа.

Я бы использовал юзер-ексит IWO10015 (F4-справка для полей пользователя в операции заказа ТОРО) для того чтобы "подцепить" справочник материалов к Полю пользователя.

Соответственно с реализацией отчета не возникло бы совершенно никаких проблем.