Migrando a NF-e 2.0 para 3.10

A NFeLibrary, a partir da versão 2014/02, passa a suportar a geração do arquivo XML no layout versão 3.10 conforme descrito no manual de orientação. A principal modificação no novo layout é o suporte para emissão de NFC-e além de ajustes gerais na NF-e.

Esta nova versão do XML inclui diversas alterações que afetam diretamente a geração do arquivo XML. Com o objetivo de minimizar o impacto para o desenvolvedor, a NFeLibrary foi modificada para permitir que as aplicações que a utilizam possam ser rapidamente adaptadas para atender as alterações do novo layout.

Apesar do encapsulamento feito pela NFeLibrary da complexidade do projeto e do descritivo abaixo com as alterações necessárias para adaptação para o novo layout, é altamente recomendado que o desenvolver examine o manual de orientação e as notas técnicas para que saiba quais são as alterações que afetarão diretamente sua aplicação.

É extremamente importante ressaltar que uma vez migrada a aplicação para a nova versão do layout identificada como 3.10 não será mais possível gerar o XML na versão 2.00. Portanto é necessário que o desenvolver garanta que a aplicação foi testada em cada SEFAZ atendida pela aplicação, garantindo assim que uma nota fiscal não seja recusada pela SEFAZ por conta do WS ainda não estar adaptado para autorizar notas eletrônicas com o XML no novo layout.

Além do desenvolvedor verificar cada SEFAZ que a aplicação faz uso é recomendado também que o desenvolvedor faça um backup completo do seu ambiente de desenvolvimento (código fonte) antes de iniciar a migração, garantindo assim que, por qualquer eventualidade, seja possível voltar à versão anterior.

Alterações no grupo de identificação da NF-e (ide)

SCHEMA-001

Neste grupo, usado para identificação da nota, foram feitas algumas mudanças, sendo que a principal delas está relacionada aos campos de data. Agora os campos de data como dhEmi e dhSaiEnt, são campos que devem conter não apenas a data mas também a hora do evento e o fuso horário em questão, por exemplo, ’01/07/2014T14:35:45-03:00’. Para que o desenvolvedor não tenha que se preocupar com a formatação do campo a Library disponibilizou dois campos na estrutura da NF-e que deverão ser usados em conjuto: dhEmissao e nEmissaoTZ, e seus tipos são DateTime e Number respectivamente. Assim o desenvolvedor se preocupará apenas em informar a data e hora da ocorrência e o fuso horário onde se encontra (-3, por exemplo). O mesmo é válido para dhSaiEnt e nSaiEntTZ, e para dhCont e nContTZ.

Além da mudança da data/hora, outra mudança é a possibilidade de informar no campo mod o valor 65, identificando que a nota em questão é uma NFC-e.

O campo tpImp também sofreu alteração, e agora são válidos os valores numéricos entre 0 e 5. Assim também o campo ifinNFe agora permite valores entre 1 e 4. E o campo itpEmis que permite  valores entre 1 e 9 exceto o 8.

SCHEMA-002

Também no grupo ’ide’ um novo campo foi adicionado que precisa ser informado, que é o indicador da operação e foi chamado de iidDest, sendo os valores válidos para esse campo 1, 2 ou 3 indicando respectivamente Operação Interna, Operação Interestadual ou Operação com o Exterior.

Outros dois novos campos foram adicionados no grupo ’ide’ que servem para indicar se é uma operação com o consumidor final (iindFinal) e outro para indicar se o comprador estava presente no momento da compra (iindPres).

STRUCT-001

Alterações no grupo de identificação do destinatário (dest)

SCHEMA-003

Há duas mudanças principais no grupo ’dest’ que afeta o desenvolvedor. Uma delas é a inclusão da informação da Inscrição Municipal, que deve ser passada no parâmetro sIM na função NFeGeraXMLCliente.

A outra principal alteração no grupo ’dest’ está relacionado à emissão de NFC-e, pois o grupo não é obrigatório neste caso e portanto, ao gerar o XML da NF-e/NFC-e através da função NFeGeraXMLNFe o parâmetro hoDest passou a não ser mais obrigatório caso o modelo informado para a nota seja "65".

SCHEMA-004

Na nova versão do layout o CPF/CNPJ/Identificação do Estrangeiro também sofreu alteração. Entretanto essa mudança foi encapsulada pela Library e o desenvolvedor deverá apenas preocupar-se em continuar passando o CPF/CNPJ para a função da mesma forma que já passava, tratando apenas a identificação do estrangeiro quando houver. O antigo parâmetro sCNPJ passou agora a ser identificado como sIdDest.

Outra alteração necessária neste grupo foi a informação da IE. Na nova versão é necessário informar através de um indicador a situação da Inscrição Estadual. Esse tratamento é feito diretamente pela Library através do conteúdo do parâmetro sIE, e o desenvolvedor deverá preocupar-se em passar ISENTO quando for o caso, vazio, ou então a IE do destinatário.

NFeGeraXMLCliente

Novo grupo dos autorizados para download do XML (autXML)

SCHEMA-005

No novo layout foi adicionado um novo grupo chamado ’autXML’ que tem por objetivo listar todos as pessoas físicas ou jurídicas que podem efetuar o download do arquivo XML da nota através do Portal da NF-e ao efetuar uma consulta de NF-e.

As informações para este grupo devem ser carregadas na parâmetro vtNFeAutXML que é uma matriz do tipo tNFeAutXML. Para detalhes de como carregar as informações neste grupo consultar a documentação da função NFeGeraXMLNFe.

STRUCT-002

Alterações no grupo de identificação do produto (prod)

SCHEMA-006

Neste grupo foi adicionado um novo campo chamado sNVE e que será carregado apenas se o seu conteúdo for diferente de branco e que serve para carregar a nomenclatura de valor aduaneiro e estatística.

Também foi adicionado neste grupo o campo snRECOPI usado para informar o número do RECOPI, informação específica para operação com papel imune.

STRUCT-003

Alterações no grupo de informações da importação (DI)

SCHEMA-007

No grupo ’DI’ referente aos dados de importação vários campos foram adicionados: itpViaTranspnvAFRMMiTpIntermediosCNPJsUFTerceiro. Cada campo deverá ser preenchido de acordo com a especificação do manual e conforme a necessidade de cada cenário.

STRUCT-004

Alterações no grupo de informações adicionais da importação (adi)

SCHEMA-008

Já no grupo ’adi’ foi adicionado o campo snDraw.

STRUCT-005

Novo grupo de detalhes da exportação (detExport)

SCHEMA-009

Dentro do grupo ’prod’ foi adicionado um novo grupo chamado de ’detExport’ que contém as informações referentes ao processo de exportação. As informações a serem carregadas neste grupo foram adicionadas no tipo tNFedet e portanto estão contidas dentro do parâmetro vtNFedets

STRUCT-006

Alterações no grupo específico para combustíveis (comb)

SCHEMA-010

Caso seja aplicado ao seu negócio, o grupo ’comb’ também foi modificado e o campo npMixGN foi adicionado para que possa ser informado o percentual de gás natural para o produto.

STRUCT-007

Alterações no grupo de impostos

No grupo dos impostos vários detalhes foram ajustados. Entre eles podemos citar:

  • Ajuste da quantidade de casas decimais em determinados campos;
  • Inclusão de campos já existentes em outros grupos de ICMS como o campo para informar o valor da desoneração no grupo ICMS20;
  • Alteração do nome do campo usado para informar o valor do ICMS como no caso do grupo ICMS40;
  • Alguns grupos se tornaram opcionais por conta da NFC-e como os grupos ’PIS’ e ’COFINS’ e são carregados apenas se o CST é informado;
  • Inclusão de novos campos especialmente no grupo ISSQN visando a possibilidade de emissão de NF-e conjugada com a NFS-e.

Novo grupo dos impostos devolvidos (impostoDevol)

SCHEMA-011

Este grupo foi incluído para permitir que seja informado o imposto que foi devolvido.

STRUCT-008

Alterações no grupo de totalização do ICMS (ICMSTot)

SCHEMA-012

No grupo ’ICMSTot’ foi adicionado o campo vICMSDeson, onde deve ser informado o valor total de ICMS desonerado.

STRUCT-009

Alterações no grupo de totalização do ISSQN (ISSQNTot)

SCHEMA-013

Neste grupo novos campos foram adicionados para informar os valores totais referentes aos impostos de serviços ou informações adicionais. Estes campos são: dCompetvDeducaovOutrovDescIncondvDescCondvISSRetcRegTrib.

STRUCT-010

Novo grupo para detalhamento da forma de pagamento (pag)

SCHEMA-014

Através do parâmetro vtNFepag, pode ser passado para a função NFeGeraXMLNFe uma matriz do tipo tNFepag, que serve para gerar as informações das formas de pagamento utilizadas para saldar a NFC-e.

Para informações sobre o preenchimento de cada campo deve ser consultado o manual de orientação.

STRUCT-011

Alterações no grupo de identificação da exportação (exporta)

SCHEMA-015

Também foram feitas algumas alterações no grupo de exportação onde os campos originais UFEmbarq e xLocEmbarq foram renomeados para UFSaidaPais e xLocExporta e o campo sxLocDespacho foi adicionado. Por questões de compatibilidade os nomes dos campos anteriores foram mantidos na estrutura, porém ao gerar o XML os mesmo serão gerados com os novos nomes.

STRUCT-012

Contingência

Com o premissa de manter o código legado funcionando, o desenvolvedor terá duas opções a partir da versão 2014/02 para tratar a data e hora da contingência. A nova versão 3.10 do layout necessida da data e hora no formato ’AAAA-MM-DDThh:mm:ssTZD’. Ou seja, é necessário informar além da data e da hora, também o respectivo fuso horário.

As duas opções que o desenvolvedor tem para informar a data/hora da contingência são:

  1. Utilizar o campo sdhCont da estrutura da NF-e carregando a data e hora com o fuso horário já de acordo com o formato exigido no novo layout;
  2. Carregar os campos dhContnContTZ da estrutura com a data/hora no formato DateTime e o fuso horário no formato Number, e a Library se encarregará de converter para o formato correto.

Recomendamos que seja utilizado a partir da nova versão os novos campos (opção 2), pois a formatação da informação fica a cargo da Library e o desenvolvedor não precisa se preocupar em carregar a informação no formato exigido. 

A função de leitura do XML, NFeLerXMLAutorizado, também faz o tratamento adequado. A partir da versão 2014/02 a Library carregará os 3 campos com a informação da data/hora da contingência, podendo o desenvolvedor escolher o campo que melhor se adapta à sua aplicação.

Processo de autorização

Com o advento da versão 3.10 e também da NFC-e, surgiu uma nova modalidade de autorização permitindo aos emissores que autorizem uma nota de forma síncrona. Essa nova forma de autorização é adotada de forma opcional por cada SEFAZ. Ou seja, uma SEFAZ pode adotar o modo síncrono e outra não. Portanto o desenvolvedor deverá fazer esse tratamento na sua aplicação.

Envio síncrono ou por lote

O envio síncrono é permitido apenas quando uma única nota é enviada. Como a NFeLibrary trata os envios uma única nota por vez, a autorização de forma síncrona acontecerá de forma automática, quando possível. Para atender essa nova forma de comunicação a assinatura do método NFeEnviar sofreu algumas alterações e o desenvolvedor deverá fazer as devidas adaptações.

O parâmetro sNroRecibo agora retornará o número do protocolo da nota se a mesma for autorizada, ou então retornará o número do recebido do lote, se o método síncrono não for permitido na SEFAZ.

O parâmetro sdhRecbto foi incluído após a o parâmetro sNroRecibo para que o desenvolvedor receba a data da autorização da nota, quando o processo de autorização for bem sucessido.

Também foi adicionado um novo parâmetro chamado de sArquivoAutorizado e que é obrigatório e deve conter o arquivo XML (caminho e nome) onde o arquivo da NF-e autorizada será salvo no caso do processo ser executado de forma síncrona.

E também foi adicionado o parâmetro opcional bGeraIdInfProt que indica se deve ser adicionado no elemento infProt do XML de retorno o atributo ID com o número do protocolo de autorização assim como é feito na função NFeBuscar.

NFeEnviar

Busca da Autorização

Para o caso da SEFAZ não implementar a autorização síncrona, o desenvolvedor deverá tratar o retorno da função NFeEnviar adequadamente e então, após receber a informação de que o lote foi recebido com sucesso, fazer a chamada da função NFeBuscar assim como acontece no processo da versão 2.00 para saber o resultado da solicitação de autorização.

Esse processo não mudou e a chamada da função NFeBuscar não sofreu alterações de parâmetros. As mudanças na função que busca o retorno da solicitação de autorização foram apenas internas e o desenvolvedor deverá apenas fazer testes para garantir que o processo na sua aplicação está adequado com autorização assíncrona, quando necessário.

NFeLibrary.DLL

As alterações para atender as novas especificações do layout 3.10 também afetaram a NFeLibrary.DLL. Para atender as novas especificações novas funções foram criadas e também o arquivo WS2.XML foi alterado com a adição de novos endereços.

Portanto todos os emitentes que desejam utilizar a nova versão do layout deverão obrigatoriamente atualizar a DLL para uma versão maior ou igual a 2.0.3.0.

Um detalhe importante que deve ser verificado é que a nova versão da DLL funcionará apenas com a versão mais nova de licenciamento. Ou seja, licenças emitidas antes de 29 de Fevereiro de 2012 precisarão obrigatoriamente atualizar suas licenças para que possam utilizar as novas funções e emitir então a NF-e no novo layout. 

Para verificar a questão das licenças, por favor entre em contato conosco para maiores informações.

IMPORTANTE: como as funcionalidades não exigem que a licença seja informada para uso em ambiente de homologação, ao realizar testes com a Library e com a nova DLL todas as funcionalidades serão executadas com sucesso. Porém, ao instalar a DLL no cliente a aplicação poderá parar de funcionar se a licença do cliente não estiver atualizada. Portanto antes de colocar a aplicação no cliente recomendamos verificar a questão da licença para que o cliente não pare o faturamento após a atualização da DLL pela não atualização da licença de uso da DLL.

Endereços do WS

Um detalhe importante relacionado à DLL é a questão da atualização dos endereços onde estão os serviços a serem consumidos da nova versão do layout. Em alguns casos os endereços se mantiveram e a SEFAZ preparou os serviços para suportar o recebimento de um arquivo na nova versão do layout. Em outros casos, como a SEFAZ de SP, novos endereços foram criados para receber os arquivos XML gerados na nova versão do layout.

Portanto é necessário verificar se a sigla da SEFAZ atendida pela sua aplicação não precisa ser modificada para que os novos serviços sejam utilizados.

SEFAZ/PR, SEFAZ/BA e SEFAZ/SP

Especificamente para o PR, para a BA e para SP é necessário mudar a sigla da SEFAZ informada na chamada das funções para identificar o WS a ser usado. Deve ser mudado de PR para PR3; de BA para BA3; e de SP para SP3.