The eDocument framework architecture is responsible for the success of the SAP Document Compliance solutions. This is an open framework, where currently SAP, customers and partners create and extend compliance related solutions. Now let's take a closer look.
Btw, If you are interested in learning more on this, kindly take a look at the training offering: WDEDOC - select country "Germany"
To understand how SAP Document Compliance - on Premise edition is architected, let's have a 2 steps approach:
From birds eye point of view, SAP Document Compliance (on premise edition) runs basically on 2 components: S/4HANA (or SAP ERP), and SAP Cloud Platform Integration.
For certain local solutions (e.g. Italy) also SAP Cloud Connector and SAP Cloud Platform Custom Domain is required.
Behind the scenes, everytime an action is executed (send to tax office, check current status, send to customer, etc...) a number of components participate to control the process flow, save the audit registers, achieve the technical connectivity, etc....
Lets take now a deep dive into the different functionalities we get from each component.
Note this presentation is more focused on the functionality and not on the real component architecture (e.g. the core part of the eDocument framework is the "process manager", but here it is split into functionalities).
Multiple source document types are supported from diverse SAP applications or external sources on framework level (e.g.: SAP Document Compliance List, SAP Document Compliance, Accounting Document, FI-CA Document, Goods Issue Posting, Goods Receipt Posting, Inbound Delivery, Invoice Verification, IS-U Print Document, Shipment, Sales/Purchase/Daily Ledger, Outbound Delivery, Real estate document, Billing Document without Accounting Data, Billing Document ,Billing Document with accounting data in FICA, Incoming Source File, Convergent Invoicing Document).
Local solutions integrate the source documents as required.
AIF makes sure no government interaction is overlooked, so all interactions are handled with this method.
AIF keeps the relationship between the compliance process and the source document requiring it, e.g. if you need to register an invoice, the invoice registration process is linked to the invoice. Also navigation from the cockpit.
This is one of the main benefits from AIF, to act as a technological buffer, and no matter what communication technology (file, ftp, proxy, IDoc) is required, the monitoring is standardized.
Also AIF integrates the SAP stardard application logging (SLG1 transaction) and it can also trigger alerts.
The local solutions provides mapping from the supported source document to the technical fields. This mapping builds the business content in technical format, later in another step, the final twiks are implemented to adjust the technology specific requirements.
From the govenment interaction some information may need to be stored in relational table to continue the business process. These compliance specific tables are provided by the local solution as well.
Many regulations also require extra steps or background jobs, there are generic steps managed by the framework, and in very particular situation there could also be some regulation specific process.
XML storage in AIF is integrated with the eDocument framework to keep all the records in case any auditing is required. For example in some countries approvals are implemented as complete documents rather than a number or string of characters.
Has this invoice already been presented to govenment? Is this transport already approved? May I retry sending this shipment for approval?
The answers to all these question come from the process manager, that describes as a finite state machine the different steps.
Along with the status management topic, the process manager also controls and triggers the internal steps to accomplish the required actions and to keep track of them.
Unless some exceptional situation arises or country specific manual action is needed, the framework runs silently all the compliance processes, also in case of errors, it is prepared to retry, retrieve messages from the govenment, etc...
So basically at runtime the SAP Document Compliance solution is running behind the scenes and the business user is not required to run any specific transaction.
The integration from the S/4 HANA or ERP to SAP Cloud Platform integration is also standardized and protected using internet standard protocols and formats. The web services runtime makes sure that all security precautions take place.
This is one of the main topics in SAP Document Compliance, it involves confidentiality, authentication, autorization, integrity and repudiations to certain extents.
In particular governments worldwide require a whole variety of encryption and signature techniques, and it supports them all.
Also, SAP Cloud Platform Integration offers business user friendly interface to manage digital identities in a secure manner.
Maybe you don't know but SAP Cloud Platoform Integration has succesfully undergone certifications and validation worldwide (including global financial service providers) and today it is the SAP backbone to manage electronic compliance, financial transactions, confidential human resources information, etc.
What should I consider in terms of security in my cloud scenarios?
No matter how difficult or tricky the format, SAP Cloud Platform integration can handle efficiently, including encodings, compressions ,namespaces, variations or even restrictions from tax offices side.
In general all tax offices use web services protocols worldwide (SOAP), so there is a high level of standardization. In some regulations, files or emails are also needed, and all those methods are also supported.
Sometimes root cause analysis involves deep dives into the integration case, going from the authentication, signature, format to content related issues. SAP Cloud Platform integration provides the tooling for that.
Also SAP Cloud Platform Integration is natively integrated to SAP Solution Manager, to monitor the integrations and also to receive alerts and manage them.
Learn more in our community or contact us, we are glad to help.
Btw, If you are interested in learning more on this, kindly take a look at the training offering: WDEDOC - select country "Germany"
To understand how SAP Document Compliance - on Premise edition is architected, let's have a 2 steps approach:
A: High level components
From birds eye point of view, SAP Document Compliance (on premise edition) runs basically on 2 components: S/4HANA (or SAP ERP), and SAP Cloud Platform Integration.
For certain local solutions (e.g. Italy) also SAP Cloud Connector and SAP Cloud Platform Custom Domain is required.
Behind the scenes, everytime an action is executed (send to tax office, check current status, send to customer, etc...) a number of components participate to control the process flow, save the audit registers, achieve the technical connectivity, etc....
B: Components more in detail
Lets take now a deep dive into the different functionalities we get from each component.
Note this presentation is more focused on the functionality and not on the real component architecture (e.g. the core part of the eDocument framework is the "process manager", but here it is split into functionalities).
Source Document
Multiple source document types are supported from diverse SAP applications or external sources on framework level (e.g.: SAP Document Compliance List, SAP Document Compliance, Accounting Document, FI-CA Document, Goods Issue Posting, Goods Receipt Posting, Inbound Delivery, Invoice Verification, IS-U Print Document, Shipment, Sales/Purchase/Daily Ledger, Outbound Delivery, Real estate document, Billing Document without Accounting Data, Billing Document ,Billing Document with accounting data in FICA, Incoming Source File, Convergent Invoicing Document).
Local solutions integrate the source documents as required.
Application Interface Framework (AIF)
XML Storage
AIF makes sure no government interaction is overlooked, so all interactions are handled with this method.
Business Process Relationship
AIF keeps the relationship between the compliance process and the source document requiring it, e.g. if you need to register an invoice, the invoice registration process is linked to the invoice. Also navigation from the cockpit.
Standardized monitoring
This is one of the main benefits from AIF, to act as a technological buffer, and no matter what communication technology (file, ftp, proxy, IDoc) is required, the monitoring is standardized.
Also AIF integrates the SAP stardard application logging (SLG1 transaction) and it can also trigger alerts.
Local Solution
Business Data Mapping
The local solutions provides mapping from the supported source document to the technical fields. This mapping builds the business content in technical format, later in another step, the final twiks are implemented to adjust the technology specific requirements.
Business Process Data Storage
From the govenment interaction some information may need to be stored in relational table to continue the business process. These compliance specific tables are provided by the local solution as well.
Local Specifics
Many regulations also require extra steps or background jobs, there are generic steps managed by the framework, and in very particular situation there could also be some regulation specific process.
eDocument Framework
History
XML storage in AIF is integrated with the eDocument framework to keep all the records in case any auditing is required. For example in some countries approvals are implemented as complete documents rather than a number or string of characters.
Compliance process status management
Has this invoice already been presented to govenment? Is this transport already approved? May I retry sending this shipment for approval?
The answers to all these question come from the process manager, that describes as a finite state machine the different steps.
Compliance process choreography execution
Along with the status management topic, the process manager also controls and triggers the internal steps to accomplish the required actions and to keep track of them.
Automation
Unless some exceptional situation arises or country specific manual action is needed, the framework runs silently all the compliance processes, also in case of errors, it is prepared to retry, retrieve messages from the govenment, etc...
So basically at runtime the SAP Document Compliance solution is running behind the scenes and the business user is not required to run any specific transaction.
Web Services Runtime and Internet Communication Framework (ICF)
Communication standardization
The integration from the S/4 HANA or ERP to SAP Cloud Platform integration is also standardized and protected using internet standard protocols and formats. The web services runtime makes sure that all security precautions take place.
SAP Cloud Platform Integration
Security
This is one of the main topics in SAP Document Compliance, it involves confidentiality, authentication, autorization, integrity and repudiations to certain extents.
In particular governments worldwide require a whole variety of encryption and signature techniques, and it supports them all.
Also, SAP Cloud Platform Integration offers business user friendly interface to manage digital identities in a secure manner.
Maybe you don't know but SAP Cloud Platoform Integration has succesfully undergone certifications and validation worldwide (including global financial service providers) and today it is the SAP backbone to manage electronic compliance, financial transactions, confidential human resources information, etc.
What should I consider in terms of security in my cloud scenarios?
Technical Transformation
No matter how difficult or tricky the format, SAP Cloud Platform integration can handle efficiently, including encodings, compressions ,namespaces, variations or even restrictions from tax offices side.
Communication
In general all tax offices use web services protocols worldwide (SOAP), so there is a high level of standardization. In some regulations, files or emails are also needed, and all those methods are also supported.
Technical Logging
Sometimes root cause analysis involves deep dives into the integration case, going from the authentication, signature, format to content related issues. SAP Cloud Platform integration provides the tooling for that.
Also SAP Cloud Platform Integration is natively integrated to SAP Solution Manager, to monitor the integrations and also to receive alerts and manage them.
Learn more in our community or contact us, we are glad to help.
- SAP Managed Tags:
6 Comments
