Olá,

Para você cliente ou parceiro que deseja ter detalhes de implementação do produto SAP Document and Reporting Compliance, inbound invoicing option for Brazil (nota fiscal eletrônica), preparamos um guia resumido e dicas de implementação, principalmente se você for um cliente migrando da solução SAP Electronic Invoicing for Brazil (SAP Nota Fiscal Eletrônica), mais conhecido como SAP GRC NFE.

SAP Notes

A primeira etapa é implementar todas as SAP Notes de pré-requisito da solução. Todas as SAP Notes necessárias estão listadas na SAP Note 2776753, como apresentado na imagem:

Etapa Inicial

Você precisa gerar as credenciais para fazer a integração do seu sistema backend (SAP ECC ou SAP S/4HANA) com o serviço na nuvem. Siga o passo-a-passo do SAP Help Portal descrito aqui assim como está apresentado na imagem abaixo. Lembre-se que a licença já deve ter sido adquirida para realizar esta etapa.

Agora vamos apresentar algumas dicas para auxiliar você neste processo:

Dica 1: Somente quem tem acesso a global account poderá gerar as credenciais, você deve verificar  na empresa quem é o responsável por administrar a global account. Para dar acesso a global account a outros usuários, acesse aqui.

Dica 2: Se a pessoa responsável por administrar a global account não está mais na empresa, você pode abrir um chamado no componente BC-NEO-CIS solicitando um novo acesso. Este é um componente do core responsável pelo provisionamento de serviços em nuvem do SAP BTP, dependendo da análise, um novo acesso será concedido.

Dica 3: Dependendo de como foi feito o contrato de licenciamento, uma segunda global account pode ter sido gerada. Caso isso tenha sido um equívoco, procure a área comercial da SAP para ajustar o contrato.

Integração

Nesta etapa, o sistema backend precisa se comunicar com a nuvem. Verifique a configuração necessária descritas neste link aqui e conforme imagem a seguir:

Para conferir se o backend está se comunicando com a nuvem, verifique o último passo descrito aqui.

Configuração/Customizing

Você precisa efetuar as configurações descritas no SAP Help Portal conforme a imagem abaixo:

Para detalhes da customização do SPRO, confira este link. Realize todos as configurações, inclusive das views do standard do eDocument Cockpit.

eDocument Framework

A solução SAP Document and Reporting Compliance, inbound invoicing option for Brazil (nota fiscal eletrônica) faz uso do monitor eDocument Cockpit. Este é um monitor global já utilizado em vários países. O monitor foi entregue como um Framework para facilitar a extensibilidade em caso de criação de novos processos ou adaptar processos existentes.

No caso de recebimento de documentos NF-e, dependendo dos processos da empresa, pode haver a necessidade de estender determinados processos via framework. Nestes casos, é imprescindível o conhecimento do pelo time de implementação, seja um parceiro ou equipe interna, principalmente do consultor ABAP.

No caso de migração do SAP Electronic Invoicing for Brazil (SAP Nota Fiscal Eletrônica), os processos FLEX devem ser substituídos por novos processos no Framework.  Para automação de documentos CT-e, foram também entregues as BAdIs FLEX, mas a automação de CT-e também pode ser feita via extensão pelo Framework.

O Framework é mantido pelo time global do SAP Document and Reporting Compliance, a documentação oficial pode ser verificada neste link conforme imagem abaixo.

Lembrando que o uso do Framework para tipos de documentos não suportados pelo SAP Document and Reporting Compliance, inbound invoicing option for Brazil (nota fiscal eletrônica) exige licença adicional.

Manifestação do Destinatário

Você pode ativar a Manifestação do Destinatário através da view EDOC_BR_MNG_DISTDFE. Mas antes de ativar é importante  entender o funcionamento do Web Service da Manifestação, através da leitura da nota técnica NF-e 2014.002.

Se for o caso de uma nova implementação, onde a empresa nunca utilizou o Web Service da Manifestação, basta informar o NSU como zero. A partir deste momento, o sistema buscará todos os documentos disponíveis na SEFAZ para o CNPJ do destinatário solicitado.

Se for uma migração, é importante que a aplicação anterior esteja desativada. Veja qual foi o último NSU processado por ela e depois informe na view. Assim, o sistema  solicitará à SEFAZ arquivos XML a partir do NSU mencionado. Consultar um NSU fora da sequência, ou quando duas aplicações estão  enviando solicitações para o mesmo CNPJ, pode causar a rejeição de Uso Indevido.

A informação do NSU deve ser informada conforme imagem abaixo para o CNPJ desejado:

A partir deste momento, o cloud  se comunicará com o Web Service do governo para realizar o download dos arquivos XML. Lembrando que para efetivamente obter o download do XML, existe um processo definido pela SEFAZ em que primeiro deve ser solicitado o resumo das notas que foram emitidas contra o CNPJ consultado, em seguida emitir o evento da ciência da operação para cada nota, e então finalmente solicitar o download de cada XML.

Você poderá verificar o status conforme imagem abaixo:

A coluna “Updated NSU” indica em qual NSU o cloud está chamando o governo naquele momento.

A coluna “Max NSU” indica qual é o NSU máximo retornado pelo governo.

Se a coluna “Updated NSU” estiver diferente do “Max NSU” significa que o cloud ainda está chamando o Web Service para obter novos arquivos XML. Se as colunas estiverem iguais, significa que não há mais documentos a serem baixados do governo.

A coluna “Last SEFAZ Search” indica qual foi a última vez que o cloud se comunicou com o governo. A ideia é que o usuário esteja ciente sobre quando foi realizada a última chamada. Para evitar a rejeição de Uso Indevido, o cloud tem a seguinte regra: se houver documentos a serem retornados, o cloud irá realizar a próxima chamada em 5 minutos; se a SEFAZ retornar que não há mais documentos, o cloud realizará a próxima chamada em 1 hora.

A coluna “Total Docs” informa quantos documentos já foram baixados do governo e que estão disponíveis na nuvem. Lembrando que toda comunicação inicial será entre a nuvem e o Web Service da SEFAZ. Os arquivos XML serão sempre retornados para a nuvem (e não para o sistema backend). A empresa pode solicitar o download destes arquivos XML para o backend executando o job EDOC_BR_DISTDFE_RETRIEVE. Este job comunica com a nuvem e carrega os arquivos XML no monitor eDocument Cockpit, onde a coluna Business Model será indicada como “B2G”. Reforçando, este job não chamará o Web Service da SEFAZ, e sim a nuvem.

Se ao rodar o job houver configurações faltantes, o sistema poderá não conseguir carregar os arquivos XML no monitor eDocument Cockpit de forma automática. Estes arquivos XML serão carregados em um monitor separado, que pode ser acessado através da transação EDOC_BR_PENDING_DOCUMENT. O usuário deverá analisar os arquivos XML retornados nesta transação, resolver os erros de configuração e então transferir ao monitor eDocument Cockpit, ou deletar os arquivos XML caso já não sejam relevantes.

No caso de Eventos, também é possível receber todos os eventos retornados pelo governo, inclusive os eventos emitidos pelo Fisco. Para isso é necessário configurar quais são os eventos desejados nas views EDOBREVTDESCV e EDOC_BR_MNG_NFE_EVT.

Estas orientações também se aplicam ao download de CT-e eventos.

Simulação da Invoice

É importante entender o funcionamento da simulação da Invoice para compreender como o sistema efetua a validação dos preços e impostos.

O sistema não valida exatamente o valor do imposto do XML contra o valor do imposto calculado no pedido de compra, pois sabemos que podem ocorrer diferenças de centavos (ou reais dependendo da empresa), por conta disto muitos clientes trabalham com a tolerância da MIRO. Logo, se houver tolerância configurada, o valor do imposto será outro então não podemos comparar exatamente os mesmos valores. Por exemplo: meu pedido tem 100,00 reais de preço líquido e eu permito uma tolerância de 10% para mais ou para menos. Se um XML tiver um preço líquido de 110,00 reais, o sistema vai aceitar e fazer a simulação da fatura considerando este preço. Os impostos também serão recalculados considerando este novo preço de 110,00 reais.

A tolerância da MIRO é uma funcionalidade standard do MM (Material Management) configurada através da view V_169G.

Se a tolerância não estiver configurada, o sistema entende que não há tolerância e não fará nenhuma verificação, assim o sistema informará que a NF-e sempre estará correta. Portanto, sempre configure a tolerância para que o sistema valide o preço e, consequentemente os impostos.

A mensagem da tolerância pode ser configurada como Warning ou Error. O recomendado é que a mensagem de tolerância esteja configurada como Error para que o sistema identifique e retorne o erro no momento da Simulação da Invoice. Se esta etapa estiver configurada para ser executada de forma automática e a mensagem da tolerância estiver configurada como Warning por exemplo, o sistema não  indicará que há um erro e  prosseguirá com o processamento da NF-e.

Dica 1: as condições iniciadas com X* devem ser criadas e adicionadas a pricing, verificar SAP note 1817495.

Dica 2: para saber qual preço líquido (condição BASB) e quais alíquotas e bases estão sendo consideradas para simulação, verifique a aba “Tax Condition” na simulação da Invoice.

Debug

Caso seja necessário realizar um debug, é possível colocar um breakpoint dentro do Process Manager. Selecionando o processo e o step você conseguirá visualizar qual classe-método será chamada.

Transação SM34 -> EDOC_PROCMGR (ou transação EDOP dependendo da versão do sistema backend)

Selecione o processo desejado.  Na imagem abaixo por exemplo, foi selecionado o processo de Compra Normal (BRNORMPRCH)

Após selecionar o processo, selecione “Process Step” no primeiro item da lista no menu da esquerda e você visualizará todos os steps desse processo.

Na imagem abaixo por exemplo, foi selecionado o step de Simulação, nas colunas Class/Method está a classe a ser chamada:

Migração do  SAP Electronic Invoicing for Brazil (SAP Nota Fiscal Eletrônica)

No SAP Help Portal, você pode acessar esta página para conferir a descrição de customizings/BAdIs do SAP Electronic Invoicing for Brazil (SAP Nota Fiscal Eletrônica) e  seus respectivos customizings/BAdI para o  SAP Document and Reporting Compliance, inbound invoicing option for Brazil.

Abaixo as principais views e BAdIs do SAP Electronic Invoicing for Brazil (SAP Nota Fiscal Eletrônica) e as respectivas view/BAdI para o inbound invoice option:

Dica 1: Através do SAP NetWeaver Process Integration (PI), era possível extrair arquivos XML enviados pelo fornecedor diretamente de uma caixa de e-mail. Caso seja uma necessidade no inbound invoice option, é possível extrair estes arquivos XML através de desenvolvimento, utilizando a transação standard SOST do SAP ERP.

Dica 2: É recomendado que os arquivos XML que hoje são armazenados no  SAP Electronic Invoicing for Brazil sejam migrados para um repositório externo. É possível fazer o upload de documentos antigos no monitor eDocument Cockpit, porém cada documento será considerado um documento processado pela métrica de licenciamento, o que não é recomendável considerando o alto custo envolvido por conta do volume extremo.

Dica 3: as BAdIs J_1BNFE_IN e J_1BNF_MSEG_DATA do sistema backend que foram criadas inicialmente para o SAP Electronic Invoicing for Brazil, também podem ser utilizadas no SAP Document and Reporting Compliance, inbound invoicing option for Brazil.