Copying Standard Transaction (MM01) to a Z Transaction (ZMM01)

[Former Member]

Hi guys. I have a question regarding the topic mentioned in the header.

Our customer wants a copy of Transaction MM01 in order to make some changes (e.g. adding a customized number to material, etc.) and accelerate copying materials. The big point in this is: MM01 should remain unchanged so the functionality of MM01 should remain the same! Hence BADI implementation or user exits are off the cards.

However my question now is if this is generally possible and if yes how. Because i tried to copy the underlying program of MM01 which results in an error and also if i just copy the Transaction (in SE93) it says that there is an error "the transactioncode ZMM01 is missing in table T130M". However i do not want to make any changes to this table though but what i want is to simply copy the program of MM01 with all Dynpros etc and make changes in the respective places in order to achieve the result which is expected by the customer.

And please do not ask questions regarding "why?" or questioning the meaningfulness of that 'project', please just try to help me fixing that problem or at least give me some hints to another solution (if there is any, I dont think so)..

Thanks in advance!!

Regards Patrick

[ThomasZloch]

OK, so no asking "why", just my personal opinion:

This customer request is nonsense, there is no way of doing this in a stable and sustainable way.

Thomas

[Former Member]

Hi thomas, thank you for your fast answer. I no that this sounds like nonsense but that's the required task. what i first thought is to copy the transaction and make a screen variant. Then, within the copied transaction, making a change in the code where i add the customized number and so on. But the problem I have with this approach is that i do not know how to copy the whole MM01 Transaction including program and so on in an appropriate way.

Regards

[ThomasZloch]

There is no simple way to copy such a complex transaction. You already ran into the issue with the standard transaction code appearing in customizing tables.

Maybe you can investigate along the lines of a an add-on or wrapper transaction, that calls standard MM01 where needed.

Thomas

[Former Member]

I think Thomas's approach of the wrapper transaction is the best. Add you BADIs/EXITs and program so that they only process if the calling program is your custom one.

Rob

[rub_alfonso]

Fully agree with Thomas.

Sorry but no answer for nonsense "solutions".

First, explore EXITs/BADIs solution.

Regards.

[raymond_giuseppi]

So you don't want to use a solution as Additional Fields on the Material Master or SPRO Logistics General, Material Mastre, Configuring the Material Master, Create Programs for Customized Subscreens?

There you could condition activation of your customer field by transaction code (e.g. if sy-tcode+0(1) NE 'Z'. then SCREEN-ACTIVE = '0' for your added fields.) Just add the field and 2 PBO and PAI modules in the copied dynpro. maitain those modules in the FG generated by SPRO.

NB: If you copy the main program and transaction codes then you should (MUST) either add records in some control tables as T130M or change the key used in the related SELECT statements, so in both cases you have to identify tables and/or access to tables, and some may be coded in FM not yet copied... (So good luck, and don't forget to leave before next upgrade )

Regards,

Raymond

[Former Member]

Hi! Thanks a lot for your reply, that could probably be an approach, just have to check if this way would satisfy all customer needs.

However, the last recommendation of yours made me laugh though because that's what I said to our consultant.

As discussed with him, they are aware (!!) of all the risks and cases which can occur. So I am quite confused, but nevertheless this has to be done and I am just looking for a quick and simple solution to that problem but as it seems this will not be as easy as thought in advance

[kiran_k8]

Patrick,

Sometimes Customers ask vague requests.Acutally these kind of vague requests come from End Users who don't have much knowledge about techincal pros and cons.This is where the Functional Consultant role comes into play.FC should discuss and then propose alternate solution within the limits of SAP so that sanctity of SAP stays on taking into consideration the pros and cons of playing with MM01.Raymond's suggesstion is very nice and you should sit and explore that option after discussing it with FC.

If the Customer doesn't know that such kind of vague requests disturbs the stability of the system,then it is the Consultant (Functional/Technical) who should pitch in and make him understand.At the end of the day that is what a Consultant's role is 🙂

K.Kiran.

[raymond_giuseppi]

they are aware (!!) of all the risks and cases which can occur.

Insure they wrote it, and keep the mail

[Former Member]

As the cons were stated already - you can, e.g. create a custom transaction, which would use a BDC or a submit / call transaction from there. So you can build your entry point from the ground, with (almost) all customer's needs.

When implementing BADI's, you could decide on the value of your called transaction. So using this approach, you would not be copying any global parts, would code into predefined places (implitic / explicit exits) and your solution could be closer to the midpoint between what the customer wants and what you can provide.

[Jelena]

It's actually not unusual to get this kind of reaction in the SAP implementation ("we will have to go through HOW MANY screens???!!") but copying standard transactions is the lamest solution ever. This actually seems like a prime candidate for some UI like Personas or software like Winshuttle but really you'd be better off with anything other than this ZMM01 travesty.

[Former Member]

Hi guys! just wanted to let you know that the task is solved. The simplest way to fulfill the requirements was to insert a dynpro before opening the MM01 and pass the needed parameters to the Standard transaction MM01.

Thanks for your help!

regards