Voltar para o topo
Caso não consiga ver as imagens deste e-mail, acesse este link.
Escovando Bits

DarumaFramework adequada à nova Nota Técnica NFC-e

Alterações da Nota Técnica 2015.002 com DarumaFramework

Escovadores de Bits,

Neste artigo vamos falar rapidamente sobre as alterações aplicadas a partir da Nota Técnica 2015.002 V1.10 da NFC-e, informando o que foi ajustado na DarumaFramework para atendê-la; e também o que não requer ajuste na DarumaFramework, mas requer atenção por parte do contribuinte e seu setor contábil.

A DarumaFramework foi atualizada!
A nova versão atende em conformidade com a nova Nota Técnica. Baixe:

DarumaFramework.dll 32bits | Versão: 10.03.02 | Liberação: 10/10/2015
DarumaFramework.dll (Windows) 32bits »
DarumaFramework.dll 64bits | Versão: 10.03.09 | Liberação: 24/11/2015 [NOVO]
DarumaFramework.dll (Windows) 64bits »
DarumaFramework.so | Versão: 10.03.07 | Liberação: 09/11/2015
DarumaFramework.so (Linux) 32bits »
DarumaMobile.jar | Versão: 3.20.00 | Liberação: 24/11/2015 [NOVO]
DarumaMobile.jar (Android)  (Android)  »

Quando entra em vigor? (ATUALIZADO 19-10-15)

Mesmo que algumas regras da Norma Técnica entre em vigor apenas em 2016, é necessário atualizar o seu sistema para as alterações antes de Dezembro de 2015.

Temos três datas, isso porque existem os servidores de Homologação – Testes e o de Produção – Oficial e as regras de validação específicas.

As datas previstas são:

  • 01/10/2015 início de atualização para Ambiente de Homologação/Testes;
  • 01/12/2015 para Ambiente de Produção;
  • 01/01/2016 é a data limite para regras de validação da lista abaixo:
    • NCM contido na tabela MDIC, (regra de validação I05-20);
    • CFOP x Grupo Combustível, a critério da UF (regra de validação LA01-20);
    • CFOP x Grupo Encerrante, a critério da UF (regra de validação LA11-10);
    • Verificação do CST ou CSOSN (regras de validação N12-30, N12a-20);
    • CSOSN 103 ou 400 não permitidos, a critério da UF (regra de validação N12a-30);
    • Se informado o grupo de pagamentos por cartão, deve ser informado o grupo de cartões, a critério da UF (regra de validação YA04-10);
    • Se informado o grupo de Cartões, deve ser informado o tipo de integração (regra de validação YA04a-10);
    • Se informado o tipo de Integração 1 - TEF devem ser informados os campos de CNPJ da Credenciadora e o código de autenticação da operação, a critério da UF (regra de validação YA05-10);
    • Falta do campo de QR-Code para a NFC-e (regra de validação ZX02-10).

Abaixo temos os tópicos presentes no Resumo inicial sobre as alterações (primeira página da NT).

Alterações

A. Consulta Situação da Nota Fiscal
Limitado o prazo da consulta ao Web Service de Consulta Situação para 180 dias da data de emissão da Nota Fiscal Eletrônica. Alterada também a resposta desta consulta, retornando unicamente os eventos de Cancelamento, Carta de Correção e EPEC.”

Esta alteração não requer alterações na DarumaFramework, além disso para quem utiliza o Serviço Daruma – Migrate, não existe esta preocupação, já que uma vez gravada no servidor InvoiCy, a venda poderá ser sempre consultada.


B. Enquadramento Legal: IPI / ICMS
Definição dos valores possíveis para o Código de Enquadramento Legal no IPI, incluindo o código de isenção de IPI relacionado com as Olimpíadas Rio 2016. Definido também novo Motivo de Desoneração do ICMS relacionado com as Olimpíadas Rio 2016.”

Este segundo item também não requer alterações na Daruma Framework, isso porque para NFC-e não se aplica IPI.


C. Regras de Validação Diversas
A partir desta NT será verificado se o NCM informado no item da Nota Fiscal existe na tabela de NCM publicada pelo Ministério do Desenvolvimento (MDIC). Foram alteradas também diversas regras de validação, melhorando a qualidade da informação recebida, afetando, principalmente, os sistemas das SEFAZ Autorizadoras.”

Para este item não temos alterações na DarumaFramework, algumas validações foram melhor documentadas, e foram inclusas novas também. Vamos citar algumas: atenção para os códigos NCM utilizados eles são validados de acordo com a tabela do MDIC (Ministério do Desenvolvimento), evitando rejeição de notas por códigos errados, não aceitar mais CPF nos dados do Emitente ou enviar nota com dados iguais para Emitente e Destinatário também não é permitido.


D. NFC-e: Ambiente de Homologação
Alterados os controles para a autorização de uso de NFC-e enviada para o ambiente de homologação (ambiente de testes para as empresas)”.

Assim como já era informado na identificação do consumidor, quando CPF indicado na nota, agora é obrigatório também que o primeiro item de cada cupom enviado para o ambiente de homologação possua descrição específica. Para este item faremos ajustes na DarumaFramework, que irá fazer automaticamente a substituição do nome do Destinatário e a Descrição do primeiro item pelas expressões obrigatórias, sempre que o tipo do ambiente for 2 – Homologação ou 3 – Desenvolvimento.

A descrição do primeiro item na venda em homologação deve ser: “NOTA FISCAL EMITIDA EM AMBIENTE DE HOMOLOGAÇÃO – SEM VALOR FISCAL”. Já a mensagem que deve constar no destinatário quando indicado o CPF/ CNPJ é: “NF-E EMITIDA EM AMBIENTE DE HOMOLOGACAO – SEM VALOR FISCAL”


E. NFC-e: Prazo de Tolerância no envio para a SEFAZ
Mantida a tolerância de 5 minutos no atraso no envio da NFC-e para a SEFAZ, devido ao sincronismo de horário do servidor da empresa e do servidor da SEFAZ. Eliminada a tolerância anterior de 10 minutos. Para o Evento de Cancelamento, foi incluída a mesma tolerância de 5 minutos de atraso no envio, devido ao sincronismo de servidores citada anteriormente.”

Para a DarumaFramework não será necessária nenhuma modificação, visto que já possuímos recursos para sincronizar horários e também para evitar rejeição por horários iguais de emissão e cancelamento.


F. NFC-e: Grupos de Tributação vinculados com CFOP
Incluídas regras de validação relacionadas com os grupos de tributação do ICMS e CFOP possíveis de serem utilizados nas operações de venda para consumidor final, através da NFC-e.”

Com a inclusão dessas validações de acordo com o CFOP informado, vimos que são necessários ajustes na Daruma Framework para atender corretamente as validações para os impostos. Por exemplo: aCFConfICMS90_NFCe_Daruma – está informando obrigatoriamente um campo que não é mais obrigatório e pode causar erro (campo modBCST). Outra alteração que surgiu deste item é a geração de um retorno de método descontinuado para os métodos: aCFConfICMSSN101_NFCe_Daruma, aCFConfICMSSN201_NFCe_Daruma, aCFConfICMSSN202_NFCe_Daruma, estes impostos não são aceitos para NFC-e. Então se o seu software está utilizando estes métodos, retire-os para evitar que seja utilizado.

Mesmo com as alterações que estamos realizando, o contribuinte deve ficar atendo em utilizar apenas o CFOP’s permitidos para NFCe, os CFOP’s usados também devem ser compatíveis com o CST, sendo recusada a venda que não estiver com combinação prevista pela Nota Técnica.

Veja a lista de CFOP’s aceitos para NFC-e (nota modelo 65): 5101, 5102, 5103, 5104, 5115, 5405, 5656, 5667, 5933. Para NFC-e também foram definidos os CST válidos: 00, 20, 40, 41, 60 e 90 (este último é aceito a critério da UF) e o CSOSN, que não pode ser diferente dos contidos na relação: 102, 103, 300, 400 500 e 900 (aceito a critério da UF).

Caso seu cliente (o contribuinte) não esteja com um desses valores aceitos, entre em contato com o seu setor contábil para verificar quais são as configurações corretas e aplicáveis ao seu comércio. Com isso evitará notas recusadas quando as novas validações entrarem em vigor.


G. NFC-e: Utilização na operação de venda de combustível
Viabilizada a utilização da NFC-e para representar a operação de venda de combustível para consumidor final, efetuada por Posto Revendedor de Combustíveis”.

A partir deste item, estamos criando o método aCFConfCombustivel_NFCe_Daruma na DarumaFramework, que deverá ser utilizado antes do aCFVender_NFCe_Daruma, e assim informar todos os dados obrigatórios para venda de combustível. Veja a assinatura do método como será:

int aCFConfCombustivel_NFCe_Daruma(char* pszcProdANP, char* pszpMixGN, char* pszCODIF, char* pszqTemp, char* pszUFCons, char* pszqBCProd, char* pszvAliqProd, char* pszvCIDE, char* psznBico, char* psznBomba, char* psznTanque, char* pszvEncInicial, char* pszvEncFinal, char* pszUsoFuturo)

Esses campos não aparecem na impressão da Danfe, mas são enviados pra sefaz, e pelo painel do InvoiCy será possível visualiza-los.


H. NFC-e: Formas de Pagamento
Alterado o grupo de informações sobre o pagamento da NFC-e por cartão de crédito / débito, incluindo a informação do tipo de integração do processo de pagamento com o sistema interno da empresa. Foram estabelecidas novas regras de validação nesta área.”

A inclusão de novo campo obrigatório para pagamentos em Cartão, gerou um novo método para pagamentos em cartão: aCFEfetuarPagamentoCartao_NFCe_Daruma. Com o qual será possível informar todos os dados do pagamento em cartão. Veja como ficou a assinatura deste método, você poderá utiliza-lo sempre que houver pagamento com cartão, não precisando chamar usar outro comando de pagamento:

int aCFEfetuarPagamentoCartao_NFCe_Daruma(char* pszTipoCartao, char* pszValorPgto, char* pszTipoIntegracao, char* pszCNPJCred, char* pszCodBandeira, char* pszAutorizacao, char* pszUsoFuturo)


I. NFC-e: Campo de QR-Code no leiaute da NFC-e
O Projeto da NFC-e compreende a autorização da NFC-e pelas empresas e a disponibilização para o consumidor final de uma Consulta da NFC-e via QR-Code. Incluído no leiaute um campo texto que representa o QR-Code. Incluídas novas regras de validação, garantindo a qualidade desta informação.”

Este requisito aumentou um campo no xml de venda, para informar os dados impressos no QRCode, então teremos implementação na DarumaFramework para atender a ele. Automaticamente a framework vai montar essa string e colocar no xml para envio, sem que seja necessário alguma implementação no seu software.

Não estão no resumo mas merecem uma observação

  • Formulário de Segurança para NFC-e: Não será mais aceita a emissão de NFC-e em contingência em Formulário de Segurança, ficando como opção válida para contingência apenas o tpEmis = 9 - Contingência Offline ou tpEmis = 4 - Contingência EPEC. Para você que utiliza a DarumaFramework, não será necessária nenhuma atualização, pois a framework e o servidor Migrate tratam a contingência como Offline sempre.
  • Identificação do Destinatário Estrangeiro: Apesar de ter formato livre, este campo não pode conter caracteres que interfiram na montagem do QrCode, e por isso a Framework passará a validar os caracteres informados no campo de acordo com a indicação da nota, que diz que pode ter algarismos, letras e 7 caracteres específicos: [:.+-/()], portanto sua aplicação receberá um erro de “Parâmetro Inválido” (código de retorno -99).
  • CSC - Código de Segurança do Contribuinte: Com as novas regras de validação para o QrCode, alguns estados passarão a exigir obrigatoriamente que seja informado o CSC que também é conhecido por token. Cada contribuinte recebe seu CSC quando a partir do momento que se cadastra para a emissão de notas, seja no ambiente de produção ou teste. Verifique se seu Token/CSC já está preenchido nos seus dados para emissão com DarumaFramework.

Como é necessário que os servidores sejam atualizados para as novas exigências passarem a valer, você pode ir preparando sua aplicação e orientando os contribuintes a checarem as suas tributações para que na data de atualização do servidor de homologação já seja possível realizarem testes e garantirem que na data em que o Ambiente de Produção entrar em vigor com a nova Nota, seja transparente para a aplicação.

As implementações como a do QrCode, campos novos de pagamento, encerrantes, passarão a ser aceitos e/ ou enviados pela framework automaticamente a partir do momento que o servidor informar para ela que a Nota 2015.002 está valendo.

É importante, que para evitar grandes problemas com essa atualização, você leia esta Nota Técnica, para que visualize tudo que pode afetar o seu ramo de atuação, ou aquilo que pode já identificar que o contribuinte precisa verificar com a contabilidade dele. Se adiante e assim quando a Nota entrar em vigor, não haverá ajuste a ser realizado de ultima hora.

A Nota está disponível no site da Fazenda:
http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=mCnJajU4BKU=

Se tiver alguma dúvida e/ou dificuldade, entre em contato com a nossa equipe de suporte ao desenvolvedor.

Suporte ao desenvolvedor: 0800 770 3320
E-mail Skype
desenvolvedores.suporte@daruma.com.br
suporte.desenvolvedores@daruma.com.br
daruma.desenvolvedores@daruma.com.br
desenvolvedores.daruma@daruma.com.br
suporte@daruma.com.br
suporte.ddc@daruma.com.br
ddc.suporte@daruma.com.br
ana.ribeiro@daruma.com.br
claudenir@daruma.com.br
desenvolvedores_suporte_daruma
suporte_desenvolvedores_daruma
daruma.desenvolvedores
suporte_ddc_daruma
ddc_suporte_daruma
desenvolvedores_daruma
suporte_daruma
anaribeiro.ddc
claudenir_andrade
Acompanhe nossa comunidade e fique por dentro de novidades
DDC Facebook Twitter Google+ Linkedin YouTube Skype Social Network
www.desenvolvedoresdaruma.com.br