italo.giurizzato.junior

Bom dia Oneide, Note que no XML do RPS que é o que você envia consta o seguinte: <IssRetido>2</IssRetido> <ValorIss>10.00</ValorIss> O valor 2 na tag IssRetido significa que não existe ISS retido e depois você informa o valor do ISS retido, no caso R$ 10,00. O webservice ao gerar o XML da NFS-e altera o 10.00 por 0 pois foi dito que não tem ISS retino. Agora se realmente tem o ISS retido e o seu valor é R$ 10,00, então você deve informar "1" em IssRetido ou seja atribuir o valor snSim a propriedade IssRetido.

Bom dia Gilbero, Alteração realizada e disponibilizada, favor atualizar os fontes e testar novamente.

Bom dia lvr, Favor atualizar os fontes e testar. Quando a Data do Serviço, vou verificar.

Bom dia Caetano, Com relação ao "1" que aparece com sendo o numero da NFS-e substituida, já esta disponivel, favor atualizar os fontes e testar.

Bom dia Tradeone, Realizando testes de inutilização de numeração ontem a noite detectei um erro no componente, favor atualizar os fontes e realizar os testes. Pode ser que com essa correção que fiz, resolva o seu problema.

Bom dia a todos, Ontem a noite testei a inutilização de numeração do CT-e versão 2.00, como não sou perfeito, não funcionou de primeira. Depois de queimar alguns neuronios, descobri onde estava o erro. Solução implementada, teste refeito, ufa agora sim funcionou. As correções já encontram-se disponiveis, favor atualizar os fontes, pois o erro pode afetar também a versão 1.04 Pretendo até o final deste mês realizar mais testes. Vou postar aqui os resultados. Testes efetuados até o momento: * Consultar Status - OK * Envio - OK * Consultar Recibo - OK * Consultar Situação Atual do CT-e - OK * Cancelamento por evento - OK * Inutilização de numeração - OK

Bom dia Liandro, Por favor post como anexo o XML da NFS-e para que eu possa analisar.

Bom dia Gilberto, Favor atualizar os fontes e testar.

Bom dia lvr, Muito obrigado pela correção, favor atualizar os fontes e testar.

Boa tarde Liandro, Favor atualizar os fontes e verifique se a versão agora é 5844.

Caetano, O você postou o XML do RPS, eu preciso do XML da NFS-e.

Boa tarde João, Estou trabalhando para resolver esse problema. Enquanto isso peço para que você mude a impressão do canhoto de "Cabeçalho" para "Rodape" no componente ACBrCTeDACTeQR temos a propriedade: PosRecibo cujo valor padrão é prCabecalho, altere para prRodape. Isso vai resolver o problema do total de paginas. Isso só acontece pelo que pude notar quando a impressão do canhoto é no cabeçalho e o CT-e é emitido como sendo carga lotação. Quando é carga fracionada podemos colocar o canhoto em qualquer posição que não ocorre o problema.

Boa tarde Caetano, Se você postar ou enviar para mim por e-mail um XML de uma NFS-e que ocorre o problema fica mais facil de encontrar uma solução.

Boa tarde Marcio, Se a homologação que você se refere é de Hard e Software a resposta é não. Uma das premicias da NFC-e é não existir homologação de nada. Você desenvolve o Software e utiliza uma impressora de bobina não fiscal para imprimir o DANFE da NFC-e. Porque não há necessidade de homologar nada? Simples, que diz que o DANFE impresso é valido juridicamente é a SEFAZ que recebeu o XML assinado e retornou o protocolo de uso. E como o DANFE é apenas uma imagem grafica do XML, logo se o mesmo esta autorizado pela SEFAZ o DANFE é valido, desde que contenha a chave para que o consumidor possa realizar a consulta, sem falar do QR-Code que é outro mecanismo de consulta e que vai confirmar ou não a autenticidade do DANFE.

Boa tarde Thiago, Quando o nome do tomador tive o caracter "&" simplesmente mude para "E". O componente já faz o tratamento, mas se o webservice não consegue interpretar corretamente o "&amp;" não resolve nada.

Boa tarde Caetano, Essa resposta alem de confrmar que a funcionalidade de Substituição não esta presente em todos os provedores, deixa claro que o gerador de NFS-e do webservices deles esta com falha e gerando uma informação que não existe. E que você tem que alterar o seu sistema para que o mesmo ignore esse lixo, pois eles não estão com a menor vontade de corrigir um problema que é deles e não nosso. Só que estamos falando de um componente que foi criado para atender dezenas de provedores e não somente o deles. E ai qual a sua sugestão, fazer a vontade deles, ou abarrotar o telefone deles com reclamações?

Bom dia Jonathan, Post como anexo o XML do RPS enviado ou melhor do lote enviado, pois o erro retornado se refere ao XML do RPS enviado no lote que esta com problema.

Bom dia Elvis, Você tem como postar como anexo o XML do conhecimento de numero 44 que é que foi rejeitado?

Bom dia Caetano, Eu acredito que o problema esta no webservice que esta gerando essa informação. Se todas as NFS-e que você emite vem que ela substituiu a de numero 1 algo esta errado. Uma vez que o componente não possui a funcionalidade de substituição. Vamos aos conceitos: Cancelar e substituir: Você emite a NFS-e para variar antes de realizar o serviço e depois o cliente desiste, neste caso você efetua o cancelamento. Você emite a NFS-e, o cliente ou você detecta um dado errado, você efetua o cancelamento da NFS-e emitida e emite outra, temos ai uma substituição. Alguns provedores possui um webservice para agilizar esse processo, ou seja você emiti a NFS-e de numero 30 e informa no XML que esta substuituindo a de numero 29 por exemplo, só que você não utiliza neste caso o webservice normal para emitir NFS-e e sim o de substituição. Pois este webservice se encarrega de efetuar automaticamente o cancelamento da NFS-e de numero 29. Mas essa funcionalidade não foi implementada no componente, uma vez que não são todos os provedores que dispõe desse webservice. Portanto isso me leva a crer que trata-se de um problema no provedor. Para confirmar isso, basta olhar para o arquivo do RPS que é gerado, verifique se tem alguma TAG que faz referencia a substituição de NFS-e.

Bom dia Tora Transportes, Como a cidade de Betim realmente vai passar a utilizar o provedor Ginfes, devemos apenas agora aguardar a data de inicio. Para que possamos efetuar a alteração.

Bom dia Udenilson, Depois que ocorre o envio do lote de RPS para o webservice temos como resultado final o XML da NFSe exatamente como foi gerado pelo webservice. O componente salva automaticamente esse XML a principio dentro da pasta NFSe. Você chega a carregar esse arquivo com o LoadFromFile e depois salva ele novamente na mesma pasta ou em outra? Se sim, tai o problema. O LoadFormFile remove os prefixos para ajudar na leitura das tags e armazena o XML sem os prefixos em uma propriedade chamada XML_NFSe. Se você depois salva o conteudo dessa propriedade temos como resultado final o XML da NFS-e sem os prefixos. Por favor verifique se não é isso que esta ocorrendo com a sua aplicação. Depois de obter o a NFS-e o XML é lido com o LoadFromFile e salvo novamente.

Bom dia Rodrigo, Até onde sei, a empresa pode utilizar o mesmo certificado usado para assinar a NF-e quando for emitir a NFS-e.

Boa tarde Caetano, Post como anexo o XML da respectiva NFS-e, sem ele fica dificil saber o que esta ocorrendo.

Boa tarde, Tenta fazer isso: Abra o fonte ACBrNFSeDANFSeQR depois abra o ACBrNFSeDANFSeQRRetratoCampinas. Remova de uses as seguintes units: qrFramelines e grimgctrl. Salva e fecha os arquivos. Abra a aplicação que utiliza os componentes e compila com a opção Build.

Boa tarde, Você esta com todos os fontes de todas as pastas atualizados? Você incluiu no Library Path do Delphi o caminho onde esta os fontes do componente ACBrNFSe?