Data Model of S/4 HANA Finance Data Migration

Case 1: Post S/4 HANA data migration some of your PBI, OneStream and etc. reports that were using ECC tables (FAGLFLEXA ,for example) as primary data source may start showing ‘incorrect’ values and you notice that ACDOCA- OSL, KSL, TSL, HSL, BSL are not balancing to 0 or totals are incorrect.

The reason for that is migrated document line items are now having COEP and COSP table entries merged into the same FI document in Universal Journal or ACDOCA table, which now becomes the only 'source of truth' in S/4 HANA environment.

From data migration model perspective, legacy FI entries are migrated with ACDOCA-MIG_SOURCE = G, F, M, A indicators (i.e. General Ledger, Material Ledger, Asset Accounting postings) while COEP and COSP table entries are merged with ACDOCA - MIG_SOURCE = 'C' indicator. Note that Controlling entries are not fully distinguished based on MIG_SOURCE = 'C', but rather by ACDOCA - CO_BELNR <> space. And in order not to duplicate the amounts so called ‘reversal’ or the correction line is also added into migrated document with MIG_SOURCE = 'R' indicator.

So, basically, FI data migration logic is as follows:

FI and CO documents merge into Universal Journal logic

And if you want to continue fetching FI data only in your PBI reports, OneStream and etc. it is required to add filtering by ACDOCA - MIG_SOURCE = ‘C’ and ‘R’ line items from the report output. Or just add filtering by ACDOCA - MIG_SOURCE = 'G', 'F', 'A', 'M' and that's it.

Same is approach is valid for FI-GL standard reporting tools reading data from ACDOCA, where applicable (FAGLB03, FAGLL03H and etc.) Exception is FBL3H t-code which is reading data from BSEG, so technically, in S/4 HANA your FBL3H will show 'inconsistent' data going forward and it is advised to stop using it / replace it with FAGLL03 or FAGLL03H (refer to SAP note 2886122 on that matter).

If any other filtering is required to get correct information based on migrated documents, it's always advisable to add filtering by BTTYP, for example. Assume, if you want to fetch BCF values only, proceed with adding ACDOCA - BTTYP = 'RFBC' and etc.

This is the standard design of FI data migration in S/4 HANA and details on how ACDOCA-MIG_SOURCE field needs to be adjusted throughout different reports is described also in attachment of SAP note 2408083.

Case 2: Assume, your PBI or OneSource report is using FAGLFLEXT as data primary and post S/4 HANA upgrade you notice the mismatch when validating OneSource amounts, that are actually built based on totals table) with line items of FAGLB03 ,FAGLL03 and etc. The reason for that is ,when drilling down into line items level, CO lines are excluded as per standard design, i.e. totals are never matching the line items values, which is happening because of line items reports are not fetching MIG_SOURCE = ‘C’ lines (migrated from COEP and COSP tables) into report output as per standard.

First and foremost solution here is to switch the OneStream data source to ACDOCA table. And if that's not feasible, then SAP is describing the solution alternative of adding FAGLB03_RESTRICT_MIG = ‘X’ and MIG_SOURCE_C_SIGN= ‘X’ parameters into FAGL_SETTINGS via SM30 t-code. Details on that approach are described in SAP note 2891129.

Finance Data Migration into S/4 HANA: FINS_RECON 119: &1/&2: Zer-Bal-Clrng account master data inconsistent

Main root cause of the error is zero balance clearing G/L account entries that exist in BSEG table, though automatically generated line items are never updated in BSEG. So existing BSEG entries, i.e. manual postings to zero- balance clearing G/L account are triggering the error message in GCC segment during data migration in FINS_MIG_STATUS t-code. Basically, system is checking if the balance of the G/L account is zero. 

Solution is to clear out existing balances of zero -balance G/L account manually in all Ledgers and activate ‘Post automatically only’ option via FS00 t-code (SKB1-XINTB = ‘X’).

By doing so, error message will be eliminated from the errors log during data migration.

Another important requirement listed in SAP note is that zero- balance G/L account needs to have ‘Only balances in local currency’ option activated (SKB1-XSALH = ‘X’).

In case of existing historical balances in foreign currencies, consider utilizing program FINS_SWITCH_XSALH for converting historical balances into local currency (refer to SAP note 3393227 for more details on how to enable the program for your release). This program is valid both for ECC (SAP_FIN 720 and higher and in S4CORE 102 and higher). 

In brief, FINS_SWITCH_XSALH program does the following:

(a) It runs conversion of historical entries in BSEG, ACDOCA and FAGL_SPLINFO tables from foreign currencies to local currency (Company Code currency)

(b)   As a result, you will see that ACDOCA – TSL amounts in foreign currencies converge to zero

(c)  SKB1 – XSALH indicator activated automatically, i.e. no manual activation via FS00 t-code needed. Note that user performing the FINS_SWITCH_XSALH program will be shown in G/L account master data change log for auditing purposes

Conversion of historical entries into local currencies is irreversible, hence required to be thoroughly tested in QA before proceeding with the conversion in Production. I’d suggest verifying all the financial reports to be verified before and after the FINS_SWITCH_XSALH program run. 

According to SAP note 9611937 requirements, zero- balance G/L account should be excluded from Foreign Currency Valuation program, so once SKB1- XSALH indicator activated, G/L will no longer be suitable for FAGL_FCV t-code.  

So, in your FINS_MIG_STATUS cockpit during S/4 HANA data migration, in case of existing balances in foreign currencies, you might still encounter FINS_RECON 119 but as a warning message.

Recommendation is to clear out foreign currency balances before data migration, or else accept the warning messages and proceed with correcting G/L account set- up post data migration. 

SAP CDS View 'Analytical Query'

Any custom report or a query can be easily generated via SQVI t-code as shown in the example below:

Suppose custom report needs to contain join of ANLA (Asset Master Record Segment), ANLZ (Time- Dependent Asset Allocations), T499S (Location) and ADRC(Addresses) tables. 

This can be achieved through creating table join via SQVI t-code:

Query output can be generated in ALV grid, classical view, Excel file and etc.:

Easy as that.

Now let's try utilizing CDS view called 'Analytical Query' in S/4 HANA for creating required query / or custom report. 

Step 1: Custom analytical query creation:

Go to 'Reporting' --> 'Query Design' option of the menu:

Select 'Custom Analytical Queries' tile:

Step 2: Create new query:

Step 3: Specify query name:

Step 4: Select query data source:

Step 5: Specify query output fields in 'Field Selection' tab of the view:

Step 6: Add filters and maintain fields status in 'User Input Values' tab of below view:

Step 7: Publish new query by pressing 'Publish' option:

Step 8: Go to Analysis for Office and select new query as data source:

Step 9: Maintain 'Asset Location Report' prompts: 

Step 10: Custom analytical query output validation:

Now in order to add T499S and ADRC table columns into the report, custom CDS view needs to be generated. 

Step 11: Custom CDS view generation: Go to 'Extensibility' --> 'Custom CDS Views' tile:

Press 'Create' option:

Step 12: Maintain primary and associated data sources:

Step 13: Select fields for custom CDS view output. Go to 'Fields selection' tab --> maintain fields in 'Selected Fields and Associations' tab of the below view:

Step 14: Publish custom CDS view:

Step 15: Creating a new query based on ZZ1_ASSET_LOCATION_03 view

Specify query name and select custom CDS view as data source:

Select fields for query output:

Maintain filters for Prompts screen of the report:

Save and publish new query:

Step 16: Go to ‘Query design’ tab and select ‘View browser’ app:

Step 17: Restrict view search by ‘Application component’ and by release status:

Step 18: Search results:

Step 19: Select ZZ1_FA_LOCATION query for fields validation:

Step 20: Show content of ZZ1_FA_LOCATION query:

Step 21: Adding dimensions into the view output:

Query output is correct as per below verifications:

Step 22: Save query as a tile:

Add new query into ‘My home’ tab of Fiori Launchpad:

Et voilà! :)

Error message XS850 'Cannot process message; maximum size exceeded'

Solving error no. XS850 error 'Cannot process message; maximum size exceeded':

So requirement is to issue email notification from background job with spool request as an attachment in it. 

Prerequisites:

(a) Create background job via SM36 t-code, by enabling sending email notification with spool requests in it:

(b) Schedule background job via SM36 t-code 

(c) Add email receiver under SMTP node via SCOT t-code:

(d) In my case attachment size is ca 3 MB, hence need to extend MAXLEN_BODYPART_ALI_SMTP  parameter size to 3 MB accordingly via SM30 t-code in SXPARAMS configuration view:

 

SAP FI TAX, BR NBS codes configuration

Services Codes (based on legal requirement LC 116)

Prerequisite:

There is no pre-configuration (customizing) needed.

SAP Configuration:

Transaction code: J1BTAX

Country: BR

Go to Entities menu and select NBS Codes option:

• In the Nomenclature Services Code column insert the codes numbers
• In the Description column insert the correct description of the NBS Code

Start entering NBS directory in above view manually.

Save.

SAP Material Ledger, Configuration of PU rule(s)

Issue description:

When posting of PU document for posted Invoice Receipt document via J1GP01 t-code, you’re getting error message stating that combination of Plant/Valuation class/Item category/Tax code entry is missing:

Root cause:

Missing configuration in J1GP02 view.

Solution:

Maintain missing entry in J1GP02 view. And then re-run J1GP01 t-code once again.

For more information on Materials Ledger t-codes check the following link.

Enjoy.

SAP Material Ledger t-codes

According to recent statistics, SAP Material Ledger topic is becoming the most viewed one...)

Okay, so below is the list of t-codes of Hellenization standard solution:

J1GVL_T01 t-code

Not needed any longer, but project should start with initial upload of stock to valuation table via J1GVL_T01 t-code (initial upload with 561 movement type);

MIGO/MIRO

Completion of GR/IR postings;

J1GP01 t-code

PU postings (FI postings that transfer the balance from SAP Stock account to the appropriate Greek purchasing account): update of foreign purchase accounts. It checks if the PU posting had already been done or not and then it continues to gather the necessary information needed to perform the posting;

J1GP05 t-code

Clearing of open items;

J1GVL_T04 t-code

Offline update of ML; 

J1GVL_T11 t-code

Initialize production run; 

J1GVL_T05, J1GVL_R3, J1GVL_RPU, J1GVL_RRV

Material valuation results check via running reconciliation reports; 

J1GVL_VL

Material valuation program;

J1GVL_P01 t-code

Running WHB analytical report; 

J1GVL_ALDI t-code

Reconciliation between WHB and ML: Analytical posing in testing/production modes;

J1GVL_S12 t-code

Compare valuation and AL postings; 

J1GVL_T15 t-code

WHB to CD utility. Export to .txt output file;

J1GVL_INVB t-code

to be executed during year end.