Italo Giurizzato Junior

Robinho, Favor atualizar novamente os fontes.

Bom dia Márcio. A mensagem na verdade não é um erro e sim um alerta. Ela lhe informa que essa funcionalidade não existe para o provedor que você esta utilizando. O componente ACBrNFSe hoje atende por volta de 34 provedores dos quais 13 não implementaram em seus web services o "Consutar Situação". É por isso que na unit pnfsNFSeG retorna vazio quando se tenta executar essa função para os provedores que não possui a funcionalidade.

Bom dia Oneide, E no DANFSE onde aparece essas informações? Pois o XML tanto do RPS quanto da NFS-e não possui TAGs para esses dados.

Bom dia Robinho, Favor atualizar os fontes e testar novamente.

Bom dia Fabio, Pesquise no fórum, existe solução para o seu problema. No pacote de instalação deve-se remover da lista de requisitos o QR5D7Run se não me falha a memória. Deve-se ainda remover as propriedades que não existe no Quick Report 3.0 Para isso temos um arquivo texto junto com os fontes do ACBrCTe que ensina como remove-las. Somente um detalhe, com o Quick Report 3.0 você não vai conseguir gerar o DACTE em PDF.

Bom dia a todos, Favor atualiza os fontes e testar novamente.

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.

Robinho, Ainda estou em busca de uma solução.

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 Robinho, Eu acredito que deva ser algum Bug no Quick Report.

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.