Authorizations

BCS does not use the same authorization objects as Former Budgeting. This means that you cannot migrate existing authorization data to the new BCS authorization concept. Please refer to the documentation on FM authorizations for further information on implementing authorizations.

Integration of Human Resources (HR)

The old Funds and Position Management (FPM) solution is not compatible with BCS, meaning that data records related to this process will not be migrated. Instead, HR planning is integrated with budget data via a “virtual distribution” using value type 9D . A customer-specific solution should be investigated to solve this particular issue.

SAP recommends that you work with the new solution Position Budgeting and Control (PBC) , and not with FPM. PBC is compatible with the Budget Control System.If you work with PBC, the integration with HR is carried out via actuals (funds reservations).

HR integration via PBC also generates budget data (corresponding to the personnel costs involved). This creates a document chain that is a specific issue for document migration to BCS. Budget data is then not integrated but must instead be generated in BCS, since the corresponding documents are not migrated to BCS. You have to set up the PBC environment for BCS, involving the following activities:

A new IMG activity has been included in the BCS Customizing menu under  BCS Budgeting    Budget Entry   Transfer of Planning Data   Specify Budgeting Information for Data Transfer from PBC. Here you can specify the subtypes for HR Infotypes that are to be transferred to BCS.

Document Chains

You may have created budget data in Former Budgeting by another application in the SAP System, such as Purchasing. The corresponding budget documents are linked to the original data. Please note that these documents will not be migrated.

The known document chains are:

Budgetary Ledger(BL)

If you are working with the budgetary ledger, you must carry out totals-based migration . You cannot carry out document-based migration, since the same budget would be sent to the budgetary ledger twice:

In order to avoid such double entries, you can either:

OR

As it is not possible to properly carry out document-based migration with BL active, this functionality is not provided. For totals migration, however, there are no such problems, since the budgetary ledger is neither checked nor updated in this context.

Copying FB Data

In the EA-PS standard system, the program BPCOPY00 (copy budget version) outputs budget amounts without documents . Former Budgeting creates documents (hierarchy documents with or without budget entry documents) whenever budget data is updated. In exceptional cases, no documents are created. Please note that this program does not generate documents in the following cases:

Budget Releases

The release process has been supported by BCS since EAPS 2.0. The functionality covers part of the Former Budgeting solution, based on specific Customizing.

In Former Budgeting, the AVC functionality uses the budget profileto check the availability of individual released fund amounts. However, BCS does not support budget profiles. This is handled differently in BCS, with AVC checking the availability of released fund amounts by default for standard ledgers, provided the release function has been activated in BCS.

Automatic budget releases in BCS are also no longer defined via the budget profile, as in Former Budgeting. Instead, in BCS you can carry out a release:

The following table shows the differences in the way FB and BCS handle the release functionality:

Please refer to the system documentation for releases in BCS to implement this function, as well as the application help on the release functionality .

Revenues Increasing the Budget (RIB)

The RIB functionality has been supported in BCS since EA-PS 2.0. However, in BCS it is handled differently than in Former Budgeting.

A budget entry document generated by Revenues Increasing the Budget for all the years before BCS activation will be migrated as a normal budget entry document. By defining a specific budget type for these RIB entry documents, you can find them again easily, but the system will not recognize them as such.

For all the years since BCS activation, entry documents related to RIB will be ignored and not migrated. You need to specifically customize the RIB process in the Implementation Guide and then run the functionality in BCS. By doing so, you can correctly generate RIB budget in BCS, based on existing BCS rules and logic.

Status Management and Budgeting

If you are using status management for your FM master data (FM master data status), you can control the budgeting process using this tool. BCS has its own status management functionality, which means that you must check your FB settings during migration, and possibly recreate the statuses in BCS accordingly.

In Former Budgeting, status management was also used to control budget processing, although no separation of budget types was possible. In BCS, a status management tool within budgeting is provided to control processing. However, please note that no status data gets migrated.

See Status Management in BCS for further information.

Customer Exits and Specific Developments

If you have implemented your own customer exits for Former Budgeting, or if you have specific developments based on Former Budgeting data, especially for reporting, and reports reading or writing to FB tables, you should review your customer exits and redefine them for BCS.

BCS provides BAdIs in Customizing that enable you to reproduce your customer-specific developments, for example, for database checks and updates.

These BAdIs can be found in the Implementation Guide:  BCS Budgeting   Tools   Business Add-Ins for Budgeting (BAdIs) BAdI: Enhance Checks and Document Postings. This BAdI, for example, has the definition name FMKU_BUDGET_EVNT. You can define your own implementation for the methods (LINE_CHECKS and DOCUMENT_CHECKS).

Table Enhancements

If you have defined customer fields in the heading of entry documents for Former Budgeting (using include CI_BPDK), you should similarly define the corresponding customer include for the entry document header in BCS (using include CI_FMBH). In order to have the corresponding values migrated properly, you should use the same names for the fields and refer to the same data elements. If a BCS include contains new fields they will remain initial, that is, empty or blank, for all migrated documents.

The following BAdIs are provided to handle these specific fields in the BCS environment:

For further information on this functionality, please refer to the BAdI documentation in the system.