Criação de Evento de Conciliação Financeira, além de inclusão e alteração de outros campos e regras de validação
Prazos:
Ambiente de homologação: 05/02/2024
Ambiente de produção: 01/04/24
1.Resumo
Esta nota técnica tem o objetivo de prover aos atores envolvidos nos processos da NF-e/NFC-e a possibilidade de anotar no documento fiscal eletrônico as transações financeiras relacionadas, facilitando a vinculação entre documentos fiscais e recursos financeiros recebidos.
Busca-se encontrar uma solução para pagamentos que ocorrem distantes da data do fato gerador e da emissão do documento fiscal. Portanto, para que seja possível às empresas informarem que o recebimento de recurso está relacionado a determinado documento fiscal, está sendo criado o Evento de Conciliação Financeira – ECONF. Os Ajustes SINIEF nº 3/2023 e 10/2023 prevêem este evento.
A utilização do Evento de Conciliação Financeira – ECONF é facultativa e tem o objetivo de auxiliar as empresas que buscam demonstrar a existência de conformidade fiscal entre as informações financeiras e de meios de pagamentos e os documentos fiscais emitidos.
Nessa NT, foram criados novos campos no grupo YA. Informações de Pagamento e nos Grupos Tributação do ICMS que possuem ICMS desonerado.
Também foram alterados campos dos grupos I01. Produtos e Serviços / Declaração de Importação e Z. Informações Adicionais da NF-e
2. Visão Geral
2.1. Webservice de Evento
A Sefaz autorizadora disponibilizará um WebService de eventos que será utilizado para autorização do ECONF. Os eventos especificados nesta NT estarão disponíveis para os modelos 55 e 65.
2.2. Alteração de Campos
2.2.1. Inclusão dos campos
Novos campos foram adicionados ao Grupo YA. Informações de Pagamento”:
• Os campos CNPJPag e UFPag são de preenchimento facultativo pelo emitente que deseja informar o CNPJ e UF do estabelecimento onde o pagamento foi processado/transacionado/recebido nos casos em que a emissão do documento fiscal ocorreu em estabelecimento distinto.
• Os campos CNPJReceb e idTermPag são destinados a informar o CNPJ do beneficiário do pagamento e o Identificador do terminal de pagamento para fins de integração do pagamento com a emissão do documento fiscal eletrônico.
Nos “Grupos Tributação do ICMS” que possuem ICMS Desonerado, foi criado o campo “indDeduzDeson” para indicar se o valor do ICMS desonerado (vICMSDeson) deduz do valor do item (vProd).
2.2.2. Alteração dos Campos
No “Grupo I01. Produtos e Serviços / Declaração de Importação”, o campo atual “CNPJ” passa a ser “CNPJ/CPF”, permitindo também que pessoa física seja adquirente ou encomendante.
No “Grupo Z. Informações Adicionais da NF-e”, foram adiconadas novas opções para identificar procedimentos, benefícios e regimes concedidos no âmbito do CONFAZ.
2.3. Alterações de Regras de Validação
2.3.1. Inclusão das regras YA04-20, YA09-20 e YA10-10
Inclusão da regra de validação YA04-20 para somente permitir o grupo de cartões ou boletos para os meios de pagamento corretos. Inclusão da regra de validação YA09-20, que limita o valor do troco. Inclusão da regra de validação YA10-10 para verificar o correto preenchimento do CNPJ beneficiário do pagamento.
2.3.2. Desabilitação das regras X03-10 e X03-20
Desabilita as regras X03-10 e X03-20.
2.3.3. Alteração da regra de validação
A regra da W16-10 é alterada para substituir a Exceção 3 pela Exceção 4, em que não há rejeição quado o campo “indDeduzDeson” não for preenchido ou preenchido com a indicação de “Valor do ICMS desonerado (vICMSDeson) não deduz do valor do item (vProd) / total da NF-e”. Cria Exceção para não aplicar a regra 1C17-34 quando emissão de NFA-e.
3. Evento “Conciliação Financeira – ECONF”
3.1. Leiaute Mensagem de Entrada
O Web Service de Registro de Evento possui uma interface genérica complementada por uma área específica para cada tipo de evento. Segue o leiaute da mensagem de entrada.
Schema XML: envEventoNFe_v9.99.xsd Schema XML – parte específica: leiauteEventoConciliacaoFinanceira_v1.00.xsd
3.2. Leiaute Mensagem de Retorno.
O Web Service de Registro de Evento possui uma interface genérica complementada por uma área específica para cada tipo de evento. Segue o leiaute da mensagem de retorno (resposta).
Schema XML: retEnvEventoNFe_v1.0.xsd
Nota: No caso de evento registrado com sucesso, os campos opcionais serão retornados.
3.3. Processo de Recepção de Evento
O Web Service de Evento é acionado pelo interessado, que deve enviar mensagem com o pedido de autorização do evento da NF-e. O processo de Registro de Eventos recebe eventos em uma estrutura de lotes no qual pode conter de 1 a 99 eventos.
3.4. Validação do Certificado de Transmissão – Geral
Regras de validação idênticas aos demais Web Services, podendo gerar os erros:
3.4.1. 280: “Rejeição: Certificado Transmissor inválido”
3.4.2. 281: “Rejeição: Certificado Transmissor Data Validade”
3.4.3. 283: “Rejeição: Certificado Transmissor – erro Cadeia de Certificação”
3.4.4. 286: “Rejeição: Certificado Transmissor erro no acesso a LCR”
3.4.5. 284: “Rejeição: Certificado Transmissor revogado”
3.4.6. 285: “Rejeição: Certificado Transmissor difere ICP-Brasil”
3.4.7. 282: “Rejeição: Certificado Transmissor sem CNPJ/CPF”
3.5. Validação Inicial da Mensagem no Web Service – Geral
Regras de validação idênticas aos demais Web Services, podendo gerar os erros:
3.5.1. 214: “Rejeição: Tamanho da mensagem excedeu o limite estabelecido”
3.5.2. 108: “Serviço Paralisado Momentaneamente (curto prazo)”
3.5.3. 109: “Serviço Paralisado sem Previsão”
3.5.4. 410: “Rejeição: UF informada no campo cUF não é atendida pelo WebService”
3.5.5. 239: “Rejeição: Versão do arquivo XML não suportada”
3.6. Validação da área de Dados – Geral
a) Validação de forma da área de dados
Regras de validação idênticas aos demais Web Services, podendo gerar os erros:
• 516: “Rejeição: Falha Schema XML, inexiste a tag raiz esperada para a mensagem”
• 517: “Rejeição: Falha Schema XML, inexiste atributo versão na tag raiz da mensagem”
• 215: “Rejeição: Falha Schema XML”
• 587: “Rejeição: Usar somente o namespace padrão da NF-e”
• 588: “Rejeição: Não é permitida a presença de caracteres de edição no início/fim da mensagem ou entre as tags da mensagem”
• 404: “Rejeição: Uso de prefixo de namespace não permitido”
• 402: “Rejeição: XML da área de dados com codificação diferente de UTF-8”
b) Extração dos eventos do lote e validação do Schema XML do evento
Regras de validação idênticas aos demais Eventos, podendo gerar os erros:
• 491: “Rejeição: O tpEvento informado invalido”
• 492: “Rejeição: O verEvento informado invalido”
• 493: “Rejeição: Evento não atende o Schema XML específico”
c) Validação do Certificado Digital de Assinatura
Regras de validação idênticas aos demais Web Services, podendo gerar os erros:
• 290: “Rejeição: Certificado Assinatura inválido”
• 291: “Rejeição: Certificado Assinatura Data Validade”
• 292: “Rejeição: Certificado Assinatura sem CNPJ/CPF”
• 293: “Rejeição: Certificado Assinatura – erro Cadeia de Certificação”
• 296: “Rejeição: Certificado Assinatura erro no acesso a LCR”
• 294: “Rejeição: Certificado Assinatura revogado” • 295: “Rejeição: Certificado Assinatura difere ICP-Brasil”
d) Validação da Assinatura Digital
Regras de validação idênticas aos demais Web Services, podendo gerar os erros:
• 298: “Rejeição: Assinatura difere do padrão do Sistema”
• 297: “Rejeição: Assinatura difere do calculado”
• 213: “Rejeição: CNPJ-Base do Autor difere do CNPJ-Base do Certificado Digital”
• 227: “Rejeição: CPF do Emitente difere do CPF do Certificado Digital”
3.7. Validação das Regras de Negócio
3.8. Final do Processamento do Lote
O processamento do lote pode resultar em: • Rejeição do Lote: por algum problema que comprometa o processamento do lote; • Processamento do Lote: o lote foi processado (cStat=”128 – Lote de Evento Processado”), e a validação de cada evento do lote poderá resultar em: • Rejeição: o Evento será rejeitado, retornando do código do status do motivo da rejeição; • Evento Autorizado, com vinculação à respectiva NF-e: Encontrada a NF-e no banco de dados. Retornar cStat=”135-Evento registrado e vinculado a NF-e”; • Evento Autorizado, sem vinculação à respectiva NF-e: Não encontrada a NF-e no banco de dados. Retornar cStat=”136-Evento registrado, mas não vinculado a NF-e”
4. Evento “Cancelamento Conciliação Financeira – ECONF”
4.1. Leiaute Mensagem de Entrada
O Web Service de Registro de Evento possui uma interface genérica, complementada por uma área específica para cada tipo de evento. Segue o leiaute da mensagem de entrada deste evento
Schema XML – parte específica: leiauteEventoCancelamentoConciliacaoFinanceira_v1.00.xsd
4.2. Leiaute Mensagem de Retorno
O Web Service de Registro de Evento possui uma interface genérica, complementada por uma área específica para cada tipo de evento. Segue o leiaute da mensagem de retorno (resposta).
Schema XML: retEnvEventoNFe_v1.0.xsd
Nota: No caso de evento registrado com sucesso, os campos opcionais serão retornados.
4.3. Validação do Certificado de Transmissão – Geral
Igual às regras previstas no item 03.4
4.4. Validação Inicial da Mensagem no Web Service – Geral
Igual às regras previstas no item 03.5
4.5. Validação da área de Dados – Geral
Igual às regras previstas no item 03.6
4.6. Validação das Regras de Negócio
5. Leiaute da Nota Fiscal Eletrônica
5.1. Grupo I01. Produtos e Serviços / Declaração de Importação
5.2. Grupo N04. Grupo Tributação do ICMS= 20
5.3. Grupo N05. Grupo Tributação do ICMS= 30
5.4. Grupo N06. Grupo Tributação do ICMS= 40, 41, 50
5.5. Grupo N09. Grupo Tributação do ICMS= 70
Grupo N10. Grupo Tributação do ICMS= 90
5.7. Grupo YA. Informações de Pagamento
5.8. Grupo Z. Informações Adicionais da NF-e
6. Regras de Validação
6.1. I01. Produtos e Serviços / Declaração de Importação
6.2. X. Tranporte da NF-e
6.3. YA. Formas de Pagamento
6.4. W. Total da NF-e
6.5. Banco de Dados: Emitente
7. Novos códigos de rejeição
767 Rejeição: CNPJ transacional do pagamento inválido.
768 Rejeição: Tipo de pagamento não aceita o grupo de cartões ou boletos.
769 Rejeição: Valor do troco acima do permitido.
796 Rejeição: CNPJ recebedor do pagamento inválido.
Fonte: Clique aqui
Nos Siga nas Redes Sociais!
Gostou do Post? Caso você não conheça nossa API entre em contato conosco!
Pingback: Decreto 599/2023 MT - Integração entre a NFe/NFCe e meios de pagamento eletrônico