The migration to SAP S/4HANA is SQL-based and cannot be compared to a migration from classic G/L to new G/L. True False.
Partitioning Universal Journal Entry Line Items Table (ACDOCA), which statements are correct: Partition ACDOCA only if you expect more than 500 million records. You must partition the table if you expect to reach 2 billion records. SAP recommends 300 million to 500 million records as an optimum partition size.
Migration regenerates the views for all related applications of table ACDOCA: Regenerate customer-specific fields in the CDS views. Regenerate the mapping of customer-specific fields in the data migration. Redirect SELECT-statements from the concerned database tables to the corresponding compatibility views.
In checking consistency of G /L Accounts and Cost Elements - A typical error message is: "Primary cost element XYZ (type 1) not found in chart of accts XYZ". There is an entry in table CSKA of controlling but no entry in table SKA1 Financial Accounting. Table CSKA will no longer be used and serves as the basis for this migration step. Every inconsistency should be corrected, otherwise there will be a wrong account type after migration. Cost elements that are not in FI are migrated as secondary cost G/L accounts.
Default assignments are no longer possible on cost center or internal orders. Any legacy default assignments are migrated automatically by the system to maintain the status quo. Migrated values are transferred to transaction OKB9 (table TKA3A). True False.
Merging cost elements and G/L accounts requires adjustments to authorizations. Authorizations are not migrated automatically. True False.
In activity reconcile transactional data, the system checks the following: Zero balance compliance and that all line items have corresponding document headers. Corresponding entries in document lines table (BSEG) and in line items table of New G/L (FAGLFLEXA) have the same amount. Consistency of new G/L index tables (FAGLBSIS, -SAS) with table BSEG_ADD. Database views for indexes return the same values as backup tables (backup tables contain data of secondary index tables from former release [for example, BSID_BCK for BSID). For CO document: the existence of document header per line item.
Data enrichment fills are as follows: BSEG-fields from BKPF. COEP from COBK and OBJNR. Profit center fields into CO line items. Company code data into old CO line items. BSEG_ADD from FAGLBSIS/BSAS.
Migrate Accounting Documents to Universal Journal Entry Structure, the universal journal (table ACDOCA) is filled in this activity. The document is called Universal journal entry (UJE) and combines the transactional data of the applications FI, FI-GL, CO, ML and FI-AA. It is enhanced by characteristics of account based CO-PA, if active. Different documents from different applications are migrated to a single document in table ACDOCA (Table BSEG does not change).
In IMG activity, Check Migration of Accounting Documents to Universal Journal Entry, the system checks if all accounting documents have been migrated correctly. Correct Incorrect.
Allocations for profit centers, segments, and so on, in new G/L are based on the totals tables FAGLFLEXT. Existing allocations must be migrated to the CDS View ACDOCT Deprecated - Totals Compatibility View on ACDOCA.
Existing allocations in Classic GL must also be migrated? True False.
Totals are calculated by aggregating line items in SAP S/4HANA. There can be differences between the sums of migrated line items and the original totals. The migrate balances activity posts a delta on the level of G/L totals as a difference between the sum of line items to balances carried forward. It is the same for Controlling and Material Ledger. Migrated line items plus balance adjustments from migration equal the original totals.
Balance Carry Forward Entries in SAP S/4HANA Old balance carry forward entries (FAGLFLEXT or GLTO) are stored in table FAGLFLEXT_BCK or GLTO_BCK. New balance carry forward entries are updated and stored in table ACDOCA as line items. New balance carry forward entries for customer and vendors are calculated on-the-fly (transaction code F.07) Old balance carry forward entries (FAGLFLEXT or GLTO) are stored in table ACDOCA.
The system takes the cost center from Controlling and does not reconcile this field with FI. The system also takes amounts from the ML and reconcile this field with FI. The system also takes amounts from the ML and does not reconcile this field with FI.
Which statements are correct: The depreciation run adopts planned asset values and posts them. The posting document is updated at asset level. The calculation of the planned depreciation remains as before, but values are stored in another table. Planned depreciation is determined with each master record change and with each posting on the asset and is updated in database accordingly.
House banks are no longer customizing objects. Migration is necessary to migrate these to separate bank account master data (from table T012K to FCLM_BAM_ACLINK2). House banks can be used in Bank Account Management Lite if not using new Cash Management. House banks can be used in Bank Account Management if using new Cash Management.
Business departments may be involved before setting migration to complete, to compare and to confirm that the migration has been performed successfully and correctly. True False.
There should be at least one correct and complete migrated system for testing purposes after migration. This is particularly important for new topics such as the following: New asset accounting. Customer vendor integration.
Activities after Migration include the following: Transfer of application indexes to cold storage (data aging). Fill due dates in FI documents. Fill the offsetting account in FI documents.
Check the correct statements: Migration programs are SQL-based and are much faster to run compared to, for example, the programs used for migration from classic to new G/L. The migration programs do not stop during runtime due to errors. Errors are collected and are shown in logs. The migration transfers data exactly as it is. The main challenge is data cleansing pre-migration.
Connect to the right ones: Application indexes that correspond to already archived documents are stored in tables The system calculates the net due date and the discount due dates and stores them in the following document tables to ensure high performance reporting on open items. Fill the offsetting account in FI documents - the following fields fills in tables accordingly to the customizing setting?
Offsetting Account Number (Field GKONT)
Offsetting Account Type (Field GKART)
G/L Account of Offsetting Acct in General Ledger Accounting (Field GHKON).
The simplification of posting logic provides the following benefits: Independent and complete depreciation areas of equal power Only one depreciation area per valuation necessary. No further depreciation areas (delta
areas) are necessary to portray a parallel valuation. New document display - Detailed impact of any transaction to the books Plan values in real-time - updated with every master data change and every asset transaction Asset balances in real time - APC posting run no longer required Posting to different periods are not possible. Navigation and drilldown per accounting principle. Transparency throughout the period and Elimination of reconciliation steps.
|
