Creating Electronic Document and Legal Report

It is important to first establish a solid foundation of knowledge about the electronic documents processingframework that will be essential for successfully implementing your custom solution.

Developer Extensibility

Developer extensibility enables you to create custom ABAP code in SAP S/4HANA Cloud Public Edition systems. It combines the benefits of custom ABAP development with cloud-ready restrictions, ensuring your extensions are upgrade-stable and follow the SAP S/4HANA programming model.

This extensibility is critical for implementing country/region-specific requirements in countries or regions that do not havestandard localization delivered by SAP.

SAP Document and Reporting Compliance

The electronic document processing framework extracts information from source documents (like sales invoices) and creates standardized electronic files for submission to tax authorities. The framework provides extension points to customize this process for specific country/region requirements.

In this lesson, we'll implement an outgoing invoice scenario for a customer local version, including:

• Document creation from sales orders
• Electronic document generation
• Communication with tax authorities
• Status tracking and management
• Additional features such as email notifications and PDF generation

The SAP Document and Reporting Compliance lectronic document processing framework extensibility requires a 3-System Landscape (3SL), which consists of Development, Customizing, and Production tenants.

In contrast, the Design Time of SAP Document and Reporting Compliance Statutory Reporting framework extensibility requires only a 2-System Landscape (2SL), meaning a Development landscape is not necessary for basic extensions. However, if you need specific developments or custom CDS views for your reports, a 3-System Landscape is necessary.

This training requires the following roles to extend SAP Document and Reporting Compliance.

Applications required in Development tenant:

• BR_DEVELOPER (Developer)

• BR_SHIPPING_SPECIALIST (Shipping Specialist)
• BR_BILLING_CLERK (Billing Clerk)
• BR_AR_ACCOUNTANT (Accounts Receivable Accountant)
• BR_BPC_EXPERT (Configuration Expert - Business Process Configuration)
• BR_EXTERNAL_AUDITOR (External Auditor)
• BR_INTERNAL_SALES_REP (Internal Sales Representative)
• BR_GL_ACCOUNTANT (General Ledger Accountant)

This training requires the following apps to create a scenario for SAP Document and Reporting Compliance.

• Manage eDocument Type
• Manage eDocument Interface
• Manage eDocument Process

• Manage Sales Orders
• Create Outbound Deliveries
• Pick Outbound Delivery
• Create Billing Documents
• Post Incoming Payments
• eDocument Cockpit / Manage Electronic Documents

When implementing SAP Document and Reporting Compliance in a system, developers need to set up the ABAP Developer Tools (ADT) and configure a connection to the embedded Steampunk environment. This section outlines the necessary steps for setting up a development environment.

• Log in to the SAP S/4HANA Cloud development tenant
• Ensure they have the appropriate developer authorizations (typically through the BR_DEVELOPER role)
• Identify the system URL, which follows the format: https://[tenant-ID].s4hana.cloud.sap/ui

ABAP Development Tools is an Eclipse-based development environment that enables creation and modification of ABAP code:

• The SAP Development Tools website provides installation resources
• Installation instructions vary by operating system and should be followed carefully
• ADT requires a compatible version of Eclipse, which the installation guide specifies
• After installation, Eclipse should be restarted to activate the ABAP Development Tools

To connect ADT to an S/4HANA Cloud system:

• Eclipse with ADT installed should be launched
• From the menu, File → New → ABAP Cloud Project should be selected
• The system URL should be entered in the format: https://[tenant-ID].s4hana.cloud.sap/ui
• The "Open Logon Page in Browser" option enables authentication with developer credentials
• Clicking "Next" and then "Finish" completes the project creation

When extending the SAP Document and Reporting Compliance electronic document processing framework, a dedicated development package should first be created to organize all custom objects:

1. In the ABAP Development Tools (ADT), a new package should be created to contain all development artifacts
2. For our example we use the following pattern for the package naming convention: Z_[UserID]_[PackageName] (limited to 30 characters)
3. After creation, adding the package to favorites provides easier access during development

A custom table is required to store the eDocument's Globally Unique Identifier (GUID) and related information:

The table should be created with an appropriate structure to store GUID, description, and other relevant fields.

A naming convention such as ZTT_[UserID]_[TableName] (limited to 16 characters) should be followed.

Custom data types are needed when the standard "eDocument Framework Extended Data Types" do not provide all required structures:

1. A data type interface should be created for mapping the "eDocument Track ID" used in service communications
2. This interface will be used across multiple components:
   • In the eDocument Handler Class (process_response and process_status_res methods)
   • In the Mapping Class (map_getStatus_request and map_invoice_response methods)
   • In the Interface Connector Class (if_edocument_int_conn_ext~get_source_data method)
3. A naming convention such as ZIF_[UserID]_[InterfaceName] (limited to 30 characters) should be followed

A root class for implementing the methods required for eDocument creation and processing must be developed:

1. Initially, two methods are required for creating the eDocument:
   • process_create method: Handles the creation logic
   • update_file_table method: Updates the custom table with relevant information
2. A naming convention such as ZCL_[UserID]_[ClassName] (limited to 30 characters) should be applied

This step involves checking and/or creating the eDocument Type, eDocument Interface, and eDocument Process for development.

The eDocument Type and eDocument Interface ID will be used inside other configurations and/or inside development work.

The eDocument Process will be used to call the eDocument Class and inside other configurations.

The following simulation demonstrates how to access these configuration steps from the Fiori Launchpad in the development system:

An enhancement implementation is required to extend the standard behavior:

1. Create a new enhancement implementation for the Business Add-In (BAdI) EDOCUMENT_BASE_EXT.
2. A naming convention such as ZEI_[UserID]_[EnhancementName] (limited to 30 characters) should be followed

A class implementing the BAdI interface should be created to determine which process configuration will be used to create the eDocument or for the communication with the service.

1. The class should implement the IF_EDOCUMENT_BASE_EXT interface
2. A naming convention such as ZCL_[UserID]_[ClassName] (limited to 30 characters) should be followed

To ensure proper integration between standard accounting documents and the custom eDocument processing, the following configuration activities must be verified:

• Assign eDocument Type to Accounting Document Type (102188):
  • This mapping connects standard accounting document types with your custom eDocument Type
  • Without this assignment, the system won't trigger eDocument creation when accounting documents are posted
• Activate Additional eDocument Instance Creation (102637):
  • This setting enables the system to generate eDocument instances automatically
  • It must be properly configured to ensure seamless integration with the posting process

For detailed guidance on configuring these settings, refer to the following exercise which demonstrates the correct configuration values and procedures.

In the following exercise you will explore the process of creating a new SD invoice which generates a corresponding entry in the Manage Electronic Documents application. This process demonstrates how standard SAP transactions integrate with the SAP Document and Reporting Compliance.

To establish communication with external tax services, a Service Consumption Model must first be created:

1. A WSDL file defining the Send Invoice Service must be obtained
2. A new Service Consumption Model should be created in the development package
3. The Service Type should be set to "Web Service" with the WSDL file uploaded as the metadata source
4. After activation, the model will generate proxy classes that can be used in subsequent development

Communication with external systems requires an Outbound Service definition:

1. A new Outbound Service should be created within the development package
2. The service type should be defined as "SOAP"
3. The service interface must reference the proxy class generated from the Service Consumption Model
4. After activation, this service definition can be used in Communication Arrangements

A Communication Scenario provides a container for related services:

1. A new Communication Scenario should be created in the development package
2. The previously configured Outbound Service must be added to the Outbound tab
3. After activation, the scenario should be published locally for use in the system
4. This scenario will be referenced when creating Communication Arrangements

A Communication System defines the technical connection details:

1. The system hosting the web service must be identified (e.g., its hostname)
2. Authentication methods (typically User ID and Password) must be configured
3. In a real implementation, the Communication System may need to be created if it doesn't exist

The Communication Arrangement connects scenarios to systems:

1. A new Communication Arrangement should be created using the previously defined Communication Scenario
2. The arrangement should be linked to the appropriate Communication System
3. Specific path information for the service endpoint must be configured

A mapping class is required to transform business data into the format expected by the tax authority:

1. A new class should be created to implement the mapping logic
2. Three primary methods should be implemented:
   • map_invoice_request: Prepares data for sending
   • call_request_proxy: Calls the web service
   • map_invoice_response: Processes the service response
3. This class will be called by the Interface Connector class

A Business Add-In (BAdI) implementation is needed to handle the communication process:

1. A class implementing the IF_EDOCUMENT_INT_CONN_EXT interface should be created
2. Two methods must be implemented:
   • if_edocument_int_conn_ext~get_source_data: Retrieves data needed for the service
   • if_edocument_int_conn_ext~trigger: Handles the service call
3. This class will be called through the enhancement implementation

The enhancement created earlier must be updated:

1. The BAdI EDOCUMENT_INT_CONN_EXT should be added to the enhancement implementation
2. This connects the custom connector implementation to the framework

The eDocument Handler Class requires additional methods for sending documents:

1. Four new methods should be added:
   • process_request_send: Prepares the send request
   • process_trigger_send: Triggers the sending process
   • process_sendedoc: Processes the send operation
   • process_response: Handles the service response
2. These methods will be called based on the eDocument Process configuration

The eDocument Class configuration must be updated to incorporate the sending functionality:

1. For this part of the development, you will need to create four methods used to send the eDocument through eDocument Cockpit.
2. Remember if you copy the example class, you will need to replace the table name with yours.
3. You can use the "ZCL_DRC_EDOCUMENT" class as an example for this part of development.
4. The methods for this step are:
   • The "process_request_send" method
   • The "process_trigger_send" method
   • The "process_sendedoc" method
   • The "process_response" method

1. Process Step: Create one new line for each new method in the class.
2. Process Step Version: Define the versions for the new steps.
3. Process Step Variant: Specify the variants for the new steps.
4. Process Step Result: Specify the possible outcome for each new step.
5. Status Flag Name: Determine the new flags needed.
6. Status Flag Position: Specify for each flag and process step, what options are mandatory for each step.
7. Status Flag Check: Specify for each flag and process step, what options are mandatory for each step.
8. Status Flag Change: Specify how the flags will be affected by each new process step result.
9. Actions incl. Variants for a Process: Specify the additional valid action that will appear in the cockpit for the eDocument process type.

10. Process Steps executed by an Action: Specify how the new action will affect the process steps. If some step is contained programmatically inside another, mark it as "included".

    
11. Process Status for Process: Define the possible process statuses for the new instances.
12. Process Status Determination: Combining the results of individual actions, define the process status determination.
13. Process Step Interface Determination: Connect the process steps with the eDocument Interface.

To test the Send eDocument functionality after completing all configurations and development:

1. Navigate to the Fiori Launchpad and open the "Manage Electronic Documents" application
2. Select the tab corresponding to your custom eDocument Process
3. Locate and select a document with "Process Status Description" displaying "Created"
4. Click the "Submit" button in the toolbar to initiate the transmission
5. After successful processing, the "Process Status Description" should update to "Track ID Received," indicating that the document was successfully sent and acknowledged by the tax authority system

This status change confirms that the integration between your SAP system and the external tax authority service is functioning correctly.

1. Obtain the WSDL file for the Get Status Service
2. Create a new Service Consumption Model in your development package
3. Select "Web Service" as the Remote Consumption Mode
4. Upload the obtained WSDL file as the service metadata source
5. Activate the Service Consumption Model

1. Create a new Outbound Service in your development package
2. Set "SOAP" as the Service Type
3. Reference the proxy class generated by the Service Consumption Model
4. Activate the Outbound Service

1. Open the existing Communication Scenario created earlier
2. Add the new Outbound Service to the Outbound tab
3. Activate and publish the updated Communication Scenario

1. Open the existing Communication Arrangement
2. Add the endpoint path for the Get Status service
3. Enable the "Service Status" option
4. Save the updated arrangement

1. Update the existing mapping class with three new methods:
   • map_getStatus_request: Prepares the status request
   • call_getStatus_proxy: Calls the status service
   • map_getStatus_response: Processes the status response

1. Enhance the existing BAdI implementation class
2. Update the if_edocument_int_conn_ext~trigger method to handle the Get Status request type

1. Add two new methods to the eDocument handler class:
   • process_status_request: Prepares the status request
   • process_status_response: Processes the status response data

1. Process Step: Create one new line for each new method in the class.
2. Process Step Version: Define the versions for the new steps.
3. Process Step Variant: Specify the variants for the new steps.
4. Process Step Result: Specify the possible outcome for each new step.
5. Status Flag Name: Determine the new flags needed.
6. Status Flag Position: Add a position for the new flags.
7. Status Flag Check: Specify for each flag and process step, what options are mandatory for each step.
8. Status Flag Change: Specify how the flags will be affected by each new process step result.
9. Actions incl. Variants for a Process: Specify the additional valid action that will appear in the cockpit for the eDocument process type.
10. Process Steps executed by an Action: Specify how the new action will affect the process steps. If some step is contained programmatically inside another, mark it as "included".
11. Process Status for Process: Define the possible process statuses for the new instances.
12. Process Status Determination: Combining the results of individual actions, define the process status determination.
13. Process Step Interface Determination: Connect the process steps with the eDocument Interface.

After completing all the development and configuration steps, the Get Status functionality can be tested to verify that it correctly retrieves the status from the tax authority:

1. Access the Fiori Launchpad and open the "Manage Electronic Documents" application
2. Navigate to the tab corresponding to your custom eDocument Process
3. Identify and select a document that has been submitted (with "Track ID Received" status)
4. Click the "Get Status" button in the toolbar
5. After processing, observe that the "Process Status Description" updates to either "Accepted by Tax Authority" or "Rejected by Tax Authority" based on the response received

This status change confirms that your implementation can successfully query the tax authority's system and interpret the response to update the document's status in SAP.

1. Create an implementation of the Business Add-In (BAdI) EDOC_PART_CONN_CHANGE_EMAIL
2. Implement the change_email_to_customer method to retrieve the appropriate email address
3. The implementation can use custom logic or reference business partner data through a CDS view

1. Extend the existing eDocument handler class with a new PROCESS_SENDTOCUSTOMER method
2. This method will handle the email preparation and sending process

1. Process Step: Create one new line for each new method in the class.
2. Process Step Version: Define the versions for the new steps.
3. Process Step Variant: Specify the variants for the new steps.
4. Process Step Result: Specify the possible outcome for each new step.
5. Status Flag Name: Determine the new flags needed.
6. Status Flag Position: Add a position for the new flags.
7. Status Flag Check: Specify for each flag and process step, what options are mandatory for each step.
8. Status Flag Change: Specify how the flags will be affected by each new process step result.
9. Actions incl. Variants for a Process: Specify the additional valid action that will appear in the cockpit for the eDocument process type.
10. Process Steps executed by an Action: Specify how the new action will affect the process steps. If some step is contained programmatically inside another, mark it as "included".
11. Process Status for Process: Define the possible process statuses for the new instances.
12. Process Status Determination: Combining the results of individual actions, define the process status determination.
13. Assign the function to the toolbar button

Your e-mail domain must be maintained the list of allowed domains.

To this end, open the Implementation Activities app and then execute the activity under path General Settings → Extensibility → Output Management → Define Allowed Email Receiver Domains for Email Outbound.

After completing all configurations, users can select a document in the eDocument Cockpit and click the "Send to Customer" button to initiate the email transmission process. The system will use the configured email address to send the electronic document to the customer.

You will add a new empty status in the eDocument Process Configuration to be the first parent status, because it does not accept the fields to be empty in the Flow Chart configuration.

Note that this status won't affect the document count calculations.

Start by opening the app "Manage eDocument Process" and apply the following steps.

1. Process Status for Process: Add new empty status.
2. Manage Electronic Documents App: Flow Chart - Add status hierarchy.

1. After configuring the status hierarchy:
2. Access the "Manage Electronic Documents" application
3. Filter for your custom eDocument Process
4. Click the "Chart View" button in the toolbar
5. The system will display a visual representation of your documents organized by status
6. This view provides at-a-glance insights into the processing status of all documents

The flow chart visualization helps users quickly understand the distribution of documents across different processing stages, enhancing monitoring and reporting capabilities.

To enhance the mapping for standard eDocuments, developers need to implement a specific Business Add-In (BAdI):

1. Create an implementation of the BAdI EDOC_ADAPTOR_CLOUD
   • This BAdI is specifically designed for extending standard mapping
2. Implement the SET_OUTPUT_DATA method
   • The standard mapped data is provided in the CS_OUTPUT_DATA parameter
   • Developers can access this data structure to add or modify values
3. Extend the data as needed for specific requirements
   • Add fields required by local tax authorities
   • Modify standard values to comply with country-specific requirements
   • Apply business logic for specific document types

When implementing this enhancement:

1. The modifications should be minimal and targeted to specific requirements
2. Changes should be properly documented for maintenance purposes
3. Testing should verify both the enhanced data and that standard functionality still works correctly
4. Consider performance implications when extending the standard mapping

This enhancement approach provides a clean, upgrade-stable way to adjust electronic document output without modifying standard SAP code, ensuring long-term maintainability within the SAP S/4HANA Cloud environment.

Further information is available at the SAP Help.