Business Partner, new fixed assets – what else?

In many companies, discussions are currently underway about whether to start the project of SAP conversion to S/4HANA this year or wait, considering that the system manufacturer might postpone the end of support date again.  At this stage of the development of the new version, it can be said with a high degree of certainty that 2027 is a realistic and final date. Of course, there is still the option of additional three years of support for an extra fee.

This means that there are only three years left for the normal use of the SAP ECC system, and it is high time to initiate projects of migration to S/4. We encourage our clients to begin preparations for this project as soon as possible.

An important issue that arises in organizations planning migration is how to prepare for the project and what actions can be taken in advance to ensure smoother operations later on. It might be worth considering breaking the conversion into several smaller projects that are less invasive for the organization.

Much of the discussion also revolves around choosing the optimal project scenarios. The Greenfield approach essentially involves a new implementation with a fresh concept and data migration. Another option worth considering is the Bluefield approach, which allows for the launch of S/4HANA with new features while retaining access to historical data. Many organizations will likely choose the brownfield method, which is essentially a technical upgrade to S/4.

This article will focus on this last method, providing guidance on how to prepare the system before the actual migration.

Business Partner is a basic data element in the S/4HANA system that replaces the model of counterparties, i.e. customer and vendor objects, among others, commonly known and used so far in the ECC system. It is a solution that consolidates all counterparty roles in one place, one transaction.

Management of master data is simpler. All information is aggregated into one area, which makes data management and control much easier.

From the user’s perspective, this functionality also provides many benefits, such as the ability to create a related vendor, customer or contact person using one transaction instead of multiple ones.

From a technical perspective, data aggregation allows many times faster reading from the database, which translates into the execution of multiple standard reports and extension elements implemented in the company’s system.

The key advantages of Business Partner include:

• The legal entity in the system is represented by a single object – Business Partner;
• The ability to create entities in various forms, including Organization, Group, Individual;
• One BP can assume multiple roles within the system, such as vendor, customer, contact person, goods receipt point, and a role for credit limit verification (these are just the basic partner roles used in most systems; there are also other less commonly used roles, such as those related to liquidity management);
• General BP data is available for all roles held by a single BP, and key data can be created for each role separately;
• The ability to assign and manage multiple addresses;
• Time dependencies in different sub-units, such as address, bank data and other. This is one of the most important advantages of PB, which allows for maintaining a full history of changes (the data does not disappear from the system after a change);
• BP has a lot of new fields in the system available for configuration so as to meet all the needs of counterparty identification and classification without adding field extensions.

The change in the data model for a business partner is well seen when the counterparty is both a customer and a vendor. Master data such as addresses, TINs, or other counterparty identifiers like REGON or BDO, is created and changed in a single location within the system using one transaction. Its code is also special since it consists of only two characters (BP), rather than four, as most transaction codes do. It is only by reference to this data that we create/assign the role of customer and/or vendor.

When we compare the customer and vendor data objects in the ECC system with the new BP model, a notable difference is the lack of a direct link between customer and vendor data in the existing model. The only link is the “customer" field in the vendor master data, where we can enter the customer number, and vice versa, the “vendor" field in the customer master data. This link allows for reporting counterparty’s open items with a single report and supports offsets.

In contrast, when we look at the BP data model, we see that the link between customer and vendor roles is established through the BP, which is a parent object in relation to the roles created within it.

When comparing the tables, we can see that after transitioning to the Business Partner functionality, none of the familiar tables related to vendor and customer data, such as KNA1 or LFA1, disappear. These tables continue to be populated with data, and in addition, a set of higher-level tables aggregating the data are activated. By utilizing these new tables, it is possible to optimize queries for custom solutions and reports. However, if a company prefers not to modify its existing solutions, in most cases this will not be necessary after launching the BP in the ECC system since the currently used tables, as mentioned earlier, remain unchanged.

Launching the Business Partner is a mandatory step that has to be done still on the ECC system (at least version 6.0). It is recommended to carry out such a project now as part of the preparation for the future migration to S/4. The time and resources spent on this will not be wasted or duplicated in any way. What is more, the conversion itself will certainly go more smoothly and quickly, and the number of errors will be minimized. The project team will be able to focus solely on the migration process without also having to address the BP and any related issues. Additionally, it is important to note that users will become familiar with the logic of the new system and the challenges associated with migrating to S/4 ahead of time, which can be a significant advantage.

The BP implementation project begins with a preparation phase, where we need to configure the system, choose a numbering model, and prepare any necessary extensions. A key part of this phase is to make sure that master data is consistent and verified. The next stage is synchronization, where we work on resolving errors and checking system compatibility. The final testing phase is combined with user training on the new functionality. Naturally, the project concludes with the go-live of the solution.

The preparation stage can also be divided into two smaller ones. The first stage that can be completed by us independently as a mini-project is the verification of data and the preparation of an analysis document. The initial data analysis concerning customers and vendors can be obtained by performing a Readiness Check. However, this is very general, preliminary information.

A more detailed data analysis can be achieved by implementing and running several reports that will give a comprehensive picture of the operations needed to be done on the data prior to migration.  The steps for preparing these reports can be found in note 2743494.

A critical component of this analysis and documentation preparation is the selection of the numbering for the new BP object. Typically, systems are not ready for the recommended solution of having the identical numbering for customers, vendors, and BP. The most commonly chosen option is partial numbering, where the BP numbering matches either the customer or vendor numbering.

This part of the preparation stage, carried out by All for One, always concludes with the preparation of documentation using the templates recommended by SAP. Implementing the BP functionality requires the activation of several business functions, with all necessary steps outlined in SAP note 2832085.

The entire project usually takes 4-6 months, depending on the complexity and amount of data.

While the Business Partner function is not yet widely utilized in current ECC systems, the EA-FIN function is already well-known to users of this system.  However, there are still systems that use the old fixed assets engine.

Launching the EA-FIN business function is an essential component of converting the existing system to S/4.  It is also advisable to implement this functionality before the main migration project begins.

The primary changes introduced by launching EA-FIN include a new method of calculating depreciation. However, using the report provided by the software manufacturer, we can easily identify these differences. These are typically minor discrepancies resulting from a different depreciation calculation model.

For the user, the most noticeable change is the ability to apply depreciation keys or useful life of fixed assets depending on time. As a result, the system does not calculate depreciation backward to the beginning of the fiscal year, but makes changes exactly at the declared date.

Activating the EA-FIN function also forces a change of the place where extensions are implemented from the previous one based on user-exit to BAdI, which is also used in S/4HANA.

Launching new fixed assets is not a large and complicated project, but it may require some system downtime during the activation of the business function. As usual, duration of this downtime depends on the amount of fixed assets.

An essential preparatory step for the current system, which cannot be overlooked, is the archiving of old, unused data. Such actions will shorten the migration time and reduce the number of possible errors that may occur during the conversion. It is often a thankless task because its effects are not immediately visible. However, they will pay off in the future during the implementation.

Other tasks worth considering in the system include removing duplicates, standardizing, or verifying data consistency. Probably some organizations already have adequate procedures in place to verify data entry, and if not, it is beneficial to implement them to minimize the amount of time spent on cleanup in the future.

When preparing for system conversion, it is advisable to utilize the available transactions and programs to check the consistency of transactional data.  SAP provides such solutions for most data, such as fixed assets, aligning MM and FI modules, verifying material ledger or special ledger data. Additionally, depending on the type of general ledger being used, a dedicated program can be used to perform comparative analysis and comprehensive verification of financial consistency.

Similar to the EA-FIN business function, the New General Ledger is already used by some of our clients. This functionality is quite common in ECC systems.

The New General Ledger introduces several enhancements, such as parallel postings in different ledgers, allowing for different reporting on the same general ledger accounts. This is especially useful for multinational companies, where group reporting is different from local (domestic) and tax reporting. In the classic GL model, we had to multiply GL accounts and build financial statements differently. In the New General Ledger, reporting is simpler. This solution is also widely used in the fixed assets module for posting depreciation.

The New General Ledger also allows for document splitting, enabling us to provide additional dimensions for reporting. We also get an aggregated table, which allows us to optimize queries and speed up standard reports, as well as to improve extensions implemented in finance.

In the systems that are still operating with the classic GL, there is no need to perform the migration to the New GL on the ECC version. It will be migrated to the New GL during the process of conversion to the S/4HANA system as one of its steps.

It is, of course, possible to launch the New GL on the ECC system, however this requires the involvement of the entire organization in testing most processes. Additionally, SAP must be engaged in the system analysis before transitioning to the New General Ledger. For purposes of this contact, a special procedure and questionnaire have been developed. It needs to be completed and sent to the software manufacturer.