In January we went live with a greenfield SAP implementation, using New G/L. Unfortunately due to a wrong customizing setting, intercompany postings were posted to the table FAGLFLEX without defining key fields populated. The fields missing were, amongst others RASSC (Partner-company) and RMVNT(movement type). This means that elimination and consolidation were difficult. We corrected the original issue, however these tables (FAGLFLEXA/FAGLFLEXT) still contain the “empty” values.
We did some investigation and logged a message with SAP support:
“We are currently implementing SAP BPC (Consolidation). We are using New-General Ledger and extraction with Datasource 0FI_GL_12. The source of this extractor is FAGLFLEXT. Our ECC system went live at 1-1-2015 and during our tests we found that we are not receiving the Partner-company from ECC. This is due to a setting in the Customizing of New-GL. We did not assign the FIN_CONS scenario to ledger “0L”. Now we like to assign the FIN_CONS scenario to ledger “L0” and rebuild FAGLFLEXA and FAGLFLEXT. We found two reports who should do this trick:- Close the system for endusers.- Run RGUDEL00 to empty the ledger- Assign scenario FIN_CONS to ledger “0L”.- Run RGURECGLFLEX to rebuild the ledger. But several posts on SDN tell us to contact SAP before we start this procedure. Maybe you have already programs to transfer Additional fields (ie. Partner-company) to FAGLFLEXA/FAGLFLEXT? Could you please advise on a short notice?”
SAP then promptly replied with the following:
It is the developer recommendation about the NON usage of RGUDEL00 for the mentioned purpose
"Deletion of new g/L and updating it again e.g. using some tools which are delivered dark for Support usage only will cause inconsistencies especially in case document splitting is used. This means the usage of such tools which have NEVER been released for customer usage are rated as a modification, subsequent issues are well known and are out of scope of support.
This means using such tools you will mess up balances per additional account assignments. SAP Support will rate such issues, which easily can be identified as a subsequent data manipulation, as a consulting issue.
RGURECGLFLEX and RGUDEL00 will create such inconsistencies. It is exactly those two tools which will cause follow up issues which we will not resolve as Support issue. Those have not released for customer usage as those create inconsistencies. Those are not migration programs and those are definitely NOT used within migration. Those are only used in a modified way. E.g. in case of document splitting: split information is created first and new g/L view is created based on this split information.
the usage of such tools is definitelly NOT supported.”
TL;DR: the tools we found as an option cannot be used.
However we are now doing a sFin upgrade and accompanying conversion. Our main question is: in the conversion strategy for this upgrade, is there any way we can make sure that in the new journal views the right values get populated with the partner company and movement type?