Italo Giurizzato Junior

Boa noite Jair, Você pode se basear no programa exemplo, nele foi colocado os valores padrões. Uma dica, o comando Enviar realiza os seguintes procedimentos: 1. Gera um XML para cada RPS; 2. Assina o RPS se necessário; 3. Gera o Lote; 4. Assona o Lote se necessário; 5. Valida o Lote; 6. Envia o Lote; 7. Salva (se configurado) o retorno contendo o numero do protocolo (equivalente ao numero do recibo da NF-e); 8. Consulta a Situação do Lote; 9. Salva (se configurado) o retorno contendo a situação; 10. Consulta o Lote de RPS; 11. Salva o(s) XML da(s) NFS-e. 12. Imprimie o DANFSE. Os procedimentos apartir de 8 podem ser executados separadamente, bastando atribuir o valor Fase a propriedade: ACBrNFSe.Configuracoes.WebServices.ConsultaLoteAposEnvio Desta forma é possível contornar o problema de Time Out. Como dito anteriormente muitos provedores recebem o lote mas não tem condições técnicas de processar de forma imediata. Como o componente logo em seguida inicia as consultas, e o webservice não consegue responder, acabamos tendo o erro de Time Out. Para saber os comandos dos demais procedimentos: Consultar Situação, Consultar Lote, Imprimir, favor estudar a rotina de cada botão do programa exemplo. Espero ter ajudado.

Boa noite Vanderlei, Dentro da pasta ...\Fontes\Pacotes\Delphi\ACBrNFe2 você vai encontrar o pacote de instalação que deseja. ACBrCTeDACTeQRpkg

Boa noite a todos, Sugestão implementada, favor atualziar os fontes e testar.

Boa noite Wislei, As informações de recibo que você se refere é o protocolo de autorização? Se sim, você só vai ter se você realizar a consulta. No seu caso o envio foi para o SVC e após o envio não foi retornado o protocolo de autorização?

Bom dia Dennis, Por favor, post como anexo a unit corrigida.

Bom dia Moacir, Tente desta forma: Apenas remova os requisitos que não existem no XE2 e depois compila o componente com a opção Build, é para ele acrescentar ou solicitar a autorização para acrescentar os requisitos faltantes.

Bom dia, Favor atualizar os schemas e os fontes do ACBrMDFe. O seu xml contem a tag <veicTracao> sendo que agora é <veicPrincipal>.

Boam dia, O componente ACBrCTe não tem essa funcionalidade.

Bom dia Léo, Desculpa pela demora. Favor atualizar os fontes e testar.

Bom dia Cleber, Não tenho, mas você pode se basear no que foi feito para a NF-e.

Boa noite Jair, Esse é um problema presente em vários provedores, eles não conseguem dar conta de processar tudo o que chega. Tem provedor que retorna o XML da NFS-e de um RPS enviado, depois de algumas horas.

Bom dia Cleber, A CC-e para o CT-e vai estar disponivel quando sair a versão 2.0 do CT-e, a previsão é para o final do ano. Precisamos de voluntário para criar as units para imprimir a CC-e, algo semenhante que foi feito para a NF-e.

Bom dia Gustavo, Sim, desde que a chave dessa segunda via do XML seja exatamente igual, caso contrario você não vai conseguir realizar a consulta.

Bom dia Luciano, Vou realizar um teste em casa, pois lá tenho duas maquinas, uma com o Quick Report versão 3.0 e a outra com a 5.0.2 Vou checar a visualização e a impressão nas duas maquinas, depois reporto os resultados. Se não me falha a memória alguns colegas tiveram problemas parecidos e só foi resolvido com a atualização do Adolbe.

Bom dia Volmir, O componente ACBrCTeDACTEQRRetrato possui a propriedade MostrarPreview, se você atribuir o valor True ao executar o comando Imprimir o DACTE vai ser apresentado na Tela, posteriormente poderá ser impresso se assim desejar. Note que estou me referindo ao DACTE feito em Quick Report e a visualização tem que ser um a um, não descobri ainda uma forma de carregar o componente com dois ou mais CT-e e visualizar todos os DACTEs.

Bom dia Ricardo, O comando LoadFromFile do componente é capaz de carregar tanto o XML do RPS quando da NFS-e. Após carregar é só mandar imprimir, mas algumas informações não vão aparecer, como por exemplo o numero da NFS-e. O interessante seria ter um lay-out de um RPS, e um comando especifico para imprimir o RPS.

Bom dia, Eu também não entendi muito bem o motivo de ser necessário realizar a consulta varias vezes para começar ter um retorno, mas existem relatos no fórum de colegas que chegaram a realizar quase 100 consultas para obter os primeiros retornos. Na minha opinião a SEFAZ precisa rever isso, pois ficar realizando "N" consultas demanda muitos acessos ao WebService. Hoje são poucos que realizam a manifestação do destinatário, mas quando se tornar obrigatório para todos e esse dia vai chegar a coisa vai ficar feia.

Boa noite Volmir, Sim, basta você seguir os seguintes passos: 1. Alimentar o componente com os dados; 2. Executar o comando Assinar; 3. Executar o comando Imprimir, lembrar de habilitar a opção para visualizar.

Boa noite, Você esta atribuindo algum valor para a propriedade cCT ao alimentar o componente? Porque você esta executando o enviar 2 vezes? //Aqui eu envio CT-e ACBrCTe1.WebServices.Envia(StrToInt(vNumLote)); ACBrCTe1.Enviar(StrToInt(vNumLote), False); basta apenas: //Aqui eu envio CT-e ACBrCTe1.Enviar(StrToInt(vNumLote), False); Uma outra informação o comando acima "Enviar" se encarrega de Assinar, Validar e salvar o XML em disco, alem é claro de envia-lo para SEFAZ.

Boa noite a todos, Por favor verifiquem se a propriedade Zoom é 100 em ambas as units: ACBrCTeDACTeQR ACBrCTeDACTeQRRetrato

Boa tarde, O GravaUltimaConsulta, simplismente salva em uma tabela do banco de dados o valor de NSU. Se você voltar a pesquisar no fórum sobre o assunto, você vai descobrir que existem relatos de alguns colegas que checou a realizar centenas de consultas sempre utilizando o último NSU retornado para que aparecessem as primeiras Notas.

Fabio, Na minha maquina tenho dois: midas.dll e midas.jdbg Não sei se os dois são necessários mas por via das duvidas eu coloco os dois.

Bom dia Osmar, Os erros retornados são: <ListaMensagemRetorno> - <MensagemRetorno> <Codigo>E259</Codigo> <Mensagem>CNPJ/CPF nao encontrado na base de dados. : 668584000178</Mensagem> <Correcao>Confira o numero do CNPJ/CPF informado. Caso esteja correto, o prestador do servico nao esta inscrito no municipio.</Correcao> </MensagemRetorno> - <MensagemRetorno> <Codigo>E43</Codigo> <Mensagem>Inscricao Municipal do prestador do servico nao encontrada na base de dados do municipio.</Mensagem> <Correcao>Nao existe registro de inscricao municipal que corresponda ao numero informado.</Correcao> </MensagemRetorno> - <MensagemRetorno> <Codigo>A9</Codigo> <Mensagem>Inscricao municipal incorreta.</Mensagem> <Correcao>A NFS-e foi gerada considerando a inscricao municipal vinculada ao CNPJ/CPF informado.</Correcao> </MensagemRetorno> </ListaMensagemRetorno> Para mim as mensagens dos erros estão claras: o prestador do serviço não esta cadastrado para utilizar o webservice para emitir a NFS-e, alem da Inscrição Municipal esta incorreta.

Bom dia Fabio, Você salvou dentro da pasta do executável no cliente os arquivos que mencionei no post anterior.

Bom dia Leandro, Os arquivos cujos nomes terminam com "-c" contem o tal do Envelope SOAP que eles querem. Se esses arquivos não estão sendo salvos, favor colocar True na propriedade: WebServices.Salvar