SolMan 7.2 enable AI_CRM_CPY_PROCTYPE to overwrite ZM transactions

Good day:

One of the realities you face in Solution Manager 7.2, is the fact that SAP introduced so many good new features to the SM* transaction types, that you want to incorporate them all into your ZM* transactions.  The problem is that the incorporation of those changes via update, can only happen in your development system, because that is the system where the ZM* transactions were created, in principle.  If a transaction type was not create in the system you are first testing the upgrade, e.g. a sandbox,  you are left with only the option of working with the SM* transactions.

As upgrade times and deliverables are important, the more sophisticated or rooted you have your Solution Manager system in your organization, the more it may take for your upgrade project.  In that scenario, your organization may end up upgrading one or two sandboxes before you reach your development system.  If that is the case, the present blogs gives you the opportunity of incorporating all the new SM* features into your ZM* transactions for non-development systems, although you can still use the same approach explained below, in that system.

Objective: To show you how to use transaction AI_CRM_CPY_PROCTYPE to recreate your ZM* transactions.

Summary of how we will achieve the objective: We use of the copy option found in transaction  AI_CRM_CPY_PROCTYPE.  That copy option does not work immediately in the first try, so we show you the steps to achieve that, by taking advantage of the very useful information the transaction itself provides.  You will be able to identify the tables that need to be adjusted, and we will tell you the methods to adjust them.

Some of the table entries are to be deleted via spro, some others via SM30/31, or even SE16.

Seems quite logical and obvious to undo configuration, but there are some tricks we explain here to achieve the whole objective, particularly  at the end, when your are left with one single table, in the case of ZMRC, for which you need to create a maintenance view in order to be able to delete the only entry left that does not allow the copy process to become achievable.

Assumptions:  We assume you are familiar with SPRO configuring ChaRM configuration, as well as using SM30/31.  There are many steps we will go through quickly to make this document lighter.  In that sense, when some tables are mentioned and we tell you to remove the records for an specific transaction type, e.g. via SM30, so you should know what we are talking about.  Not a big deal taking special care, doesn’t it?

---

Time for a cookie.   Please take the first one from the jar.

The table that stores the transaction type information for the transaction types created in your SAP system is AIC_PTYPE_TABLOG.  If a transaction type you are looking for has no entries in that table, it means the transaction type was created in another system of your landscape and it came into the system you are checking via transport.  This may give you a tip of why the update program does not work for you and no tables are retrieved when you press F4 in the selection screen below:

---

Process:  We will take ZMCR for the exercise as that is the most challenging of all.  For the rest of the transaction types, the process is very similar.

Step 1:  Use the transaction AI_CRM_CPY_PROCTYPE to backup your transaction types, e.g. ZMCR > YMCR, ZMAD > YMAD, ZMHF > YMHF, ZMMJ > YMHJ.  This will help if in the future you need a reference of how things were before you started the re-creation of the transaction types.

Step 2:  Delete you transaction type ZMCR. 

Via SPRO > IMG > SAP SolMan > Capabilities > ChaRM > Transactions > Multilevel Categorization > Assign Transaction Types to Catalog Categories.

Via SPRO > IMG > CRM > Transactions > Basic Settings > Define Item Category Determination.

Via SPRO > IMG >  SAP SolMan > Capabilities > ChaRM > Transactions > Define Transaction Type.

Step 3. Use the copy program to try to see what else needs to be cleared.  Unfortunately the step above leave lots of entries still in some tables, that need to be manually cleared.

Run the transaction AI_CRM_CPY_PROCTYPE to try to copy from the first time SMCR > ZMCR.  You will get a first glance of the work to be done.

So, what do we have above?  Two types of pending issues.  The yellow warnings (in red rectangles), refer to objects that are found still in the system and will not be overwritten by the copy.  You can decide whether to incorporate the SM* changes or not into those tables, e.g. partner determination procedure.  In our first approach, we decided to overwrite everything, so we had to go into each of the configuration areas or the red squared items and manually remove the configuration for ZMCR via SPRO.   We hope with this explanation is more than enough for you to know what to delete. You should know where in spro to delete: action profile, text determination procedure, etc.  If you are not familiar my friend, either you are learning or you are in the wrong blog.

The clearing of the 13 tables in the blue squares is the most.  Your mission is to clear all the entries referring to ZMCR in those tables, else the copy will not be possible.  As a final note, you may get a list of more or less tables with error status.  Still the logic presented here can be used for your own reality.

***

Before we show the analysis per table, one nice feature in the copy program happens when you double-click on an entry in error status.  On the right hand side of the screen it will be displayed the entries the copy program is planning to insert.  You can use that to focus on the entries you need to remove from that table, in particular. Example:

For the table above CRMV_TRJN_TRCA you use  SE16 to access it.  Below the process:

After you do that, the table entries are displayed and after you switch to change mode, you will be able to clear the entries.

Step 4. Re-point current usage of ZMCR.  Via SM30, update table DNOC_USERCFG by repointing the entries for ZMCR and ZSOLMANPRO to the standard.

Before:

After:

Note: After the copy, you will need to point back to ZMCR, even the newly introduced entry in 7.2 CHARM_ADD.

Step 5. Begin clearing up all the tables. The table below shows the tables from the copy report mentioned above reports, and the recommended method to clean up each respective table:  Some via SE16, some via SM30/31, some via SPRO.

Note:  Some of the SM30/31 tables could be accessed via SPRO, as well, but after a couple of searches with no results, we decided to take the quick path.

Note:  Some notes about some of the tables above:

• The first entry is in light grey, as it is not really indicated by the copy report, but it is a pre-requisite for one of the tables below.
• For table CRMV_TRINB_PROCA, when you try to delete the entries for SOLMANPRO, instead of skipping the error that is displayed about not to change SAP entries, press and you will be able to delete the entries.
• The tables placed in italics and orange font only appeared when we decided to delete the partner determination procedure for ZMCR.
• Table SOCMV_STAT_PROP requires updates in two areas, one of them being a second table.
• The last table, the view in red font, SOCMV_PROC_TYPE2, was the real challenge. That view is formed by various tables, one of which is TSOCM_PTOC_TYPE.  Unfortunately, there is no maintenance view built for that table.  Without that maintenance view, you cannot delete the only entry left to get the green light to successfully copy SMCR > ZMCR.  How did we achieve that?

Create a function group via SE37.

Provide information similar to the one shown and save.

In transaction SE11 take a look at view SOCMV_PROC_TYPE2 and see the tables it is conformed of:

In the screen below, you are supposed to select the fields for the maintenance view.  For our case we leave them all there.   You may want to activate now and may want to use a package related to the upgrade.

Assign the appropriate details, save and activate.

With that in place you should be able to use SM31 to access view ZTSOCM_PROC_TYPE to edit table TSOCM_PROC_TYPE and delete the only line left before you can actually copy SMCR on to ZMCR.

 

Step 6.  Copy process.  Launch AI_CRM_CPY_PROCTYPE to copy from SMCR to ZMCR.  The green light to copy should be visible.   Screenshot from ZMMJ, another transaction type we were able to recreate

Step 7. Post-copy actions.    Up to here, you have a vanilla transaction type.  The pending actions are divided in 2:

1. The SPRO-based customization you had in ZMCR prior the copy that you will need to add back via SPRO or the new flavor of SOLMAN_SETUP.
2. The Web UI, that also needs to go back to standard.

With item #1, there are some important things to consider:

• Via SM30, update table DNOC_USERCFG by repointing back the entries to ZMCR and ZSOLMANPRO.  Check out the newly introduced parameter, as well.

• Restore back number range, approval procedure, and early numbering assignment, if applicable.

• In the partner determination procedure, you may need to adjust the main partners of your ZMCR.  You can compare the screen below with the one your backed up when you created YMCR to bring back the old customization.

Note:  Keep in mind, as of 7.2 Support Team has been replaced by Development Team.

• Also in Change Request Management Framework, review and compare between YMCR and ZMCR, Define status change depending on approval result.
• Compare YMCR and ZMCR  via SE16 for table CRMV_TRINB_TRCA > SOLMAN-TRANSACTIONS.
• Are there are new texts in Text Determination Procedure that need to be incorporated.

• In multilevel categorization, are there business proposals to be adjusted?

• And the copy control, because the vanilla may have additional entries that are not required.

With regards to Item #2, Web UI, same as it was done with the transaction types, you may want to backup the old configurations, delete the old ones and recreate them.  Example ZMMJ:

With this in place, ZMCR is fully functional.

Step 8. Place back any additional SPRO customization performed in the past.

Step 9.  Incorporate any pre-existing Web UI customization performed in the past.

Conclusion: We know, it seems  like a long walk, but the satisfaction in our team was that we were able to fully access ZMCR in the sandbox to quantify the gaps we had, test security, etc.  We were ahead of time in identifying all necessary steps for after the upgrade, before we reached the development system of the production landscape.  That is not possible in the status quo right after the upgrade.

Hope you enjoy and thanks for reading.

Juan-Carlos Garcia-Garavito

Aftermath 1:  If by any chance in your transaction type you need to add back customer user statuses and when you test them, one or more of them fail, go to transaction CRMC_ACTION_CONF, delete and insert the Action(s) that is(are) failing.  You may have to add back again, e,g, scheduling entries.  This should resolve that issue, which is originated due to an incomplete table cleanup.