After implementing the DRC solution many times in different countries I’ve prepared some information on how to analyze the creation of the eDocument from SD.
Besides the obvious parts of reading the notes, reading the help page, preparing the lists of the requirements and so on I wanted to create a document to help when things go wrong in the tests/configuration/developments of the solution.
I always recommend for all DRC consultants to bookmark the DRC topic page in the community https://community.sap.com/topics/document-reporting-compliance and to check the blog posts in the blog feed from time to time to check the news on this area.
I summarized some relevant parts (in my opinion) where I had to debug it in the past to find issues and configuration errors.
If you have suggestions or comments about areas you'd like to see a more detailed analysis please leave a comment.
One classic example of error, invoice saved in VF01 but no eDocument created. You configured the system but you don’t know whats going on in this case.
I separated some interesting debug points to analyze the code and the behaviour of the solution and find out the reason for errors.
The first thing to find out is how the eDocuments are created. They do not come out of thin air, it requires notes and configuration.
I’ll give the example from the SD scenarios created from the billing in VF01. The creation is started when the billing document is saved.
The eDocument itself is created from inside the Function Module RV_INVOICE_DOCUMENT_ADD. Below you can see the SAP enhancement there that triggers the first checks related to the edocument:
The method INITIAL_CHECKS1 analyzes if the company code is configured for eDocument process for SD_INVOICE source documents (there are some different behaviours if the document is not relevant to accounting or not released to accounting).
After that then the system calls the method CREATE_EDOCUMENT from the class related to the SD documents CL_EDOC_SOURCE_SD. Up to this point it’s all generic code from the eDocument Framework and it’s used for basically all countries:
The CREATE_EDOCUMENT method in class CL_EDOC_SOURCE_SD starts the creation of the edocument data, checks if eDocument is active in the company code and it triggers the classes that transfer the data from the SD structures (vbrk, vbrp, pricing_elements, etc…) to the internal structures of the document (document_header, document_item, partner_data, etc…). Later on the method CREATE_DOCUMENT will be called in the class CL_EDOCUMENT.
If no error happens or not check fails the system calls later in the stack the method PREPARE_EDOCUMENTS from class CL_EDOC_SOURCE that will read the country and derive the country-specific classes that contain the details for the specific edocument type to be created.
After the country-specific class is found the edocument architecture will call the country specific logic to start checking details related to the country where the solution is being implemented.
Below you can see the country-specific class CL_EDOCUMENT_MX, calling the method IS_RELEVANT from the SD scenario, and it has a check that marks the process as relevant.
The class is generic for SD and FI cases, so there is a check on the source type and edoc type because there are different rules for FI_INVOICE that should be eInvoice and FI_INVOICE that should ePayment.
After the standard logic definition there is a very interesting BAdI EDOC_ADAPTOR that also has a method IS_RELEVANT.
This is a generic BadI from the eDocument Framework and it works with country specific implementations/filters, it means that you create one implementation for MX in this BAdI if you want to make adjustments specific for the MX scenario. For other countries you also create implementations in the same BAdI but with filters for each specific country.
This method IS_RELEVANT is used when you want to prevent the creation of an edocument for a certain specific scenario. For most of the cases the FI document type is the main driver of the eDocument creation, but in a certain scenario there might be additional restrictions. For example, all the Billing Types used by a company are assigned to FI document type RV, but depending on the Billing Type (for example ZF2B) you might not need an eDocument to be created for a certain scenario.
A bit after this point the system call the process manager instantiation and it calls the PROCESS_CREATE method from the respective country specific class CL_EDOCUMENT_MX .
The process manager structure classes/methods control the actions executed and each step to be run based on the configuration of the scenario. This can be checked in the SM34 view cluster EDOC_PROCMGR using the eDocument process ID, MXINVOICE in this case.
The country specific class also call the persistency of the eDocument data to the database tables. The generic class SAVE_TO_DB saves to table EDOCUMENT and there is a country specific method that saves data into the edomxinvoice. If you liked the technical content of the post please leave a comment or suggest if some other information you'd like to see was not included here.
For a scenario with manual submit then the next action starts from the eDocument cockpit itself, but this will be content for another blog post where I’ll focus in the mapping and sending to BTP.
Please leave a comment if you have any suggestion of topics to be covered in the next blog posts.
That’s all for now, Folks!
Renan Correa
If you liked the content you can follow my profile and get notified whenever new blog posts are created in the SAP community.
Besides the obvious parts of reading the notes, reading the help page, preparing the lists of the requirements and so on I wanted to create a document to help when things go wrong in the tests/configuration/developments of the solution.
I always recommend for all DRC consultants to bookmark the DRC topic page in the community https://community.sap.com/topics/document-reporting-compliance and to check the blog posts in the blog feed from time to time to check the news on this area.
I summarized some relevant parts (in my opinion) where I had to debug it in the past to find issues and configuration errors.
If you have suggestions or comments about areas you'd like to see a more detailed analysis please leave a comment.
eDocument Cockpit with customizations
One classic example of error, invoice saved in VF01 but no eDocument created. You configured the system but you don’t know whats going on in this case.
I separated some interesting debug points to analyze the code and the behaviour of the solution and find out the reason for errors.
How an eInvoice is born in SD?
The first thing to find out is how the eDocuments are created. They do not come out of thin air, it requires notes and configuration.
I’ll give the example from the SD scenarios created from the billing in VF01. The creation is started when the billing document is saved.
The eDocument itself is created from inside the Function Module RV_INVOICE_DOCUMENT_ADD. Below you can see the SAP enhancement there that triggers the first checks related to the edocument:
eDocument Checks in SD invoice
The method INITIAL_CHECKS1 analyzes if the company code is configured for eDocument process for SD_INVOICE source documents (there are some different behaviours if the document is not relevant to accounting or not released to accounting).
Main Logic of Initial Checks
After that then the system calls the method CREATE_EDOCUMENT from the class related to the SD documents CL_EDOC_SOURCE_SD. Up to this point it’s all generic code from the eDocument Framework and it’s used for basically all countries:
Class to create eDocument in SD code
Generic eDocument Classes
The CREATE_EDOCUMENT method in class CL_EDOC_SOURCE_SD starts the creation of the edocument data, checks if eDocument is active in the company code and it triggers the classes that transfer the data from the SD structures (vbrk, vbrp, pricing_elements, etc…) to the internal structures of the document (document_header, document_item, partner_data, etc…). Later on the method CREATE_DOCUMENT will be called in the class CL_EDOCUMENT.
create_edocument
If no error happens or not check fails the system calls later in the stack the method PREPARE_EDOCUMENTS from class CL_EDOC_SOURCE that will read the country and derive the country-specific classes that contain the details for the specific edocument type to be created.
prepare_edocuments
After the country-specific class is found the edocument architecture will call the country specific logic to start checking details related to the country where the solution is being implemented.
Below you can see the country-specific class CL_EDOCUMENT_MX, calling the method IS_RELEVANT from the SD scenario, and it has a check that marks the process as relevant.
The class is generic for SD and FI cases, so there is a check on the source type and edoc type because there are different rules for FI_INVOICE that should be eInvoice and FI_INVOICE that should ePayment.
IS_RELEVANT implementation for MX scenarios
After the standard logic definition there is a very interesting BAdI EDOC_ADAPTOR that also has a method IS_RELEVANT.
This is a generic BadI from the eDocument Framework and it works with country specific implementations/filters, it means that you create one implementation for MX in this BAdI if you want to make adjustments specific for the MX scenario. For other countries you also create implementations in the same BAdI but with filters for each specific country.
This method IS_RELEVANT is used when you want to prevent the creation of an edocument for a certain specific scenario. For most of the cases the FI document type is the main driver of the eDocument creation, but in a certain scenario there might be additional restrictions. For example, all the Billing Types used by a company are assigned to FI document type RV, but depending on the Billing Type (for example ZF2B) you might not need an eDocument to be created for a certain scenario.
Country Specific eDocument Content
A bit after this point the system call the process manager instantiation and it calls the PROCESS_CREATE method from the respective country specific class CL_EDOCUMENT_MX .
Start of eDocument Processing in MX
The process manager structure classes/methods control the actions executed and each step to be run based on the configuration of the scenario. This can be checked in the SM34 view cluster EDOC_PROCMGR using the eDocument process ID, MXINVOICE in this case.
Process Manager actions
The country specific class also call the persistency of the eDocument data to the database tables. The generic class SAVE_TO_DB saves to table EDOCUMENT and there is a country specific method that saves data into the edomxinvoice. If you liked the technical content of the post please leave a comment or suggest if some other information you'd like to see was not included here.
Persistency
For a scenario with manual submit then the next action starts from the eDocument cockpit itself, but this will be content for another blog post where I’ll focus in the mapping and sending to BTP.
Please leave a comment if you have any suggestion of topics to be covered in the next blog posts.
That’s all for now, Folks!
Renan Correa
If you liked the content you can follow my profile and get notified whenever new blog posts are created in the SAP community.
- SAP Managed Tags:
1 Comment
