You may think that a technical upgrade to mySAP ERP 2004 or SAP ERP Central Component (SAP ECC) 6.0 is just that — a technical upgrade. However, if Transaction Manager components are implemented in the existing system, then these components have to be upgraded during the technical upgrade. The Transaction Manager is a component of Treasury and Risk Management. It contains tools that allow you to manage financial transactions and positions. The Transaction Manager upgrade involves the configuration migration from the prior version to the new functionality, as well as some manual configuration requirements, data (document level) migration, and updates to existing Treasury documents. There is new functionality in the latest Treasury and Risk Management releases, but SAP has added items that have to be implemented structurally. As such, the configuration must be migrated to these new structures and existing documents have to be updated with these newly defined fields. Some of the configuration changes can’t be derived, so you have to configure them. You also have to move documents and configurations to new table structures. I’ll highlight the initial steps and potential hurdles to look out for in the migration of Transaction Manager and its associated components in previous releases to the Transaction Manager in SAP ECC 6.0. I’ll use over-the-counter (OTC) transactions as the example. The Securities module (which handles stocks, bonds, or ownership investment transactions) involves much more discussion and is beyond the scope of this article. Additionally, there are various conversion types, but only one is selected for your specific migration. Each type has unique migration steps associated with it. For this article, I’m covering type 4: Conversion from <= Rel. CFM1.0/CFM2.0 to Enterprise 2.00/ERP2004/ERP2005. This covers the core migration steps not associated with Securities.

Transaction Manager Migration Preparation

The Transaction Manager is a component of the Treasury module that includes any or all of the following components: Money Markets, Foreign Exchange, Debt, Derivatives, and Securities. Before you migrate, you need to first define your conversion type (Figure 1). The conversion type determines the starting release level of your current SAP system. SAP uses this to define the activities and migration steps needed for your upgrade.   Then you need to ensure your system landscape is set up properly. For the Treasury migration, I recommend that you have a sandbox client that is in the same system as your development client. You should be able to use transaction SCC1 to transport your changes to this client without having to release them. Transaction SCC1 allows you to move transports between different clients in the same system without having to release them. This allows you to make changes to the same transport change request without having to create new requests for each change. This client allows you to practice your migration with the appropriate configuration while allowing you to reset your client as the Treasury migration mandates, separate from the rest of the technical upgrade being tested. The company code-dependent migration steps generate configuration, so they need to be run in a development client. It’s best to do this first in the sandbox. Secondly, not all the company code-independent steps are reversible, so the only true way to test changes is to run the migration directly from a system refresh. The Treasury migration resets should not be totally dependent on other systems that the rest of the migration teams use. The initial Treasury test environment should be isolated. In my case, we were only given a development (configuration) client initially. We had to run the first set of steps (company code-dependent) in this client. The first few runs were not clean. While testing, we found errors in the existing configuration that needed to be corrected, so we had to re-run the steps. When our test environment was ready, we had to temporarily turn it into a development client to regenerate the configuration correctly, create a transport, and then move it back to the original development client. Trust me — you don’t want to go through all this. Create the Treasury sandbox as part of the development system client. Now that you’re prepared for the Transaction Manager migration, you can move on to the basic configuration for the migration.

Basic Configuration Settings for Migration

Step 1. Set the migration type and assign the customizing task. Use transaction code TPM_MIGRATION_CAT (Figure 1). This creates general settings for the migration. You need to configure and transport this to any client where the migration is being executed. The systems in Figure 1 may need to be changed depending on where they are transported for execution of the migration steps.

• Conversion Type: Set the conversion type based on which system you’re converting to and which system you’re converting from.
• Request/Task: Use transaction code SE10 to create a shell transport number. The numbering is unique to each client installation and is assigned automatically during its creation in transaction SE10. Do not attach any other configuration to this transport. SAP places all its configuration and table updates from the transaction code TPM_Migration run of the Cxx steps here. The Cxx steps are the initial Treasury migration steps that convert and create configuration in the new Treasury tables (e.g., account determination). When you move this transport to production, the Cxx steps are flagged as imported or complete.
• Production System: Not relevant for over the counter (OTC): money markets, foreign exchange, or derivatives. It is used for the Remote Function Calls (RFCs) to production, as outlined in the migration guide. In a drop-down menu, you can see the available systems from which you can choose your specific production system client. This is unique to each company’s implementation and how they’ve defined their systems.
• Test System: Used for the migration to import the help tables (TRGTS_MIGR_PMP and RFDT field RELID=TR) into the test system. Without this, you have to manually transport them. Select your test system client from the drop-down menu.
• Customizing System: The migration checks the customizing system here to see if the conversion steps have been carried out. Select your specific customizing system client from the drop-down menu.
• Reversal Reason: Reversal reasons are required in standard FI. If the migration steps are executed and then reversed at any time, they trigger an FI document reversal. Therefore, they require a reversal reason code. Rather than requiring you to manually add reversal codes to each FI document created by the migration that it’s reversing, this step automates the process behind the scenes. This reversal code is only used during the Treasury migration execution.
• Prefix for Batch Job: If you run the migration steps as batch jobs, you can set the prefix here.
• Parallel Processing: You can run migration steps D33-D40 in parallel if you activate parallel processing here. Steps D31 and D32 are the only steps that cannot be run in parallel.
• Logon/server group: The migration parallel processing uses any available system application server if this is not specified. Otherwise, you can direct the migration parallel processing to specific servers.
• Number of Tasks: This defines the maximum number of processes that parallel processing can use during the migration. This is only needed if you use parallel processing. This setting varies depending on the number of servers available for processing. Ask your Basis team to set this for about 75% of the available processes.

Step 2. Set key dates for conversion. Follow menu path Treasury and Risk Management > Transaction Manager > General Settings > Tools > Conversion > Conversion Customizing > Specify Key Date for Conversion (Figure 2). The Key date for data transfer and Amortization Date fields are only relevant for the Securities module. The Accrual/Defer. Date column affects all areas. At a high level, you can define how your Securities data is migrated by company code.   Step 3. Set the number intervals for Position Management Procedures (PMP). Use transaction TPM_Migration_PMP to set number ranges for the PMP procedures generated during the Treasury migration (Figure 3). If parallel valuation areas have not been used to date you can use any number, but make sure it’s large enough (e.g., 0001 through 9999). Otherwise, select a range that doesn’t contain PMP procedures.  

Data Cleansing Requirements

You need to execute data cleansing of existing transactions in the legacy system. Otherwise, the migration will not migrate transactions in particular statuses. Despite strong efforts to correct all legacy transaction statuses, it is inevitable that some are missed during legacy data cleanup, or that new transactions are posted with the incorrect statuses for migration. You can correct these in newer versions, but fixing them is not foolproof, is prone to errors, and is manually more intensive than fixing them in the legacy system. The system may not migrate documents that have the statuses listed below set on them unless you resolve them. The migration doesn’t consider these statuses as completed transactions. The statuses must be changed to one recognized by the migration.

• Transactions blocked for posting
• Transactions flagged for posting, but not posted
• Transactions flagged for reversal, but not reversed
• Post realized gain/loss postings for foreign exchange and money markets

Ensure No Transactions Are Blocked for Posting

You can find a blocked posting by looking in table VTBFHAPO, field SBEWEBE. If this field is 0, the transaction is blocked and the migration warning “Transaction xxxxxxxx contains a valuation or realization not relevant for posting” appears. Note that this is a warning and it’s up to you to research why the status is 0. You should resolve the error in the legacy system. Release the flow for posting (if possible) and then post it. Sometimes it warrants ignoring this warning for business reasons. An example is when the blocking reason is 0, but the reason code is 3 (activity does not allow posting, in which case it might not be settled) or 6 (function has been reversed, when reversals are not migrated).

Ensure No Transactions Are Flagged for Posting

You can find a transaction flagged for posting (but not posted) by looking in table VTBFHAPO, field SBEWEBE. If this field is equal to 1, the transaction is flagged for posting. This status can generate various error messages during the migration execution. You should resolve the error in the legacy system. In the legacy system, run transaction TBB1 to post Treasury flows. Alternatively, you can use transaction TBB1_LC to flag the flow as posted (if no FI posting is necessary) or reverse it via transaction TBB2. If the only choice is to fix it in SAP ECC 6.0, use transaction TBB1_OP_ONLY (or transaction TBB1_LC_OP_ONLY if no FI document is necessary) to flag the flow as posted before migration.

Ensure No Transactions Are Flagged for Reversal

You can find a transaction flagged for reversal (but not reversed) by looking in table VTBFHAPO, field SBEWEBE. If this field is equal to 3, the transaction is flagged for reversal. This status prevents these transactions from migrating. You should resolve the error in the legacy system. In the legacy system, run transaction TBB2 to reverse the Treasury flow. If, however, the only choice is to fix them in SAP ECC 6.0, run transaction TBB2_OP_ONLY to flag the flow as reversed before migration. If no FI reversal documents are necessary, use transaction TBB3_OP_ONLY.

Ensure Realized Gains or Losses Are Posted for Foreign Exchange and Money Market Transactions

If gains or losses have not been posted, an error message stating “Position values differ for transaction xxxxxxxxxx in company code xxxx” occurs during the migration. You should resolve the error in the legacy system. In the legacy system, run transaction TBB6 with the indicator Post Immediately selected. If you don’t select Post Immediately, the system creates additional unposted flows with a status of 1 and you have to then rerun transaction TBB1. If the only choice is to fix the error in SAP ECC 6.0, run transaction TPM19 (to post the gains or losses) and select Recalculate Immediately, or run transaction SE38 and enter program RFTR_MIGRATION_EXCLUDE_OTC to exclude them from the migration.

Preparation for TPM Migration Execution

In preparation for the Treasury migration, consider the following:

• Create multiple logon IDs for each user to reduce the system load. Create these new IDs as unique IDs for the upgrade (e.g., XXUser123 or ZZUser123). This allows you to see all the postings and changes made as part of the migration separate from daily business processing. This also minimizes the chance of RFC communication errors that can occur when multiple people or processes attempt to access the same tables.
• SAP recommends that you be on Support Package 10 or higher for the migration. I recommend the latest Support Package for your version at the time of your upgrade to mitigate any new issues. Additionally, you can go to SAP Service Marketplace (https://service.sap.com/support) and use the search term TPM_MIGRATION to find all relevant Treasury notes. Refer to section 12.6 of the migration guide for a short list of critical SAP Notes.
• If a migration step is not complete and stops for any reason, internal errors can occur. Refer to SAP Notes on internal errors. Search SAP Service Marketplace (https://service.sap.com/support) with TPM_MIGRATION Internal Errors to see some of the relevant SAP Notes.