2425255 – Profit Center Accounting in the universal journal in SAP S/4HANA, on-premise edition
Classical Profit-Center Accounting Vs S/4HANA Profit-Center Accounting
You want to know
- how Profit Center Accounting (PCA) is mapped in the context of SAP S/4HANA and
- to what extent classic Profit Center Accounting can be used in parallel with SAP S/4HANA.
- How long selected functions of classic Profit Center Accounting are still supported.
! Important: This SAP Note will be supplemented in the near future. If you are interested, check it regularly.
Other Terms
Profit center, PCA, SAP S/4HANA Finance, ACDOCA, GLPCA, GLPCT, GLPCP
Reason and Prerequisites
Use of Profit Center Accounting
Solution
We strongly recommend that you map Profit Center Accounting in the universal journal in SAP S/4HANA. When you use SAP S/4HANA, on-premise edition, it is possible in principle to use classic Profit Center Accounting in parallel with Profit Center Accounting in the universal journal. However, we do not recommend you do this on a long-term basis due to the increased data volume and the increased time and effort required, and in the case of active document splitting, the update response changes.
In addition, selected functions of classic Profit Center Accounting are part of the compatibility scope with limited use rights. For more information about this, see SAP Note 2269324.
See the following explanations for details about deviating functions of Profit Center Accounting in the universal journal and classic Profit Center Accounting in SAP S/4HANA as well as details about the effects on the posting response.
Overview of topics:
1. Activating Profit Center Accounting
2. Data migration to SAP S/4HANA
3. Derivation of profit center, partner profit center, and elimination profit center
3.1 CO account assignment logic
3.2 Dummy profit center
3.3 Default profit center
3.4 Partner profit center
3.5 Elimination profit center
4. Authorization
5. Reporting receivables and payables in classic Profit Center Accounting
6. Reconciliation of the universal journal with classic Profit Center Accounting
7. Reporting
8. Planning
9. Allocation
10. Manual document entry
11. Statistical key figures
12. Number of profit centers
13. Origin object type (field RHOART)
14. CRM integration
15. Unvaluated material processes (KSTAT = U)
16. Postings from CO
17. Tables
17.1 T882
1. Activating Profit Center Accounting
In SAP S/4HANA, Profit Center Accounting is mapped in the universal journal by default. Profit Center Accounting in the universal journal is activated in Customizing as follows:
Financial Accounting –> General Ledger Accounting –> Master Data –> Profit Center –> Activate Profit Center Accounting in Controlling Area
Profit Center Accounting always takes place within one controlling area. We do not support cross-controlling area Profit Center Accounting. The activation in a controlling area sets the field PCRCH for the entry of this controlling area to the value ‘2’ in the table TKA00. If a document is then posted in the universal journal that contains a profit center and, if applicable, also a partner profit center, these are checked for existence and updated in the tables of the universal journal.
If the system issues message FINS_ACDOC_CUST 415 or FINS_ACDOC_CUST 416, proceed as described in the long text. For more information, see SAP Note 2420147.
In addition, it is possible to continue to use classic Profit Center Accounting in SAP S/4HANA, on-premise edition for a transition period. When the active indicator is set in transaction 0KE5, the field PCRCH for the corresponding controlling area in the table TKA00 is set to ‘2’, provided it has not already been populated with ‘2’ through the activation of Profit Center Accounting in the universal journal. This means that, simultaneously with the original activation of classic Profit Center Accounting (transaction 0KE5), Profit Center Accounting in the universal journal is also always active.
In classic Profit Center Accounting, in addition to the activation (transaction 0KE5), the online posting of data records in the tables (GLPCA = actual line items table, GLPCT = totals table, GLPCP = plan line items table) must be activated using transaction 1KEF. Actual documents are updated online in the database tables of classic Profit Center Accounting only if the ‘Online transfer’ indicator is set in transaction 1KEF (plan: transaction OKEQ –> version 0 –> Settings for Profit Center Accounting).
Classic Profit Center Accounting has the ledger ‘8A’ as a fixed ledger assignment.
If you want to deactivate classic Profit Center Accounting later, note the following:
– Do not remove the activation of Profit Center Accounting in transaction 0KE5. Otherwise, you would also deactivate Profit Center Accounting in the universal journal (table/field TKA00-PCRCH).
– Remove only the online posting of data records in transaction 1KEF (actual data) or OKEQ (plan data). However, data may still be transferred periodically to classic Profit Center Accounting. Therefore, you can also set the lock indicator in the year entry of transaction 1KEF or OKEQ.
See also SAP Note 702854 for information about the deactivation.
2. Data migration to SAP S/4HANA
During a data migration from an SAP ERP system to SAP S/4HANA, the profit center information from the tables of classic general ledger accounting (BSEG) or, if it was active, General Ledger Accounting (new) (tables FAGLFLEXA/FAGLFLEXT delivered in the standard system) is transferred to the new table ACDOCA of the universal journal.
During the data migration of CO documents to ACDOCA, the profit center information is derived again from the CO account assignments and updated in ACDOCA.
! There is NO migration of data from classic Profit Center Accounting (tables GLPCA/GLPCP/GLPCT) to the universal journal, that is, to the table ACDOCA.
The contents of the database tables of classic Profit Center Accounting (GLPCA, GLPCT, GLPCP) are copied to SAP S/4HANA during a data migration from an SAP ERP system. They are thus simply transferred.
3. Derivation of profit center and partner profit center
The profit center or partner profit center in SAP S/4HANA is also derived on the basis of the assignment in the relevant master data of CO objects and logistical objects.
3.1 CO account assignment logic
The basis of the profit center derivation from the account assignment objects is that all account assignment objects are assigned to a profit center. (Customizing –> Financial Accounting –> General Ledger Accounting –> Master Data –> Profit Center –> Assignments of Account Assignment Objects to Profit Centers)
All objects that have a profit center in the master record must be assigned to a profit center. This applies in particular if the profit center is configured in the document split as a financial statement characteristic and thus as a required entry field. If you deem the assignment to a profit center to be impossible in a process (because the responsibility cannot be assigned to a profit center), consider the option of defining a default profit center and later distributing the postings to other profit centers using transfers.
The logic of the derivation/determination of the profit center from the master data of the account assignment objects in the case of cost postings/revenue postings remains the same as in the ERP releases. For the posting, a true account assignment object to which the costs/revenues can be assigned is required (check in the function module K_COBL_CHECK). The profit center for the document line item is derived from this true account assignment object. This connection cannot be broken. This means that if a different profit center is required for a cost element/revenue element, the CO account assignment object must be replaced (for example, using a BAdI or a CO substitution). In this case, contact your FI/CO consultant regarding implementation.
The logic for posting to expense accounts/revenue accounts in FI (for example, transaction FB50) also remains unchanged. In the master data of SAP S/4HANA, these accounts have the following G/L account type on the ‘Type/Description’ tab: ‘Nonoperating Expense or Income’. In this case a true account assignment object is not required. Direct posting to a manually specified profit center is then possible.
3.2 Dummy profit center
Important: The creation of a dummy profit center is required only if classic Profit Center Accounting is to be used.
a) Profit and loss accounts (P+L accounts)
In classic Profit Center Accounting, the system first tries to determine a default profit center for document line items with a P+L account (no cost element) and without a profit center account assignment if no profit center was set manually (for example, using transactions 3KEH and 3KEI). If the system does not find a default profit center, the dummy profit center is set for some activities (primarily from Logistics). If document splitting is active for at least one of the two characteristics profit center and/or segment, the routine for setting the dummy profit center is no longer processed. Otherwise, document splitting would either split a document incorrectly or not at all in the case of a set dummy profit center. The system must therefore find and set the profit center that is valid for the process using the document splitting or another derivation option. If this is not the case, the document line item will not be updated in classic Profit Center Accounting (Document line items with initial profit center are not allowed in classic Profit Center Accounting and are therefore not updated.).
Note also that document splitting overwrites the dummy profit center for profit and loss accounts. If required, use a default profit center instead, which you create using the normal standard transaction for profit centers.
b) Cost elements and revenue elements
The dummy profit center is set on posting items with cost elements/revenue elements if the system recognizes a true CO account assignment (for example, cost center) to which, however, no profit center is assigned. (Function module K_COBL_CHECK –> subroutine accountings –> subroutine SUBST_FROM_REAL_OBJECT)
In addition, there is a derivation step for the dummy profit center in the CO-PA characteristic derivation (transaction KEDR):
If classic Profit Center Accounting is inactive and no dummy profit center is maintained, no dummy profit center is found in the last derivation step “Move dummy profit center”. As a result, a profitability segment with an initial profit center may be created. If a profitability segment is to be created for a cost element/revenue element (difference line, KTOSL = ‘DIF’) and a profit center must exist at the time of the profitability segment creation, standard options for setting a profit center can be used (for example, FI substitution, BAdI AC_DOCUMENT, COPA derivation step with a customer-specific default profit center at the end of CO-PA derivation).
Note also that document splitting overwrites the dummy profit center for accounts. Use a default profit center instead, which you create using the normal standard transaction for profit centers.
3.3 Default profit center
There are various options for setting a default profit center:
- Manual entry (if the transaction permits this)
- Maintenance of transaction FAGL3KEH or implementation of the BAdI FAGL_3KEH_DEFPRCTR
- Use of FI substitution
- Implementation of the BAdI AC_DOCUMENT (only for postings via the Accounting Interface, for example, MM postings, SD postings)
Transactions 3KEH and 3KEI from classic Profit Center Accounting CANNOT be used for the derivation of a default profit center. Default profit centers maintained using these transactions are not updated in the universal journal. Entries maintained using transaction 3KEH control the transfer of document line items to classic Profit Center Accounting. The profit center from transactions 3KEH and 3KEI would be relevant for the document in classic Profit Center Accounting if no profit center was derived at this point. Since this would result in different profit centers in the universal journal and in the PCA document, you should always use one of the options mentioned above and NOT transaction 3KEH to derive a default profit center.
Note that if document splitting is active, the derivation of a default profit center may prevent the document item from being split according to cause by document splitting. Therefore, NEVER set a default profit center for document items with accounts of which you expect an account assignment according to cause by document splitting. This applies in particular to OI-managed accounts, that is customers/vendors and also OI-managed G/L accounts, for example, the goods receipt/invoice receipt account account (GR/IR account). Note also that document splitting overwrites a true dummy profit center. Use a default profit center instead, which you create using the normal standard transaction for profit centers.
3.4 Partner profit center
Some applications, such as Controlling, automatically determine the partner profit center (for example, from the partner object of Controlling) and populate the document item with it.
For all other postings, the BAdI FAGL_DEFPPRCTR (enhancement spot FAGL_LEDGER_CUST_DEFPRCTR) with the method SET_DEFAULT_PART_PRCTR or the general BAdI AC_DOCUMENT is available for setting the partner profit center. A partner profit center determined in this way is always updated both in the universal journal and in classic Profit Center Accounting.
If the company codes of your group are located in a single system, the relevant partner profit center can be determined automatically for billing documents, goods issues, invoice receipts, and goods receipts by reading the relevant logistical object. For information about the processes in which this is possible, see SAP Note 161277.
This automatic determination can be activated directly using transaction OCCL. (currently not in customizing of Financial Accounting)
Transactions 8KER and 8KES for the determination of the partner profit center in purchasing and sales are available only if classic Profit Center Accounting is active and online update is activated (see customizing transactions 0KE5 and 1KEF). However, we recommend that you do not use transactions 8KER and 8KES in SAP S/4HANA because partner profit centers derived in this way are updated in the universal journal and in classic Profit Center Accounting only if the line item is relevant for classic Profit Center Accounting.
3.5 Elimination profit center
In classic Profit Center Accounting, the derivation rules for the elimination profit center are defined fixed in source code. There were repeated queries from customers who wanted to fill the elimination profit center for the same type of posting in different ways. For this reason, no fixed logic was implemented by SAP for postings in General Ledger Accounting (new). However, a BAdI was provided, which customers can use to implement their own logic. In SAP S/4HANA, the BAdI FAGL_DERIVE_EPRCTR (enhancement spot FAGL_DERIVE_EPRCTR) is also available for the derivation of the elimination profit center. The BAdI FAGL_DERIVE_EPRCTR is called from the function module FAGL_ELEM_PRCTR_SET. If the elimination profit center is set, it must always be identical to the partner profit center. You can also decide whether the elimination profit center is to be filled automatically in all posting items in which a partner profit center is set, or only in a subset of these posting items. This depends on the individual reporting requirements.
Plan: If you execute plan assessments in the universal journal, you can use the BAdI FAGL_ALLO_SUBSTITUTE to set the elimination profit center.
Reporting: The table T804C controls which fields are used for the sender-receiver relationship for elimination of IU sales. For the table ACDOCT for the field name PRCTR, the corresponding field (sender) is defined as EPRCTR.
The following is a list of the source code points in classic Profit Center Accounting for actual postings, which can give you an idea of how they are implemented in the BAdI.
AC Interface postings (for example, SD/MM):
For cross-company postings, the partner profit center (SPRCTR) and the elimination profit center (EPRCTR) from the affiliated company are determined and set. This is done using the read function for partner profit centers (transaction OCCL/function module COPCA_PARTNER_GSBER_PRCTR).
In addition, the derivation function for the partner profit center (transactions 8KES and 8KER or function module COPCA_PARTNER_PRCTR_GET) is used to set the elimination profit center). In the function module COPCA_DOCUMENT_CHECK, the partner profit center is transferred to the elimination profit center after the function module COPCA_PARTNER_PRCTR_GET is processed.
FI postings:
When the function module COPCA_PARTNER_PRCTR_GET is processed in the function module COPCA_DOCUMENT_CHECK, an existing customer number or vendor number is used to determine whether it is a posting with an affiliated company. In the subsequent subroutine set_elim_prctr, invoices posted in FI with an affiliated company and transaction RFBU receive the elimination profit center if the partner profit center is filled. For the affiliated company, the VBUND derived by the system from the function module COPCA_PARTNER_PRCTR_GET is used.
CO postings: In the include LGIN1F80, the elimination profit center (EPRCTR) is set from the partner profit center (PPRCTR); however, for some transactions, the elimination profit center is NOT set because there should be no elimination for these transactions. For example, this applies to the following transactions:
KAZI Actual cost center accrual
KAZP Plan cost center accrual
RKP1 Planning primary costs
RKP2 Planning activities
RKP5 Plan Revenue Types
RKP6 Planning activity-dep. costs
RKP8 Planning Settlement Costs
RKP9 Plan. act-dep.settlement costs
4. Authorization
The existing authorization objects are available.
5. Reporting receivables and payables in classic Profit Center Accounting
General SAP Notes: 81906, 180906, 81374
Document splitting is active
The detailed information from the general ledger view about receivables and payables split online from the document splitting is NOT available for classic Profit Center Accounting.
If the business area or the profit center is defined as a document splitting characteristic, the reports for balance sheet adjustment (SAPF180*) cannot be executed. The system issues message FR 662 or message FR663.
If the business area and the profit center are not defined as document splitting characteristics, the reports for balance sheet adjustment (SAPF180*) can be executed. This makes it possible to transfer receivables and payables to classic Profit Center Accounting using transaction 1KEK (data in the tables BFOD_A and BFOK_A is available as a result of the execution of transaction F.5D). However, the old foreign currency valuation function (transaction F.05, report SAPF100) is no longer available in the universal journal. As a result, transaction 1KEK copies only the original receivables/payables, independently of transaction 2KEM “Perform Account Control for Valuation Differences”. In other words, the original data is not corrected by the valuation differences.
The new foreign currency valuation of open items (report FAGL_FC_VALUATION) can be performed only with depreciation areas. However, if document splitting by profit centers is set, the report FAGL_FC_VALUATION posts with the operational profit centers. The balance sheet adjustment account can be transferred to classic Profit Center Accounting using transaction 3KEH.
The execution of the profit and loss adjustment (report SAPF181, transaction F.50) is not possible because CO objects are adjusted that are also directly or indirectly (for example, using the profit center) adjusted by means of document splitting. Follow-up costs split according to cause can be transferred online to classic Profit Center Accounting because these are already available in the entry view. The account can be transferred to classic Profit Center Accounting using transaction 3KEH.
Document splitting is not active
In this case, you CANNOT display the receivables and payables according to cause at profit center level in the universal journal.
Within classic Profit Center Accounting, the old split of receivables and payables (transaction F.5D) as well as follow-up costs (transaction F.50) can be used, and the periodic transfer of receivables and payables using transaction 1KEK can be used. However, the report FAGL_FCV for the foreign currency valuation of open items can be executed only with depreciation areas, which means that the valuation differences are no longer updated in the documents (valuation difference not updated in BSEG-BDIFF). As a result, transaction 1KEK copies only the original receivables/payables, independently of transaction 2KEM “Perform Account Control for Valuation Differences”. In other words, the original data is not corrected by the valuation differences.
6. Reconciliation of the universal journal with classic Profit Center Accounting
Transaction GCAC is available for the reconciliation of the data in the universal journal with the data in classic Profit Center Accounting. Here, you can select the leading ledger or a nonleading ledger of the universal journal as the base ledger. The ledger selected for the reconciliation should have the same fiscal year variant as the PCA ledger. As selection data for the comparison ledger, enter the ledger 8A and version ‘0’.
! Note that transaction GCAC carries out a technical display/totaling of the values in the selected ledgers on the basis of the information or characteristics entered. Whether the values for the selected account (or another selection characteristic) must be identical between the selected ledger of the universal journal and the ledger 8A depends on your business processes and system settings and must therefore be checked individually by the user. Transaction GCAC, with its purely technical approach, cannot provide this.
Up to now, you may have used transaction KE5T. KE5T is based on transaction GCAC. When you execute transaction KE5T, the ledger ‘0L’ and version ‘1’ are defined for the base ledger, and the ledger ‘8A’ and version ‘0’ are defined for the comparison ledger.
7. Reporting
Many universal journal reports, such as Financial Statement, Trial Balance, GL Balance, and GL Line Items support the profit center entity. In addition, special reports for Profit Center Accounting (for example, Profit Center Group: Plan/Actual/Variance, Profit Center Group: Plan/Plan/Actual, Profit Center Group: Key Figures, Profit Center Comparison: ROI) are available in the universal journal. Furthermore, it is also possible to create customer-specific reports based on various reporting tools.
The reports in classic Profit Center Accounting have remained unchanged in SAP S/4HANA. Note that the classic Profit Center Accounting reports do not display any data if the update to classic Profit Center Accounting is not activated (transaction 1KEF).
The libraries for classic Profit Center Accounting in Report Writer are part of the compatibility scope and are available only for a limited period of time. You can use the report FAGL_RMIGR to change the data source of your existing reports.
8. Planning
As described in SAP Note 2270407, in SAP S/4HANA, on-premise edition, balance sheet planning and profit center planning are part of SAP BPC for SAP S/4HANA Finance (previously known as SAP Integrated Business Planning, SAP Note 2081400).
If you want to use the classic planning functions of Financial Accounting and/or classic Profit Center Accounting instead of SAP BPC for SAP S/4 HANA, you can reactivate these as described in SAP Notes 2474069 and 2253067 (FI-GL) as well as 2345118 and 2313341 (EC-PCA). Note that in this case, the planning results are updated in the respective totals record tables and integrated planning is required so that the data can be used across plans. Reports that are intended to be used specifically with SAP S/4HANA Finance do not access these totals record tables.
The planning transactions for classic Profit Center Accounting are part of the compatibility scope and are available only for a limited period of time. You can plan on profit centers using the G/L planning transactions.
9. Allocation
Allocations in the universal journal offer more flexibility in comparison to allocations in classic Profit Center Accounting. This is because the table ACDOCA contains more characteristics that can be used for allocation. In addition, the universal journal supports more parallel currencies.
Allocations for profit centers previously used in General Ledger Accounting (new) can be transferred to the universal journal during the migration.
A migration of allocations from classic Profit Center Accounting to the universal journal is impossible.
10. Manual document entry
In classic Profit Center Accounting, manual documents can be entered using transaction 9KE0 and 1KEL. This allows you to make transfers between profit centers.
If you use Profit Center Accounting in the universal journal, use the usual transactions for manual postings in the universal journal, that is, transaction FB01 or transaction FB01L (ledger-specific postings).
11. Statistical key figures
Statistical key figures are entered as before in CO (using transaction KB31N for actual and transaction KP46 for plan). They are then available in the tables COSR and FAGLSKF. If classic Profit Center Accounting is not active, transactions FAGLSKF and FAGLSKF1 can be used to adjust the statistical key figures at profit center level. Transaction FAGLSKF3 can be used to display the data.
You can also use the BAPI or the function module BAPI_ACC_POST_STAT_KEYFIGURE to post statistical key figures (see SAP Note 1011595). This is useful, for example, if you want to transfer the planning from one company code to other company codes from the controlling area.
12. Number of profit centers
See SAP Note 217338.
General information about the number of profit centers:
- In classic Profit Center Accounting
- When using the profit center characteristic in the new General Ledger Accounting
- When using the profit center characteristic in the universal journal in SAP S/4HANA
You use the profit center characteristic or Profit Center Accounting. –>
A profit center is a management-oriented organizational unit used for internal controlling purposes. A subdivision into profit centers allows you to analyze areas of responsibility by considering them as a “company within the company”. The number of areas of responsibility depends on the size of the company.
The number of profit centers influences – among other things – the number of posted data records. The number of totals records or ACDOCA records in turn affects performance in processes that handle a large number of totals records or ACDOCA records. However, many other factors also have an influence on performance, such as the system infrastructure or server infrastructure.
The number of profit centers is therefore one aspect to consider when evaluating performance. A large number of profit centers and therefore a large number of totals records or ACDOCA records can result in performance problems and even program terminations.
Even if no physical totals records exist in the universal journal (ACDOCA) in sFIN or SAP S/4HANA, data is aggregated in many processes at runtime and stored in internal tables for further processing. This can also cause problems in sFIN or SAP S/4HANA.
Examples:
– In reporting
– For consolidation operations (particularly allocations)
– In the master data transactions of Profit Center Accounting, particularly when changing or displaying the profit center hierarchies
– For the balance carryforward
– For the rollup within a central ALE scenario
– When you use the decentralized ALE scenario (only available in classic Profit Center Accounting)
Considerations based on the number of profit centers:
– Fewer than 1,000 profit centers: This is a normal installation where no problems are to be expected, based on our experience to date.
– 1,000–5,000 profit centers: This size may be appropriate in large companies. Based on our experience to date, no problems are to be expected.
– 5,000–10,000 profit centers: This is a very large installation. You must check whether such a large number is really necessary. Careful performance testing is essential before going live.
– More than 10,000 profit centers: Generally, the use of such a large number of profit centers is not appropriate or does not correspond to the concept of Profit Center Accounting envisaged by SAP. You should consider redesigning your approach to reduce the number of profit centers or checking whether Profit Center Accounting or the profit center characteristic is a suitable tool for mapping your requirements.
!!! Please note the following:
The specified values are only ballpark figures, not precise technical restrictions. It is entirely possible that an installation with a high or very high number of profit centers will not experience any problems.
If you plan an installation with a very large number of profit centers, it is definitely necessary to carry out tests with mass data for all relevant processes before the go live. When you do this, also take into account the system growth in the following years.
13. Origin object type (field RHOART)
The origin object type is available as the field RHOART in the table ACDOCA. The logic for determining the origin object type is contained in the function module COPCA_ACCIT_HOART_SET. Determination takes place using information or fields from the accounting document.
Example: Set RHOART for asset portfolio items in COPCA_ACCIT_HOART_SET:
…
IF i_accit-koart = lc_koart_a OR
i_acchd-awtyp = ‘AMDP’ OR “RAPOST2000
i_acchd-tcode CS ‘ASKB’. “RAPERB00/2000/V2
* End of note 693885
E_ACCIT_HOART = GC-HOART_ANLAGENBEST.
EXIT.
ENDIF.
…
Otherwise, asset portfolio items for which no exact origin object type could be found receive origin object type ’35’ (‘Additional Balance Sheet Items’).
In the case of asset postings, the logic of the function module K_ACCOUNTINGS_SET_FOR_ASSETS also influences the determination of the origin object type. This is because the account type, in combination with other system settings, deletes account assignment information, such as cost center information (depending on customizing for CO message KI098; transaction OBA5). This may lead to origin object type ’35’ (‘Additional Balance Sheet Items’) being set in the function module COPCA_ACCIT_HOART_SET.
See also SAP Note 2483786 – “Wrong HOART 35 in ACDOCA P&L line items from fixed asset accounting”.
14. CRM integration
See SAP Note 386391 – “CRM: Determination of profit center”.
A real dummy profit center (table field TKA01-DPRCT) must be maintained only if classic Profit Center Accounting is active. This is necessary for reasons of consistency for the tables in classic Profit Center Accounting. If you exclusively use Profit Center Accounting in the General Ledger Accounting (new) or Profit Center Accounting in the universal journal, you no longer need to create a dummy profit center. If you still receive an error message because no dummy profit center can be found, contact us in a customer incident.
15. Unvaluated material processes (KSTAT = U)
In classic Profit Center Accounting, documents with KSTAT = U that have initial values but a filled quantity, are transferred (include LGIN1F03 / subroutine process_rwbeleg_pca -> perform quantity_relevant). Whether a quantity is set depends, among other things, on the set quantity indicator (XMFRW) in Logistics (SD/MM) and can be influenced by the central quantity module AC_DOCUMENT_QUANTITY_GET.
In Financial Accounting, documents with KSTAT = U that have initial values but a filled quantity were not posted until now. In SAP S/4HANA, there is a new logic. It is important that lines without value but with quantity (VMSL) in the table ACDOCA must be retained for inventory valuation in the ML. For this purpose, the system checks the line items for relevancy. If only one posting line remains (for example, an inventory line with KTOSL = BSX) after the relevance check, the system creates an offsetting line with the same account and KTOSL = OSI. See also SAP Note 2503258.
16. Postings from CO
Implement the BAdI BADI_FINS_POSTING_INTF with the method ACT_COFI_PCA_INTEG_WITH_CC_ITM to control whether in the future, CO postings to classic Profit Center Accounting are transferred using the new CO-FI interface or continue to be transferred directly from CO. By activating the parameter RV_IS_ACTIVE, you enable the update of the complete CO document including company code clearing lines in classic PCA.
Set the parameter RV_IS_ACTIVE of the method ACT_COFI_PCA_INTEG_WITH_CC_ITM to ‘X’ if you want the CO document including the company code clearing lines to be updated in PCA.
17. Tables
17.1 T882
In SAP S/4HANA, the entry in table T882 is still relevant for the ledger 8A of classic Profit Center Accounting (as well as for ledgers used in FI-SL). However, only the field VTRHJ is used for the ledger 8A. In the field VTRHJ, the carryforward year of the last execution of transaction 2KES (balance carryforward PCA) is set. It is important for the correct execution of transaction 2KES. All other fields are irrelevant for processing in classic PCA. The local currency (HSL) is always derived from the information of the company code (table T001). The PCA local currency (KSL) is always derived from the information of the controlling area (table TKA01).
MP's S/4HANA 