Italo Giurizzato Junior

Boa tarde, Antes de iniciar a montagem da sua rotina de EPEC você precisa entender de forma correta o seu objetivo. Lembre-se que o EPEC é um evento que tem como objetivo enviar o minimo de informações possível da venda para SEFAZ. Logo não ocorre o envio da nota completa. Devemos utilizar o EPEC quando é o emitente que esta com problema de conexão com a SEFAZ. Quando é a SEFAZ que esta com problemas devemos usar o SVC - SEFAZ-Virtual de Contingência. Lhe convido a ler a Nota Técnica: 2013/007 versão 1.03 - que trata sobre o SVC. De forma resumida: 1. Enviar a nota para a SEFAZ-Autorizadora quando tanto o emitente quanto a SEFAZ estão operando sem nenhum problema. 2. Enviar a nota para a SVC quando a SEFAZ-Autorizadora estiver com problemas e o emitente não. 3. Enviar o evento EPEC para a SEFAZ-Autorizadora através de uma conexão 3G (por exemplo) quando o emitente estiver com problemas e a SEFAZ-Autorizadora não. Após sessar os problemas do emitente enviar a nota para a SEFAZ-Autorizadora.

Boa tarde Jorge, O retorno da situação só retornado ao usar o método ConsultarSituacao no caso dos provedores que seguem o layout versão 1.00 como é o caso do Ginfes. Já os que seguem a versão 2.00 é retornado ao usar o método ConsultarLoteRPS.

Boa tarde Wislei, E ao tentar usar a função mencionada o que você tem como retorno?

Boa tarde a todos, Luis, tem que ficar claro que o terceiro paragrafo do FAQ que você postou se refere ao pedido de cancelamento e que o mesmo poderá ser rejeitado pela SEFAZ caso o CT-e tenha uma CC-e conforme descrito no primeiro paragrafo. Mateus, a mensagem que você recebeu ao tentar cancelar não é um erro e sim uma resposta da SEFAZ ao seu pedido de cancelamento. Ao pedir um cancelamento a SEFAZ pode aceitar ou não, se for aceito é retornado o protocolo de homologação do cancelamento e o evento de cancelamento é vinculado ao CT-e. Por outro lado de não for aceito, temos ai a rejeição, ou seja, a SEFAZ rejeitou o seu pedido e neste caso ela retorna o motivo dessa rejeição.

Boa tarde Nelson, Você pode tomar como base os provedores que mencionei na minha postagem anterior.

Boa tarde Tiago, Mas você configurou o componente para realizar a consulta após o envio? Existe uma propriedade para isso. Se o valor dela for False o componente realiza o envio e salva o retorno apenas. E você esta postando exatamente isso o envio e o retorno. Ao configurar o componente para realizar a consulta outros arquivos serão gerado e salvo no disco. Se você abrir o arquivo de retorno *-rec.xml vai notar que não contem nenhum erro e sim o numero do protocolo de recebimento do lote pelo web service.

Boa tarde Tiago, Favor atualizar os fontes. Fiz uma alteração para que o componente remova do retorno do Web Service os Escapes e quebras de linhas inseridos no XML. Refaça os testes, mas antes verifique se o componente esta configurado para consultar o lote após o envio.

Tiago, Favor atualizar todos os fontes e realizar novos testes. Note que fiz uma atualização no arquivo INI do provedor.

Boa noite Tiago, No caso da NFS-e você não gera o XML da nota e sim do recibo, ou seja, RPS. O componente gera o XML do RPS e envia para o Web Service do provedor, este por sua vez o processa e se estiver tudo OK retorna o XML da NFS-e. Configure o programa exemplo para salvar os arquivos Soap. Realize novos testes e post como anexo os XML gerados.

Raylan, Eu não encontrei nada que pudesse estar provocando esse erro, não tem vogais acentuadas, cedilha e nem caracteres especiais no XML do RPS. A montagem do envelope esta seguindo exatamente o que consta na especificação feita por eles. O XML é salvo em UTF-8. Veja se consegue com o pessoal do provedor um XML que certamente seria aceito, para que possamos efetuar uma comparação.

Boa tarde Fabrício, Não existe inutilização de notas e sim de números. Vamos pegar a chave que você postou: 1316044299150001786500100000048300000048, agora vamos fragmenta-la: 13-16-04429915000178-65-001-000000483-000000483 13 = Código da UF 16 = Ano 2016 04429915000178 = CNPJ do emitente da nota 65 = modelo da nota -> NFC-e 001 = série 000000483 = numero inicial 000000483 = numero final Você solicitou a inutilização do numero 483 série 1 do modelo de nota 65, etc. A SEFAZ entende que por algum problema no seu sistema a nota de numero 483 série 1 não foi emitente, logo ela não existe na base de dados da SEFAZ. Portanto não cabe cancelamento, carta de correção e consulta.

Boa tarde, Post em anexo o XML da respectiva nota que foi rejeitada.

Boa tarde Leandro, Não adianta eu lhe enviar o programa exemplo compilado se o componente apensar de ser possível de ser compilado e instalado no Delphi ainda precisa de correções. Você vai tentar usar, vai ocorrer erros, e ai? Volto a lhe perguntar, você tem o componente instalado no Delphi?

Boa tarde Mateus, Você concorda que se isso fosse possível a SEFAZ iria rejeitar o cancelamento de um CT-e que possui um evento de carta de correção? Me desculpe a mensagem da rejeição deixa muito claro, eu não tenho nenhuma duvida sobre isso. A SEFAZ interpreta da seguinte forma se você enviou uma carta de correção significa que o transporte foi realizado sendo assim não cabe um cancelamento. Ah mas o transporte não foi realizado, a carta de correção foi feita porque descobrimos o erro, mas agora ocorreu um desacordo comercial e a carga não vai mais ser transportada. O que fazer nesse caso, primeiro se o transporte não foi realizado não faça uma carta de correção e sim cancele o errado e faça outro CT-e com os dados corretos, desta forma se for necessário um cancelamento por desacordo comercial você não terá nenhum impendimento. Se você esta fazendo apenas testes em ambiente de homologação, legal, mais uma que você aprendeu e que deve ser passado para os seus clientes a forma correta de trabalhar. Agora se isso ocorreu em ambiente de produção consulte um bom contador para saber como proceder nesse caso.

Raylan, Obrigado pelos arquivos. Analisando eles com a definição dos serviços esta tudo de acordo. Com apenas uma diferença, o prefixo usado no envelopamento era s: alterei para soap: Essa alteração foi feita no arquivo Vitoria.INI Favor atualizar os fontes e refazer os testes.

Boa tarde Raylan, Configure o programa exemplo para salvar os arquivos soap e repita os testes, depois post em anexo os XML gerados.

Leandro, Você esta com todos os fontes de todas as pastas atualizados? Você utilizou o ACBrInstall_Trunk2 para instalar os componentes, inclusive o ACBrGNRE? Esse tipo de erro ocorre quando o Delphi não encontra a pasta onde encontra o componente. Você já procurou por essa DCU, para saber em qual pasta ela esta? Verificou no Library Path do Delphi se o caminho dessa pasta consta da lista?

Bom dia Juliano, Você abriu o seu XML com um navegador? Se sim, notou isso: &cDest=72496207034 &dhEmi= a existência de espaço em branco entre o CPF do destinatário e o elemento dhEmi? Isso significa que você esta atribuindo ao campo CNPJCPF o numero do CPF formatado com 14 caracteres sendo que o CPF possui apenas 11. A rotina que gera o XML remove os espaços em branco, mas a rotina que gera a URL do QR-Code não faz isso.

Leandro, O que ocorre durante a compilação do programa exemplo?

Claudio, O componente ACBrNFe que é usado no ACBrMonitor Plus possui apenas uma rotina para gerar o XML. O XML é gerado com base nos valores atribuídos nos campos, que no seu caso é através da leitura do XML que você gerou. Como existem TAGs opcionais e diversas regras de negócio isso faz com que até TAGs obrigatórias não sejam geradas em função dessas regras. Para saber o que foi suprimido só comparando mesmo os 2 XML. Desculpa, mas no meu entendimento é a sua rotina que esta errada, é preciso fazer uma analise para descobrir em quais situações ela gera o que não devia ou qual a informação deva ser informada para que uma TAG ou grupo realmente seja gerado.

Claudio, Então quer dizer que você utiliza o ACBrMonitor Plus? Se sim, o comando EnviarNFe le o XML e gera novamente.

Bom dia, Na sua aplicação existe uma rotina para efetuar o cancelamento? Com certeza sim, pois bem o cancelamento é um evento e o EPEC também é. Sendo assim, você pode se basear na sua rotina de cancelamento para fazer a do EPEC.

Bom dia Claudio, Acredito que isso não seja possível. Os casos que acompanhei de TAGs sendo suprimidas do XML o motivo era que o XML esta sendo gerado por uma rotina própria do desenvolvedor e depois o XML era lido pelo ACBr para que o mesmo fosse assinado e enviado. O motivo sempre era falhas na rotina própria do desenvolvedor e não do componente. Lembre-se que o LoadFromFile possui 2 parâmetros, sendo que o segundo por padrão vale True, isso faz com que o componente gere novamente o XML e desta forma pode suprimir o que esta errado. Mas se você desejar pode passar o valor False, neste caso o componente apenas lê os dados de XML. Exemplo: LoadFromFile(sNomeXML, False)

Bom dia Hugo, Muito obrigado pela colaboração, já fiz a alteração. Baseado no Enviar síncrono e Consultar NFSe por RPS alterei os demais. Já esta disponível o novo INI para o provedor GovDigital, favor atualizar os fontes e realizar novos testes.

Tiago ao digitar a URL no navegador é solicitado a escolha do certificado? Pois aqui fiz um teste e não apareceu o erro 403.