Evento de Comprovante de entrega do CT-e

Última atualização em: 03 de setembro, 2019

Atualmente as empresas e transportadoras fazem uso do canhoto da Nota Fiscal, que se encontra na representação impressa da NF-e/CT-e, para comprovação da entrega das mercadorias ao destinatário.

Tendo isso em vista, a NT 2019.001 tem como objetivo disponibilizar uma infraestrutura digital para comprovação de entrega/recebimento de mercadorias, por meio da captura de imagens e registros de eventos nos documentos fiscais eletrônicos utilizados pelos transportadores de cargas (CT-e).

Dessa forma o CT-e passa a disponibilizar o envio de dois novos eventos:

  • Comprovante de entrega eletrônico
  • Cancelamento do comprovante  de entrega eletrônico

O evento 110180 – Comprovante de Entrega Eletrônico do CT-e deve ser utilizado para indicar a efetivação da entrega da carga pelo transportador, onde o emissor do CT-e é o autor do evento. Destacando que esse evento deve ser enviado apenas para CT-e com status autorizado. Clique aqui para efetuar o download do exemplo XML.

IMPORTANTE: o preenchimento da tag ‘hashEntrega’ deve ser feito com um Hash (SHA1) no formato Base64 resultante da concatenação: Chave de acesso do CT-e + Base64 da imagem capturada da entrega (Exemplo: imagem capturada da assinatura eletrônica, digital do recebedor, foto, etc.).

Algumas especificações de acordo com a NT:

Nota 1: A critério do autor desde evento, este campo pode ser utilizado como índice para acesso as informações do Comprovante de entrega.

Nota 2: A SEFAZ não tem nenhum controle sobre a informação deste campo.

Já o evento 110181 – Cancelamento do Comprovante de Entrega Eletrônico do CT-e deve ser utilizado para indicar o cancelamento de um evento de entrega da mercadoria pelo transportador, quando ocorrer erro na geração do evento de entrega por exemplo. Clique aqui para efetuar o download do exemplo XML.

É importante destacar que enquanto um CT-e possuir um evento de comprovante de entrega com status autorizado, o documento não poderá ser cancelado. Clique aqui para baixar o layout de eventos e ter conhecimento de todos os campos que compreendem esses novos eventos.

Release Notes – Versão 2.11.0

Versão 2.11.0 – 31/01/2019 – em produção

Melhorias na tela de digitação

Nesta versão, o InvoiCy passa a contar com melhorias na tela de Digitação. Além da parte visual, foram alterados diversos pontos para melhorar a experiência do usuário. Entre essas alterações, está a possibilidade de visualizar quais campos são obrigatórios no preenchimento dos dados, como por exemplo, de um novo destinatário. Esses campos estarão destacados em vermelho, como demonstra a exemplo abaixo.

Se um produto já foi utilizado para a mesma UF ou mesmo destinatário, o InvoiCy preencherá automaticamente os campos de Informações do Produto e os campos de Informações do Imposto. Caso um produto ainda não tenha sido utilizado para a UF ou para o destinatário da nota em digitação, ou seja um produto novo, esse produto ficará destacado em vermelho para que o usuário lembre-se de revisar detalhes importantes do item. Na imagem a seguir, um exemplo de como o produto ficará quando destacado.

Nas informações dos impostos, as abas que forem de maior importância e obrigatórias estarão destacadas em amarelo. A imagem a seguir demonstra as abas destacadas.

Permitir referenciar NFC-e para nota de devolução

Agora, a tela de digitação permite também referenciar uma NFC-e para uma nota de devolução. Para realizar essa ação o usuário deve selecionar no campo “Finalidade” a opção “Devolução de NFC-e”.

No referenciamento, o usuário poderá referenciar todos ou alguns itens da nota, sendo permitido 120 itens referenciados por cada nota emitida.

Para as notas que estão na base de dados do InvoiCy, o usuário poderá buscá-las por Número e Série ou Chave de Acesso.

O usuário poderá também referenciar notas que não constam na base de dados do InvoiCy, sendo necessária a inclusão da Chave de Acesso da NFC-e, e consequentemente, a inclusão dos produtos manualmente por parte do usuário na grid de produtos.

Ao referenciar uma NFC-e para devolução, o InvoiCy preencherá automaticamente o campo das Informações de Interesse do Fisco com os dados do destinatário da nota referenciada (Nome, endereço, CPF ou CNPJ).

Mensagem de orientação ao usuário

Para os usuários da digitação que emitirem a primeira nota do dia, o InvoiCy mostrará uma mensagem de orientação caso houver pulos de numeração (notas em digitação) em dias anteriores ao atual.

O objetivo é seguir a regra da SEFAZ, que orienta que não se emita uma nova NF-e quando ainda há NF-es em digitação de dias anteriores, para não ocasionar problemas na sequência da numeração das próximas notas emitidas.

De acordo com a SEFAZ: “Conforme Ajuste SINIEF 7/05 Cláusula terceira, Inciso II – a numeração da NF-e será sequencial de 1 a 999.999.999, por estabelecimento e por série. Caso você deixar NF-e em digitação com numeração anterior a última NF-e autorizada, terá uma quebra na sequência da numeração da NF-e e estes números de NF-e em Digitação não poderão ser mais utilizados nas emissões, mas sim deverão ser inutilizados até o 10 (décimo) dia do mês subsequente, conforme Cláusula décima quarta.”.

Novo campo disponível na correção de NFC-e

Na versão 2.11.0 do InvoiCy, foi incluído um novo campo para correção de NFC-e. A partir de agora o campo CEANTrib também pode ser corrigido através da tela de correção da NFC-e.

Importação de CT-e recebidos

Nas versões anteriores do InvoiCy, os documentos CT-e recebidos eram importados para o InvoiCy apenas quando o CNPJ da empresa estivesse no papel de Destinatário do documento. A partir dessa versão, os documentos serão importados, independente de qual papel o CNPJ da empresa esteja informado (tomador, remetente, expedidor, recebedor).

Novo campo no layout de impressão da NFS-e

A partir desta versão do InvoiCy, a representação impressa do Espelho da NFS-e passa a apresentar a data e hora de autorização ou conversão da NFS-e na prefeitura. A apresentação desta informação depende do retorno da prefeitura, portanto, está disponível apenas para os municípios que retornam tal informação, nos demais será apresentada a data de emissão do Recibo Provisório de Serviço (RPS).

Detalhamento da versão

Para conhecer todas as modificações realizadas nesta versão, clique aqui.

Evento de Prestação do Serviço em Desacordo

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

Juntamente com a nova versão do layout 3.0 do CT-e, foi disponibilizado o novo evento de prestação do serviço em desacordo.

Esse evento permite que o tomador do serviço informe ao fisco que o documento CT-e que o relaciona está em desacordo com a prestação de serviço, ou seja, o tomador pode se manifestar nas situações em que não estiver de acordo com o CT-e emitido pela transportadora.

O prazo para informar esse evento é de até 45 dias após a autorização de uso do CT-e objeto do evento, sendo que este CT-e não pode estar cancelado ou denegado, ou ter um CT-e de substituição ou anulação associado.

O código correspondente ao evento de prestação do serviço em desacordo é 610110, onde o autor do evento é o tomador do serviço que está indicado no CT-e.

Para efetuar o envio do evento, deve-se usar o layout de eventos, apenas adequando os campos necessários para o evento em específico. De acordo com a imagem abaixo, deverá informar na tag <Evedet> a descrição “Prestação do serviço em Desacordo”. A tag <indDesacordo> deverá ser preenchida com o valor ‘1’, e se desejar ainda pode informar observações do tomador na tag <Observacao>.

Estrutura evento

Para entender melhor a estrutura do layout de eventos disponibilizamos nosso layout em Excel, com todos os campos disponíveis, faça download clicando aqui. Para visualizar um exemplo completo do XML do evento clique aqui.

Layout 3.0 CT-e

Última atualização em: 06 de junho, 2017

Olá! Este artigo tem por objetivo disponibilizar o layout 3.0 do XML do CT-e. Aqui você irá encontrar a estrutura completa de campos para realizar a integração de seu ERP com o InvoiCy.

A tabela abaixo deve ser utilizada como legenda para interpretação dos campos do arquivo do envio e retorno do XML.

Coluna

Nome do Campo

Tipo

(tamanho)

N – campo numérico C – campo alfanumérico D – campo data H – campo hora

Ele

G – Grupo E – Elemento CG – Elemento de Grupo que deriva de uma escolha (choice) CE – Elemento que deriva de uma escolha (choice)

Pai

TAG raiz do XML de integração

Ocorrência

x-y, onde x indica a ocorrência mínima e y, a ocorrência máxima:

1-1  = campo obrigatório, com uma possibilidade,

1-N = campo obrigatório, com uma ou várias possibilidades,

0-1  = campo opcional, com uma possibilidade,

0-N = campo opcional, com uma ou várias possibilidades.

LAYOUT XML 3.0

LAYOUT Eventos

É importante destacar que a partir da liberação do layout 3.00, quando existir um CT-e de anulação autorizado há mais de 15 dias com o mesmo emitente, sem que exista o CT-e de substituição correspondente, será retornada a seguinte rejeição: “736 – Rejeição: Existe CT-e de anulação autorizado há mais de 15 dias sem a autorização do CT-e substituto”, e será retornada a chave de acesso do CT-e de anulação mais antigo.

Dessa forma, sempre que um CT-e de anulação for autorizado, posteriormente é necessário emitir o CT-e de substituição correspondente, evitando assim que a empresa seja bloqueada para emissão de CT-e de anulação.

Acesse também a Central de Downloads Migrate, onde você poderá encontrar diversos exemplos reais de CT-e para download.

Alterações necessárias para entrada em Produção

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

 

Olá! Neste artigo iremos abordar quais alterações são necessárias para que a empresa inicie a emissão no ambiente de PRODUÇÃO do InvoiCy. Antes de realizar a entrada em Produção recomendamos que leia o artigo “Verifique se sua empresa está apta para entrar em Produção”, e efetue o checklist de testes recomendado no artigo.

Ao concluir os testes de integração com o ambiente de homologação do InvoiCy, seu próximo passo será iniciar a emissão com o ambiente de Produção. Para que isso seja possível devemos atentar-se para os seguintes procedimentos:

1. ASSINE O CONTRATO! Só será possível realizar a emissão em Produção após a Migrate ter recebido o contrato devidamente assinado. Após a assinatura do contrato a Migrate irá liberar o ambiente de Produção, onde você receberá um e-mail contendo os dados de acesso do ambiente, como usuário e senha, bem como o link de acesso ao portal. Em caso de dúvidas referente este procedimento contate imediatamente seu Gerente de Contas, ou envie um e-mail para comercial@migrate.com.br.

2. CADASTRE SEUS CLIENTES! Após o recebimento dos dados de acesso ao ambiente de Produção por e-mail, seu primeiro passo será efetuar o cadastro de seus clientes no InvoiCy. ATENÇÃO! O processo de cadastro é IRREVERSÍVEL e passível de COBRANÇA! Uma vez cadastrada, a empresa não poderá mais ser excluída, e a ativação de sua licença poderá iniciar o processo de cobrança. Só efetue o cadastro de uma empresa no ambiente de Produção se tiver certeza de sua utilização. Em caso de dúvidas no processo de cadastro consulte o artigo “Cadastrar uma empresa via Interface Web”.

3. AJUSTE SEU XML DE INTEGRAÇÃO! Para que seja possível realizar a emissão do primeiro documento em ambiente de Produção, atente-se para alguns ajustes que devem ser realizados no XML de integração.

     3.1 TAG <tpAmb>: Em ambiente de homologação esta tag era enviada com o valor 2. Agora em Produção é necessário enviar o valor 1, que corresponde ao ambiente de Produção. Ex: <tpAmb>1</tpAmb>.

     3.2 TAGS <ChaveParceiro> e <ChaveAcesso>: Apenas para quem realiza integração com o InvoiCy Conector, altere as tags <ChaveParceiro> e <ChaveAcesso> com as chaves do ambiente de Produção. Para obter essas chaves acesse o ambiente de Produção, menu Painel de Controle > Dados da Empresa. Para integrações via Web Service ver item 4.

4. CHAVE DE COMUNICAÇÃO: Em ambiente de Produção atente-se para o correto uso das chaves para comunicação com o InvoiCy. No ambiente de homologação era utilizado uma chave de acesso para geração do hash MD5 de comunicação. Já em Produção, é gerada outra chave. A chave de parceiro não é alterada. Para encontrar a nova chave de acesso que deve ser utilizada acesse no ambiente de Produção o menu Painel de Controle > Dados da Empresa.

5. ALTERAÇÃO DO WEB SERVICE: Para comunicação com o InvoiCy em ambiente de Produção altere o Web Service de sua aplicação para: https://app.invoicy.com.br/arecepcao.aspx?WSDL. Já para quem realiza integração via InvoiCy Conector, acesse a tela abaixo e efetue a devida alteração de sua instância para ambiente de PRODUÇÃO:

6. LICENCIAMENTO: Caso não tenha licenciado a empresa, vá até a tela Painel de Controle > Módulos Contratados e efetue o licenciamento de acordo com o módulo contratado. Para maiores informações consulte o artigo “Licenciamento de Empresas”.

Após estas alterações você estará apto para realizar a emissão em Produção. Em caso de dúvidas ou problemas nas primeiras emissões em Produção envie um e-mail para integracao@migrate.com.br. Estaremos dispostos a lhe auxiliar.

Chave de Comunicação Inválida

 

Olá! Neste artigo vamos apresentar algumas das principais causas do retorno 173 – Chave de Comunicação inválida, muito comum no início da integração, e que pode causar bastante dúvida no início dos testes de desenvolvimento.

Vamos lá! Antes de mais nada, devemos entender como funciona o processo de validação da chave de comunicação no InvoiCy. A essa altura, você já deve saber que é necessário gerar uma chave de comunicação MD5, com base na chave de acesso da empresa com o XML que está sendo enviado. Essa informação é informada no parâmetro “EmpCK” do WebService. Caso tenha dúvidas quanto a geração do MD5, consulte o respectivo artigo clicando aqui.

Quando ocorrer alguma falha na geração desta chave MD5, você receberá o retorno 173 – Chave de Comunicação Inválida. Abaixo seguem alguns dos problemas rotineiros na geração da chave, que geram este retorno:

  • Usar chave errada para geração do MD5. Conforme visto no artigo “Gerando o Código Hash no formato MD5”, é necessário utilizar a chave de acesso da empresa cadastrada no InvoiCy. Ao término do cadastro de uma empresa, é gerada a chave que deve ser usada neste processo. Para se certificar de que está utilizando a chave correta, acesse no InvoiCy o Painel de Controle > Dados da empresa, e clique sobre o botão “Chave de Acesso”. Esta é a chave que deve ser utilizada para geração do MD5.
  • Enviar palavras com acentuação gráfica ou caracteres especiais no XML do documento. Não é permitido o envio de caracteres especiais no XML.
  • Dupla conversão do XML para texto. Sabemos que no momento do envio de um documento ao WebService, os caracteres < e > do XML devem ser substituídos por &lt; e &gt; respectivamente. A maioria das ferramentas de desenvolvimento já realiza essa conversão de forma automática, não sendo necessário fazer a conversão manualmente. Porém, quando é realizada a conversão manual e a ferramenta também realiza essa conversão, ocorre a dupla conversão, o que irá causar erro no momento do envio da nota, e poderá causar também erro de chave de comunicação inválida.
  • Modificar informações no XML após geração do MD5. Não é permitido alterações no XML após geração do MD5. Em caso de qualquer alteração, deverá ser gerado novamente o MD5.
  • Problemas no método gerador de MD5 da ferramenta de desenvolvimento. Principalmente na linguagem DELPHI, costuma ocorrer falha no processo de geração do MD5. Para comparar um MD5 gerado pela aplicação com o MD5 correto, pode-se usar o seguinte site: http://www.miraclesalad.com/webtools/md5.php

Basta inserir a chave de acesso mais o XML (tudo junto e linearizado), e então verificar o MD5 gerado.

Contingência para Módulo CT-e

Última atualização em: 19 de fevereiro, 2018

 

Olá! Neste artigo iremos falar sobre o processo de envio de documentos em contingência, as possíveis situações que podem acontecer e como o emissor deve proceder em cada uma delas.

Primeiramente o emissor deve definir as configurações relacionadas a contingência para sua empresa. Para isso, basta acessar o Painel de Controle, módulo CT-e, Configurações para emissão, como demonstra a imagem.

 

Para o módulo CT-e estão disponíveis as formas de contingência EPEC, SVC e Nenhuma, onde o InvoiCy possibilita que o emissor defina qual a opção de emissão será priorizada no momento em que o ambiente normal estiver indisponível.

Para definir a ordem das opções de emissão basta clicar nas flechas que estão ao lado de cada uma das opções, até posicioná-las na forma desejada. O InvoiCy fará o envio do documento de acordo com a primeira opção de contingência que estiver configurada. Caso a primeira opção de contingência não esteja disponível, será realizada uma tentativa de envio para a opção seguinte, seguindo assim para todas as opções e só encerrando o processo ao chegar na opção Nenhuma.

 

Opções de contingência

Bem, antes de definir qual será a primeira opção de emissão em contingência, vamos entender as diferenças entre os ambientes SVC e EPEC.

O ambiente da SEFAZ Virtual de Contingência (SVC) tem sua disponibilidade controlada pela SEFAZ, sendo ativado geralmente quando a SEFAZ de origem realiza alguma manutenção programada em sua estrutura. Nestas circunstâncias, a SEFAZ de origem solicitará a ativação do ambiente SVC para sua UF, que passará a receber seus CT-e por um tempo pré-definido. Os CT-e autorizados pela SVC não precisam ser reenviados, pois a sincronização dos documentos entre a SVC e a SEFAZ de origem é realizada automaticamente.

Já o Evento Prévio de Emissão em Contingência (EPEC) está disponível a qualquer momento, sendo recebido pelo Ambiente Nacional, porém um evento de CT-e registrado neste ambiente, necessita obrigatoriamente, de seu posterior envio para a SEFAZ de origem, realizando assim a conciliação do evento junto a autorização do CT-e.

Outra informação que deve ficar entendida é que a contingência é definida por UF e não por empresa, ou seja, a partir do momento que qualquer uma das empresas emitentes em determinada UF deixar de receber o retorno de um documento da SEFAZ, esta UF passará a operar em contingência e todas as demais empresas desta UF também.

A partir do momento em que a contingência for ativada, o InvoiCy passará a verificar a ordem de contingência configurada em cada empresa e fará o envio dos documentos conforme esta configuração.

 

Contingência SVC

Se a contingência SVC estiver configurada como primeira opção, o InvoiCy fará o envio do documento para o ambiente da SVC, que uma vez estando ativo, fará as validações do documento e em caso de efetivação o emissor receberá como retorno o código 100, o arquivo xml e o DACTE (conforme configurações da empresa), indicando que o documento foi autorizado. Nesse caso o processo de envio em contingência foi executado com sucesso, o documento está autorizado e o emissor não tem a necessidade de consultar o status do documento, pois conforme vimos acima, a sincronização entre os ambientes será automática.

Em caso de rejeição o emissor deverá fazer a correção e o reenvio do documento. Se o ambiente da SVC não estiver ativo, o InvoiCy fará uma nova tentativa de envio do documento para o EPEC, caso esta for a segunda opção de contingência configurada, senão o processo termina neste momento e o documento ficará com o status Pendente.

Acesse o fluxo da contingência SVC.

 

Contingência EPEC

Agora, se a primeira opção for a contingência EPEC, o InvoiCy fará o envio de um evento com os dados do documento para o ambiente nacional da SEFAZ, onde passará por validações básicas em sua estrutura e em caso de autorização o emissor receberá como retorno de status da comunicação o código 109, e como retorno de status do documento o código 136, sem o arquivo xml, mas com o DACTE para transporte da mercadoria. Isto significa que o documento foi emitido porém ainda não está autorizado na SEFAZ, ou seja, o emissor deverá realizar, em um segundo momento, a consulta desse documento para atualização de status e obtenção do XML completo de autorização.

Acesse o fluxo da contingência EPEC.

Vale ressaltar que no momento em que a comunicação com a SEFAZ de origem for restabelecida, o IncoiCy fará automaticamente o envio de todos os documentos emitidos em EPEC para a sua SEFAZ de origem, buscando sua autorização e consequentemente a conciliação do evento EPEC. Em caso de rejeição o emissor deverá fazer a correção e o reenvio do documento.

Pode acontecer ainda a situação de nenhuma das contingências configuradas estarem disponíveis, 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.

109 – SEFAZ em contingência

105 – Documento pendente

Resumo: O emissor estará temporariamente impedido de emitir e deverá realizar uma consulta antes de fazer o envio do próximo documento.

 

Códigos de retorno

É importante salientar que o emissor deve estar atento aos códigos 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.

Uma vez definida a utilização do EPEC, o emissor deverá tratar em sua integração o código de retorno 136, de forma que o ERP consiga interpretar o mesmo, pois quando um documento for emitido em EPEC, os códigos retornados serão 109 para o status da comunicação e 136 para o status do documento. Neste caso o emissor deverá fazer uma consulta posteriormente destes documentos buscando a atualização de seus status e não deverá realizar seu reenvio enquanto não obtiver um novo status. Isso irá evitar problemas de duplicidade de documento com diferença na chave de acesso e bloqueio de empresas para emissão de novos documentos em EPEC. Em caso de bloqueio da empresa, o artigo Desbloqueio de EPEC explica como proceder nessa situação.

109 – SEFAZ em contingência

136 – Contingência EPEC

Resumo: Para os documentos com estes status, o emissor deverá realizar consultas para a atualização de status e fazer seu reenvio somente quando receber um status diferente do atual.

Outro código que precisa ser tratado na integração é o 108, que será retornado para o documento que identificar a indisponibilidade da SEFAZ de uma UF. Isso irá ocorrer quando o InvoiCy receber um documento e não conseguir enviá-lo à SEFAZ ou não obtiver o seu retorno junto a SEFAZ, detectando neste momento a necessidade de entrar em modo de contingência. O documento que identificar a contingência ficará com o status “Necessita interação” no InvoiCy e o emissor receberá como retorno do InvoiCy o código 108, tanto para o status do documento, como para o status da comunicação.

108 – Entrada da SEFAZ em contingência: [erro_encontrado]

108 – Entrada da SEFAZ em contingência: [erro_encontrado]

Resumo: Quando um documento se encontra com o status ‘Necessita Interação’, significa que esse documento identificou uma instabilidade na comunicação com a SEFAZ e o InvoiCy não obteve retorno satisfatório. O fluxo indicado pela Migrate para tratamento nesse caso, é envia-lo novamente incrementando a numeração e referenciar o documento que está como ‘Necessita Interação’ para descarte. Através deste processo o InvoiCy verificará o status deste documento, caso ele esteja autorizado ele será cancelado e caso não conste na SEFAZ a numeração será inutilizada. Esse modelo de descarte permite que o fluxo de emissão siga sem interrupções de forma automática e transparente para o emissor. Recomendamos a leitura do artigo Referenciando documento emitido anteriormente” para compreender o funcionamento desse processo.

Quando é executado o processamento automático desse documento que ficou com status ‘Necessita Interação’, o sistema realiza uma consulta do mesmo na SEFAZ a fim de obter seu status, caso essa consulta tenha sucesso o documento será apresentado na plataforma de acordo com o retorno obtido da SEFAZ, caso a consulta retorne que o documento não existe na base de dados da SEFAZ, esse será alterado para status de ‘Rejeitado’ no painel do InvoiCy permitindo assim que o ERP realize o reenvido dessa numeração. É muito importante que seja executado o reenvio do documento somente após obter o retorno de ‘Rejeitado’.

Uma informação importante quanto ao código 108 é que um único documento por UF irá receber este retorno ao identificar alguma falha de comunicação com a SEFAZ, pois a partir disso todos os demais documentos das empresas que emitam nesta mesma UF passarão a emitir automaticamente em modo de contingência. Outro detalhe é que este retorno independe do tipo de contingência utilizada pela empresa que enviou o documento e detectou a falha de comunicação.

 

Por que avançar numeração e referenciar o documento anterior?

Esta regra foi implementada para evitar problemas com o documento que identificar a contingência, uma vez que neste momento não é possível saber se o documento chegou até a SEFAZ ou não. Realizando este tratamento o emissor consegue garantir que um documento que pode estar efetivado na SEFAZ não seja enviado também para a SVC ou EPEC, por exemplo. Supondo que o documento esteja efetivado na SEFAZ e seja feito simplesmente o seu reenvio pelo sistema, como o InvoiCy já estará operando em modo de contingência ele fará o envio para uma das opções (SVC ou EPEC), podendo gerar os seguintes problemas:

– Se o documento for enviado e efetivado na SVC, irá ocorrer falha na sincronização entre os ambientes, devido a duplicidade de documento com diferença nas chaves de acesso;

– Se for enviado para EPEC, o problema irá ocorrer no momento da conciliação do documento, pois o documento teve um EPEC com horário posterior a sua autorização.

Uma vez referenciado o documento, o InvoiCy se encarrega de realizar as ações necessárias sobre ele, realizando seu cancelamento ou inutilização, conforme for a situação em que o mesmo se encontra junto a SEFAZ.

 

Restabelecimento de comunicação

Após cessarem os problemas de comunicação com a SEFAZ da UF o InvoiCy voltará ao modo de comunicação normal e passará a verificar quais documentos precisam receber algum encaminhamento.

Para o documento que identificou a contingência e foi referenciado no segundo documento, o InvoiCy fará automaticamente a sua consulta junto a SEFAZ. Se estiver efetivado será providenciado seu cancelamento, caso contrário, a sua inutilização.

Já para os documentos emitidos em EPEC, o InvoiCy irá realizar seu envio para conciliação, podendo ser efetivado ou rejeitado. Estes são os casos de retorno 136, onde o emissor deverá fazer a consulta dos documentos para atualização de seus status e reenvio, quando necessário.

Para facilitar o entendimento do emissor, foi elaborado um fluxo abrangendo todas as situações de emissão em contingência, 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.