Italo Giurizzato Junior

Bom dia Leandro, Como não tenho XML de exemplos de envio e de retorno, muito provedores não sei como é o retorno. Você poderia anexar o XML (soap) de retorno do envio da consulta para que eu possa analisar e fazer os ajustes necessários? Desde já muito obrigado pela colaboração.

Bom dia Guilherme, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-3023

Bom dia, Já inclui na minha lista de tarefas. TK-3022

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde Renato, Já está no SVN a atualização do TXT, muito obrigado.

Boa tarde João, Já está no SVN.

Boa tarde, Vou ver se consigo ainda esta semana verificar se a rotina que lê o arquivo INI contempla o GTV-e.

Bom dia Souza, Analisei a unit que gera o XML do GNRE a ser enviado, realmente não está previsto gerar com mais de 1 receita e nem vários documentos de origem. Para atender essas necessidades vai ser necessário fazer uma alteração nas classes dos campos e essa alteração vai quebrar o código de todos que usam o componente.

Joel, Já está no SVN a troca das URLs no componente novo.

Bom dia, Enviado para o SVN as untis anexadas acima.

Bom dia Joel, Muito obrigado pela contribuição, já inclui na minha lista de tarefas. TK-3019 Notei que você ainda está usando o componente antigo. Lhe convido a iniciar os testes com o novo componente de emissão de NFS-e: ACBrNFSeX O componente antigo: ACBrNFSe não está mais tendo manutenção. Faça os testes usando o programa exemplo do novo componente. Manual de Migração https://www.projetoacbr.com.br/forum/topic/63017-manual-de-migração-para-o-novo-componente-de-emissão-de-nfs-e/

Bom dia Carlos, Esse erro está ocorrendo porque no schema do provedor não está previsto esse tipo de consulta. O botão existe para contemplar outros provedores. Mas na Consulta a NFS-e Serviço Prestado está previsto a consulta por período de emissão das notas ou por período de competência. A consulta a NFS-e Serviço Tomado também está previsto.

Bom dia Gabriel, Complementando o que o Renato já lhe passou, o provedor Fiorilli tem um bug em ambiente de homologação que faz com que gere esse erro de assinatura. Faça um teste em ambiente de produção mesmo, envia um Rps no valor de 1 real e caso tenha sido processado com sucesso, você cancela ela.

Bom dia Leonard, Não encontrei nada XML que você anexou que poderia estar provocando o erro. A não ser que as tags referentes as observações mesmo não tendo informações devem ser geradas vazias. Outra coisa é a formatação dos valores, exemplo: em vez de 125.50 gerar assim: 00000125.50 Quem pode responder isso é o próprio provedor.

Bom dia Maurício, Analisando o XML 5-lista-nfse-sinc-soap.xml que é o arquivo de retorno do envio do lote, nota-se uma estrutura de tags vazias. Essa estrutura é gerada quando o webservice não retorna nada. Sendo assim, não vejo outra alternativa entrar em contato com o provedor e questionar eles. São eles que vão poder dizer se o XML de envio de lote está faltando alguma coisa ou se tem algo a mais ou se alguma informação está errada.

Bom dia João, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-3018

Bom dia, Eu sei que o GTV-e é parecido com o CT-e Normal, inclusive foi eu que fez a alteração no componente ACBrCTe visando atender o GTV-e. Como faz muito tempo que essa alteração foi feita não me recordo se a rotina responsável pela leitura do arquivo INI já contempla o GTV-e.

Bom dia, Chegou a gera o XML do Rps com a alíquota igual a zero conforme mensagem de correção? Correção.: Informe o valor da aliquota como 0 quando a empresa for imune ou isenta.

Bom dia, Esse link apresenta um exemplo do arquivo INI para o envio do evento GTV. Se faz necessário fazer o seguinte: 1. Comparar a rotina do componente ACBrCTe responsável por ler o arquivo INI o que está faltando para atender a leitura do arquivo INI referente ao documento GTV-e (que não é o evento mencionado acima); 2. Feito os devidos ajustes na rotina, incluir no manual do ACBrMonitor e do ACBrLibCTe um exemplo do arquivo INI para o documento GTV-e. 3. Por fim liberar uma nova versão do Monitor e da Lib.

Bom dia Souza, Não cheguei a ver o código do componente, mas me parece que o componente foi feito para a emissão de Guia Simples.

Boa tarde Robson, No meu entendimento o CIOT deve ser informado. Quanto o pagamento do frete do contratante pode constar já no MDF-e ou as informações sobre o pagamento serem enviadas depois através do evento especifico para esse fim.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Maurício, Configure o componente para salvar os arquivo (soap). Faça um novo teste e anexe os arquivos (soap) salvos, para que possamos analisar.

Bom dia Vanessa, Analisando o código referente a leitura de um campo do tipo data que se encontra na unit ACBrPagForLerTxt temos o seguinte: tcDat: begin if length(ConteudoCampo) > 0 then begin if ConteudoCampo <> '00000000' then begin ConteudoCampo := Copy(ConteudoCampo, 1, 2) + '/' + Copy(ConteudoCampo, 3, 2) + '/' + Copy(ConteudoCampo, 5, 4); result := EncodeDataHora(ConteudoCampo, 'DD/MM/YYYY'); end else Result := 0; end else result := 0; end; Se o conteúdo da variável "ConteudoCampo" não for vazio e diferente de "00000000" converte o conteúdo em uma data , caso contrario retorna o valor zero. Você esta com todos os fontes de todas as pastas atualizados? Não tem nenhuma unit que compõe o componente com uma bolinha vermelha em seu ícone? Caso afirmativo, delete essa unit e atualiza novamente, reinstale o ACBr e por fim faça novos testes.

Bom dia Rafael, Favor atualizar os fontes, reinstale o ACBr e faça novos testes.