How Could I create this scene in SAP MM-WM?

[Former Member]

Hello Guys,

I am testing a work around in Testing enviroment, but I need to have zero stock of a material/Batch in MM and the a negative quantity of the same material in a non interim storage type of the same material/Batch? How could I do this? which steps I would need to follow, supposing that now I don t have stock neither in MM nor in WM....

thanks!

[former_member318507]

Hi,

You can do this by two options

Option-1. Request your basis team to do a system Refresh from production to test system. ( It will copy eveything from production to test system) Or wait for your test system to gets refreshed from production.Generally every company does it periodically either once in 6 months or once in a year.

By this you dont need to replicate the same scenario like production, once the refresh is done, you can refer the same scenario in your test system with same document #.

Option-2: (Some times it will work, but depends on you latest version of hot pack versions)

Step-1: Create PO- Inbound delivery- TO- confirm TO.(Dont do PGR)

Step-2: Go the LT0G , and cancel the document. Make sure line turns green.(If required confirm the TO)

Step-3: Again create TO & confirm the TO.(Dont do PGR)

Step-4: Go to LT0G and cancel the document.( some times it will turn green or some times you will error)

Step-5: Now go and check your MM stock ,it will be zero, but check your WM stock it will show you negative stock.

[mihailo_sundic]

If you, for any reason, really need to create this inconsistency, there are no specific steps to follow since it is a thing that happens as unplanned, but you could create it for example by forced creating false stock in WM, e.g. SE16N + &sap_edit.
You can create a quant in LQUA, update WM tables with stock info but leave MM tables un-updated.

[joao_sousa2]

Let's just point out that this an excelent way to start your field trip into Mount Doom if you do it in production. From my experience all it takes is one innocent SAP_EDIT and in no time the system becomes an inconsistent mess that nobody trusts.

[JL23]

This edit function is disabled in newer releases as it can be read in OSS note 1420281 - CO-OM tools: SE16N: Deactivating &SAP_EDIT

[mihailo_sundic]

Surely, this is not recommended to be used in production.
I am guessing Sil wants to reproduce the case on sandbox for testing purposes, if not Sil, if you are doing this on production, please DO NOT use &SAP_EDIT function.

Yes, &SAP_EDIT is disabled in newer releases but can be forced by easy 10sec debugging.

1) Go to SE16N and type the table name you want to deal with

2) Instead of typing &SAP_EDIT in the command window, type /H to activate the debug

3) Hit the F8 key to enter the data browser for the table you typed on step 1)

4) While in debug, type the name of the following two global variables on the right panel: GD-EDIT and GD-SAPEDIT

5) Change the values of BOTH variables to an uppercase X

6) Finally, press F8 to exit from debug
as shown in thread:

Again, by no means &SAP_EDIT is not to be used in productive environment, but only on systems that are used for testing purposes!

[joao_sousa2]

And now many people know something even worse then SAP_EDIT. We know that route, I didn't mention it because the fewer people know it, the better, at least SAP_EDIT leaves a trace.

[JL23]

in good secured systems even this debug way would not be possible.

I fully agree to Joao's statement as this was for me the main message in the note: "ue to the circulation of this function in the Internet, security breaches have been detected ..."

hence we should avoid to spread such information widely.

I already fear that I come someday to a surgeon who knows from the Internet how to do it.

[Former Member]

Yes, these functions are very dangerous. Seen some really messed up data recently as tables were updated directly in Production to match numbers. Consultants says no and client access to google searches and language skill does a mess.

Shouldn't we hide these kind of posts which are freely available. If there are such constraints it is always better to raise to SAP.

[mihailo_sundic]

In reply to all three of you talking about dangers of &sap_edit. I do partially agree... However:

From my point of view this is not a problem of availability of &SAP_EDIT usage instructions.
The real problem is giving uneducated people access to &SAP_EDIT and many other functions. But that is a much more critical problem than availability of instructions on the internet. It is a problem of security policies and authorizations in SAP system for which SCN users cannot be responsible.
Further, if you empower a user that has no idea about the dangers of some functions in SAP to solve you the problems that are very difficult and require highly skilled professional, than no I wouldn't blame it on anything else than on awful  sap team management and finally very risky business decisions.
So number 1 reason IMO is bad sap team management, and number 2 reason would be catastrophical auth/security policies. Availability of this info on i-net would be very low on my list of reasons, it is just one of the factors, but not even remotely important as the two I have mentioned above.

Excuse me but having google search and language skills and info on SCN is not a problem. The problems are just as I said in previous paragraph. Surely everything would be fine if they didn't speak English and/or they didn't search or couldn't find some info on SCN. With all due respect, I don't think so.

So, if you have a user that missuses &SAP_EDIT in the system which creates some huge problem or inconsistency, and you were the system admin, would you blame it on the availability of instructions on the internet or your security/user policy, or maybe even language skills? I am not for any kind of censorship, this is a backward approach to this problem (and any problem) in my humble opinion. Yet, not having instructions on &SAP_EDIT on SCN will keep many clients safe? Maybe we should restrict info on some more functions, since if user has &SAP_EDIT authorization than most probably it's SAP_ALL user and has accessibility to a huge number of dangerous transactions.
Maybe compiling a list of safe / dangerous functions would be a prelude to this.

From my point of view, again, SAP is a serious system and requires such approach in authorization definitions. If you did restrict &sap_edit from every user (these kinds of users that can mess up the system by using &sap_edit), these kinds of users will have one less way to mess up the system, but will still have a huge number of possibilities for that.

I do approve using &SAP_EDIT in sandbox systems and see no problem with that, but only in situations when you want to test something on sandbox that's happened on production but you have no other means of recreating the problem. And this is for the sake of testing the solutions on sandbox so that we can have a safe solution not implemented directly on production. As far as I can see, this user has stated "in Testing environment". Yes, this is a serious user at the first look, he has an inconsistency on PROD, wants to recreate it on testing system and find the best and safest solution.
Option 1: Let's tell him about &sap_edit since no other solution for recreating the problem was proposed and most probably won't be considering the problem type.
Option 2: Let's keep quiet about &sap_edit so that user can't recreate it since he will use &sap_edit to mess up the system eventually, so let him try fixing the problem directly on production, might be a bit dangerous too if he is as uneducated as we assume, but it seems safer. Does it?

Again I emphasize that uneducated users shouldn't be allowed &SAP_EDIT access in the first place, and we cannot know which users are uneducated, it is responsibility of every company to keep the dangerous transactions out of reach from any uneducated user. Not only this one but all other functions.
If we have to babysit some of them, you will lose the game, STARTS with allowing uneducated users having SAP_ALL or access to DEV licenses. So babysitting stops when users get mature. If they don't then it's a huge problem far deeper than &SAP_EDIT availability.

And yes, I know that some companies having SAP have problems with this, but if you want to allow uneducated internal users use functions that are dangerous, than you are calling for trouble and taking a huge risk. Not a &sap_edit related problem.

Further down this thought flow(that not only &SAP_EDIT is dangerous), a lot of SPRO customizing steps (not to mention SE80/38) can make such problems that are very hard to repair, so there are a lot of accessible things in SAP by which you can mess up the system, and yes, &SAP_EDIT is the master of dangerous functions in SAP but considering the number of messed up systems I bet &sap_edit wouldn't make it in the Top 5 causes.

I have seen so many stupid things done in SAP and yes in some of those there was a factor of "instant-knowledge" involved, but in every single one of them there was bad security policy / auth issue and/or bad internal SAP team management. Bad is an understatement.

You can teach a man to light a fire, but you can never know how he will use it.

[joao_sousa2]

It is a problem of security policies and authorizations in SAP system for which SCN users cannot be responsible.

I agree, and yet even last week a customer asked me to teach him to how to edit tables and I refused. I know he can go to the internet and find out on his own, but at least I made it a little more difficult.

And many times we are talking about IT people that have access to authorization management, and can change them if they want to. Good luck telling the IT administrator that he can't have SAP_ALL.

Anyway this topic has been widely discussed, and people will never agree on the correct way to handle dangerous knowledge.

[JL23]

You want create an inconsistency?

And you need this inconsistency to test a workaround?

Without inconsistency in a system nobody would need a workaround, hence I think you have this situation already in your production system, right?

Wouldn't it be better to analyze how it came to this inconsistency and then eliminating the root cause instead of developing a work around?

If you are already in the process of looking for a workaround then I would assume that you know the root cause and think you cannot avoid it in your process.

[joao_sousa2]

You want to have an inconsistency between MM and WM? Or a positive quantity in a interin storage to match the negative in the non-interin?