Question:
Hi experts,
our production system is currently not closed for customizing. A reason is that the business insists on making some customizing changes directly in production (e. g. define account groups, maintain document types). As a result the system cannot be closed. Would it be possible to define these specific tables as non-customizing (like e. g. the currency or posting period tables) so that we could close the system but still let them make their changes.
I am aware that this is not the right procedure and I already went through a lot of discussions. My question is to find out if this is possible from a technical perspective?
Thanks
Franz
Answer:
Hi experts,
our production system is currently not closed for customizing.
That's bad!
A reason is that the business insists on making some customizing changes directly in production (e. g. define account groups, maintain document types). As a result the system cannot be closed. Would it be possible to define these specific tables as non-customizing (like e. g. the currency or posting period tables) so that we could close the system but still let them make their changes.
I am aware that this is not the right procedure and I already went through a lot of discussions. My question is to find out if this is possible from a technical perspective?
Thanks
Franz
The technical solution is described here.(look for "current settings".)
Your highest priority should be to close production as soon as possible, and if the price is to make account groups current settings, so be it. A better solution would be to transport these changes or open production selectively. If changes to account groups occur more than twice a year, you've got an FI-problem.
How do you prevent unauthorized changes to account groups in production in your scenario? Are you aware of the risks (CpD-Konten, abweichender Zahlungsempfänger etc) and what this does to your internal control system? To me your current situation sounds like a security nightmare, and so does your anticipated solution!
Have fun,
Marc
Answer:
I'll only eccho the previous post. THere is ALWASY a cost of doing business and you are NOT in the busineess to do what the USER LIKES but operate the business in a controlled, ethical, profitable and secure method. The business does not revolve arround the users but the customer.
There is a STRONG reason called CHANGE MANAGEMENT ,one of the foundations of a controlled environment, that Is the foundation of SAP and why the tables are classified as customizing or not. With your current scenario you might as well give everyone SAP_ALL... Or give me an id for 15 minutres in your scenario and you'll have no assests to worry about.
Answer:
Hi
This may happen in real life situations but the best way is to take help from your basis folks and keep the system closed (SCC4 and SE06) and then open the system selectively on need basis. These are stupid arguments from the FI dept that they have to do config in Prod. If it is config, it has to be in dev->Q->prod. No compromises what so ever. If it is master data like defining CO hiererachy etc then its fine to do them in Prod.
Hope this helps.
_________________
SAPFAN
Answer:
In addition to the arguments previously stated, your Prod, QA and Dev systems are all now out of sync. This is going to create more problems down the road.