Conversion to SAP S/4HANA with Coding Block Enhancement in SAP ECC system
2023-12-19 11:57:21 Author: blogs.sap.com(查看原文) 阅读量:31 收藏

About the Blogpost:

This blogpost is a general guidance for Customers, Partners, Solution Experts, Enterprise Architects and SAP Finance Consultants in a situation, where customer system has active coding block in FI-GL module in the existing SAP ECC system and planning for the conversion to SAP S/4HANA. The details explained in the blog is based on certain customer situation, available SAP standard documentations and released notes. The situation/status of the system may differ from customer to customer.

Details on the problem statement:

During the solution mapping and implementation in SAP ECC system, as a customer you decided to activate the additional attribute in FI-GL module so that the additional field is updated in the GL line items for reporting.

To perform the coding block extension in SAP ECC, you have incorporated the new field in the include structure CI_COBL. The CI_COBL has been included in all the tables relevant to the coding block, so that new field can thus be entered in these tables. While maintaining the filed name, you have entered the field name using the naming convention beginning with ZZ or YY as per the instruction provided in SAP standard.

(Pic-1: Configuration path of coding block)

(The above picture is from a reference system and may differ from your system status)

(Pic-2: Coding block activation sample display)

(The above picture is from a reference system and may differ from your system status)

As part of the transition or conversion to SAP S/4HANA, you are interested to analyse and understand the impacts of those enhancement (as explained above) of coding block extension on the migrated FI-GL line items in the ACDOCA table in SAP S/4HANA system.

Solution Guideline:

  1. About Classic Coding Block functionality in SAP S/4HANA:

Before you understand the impact, you may need to note the below guidelines in SAP S/4HANA about the coding block functionality availability.

  • “Classic” Coding Block extensibility using OXK3 transaction and CI_COBL structure is available in SAP S/4HANA
  • This functionality can be widely used in SAP GUI transactions, in MM, FI and CO. You can easily extend many processes that lead to journal entries in the ACDOCA table. On the other hand, many additional tables are also extended including MSEG, EBKN and EKKN, which may be unnecessary for some use cases.
  • It is available in many Fiori apps that post journal entries as of SAP S/4HANA Finance 1605 and SAP S/4HANA (On-Premise) 1610 onwards.
  • Derivation and validation possible with the Validation/Substitution tool (GGB0/GGB1 transactions).
  • It is Limited to 18 fields (see SAP Note 885181 for a workaround).
  • Only CHAR and NUMC data types allowed (see SAP Note 130174).
  • It is not used for customer or supplier line items (account type D or K in ACDOCA table), but substitution is possible with FI callup point 2.
  • Analytics: As of SAP S/4HANA (On-Premise) 1610, you can use the SCFD_EUI transaction to publish a classic Coding Block field to the S/4HANA key user extensibility app (Custom Fields and Custom Logic apps) and subsequently use it in CDS-based analytics, in the same way as for any field initially created in the key user app.
  • Interfaces: BAPI_ACC_DOCUMENT_CHECK/POST interfaces and other interfaces support CI_COBL fields.

SAP strongly recommends using the extensibility options. In general, it is not recommend extending journal entry line items by creating append structures direct in the SE11 transaction. You should never create an append structure direct to the ACDOCA table as this causes issues such as the syntax error.

  1. Details to be considered during the conversion:

Below are the key points which need to be considered during your system conversion from SAP ECC to SAP S/4HANA.

  • If you want custom fields from BSEG, FAGLFLEXA table to be present in ACDOCA then structure CI_COBL must contains the custom fields. If you have used the CI_COBL structure, then they will be available in ACDOCA by default.
  • If you activated the field within customer enhancement CI_FAGLFLEX04 for FAGLFLEXA table which is not there in CI_COBL, then to have these fields in ACDCOCA you must add this fields in CI_COBL structure.
  • Followed by the above additional activation, you must generate the CDS view. After the generation of the CDS view, the fields should be available in ACDOCA.
  • During a standard conversion, the data is migrated to ACDOCA with the below logics are available in standard program:
    • Logic to update ACDOCA standard fields from optional fields of New G/L like FAGLFLEXA-ZZAUFNR to ACDOCA-AUFNR etc. But there is no logic to migrate data from an optional field in New G/L to customer field in ACDOCA.
    • Logic to update ACDOCA CI_COBL fields from BSEG is available.
    • Logic to update customer fields from BSEG & COEP which are not part of CI_COBL via append structure to append INCL_EEW_ACDOC. The migration program will then consider these fields in the line-item migration, i.e. fields with identical name in BSEG/COEP, and in the append to INCL_EEW_ACDOC will be migrated from BSEG/COEP to ACDOCA automatically.
  • For a scenario of fields of Appends to COEP and BSEG missing in table ACDOCA for more details, you may refer snote- 2160045 – S/4HANA Finance: Fields of Appends to COEP and BSEG missing in table ACDOCA
  • The best approach you can take is to add the custom field to BSEG via CI_COBL so that it is automatically there in ACDOCA. But you should ensure the data availability in the BSEG-ZZZZZ field for all records in ECC before starting their upgrade to S/4HANA.
  • Along with BSEG, the ‘ZZ*’ fields need to be part of totals table FAGLFLEXT (you can check FAGLFLEXT_BCK) via coding block extension. If the field is not available in FAGLFLEXT, system will create the additional technical documents in ACDOCA system to balance the amounts. For details, please refer the note-  3378282 – Technical documents in ACDOCA
  • Please note- You can use the report ‘FGL_MIG_REGENERATE_CDS’ to regenerate the CDS view every time there is any change to DDIC structures of tables used in migration. The report ‘FINS_MIG_UJ_MAPPING_GENERATE’ is used to dynamically generate the class which is responsible for migration of line items.
    This determines the logic to map fields from BSEG, COEP, FAGLFLEXA, BKPF, COBK etc to ACDOCA using system specific customizing.
  • So, whenever there is a change to any DDIC structures, you need to run the report ‘FGL_MIG_REGENERATE_CDS’ followed by FINS_MIG_UJ_MAPPING_GENERATE to make sure the migration artifacts are up to date.

Additional reference SAP notes related to the subject:

Conclusion: The above technical details will provide the required details during a situation of conversion to SAP S/4HANA from SAP ECC system with Coding Block enhancement. However, if the details shared here does not help you in resolving your query or issue, you may reach out to SAP support through the proper channel as we believe the situation may differ from customer to customer.

This blogpost is brought to you by the SAP S/4HANA RIG.

(Dear reader, we appreciate your time and thank you for reading the blog post. Please feel free to share your feedback (if any) from your experience in your project to add more details to the content and enrich it further).


文章来源: https://blogs.sap.com/2023/12/19/conversion-to-sap-s-4hana-with-coding-block-enhancement-in-sap-ecc-system/
如有侵权请联系:admin#unsafe.sh