Italo Giurizzato Junior

Dercide, O método Enviar se utiliza do web service EnviarLoteRps cujo modo de acesso é assíncrono, ou seja, o retorno desejado que é o XML da NFS-e demora, pois é preciso após o envio, consultar a situação do lote para saber se o mesmo já foi processado ou não se sim ai sim consultar o Lote, é nesta consulta que obtemos o XML da NFS-e caso o lote tenha sido processado com sucesso. O Lote do método Enviar pode conter de 1 até 50 RPS. Por outro lado o método Gerar se utiliza do web service GerarNFSe cujo modo de acesso é síncrono, ou seja, já temos o que desejamos logo no retorno dele que neste caso é o XML da NFS-e, logo não se faz necessário executar nenhum método de consulta. O método Gerar só pode conter apenas 1 RPS, com exceção dos provedores BHISS e WebISS (até o momento) que aceitam até 3 RPS.

Bom dia Dercide, Quem lhe passou essa informação, esta completamente por fora. O provedor BHISS não possui o serviço EnviarSincrono e sim o GerarNFSe que diferente dos demais permite enviar até 3 RPS sendo que o normal é apenas 1. Você pode comprovar isso, procurando pela palavra sincrono no Schema do respectivo provedor ou digitando a URL de homologação ou de produção no navegar e por fim procurar pelo serviço EnviarLoteRpsSincrono, não vai achar. No componente para o provedor BHISS você pode usar os métodos Enviar ou Gerar, sendo que este último como dito vai permitir um lote com até 3 RPS.

Bom dia Tiago, Se esta configurado para consultar após o envio e esta aparecendo um erro em branco é preciso "debugar", pois deveria pelo menos salvar o XML da consulta e isso não esta ocorrendo. O retorno após o envio esta correto, ou seja é retornado o numero do protocolo que atesta que o lote foi recebido com sucesso. Se o componente estiver configurado para realizar a consulta, ele deve se utilizar do numero do protocolo para consultar a situação do lote.

Boa tarde Fabrício, Exatamente.

Boa tarde, O grupo <ICMSUFDest> deve constar no XML quando a venda for interestadual para consumidor final.

Boa tarde Rodrigo, Primeiro: 6.3 - Mostre respeito pelo modo de escrever. Escreva de modo claro, gramaticalmente e semanticamente correto. Não escreva TUDO EM MAIÚSCULAS. Isso é lido como se estivesse gritando e é considerado rude. Favor leia as regras do fórum. Segundo, noto que é a sua primeira postagem, sendo assim você não sabe nada sobre o projeto ACBr. Lhe convido a pesquisar sobre esse projeto que eu e milhares de desenvolvedores utilizam. Utilizo os componentes ACBr a mais de 4 anos e todos funcionando 100% e são gratuitos. Agora se você acha que o ACBr não presta uma vez que ele é gratuito, porque se cadastrou no fórum? O que é cobrado é uma pequena taxa mensal para ser um usuário SAC e uma das vantagens é ter uma compilação semanal do ACBrMonitor Plus para aqueles desenvolvedores que não programam em Delphi.

Tiago, Configuracoes.Geral.ConsultaLoteAposEnvio := True;

Boa tarde, Para saber se o componente esta hapto a emitir NFS-e para uma determinada cidade basta procura-la no arquivo Cidades.INI As cidades em questão constam no arquivo.

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.

Valdemir, Quando o código do pais é zero o componente automaticamente altera para 1058, ou seja, Brasil. Dai o erro no seu caso que se trata de um destinatário do exterior.