Уважаемые коллеги,

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

Настроили, запустили, работает….

Но до сих пор не можем своими силами решить один проблемный вопрос – обеспечить в SAP нормальный учет запасных частей, которые используются при оказании сервиса.

Да, есть стандарт, который определяет последовательность:
• IW31 – Создание сервисного заказа с позициями услуг (оператор сервиса);
• IW3K - Выбор материалов для сервисного заказа и резервирование на обычном складе (консультант сервиса);
• MB11 - Списание материалов в расход (кладовщик).
И далее закрытие - Подтверждение выполненных работ - IW41, Преобразование сервисных позиции в позиции SD - DP90, Техническое закрытие сервисного заказа IW32 (оператор сервиса).

Схема не сложная, но для наших требований не подошла по ряду причин:
1. Выданная запасная часть может не подойти, а при ее возрате-обмене потребуется сторнировать списание в расход;
2. Использованные по такой схеме материалы не могут быть включены в сбытовой заказ, как следствие, по ним не может быть указана цена!
3. Ремонт автомобиля может занять продолжительное время и при этом списание материалов и фактурирование реализации пройдут разными днями, даже разными периодами – создает очень серьезные вопросы в налоговом учете.

Ради обеспечения требуемой аналитики учета, возможности в любой момент времени легко определять текущий статус запасной части, внедрили более сложную схему:
a. IW31 - Создание сервисного заказа с позициями услуг (оператор сервиса);
b. IW3K - Выбор материалов для сервисного заказа (консультант сервиса);
c. ME21N - Создание заказа на перемещение с обычного склада на сервисный склад (консультант сервиса);
d. MIGO_GI - Выдача материалов с обычного склада (кладовщик обычного склада);
e. MIGO_GR - Прием материалов на сервисный склад (кладовщик сервисного склада);
f. IW3K - Резервирование материалов на сервисном складе при выдаче мастеру (кладовщик сервисного склада);
g. IW3K - Создание заказа SD из сервисного заказа (консультант сервиса);
И далее закрытие - Подтверждение выполненных работ - IW41, Преобразование сервисных позиции в позиции SD - DP90, Техническое закрытие сервисного заказа IW32 (оператор сервиса).

Да, в любой момент времени можно легко определить статус запасной части, перед закрытием удобно проверяется, что все запланированные под конкретный сервисный заказ материалы уже переданы с обычного склада и выданы мастерам для установки – любое обнаруженное отклонение должно быть исправлено до закрытия. Но используемая схема, как бы мы ее не нахваливали, является сложной и громоздкой! Для обеспечения ее работоспособности пользователям с совершенно разными задачами приходится предоставлять право работать с одной и той же транзакцией (IW3K). На этапе формирования заказа на перемещение приходится повторно заниматься выбором материалов….

Что в итоге?!
Стандартная схема не может быть использована из-за недостаточной аналитики и управляемости.
Расширенная схема используется, каждый шаг совершается по конкретному событию и уровень аналитики более чем достаточен, но схема громоздка и излишне трудоемка.

Как быть?!
Может в рамках стандарта можно сконструировать другую схему?
Или просто начинать разрабатывать набор Z-решений, которые сделают используемую схему более простой в эксплуатации? Но чтоб принять решение пойти по Z-пути стоит изначально узнать, что все другие варианты уже отклонены.

Будем рады любым советам, подсказкам.
Готовы ответить на любые уточняющие вопросы.

Добрый день, I♥Georgia,

Удалось ли получить ответ на запрос?
По существующему опыту, люди смело идут на Z-допиливание, особо не мучаясь.
Здесь стоит вопрос: сколько в наличие есть ABAP-разработчиков и возможность поддержки всех этих вещей.

Добрый день, Yalo.

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