Post golive

hi SAP gurus,
1.Solving Post Go.live enduser issues. What is this?
What is the meaning of post golive issues. Plz do explain.
2. Why to give common Dis.channel and common Division. what is the use .

hi,
post go-live end user issues- wen the system has been throughly tested and configured and the changes are moved to the production server so that the end user can work on the new application, he may come across issues like that of master data, screen transition, BPR chnages etc.
common DC and Dv are basically to enable extension of master data to other sales areas, thus reducing wrk.
saurabh

Similar Messages

Best practice for a deplomyent (EAR containing WAR/EJB) in a productive environment

Hi there,
I'm looking for some hints regarding to the best practice deployment in a productive
environment (currently we are not using a WLS-cluster);
We are using ANT for buildung, packaging and (dynamic) deployment (via weblogic.Deployer)
on the development environment and this works fine (in the meantime);
For my point of view, I would like to prefere this kind of Deploment not only
for the development, also for the productive system.
But I found some hints in some books, and this guys prefere the static deployment
for the p-system.
My question now:
Could anybody provide me with some links to some whitepapers regarding best practice
for a deployment into a p-system ??
What is your experiance with the new two-phase-deploment coming up with WLS 7.0
Is it really a good idea to use the static deployment (what is the advantage of
this kind of deployment ???
THX in advanced
-Martin

Hi Siva,
What best practise are you looking for ? If you can be specific on your question we could provide appropriate response.
From my basis experience some of the best practices.
1) Productive landscape should have high availability to business. For this you may setup DR or HA or both.
2) It should have backup configured for which restore has been already tested
3) It should have all the monitoring setup viz application, OS and DB
4) Productive client should not be modifiable
5) Users in Production landscape should have appropriate authorization based on SOD. There should not be any SOD conflicts
6) Transport to Production should be highly controlled. Any transport to Production should be moved only with appropriate Change Board approvals.
7) Relevant Database and OS security parameters should be tested before golive and enabled
8) Pre-Golive , Post Golive should have been performed on Production system
9) EWA should be configured atleast for Production system
10) Production system availability using DR should have been tested
Hope this helps.
Regards,
Deepak Kori

Best Practice for Production environment

Hello everyone,
can someone share the best practice for a production environment? or is there a SAP standard best practice to follow in a Production landscape?
i understand there are Best practices available for Implementation , Migration and upgrade. But, i was unable to find one for productive landscape
thanks.

Hi Siva,
What best practise are you looking for ? If you can be specific on your question we could provide appropriate response.
From my basis experience some of the best practices.
1) Productive landscape should have high availability to business. For this you may setup DR or HA or both.
2) It should have backup configured for which restore has been already tested
3) It should have all the monitoring setup viz application, OS and DB
4) Productive client should not be modifiable
5) Users in Production landscape should have appropriate authorization based on SOD. There should not be any SOD conflicts
6) Transport to Production should be highly controlled. Any transport to Production should be moved only with appropriate Change Board approvals.
7) Relevant Database and OS security parameters should be tested before golive and enabled
8) Pre-Golive , Post Golive should have been performed on Production system
9) EWA should be configured atleast for Production system
10) Production system availability using DR should have been tested
Hope this helps.
Regards,
Deepak Kori

Need help with Firefox display issue on one page of site

I have a page that W3C validates, displays properly in IE and Netscape, but does not display properly in Firefox. The issue is with a style class applied to the inner centered table. class= "vert_table" This class works on all of the other pages in the site, but not in this one.
The page:
http://www.redshift.com/~lorac/sdy-46-49.html
The issue:
< table class="vert_table" width="760" border="0" cellspacing="0" cellpadding="0" align="center" bgcolor="#f1ebe8" >
The vertical rule does not display, and further down the page a dark left-right border appears starting with this text.
my mother, when I was wasting my life away not knowing who I was,
and ends with:
Mojin: (hugging him) I don't expect you to love me. I just want you to live, that's all.
I have been looking through this code for two days, searching for any offending omission in code or redundancy that would break the page. I've searched for missing div tags but none are apparent to me. I'm hoping someone with fresh eyes can spot it right away.
It's odd that the page validates but Firefox cannot display it properly.
Sample page of code working properly:
http://www.redshift.com/~lorac/sdy-41-45.html
Any help is appreciated.

Hi Jim, thanks for the reply. Your suggestions sound interesting but I'd like to figure out why this particular page doesn't work when all of the others do. I'm sure it's just a little code thing that I'm overlooking.
I could revert back to a saved page, but I updated text and images on this page before the verticle border broke, so I don't want to lose those edits. And that is why I'd like to fix this one instead of redesigning the page.
BTW, I forgot to mention in my first post, GoLive CS, W2K.

Vendor to vendor entry

hi,
The case is wrong entry done in vendor a/c instead of entered in one vendor entry made to other vendor a/c now how to clear it & that entry related opening balance related to initial upload
Because while passing JV thorough fb01 hitting error of Balancing field profit center in line item not filled
please guide me.

Simply reverse the entry using FB08 and upload again with the correct vendor.
If the entries are happening post golive and this was discovered in post golive, then simply open the psoting period of uploads, and then pass a rectification entry.
First Credit the Upload GL account and then Debit Vendor who was wrongly credited with the Balance.
Secodnlt Debitthe Upload GL account and then Credit the correct vendor. Make sure that the Gl line item contains teh Profit center as in vendor line item you cannot gve Profit center.
Reward if useful.
sarma

Re-sizing SAP

Hi Experts,
We have ECC 6 system, the SAP was implemented a few years ago.
We are rolling out new businesses to the existing system using same customization template, also there will be additions to users.
From sizing perspective this categorises as re-sizing part of post golive activities.
To ensure we have enough system capacity to handle the load of new rollouts we need to calculate for additional CPU, Memory, application server and disk requirements. We have to go for re-sizing exercise. SAP recommends not to use the Quick Sizer for re-sizing. I would appreciate if you can re-direct me to the detailed SAP documentation's which describes step by step approach for re-sizing. Also any sample resizing exercise document should be a good help.
Thanks and Regards,
Gautam Patil

Hello Gautam,
Check SAP note 85524 - Sizing SAP Business Solutions (e.g. with the Quick Sizer):
How to size for additional load (re-sizing)
Monitor CPU utilization, table growth, and memory usage
Relate it to a meaningful business entity, such as the number of concurrent users or the number of active projects
Add the load coming in through the additional users and projects causing the same load structure
Judge whether your current hardware is sufficient, or whether you may need to buy additional hardware
It seems there is not an easy way to do it as the Quick Sizer. About using the Quick Sizer what you can do is to create a new project with your current requirements and the new requirements (lets say a sum of both) so you will get an approximately idea of what you will need.
Best regards.

Mrp control parametrs

Hi, Pls advise what are control parameters need to maintain in mdbt variant for running mrp immeadietly after golive. pls note cutover data is uploaded and using strategy 20. pls advise.

Dear ,
Few Inputs regarding MRP run at Go Live and Post Golive situation :
1.Go Live time MRP run : Based on WIP posting , open orders (PR,PO,SO,STPR,STO) , Stock , you will run MRP for the frist time with Process Indicator -NEUPL,2,1,3,3,2 in MD02/MD03
2.After that you need to analysis the planning result -Net Rquerement (+/-) and lead time analysis , safety stock , replensihment pattern -weekly , month as per your business requirement
3.Basically , frequency of MRP run depends on the material lead time and order fullfill ment (Sales Order ,Independent Order ) .
4.It depends on the planning situtation -Demand Pattern and replenshment set up.For example , you have central plant-supplying plan and having 6 DC.The lead time of DC is 7 days from suppling plant and Vendor to Suppling plant 90 days .In thsi case , i hope u need to run MRP every month for DCs if you want to repleish monthly basis .Where as in Supplying plant every three months besaue of lead time .It depends on order fullfill ment and LT
Few parameters :
1.Stockable or non stockable material
2.Lead Time
3.Replishment strategy and RLT
4.Demand pattern -Order /In dependent
5.Safety Stock
6.Planning Structure
7.Validity of the Fcatory calander
8.WIP posting or WIP should cleared .
9.All the stock are updated or not .
Hope this will give you an idea on your requirement
Regards
JH

Contact Person - Mapping ECC-CRM

Hello,
Please suggest best practices of creating contact persons in CRM
Our scenario is existing customers and contact persons would be uploaded in ECC which need to be replicated in CRM
All new customers and contact persons would be entered in CRM only post golive.
User have multiple contact persons with different addresses for every corporate account in CRM
Thanks,
Satish

Hello ,
PIDE settings in ECC:
CRM--> ECC : B(Classification) - Z001 Ext Account Group of ECC
ECC-->CRM : 0001 Account Group - B(Classification) - 0001 - Ext No Range (ECC)
Z001 Account Group - B(Classification) -0002 - Int No Range (CRM)
Please suggest how to maintain Account group and number ranges for contact persons in ECC and CRM and PIDE settings for the contact person.
which classification need to be used in PIDE
Thanks,
Satish

ReSizing to existing retail system if activate batch management

Hi Experts
We have a SAP ERP retail system, the retail industry solution was implemented a few years ago.
We are implementing improvements on the existing Retail System (post golive activities), we add modifications in master data activating the batch management to materials.
We will be have additional users too.
We are adding load on the system with the additional users and we are increasing the disk requeriments for additional information (to the batch management) in the existing table records and
to the future records.
We have the latest version of the retail sizing questionnaire "Retail_Sizing_20080715.xls" obtained from http://service.sap.com/sizing but
I need to know if we have to fill it to obtain the new hardware estimation (taking into account it is not a new configuration, is a post golive activity).
Our scenario need a re-sizing because we are extending an existing system by load (additional users) and we need the calculation for disk requeriments to the additional
information and the calculation for CPU and memory requeriments to minimize the impact of these changes on the system performance.
Is the retail sizing questionnaire right to our scenario?
How I can to calculate the new load on the system?
Is right calculate the future load in our retail system monitoring the current resource utilization to CPU, table growth (and including new fields), and memory usage?
Thanks in advanced for your cooperation, please let me know if you need additional information.
omm

additing t o about post system also check if ur having stock for last year last period, it should be also zero
best this will be
make the stock zero and the change the indicator either in MM02 or In tabel MARC
and then post the stock back with batchs
hope this helps
Reward if usefull

Std cost strategy in Cutover

Hello,
I have a query related to Std costing in cutover period.
If client doents have any costing system in legasy system prior to SAP golive. If there is any stock in cutover and that is as per price control S then how the strategy to be applied in cutiver for std costing. If we calculated cost as per BOM and routing in cotover then ther are chances that the value of stock would be different than the legacy system stock value, and becasue of different price the inventory value in legacy system and SAP would be with huge different. so request you to please inform how the std cost is trated in cutover period.
Reg,
Harry

Hello Harry,
You would need to ascertain the basis on which the cost is being carried out in the existing system and then you need to take appropriate steps and follow the correct sequence to arrive at the cost at which the stock is carried in the legacy system. Now the question arises that whether the legacy system has some form of estimate for the finished and the semi finished goods or they are valuating the same at some standard price which does not necessarily correspond to the prices of the RMs and the activity types.
Scenario 1 : Material valuation is based on cost estimates
In this case what I mean is that the value of the FG & SFG would be based on the prices of the RMs and activity. In this case the first step would be to update the RM and stores prices with the prices at which they are being carried in the inventory. It should also be kept in mind that the pre-golive BOM and Routing should be same as post golive. The next step would be creation of cost estimate for FG and SFG that would correspond to the value at which they are being carried in the legacy system. Thereafter you can upload the FG and SFG stocks using 561 movement and the differences expected in this process is minimal.
This is the best course of action to be followed. Even though your legacy system doesn't have this level of details but it would be better to create some form of estimation and try to match the same in new SAP system would be better as your client would not be ready to write off inventory valuation just because of go live.
Scenario 2A : Material Valuation is not based on any estimates and Material Ledger / Actual Costing is not implemented.
In this case I can understand that the client would be able to provide item wise valuation sheet for FG but he would not be able to provide any breakup by CE. In that case it would be better not to create a cost estimate for FG and SFG before upload. Rather manually put the item wise prices in the system so that when you load the data the legacy matches SAP. Remember in all cases take the RM and stores at the prices they are being carried out in the inventory. After the inventory is uploaded then you can execute the cost estimate and you get entries in the revaluation account. This amount posted to revaluation account can be separately stored in another GL (a balance sheet account, say FG Valuation - Manual) and that is also carried on year after year or written off as per convenience.
(ii) In this case I assume that you would not be able to get even an itemised list of FG and SFG valuation and in that case you can create the cost estimate first , upload FG and SFG and then the difference would be there between legacy and SAP which can be posted to a Balance sheet account as mentioned in (i).
Scenario 2B : When you have Material Ledger implemented
In this case th job is a bit easier. If you have itemised costs for the materials then what you need to do is that in a excel file calculate the item wise difference of the FG, SFG and RM etc and then go to transaction MR22 and post these differences there debiting or crediting the materials. In this process the advantage is that for materials being carried in standard price the difference is posted to the inventory price variance account but the advantage is that this price variance account is taken care when the month end valuation of the inventory. Therefore the difference totals up with the inventory valuation.
Do get back with your scenario in order to get more inputs
Kind Regards // Shaubhik

Going live check service

hello all!
who knows the procedure of receiving "going live check session service" or something about the 'going live check '
Can anyone help me,or where i can find the document about it!
best regards.
zokii

SAP Going Live Analysis session is performed before start of major upgrade activities/migration etc. This pre session is performed before your task giving source system information and target system information and SAP runs the session based on that.
SAP Post GoLive analysis check is performed after your change and target system creation. Post session is to find out optimum settings for your system in terms of performance and other parameters or if you missed any specific settings etc.
You can request for both pre and post sessions via opening of message via SAP marketplace. They will send you a questionnaire to fill out with your system details. Once you send that sap will mark a date for the session in your system. You have to open remote connection/HTTP URL / WTS as required with login details to your system.
Regards,
Sandeep.

Testing general help

Hi Gurus,
I am soon going to start testing on an SAP upgrade project. Whats the best way to get myself prepared for the same? I am currently studying the client's Buiness processes, however there are just too many docs and these are getting me confused. Also I am concerned that all this time studying the docs is not wasted. If you have been in a similar situation before, please let me know how do you go about it. testing will be Functional + integration.

hi dave,
pls see the below matter i think it gives you a solution.
SAP R/3
Security Upgrades
                                                                                1.             overview
The purpose of this document is to provide additional information that could be helpful with SAP Security upgrades, especially pertaining to 4.6C.
This document is not aimed at replacing the SAP Authorizations Made Easy guidebooks procedures, but rather to complement these based on lessons learnt from previous upgrade projects.
It is focused mainly on upgrades from 3.1x to 4.6x and covers the following:
·        Evaluation of the Security Upgrade approaches;
·        Gotchas to watch out for with SAPs SU25 utility;
·        Transactions and authorizations that require special attention; and
·        Helpful reports, transactions, hints and tables to know.
It is highly recommended that you review the chapter on upgrades in the Authorizations Made Easy guide before attempting the security upgrade.
See OSS note 39267 for information on obtaining the Guide, or visit SAPLabs website at: http://wwwtech.saplabs.com/guidebooks/
2.             Security upgrade objectives, Process and approaches
2.1.               Objectives
There are a couple of objectives for having to upgrade the SAP Security infrastructure:
·   Converting manual profiles created via SU02 to activity groups, as SAP recommends the use of Profile Generator (PFCG) for the maintenance of profiles;
·   Adding new transactions representing additional functionality to the applicable activity groups;
·   Adding the replacement transactions that aim at substituting obsolete or old-version transactions, including the new Enjoy transactions;
·   Adjusting the new authorization objects that SAP added for the new release; and
·   Ensuring that all existing reports, transactions and authorizations still function as expected in the new release of SAP.
2.2.               Overview of the Security upgrade process
Once the Development system has been upgraded to 4.6, the security team will need to perform the following steps as part of the Security Upgrade:
·        Convert Report Trees to Area Menus;
·        Review users (via SU01) to check for any new or changed fields on the user masters;
·        Convert manual profiles created via SU02 to Activity Groups (See Approaches below);
·        Compare SU24 customer settings to new SAP default settings (SU25 steps 2A-2C);
·        Determine which new / replacement transactions have to be added to which activity groups (SU25 step 2D);
·        Transport the newly-filled tables USOBT_C and USOBX_C that contain the SU24 settings youve made (SU25 step 3); and
·        Remove user assignments to the manual profiles.
2.3.               Approaches to convert manual profiles to Activity Groups:
2.3.1.      Approach #1: SAPs standard utility SU25
SAP provides an utility for converting Manual Profiles to Activity Groups and to identify the new and replacement transactions that need to be added to each activity group.
You can access this utility by typing SU25 in the command box.
If you do decide to use SU25 Step 6 to convert the Manual profiles to activity groups, you will need to watch out for the following gotchas:
Naming convention (T_500yyyyy_previous name)
All activity groups created before SU25 is run, are renamed to T_500yyyyy_previous name.
See OSS note 156196 for additional information and procedures to rename the activity groups back to their original names using program ZPRGN_COPY_T_RY_ARGS. Carefully review information regarding the loss of links between profiles and user master records.
Transaction Ranges
Ranges of transactions are not always added correctly to the newly-created activity groups. Some of the transactions in the middle of the range are occasionally left off. E.g. you have a transaction range of VA01 VA04 for a specific manual profile. After SU25 conversion, the new Activity Group only contains VA01 and VA04. Transactions VA02 and VA03 were not added.
It is important that a complete download of table UST12 is done prior to running SU25. Once SU25 has been run, a new download of UST12 can be done to identify which transactions have been dropped off.
The missing transaction codes will need to be added manually to the relevant activity group via PFCG.
Missed new transactions
The output of one of the steps in SU25 is a list of the new replacement transactions (e.g. Enjoy transactions) that need to be added per activity group. E.g. transaction ME21N replaces ME21. The list will identify each activity group that has ME21 where ME21N needs to be added to.
In some cases SU25 does not identify all new transactions to be added.
2.3.2.      Approach #2: Manual reconstruction of Profiles as Roles (Activity Groups)
An alternative approach to SU25 is to manually create an activity group for each manual profile that was created via SU02.
The advantage of this approach is that you wont have any missing transactions that were dropped off with the SU25 conversion.
3.      Items requiring special attention
3.1.   Authorizations
Several new authorization objects have been added with release 4.6. Care should be taken when adjusting authorizations carefully review all new defaults that were brought in. These are indicated by a Yellow or Red traffic light in PFCG.
It is highly recommended that you first check the previous settings where new defaults were brought in, before just accepting the new defaults. You can either use the existing 3.1x Production system or the UST12 and/or USOBT_C tables as reference.
3.2.   * in S_TCODE
Its recommended that all activity groups containing an * in authorization object s_tcode are recreated via PFCG by selecting only those transactions required for that role. Also, if you did previously add transactions to an activity group by manipulating the s_tcode authorization entries, it is recommended that the transactions are pertinently selected/added on the Menu tab. The object s_tcode should be returned to its Standard status.
3.3.   Report Trees
Report Trees need to be converted to Area Menus using transaction RTTREE_MIGRATION..
3.4.   ABAP Query reports
Reports created by ABAP Query need to be added either to the activity group (Menu tab) or to an Area menu to ensure an authorization check on s_tcode level.
3.5.   S_RFC
The use of an authorization object for Remote Function Calls (RFC) was introduced to provide authorization checks for BAPI calls, etc. Authorization object s_rfc provides access based on the Function Group (each RFC belongs to a Function Group). Due to the potential prevalent use of RFCs within the R/3 system, SAP has provided the ability to change the checks for this object via parameter auth/rfc_authority_check. It is possible to deactivate the checking of this object completely. However it is recommended to rather set the values as required, which makes testing even more important!
3.6.   Custom tables and views
Custom views and tables that are customarily maintained via SM30, SM31,etc. will need to be added to an authorization group. This can be done via transaction SE54 or SUCU or by maintaining table TDDAT via SM31.
3.7.   User menus versus SAP menu
A decision needs to be made once the first system has been upgrade to 4.6x as to whether the user menus or the SAP menu, or both are to be used.
Most users find the new user menus confusing and unfamiliar due to duplication of transactions, etc. (if a user has more than one activity group and the same transaction appears in several, the transaction will appear multiple times). The majority of upgrades from my experience have opted to use a modified copy of the SAP menu by adding their own area menus (converted report trees).
3.8.   Re-linking of user master records to profiles
If you do not maintain the user masters in the same client as the activity groups, you will need to establish a strategy for re-linking the users in the QA and Productive environments when transporting the activity groups as part of the upgrade cutover. This might also be necessary depending on whether you decided to rename the Activity groups per OSS note 156196.
Remember to thoroughly test and document all procedures and CATT scripts prior to the Production cutover.
3.9.   Dual-maintenance
With most current upgrades, the upgrade process will be tested on a separate environment set aside from the existing landscape. In a lot of cases a dual-landscape will be implemented where the existing landscape is complemented with an additional 4.6x test client(s).   The new 4.6x clients usually become part of the permanent landscape once the Production system has been cut over and all changes are then sourced from these new Development and/or QA systems.
It is imperative that all interim security-related changes are applied to both sets of systems to ensure that the new 4.6x development source system is current with all changes that were made as part of Production support in the old version landscape. If not, you will have changes that were taken to Production when it was still on the older release, but are now missing after the switch is made to the 4.6x systems.
It is thus advisable to keep changes during the upgrade project to a minimum.
3.10. Transport of activity groups
Changes to activity groups are not automatically recorded in 4.6x. When an activity group needs to be transported, it needs to be explicitly assigned to a change request via PFCG.
SAP recommends that you first complete all the changes to an activity group, before you assign it to a transport request.   Once youve assigned the activity group to a request, do not make any further changes to it.
You can also do a mass transport of activity groups via PFCG > Environment > Mass Transport.
If you want to transport the deletion of an activity group, you first have to assign the activity group to a transport request before performing the deletion via PFCG.
3.11. Client copies
The profiles used for creating client copies have been changed, especially profile SAP_USER from 4.5 onwards. Activity groups are seen as customizing and the SAP_USER profile copies both user masters and activity groups.
Its recommended that the client copy profiles are carefully reviewed before the copy is performed.
See OSS note 24853 for additional information on client copies.
3.12. SU24
Changes to check indicators that were made via SU24 might have to be redone as part of the upgrade. Ensure that any resulting transport requests are noted and included in the detailed cutover plan.
Check indicator changes done via SU24 will need to be applied for any new and replacement transactions.
3.13. Composite Activity Groups
Composite activity groups can be built in release 4.6x using individual activity groups. A composite activity group does not contain any authorizations, but is merely a collection of individual activity groups.
3.14. Central User Administration
Central User Administration (CUA) simplifies user administration, allowing security administrators to maintain users in a single central client only. The user masters are then distributed to other clients using ALE. It is recommended that CUA is implemented post-upgrade and once the systems have been stabilized. Carefully review OSS notes and the impact on the existing landscape, client copy procedures, etc. prior to implementing CUA. It is recommended that the upgrade is kept as simple as possible there are going to be plenty of opportunities to test your problem-solving skills without complicating the setup with new utilities!
See Authorizations Made Easy guide for information on setting up CUA.
See OSS notes 333441 and 159885 for additional information.
4.      additional tips
4.1.               OSS and Release Notes
Review all security-related OSS and Release notes related to upgrades and to the release youll be upgrading to, prior to the upgrade. Its useful to review these before you define your workplan, in case you have to cater for any unforeseen issues or changes.
4.2.               Workplan
Given the amount of work and number of steps involved in the security upgrade, it is recommended that a detailed Workplan is defined at the startup of the upgrade project. Key milestones from the security workplan should be integrated and tracked as part of the overall Upgrade Plan.
Clear ownership of activities, including conversion of Report Trees, needs to be established. This function is often perform by the Development team.
4.3.               Standards and Procedures
Naming conventions and standard procedures should be established before the manual profiles are reconstructed as activity groups. Each team member should know how the new activity groups should be named to ensure consistency. Other standard practices for the construction of the activity groups should include:
·        Transactions are added via the Menu tab and not by manipulating s_tcode.
·        Ideally, no end users should have access to SE38, SA38, SE16 nor SE17.
Remember to keep Internal Audit involved where decisions need to be made regarding the segregation of job functions or changes to current authorizations are requested or brought in with new authorization objects / defaults.
4.4.               Testing
4.4.1.      Resources for testing
Enough resources should be allocated to the security upgrade process as each activity group and profile will require work to some degree or the other. It is important that key users and functional resources are involved in testing the activity groups and that this effort is catered for in the Upgrade Project plan. Clear ownership of each activity group should be established not only for testing purposes, but also for ongoing support and approval of changes. Ideally, the ownership and approval of changes should reside with different resources (i.e. the person requesting the addition of a transaction or authorization should not be the same person responsible for approving the request).
4.4.2.      Test Plan
The security team should also establish testing objectives (whether each transaction being used in Production should be tested, whether each activity group should be tested with a representative ID, etc.).
A detailed test plan should then be established based on the approach, to ensure each person responsible for testing knows what s/he should be testing, what the objective(s) of the test is and how to report the status of each test. Both positive (user can do his/her job functions) and negative (user cant perform any unauthorized functions) testing should be performed.
The Reverse Business Engineering (RBE) tool is very useful in identifying which transactions are actually being using in Production. This can assist with focusing on which transactions to test.
The importance of testing all used transactions individually and as part of role-testing cannot be stressed enough. TEST,TEST,TEST!
Every menu option, button, icon and available functions for all critical transactions need to be checked and tested. There are some instances where icons are grayed out or dont even appear for certain users, due to limited authorizations. The only way these type of issues can be identified, is through thorough testing.
4.5.               Issue Management (tracking and resolution)
Due to the number of users potentially impacted by issues / changes to a single activity group, a perception can quickly be created that the security upgrade was unsuccessful or the cause of many post GoLive issues.
It is therefore recommended that an issues log is established to track and ensure resolution of issues. The log should ideally also contain a description of the resolution, to aid with similar problems on other activity groups.
This log will be helpful during the entire upgrade process, especially where more than one resource is working the same set of activity groups, so set it up at the beginning of upgrade project! You can also use this for a lessons learnt document for the next upgrade.
4.6.               Status reporting
The security upgrade forms an integral part of the overall upgrade given the sensitivity and frustration security issues could cause. It is important that key milestones for the security upgrade are tracked and reported on to ensure a smooth and on-time cutover.
4.7.               Detailed cutover plan
The detailed cutover plan differs from the overall security workplan, in that the detailed plan outlines the exact steps to be taken during each systems upgrade itself. This should include:
·        Transport request numbers,
·        Download of security tables prior to the upgrade, especially UST12, USOBT_C and USOBX_C,
·        A backup and restore plan, (e.g. temporary group of activity groups for critical functions),
·        The relinking of user master records, with details on any CATT scripts, etc. that might be used,
·        User comparison, etc.
The security team needs to ensure that enough time is allocated for each action item and that this time is built into the overall cutover plan.   The project manager is usually expected to give an indication to end users and key stakeholders as to when the Productive system will be unavailable during its cutover to the new release. This downtime should thus incorporate time required to perform user master comparisons, unlocking of IDs and all other action items.
4.8.               Project team access
The SAP_NEW profile can temporarily be assigned to project team members to provide interim access to the new authorization objects. This provides the security team the opportunity to convert and adjust the IS teams activity groups. It also eliminates frustration on the functional teams side when configuring and testing new transactions, etc.
4.9.               Training and new functionality
Some support team members (e.g. Help Desk members responsible for reset of user passwords, etc.) might require training and/or documentation on the changed screens of SU01, etc.
It is recommended that a basic Navigation & Settings training module is created for all SAP users and should cover the use of Favorites, etc.
The security team should also review Profile Generator in detail, as several new functions have been added (e.g. download/upload of activity groups, etc.). Remember to review all the different icons, menu options and settings on the authorizations tab, etc.
Lastly, if your company / project does use HR as related to security (activity groups and users assigned to positions / jobs), ensure that you become acquainted with the new enjoy transactions, e.g. PPOMW.
4.10.           SU53
A new function with SU53 is the ability to display another users SU53 results.   (Click on the other user button and enter the persons SAP ID).
4.11.           Post Go-live
Remember to establish a support roster, including after hours for critical batch processes, to ensure security-related issues are resolved in a timely fashion.
Dumps should be checked regularly (Objects s_rfc and s_c_funct like making appearances in dumps) for any authorizations-related issues. Transaction ST22 can be used to review dumps for that day and the previous day.
Avoid transporting activity groups at peak times, as the generation of activity groups can cause momentarily loss of authorizations. Its recommended that a roster for activity group transport and mass user comparison be reviewed with the project manager prior to the upgrade. Exceptions should be handled on an individual basis and the potential impact identified, based on number and type of users, batch jobs in progress, etc.
And, dont forget to keep on tracking all issues and documenting the resolutions for future reference.
5.      helpful reports, transactions and tables
5.1.               Reports and Programs
·           RTTREE_MIGRATION: Conversion of Report Trees to Area Menus
·           PFCG_TIME_DEPENDENCY: user master comparison (background)
·           RSUSR* reports (use SE38 and do a possible-values list for RSUSR* to see all available security reports), including:
v     RSUSR002 display users according to complex search criteria
v     RSUSR010 Transactions that can be executed by users, with Profile or Authorization
v     RSUSR070 Activity groups by complex search criteria
v     RSUSR100 Changes made to user masters
v     RSUSR101 Changes made to Profiles
v     RSUSR102 Changes made to Authorizations
v     RSUSR200 Users according to logon date and password change, locked users.
5.2.               Transactions
·           SUIM : various handy reports
·           SU10 : Mass user changes
·           PFCG: Profile Generator
·           PFUD: User master comparison
·           SU01: User master maintenance
·           ST01: System trace
·           ST22: ABAP dumps
·           SUCU / SE54: Maintain authorization groups for tables / views
·           PPOMW: Enjoy transaction to maintain the HR organizational plan
·           PO10: Expert maintenance of Organizational Units and related relationships
·           PO13: Expert maintenance of Positions and related relationships
·           STAT: System statistics, including which tcodes are being used by which users
5.3.               Tables
Table
Use
UST12
Authorizations and Tcodes per Profile
UST04
Assignment of users to Profiles
AGR_USERS
Assignment of roles to users
USOBT_C
Authorizations associated with a transaction
USR02
Last logon date, locked IDs
AGR_TCODES
Assignment of roles to Tcodes (4.6 tcodes)
USH02
Change history for users (e.g. who last changed users via SU01)
USH04
Display history of who made changes to which User Ids
USR40
Non-permitted passwords
i am also providing the url of sap upgrade guide. pls check it out ok.
www.thespot4sap.com/upgrade_guide_v2.pdf
reward me points if it helps you
thanks
karthik

Document names

hi,
what are the documents used in project preparation,blue print stage,realisation phase,final preparation & golive and support stages.

Hi Siva,
These are the documents used in SAP R/3 implementation using Accelerated SAP methodology.
Documents in each phase as follows:
I.Project Preperation
1.Project Plan &Schedule of tasks
2.Project Goals &Objectives
3.Project Scope
II.Business Blue Print
1.As Is document
2.To Be document
3.Gap document &Additional goals
4.Business blue print document (a complete document of client's business processes, it is the guide for realization for SAP R/3)
III.Realization
1.Configuration document
2.Test plan &Test cases
3.Customer specific end user document &Training material
IV.Final preperation
1.UAT document
V.Go Live &Support
1.Post Golive tracker document
Hope you have understand,
reward, if it helps,
Regards,
Srinu.K

NOTES ON WARE HOUSE MANAGEMENT

Iam implemeting ware house management for RAW MATERIALS... if you have any notes on how to implement from start.. pls forward to my id ...
My client is in chemicals.....
[email protected]..
Garanteed reward...
Kiran

Hello Kiran,
It will be typical implementation project so plan accordingly. you will have scoping, business blueprint, configuration, testing, integration testing, User acceptance testing, data conversion and final go-live with support on post golive system.
- Prepare the scoping list
- Discuss with business expert and document business processes
- Input your suggestion on SAP solution
- Analys fit-gap
- Propose final solution for gap
- Configure the system and develop objects for gap
- Carry out the testing, integration testing
- Conduct CRP and sign off the testing documents
- Plan data migration and prepare accordingly
- Carry out cutover activities and finally upload data
- Check the RF related setup and test the same.
- Finally go-live
- Check out the best practice for chemical industry
- Relevent configuration document, you can download from the first thread of this forum.
Hope this helps.
Regards
Arif Mansuri

Depot Stock posting at golive period

Hi,
Can anybody give me advise on depot opening stock posting procedure before go live of project.
regards

Hi bvdv,
Here if you need to capture excise invoice(reciept) using the t-code J1IG to update RG23D register from MM side. And SD end issues will be updated in RG23D register using the t code - J1IJ.
With the help of abap consultant look for BDC programing to upload RG23D register for receipts, but to update RG23D register for issues you need to manually refer respective bill of entries for each issues.
Thanks,
Swamy H P

Post golive

Similar Messages

Maybe you are looking for