Подскажите, кто сталкивался с задачей учета простоев оборудования? В каком модуле это лучше реализовать? Какими транзакциями пользовались?

учет простоя оборудования ведем в модуле ТОРО, используем сообщения (iw21(22/23))...

Все простои, причины простоев, причины неисправностей, коды неисправностей, мероприятия и коды мероприятий формируются на уровне сообщений, отчеты только надо писать свои.
Что интересует?

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

Все это можно развести видами сообщений и каталогами кодов. Главный вопрос, кто будет фиксировать виновного в простоях? Одно дело зафиксировать факт останова и принимать меры по устранению, другое дело искать виноватого. Бывает так, что причину и виновного определяет комиссия, путем расследования события....Проще каталогизировать причины: Организационные; Нарушение ТБ; Несоблюдение технологии и т.д., т.к. с точки зрения производства, эта аналитика будет более полезной нежели кто больше оборудования запорол, Иван Иваныч или Абрам Абрамыч....

не все простои вводятся в ТОРО. Некоторые простои должны вводиться в PP, другие получаются из графика календаря (праздники). По простоям оборудования есть дополнительные транзакции, попробуйте запустить у себя DTR0. Юридически ее использовать можно только в SCM. посмотрите еще на ноты 333382 , 381137 .

... в дополнение к вышесказанному...
типы дефектов и коды причин должен предоставить бизнес, скорее всего уже все разработано до Вас.. и раньше (до ЕRP систем)велся анализ...технологические нарушения расследовали комиссии, заполняли Акты установленной в отрасли формы.. и даже какую-то автоматизацию внедряли...в энергетике, например, была АРТН2000, в ней есть готовые коды типов и причин дефектов.. и простои учитывались по типам (дефекты конструкции, ремонта итд) а не по фамилиям...

ещё вопрос. Есть ли у кого-нибудь практика ведения причин + первопричин, если есть то как это реализовано ?

Есть такая практика:
1. Происходит отказ оборудования, назовем "Установка". В сообщение на вкладке "Причина" заносится первоначальная причина отказа из группы кодов "Причины отказа".
2. Установка состоит из насоса, двигателя, кабеля и т.д. Это оборудование дефектуется на участках ремонта - выявляется отказавший узел и причина отказа этого узла. Служба ПТО заносит результаты дефектации в соответствующее сообщение на вкладке "Причины" из других групп кодов.
3. В какой-то момент проводится ПДК (расследование), на котором определяется виновная сторона. В соответствующее сообщение на вкладке "Причины" заносятся заключение ПДК и виновник.
4. Организуем свой отчетик и анализируем данные - сколько, какого, почему и кто!
Вот примерно так.

реализовано ровно так как предлагает стандарт. По каждому сообщению вахтой вносится информация по внешнему проявлению дефекта/инцидента-то что первоначально обнаружили...-1 справочник-2-х уровневый по видам оборудования
- после ремонта или расследования -появляется истинная причина- 2-й справочник- тоже 2 уровня -причина дефекта/инцидента- может совпадать, либо отличаться от первого справочника( мы взяли готовые коды в службе производственного контроля). Инфу по дефектам может вносить исполнитель или закрывающий сообщение. По инцидентам коды может вносить служба контроля прямо по Актам расследования.(они давно формализованы)
- для укрупненного анализа создается 3 -й справочник- тип дефекта( дефект изготовления. монтажа, проекта и т.д.)
Обработку каталогов можно отдать технологам по QS41, самим тока запросы таскать
..глубже вроде никогда и не требовалось, а доп инфу всегда можно прикрутить в любых объемах.