on 01-20-2011 10:53 AM
Hi,
We keep getting purchasing group changes requests and we follow conventional approach, configure in development - move to Quality and then to Production.
Since we have high number of requests, we are exploring the direct maintenance in Production system. Please advise on the best approach to this.
thanks
Mahesh
Not advisable since you would need keep the production client open.
S. Kumar
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Got the information..thanks to all...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for inputs,
we are doing a check on all options and then decide the best approach
From data consistency wise, we are cheking of options updating directly in each system or quality gets refreshed from production once in a month.
If we want to take this apporach of updating directly in production, what are the solutions for it.... what authorizations are required...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
there is an alternative missing.
you can change a customizing activity to be a master data activity, and you do not need to have the PRODuction system open for customizing..
this is explained in OSS Note 135028 - Transfer IMG activity to current setting
However, I have made my experience in the past when I joined my current employer. In this system the purchasing groups were maintained in production system, which I did not know, and some key user did not know too, as they asked me to add a new purchasing group. I did this in the development system and transported to production.
And it happened, that I added a purchasing group in development that was already occupied in production, so the entry in production got overwritten with my transport. So for a couple of days 2 buyers worked with the same purchasing group, they did not even realize it, as nobody is really looking at a PO form if a system is live for many years. This caused some trouble with statistics and as well with communications between vendors and us.
A second experience was made by the fact that people had deleted purchasing groups, after buyers had left the company. But SAP validates the existence of purchasing groups when archiving purchase orders. So I had to recreate all deleted purchasing groups before I could continue with archiving.
I think that this experience is reason enough to not give this customizing activity into user hands.
It is not advised to open a client to do this trivial changes on the purchase group.
what happen if you open a client ,if any one has access any piece of configuratyion can be changed.
i believe your basis team will not allow to do open a production client for a while .It requires lot of approval process might be built up in our organisation.
Hi Mahesh,
as very well said by Mr. Kumar, Not advisable, because when you will do the client copy from Production the Pur grps are available in PROD, and not in any other client, henceforth there will be data inconsistency.
Please avoid that.
Regards,
Yawar Khan
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You of course cannot keep Prod open so doing the config step in SPRO is out of the question.
What you can try to do is develop a custom program that will update Purchase Groups.
The selection screen will be similar to what we see on the config step.
The user will enter the data that he wants to update and on saving, table T024 will be updated.
The users authorisation will be checked against the purchase group he tries to change.
To create a new grp, you can have authorisation provided to only one user.
Since this will be a direct table update for T024, take care of database locks.
Also ensure compliance issues are taken care of.
If you do go for create function, make sure you have the change replicated in Dev/QA at least on periodic basis.
Otherwise you end up with grps existing in prod but not in Dev.
This solution can be implemented to ensure that Pur. Grps. data is updated quickly in prod, i'e., to bring down change turnaround time
It is always prefferd to go via the standard dev/qa/prod approach.
Hi,
How you are doing in production? Is it client open and making necessary changes?
Better to do in DEV and transfer to production.
Arun
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
108 | |
12 | |
11 | |
6 | |
5 | |
4 | |
3 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.