Need to understand impact on workflows during upgrade from EBP 3.0 to SRM 5

Hello experts,
Greetings to all and a Happy New Year!!
I am new to the workflow concept, though i have a fair idea of EBP.
We are using EBP 3.0, classic scenario. Very soon, we would be upgrading from EBP 3.0 to SRM 5.0. I have a few questions which i need to knw before I take up the upgrade part:
1) The impact on the worflows like Shopping cart approval, purchase contract approval etc when we upgrade from EBP 3.5 to SRM 5.0...
2) Does EBP have their own release strategies or are the release strategies defined in R/3 and applied to the shopping cart when it is ordered in EBP? As in classic scenario, POs are created in R/3, then how does the appoval process happen?
3) What are the necessary things, if any, that I should make sure of before upgrading?
4) Does all workflows also get upgraded or is there any tool to upgrade the workflow?
I am not clear with the approval concept in EBP. I know there are workflows that get triggered when a shopping cart is ordered but the approval process in this workflow is something which i want to understand. Please forward me a document, if possible, or a link will also do.
Please let me know the necessary details.
Thanks in advance.
Regards,
Ayush

Hi Ayush,
Most workflows will be the same, but if you have modifications on these workflows' then i'd suggest reverting back to the standards for the upgrade.
Im not quite sure what you mean about the release strategy. What can be done though, is creating Purchase Requisitions in the R/3 and pass them to the SRM system. From here PO's can be created and the approval process will take place in accordance with your workflow rules in tcode: swb_cond.
Before upgrading, try to have the system as clean as possible. When i say clean, i mean make sure that users are consistent, SC's, PO's etc arent left hanging. Try to avoid carrying documents over to the new system. I'd suggest archiving anything you can too.
I don't have any documents to give you but the basic process and transactions are as follows:
SWB_COND: Your workflow start conditions. Which WF's are on/off (defined by green/red light)
SWI6: This will let you examine a document and its relevant WF by its object id. (SC No, PO No etc..
SWUD: Allows for Consistency checks on your workflow and will find any inconsistencies which are occuring. (Use Test Environment and WF Tech Name i.e 14500015)
SWDD: The workflow builder, will let you build, activate, create new version and modify the worklows in your system.
Approval itself is simply the chain of approval which a workflow is defined to follow. You need your managers to approve/reject and the conditions for which Managers should be called for approval. Its works from Possible Approvers for workitems and Excluded Approvers for workitems.
Understanding the WF log is the most essential thing of all. The understanding of BADI is quite important too.
Hope this info helps you. Check help.sap.com cause everything is documented there too!
Cheers
Will

Similar Messages

Upgrade from EBP 4.0 to SRM 5.0

Hi y'all,
We are thinking about upgrading from our current EBP 4.0 to SRM 5.0. We are only using EBP for the self-service procurement scenario - with a classic integration towards two different R/3 4.6C systems. We have no internal catalogs and it is very much a standard set-up
Has anyone had some experiences to share?
Will it be a "large" or a "small" upgrade?
Are there any watchouts or learnings?
Many thanks in advance
Thyge

hello Thyge,
you are running on EBP 4.0, i.e. SRM 3.0: Extension of mainstream maintenance was extended from end of June 2006 to end of December 2006, at no extra fee.
Requisite 4.0 will be supported to end of December 2006 (refer to SAP Note 485884 for detailed information on Requisite).
That means that, excpet if you go in a custom support contract with SAP, your system will not be supported at end of 2006.
So you must "be prepared" and do this upgrade in 2006 !!!
If you don't use new features, have only 20 users, and a nearly standard SRM, you upgrade efforts will be really light:
- technical upgrade (attention: new Oracle version required) Unicode version ?
- nearly no custom dev alignement
- light re-training
The main workload would be the migration from Requisite to SAP CCM 2.0 (if you choose this option), depending on your actual content management strategy.
I think a 3 months upgrade project will be the correct duration for you.
Rgds
Christophe

Workflows during Upgrade

Hi Experts,
I would like to know the best practices followed to handle workflows during upgrade.
1. Do we need to terminate all the In process Workflows i.e. Workflows which have not completed the entire cycle ?
2. How do we overcome such problems . Any best practices which can be adopted.
Thanks,
Best regards,
Prashant

Prashant,
There will be a composite note regarding Workflow during upgrade, I find this note very useful. you may need to look into
PS ( There are few supporting notes associated with this notes)
a®

IMPACT ON SCREENS DURING UPGRADE

Hi Experts,
Can any one please let me know if there is any tcode or tool which tell us if there is screen change(few field added, tab added, or removed field or tab etc) during upgrading from 4.6c to ECC6.0

You may get information related to changes from these tables.
PRGN_CORR
PRGN_CORR2
PRGN_CORR3.

Can we activate Classic General Ledger in ECC6.0 during upgrade from 4.6C

Dear SAP Gurus,
Greetings
My Client's technical team had upgraded their system from 4.6C to ECC6.0 and they had activated classic GL instead of New GL. And they had also activated classic withholding tax in place of Extended Withholding tax.
They are facing some error during posting of transactions (like generation of excise invoices, posting of WHT transactions, etc.) I told that it can be a reason of not activating New GL.
Is my understanding correct...?? Can we activate classic GL during upgrade from 4.6C to ECC6.0...??
In case of a new client built (with ECC6.0), can we activate the classic GL instead of the New GL..??
Does the system will work correctly in the long run if they had activated classic GL and classic WHT...??
Please clarify. Thanks in advance for your time and efforts
Regards,
Chaps
P.S. Points will be awarded for answers !!

Hi,
I think that you should read long text of OSS note 999614 carfully and you are
aware of the fact that you will have additional migration efforts in
case you need to migrate to new G/L later on.
In case you are convinced that this is the best way please feel free
to deactivate new G/L as described in note 999614.
Please make sure that you deactivate new G/L in all clients of your
new system in case there were already client copies done.
Yes this is possible and I would not automatically assume that
error during posting of transactions are due to New GL not being activated.
Note 756146 documents the issue and possible repercussions
of using Classic GL.
In the case of a new installation the new G/L accounting
is active by default in ERP. In principle, the use
of the classic GL is also possible for new customers, however,
SAP does not recommend it since this requires an additional
migration expense in later years.
Regards,
Aidan

Impacts on MRS and MAM during upgradation from ECC 5.0 to 6.0

Hi Gurus,
I would like to know the impacts on MRS and MAM during the upgradation from ECC 5.0 to 6.0. The version of MRS we are using is MRSS 500, and the version of MAM is 3.0. please let me know your valuable comments.
Thanks in advance.
Regards
Satish

HELLO,
Search the form you will get few links.
Also many companies have gone technical upgradation , but not functional upgradation.
Thanks
RK

What is the impact of R/3 upgradation from 4.7 to ECC 6 on BI

Dear all,
Can any one tell me what will be the impact of R/3 Upgradation on BI... as we are shortly going to upgrade our R/3 from 4.7 to ECC 6.
Do we need to take any precautions in R/3 and aswell as BI
Please give the information...points will be given
Regards
venu

Hi
Please Refer this as this vll give u the Pros and Cons for upgrade.
Refer
http://wiki.ittoolbox.com/index.php/Upgrade_BW_to_Netweaver_2004s_from_v3.0B
This Wiki contains Rob Moore's ( BW Manager, Edwards Limited) teams experiences in upgrading Business Warehouse System from 3.0B to BW 7.0.
Contents
1 Upgrading from BW 3.0B to BW 7.0 (Netweaver 2004s)
2 Introduction
3 Overview & Scope
4 Drivers
5 Environment
6 Resource & Timescales
7 High Level Plan
8 Summary Task List
8.1 #Support Pack Hike
8.2 #Plug-in installation
8.3 #PREPARE process
8.4 #Dbase upgrades
8.5 #System Upgrade
9 Lessons Learnt
10 Issues & Fixes
10.1 Unfixed Issues
10.2 Fixed Issues
11 Regression Testing Process
11.1 Introduction
11.2 Set up
11.3 Actions
11.4 Security
12 Transport Freeze
13 Web Applications
13.1 Dashboards
13.2 Internet Graphics Server (IGS)
14 Detailed Task Lists
14.1 Support Pack Hike (detail)
14.2 Plug-in installation (detail)
14.3 Dbase upgrades (detail)
14.4 PREPARE Process (detail)
14.5 System Upgrade (detail)
Upgrading from BW 3.0B to BW 7.0 (Netweaver 2004s)
Introduction
This Wiki contains my teams experiences in upgrading our Business Warehouse System from 3.0B to BW 7.0.
Hopefully it will be useful to anyone else who's about to embark on this. If there's anything I've missed or got wrong, then please feel free to edit it or contact me and I'll try to explain.
Rob Moore - BW Manager, Edwards Limited.
Overview & Scope
This was to be a technical upgrade of BW only. The new BW 7.0 web functionality & tool suite which requires the Java stack rather than the ABAP stack was out of scope. We had heard that the latter was where most of the problems with the upgrade lay. Our plan is to wait for this part of BW 7.0 to become more stable. Also it has a big front end change and the business didn't have sufficient resource to cope with that much change management.
Drivers
3.0B at the end of its maintenance
Opportunities to do better reporting
Options to utilise BI Accelerator
Environment
Our R/3 system was at 4.6C and was not going to be upgraded. We have APO at version SCM4.0.
Our BW system is approximately 300 GB, with 125 global users. It was at version 3.0B SP 18
We have Development, Acceptance and Production environments.
Resource & Timescales
The Project ran for 3.5 months from Feb to May 2007. We used the following resources. The percentages are the approx. amount of their time spent on the project.
Project Manager * 1 70%
BW technical team * 3 50%
ABAP coder * 1 10%
SAP Systems Development expert * 1 20%
Basis * 1 25%
High Level Plan
These are the basic areas. We planned to complete this process for each environment in turn, learning our lessons at each stage and incorporating into revised plans for the next environment. However we did the Support Packs and Plug-Ins in quick succession on all environments to keep our full transport path open as long as possible.
Upgrade BW to the minimum support pack.
Install R/3 Plug-ins PI 2004.1
Run PREPARE on BW
Dbase upgrades (Database & SAP Kernel upgrade)
System Upgrade
Summary Task List
This list contains all the basic tasks that we performed. A more detailed check list is shown below for each of the headings.
#Support Pack Hike
We moved only to the minimum acceptable SP as this seemed most likely to avoid any problems with the 3.0B system prior to the upgrade.
Apply OSS 780710 & 485741
Run Baseline for Regression tests
Full Backup
Apply SP's (we were at SP18, going to SP20)
SPAU list review
Regression testing
#Plug-in installation
Apply SAP note 684844
Import and patch Basis plugin PI 2004.1
SPAU list review
#PREPARE process
BW Pre-Prepare tasks
BW - Inconsistent Data fix
Run PREPARE
Review of results
Any showstoppers from PREPARE?
#Dbase upgrades
Database Upgrade (FixPak)
SAP Kernel Upgrade
#System Upgrade
Reverse Transport of Queries
Reconnect DAB & SAB to AAE
Run Baseline for Regression tests
Full Backup
Run the Upgrade
SPAU list review
Regression testing
Lessons Learnt
Testing is all! We picked up on a lot of issues, but would have picked up more if we'd had a full copy of our production environment to test over.
Our approach of doing a full upgrade on each environment before moving to the next one paid dividends in giving us experience of issues and timescales.
Write everything down as you go, so that by the time you get to upgrading production you've got a complete list of what to do.
We succeeded because we had people on our team who had enough experience in Basis and BW to be able to troubleshoot issues and not just read the manual.
The SAP upgrade guide is pretty good, if you can understand what they're on about...
Remember the users! The fact that the loads have been successful doesn't count for anything unless the users can see the data in Excel! There's a tendency to get caught up in the technology and forget that it's all just a means to an end.
Issues & Fixes
I've listed the main issues that we encountered. I have not listed the various issues where Transfer rules became Inactive, DataSources needed replication or we had to reinstall some minor Business Content.
Unfixed Issues
We could not fix these issues, seems like SP 13 will help.
Cant delete individual request from ODS
After PREPARE had been run, if we had a load failure and needed to set an ODS request to Red and delete it, we found that we could not. We raised an OSS with SAP but although they tried hard we couldn't get round it. We reset the PREPARE and still the issue persisted. Ultimately we just lived with the problem for a week until we upgraded production.
Error when trying to save query to itself
Any query with a re-usable structure cannot be saved (more thsan once!)
OSS 975510 fixed the issue in Dev and Acc, but NOT in Production! SP 13 may solve this once it's released.
Warning message when running some queries post-upgrade
Time of calculation Before Aggregation is obsolete. Not a big issue so we haven't fixed this one yet!
Process Chain Scheduling Timing error
Process chains get scheduled for the NEXT day sometimes and has to be manually reset.
See OSS 1016317. Implement SP13 to fix this. We will live with it for now .
Fixed Issues
Duplicate Fiscal Period values in Query
If you open up a drop down box ("Select Filter Value") for Fiscal Year/Period to filter your query, you are presented with duplicate entries for Month & Year.
Due to Fiscal Year Period InfoObject taking data from Master Data not InfoProvider. Thus it picks up all available periods not just Z2.
Auto-Emails being delayed
Emails coming from BW from process chains are delayed 2 hours on BW before being released
Due to userids that send these emails (e.g. ALEREMOTE) being registered on a diffferent timeazone (i.e. CET) from the BW system (i.e. GMT)
Pgm_Not_Found short dump
Whenever a query is run via RRMX or RSRT
Call transaction RS_PERS_ACTIVATE to Activate History and Personalisation
Characteristics not found
When running a query the warning message Characteristic does not exist is displayed for the following: 0TCAACTVT, 0TCAIPROV, 0TCAVALID
We activated the three characteristics listed and the warnings stopped. NO need to make them authorisation-relevant at this stage.(also did 0TCAKYFNM)
System generated Z pgms have disappeared
Post-upgrade the system Z-pgms ceased to exist
Discovered in Development so we compared with pre-upgraded Production and then recreated them or copying them from production.
Conversion issues with some Infoobjects
Data fails to Activate in the ODS targets
For the InfoObjects in question, set the flag so as not to convert the Internal values for these infoobjects
InfoObject has Conversion routine that fails, causing load to fail
The routine prefixes numeric PO Numbers with 0s. SD loads were failing as it was not able to convert the numbers. Presumably the cause of the failure was the running of the Pre-Prepare RSMCNVEXIT pgm.
Check the Tick box in the Update rule to do the conversion prior to loading rather than the other way round.
Requests fail to Activate on numeric data
Request loads OK (different from above issue) but fails to Activate
Forced conversion within the update rules using Alpha routine. Deleted Request and reloaded from PSA.
Database views missing after pre-PREPARE work
Views got deleted from database, although not from data dictionary
Recreated the views in the database using SE14.
Workbook role assignations lost
We lost a few thousand workbook assignments when we transported the role they were attached to into Production
The workbooks did not exist in Development, thus they all went AWOL. We wrote an ABAP program to re-assign them in production
Regression Testing Process
Introduction
We were limited to what we could do here. We didn't have a sandbox environment available. Nor did we have the opportunity to have a replica of our production data to test with, due to lack of disk space in Acceptance and lack of sufficient Basis resource.
Set up
We manually replicated our production process chains into test. We didn't have any legacy InfoPackages to worry about. We asked our super-users for a list of their "Top 10" most important queries and did a reverse transport of the queries from Production back into test (as we do not generally have a dev/acc/prodn process for managing queries, and they are mostly created solely in prodn). We made sure every application was represented. In retrospect we should have done some Workbooks as well, although that didn't give us any problems.
Actions
Prior to the various changes we loaded data via the Process chains and ran the example queries to give ourselves a baseline of data to test against. After the change we ran the same queries again and compared the results against the baseline. We tried to keep R/3 test environments as static as possible during this, although it wasn't always the case & we often had to explain away small changes in the results. After upgrading BW Development we connected it to Acceptance R/3, so that we had pre-upgrade (BW Acceptance) and post-upgrade (BW Development) both taking data from the same place so we could compare and contrast results on both BW systems. We did the same thing once BW Acceptance had been upgrading by connecting it (carefully!) to Production R/3. To get round the lack of disk space we tested by Application and deleted the data once that Application had been signed off. Once we got to System test we involved super-users to sign off some of the testing.
Security
We chose to implement the new security schema rather than choosing the option to stick with old. For us, with a relatively small number of users we felt we could get away with this & if it all went wrong, just temporarily give users a higher level role than they needed. Our security roles are not complex: we have end user, power-user and InfoProvider roles for each BW application, together with some common default roles for all. In the event we simply modified the default "Reports" role that all our users are assigned, transported it and it all went smoothly. Apart from the fact that everyone's workbooks are assigned to this role and so we "lost" them all !
Transport Freeze
Once you've upgraded Development you've lost your transport path. We planned around this as best we could and when absolutely necessary, developed directly in Acceptance or Production, applying those changes back to Development once the project was complete. Depending on what other BW projects you have running this may or may not cause you pain!
Web Applications
Dashboards
We had various dashboards designed via Web Application Designer. All these continued to function on the upgraded system. However there were various formatting changes that occurred e.g. Bar graphs were changed to line graphs, text formats on axes changed etc. SAP provides an upgrade path for moving your Web applications by running various functions. However we took the view that we would simply re-format our dashboards manually, as we didn't have very many to do. Plus the external IGS (see below) powered all our environments and needs upgrading separately as part of the SAP method. Thus we couldn't have tested the SAP path in Development without risking Production. Sticking with manual mods was a lower risk approach for us. We did find we had to re-activate some templates from BC to get some of the reports to continue to work.
Internet Graphics Server (IGS)
We had an external IGS server with v3.0B. Post-upgrade the IGS becomes part of the internal architecture of BW and thge external server is redundant. We found no issues with this; after the upgrade BW simply stops using the external IGS and no separate config was needed.
Detailed Task Lists
Support Pack Hike (detail)
Apply OSS 780710 & 485741
Communicate outage to users
Warning msg on screen
Stop the jobs which extract data into delta queues
Clear the delta queues by loading into BW
Check RSA7 in PAE that delta queues are now empty
Run Baseline for Regression tests
Stop Delta queues
Lock Out users
Full Backup
Apply SP's
Upgrade the SAP kernel from 620 to 640
SPAU list review
Apply OSS Notes 768007 & 861890
Unlock Test users (inc. RFC id's on R/3)
Regression testing
Regression sign-off
Remove warning msg
Unlock users
User communication
Plug-in installation (detail)
Communicate outage to users
Warning msg on screen
Apply SAP note 684844
Lock out users
Full Backup
Empty CRM queues
Import and patch Basis plugin PI 2004.1
SPAU list review
Apply OSS 853130
Switch back on flag in TBE11 (app. BC-MID)
Remove warning msg
Unlock users
User communication
Dbase upgrades
Dbase upgrades (detail)
Communicate outage to users
Warning msg on screen
Run Baseline for Regression tests
Stop the Data extract jobs
Full Backup
Lock Out users
Apply FixPak13SAP to DB2 database
Upgrade the SAP kernel from 620 to 640
Apply OSS 725746 - prevents RSRV short dump
Unlock Test users (inc. RFC id's on R/3)
Regression testing
Regression sign-off
Remove warning msg
Unlock users
User communication
PREPARE Process (detail)
Pre-PREPARE Process
RSDG_ODSO_ACTIVATE
Repair Info objects and recreate the views
Communicate outage to users
Warning msg on screen
Run Baseline for Regression tests
Stop the Data extract jobs
Lock Out users
Full Backup
Run RSMDCNVEXIT Using BSSUPPORT ID
If there conversion process runs longer delay the regular backup
Re-run Baselines and sign off
If there conversion process Fails repeat the steps on Sunday after the regular backup
BW work
Back up customer-specific entries in EDIFCT (note 865142)
Activate all ODS objects
Execute report RSUPGRCHECK with flag "ODS objects" (note 861890)
Check Inconsistent InfoObjects - Upgr Guide 4.4; OSS 46272; Convert Data Classes of InfoCubes - Upgr Guide 4.3
Execute report SAP_FACTVIEWS_RECREATE (note 563201)
Make sure Delta queues are empty (RSA7)
Basis Work
Full Backup of BW
Lock users
Unlock id's RFC id's and designated test users
Confirm backup complete OK
Apply OSS 447341 Convert Inconsistent Characteristic Values - Upgr Guide 4.5
Confirm OK to PREPARE
Run PREPARE
Review of results
System Upgrade (detail)
Communicate outage to users
Process errors from PREPARE
Check disk space availability for PAB
Warning msg on screen
Reverse Transport Queries from PAB to SAB & DAB
Change BW to R/3 connection
Get backup put on hold, for Ops to release later
Ensure Saturday night backup is cancelled
Final run of PREPARE
Run Baseline for Regression tests
Clear Delta Queues
Delete Local Transports
Remove process chains from schedule
Lock Out users (with some exceptions)
Confirm to Ops and Angie that we're ready
Full Backup
Incremental backup of Unix files
UPGRADE "START"
Back up kernel
Unpack latest 700 kernel to upgrade directory
Check ids required for upgrade are unlocked
Check no outstanding updates
Turn off DB2 archiving
Open up the client for changes
Stop saposcol, & delete from exe directory
Run the Upgrade
Execute the saproot.sh script
Perform the database-specific actions
Perform follow-up activities for the SAP kernel
Reimport additional programs
Import Support Packages
Call transaction SGEN to generate ABAP loads
Transport Management System (TMS)
Handover to BW Team
SPAU list review
Apply OSS Notes from SPAU
Process Function Module XXL_FULL_API (part of SPAU)
Restore table EDIFCT (if required)
Transport Fixes from our BW Issue list
Convert the chart settings - manually
Perform activities in the Authorization Area
Activate hierarchy versions
Update the where-used list
Execute the conversion program for the product master
Transport New roles to PAB
Unlock selected users
Regression testing
Regression sign-off
Go / No Go decision
Restore if required
Remove warning msg
Tell Ops that the CR is now complete
Lock down PAB
Unlock users
User communication
Perform the follow-up activities for SAP Solution Manager
Reschedule background jobs
Reschedule weekly backup on Ctrl-M
Drinks all round.
Vendors mentioned: dBase
Hope this helps.

OWB + Workflow following upgrade from 11.2.0.1 to 11.2.0.3

Hi,
Our database is being upgraded from Oracle 11.2.0.1 to 11.2.0.3 at moment.
We use Oracle workflow for the process flows.
Given that workflow is a separate application, I'm assuming we don't need to take any action regarding workflow.
Would this be the case?
Thanks

Just confirming - no impact on oracle workflow.
Thanks

LONGPOST.LOG Errors during Upgrade from 4.6C to ECC 6.0

Dear all,
We have received the below errors during our upgrade from 4.6C to ECC 6.0.
Basically we have received three types of errors:
1.
4PETG065 RSUPGDEC: Table/structure "BAPE_VBAK" (component "SD-SLS" ) enhanced illegally: Error "2"
2.
A2PESEEF_BADI 103 BAdI implementation "/IRM/BADI_SDDOCFLOW" must still be migrated
A2PESEEF_BADI 103 BAdI implementation "ZOTC218E_1" must still be migrated
A2PESEEF_BADI 103 BAdI implementation "ZZ_MG_MASS_NEWSEG" must still be migrated A2PESEEF_BADI 103 BAdI implementation "ZOTC218E_1" must still be migrated
A2PESEEF_BADI 103 BAdI implementation "ZOTC218E_1" must still be migrated
3.
3PETG447 Table and runtime object "/SSF/DHEAD" exist without DDIC reference ("Transp. table")
3PETG447 Table and runtime object "/SSF/DTAB" exist without DDIC reference ("Transp. table")
3PETG447 Table and runtime object "/SSF/PTAB" exist without DDIC reference ("Transp. table")
Can anyone help us how to solve this issues.
Thanks & Regards
Senthil

Hi,
Senthil following are ans to ur questions
1. After the SPAU remediation is completed, should I manually release the transport or should I start the upgrade and the upgrade will release that transport?
Ans : Once your SPAU remediation is completed you should release the requests and then start the upgrade of the DEV system.
2. How do we import this SPDD & SPAU transport in the QA and PRD, I mean at what stage of the upgrade we need to specify/ include this transport?
Ans : Now when you start the QA or PRD upgrade at that time you come across a phase during PREPARE called ADJUSTPRP.
Refer following note for further information --
SAPNote 124522 - Importing a modification adjustment in 2nd upgrade
3. Suppose the QA & PRD has more objects to adjust than our Dev box, and this transport will not take care of the delta objects, so in that case how should we remediate, we need to create an other transport request in QA and then it will become two transports?
Ans : First of all this should not be the scenario where you have more modified objects than that in DEV. As all the modfications should take place in DEV first and then should be transported to QA and then PRD. But in such case what you can do is complete the upgrade of QA system and then you are still having 14 days to complete the SPAU objects. So you can make another request which can be transported as a post upgrade activity once the upgrade is completed in production. For SPDD you will have to take care of the SPDD objects if there are different than those in DEV during the ACT_700 phase only or else you might risk data.
This is the reason why SAP always asks you to follow a proper transport path.
4. If our dev box has more objects for remediation than our QA & PRD, then will these objects be also imported into the QA & PRD box?
Ans : Yes, thats why you should be very sure about the SPAU objects that you have found in DEV. You need to compare the objects with QA and PRD and then only make the modifications.
I hope i have answered all your queries.
Regards,
Suhas

Impact of ECC 6 upgrade on EBP 3.0

I hav EBP 3.0 and R/3 4.6C is planned to be upgraded to ECC 6. Not sure what will be the impact of upgrade on EBP 3.0. Can I continue to use EBP 3 with ECC 6 w/o having need to upgrade it to SRM. Has anyone seen EBP 3.0 and ECC 5 or 6 combination. Please revert.
Regards
Giriraj

Hi,
We have R/3 4.5c upgraded to ECC 6 and SRM 3.0 (EBP 4.0).
All we have to do is upgrading R/3 plugin and thats all.
Regards,
Marcin Gajewski

ZSearch Help: will it remain during upgradation from ECC6 to higher version

Hi,
During upgarde from ECC6 to higher versions, will zserach help be moved to higher version automatically or will it be removed and I have to create ZSearch Help again in the higher version.
What about the ZTable, will it be there in higher version or I need to create it again in the higher version.
Thanks,
Priyanka.

Hello Priyanka
Upgrading your SAP system will not affect your Z-objects directly.
However, if your Z-objects reference (i.e. use) SAP standard objects that are changed (or, rarely, are deleted) during upgrading then you may have to adjust your Z-objects. Therefore, keep your (automatic) test scripts available (e.g. eCATT) and run them immediately after the upgrade has been finished.
Regards
Uwe

Error during upgrade from OBIEE 10G to 11G

Hello All
I ran into this issue while trying to upgrade my 10g RPD and catalog to 11.1.1.7
After installing 11G, I launched the upgrade utility from Oracle_Common/bin/ua in linux.
I am getting the below error:
UPGAST-00797: Oracle Fusion Middleware Upgrade Assistant cannot be run from an Application Developer Oracle home.
Based on the Oracle Doc. it has the following desc:
UPGAST-00797: Oracle Fusion Middleware Upgrade Assistant cannot be run from an Application Developer Oracle home.
Cause: The user has chosen to perform a upgrade from an Oracle home that does not allow an upgrade.
Action: None.
Level: 1
Type: ERROR
Impact: Upgrade
So what should I do to resolve this issue?
Thanks in advance

Hi,
First of all i am not familiar on linux box.
I tried in windows environment the rpd is deployed with out any errors.
But i ran the ua.bat file in the following path
\MWHOME\Oracle_BI1\bin\ua.bat.
while i am running in oracle_common\bin\ua.bat is not responding in my local system.
Please Mark if it helpful.
Thanks

Error while generating JAR files during upgrade from 11.5.9 to 11.5.10

Hi,
We are getting the following issue after applying 11.5.9 CU2 patch set during the process of upgrade from 11.5.9 to 11.5.10.
- 3171663: 11.5.9 Oracle E-Business Suite Consolidated Update 2
Executing: /u01/app/tinst/tinstcomn/util/java/1.6/jdk1.6.0_18/bin/java -Djava.security.egd=file:/dev/urandom sun.security.tools.JarSigner -keystore ******** -storepass ******** -keypass ******** -sigfile CUST -signedjar /u01/app/tinst/tinstcomn/java/oracle/apps/fnd/jar/fnddssgraphgui.jar.sig /u01/app/tinst/tinstcomn/java/oracle/apps/fnd/jar/fnddssgraphgui.jar.uns CUSTOMER
ERROR: JarSigner subcommand exited with status 1
No standard output from jarsigner
JarSigner error output:
Exception in thread "main" java.lang.NoClassDefFoundError: sun/security/tools/JarSigner
Caused by: java.lang.ClassNotFoundException: sun.security.tools.JarSigner
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
Could not find the main class: sun.security.tools.JarSigner. Program will exit.
Can you please advice regarding this issue....????
Regards,
Sreenivasulu.

Please see these docs.
Generate Jar File causes NoClassDefFoundError sun/security/tools/JarSigner [ID 393306.1]
Generating Jar Files Fails with a NoClassDefFoundError: sun/security/tools/JarSigner Error [ID 801014.1]
Thanks,
Hussein

Error during Upgrade from 4.6c to ECC 6.0

Hi All,
We are facing an error when upgrading from 4.6c to ECC 6.0. We are facing this error on the table COEP - runtime object inconsistancy. What we found is there is ERP upgrade has created new extra fields in the table. In log file the error is specified as : Duplicate Field name, But we not able to find the duplicate field name in the table. Please kindly help as early as possible. The upgrade process is stuck.
Regards
Anil Kumar K

Hi Anil,
Is this issue fixed? Can i know how you fixed it?
replied to your message Re: How to adopt the index changes during upgrade.
Thanks,
Somar

TP version problem during upgrade from 4.7 sr2 to ECC6

Hello All,
i am doing an upgrade from 4.7 to ECC6 (ultimately i have to upgrade to EHP4). I am stuck in phase PREPARE module Initialization finished with status failed #. Below is the error i am getting. before pasting log file i tried my best to uprade TP level by upgrading the Patch level. but its not taking effact in to SAP system. If i check TP version in STMS >> system >> Check TP tool it shows me old version.
below is the error log excerpt from file CHECKS.LOG
 #====================================================#
Requests and information for module Initialization #
 #====================================================#
ERROR: The upgrade needs a patched version of R3trans which is
 build on 21.06.06 or later.
 The R3trans in your active SAP kernel is either older or
 the version could not be determined. Call it without
 any option to determine the build date.
 If the build date is too old, you have to replace it
 before you can continue the upgrade.
 Download the latest executable available from the SAP service
 market place and update it before you continue.
 Otherwise, the upgrade tools will be corrupted.
INFO: The version check of the disp+work in your active SAP kernel
 determined that it has a sufficient level.
 No update of disp+work is necessary.
ERROR: The upgrade needs a patched version of tp with version
 number 340.16.05 or higher.
 The tp in your active SAP kernel is either older or the
 version could not be determined. Call it without any option
 to determine the version.
 If the version is too old, you have to replace it before
 you can continue the upgrade.
 Download the latest executable available from the SAP service
 market place and update it before you continue.
 Otherwise, the upgrade tools will be corrupted.
ERROR: To be able to use ASU Toolbox, your system requires
 the ST-PI software component with at least Support Package Level 8
 After the update is done, the module must be repeated!
 For more information, see the upgrade documentation
INFO: The upgrade strategy for the addon ABA_PLUS
 is described in note: 632429
INFO: The upgrade strategy for the addon APPINT
 is described in note: 632429
INFO: The upgrade strategy for the addon BP-R3PF
 is described in note: 632429
INFO: The upgrade strategy for the addon FINBASIS
 is described in note: 438521
INFO: The upgrade strategy for the addon LSO
 is described in note: 503468
INFO: The upgrade strategy for the addon LSOFE
 is described in note: 503907
INFO: The upgrade strategy for the addon PI
 is described in note: 700779
INFO: The upgrade strategy for the addon PI_BASIS
 is described in note: 555060
INFO: The upgrade strategy for the addon SLL_PI
 is described in note: 1306751
INFO: The upgrade strategy for the addon ST-A/PI
 is described in note: 69455
INFO: The upgrade strategy for the addon ST-PI
 is described in note: 539977
INFO: The upgrade strategy for the addon WP-PI
 is described in note: 632429
 #===========================================================#
PREPARE module Initialization finished with status failed #
 #===========================================================#
i downloaded the 47 kernel files SAPEXEDB_304-20001172.SAR and SAPEXE_304-20001172.SAR and installed the kernel file. if i check TP version from command level it shows me 340.16.62, but in SAP STMS it shows me 340.16.03. Can somebody explain what shoulkd i do?
Can i know also if i can update SAP Kernel from 4.7 sr2 to NW7.0 without upgrading even started?
If somebody can tell me the exact number of CDs to use to upgrade from 4.7 SR2 to ECC6 EHp4, that would be very
nice.
Mani

Hi Mani,
ERROR: The upgrade needs a patched version of R3trans which is
build on 21.06.06 or later.
ERROR: The upgrade needs a patched version of tp with version
number 340.16.05 or higher.
show that the tp and R3trans used by the source 470 system are old.
You should download the latest tp and R3trans for kernel 470, and
replace the old tp and R3trans with the downloaded ones under the 470 kernel directory. The 470 kernel directory is specified by parameter DIR_EXECUTABLE which is usually /usr/sap/<SID>/SYS/exe/run.
Please note that there is also a kernel directory under /<DIR_PUT>/<SID>/SYS/exe which is for the the target system 700. Please do not replace tp and R3trans under this directory with the ones downloaded for kernel 470.
NO, you cannot update SAP Kernel from 4.7 sr2 to NW7.0 without upgrading even started. Kernel upgrade will be done by SAPup automatically.
With Best Regards
Julia

Need to understand impact on workflows during upgrade from EBP 3.0 to SRM 5

Similar Messages

Maybe you are looking for