Publicado por:Debugando o DRC – Mexico CFDI
Depois de vários projetos de DRC (e muitas discussões com colegas que estão começando na área) resolvi criar um conteúdo com um compilado de explicações sobre a criação do eDocument e com umas dicas pra ajudar a analisar o que está ocorrendo no sistema bem naquela hora que o “sapato aperta” e não tem opção pra onde correr. Se curtirem o conteúdo deixem um comentário aí ou sugiram algum próximo assunto para fazer um blog post. Se não curtirem, de boas, o mundo é livre ;D
Como nasce um eDocument numa fatura de SD?
Começando do começo vamos ver como o eDocument é criado no SAP. Tudo começou em 1972 quando 5 ex-funcionários da IBM decidiram criar uma empresa de sistemas inte…ops… não precisa ser tão do começo assim. O exemplo a ser analisado é de um cenário de SD criado por uma fatura na VF01. A criação do eDocument é disparada no momento que a fatura é salva.
O eDocument é criado na função RV_INVOICE_DOCUMENT_ADD de SD. Na imagem aqui de baixo você pode ver o ENHANCEMENT (standard da SAP) que chama os primeiros checks de eDocument no módulo de SD.
O método INITIAL_CHECKS1 verifica se a empresa está configurada para gerar eDocuments no caso de um documento fonte SD_INVOICE (o comportamento é diferente se a fatura de SD tem contalização, se não tem contabilização ou se é um documento relacionado a FICA).
Classes genéricas de eDocument
Depois desse ponto é chamado o método CREATE_EDOCUMENT da classe CL_EDOC_SOURCE_SD que é usada para o documento fonte SD_INVOICE. Até esse ponto é basicamente código genérico válido para qualquer cenário de SD e isso é usado para praticamente qualquer país que usa eDocuments a partir da fatura:
O método CREATE_EDOCUMENT da classe CL_EDOC_SOURCE_SD inicia a criação dos dados do eDocument, esse ponto verifica se eDocument está ativo na empresa e dispara as classes/métodos que transfere os dados das estruturas de SD (vbrk, vbrp, pricing_elements, etc…) para as estruturas internas do framework de eDocument (document_header, document_item, partner_data, etc…). Posteriormente o método CREATE_DOCUMENT vai ser chamado na classe CL_EDOCUMENT.
Se nenhum erro ocorrer logo adiante o método PREPARE_EDOCUMENTS vai ser chamado e vai identificar o país dessa fatura e a partir dessa informação serão buscadas as classes específicas do país that contain the details for the specific edocument type to be created.
Após encontrar qual a respectiva classe do país a arquiteura do o eDocument irá disparar o uso dos métodos dessa classe com a lógica específica do cenário daquele país.
Abaixo tenho uma screenshot da classe CL_EDOCUMENT_MX chamando o método IS_RELEVANT a partir do cenário de SD, existe um código na linha 17 que marca o processo como relevante por padrão e algumas verificações posteriores que podem desabilitar a relevância. Esse é um exemplo interessante, pois essa classe é a mesma chamada para o caso de eDocument no MX vindo tanto de SD como de FI , então ela possui verificações tanto no source_type (FI_INVOICE ou SD_INVOICE) como no edoc type (MX_PAYMENT) porque tem regras diferentes para FI_INVOICE que deve ser eInvoice e FI_INVOICE que deve ser ePayment. Além disso, no cenário do MX não é gerado eDocument para cenários de cancelamento (billing criado pela VF11) e nem para faturas já canceladas.
Após a logica de relevância standard da SAP para o México tem a chamada da da BAdI EDOC_ADAPTOR que também tem um método IS_RELEVANT (e aqui gambiarras podem ser feitas).
Essa BadI do eDocument Framework é genérica para todos os países e trabalha com múltiplas implementações usando o país como filtro, por exemplo se você cria uma implementação para MX nessa BAdI só no cenário em que o país do eDocument for MX isso vai ser chamado. Para outros países que você usar eDocument de SD você pode ter outras implementações com outras regras, essa funcionalidade é bem interessante e faz sentido.
O método IS_RELEVANT é usado quando você deseja impedir a criação de um documento eletrônico para um determinado cenário específico. Na maioria dos casos, o tipo de documento FI é o principal motivador da criação do eDocument, mas em um determinado cenário pode haver restrições adicionais. Por exemplo, todos os Tipos de Faturamento usados por uma empresa são atribuídos ao tipo de documento FI RV, mas dependendo do Tipo de Faturamento (por exemplo ZF2B) você pode não precisar que um eDocument seja criado para um determinado cenário.
Código Específico do País ( Classes CL_EDOCUMENT_**)
Um pouco depois da verificação de relevância o sistema começa a executar chamadas para as classes que buscam os dados do process manager instantiation and it calls the PROCESS_CREATE method from the respective country specific class CL_EDOCUMENT_MX .
A estrutura de classes métodos do “Process Framework” controla as ações executadas e cada passo a ser rodado com base na configuração do cenário nas tabelas da view cluster “Process Manager”. Isso pode ser consultado na SM34 com view cluster EDOC_PROCMGR utilizando eDocument process ID, que é MXINVOICE nesse caso.
A classe específica do país (MX) também irá chamar a persistências dos dados nas tabelas. O método genérico (da classe do framework global) SAVE_TO_DB persiste dados na tabela EDOCUMENT e o método específico de país (da classe do país) persiste na tabela EDOMXINVOICE.
O próximo passo na luta de implementar eDocuments é a parte mais importante na minha humilde opinião, o MAPEAMENTO dos dados! Esse é um blog post que vai levar um tempinho para preparar porque é o coração do paranauê todo, dominado o conceito do mapeamento é possível implementar qualquer cenário em qualquer país (com uma boa dose de ABAP).
Valeu Gurizada!
Renan Correa
Quer ficar ligado nas novidades de localização? Entra no grupo da S4CN no Telegram e segue a gente no canal do Youtube
Mais infos sobre a localização Brasil no ERP, direto da sap, vocês podem conferir no SAP community na tag de S/4HANA logistics for Brazil
Outros posts sobre Localização você pode conferir filtrando pela categoria NFE/CTE ou Localização BR Geral.
Outros posts sobre TDF você pode conferir filtrando pela categoria TDF/ACR.
