segunda-feira, 25 de maio de 2015

NFe/CTe/MDFe - Tabelas de Erros

Prezados,

Para facilitar a pesquisa de erros quando transmitidos os arquivos XMLs para o SEFAZ, segue link que demonstra os Erros de acordo com os códigos retornados :

- CTe
http://www.scansist.com.br/tabelaErros/Err-CTe.Txt

- NFe
http://www.scansist.com.br/tabelaErros/Err-NFe.Txt

- MDFe
http://www.scansist.com.br/tabelaErros/Err-MDFe.Txt

terça-feira, 17 de março de 2015

Prazo se esgota em 31-3-2015 para migração do layout da NFe 3.10

Conforme publicação da Coordenação Técnica do ENCAT que atualiza a Nota Técnica 2013.005 – Versão 1.10, o layout 2.0 da NFe poderá ser usado até 31 de Março de 2015. Após essa data o mesmo será desativado só sendo permitido emissões no novo layout 3.10.

As mudanças ocorreram em vários pontos, como Serviço de Autorização, Layout do XML, Regras de Validação e Status do Serviço.
Todas essas mudanças têm prazo de implantação conforme o modelo do documento fiscal, até porque as empresas que já estão operando com o modelo 65 (NFC-e), já fizeram as mudanças previstas nesta NT.
Para NFC-e - Modelo 65:
  • Ambiente de homologação: 01/10/2013
  • Ambiente de produção: 04/11/2013
  • Desativação da versão "2.00" da NFC-e: 01/12/2014
Para NF-e - Modelo 55
  • Ambiente de homologação: 02/12/2013
  • Ambiente de produção: 03/03/2014
  • Desativação da versão "2.00" da NF-e: 01/12/2014
Apesar de fazer parte do mesmo manual, os documentos NF-e e NFC-e são tratados  como produtos distintos, ou seja, a Scansist tem os produtos para emissão de NF-e e emissão de NFC-e , ambos disponíveis em versão testes.
Vale ressaltar que nós da Scansist , nossas soluções já estão adequadas para o documento NF-e 3.10 e NFC-e.
Conheça as alterações detalhadamente, com a identificação dos campos que sofreram alteração com a identificação tag XML e id do campo.

Nota Técnica 2013/005 v 1.20/1.21 Alteração no Leiaute de NF-e 
Em Novembro de 2014 a SEFAZ publicou a Nota Técnica 2013/005 versão 1.20 e 1.21, com alterações em esquemas e regras de validação. Com esta Nota Técnica foi liberado a nova versão de esquema PL_008F. Atualmente o leiaute da NF-e está na versão “2.00” e esta Nota Técnica tem o objetivo de divulgar: 
  • * Funcionalidades opcionais que disponibilizadas pelas SEFAZ para o serviço de autorização de uso da NF-e; 
  • * Alterações necessárias para a migração da versão "2.00" para a versão “3.10” do leiaute da NF-e; 
  • * Alterações em regras de validação, principalmente aquelas vinculadas aos novos campos ou a novos controles, melhorando a qualidade da informação prestada pelas empresas e mantida pelas SEFAZ. 
  • Sobre o Serviço de Autorização de Uso da SEFAZ Algumas melhorias serão incorporadas ao serviço de autorização de uso fornecido pelas SEFAZ Autorizadoras (e SEFAZ Virtual), entre elas a possibilidade de a empresa: 
  • * Solicitar a resposta da SEFAZ de forma síncrona, sem a necessidade de geração de recibo de Lote para posterior consulta do resultado do processamento do Lote 
  • * Encaminhar a mensagem do Lote de NF-e de forma compactada, com redução do consumo do seu canal de Internet, potencializando também a redução do canal interno de rede dentro da própria empresa. 

Cabe ressaltar que as mudanças acima são opcionais, podendo a empresa manter o mesmo processo de autorização de uso atual. 

Sobre o Leiaute da NF-e As principais mudanças documentadas nesta versão relacionadas com o leiaute da NFe são: 
  • * Inclusão do campo de Hora de emissão da NF-e e no formato UTC1 e conversão dos demais campos de hora para o mesmo formato UTC; 
  • * Identificação do tipo de operação (interna na UF, interestadual ou operação com o exterior) a partir de um campo novo, permitindo a autorização de uma NF-e em uma operação interna na UF para um destinatário com endereço em outra UF, ou no exterior;
  • * Identificação, no leiaute da NF-e, se o destinatário possui Inscrição Estadual mesmo não sendo contribuinte do ICMS, para as UF que adotam este tipo de controle; 
  • *  Identificação de venda para Consumidor Final; 
  • *  Identificação de venda presencial, pela Internet ou por outros meios de atendimento; 
  • * Identificação da finalidade de emissão da NF-e para devolução de mercadoria, aceitando unicamente itens referentes a devolução de mercadorias; 
  • * Compatibilização do leiaute da NF-e com o leiaute da Nota Fiscal de Consumidor Eletrônica, por meio de um leiaute único para os dois modelos de documento fiscal; 
  • * Possibilidade de a empresa informar na própria NF-e aquelas pessoas (CNPJ / CPF) que poderão, ter acesso ao arquivo XML da NF-e (exemplo: Contador, Transportador, escritório de contabilidade, etc.); 
  • * Inclusão de campo opcional para detalhamento do NCM (campo NVE - Nomenclatura de ValorAduaneiro e Estatística); 
  • * Estabelecimento de grupo de controle, por item da NF-e, para as operações de exportação e exportação indireta; 
  • * Estabelecimento de grupo de controle para operação com papel imune (RECOPI); 
  • * Ampliação do grupo de exportação, documentando na NF-e alguns dos controles necessários, informando, inclusive, o local de saída do País; 
  • * Ampliação opcional da quantidade de casas decimais das alíquotas dos impostos; 
  • * Ampliação na informação sobre a tributação do ICMS, para alguns grupos de tributação (CST 20, 30, 40, 51, …); 
  • * Mudanças solicitadas pela Receita Federal do Brasil (RFB) no controle dos impostos federais; 
  • * Mudanças solicitadas pela Associação Brasileira das Secretarias de Finanças das Capitais (ABRASF) para viabilizar a implementação da NF-e conjugada (ICMS e ISS); 
  • * Mudanças relacionadas com a operação com combustível, principalmente com a obrigatoriedade da descrição do produto conforme o padrão definido pela ANP. Sobre a Nota Fiscal de Consumidor Eletrônica (NFC-e) As mudanças introduzidas no leiaute para a implementação da NFC-e (Modelo 65) são poucas, basicamente envolvendo alterações no processo de validação. Sobre a NFC-e cabe destacar que: 
  • * O escopo da NFC-e abrange, exclusivamente, operações comerciais de venda de mercadoria aconsumidor final, de forma presencial ou com entrega a domicílio, ocorridas no âmbito do Estado (operações internas), sem possibilidade de geração de crédito de ICMS ao adquirente; 
  • * Diferentemente da NF-e, fica a critério da UF aceitar ou não este tipo de documento; Para as UF que aceitarem este tipo de documento, fica a critério da UF o credenciamento das empresas para a emissão da NFC-e; 
  • * A UF que adotar a NFC-e poderá ainda, a seu critério, aceitar ou não a utilização da nova modalidade de contingência criada especificamente para a NFC-e, a contingência off-line, e a dispensa de impressão do DANFE NFC-e. 


Sobre as Regras de Validação 
O processo de validação dos dados da NF-e fica a cargo da SEFAZ Autorizadora, não trazendo, em princípio, grande impacto para as empresas. No entanto, estas validações também têm o objetivo de orientar as empresas de como devem informar os dados na NF-e e, neste sentido, podem acarretar, eventualmente, em algumas mudanças em suas aplicações. A própria alteração do leiaute da NF-e já acarretará, por si só, a necessidade de inclusão e/ou mudança em regras de validação. 
Além disso, foram definidas algumas novas validações, destacando-se as que seguem: 
  • * Possibilidade de informação da IE com ou sem zeros não significativos, independentemente da UF; 
  • * Definição mais precisa do arredondamento para o total da NF-e e para o total do imposto calculado pelo produto da Base de Cálculo e alíquota; 
  • * Validação do Destinatário (CNPJ), mesmo que não informada a IE do destinatário; 
  • * Na operação com combustível, a descrição do produto deve ser a descrição definida pela ANP; 
  • * Criada uma finalidade de emissão específica para a NF-e de devolução de mercadorias, que poderá conter unicamente itens de devolução de mercadoria. 


Alterações na documentação: 
  • * Excluído o subitem 04.8.C.6, que tratava da aplicação da regra “LA-02-10”, a qual tinha, por sua vez, sido desativada na versão 1.10 desta NT; 
  • * Corrigida a natureza do campo B06 para “N”, refletindo o a realidade do Schema; 
  • * Corrigido o tamanho dos campos I29a e I51; 
  • * Corrigida a descrição da hipótese de incidência da regra UA01-10. 


Alterações em regras de validação: 
  • * Alterada a redação da descrição do erro 777 (regra I05-10) para “Obrigatória a informação do NCM completo”; 
  • * Acrescentados os CFOP 5.103 e 5.104 na regra I08-150 (CFOP válidos para uso com NFC-e); 
  • * Acrescentadas CFOP 1.201, 1.202, 1.410 e 1.411 à exceção da regra B25-70 (Finalidade de Emissão de "Devolução de Mercadoria"; 
  • * Acrescentada CFOP 3.949 à exceção das regras I08-120 (CFOP de importação e não informado dados de IPI) e I08-130 (CFOP de importação e não informado dados de II); 
  • *  Introduzida exceção na regra U05-10 para o caso de prestação de serviço no exterior; 
  • * Excluídos seis CFOP da tabela de CFOP de devolução (Anexo XI.01), pois foram detectadas situações que tornavam esta validação inconsistente. 


Prazos de Vigência: Para a NF-e (Modelo 55):
  • * Ambiente de Homologação: 03/02/2014; 
  • * Ambiente de Produção: 10/03/2014; 
  • * Desativação da versão "2.00" da NF-e: 31/03/2015 (NT 2013/005 v 1.10). 
  • * Adiado uso do DPEC até: 31/03/2015 


Nota: No caso das UF que participam do piloto da NFC-e (veja item a seguir), os prazos estabelecidos para a NF-e foram antecipados, já que o novo leiaute unifica os dois modelos de documento fiscal: NF-e (modelo 55) e NFC-e (modelo 65). 

Para a NFC-e (Modelo 65) 
  • * Desativação da versão "3.00" da NFC-e: 31/07/2014. 
  • * Prazos para as UF integrantes do projeto piloto (AC, AM, MA, MT, RN, RS e SE): 
  • * Ambiente de Homologação: 02/12/2013; 
  • * Ambiente de Produção: 06/01/2014. 
  • * Prazos para as demais UF: de acordo com cronograma próprio, divulgado pela própria UF; 


Por enquanto é só !

Para isso, alertamos para aqueles que utilizam sistemas de terceiro para emissão das NF-e, que procurem as Empresas ou Pessoas desenvolvedoras para atualizar a versão do aplicativo com o novo layout da NF-e 3.10, senão vocês terão problemas para emitir NFe em 1-4-2015.


segunda-feira, 16 de março de 2015

Rejeição (219) : Circulação da NF-e / CT-e verificada

Embasamento Legal
Um CT-e ou NF-e só pode ser cancelado caso ainda não tenha ocorrido o fato gerador, ou seja, a circulação da mercadoria da NF-e vinculada. Caso haja a circulação dessa mercadoria (ou relacionado em um MDF-e), o seu cancelamento não será possível, conforme estipulado no manual do contribuinte.
Na prática, o que isso significa?
No momento em que a mercadoria já se encontra em circulação e a sua respectiva CT-e / NF-e tenha sido  consultada em uma barreira fiscal, não será mais possível realizar o seu cancelamento. 
Caso de exemplo:
Uma determinada mercadoria está sendo transportada de São Paulo para o Rio Grande do Sul e, nesse  trajeto,  a CT-e foi consultada em uma barreira fiscal. A partir desse momento o FISCO reconhece que a mercadoria entra em circulação, ou seja, está sendo executado o fato gerador do recolhimento do ICMS. 
Por mais que ainda haja tempo hábil para o cancelamento, este não será mais possível. Caso haja a tentativa de cancelamento nesse momento, será retornada a Rejeição (219): “Circulação do CT-e / NF-e verificada” e o conhecimento ou NF-e não será cancelado.
fonte : https://ciranda.me Thalita Simoni Reis

sexta-feira, 20 de fevereiro de 2015

Ambiente de contingência SVC - SEFAZ VIRTUAL DE CONTINGÊNCIA

A Sefaz Virtual de Contingência (SVC) é uma nova forma de contingência para a emissão de Nota Fiscal Eletrônica (NF-e) que poderá ser usada pelos contribuintes, quando a SefazSecretaria de Estado de Fazenda de origem estiver indisponível. 

O método de funcionamento se assemelha à contingência SCAN-Sistema de Contingência do Ambiente Nacional. Ou seja, quando houver a indisponibilidade de recepção dos arquivos pela Sefaz de origem, esta acionará a SVC referente à sua UF para que ocorra a ativação do serviço de recepção. Após a Sefaz de origem ter seus serviços normalizados, esta deverá entrar em contato novamente com a SVC para desativar o serviço. 

Esta alternativa de emissão da NF-e em contingência, com transmissão da NF-e para a Sefaz Virtual de Contingência (SVC), permite a impressão do DANFE em papel comum e não existe a necessidade de transmissão da NF-e para Sefaz de origem quando cessarem os problemas técnicos que impediam o uso do ambiente de autorização normal da circunscrição do contribuinte. 

Diferentemente do SCAN - Sistema de Contingência do Ambiente Nacional, esta modalidade de contingência não obriga o uso de série específica na NF-e (série 900-999), o que facilitará o uso dessa modalidade de contingência por parte das empresas. Existem dois locais alternativos de autorização em contingência: 
* a do Ambiente Nacional (SVC AN - Tipo de emissão 6), que será disponibilizada pela Secretaria da Receita Federal do Brasil e atenderá aos estados do Acre, Alagoas, Amapá, Minas Gerais, Paraíba, Rio de Janeiro, Rio Grande do Sul, Rondônia, Roraima, Santa Catarina, Sergipe, São Paulo, Tocantins e o Distrito Federal, e 
* a SVC RS (Sefaz Virtual de Contingência do Rio Grande do Sul - Tipo de emissão 7), que atenderá aos estados do Amazonas, Bahia, Ceará, Espirito Santo, Goiás, Maranhão, Mato Grosso, Mato Grosso do Sul, Pará, Pernambuco, Piauí, Paraná e Rio Grande do Norte. 

Onde nForma pode ter os seguintes valores:

  • 1=Emissão normal (não em contingência);
  • 2=Contingência FS-IA, com impressão do DANFE em formulário de segurança;
  • 3=Contingência SCAN (Sistema de Contingência do Ambiente Nacional) (*em desativação*);
  • 4=Contingência DPEC (Declaração Prévia da Emissão em Contingência);
  • 5=Contingência FS-DA, com impressão do DANFE em formulário de segurança;
  • 6=Contingência SVC-AN (SEFAZ Virtual de Contingência do AN);
  • 7=Contingência SVC-RS (SEFAZ Virtual de Contingência do RS);
  • 9=Contingência off-line da NFC-e;
  • Nota: Para a NFC-e somente estão disponíveis e são válidas as opções de contingência 5 e 9.

Confira a Nota Técnica 2013.2007, que apresenta o novo ambiente de autorização de contingência do Sistema NF-e denominado "SVC-SEFAZ VIRTUAL DE CONTINGÊNCIA", disciplinando a forma de uso deste ambiente pelas empresas.
http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=n35AO6XmqBA=

WebServices :
http://www.nfe.fazenda.gov.br/portal/webServices.aspx

Atente que a relação a seguir apresenta uma lista diferente da existente na NT 2013.007 v1.02 e no Portal Nacional da NF-e.
A lista correta, conforme segue, não deve incluir os endereços para Inutilização (discutiremos este item em um próximo artigo).


Corrigindo erro 578 - Rejeição: A data do evento não pode ser maior que a data do processamento (Cancelamento)

578 - Rejeição: A data do evento não pode ser maior que a data do processamento.

O xml do Evento de Cancelamento tem a tag dhEvento que deve ser informada com a data e hora do cancelamento.

O Web Service compara o dhEvento com o horário do servidor e caso seja ela seja maior vai ocorrer o erro:

"578 - Rejeição: A data do evento não pode ser maior que a data do processamento"

A causa do erro pode ser:
1) o horário do equipamento adiantado em relação ao horário do servidor - neste caso basta sincronizar o horário do equipamento;

No pedido de Cancelamento:
<dhEvento>2011-09-23T10:17:29-03:00</dhEvento> <=== hora informada no pedido de cancelamento

Na resposta do WS:
<dhRegEvento>2011-09-23T10:14:29-03:00</dhRegEvento> <==== hora do servidor da SEFAZ <====

2) o horário do equipamento está correto, mas o fuso horário está incorreto - neste caso podemos corrigir o fuso horário ou corrigir o horário.
No pedido de Cancelamento:
<dhEvento>2011-09-23T10:14:29-04:00</dhEvento> <=== hora informada no pedido de cancelamento

Na resposta do WS:
<dhRegEvento>2011-09-23T10:14:29-03:00</dhRegEvento> <==== hora do servidor da SEFAZ <====

corrigindo o fuso horário:
<dhEvento>2011-09-23T10:14:29-03:00</dhEvento>, alteramos o fuso horário para UTC-03:00 no Windows

corrigindo o horário:
<dhEvento>2011-09-23T09:14:29-04:00</dhEvento>, corrigimos a hora para 09:14:29-04:00 que é a hora local equivalente 10:14:29-03:00 no fuso UTC-04:00 (Cuiabá), são 9 horas em Cuiabá (UTC-04:00) quando forem 10 horas em Brasília (UTC-03:00)

Tente verificar qual é a data e hora que está sendo informada na mensagem da cancelmeno enviada para o WS (veja o conteúdo de msgDados) e compare com a data e hora do servidor da SEFAZ que existe na resposta do WS.

<?xml version="1.0" encoding="UTF-8"?>
<retEnvEvento versao="1.00" xmlns="http://www.portalfiscal.inf.br/nfe">
<idLote>11111111111101</idLote>
<tpAmb>2</tpAmb>
<verAplic>SP_EVENTOS_PL_100</verAplic>
<cOrgao>35</cOrgao>
<cStat>128</cStat>
<xMotivo>Lote de Evento Processado</xMotivo>
<retEvento versao="1.00">
<infEvento>
<tpAmb>2</tpAmb>
<verAplic>SP_EVENTOS_PL_100</verAplic>
<cOrgao>35</cOrgao>
<cStat>213</cStat>
<xMotivo>CNPJ-Base do Autor da mensagem difere do CNPJ-Base do Certificado Digital</xMotivo>
<chNFe>35111111111111111111111111111111111111111111</chNFe>
<dhRegEvento>2011-09-23T10:14:29-03:00</dhRegEvento> <==== hora do servidor da SEFAZ <====
</infEvento>
</retEvento>
</retEnvEvento>

Outra opção seria o utilizar o CancelaNFEvento que permite informar a data e hora que o Sr. achar mais conveniente.

Fonte : FlexDocs e Unimake

quinta-feira, 19 de fevereiro de 2015

Corrigindo Erro Requisição 12031 e 12057 - envio de eventos CTe e NFe

Erro de Requisição 12031
Erro de Requisição 12057

Após algumas pesquisas e dor de cabeça com diversos certificados digitais que estão sendo instalados nas estações de trabalhos para envio de CT-e e NF-e , resolvi registrar a melhor forma que encontrei para que os mesmos funcionem corretamente para envio de eventos dos documentos fiscais.

Notei que os erros acontecem devido a uma configuração do I.E. , que quando modificada , aparentemente resolve os problemas de Erro de Requisição.

Os Erros que corrigi com essa mudança foram :

1) CT-e ou NF-e , envio de eventos para cancelamento ou carta de correção
Erro : Requisição não enviada
números : 12031 e 12057
Conexão com servidor foi reconfigurada

2) MDF-e, envio de eventos para encerramento e cancelamento
Erro : Requisição não enviada
número: 12057
Erro para envio de requisição.

Para corrigir (pelo menos em meu caso deu certo) :
a) entre no I.E. > Ferramentas > Opções de Internet > Avançado
b) Grupo Segurança. desmarque todos TLS , ficando dessa maneira.



Vale salientar também que :
- todos os certificados registrei sem  Ativar proteção de chaves, para que não seja pedido 'Conceder Permissão' no momento do envio.
- Marcado apenas opção para backup do certificado.

Dessa forma 



Espero que ajude.












quinta-feira, 20 de dezembro de 2012

Entendendo de forma Simples SCAN, DPEC e FS da NFe


Entendendo de forma Simples SCAN, DPEC e FS da NFe


Modalidades de Contingência como funcionam ?

Os desenvolvedores de sistemas emissores de NF-e devem ficar atentos a essa regra, pois os sistemas precisam saber como se comportar em cada situação.

SCAN – Sistema de Contingência do Ambiente Nacional

O SCAN possui a mesma estrutura de recepção da SEFAZ Origem, executando as seguintes operações:
  • Recepção e autorização de NF-e
  • Cancelamento de NF-e
  • Inutilização de numeração de NF-e
  • Consulta ao status de uma NF-e
  • Consulta status operacional do seu serviço (webservice exclusivo do SCAN)
  • Consulta status operacional do serviço da Sefaz Origem (webservice exclusivo do SCAN)
Para que não ocorra a situação de uma mesma NF-e ser autorizada pelo SCAN e também pela SEFAZ Origem, o SCAN tratará somente Notas com numerações nas séries 900 a 999. Isso se aplica a todos os serviços elencados acima. Do mesmo modo, a SEFAZ Origem não tratará nenhuma Nota que possuir séries reservadas do SCAN.
O software emissor de NF-e deve estar preparado para operar tanto com a SEFAZ Origem quanto com o SCAN. Segundo o Manual de Contingência da NF-e, o sistema de mensageria de NF-e deve se comportar da seguinte forma:
  • Passar a gerar NF-e com numeração nas séries de contingência (900 a 999);
  • Alterar as chamadas dos webservices para invocar os webservices do SCAN;
  • Transmitir o aqruivo da NF-e e imprimir DANFE normalmente, conforme as autorizações emitidas pelo SCAN.
  • Monitorar a disponibilidade da SEFAZ Origem (através do webservice NfeStatusServico do SCAN), para determinar o momento de voltar a operar com a SEAFAZ Origem.
A SEFAZ Origem e o SCAN trabalham em sincronia. A SEFAZ Origem avisa o SCAN quando é o momento em que ele deve ativar/desaticar os seus serviços. A Notas Fiscais eletrônicas autorizadas pelo SCAN serão transmitidas também para o ambiente da SEFAZ Origem, permitindo que a consulta possa ser efetuadas nos dois ambientes.

DPEC – Declaração Prévia de Emissão em Contingência

O DPEC também é um ambiente que recebe solicitações das empresas contribuintes através da comunicação de webservices. Entretanto, o DPEC não autoriza a Nota eletrônica, ele apenas autoriza uma declaração de que aquela NF-e será transmitida posteriormente para a SEFAZ Origem, mas que no momento o DANFE será impresso em contingência (formulário comum A4).
Diferentemente do SCAN, o DPEC não se comunica com a SEFAZ Origem. Nesta forma de emissão em contingência, quando a conexão com a SEFAZ Origem for estabelecida novamente, a empresa contribuinte precisará encaminhar para ela todos os arquivos emitidos em contingência pelo DPEC.
Imagine a seguinte situção: a empresa perdeu a conexão com SEFAZ Origem e também não conseguiu conectar com o SCAN. O que ela faz? Ela bate na porta do DPEC e fala:
- DPEC, preciso emitir uma NF-e em contingência, você pode autorizar?
E o DPEC responde: – Claro, mas preciso de algumas informações. Me passe a chave de acesso, número da nota, série, informações da sua empresa e da empresa do destinatário.
- Ok, seguem as informações. Estou autorizado a imprimir o DANFE em uma folha A4 comum?
- Sem problemas, pode emitir. Mas depois, envie o arquivo completo da NF-e para a SEFAZ Origem.
Fiz essa apresentação “lúdica” para exemplificar de forma mais simples como funciona o processo. Em resumo, a NF-e não foi autorizada pelo DPEC, ele apenas tomou conhecimento de que naquele momento não havia conexão com a SEFAZ Origem, que o contribuinte imprimiu o DANFE e que encaminhará o arquivo posteriormente.
Assim como no SCAN, o software emissor de NF-e precisa ficar checando o momento em que a SEFAZ Origem voltar a ter conexão. Quando isso ocorrer ele, precisa enviar para ela (SEFAZ) todos as Notas eletrônicas que tiveram a autorização de emissão feita pelo DPEC.

FS – Formulário de Segurança

Na emissão do DANFE em Formulário de Segurança o processo muda um pouco. Nessa modalidade, o contribuinte precisa imprimir o DANFE em um formulário especial e em duas vias: uma para acompanhar a mercadoria e outra para ser arquivada na empresa (para posterior apresentação ao fisco). O formulário de segurança trata-se de uma folha especial, feita em Papel Moeda. Ao imprimir deve ser adicionada uma “marca d’água” com a identificação de que o DANFE está sendo impresso em contingência devido a problemas técnicos.
Assim como no DPEC, o arquivo da NF-e não é enviado diretamente para a SEFAZ Origem (pois não está sendo possível a conexão). Então, o sistema emissor de NF-e deve identificar quais NF-e foram emitidas em Contingência e transmitir essas NF-e para a SEFAZ Origem logo que a conexão for estabelecida novamente.

Implementando o Modo de Contingência

Para auxiliar o contribuinte a tomar a decisão de passar a operar em modo de contingência, o sistema de emissão de NF-e pode possuir algumas parametrizações e/ou verificações que definam as circunstâncias em que a emissão passará a ser em contingência. Podem existir inúmeras formas de efetuar esse tratamento, vou descrever algumas formas simples, porém eficázes, de possíveis implementações do sistema emissor de NF-e.

Emissão em contingência através do ambiente do SCAN

De tempos em tempos, o sistema pode consultar o status do serviço da SEFAZ-Origem. Caso identifique que a SEFAZ Origem não esteja disponível, o sistema emissor de NF-e já pode alterar automaticamente a forma de geração das NF-e, passando a gerá-las de acordo com as regras do Ambiente do SCAN.
O sistema pode fazer o mesmo quando a SEFAZ Origem voltar a ficar disponível, retornando a geração de NF-e para a forma normal.
Ao invés de proceder de forma automática, o sistema também pode informar ao usuário da situação e solicitar a confirmação da operação.

Emissão em contingência através do ambiente do DPEC

Assim como no SCAN, de tempos em tempos, o sistema pode consultar o status do serviço da SEFAZ Origem e verificar a sua disponibilidade. Se a SEFAZ Origem não esteja disponível, o sistema emissor de NF-e já pode alterar automaticamente a sua operação, passando a solicitar ao DPEC a autorização para emissão em contingência e identificar quais foram as Notas emitidas em contingência.
Quando a SEFAZ Origem voltar a ficar disponível, retornando a geração de NF-e para a forma normal, deverá transferir todos as Notas eletrônicas setadas como enviadas ao DPEC.
É desejável que esse vai e vem possa ser determinado pelo usuário como automático ou manual (fazendo assim que o usuário confirme a operação).

Emissão em contingência utilizando Formulário de Segurança

Poderia funcionar semelhante ao SCAN. Entretanto, ao invés de solicitar a autorização, poderia setar as Notas emitidas em contingência e também disparar a impressão para o Formulário de Segurança, setando a marca d’água necessária.
Quando a conexão com a SEFAZ Origem for estabelecida novamente, todas as Notas marcadas anteriormente deverão ser eviadas para a SEFAZ para autorização.
Também é desejável que esse processo seja disponibilizado ao usuário de forma onde ele possa optar por fazer manualmente ou deixar que o sistema faça as escolhas automaticamente.

Maicon Klug

Marcel Henrique Scandolara