Italo Giurizzato Junior

Bom dia, Não esta implementado, esse provedor segue o padrão abrasf, quais são as cidades atendidas por ele?

Rafael, Ao postar ocorreu um erro e não foi toda a mensagem. Vamos lá: O grupo PrestadorServico faz parte do XML da NFS-e que é retornado pelo Web Services, logo você não preenche. Se não esta sendo impresso o Telefone, é porque no cadastro do prestador de serviço "no Web Service" não consta essa informação. Lembre-se você gera o XML do RPS e não da NFS-e. E no RPS só consta a identificação do prestador, ou seja: Prestador.Cnpj := edtEmitCNPJ.Text; Prestador.InscricaoMunicipal := edtEmitIM.Text; // Para o provedor ISSDigital deve-se informar também: Prestador.Senha := 'senha'; Prestador.FraseSecreta := 'frase secreta'; Prestador.cUF := 33; // código da UF do prestador Você esta tentando alimentar propriedades do componentes que na verdade são alimentadas ao ler o XML da NFS-e. Se possível poste como anexo o XML da NFS-e.

Bom dia Rafael, Acho que você não entendeu. O grupo PrestadorServico faz parte do XML%

Boa tarde Rafael, A NFS-e é totalmente diferente da NF-e. Na NF-e, você gera o XML, assina e obtem da SEFAZ o protocolo de Autorização. Na NFS-e, você gera o XML do RPS, assina e obtem como retorno o XML da NFS-e. No RPS é gerado o grupo Prestador, no XML da NFS-e temos o grupo PrestadorServico.

Caio, O XML a ser enviado é exatamente desse jeito, sem a tag protNFe. Quando retorna o resultado do processamento se foi autorizado o componente inclui essa tag no XML deixando-o com validade juridica. Uma vez que o XML só é aceito como sendo um documento valido juridicamente quando o mesmo possui os dados pertinentes a venda, a assinatura digital do emitente e o protocolo de autorização da SEFAZ. Se o seu XML esta sem o protocolo e já foi enviado, basta realizar uma consulta, pesquise no forum que você vai achar como fazer isso. Basicamente, basta carregar o componente com o XML e executar o comando Consultar. Detalhe importante verifique se as 2 propriedades Salvar do componente estão com o valor True.

Caio, Esse XML não contem a tag que esta faltando a versão, por favor poste o que esta apresentando problema, o XML que você postou só esta assinado.

Boa tarte Caio, Poste como anexo o XML. E aproveitando, você esta com todos os fontes de todos os componentes atualizados?

Boa tarde Walter, mude para: NF:= StrToIntDef(FrmPrincipal.ACBrNFSe1.NotasFiscais.Items[0].NFSe.Numero, 0); RPS:= StrToIntDef(FrmPrincipal.ACBrNFSe1.NotasFiscais.Items[0].NFSe.IdentificacaoRps.Numero, 0); Em um desses dois o numero não deve estar sendo retornado, ficando a string vazia provocando o erro de conversão. Desta forma não vai dar erro mas você vai descobrir qual é a informação que não esta sendo retornada, uma vez que não existe numero de nota e numero de RPS igual a zero.

Bom dia João, Quero lembra-lo que os schemas *_v3.00 no primeiro momento só são utilizados na geração da NFC-e. A NF-e continua a tulizar os schemas da versão 2.00 Vou verificar a function Envia que você utiliza. A idéia é exatamente essa vazer com que a migração de versões sejam a menos traumatica possivel. Foi pensando nisso que não quiz criar um novo componente exclusivo para a versão 3. Caso detecte mais alguma coisa por favor poste o problema e se possível a correção. Fico feliz que esta funcionando.

Bom dia Juliomar, Acabo de disponibilizar diversas alterações que realizei em quase todos os fontes do componente ACBrNFSe, para implementar uma nova função: EnviarSincrono. Não terminei a implementação, logo não é possível utiliza-la. A utilização dessa opção de envio vai depender do provedor ter implementado ou não essa funcionalidade em seu Web Services. Adianto um dos que tem: IssDigital. Espero que os nossos amigos que estão trabalhando para fazer com que o componente funcione com a cidade de Juiz de Fora, postem no fórum os fontes alterados e onde foram feitas as alterações. Desta forma podemos fazer um merge e disponibilizar para toda a comunidade.

Michel, Muito obrigado, Linhas incluidas, fonte já disponivel para baixar.

Desculpa, Já esta atualizado.

Boa tarde Gabriel, Os seus clientes pertencem aos Estados que fazem parte do projeto piloto? Se sim, é melhor ficar com um pé em cada barco.

Boa tarde Nazareno Neto, As URLs dos Web Services estão fixas nos fontes do componente, não são parametrizaveis. Ou você espera, ou você altera a Unit que contem as URLs e compila a sua aplicação como sendo uma nova versão a ser usada depois de uma determinada data.

Boa tarde Michel, Na Unit ACBrNFSeWebServices qual foi a alteração que você realizou?

Sim, O recibo, não pois ele não faz parte do XML do CT-e, mas o protocolo sim, desde que o XML esteja protocolado. sProtocolo := ACBrCTe.Conhecimentos.Items[0].CTe.procCTe.nProt;

Bruno, Tente usando a propriedade RetWS ela contem o retorno do Web Services já tratado.

Boa tarde Galegobr, Porque não postar aqui no fórum? O que poderia ser a solução não só para o nosso amigo Markapollo e sim para todos que estão passando ou vão passar por esse problema.

Boa tarde Bruno, Depois que o XML do CT-e é gerado, independente se ele foi enviado ou não, você pode obter a chave da seguinte forma: sChave := Copy(ACBrCTe.Conhecimentos.Items[0].CTe.inFCTe.ID,4,44); Caso o componente tenha mais de 1 conhecimento adicionado basta variar o indice do items[X], 0, 1, 2, ... ********************************** A principio o XML é gerado e assinado, correto? Se ocorrer algum problema e o XML ficar sem o protocolo de autorização, basta realizar a consulta como já mostrada nesse tópico. Carrega-se para o componente o XML do CTe em questão, executa-se o Consultar, zera o componente com o Clear e carrega novamente o XML desta forma você vai poder ter acesso ao numero do protocolo, status, data e hora da autorização, bem como imprimir o DACTE com o protocolo.

Boa tarde, Cidade Incluida.

Poste como anexo o XML que ficou sem a chave.

Thaine, Como dito anteriormente a Chave é o componente que gera, ela não é retornada pela SEFAZ. O que a SEFAZ retorna é o recibo de entrega do lote e depois que o CT-e é autorizado, é retornado o numero do protocolo. Você só envia novamente quando ocorre uma rejeição, digamos por erro, por exemplo, rejeitado por estar faltando os dados da seguradora. Neste caso basta fazer a correção e enviar novamente. Agora Rejeitar por uso indevido, não significa que existe erro, a SEFAZ recebeu o lote e vai processar, mas você deve aguardar alguns minutos. Esse tipo de rejeição ocorre porque esta ocorrendo muitas chamadas ao webservice em curto espaço de tempo, principalmente no webservice do status de serviço. No caso de rejeição por uso indevido, você faz da forma que eu já lhe mostrei, ou seja realizando uma consulta (vejas os postes anteriores).

Boa tarde Thaine, A chave que você se refere é a chave de 44 digitos? Se sim, esta é gerada pelo componente, ela faz parte do XML que é gerado e enviado para SEFAZ.

Bom dia Thaine, Simples, quando isso acontece, primeiro você tenta realizar uma consulta, se você obter o protocolo de autorizãção, isso significa que o envio foi realizado e o lote foi processado com sucesso. Caso contrario você envia novamente. Como realizar essa consulta: // Carrega no Componente o CTe salvo em Arquivo XML ACBrCTe.Conhecimentos.Clear; ACBrCTe.Conhecimentos.LoadFromFile(NomeArquivo); ACBrCTe.Consultar; ACBrCTe.Conhecimentos.Clear; ACBrCTe.Conhecimentos.LoadFromFile(NomeArquivo); Status := ACBrCTe.Conhecimentos.Items[0].CTe.procCTe.cStat; sProtocolo := ACBrCTe.Conhecimentos.Items[0].CTe.procCTe.nProt; // Status é uma variável Integer e sProtocolo é String Se Status = 100 significa que ocorreu o envio e foi processado com sucesso e o CT-e esta autorizado. Espero ter ajudado

Bom dia Helderlr, Vou dar uma olhada com calma, neles.