Extending the Solution

In this section, we will look at the extensibility capabilities of SAP Document and Reporting Compliance. While more than 400 statutory reports and scenarios are delivered as standard by SAP, this is still a fraction of the statutory reports and scenarios that are there. Even for standard statutory reports and scenarios, there are instances when standard solutions need to be tweaked in order to suit specific business needs. The in-built extensibility capabilities of the framework makes it very easy and intuitive to enable such scenarios.

Let us take 4 common scenarios and see how extensibility can help us achieve these:

1. A regional statutory report is required which is not delivered by SAP
2. A standard SAP delivered statutory report or scenario needs to be adjusted due to a niche business process adopted by the customer
3. Adaptation of end-user behaviour, such as workflow and task list, for the customer's specific needs

In the upcoming sections, we will look at the extensibility capabilities of the two underlying technical frameworks - one for Statutory Reporting and one for electronic document processing and learn how they can be leveraged to fulfill the aforementioned scenarios.

Let's start with Statutory Reporting and its extensibility capabilities.

Before we elaborate the steps one needs to follow in order to create or extend a statutory report, let us acquaint ourselves with the technical artifacts that we will be making use of:

• Report Definition:

  A Report Definition is a template of the actual report output based on the legal mandates. It contains the number and type of files, structure of output and associated information.

• Report Category

  A Report Category emulates the characteristics of a legal report by combining the report definition with details like the phases of submission, the organizational unit level of reporting and the set of pre and post activities required.

• Reporting Activity

  A Reporting activity is a representation of a sub process within the overall reporting process. These activities are performed either pre or post the report generation activity.

If your use case requires you to build a custom report, it can be done by creating a report definition and then assigning it to the report category. A report definition can be created by following a guided process which is described below:

1. Defining general properties

   In this step, you can define the technical id of the report, its description and other general properties.

2. Defining parameters of the report

   In this step, you can define the various parameters on the basis of which the report would be generated.

3. Identifying and selecting the data sources

   In this step, you can define the data sources from which the information will be filled in the report. Various types of data sources are supported.

4. Mapping to output formats

   In this step, you can define the format and the structure of the document that the tax authorities mandate. You can also map the various elements in the document with the corresponding data sources defined in the previous step.

   To define the structure of the document, if a tax authority provides a schema of the same, it can be uploaded in the tool and the framework parses and creates the structure of the document.

5. Enabling custom logic

   To further customize the report, events can be utilized to write more specific logic.

6. Including business correspondence

   For certain specific scenarios where you also need to correspond with business partners e.g. sending withholding tax certificates via email

Once the report definition is created, it can be assigned to a report category. Post this, necessary configurations need to be performed and then this report can be used in the Run Statutory Reports app.

For electronic documents processing , we have an open framework to customize electronic document processing using BAdIs and the process manager.

You can customize XML documents, PDF formats, and business process integration. Of course, when we are talking for the BAdIs and using BAdIs to do the enhancement or create extensibility for electronic documents, we are not only talking about SAP S/4HANA Cloud, private edition, but also SAP S/4HANA Cloud Public Edition. In release 2208, we made most BAdIs also available via Steampunk in SAP S/4HANA Cloud Public Edition.

Please note that Steampunk is only available to SAP S/4HANA Cloud customers on the 3-tier landscape. In SAP S/4HANA Cloud, private edition, there are no restrictions.

At this point, we will understand why extensibility in electronic documents is important, and how it can benefit our customers in countries where SAP does not provide standard e-invoicing features:

• In the absence of extensibility options, the Document and Reporting Compliance solution faces the risk of becoming non-compliant with local legal requirements​​.
• The absence of extensibility options was preventing customers from enhancing the solution on their own.
• The ability to enhance the solution as per the local legal requirements will increase the adoption of Document and Reporting Compliance for SAP S/4HANA Cloud Public Edition.

Here, we can envision a typical scenario where we can apply extensibility to perform process improvement​.

Let’s take a look at the steps required to develop new processes for electronic documents in the Electronic Document Processing framework .​​Step 3: ​​Step 4: ​Step 5

• To build or develop objects required for communication between SAP cloud system to external service (for example, tax authority).
• ​​Preparation of XSD or WSDL as per tax authority file formats, and generate the proxy structures which will be used for mapping.

• Conversion of source invoice data into the tax authority file format defined in step 1.​
• Invoking API calls defined by the tax authority.

• ​Implementing process orchestration as per the tax authority defined process.

• Connecting all the objects created in the above steps, using BAdI implementations.​​

• End-to-end testing of the process once all the objects are implemented.​