Simular timeout na comunicação

Última atualização em: 06 de maio, 2016

 

É disponibilizada na tela de configurações para emissão do Módulo NFC-e uma opção para que você usuário possa simular o time out da sua aplicação no momento de comunicar com o Web Service.

Basta acessar o Painel de Controle – Configurações para emissão no módulo NFC-e, e ao configurar o campo ‘Simular timeout de emissão’ como Sim aparecerá o campo ‘Tempo (s)’ em tela, para configurar o tempo de espera para o envio. Por padrão esse campo virá configurado com 20 segundos, permitindo ao usuário configurar um tempo de até 120 segundos.

Se desejar que o tempo de espera para o envio volte ao padrão, basta configurar o campo ‘Simular timeout de emissão’ para Não. O envio então será executado normalmente.

Campo QR-Code na emissão de NFC-e

Última atualização em: 08 de novembro, 2016

 

De acordo com a Nota Técnica 2015/002, “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”.

Com a liberação desta nova Nota Técnica, foi incluído no leiaute da Nota Fiscal um grupo opcional de “Informações Suplementares”, contendo um texto que representa o conteúdo do QR-Code impresso no DANFE – NFC-e. Este grupo de informações está no mesmo nível do grupo “infNFe”, não afetando, portanto, a assinatura digital da Nota Fiscal.

Para as empresas emissoras que integram via Web Service não é obrigatório preencher este novo campo, porém se o mesmo for informado deve seguir as normas do manual do QR-Code, disponibilizado pela SEFAZ.

Se este campo vier em branco o InvoiCy irá preenchê-lo automaticamente, mas se o mesmo já vier preenchido o InvoiCy não fará nenhuma verificação e enviará a informação diretamente para a SEFAZ.

Já para as empresas emissoras que integram via DLL Daruma, a própria DLL irá preencher este campo automaticamente.

Também existe a possibilidade de configurar a forma de alinhamento na impressão desse QR Code no DANFE NFC-e, escolhendo se o mesmo virá centralizado ou alinhado a esquerda.

Para isso basta acessar o Painel de Controle do InvoiCy, módulo NFC-e – Configurações para emissão, onde terá disponível a configuração ‘Alinhamento do Qr Code no DANFE’, com as opções ‘Centralizado e Esquerda’, conforme imagem abaixo.

Ao optar pelo alinhamento do QR Code na esquerda, o mesmo será impresso da seguinte forma no DANFE NFC-e:

Já ao optar pela forma de alinhamento centralizado, o QR Code será impresso da seguinte forma no DANFE NFC-e:

Cadastro de fornecedor para emissão de NFC-e no Paraná

Última atualização em: 13 de outubro, 2015

 

A SEFAZ do Paraná exige que o Fornecedor (Desenvolvedor de Sistemas) faça seu cadastro junto a Receita Estadual, visto que, a adesão voluntária à NFC-e no estado já foi liberada e a data para primeira obrigatoriedade é de 1 de julho (vide calendário); os emissores precisarão encontrar o CNPJ do fornecedor da aplicação para que possam emitir seu CSC (Código de Segurança do Contribuinte).

Para credenciamento:

O FORNECEDOR (Desenvolvedor de Sistemas) deverá efetuar o seu cadastro, alteração e cessação, no endereço eletrônico www.fazenda.pr.gov.br, ambiente RECEITA/PR, serviço UPD, mediante preenchimento de formulário específico, utilizando-se do código de acesso da área restrita e da senha de representante legal previamente cadastrado, conforme passo-a-passo:

Caso ainda não seja usuário do serviço Receita/PR

1) Acessar o serviço “Receita/PR → torne-se usuário” no menu lateral do Portal da SEFAZ, em www.fazenda.pr.gov.br.

2) Seguir todos os passos que o sistema apresentar e ao final você receberá o e-mail de confirmação da homologação, com a senha inicial de utilização.

Caso já tenha login para o serviço Receita/PR

1)  Acessar o site da Receita do Paraná http://www.receita.pr.gov.br/ e efetuar o Login.

2) Clicar no Menu “UPD” e ir em “Pedido de Cadastro”

3) Na próxima tela é preciso informar o CNPJ da software house para “Efetuar o Pedido de Cadastro de Fornecedor de Software”. Depois, é preciso selecionar “NFC-e modelo 65”.

4) Ao final do cadastro, imprimir duas vias, assinar, fazer o reconhecimento em cartório e enviar para a SEFAZ-PR no setor de Protocolo.

5) Após 24 horas você recebe o código de credenciado e está apto a distribuir sua aplicação.

Ambientes de homologação e produção:

Serão disponibilizados ambientes de homologação para testes e ambientes de produção para documentos com validade jurídica.

Para maiores informações acesse a NP FISCAL Nº 063/2012.

Procedimento para obter o CSC na SEFAZ RS

Última atualização em: 05 de maio, 2016

 

Tanto no ambiente de homologação como em produção, ao consultar uma NFC-e pelo QR Code pode surgir a mensagem 383 no site da SEFAZ RS, conforme mostra a imagem abaixo.

Para resolver este erro é necessário gerar o CSC e informá-lo no Daruma FrameWork, ou no painel do InvoiCy.

1º Acessar o link abaixo:

https://www.sefaz.rs.gov.br/Site/MontaMenu.aspx?MenuAlias=m_nfe_nfce

2º Clicar na opção Manutenção de CSC

3º Escolher a opção de login por certificado, ou então se tiver login por CPF.

4º Clicar por certificado Digital.

Caso não funcionar seguir as orientações do final da página da SEFAZ para fazer a limpeza do cache do navegador.

5º Escolher o acesso por CPF do responsável, clicar em Ok.

6º Clicar em meus Serviços

7º No menu do lado esquerdo clicar em Nota Fiscal de Consumidor Eletrônica

8º Após, clicar em Manutenção de CSC

9º Marcar a opção Ambiente de homologação

10º Digitar o CNPJ ou clicar nos três pontinhos

11º Consultar (irá mostrar que não existe nenhum Token para o CNPJ)

12º Clicar em novo

13º Clicar em Ok para gerar um novo Token

14º Clicar na lupa para verificar o Token NFC-e

15º Para integração via DFW, este token deve ser informado no Daruma FrameWork, na tag CONFIGURACAO\IDTokenSefaz, conforme o link: http://www.desenvolvedoresdaruma.com.br.

16º Para integração via Web Service, acessar o InvoiCy, Painel de Controle – grupo NFC-e – Configurações para emissão.

17º Informar o ID e o CSC e clicar em Salvar.

Configurando exportador de documentos para FTP

Última atualização em: 10 de outubro, 2017

 

A Plataforma InvoiCy foi adequada de forma a atender a necessidade do cliente de realizar a exportação automática dos arquivos XML de CF-e SAT e NFC-e emitidas para um diretório FTP, onde terá a possibilidade de configurar os dados do diretório FTP de acordo com sua preferência.

Porém, é importante destacar que o InvoiCy trabalha apenas com o SFTP, que utiliza segurança SSH para garantir a segurança dos dados trafegados, pois se utilizar o FTP normal os dados trafegados serão públicos.

Para configurar os parâmetros da exportação automática e informar os dados do FTP basta acessar o “Painel de Controle”, localizado no menu a esquerda da tela inicial, como destacado na imagem abaixo: “Tela inicial da Plataforma InvoiCy”.

Tela inicial da Plataforma InvoiCy

Na tela do Painel de Controle, representada na Figura “Painel de Controle – Exportação Automática”, acessar a opção “Exportação Automática”, junto as demais opções do Módulo NFC-e.

Painel de Controle – Exportação Automática

Na tela de “Exportação”, representada na imagem abaixo, é possível configurar os dados do Servidor FTP, como Host, Porta do servidor, Usuário e Senha, e ainda definir o diretório para exportação dos arquivos no FTP. É importante destacar também que ao executar o processo de exportação o InvoiCy irá gerar um arquivo de teste (testeFTP.txt) no FTP, para verificar se obteve sucesso na conexão com o FTP configurado, caso contrário irá gravar logs na aplicação relatando as falhas ocorridas.

Após configurar os dados do Servidor FTP o usuário pode definir se a empresa irá exportar os arquivos de forma automática ou não, definindo o tipo de exportação, por período ou intervalo de tempo.

Quando o processo de exportação for executado serão baixados apenas os arquivos com status Autorizado, Cancelado, Inutilizado e Denegado. Se a exportação for por período, todos os arquivos serão compactados em uma pasta .zip e armazenados no endereço do diretório FTP configurado. A nomenclatura padrão do arquivo .zip gerado será: CNPJ_DATAHORAEXPORTADA.zip, exemplo, 99999999000191_20102014100442.zip.

Será gerado ainda um relatório com os totalizadores de todos os documentos que foram exportados pela empresa, por status. O mesmo será armazenado junto com o arquivo .zip no diretório do FTP, com a seguinte nomenclatura: CNPJ_DATAHORAEXPORTADA.pdf. A Figura a seguir demonstra um modelo deste relatório.

Relatório arquivos exportados

Já se o tipo de exportação for por intervalo de tempo, os arquivos serão enviados abertos e salvos no diretório FTP configurado, e nenhum relatório será gerado.

Ao optar por intervalo de tempo deve-se definir o tamanho máximo do lote, ou seja, quantos arquivos serão executados a cada exportação. Destacando que essa configuração é por Parceiro, e o valor padrão é 100. Também deve-se informar para cada empresa um endereço de e-mail para que o Parceiro possa receber informações sobre o processo de exportação. Após 6 tentativas de exportação, se ocorrer falha o Parceiro será comunicado através desse endereço de e-mail, e também no e-mail que está configurado nos dados da empresa.

Quando o tipo de exportação for por intervalo de tempo, os documentos são enviados individualmente para a fila de exportação. O processo de exportação irá buscar os documentos pendentes na fila e exportar a quantidade configurada no lote.

Já ao escolher a opção de exportação por período, na exportação será considerada a data de geração da exportação – 2.

Por exemplo, hoje é 31/07/2015, então o processo irá exportar os arquivos de 2 dias atrás, ou seja, dia 29/07, e a próxima exportação será agendada para o dia 30/07. Então amanhã que é dia 01/08, serão exportados os arquivos do dia 30/07, que é o resultado da data de geração (hoje 01/08 – 2 = 30/07). Dessa forma automaticamente a cada dia será gerada uma exportação D-2, por exemplo:
02/08/2015 gera do dia 31/07/2015 e agenda para dia 01/08/2015
03/08/2015 gera do dia 01/08/2015 e agenda para dia 02/08/2015

Quando a exportação for por período, irá buscar todos os documentos do período agendado, e incluir um único processo de exportação na fila. O usuário poderá ainda escolher se deseja exportar também os documentos com status rejeitado, através da opção “Exportar documentos rejeitados?”.

Exportação por período

Se a empresa desejar exportar os arquivos de um período diferente ou do dia atual poderá fazer uso da Exportação Manual, como representa a Figura “Tela Exportação Manual”

Tela Exportação Manual

Nesse processo de Exportação Manual, ao clicar no botão “Incluir”, poderá criar uma exportação definindo o período inicial e final do intervalo de exportação, conforme a Figura “Criando Exportação Manual”. Ao criar uma nova exportação, seu status será definido automaticamente como “Não Iniciado”.

Criando Exportação Manual

O processo de exportação manual ficará rodando e gerando a exportação de todos os documentos vinculados ao período informado, e que esteja com status “Não iniciado”. Ao concluir o processo será alterado o status de acordo com o resultado final da exportação, “Erro” em caso de falha, e “Concluído” em caso de sucesso. 

No processo de exportação manual, os documentos serão exportados de acordo com a data configurada, mesmo que em paralelo exista um agendamento para a exportação automática, que deverá rodar normalmente. Desta forma, se gerar alguma exportação manual a data do agendamento automático não será afetada pela data informada no processo manual.

É possível ainda gerar um relatório com os totalizadores de todos os documentos que foram exportados pela empresa, por status. Para obter mais informações sobre a geração de relatórios, leia o artigo Relatórios FTP.

Inutilizando uma NFC-e via integração Framework Daruma

Última atualização em: 19 de outubro, 2016

 

Olá! Vamos aprender agora como efetuar a inutilização de uma NFC-e via integração DLL Daruma.

É importante salientar que quando a inutilização for executada através do InvoiCy o aplicativo de PDV ou retaguarda precisa CONSULTAR estes documentos, para atualizar as informações na retaguarda. Já quando a inutilização for disparada pelo aplicativo do emissor, este documento terá um retorno imediato deixando-o atualizado.

Abaixo seguem duas situações onde pode surgir a necessidade de inutilizar uma NFC-e:

Caso 1: O emissor emite uma NFC-e mas esta é rejeitada. A inutilização no PDV não é efetuada e o emissor realiza outra emissão. Passado algum tempo, será necessário inutilizar essa NFC-e que foi rejeitada.

Caso 2: O emissor emite uma NFC-e que identificou a entrada em Contingência, nesta situação a emissão da NFC-e foi em timeout, ou seja, não sabemos o que a SEFAZ fez, se efetuou a emissão ou não.

Com estas duas situações expostas, descrevemos abaixo como proceder para inutilizar o documento.

1. Para parceiros e emissores integrados via Daruma Framework

Na situação do Caso 1, a inutilização pode ser disparada utilizando a seguinte função na DLL:  tCFInutilizar_NFCe_Daruma.

Para mais informações sobre como utilizar a função no Daruma Framework acesse: http://www.desenvolvedoresdaruma.com.br/.

Na situação do Caso 2, a aplicação do emissor e/ou o Daruma Framework referencia o documento anterior para o servidor, e emite um novo documento. O servidor (Daruma-Migrate) é quem resolve a questão automaticamente, ou seja, se cancela ou inutiliza o documento que detectou a entrada em contingência.

Para isso funcionar o documento a ser inutilizado precisa estar referenciado na próxima emissão. Isso deve estar configurado na aplicação e/ou na DLL, dependendo da forma como é controlado o sequencial da NFC-e, se é pela aplicação ou pela DLL.

Para entender melhor como o InvoiCy procede com um documento referenciado, acesse o artigo Referenciando documento emitido anteriormente.

Se caso este documento não for referenciado na emissão posterior, então será necessário seguir com o processo do Caso 1 para inutilizá-lo.

Testes de entrada em contingência – Integração via DLL Daruma

Última atualização em: 04 de maio, 2016

 

No módulo NFC-e da Plataforma InvoiCy é disponibilizada uma opção para que o usuário simule o ambiente de contingência para testar a sua aplicação. Esta opção deverá ser configurada por empresa, e é importante destacar que a mesma estará disponível apenas para o ambiente de homologação.

Para configurar o parâmetro e simular a entrada da contingência basta acessar o Painel de controle – Módulo NFC-e – Configurações para emissão, como demonstra a imagem a seguir.

Na tela do módulo NFC-e estará disponível o campo “Ativar simulação de contingência”, representado na imagem abaixo, com as opções Sim e Não. Nessa mesma tela será possível ainda configurar a ordem de entrada em contingência para a empresa.

Ao ativar a simulação da contingência os documentos de envio, inutilização e eventos (Cancelamento, CC-e, entre outros) emitidos nesse tempo não serão enviados para a SEFAZ, somente após a empresa desativar a opção.

Configurações de Contingência

 

Através desta opção é possível que o usuário simule várias situações que podem acontecer durante a emissão em contingência. A seguir iremos explicar essas possíveis situações e como o usuário deve proceder em cada uma delas.

Para exemplificar usaremos os termos Emissor 1, Plataforma InvoiCy e Daruma framework de forma a facilitar a compreensão por parte do usuário.

Se o Emissor 1 estiver emitindo em modo Normal com tpEmis 1, porém a opção “Ativar simulação de contingência” estiver configurada como Sim, a Plataforma InvoiCy irá entrar em modo contingência, este documento enviado irá detectar a entrada em contingência e ficará com status “Necessita interação”, retornando para o Emissor 1 o código 108.

O correto a fazer neste caso de retorno 108 é emitir uma cópia do documento anterior e avançar a numeração. Esta cópia terá um avanço na numeração e deverá referenciar o documento emitido anteriormente. Recomendamos a leitura do artigo Referenciando documento emitido anteriormente para compreender o funcionamento desse processo.

O Daruma FrameWork irá reenviar este novo xml automaticamente após receber o retorno.

Após o envio desse novo documento com tpEmis 9 o InvoiCy deverá cancelar ou inutilizar o documento anterior que está referenciado. Este processo não roda automaticamente no servidor de testes.

Já a partir da segunda emissão, os próximos documentos emitidos deverão continuar com o tpEmis 9, onde o retorno para o Emissor 1 será o código 109 e o status dos documentos será Contingência Offline.

Para cancelar a simulação do ambiente de contingência a empresa deve desativar a opção “Ativar simulação de contingência”, marcando como Não. Após a empresa sair do modo contingência no InvoiCy, então os documentos serão enviados para a SEFAZ e terão seu devido retorno.

É importante destacar ainda que sempre que o Emissor receber como retorno o código 108 deverá avançar a numeração e enviar um novo documento referenciando o anterior.

Não é aconselhável que o Emissor simule situações para receber o código 109 direto para o Daruma Framework quando estiver enviando com tpEmis 1, pois no processo do ambiente de produção este retorno não irá ocorrer, nesse caso sempre irá retornar primeiro o código 108.

O InvoiCy só irá retornar o código 109 quando estiver em contingência e receber um documento com tpEmis 9, ou se está em modo normal e receber um documento com tpEmis 9 e este identificar a contingência na SEFAZ.

Para facilitar o entendimento do emissor, elaboramos um fluxo abrangendo todas essas situações de emissão em contingência comentadas no artigo, bem como o retorno de cada situação.

Durante o processo de envio, ainda podem acontecer situações como o Aplicativo Comercial ou ERP não possuir conexão com a internet, ou a conexão com o InvoiCy ser perdida durante o processo de emissão e não dar nenhum retorno do documento.

Na primeira situação o documento não será enviado para o InvoiCy, sendo responsabilidade do emissor ajustar a sua infraestrutura para permitir a comunicação com o InvoiCy. Já na segunda situação, o emissor deverá consultar o status do documento para verificar se o mesmo já não foi emitido, ou se será necessário enviá-lo novamente.

Testes de entrada em contingência – Integração via Web Service

Última atualização em: 31 de março, 2016

 

No módulo NFC-e da Plataforma InvoiCy é disponibilizada uma opção para que o usuário simule o ambiente de contingência para testar a sua aplicação. Esta opção deverá ser configurada por empresa, e é importante destacar que a mesma estará disponível apenas para o ambiente de homologação.

Para configurar os parâmetros e simular a entrada da contingência basta acessar o Painel de controle – Módulo NFC-e – Configurações para emissão, como demonstra a imagem a seguir.

Na tela do módulo NFC-e estará disponível o campo “Simular contingência”, representado na imagem abaixo, onde o usuário poderá configurar a simulação do ambiente de contingência, com as opções “Simular timeout SEFAZ” que retorna o código 108, “Simular SEFAZ fora do ar” que retorna o código 109 e “Emissão normal” que retorna o código 100 após o documento ser autorizado na SEFAZ.

Ao ativar a simulação da contingência os documentos emitidos nesse tempo não serão enviados para a SEFAZ, somente após a empresa voltar para a opção “Emissão normal”.

Através desta opção é possível que o usuário simule várias situações que podem acontecer durante a emissão em contingência, que pode ser por EPEC ou contingência Offline.

Antes de optar pela opção EPEC, em primeiro lugar o emissor deverá tratar na integração o código de retorno 136, de forma que seu ERP consiga interpretar o mesmo, pois quando uma NFC-e for emitida em EPEC será retornado o código 109 no status da comunicação e o código 136 no status do documento, sem o arquivo xml, mas com o DANFENFC em base 64 (para mais informações sobre base64 acesse o artigo). Nesse caso, o documento foi emitido porém ainda não está autorizado na SEFAZ, então o emissor deverá consultar o documento posteriormente para ter o xml completo autorizado.

Da mesma forma, ao receber um retorno de código 136 o emissor não deve reenviar o documento, somente consultar o seu status. Tratando o código 136 na integração poderá evitar problemas maiores, como sua empresa ser bloqueada para emissão de documentos em EPEC. Mas em caso de bloqueio da empresa, o artigo Desbloqueio de EPEC explica como proceder nessa situação.

A seguir iremos explicar essas possíveis situações e como o usuário deve proceder em cada uma delas.

Para exemplificar usaremos os termos Emissor 1, Emissor 2, Plataforma InvoiCy e Aplicação parceiro, de forma a facilitar a compreensão por parte do usuário.

Caso 1:

Se o Emissor 1 estiver emitindo em modo Normal com tpEmis 1, porém a opção selecionada for “Simular timeout SEFAZ” a Plataforma InvoiCy irá entrar em modo contingência, este documento enviado irá detectar a entrada em contingência e ficará com status “Necessita interação”, retornando para o Emissor 1 o código 108.

O correto a fazer neste caso de retorno 108, é emitir uma cópia do documento anterior e avançar a numeração. Esta cópia terá um avanço na numeração e deverá referenciar o documento emitido anteriormente. Recomendamos a leitura do artigo Referenciando documento emitido anteriormente para compreender o funcionamento desse processo.

O InvoiCy está preparado para que mesmo na opção “Simular timeout SEFAZ”, se receber um xml com tpEmis 9, retornar o código 109. Após o envio desse novo documento com tpEmis 9 o InvoiCy deverá cancelar ou inutilizar o documento anterior que está referenciado. Este processo não roda automaticamente no servidor de testes.

Ao alterar a opção no InvoiCy  para “Simular SEFAZ fora do ar” os próximos documentos enviados irão retornar para o Emissor 1 o código 109 como status da comunicação e do documento,  se forem emitidos em contingência Offline. Porém, se forem emitidos em EPEC o retorno do status de comunicação será 109, e o retorno do status do documento será 136.

Ainda pode acontecer a situação de nenhuma contingência configurada estar disponível, então o documento ficará como pendente no InvoiCy e não será emitido. O emissor receberá como retorno de status da comunicação o código 109, e como retorno de status do documento o código 105. Isso indica que não poderá mais emitir temporariamente, e deverá então realizar uma consulta antes de fazer o envio da próxima NFC-e.

É importante salientar que o emissor deve sempre estar atento para o código de retorno do status do documento, e não apenas para o código de retorno da comunicação. Para auxiliar na identificação de ambos, o código de status da comunicação pode ser observado no cabeçalho de retorno do SOAP. Já o código do status do documento pode ser visualizado dentro do arquivo xml do documento.

Caso 2:

Pode acontecer uma situação onde o InvoiCy está configurado para emissão em contingência e um Emissor 2 do mesmo estado do Emissor 1, que desconhece que o InvoiCy está em modo contingência, envia um documento com tpEmis 1. Neste caso, o Emissor 2 irá receber como retorno o código 108 e seguirá o fluxo da mesma forma que o Emissor 1 quando também recebeu o retorno 108.

Caso 3:

Também pode acontecer uma situação onde o Emissor 1 recebeu o retorno 108 no primeiro documento, indicando que este documento identificou a entrada em contingência. Se durante este processo de referenciar o documento anterior e enviar novamente o novo documento, o InvoiCy saiu do modo contingência por ter conseguido autorizar outro documento do Emissor 2, ao receber este documento do Emissor 1 com tpEmis 9 ou 4, e ao enviar para a SEFAZ detectar novamente a contingência, o Emissor 1 irá receber o retorno 109 e o documento ficará armazenado no InvoiCy com status Contingência Offline, ou EPEC autorizado.

Para cancelar a simulação do ambiente de contingência a empresa deve selecionar a opção “Emissão normal”.  Após a empresa sair do modo contingência no InvoiCy, então os documentos serão enviados para a SEFAZ e terão seu devido retorno.

É importante destacar ainda que sempre que o Emissor receber como retorno o código 108 deverá avançar a numeração e enviar um novo documento referenciando o anterior.

Não é aconselhável que o Emissor simule situações para receber o código 109 quando estiver enviando com tpEmis 1, pois no processo do ambiente de produção este retorno não irá ocorrer, nesse caso sempre irá retornar primeiro o código 108.

O InvoiCy só irá retornar o código 109 quando estiver em contingência e receber um documento com tpEmis 9, ou se está em modo normal e receber um documento com tpEmis 9 e este identificar a contingência na SEFAZ.

Para facilitar o entendimento do emissor, elaboramos um fluxo abrangendo todas essas situações de emissão em contingência comentadas no artigo, bem como o retorno de cada situação.

Durante o processo de envio, ainda podem acontecer situações como o Aplicativo Comercial ou ERP não possuir conexão com a internet, ou a conexão com o InvoiCy ser perdida durante o processo de emissão e não dar nenhum retorno do documento.

Na primeira situação o documento não será enviado para o InvoiCy, sendo responsabilidade do emissor ajustar a sua infraestrutura para permitir a comunicação com o InvoiCy. Já na segunda situação, o emissor deverá consultar o status do documento para verificar se o mesmo já não foi emitido, ou se será necessário enviá-lo novamente.