Debugging DRC eInvoice Creation – Mexico CFDI

Debugging DRC eInvoice Creation – Mexico CFDI

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.

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:

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:

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.

If no error happens or not check fails the system calls later in the stack the method PREPARE_EDOCUMENTS 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.

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 .

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.

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.

That’s all for now, Folks!

Renan Correa

Wanna learn more about Brazil, Latam and DRC in the SAP world? Subscribe to our Youtube channel!

You can also check our content by filtering TDF/ACR/DRC categories in our blog.