English
EspañolComo analisar situações
Como analisar situações no processo de emissão/cancelamento/inutilização de documentos eletrônicos
As principais situações que impedem a autorização, o cancelamento ou a inutilização de um documento eletrônico estão voltadas as rejeições que a solicitação enviada para o órgão autorizador pode ter. Estas rejeições são baseadas em manuais de orientação, notas técnicas e legislações.
Este tópico tem como objetivo demonstrar um processo padrão de análise para as situações onde ocorrem rejeições em solicitações de autorização, cancelamento ou inutilização de um documento eletrônico enviado para um órgão autorizador.
Observação
Este tópico não tem como objetivo indicar verificações que podem ser efetuadas no caso de estarem ocorrendo problemas de impressão ou retorno de status do documento eletrônico ao ERP. Para isso, poderão ser consultados os tópicos específicos que tratam estas questões no Manual do Usuário.
- Informações sobre processos de impressão;
- Informações sobre problemas de retorno ao ERP.
Além disso, leva-se em consideração que a comunicação do eDocs com a SEFAZ/Prefeitura esteja ocorrendo normalmente, ou seja, há um retorno de rejeição da solicitação encaminhada. Caso a solicitação não esteja nem sendo enviada para a SEFAZ/Prefeitura (exemplo: a NF-e fica parada no DE com status de Recebida ERP ou Validada), é necessário avaliar o log para verificar eventuais falhas de comunicação com a SEFAZ/Prefeitura.
O primeiro ponto para início da análise é entender qual o documento eletrônico está gerando a rejeição e reunir o maior número de informações possíveis sobre este documento (consultando manuais de integração, manuais de orientação do contribuinte, notas técnicas, consulta em portais especializados, ...). Através destes recursos, os seguintes questionamentos devem ser respondidos:
- Qual é o documento eletrônico que está sendo emitido/cancelado/inutilizado? (NF-e, CT-e, MDF-e, NFC-e ou NFS-e);
- Qual é o órgão autorizador deste documento? (SEFAZ [de qual estado/Nacional], Prefeitura);
- Quais os manuais de orientação definem o leiaute a ser seguido e as validações que podem ser efetuadas? Onde encontra-los? (Manual de Orientação do Contribuinte, Manual de Integração, Nota Técnica);
- Apesar de ter havido rejeição, o documento teve a requisição de autorização/cancelamento/inutilização autorizada junto ao órgão autorizador? (A consulta deverá ser efetuada junto ao portal disponibilizado pelo órgão autorizador).
Outro pré-requisito para análise de problemas na autorização de solicitações encaminhadas é possuir o arquivo XML gerado pelo ERP ou pelo Gestão de Lojas e o arquivo XML que o eDocs enviou para a SEFAZ/Prefeitura. Na maioria das situações que envolvem leiautes nacionais (NF-e, CT-e, MDF-e e NFC-e), não há necessidade de possuir o arquivo XML enviado pelo eDocs para a SEFAZ, pois o eDocs mantém a mesma estrutura do arquivo XML gerado pelo ERP/Retaguarda. No entanto, no caso de emissão de NFS-e, é pré-requisito que se tenha o arquivo XML gerado pelo eDocs para a Prefeitura.
Importante
- Os arquivos XMLs da comunicação do eDocs com a Prefeitura podem ser obtidos através da rotina de logs de XML. Para mais informações, consulte a documentação sobre esta funcionalidade.
- Os arquivos XMLs da comunicação do eDocs com a SEFAZ podem ser obtidos utilizando-se o log do serviço do eDocs em modo DEBUG no momento em que a comunicação ocorrer.
Dica
Nos processos de análises indicados abaixo serão citadas como fonte de informações, os manuais padrões disponibilizados pelos órgãos autorizadores. No entanto, é importante utilizar uma busca na Internet para obter informações ou, até mesmo, encontrar outras empresas que já tenham se deparado com a mesma situação. Fóruns de discussão e blogs são muito úteis em reunir estas informações.
Em muitas ocasiões, ao localizar um manual ou outro documento que possa facilitar a análise da situação, é necessário ler os principais tópicos do documento, ao invés de apenas utilizar atalhos para pesquisa de palavras dentro do documento (CTRL + F, por exemplo). Isso porque, muitas vezes, os manuais poderão ter informações inseridas como imagens, onde a busca por palavras não trará resultados.
Análise para leiautes nacionais (NF-e, CT-e, MDF-e e NFC-e)
Na análise de documentos eletrônicos que seguem leiautes nacionais (NF-e, CT-e, MDF-e e NFC-e), toda a comunicação do eDocs com a SEFAZ é efetuada com base em web services e troca de arquivos XML.
Os leiautes são padronizados e devem ser seguidos por qualquer órgão autorizador (SEFAZ). Caso existam legislações específicas a serem atendidas em apenas um estado, por exemplo, o leiaute nacional padrão deve ser adaptado para esta legislação.
A documentação dos leiautes (Manuais e Notas Técnicas) pode ser encontrada nos portais disponibilizados pela própria SEFAZ. Seguem os links:
- NF-e e NFC-e: http://www.nfe.fazenda.gov.br/
- MDF-e: https://mdfe-portal.sefaz.rs.gov.br/
- CT-e: http://www.cte.fazenda.gov.br/
Para exemplificar o processo de análise de uma rejeição, iremos nos basear na seguinte rejeição ocorrida durante o processo de emissão de uma NF-e: 328 - CFOP de devolução de mercadoria para NF-e que não tem finalidade de devolução de mercadoria.
Observação
Caso não haja familiarização com os conceitos utilizados pela SEFAZ para definição dos manuais de orientação e notas técnicas, orienta-se a verificação do tópico Informações para interpretação de Manuais de Orientação do Contribuinte e Notas Técnicas da SEFAZ.
Neste caso, precisamos procurar esta rejeição no Manual de Orientação do Contribuinte (a procura poderá ser feita por parte do texto da rejeição ou pelo código da rejeição). Ao procurar esta rejeição, encontramos a informação conforme imagem abaixo:
Importante
O Manual de Orientação do Contribuinte (MOC) nem sempre têm todas as rejeições possíveis de uma NF-e. Isso porque o MOC recebe uma nova versão somente quando houverem várias Notas Técnicas (NT) já publicadas anteriormente. Neste caso, em muitas ocasiões, a rejeição é encontrada somente dentro de uma Nota Técnica.
Neste caso, a rejeição tem como regra de validação que, se a NF-e não tem a tag <finNFe> definida como 2 ou 4, não serão aceitos CFOP de devolução de mercadoria. A rejeição ainda indica de que deve-se verificar a lista de CFOPs de devolução presentes no anexo XIII.01 do MOC.
Desta forma, para entendermos melhor o que é a tag <finNFe> e quais as possibilidades de preenchimento dela, vamos procurar por esta tag no MOC. Encontramos as seguintes informações, conforme imagem abaixo:
Agora que conseguimos identificar a regra utilizada para ser gerada a rejeição e como a tag <finNFe> é preenchida, vamos verificar o arquivo XML gerado para esta NF-e, nos atentando para o preenchimento da tag <finNFe> e para a CFOP utilizada.
Abaixo segue imagem da visualização do arquivo XML da NF-e que teve a rejeição 328 - CFOP de devolução de mercadoria para NF-e que não tem finalidade de devolução de mercadoria, em que é possível identificar que a tag <finNFe> está preenchida como 1-NF-e normal.
Abaixo segue uma imagem da visualização do arquivo XML da mesma NF-e, em que é possível identificar que a tag <CFOP> do único item de produto presente na NF-e está preenchida como 5921.
Neste caso, conseguimos identificar que a CFOP utilizada é a 5921 (Devolução de vasilhame ou sacaria), sendo que a finalidade da NF-e foi definida como NF-e Normal (ou seja, não é uma NF-e de devolução). Desta forma, a SEFAZ aplica a validação 328 e rejeita a NF-e. Esta Rejeição, inclusive, foi inserida no leiaute da NF-e através da versão 1.20 da NT 2013.005.
Importante
As validações aplicadas pela SEFAZ podem ser alteradas conforme definições dos órgãos responsáveis por defini-las. Desta forma, uma validação que é aplicada em uma NF-e em determinada data pode não ser aplicada na mesma NF-e em outra data. Por este motivo, é sempre importante utilizar os MOCs e NTs atualizadas e, em caso de alguma dúvida sobre a validação, entrar em contato com a SEFAZ para onde o documento está sendo enviado.
Informações para interpretação de Manuais de Orientação do Contribuinte e Notas Técnicas da SEFAZ
Os manuais de orientação e notas técnicas disponibilizados pela SEFAZ seguem um padrão único para indicar as informações que devem ser enviadas em cada campo do arquivo XML. No próprio MOC (Manual de Orientação do Contribuinte) existem definições para os campos que são demonstrados no documento. Abaixo transcrevemos as principais informações que são úteis para interpretação dos manuais, em relação aos campos que podem estar presentes no XML.
Importante
Para que haja assimilação de todo o conteúdo que esclarece como o MOC, indica-se a leitura das informações presentes sobre os campos definidos no manual. As informações presentes abaixo são informações básicas para auxiliar na interpretação do manual e são focadas no MOC da NF-e.
Os manuais e notas técnicas podem mostrar diferenças na forma em que as informações são dispostas, de acordo com o tipo de documento eletrônico. Desta forma, o MOC de NF-e poderá ter algumas diferenças do MOC do CT-e, por exemplo.
- ID: identificação do campo no MOC;
- Campo: nome do campo – se refere à tag do arquivo XML;
- Descrição: uma breve descrição sobre o que representa este campo;
- Pai: indica qual é o elemento pai do campo que está sendo verificado;
- Tipo: indica o tipo do campo, levando em conta que: C indica que é do tipo caractere, N indica que é do tipo número e D indica que é do tipo data/hora;
- Ocorrência: indica quantas vezes o campo pode aparecer no arquivo XML (indica-se verificação da informação detalhada sobre ocorrências no MOC). Exemplos:
1-1: é obrigatório e pode ter até uma ocorrência;
0-1: é opcional e pode ter até uma ocorrência;
0-3: é opcional e pode ter até três ocorrências;
0-N: é opcional e pode ter várias ocorrências (sem limite definido);
1-N: é obrigatório e pode ter várias ocorrências (sem limite definido).
- Tam.: indica o tamanho da informação gerada no campo. Exemplos:
1, 2, 44, 15: tamanho pré-definido do campo. Tamanho não possui variação;
1-3, 3-15: tamanho pré-definido do campo, mas pode variar.
- Observação: informações adicionais sobre o campo (geralmente informação de como deve ser preenchido o campo).
Para demonstrar uma análise efetuada a partir de um campo do leiaute padrão, utilizaremos como exemplo a tag <modFrete> do leiute da NF-e. Abaixo segue imagem da forma como esta tag está definida no MOC:
Neste caso, podemos interpretar que a tag <modFrete>:
- Seu ID no manual é X02;
- Indica a modalidade de frete definida na NF-e (coluna Descrição);
- É filha da tag <transp> (coluna Pai);
- É do tipo número (não aceita caracteres) (coluna Tipo);
- É obrigatória, podendo ter no máximo uma tag com este nome no XML (coluna Ocorrência);
- Deverá ter em seu conteúdo, obrigatoriamente, um algarismo (coluna Tam.);
- Deverá ser preenchida com 0, 1, 2 ou 9, de acordo com a modalidade do frete (coluna Observação).
Importante
As informações contidas neste tópico tiveram como fonte o Manual de Orientação do Contribuinte da NF-e (v6.0). Este manual não é mantido pela Senior, mas sim pela SEFAZ. Desta forma, eventuais modificações no manual são de inteira responsabilidade da SEFAZ. Se eventuais modificações forem efetuadas, deve-se considerar as informações presentes no manual atualizado. O manual pode ser acessado no endereço http://www.nfe.fazenda.gov.br.
Além das informações referentes aos campos que podem estar presentes no arquivo XML do documento, o Manual de Orientação do Contribuinte e as Notas Técnicas têm ainda informações sobre as validações que são aplicadas nas informações que são enviadas no XML. Abaixo transcrevemos as principais informações que são úteis para interpretação dos manuais, em relação as informações sobre as validações aplicadas sobre o arquivo enviado:
- Campo-Seq: identificação do campo do MOC ao qual a validação está vinculada, juntamente com a sequência da validação relativa a este campo;
- Modelo: modelo ao qual se aplica a validação (55: NF-e / 65: NFC-e). Uma validação poderá ser aplicada para mais modelos;
- Regra de validação: é informada a regra de validação que é aplicada para que ocorra uma determinada rejeição, por exemplo;
- Aplic.: indica se a validação é Obrigatória ou Facultativa. Se ela for obrigatória, todas as SEFAZ, independentemente do estado, deverão aplicar esta validação. Se ela for facultativa, a SEFAZ estadual decidirá se irá ou não ativar a validação em seu ambiente receptor dos documentos;
- Msg.: indica o código da mensagem de validação. Este código é retornado pelo web service da SEFAZ quando ocorre uma rejeição, por exemplo, juntamente com a descrição da rejeição;
- Efeito: indica qual o efeito da validação no documento eletrônico enviado para autorização. Os efeitos poderão ser Rej. (Rejeição) ou Den. (Denegação);
- Descrição Erro: indica a descrição do erro que será retornado pela SEFAZ como motivo pelo qual a solicitação de autorização não foi atendida.
Abaixo segue exemplo de como é exposta uma validação no MOC da NF-e.
Análise para leiautes municipais (NFS-e)
Na análise de documentos eletrônicos que seguem leiautes municipais (NFS-e), a comunicação do eDocs com o sistema da Prefeitura pode ser efetuada de algumas formas: com base em web services e troca de arquivos XML, com base em requisições HTTP ou com base em processos que emulam o upload de um arquivo TXT no site do sistema da Prefeitura.
Os leiautes utilizados pelas prefeituras podem variar de acordo com o fornecedor do sistema utilizado pela prefeitura (poderá haver, também, variação de leiaute entre prefeituras que utilizam um mesmo fornecedor). Legislações municipais podem influenciar nas informações que podem ser enviadas em cada campo da NFS-e.
A documentação dos leiautes geralmente é encontrada no site da Prefeitura para onde a NFS-e está sendo enviada ou no site do fornecedor do sistema da Prefeitura. Algumas prefeituras, no entanto, disponibilizam a documentação apenas mediante solicitação a ser realizada, geralmente, através de e-mail. Nestas situações, é sempre importante manter contato com a Prefeitura para conseguir a documentação atualizada para integração.
Observação
O eDocs converte o arquivo XML gerado pelo ERP no padrão ABRASF 1.0 (e que contém o grupo de informações InfSenior, eventualmente) no padrão que a Prefeitura para onde a NFS-e/RPS é enviada.
Para exemplificar o processo de análise de uma rejeição, iremos nos basear em uma rejeição gerada pela Prefeitura de São Paulo-SP. A rejeição é: Valor Total de Dedução não confere com o enviado.
A prefeitura de São Paulo-SP disponibiliza um web service para integração de NFS-e. Desta forma, o primeiro passo é verificar esta rejeição no manual de integração via web service, para identificar se existe alguma informação adicional sobre a rejeição.
Dica
Como já informado, os manuais são encontrados no site da própria Prefeitura para onde a NFS-e está sendo enviada, no entanto, pode ser utilizado alguma ferramenta de busca na Internet para localizar o manual. Exemplo de termos a serem utilizados em uma busca: manual integração NFS-e São Paulo.
Atualmente os manuais de integração da Prefeitura de São Paulo-SP estão disponíveis em http://nfpaulistana.prefeitura.sp.gov.br/Nfe/empresas/informacoes-gerais/manuais. Importante lembrar de que este link pode ser alterado pela Prefeitura e a Senior não tem responsabilidade pelas informações presentes nestes manuais ou na disponibilização dos mesmos.
No manual de integração, encontramos a rejeição registrada, conforme imagem abaixo:
A mensagem de rejeição não traz nenhuma informação detalhada, no entanto, nos traz a informação de que a rejeição ocorre porque o valor total de dedução presente no arquivo não confere com a soma do valor total de deduções presentes no arquivo.
Partimos agora para avaliar o arquivo XML gerado pelo ERP, na busca de identificar se existe alguma informação que o ERP deixou de gerar no arquivo XML.
Buscando informações sobre deduções no arquivo XML gerado pelo ERP, encontramos a tag <ValorDeducoes> que é filha da tag <Valores> que por sua vez é filha da tag <Servico>.
Como o ERP gera o arquivo XML no padrão ABRASF 1.0, vamos identificar informações sobre deduções que podem ser enviadas neste padrão de arquivo. Para isso, vamos consultar o manual conceitual do padrão ABRASF 1.0, disponível em http://www.abrasf.org.br.
Encontramos a seguinte informação sobre no manual conceitual sobre o envio de valor de deduções no arquivo XML (a informação faz referência especificamente a tag <ValorDeducoes> presente no arquivo XML do RPS):
É possível identificar que no manual conceitual do padrão ABRASF 1.0 não existe nenhuma outra tag onde deveria ser enviado um totalizador do valor de deduções presentes no arquivo, ou seja, cada RPS pode ter no máximo uma tag <ValorDeducoes>, sendo que a tag não é obrigatória ser gerada no arquivo (indicativo 0-1).
Como no padrão ABRASF 1.0 não foram encontradas informações que deveriam ter sido geradas pelo ERP e não foram, o próximo passo é identificar se na estrutura de XML utilizada pela Prefeitura de São Paulo-SP há alguma informação que o eDocs deveria estar enviando e não está gerando no XML.
Para isso, vamos identificar no manual de integração da Prefeitura se há alguma informação relativa a Deduções. Efetuando análise do documento, encontramos a seguinte informação, referente ao padrão de como um arquivo XML deverá ser enviado ao web service utilizando o método PedidoEnvioLoteRPS.
É possível identificar que a tag <Cabecalho> do arquivo XML de envio do RPS para a Prefeitura existem duas tags: <ValorTotalServico> e <ValorTotalDeducoes>. A tag <ValorTotalDeducoes> possui a seguinte descrição: valor total das deduções dos RPS/Cupom contidos no lote. Neste caso, encontramos a tag que deve conter a totalização de todas as deduções dos RPS contidos no lote, o que faz referência a rejeição gerada pela Prefeitura, que é Valor Total de Dedução não confere com o enviado.
Dica
Para informações consulte a documentação da rotina de logs XML.
Analisando o arquivo XML, identificamos que a tag <ValorDeducoes> está presente no arquivo XML, com o mesmo valor presente no arquivo XML do ERP. Neste caso, o eDocs está enviando a informação correta para esta tag, conforme imagem abaixo:
No entanto, conforme identificamos anteriormente, o leiaute da Prefeitura indica que deve-se enviar a tag <ValorTotalDeducoes> junto ao cabeçalho do XML enviado ao método PedidoEnvioLoteRPS do web service. Vamos, então, analisar o cabeçalho do XML:
Verificando as tags presentes no cabeçalho do arquivo XML, é possível identificar que o eDocs não gerou a tag <ValorTotalDeducoes> abaixo da tag <ValorTotalServicos>, conforme determina o leiaute da Prefeitura. Com isso, a Prefeitura entende que o valor de deduções é zero, fazendo com que o valor de deduções presente no RPS (que foi de R$ 97.930,77) seja diferente do somatório das deduções (que é, efetivamente o valor presente na tag <ValorTotalDeducoes>).
Tendo em vista de que foi encontrada a inconsistência no eDocs (falta enviar uma tag no arquivo XML), é necessário, então, verificar se a situação já não foi corrigida em uma versão atual do sistema. Para isso, é necessário verificar o Notas da Versão do sistema.
Verificando o Notas da Versão, é possível identificar a seguinte correção liberada na versão 5.8.8.36:
Erro ao enviar valores de deduções
Problema: ao emitir uma NFS-e para a prefeitura de São Paulo com valores de deduções, era retornada a seguinte mensagem: Valor total de dedução não confere com o enviado.
Correção efetuada: ajustamos o sistema, para que o envio dos valores de deduções para NFS-e do fornecedor São Paulo ocorra corretamente.
- Local: NFS-e > Emissão
Desta forma, é possível concluir que a Rejeição gerada e analisada como exemplo nesta ocasião ocorre devido a uma falha do sistema que já foi corrigida e liberada ao mercado. Neste caso, é necessário atualizar o sistema para a versão atual e gerar o arquivo XML no ERP novamente.
Importante
É importante observar de que nem toda rejeição gerada por uma Prefeitura ocorre devido a uma inconsistência no sistema. As rejeições podem ocorrer, muitas vezes, pois as informações definidas pelo usuário no ERP estão em desacordo com o exigido pela Prefeitura. Por este motivo, é muito importante efetuar a análise das informações presentes no arquivo XML de acordo com os manuais e informações disponibilizadas pela Prefeitura e encontradas na Internet.
Caso, em alguma situação específica, não seja possível identificar o motivo real de uma rejeição gerada pela Prefeitura, é necessário que o emitente da NFS-e (que é o contribuinte) entre em contato com a Prefeitura e solicite análise do arquivo XML/TXT enviado para que a Prefeitura indique o real motivo da rejeição. Nestes casos é importante lembrar de que o arquivo que deverá ser enviado para a Prefeitura é o arquivo gerado pelo DE e não o XML gerado pelo ERP no padrão ABRASF 1.0.
English
Español
