En la lista Sistema, seleccione el CMS apropiado

7.8.1 Why do migrated payments not clear open items?

Problem

With the PAYMENT migration object, it is possible to migrate payments to clear predetermined open items. This allows the migration of a payment history of a contract account as it is in the legacy system. Why do migrated payments not clear any open item?

Solution

There are various reasons why a clearing process does not result in cleared open items. The main causes are as follows:

o Wrong or incomplete selection of open items to be cleared o The selected open items are already cleared

o Wrong or incomplete setup of the clearing control and clearing rules

The first two causes are related to problems during the extraction or transformation process and need to be fixed by the data migration team. The responsibility to solve problems in the clearing control is with the functional FI-CA team. Define the clearing control for migrated payments to improve the performance of the data migration of payments. The simplest way to determine whether a payment is a migrated payment is to analyze the information in the HERKF field (document origin key). Ideally, a migration specific origin key is used to allow the use of a migration specific clearing variant. This migration specific clearing variant can be kept very simple and allows the clearing of any selected open item of the same contract account.

7.8.2 Error due to competing processes

During the migration of payments the application raises either the error message >0 103 Complete selection not possible due to competing processing or >0 105 Complete selection not possible due to block by user x.

Solution

Both error messages are pointing to the same problem and the long texts of the error messages are explaining the root of the problem. The clearing process for one contract account will not be completed if you initiate a second clearing process for the same contract account. This is to prevent a double clearing of the same open item.

It is not an option to repeat the migration of the same import file with migrations until all payments have been migrated. The reduction of the commit buffering value to 1 for the migration payment is not a solution. Even if all business locks on the related business partner and contract account are released with a COMMIT WORK, there is still the risk of accessing the same contract account for a clearing process in parallel processes. We do not recommend the release of the business lock in an event right after calling the service function module for the PAYMENT migration object because the very critical clearing process might be compromised.

You can solve the problem in the following ways:

o Execute data migration with a single process per import file with commit buffering 1 o Execute data migration with the Distributed Import (data import of the same import file

with parallel jobs) but with import files which contain only one payment for the same contract account.

We do not recommend option one due to performance limitations. The second approach allows the use of commit buffering to improve the performance of the data migration of

payments. The downside of the second approach is, that more import files have to be created and migrated. This makes the data migration process more complex. The number of import files should be kept to a minimum. Create a final import file that collects all remaining payments, even for the same contract account. This import file must then be migrated with a single job (with commit buffering set to 1) to avoid the described blocking situations. The data migration team should use the Migration Lock Mechanism function to simplify the migration process (for more information, see chapter 2.8 ).

The described scenario may occur during both the clearing of single opens items and the migration of payments of an installment plan or budget-billing plan.

7.8.3 Error >0 009: Reconciliation key already in use

The application raises the error >0 009 Reconciliation key x already in use: Choose another key.

Solution

This error usually occurs if one of the following conditions is met:

o The reconciliation key is transferred in the import file for the EMIG_PAY_FKKKO-FIKEY field

o The same name of the reconciliation key is generated more than once

For more information about this problem and its solution, see chapter 7.7.1 Error >0 009:

Reconciliation key already in use.

7.8.4 Is it possible reusing reconciliation keys

Is it possible to reuse reconciliation keys when you are migrating payments with the PAYMENT migration object?

Solution

It is possible to reuse reconciliation keys but we do not recommend it. The disadvantage of reusing reconciliation keys is that it is more difficult to reconcile migrated financial documents between the legacy system and the SAP system. Implement the following changes to use the same reconciliation key more than once:

o In the PAYMENT migration object the X_REUSE_FIKEY parameter of the ISU_M_PYAMENT_CREATE service function module has to be set to X.

o The reconciliation key is determined individually. For that, the ISU_M_FIKEY_DETERMINE function module in the field rule for the EMIG_PAY_FKKKO-FIKEY field has to be replaced by an own project specific function module.

For more information about the development of an own algorithm, see chapter 9.4 Function Module to Determine Reconciliation Keys for a Reuse.

7.8.5 Is it possible to use the

migration object for payments?

Problem

Is it possible to migrate payments as credits with the DOCUMENT migration object?

Solution

It is possible to migrate payments as credits. However, a subsequent clearing process has to be implemented as part of the data migration. The clearing is done by executing a mass activity (transaction FPMA Automatic Clearing) as an additional step. The disadvantage is that the clearing variants have to be defined to deal with migrated historical payments, which leads to more complex clearing variants.

7.8.6 Error >4 036: “Document does not exist” when paying security deposits

The PAYMENT migration object is used to pay the open requests of migrated security deposits. The error message >4 036 Document x does not exist is raised for all payments so none of the payments can be migrated. What has to be changed to pay the request document of a cash security deposit?

Solution

When you migrate a cash security deposit the security object business object and an FI-CA request document are created. Pay the request document with the PAYMENT migration object. The PAYMENT migration object is configured to transfer the oldkey of the security object in the EMIG_PAY_FKKKO-OIBEL field; and the EMIG_PAY_FKKKO-OIBEL field has been configured with the via KSM field rule and the SECURITY top object. This configuration does not work as the SECURITY migration object is configured by default to save the key of the created security object in the KSM. The error > 036 Document x does not exist is raised because the application searches the request document with the key of the security object.

The key of the security object is saved in the KSM according to the configuration in the Return field (FKKSE_SEC-G-SECURITY) of the SECURITY migration object on the migration object maintenance screen. The problem is that a request document number is required for the payment and not the number of the cash security deposit.

You can solve the problem in the following ways:

o Add the code of Figure 7-10 to the postprocessing code of the EMIG_PAY_FKKKO structure (assuming that you use the EMIG_PAY_FKKKO-OIBEL field to transfer the oldkey of the cash security deposit). The ABAP code replaces the newkey of the security deposit by the request document number that it can be found in the OPBEL field of the FKK_SEC_REQ database table.

if not $S$-oibel is initial.

select single opbel from fkk_sec_req into $S$-oibel

Figure 7-10 Postprocessing Code for a Payment for a Request Document

o Replace FKKSE_SEC-G-SECURITY with FKKSE_SEC-G-OPBEL in the field Return Field on the Migration Object Maintenance screen for the SECURITY migration object. The request document number of the security deposit, instead the number of the security deposit itself, is now saved in the KSM when migrating security deposits. The via KSM field rule in the PAYMENT migration object will now return the required request document number of the security deposit when transferring the oldkey of the security deposit in the import file. Additionally, change the migration class of the SECURITY migration object from SECURITY to DOCUMENT. Figure 7-11 shows the changed Customizing for the SECURITY migration object.

Figure 7-11 Maintenance Screen of the SECURITY migration Object