Нужен совет. Необходимо автоматизировать создание ОЗМ с помощью потока операций. Можно ли такое реализовать без z-разработки?

Уточните, пожалуйста, что значит "автоматизировать создание ОЗМ"?

Совсем без z разработки, думаю, не обойтись - скорее всего потребуется как-нибудь расширить стандартный бизнес объект BUS1001. А идея реализации как и в ОС - после создания ОЗМ сразу заблокировать (возможно подойдет поле MARA-MATFI, но надо спросить у MM), потом передать ответственному, который либо разблокирует, либо вернет с замечаниями.

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

У нас на проекте подобный функционал был реализован следующим образом с использованием разработок.

Был создан Z-бизнес-объект, содержащий некоторые ключевые данные для материала. При старте потока операций в нём создавался экземпляр этого Z-объекта. Для заполнения полей Z-объекта была создана программа, на первом экране которой находились поля. К программе была создана транзакция с несколькими вариантами, соответствующими разным департаментам. В каждом варианте поля, релевантные для данного департамента, были открыты для заполнения, а нерелевантные были заблокированы.

Для Z-бизнес-объекта были созданы методы вида EDIT_DEP1, EDIT_DEP2 и т.д., в коде каждого из которых был указан запуск транзакции с вариантом для данного департамента. На основе этих методов были созданы стандартные задачи (TS...) и помещены в поток операций.

Таким образом, например, в Департамент 1 приходит шаг потока операций, при запуске которого пользователю доступно заполнение полей, релевантных только для данного департамента.

Lexxxy! Сможете хоть чуть подробнее описать или схемку? Идея классная. Буду рада всему, что дадите.

В нашем проекте мы подразумевали, что есть некий документ – «Заявка на создание ОЗМ», где перечислены основные данные для создания будущего материала. Например, вес, имя, базисная единица измерения. Также подразумевается, что в заявке может быть несколько позиций. Таким образом, создаём таблицу, где будут храниться данные всех заявок, и куда мы будем обращаться, чтобы затребовать необходимую информацию. К ключевым полям таблицы будут относиться номер заявки и номер позиции заявки.

Далее создаём Z-бизнес-объект, у которого будет одно ключевое поле – номер заявки. К событиям Z-объекта нужно добавить события Created (Заявка создана) и Changed (Заявка изменена).

Для примера рассмотрим процесс, в котором участвуют три департамента: в первом заполняют имя будущего материала, во втором – вес, в третьем – базисную единицу измерения. Когда в первом департаменте заполняют имя материала и сохраняют заявку, генерируется событие Created (Заявка создана) и запускается поток операций (где в стартовом событии указано Created). При сохранении заявки происходит запись данных в нашу Z-таблицу (это наши внутренние данные, создания материала не происходит).

Пишем Z-программу, где на первом экране отображаются три поля ввода: имя, вес и ЕИ. Для первого департамента создаём вариант, где доступно для ввода только поле «Имя», а остальные поля заблокированы. Существует возможность ввести имена для нескольких позиций заявки, нажав на кнопку «Добавить позицию». Также будет хорошо добавить на экран поля «Номер заявки» и «Номер позиции», недоступные для ввода и заполняемые автоматически. При нажатии на кнопку «Сохранить» происходит запись данных в нашу Z-таблицу и генерируется событие Created (Заявка создана).

Далее создаём варианты транзакции (или отдельные процедуры в программе) для работы двух других департаментов, где для каждого из них будет доступно своё поле для ввода. После того, как каждый из последующих департаментов завершает свой ввод, генерируется событие Changed (Заявка изменена).

В Z-объекте создаём диалоговые синхронные методы для каждого департамента. В коде метода указан запуск транзакции для соответствующего департамента и передача необходимых параметров (например, номера заявки).

На основе методов создаём стандартные задачи, из которых строим поток операций. Поток операций стартует от события Created (Заявка создана). Для шагов потока, относящихся к двум департаментам, завершающим событием будет являться событие Changed (Заявка изменена). Чтобы сгенерированное событие Changed не повлияло на другие потоки того же типа, в дополнительном условии можно поставить проверку на номер заявки и департамент. Это позволяет однозначно идентифицировать шаг потока.

На финальном шаге потока ответственному сотруднику, запускающему MM01 и создающему материалы, в потоке операций приходит шаг типа «Решение пользователя» с одной кнопкой «Создание материалов завершено». Во вложениях (Attachments) к этому шагу передаётся экземпляр нашего Z-объекта. Здесь хочу немного отклониться от повествования и сказать, что для Z-объекта стоит создать метод для просмотра заявки. И сделать этот метод методом по умолчанию. Тогда если этот Z-объект будет в вложении к шагу потока операций, при щелчке мышью на него заявка откроется на просмотр. Таким образом, на финальном шаге сотрудник открывает заявку на просмотр, создаёт материалы и нажимает на кнопку «Создание материалов завершено».

Понимаю, что возможны другие варианты, но сейчас у нас это работает так.

Lexxxy, здравствуйте! Из ответа видно, что и вам помогали в этой жизни, что вы такой не равнодушный. Спасибо за сочуствие. А терепь вопросы:что значит позиции? Как быть с расширением на заводы, рынки сбыта или это и есть позиции материала?Даные к ракурсу качества тоже можно ввести в z-таблицу?

Рад, что мои советы оказались в какой-то степени полезными

По вопросам:

1) В нашей логике по одной заявке может быть создано несколько материалов. Одному материалу соответствует одна позиция заявки. Это выглядит примерно так:

№ заявки|№ позиции|Имя материала|Вес..|
----------------------------------------------------
1...........|1.............|Материал 1...|1,000|
1...........|2.............|Материал 2...|1,500|
1...........|3.............|Материал 3...|2,100|

То есть по заявке №1 будет создано три различных материала.

2) и 3) Признаться, я не очень хорошо разбираюсь в материалах, чтобы отвечать на вопросы о расширении на заводы и рынки сбыта, а также о ракурсе качества. Но поскольку структура Z-таблицы может быть задана как угодно, полагаю, что все необходимые данные в неё можно внести. Хочу просто внести ясность: в нашем процессе все предварительные данные для создания материала собираются в Z-таблице, затем ответственный сотрудник на основе этой Z-таблицы создаёт материалы через MM01. Если вам требуется действительно автоматическое создание, то на последнем шаге потока должен быть фоновый шаг потока на основе синхронного метода с пакетным вводом, который сам будет создавать материалы без чьего-либо участия.

У вас наверное материалы имеют мало ракурсов. У нас материалы FERT, HALB имеют почти все ракурсы и много полей. Я думаю у нас получится длинная структура z-таблицы. Я с 29.07 ухожу в отпуск, после выхода я хочу предложить руководству этот путь. Вы в дальнейшем мне поможете с методами и т.д. и т.п.? Мне кажется решение удачное. А просмотр данных из z-таблицы вы сделали в smartforms , эти данные можно вывести на печать или не было нужды?

Наверное, у нас действительно не так много ракурсов к материалам. Во всяком случае, в MM03 я не заметил ничего, что могло бы относиться к качеству. Возможно, после периода отпусков в этот форум вернутся специалисты более высокой категории и подскажут изящное решение вашего вопроса. Если вы всё же будете реализовывать поток операций по моей схеме, я помогу вам в рамках своих знаний модуля SAP Business Workflow.

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

Я вам очень признательна. Будете у нас на Колыме-заходите ! А вы в отпуск не собираетесь? Если да, то хоть приблизительно когда?

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

Так ведь связка MM11 - MM13 делает ровно то же самое - MM11 записывает данные в таблицы PCDHDR + PCDPOS, а MM13 на основе этих данных создает материал. На мой взгляд, гораздо проще насоздавать вариантов транзакции MM11 для разных отделов с разными ракурсами, и затем вызывать в пакетнике MM13. Или я неправ?

Привет борцам за ОЗМ!
Сережа! Vне с самого начала моей проблемы понравилась идея с мм11-мм13. Решила создать бизнес объект для workflow (swo1) и не нашла фм для мм11. На форуме http://www.sdn.sap.com/irj/sdn сказали, что нет фм для мм11. Как быть дальше? Как создать методы create, display, edit для этих транзакций?

Ваш юзер будет ведь в диалоге вызывать MM11? Зачем тогда FM?