Italo Giurizzato Junior

Entendi, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia, Neste caso você pode aumentar o valor da propriedade Timeout.

Vamos ver se eu entendi, Dependendo da cidade que se utiliza desse provedor, não se faz necessário informar o endereço do tomar, pois o provedor vai utilizar os dados que a prefeitura informar. É isso?

Bom dia Joelcio, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia simons, Em vez de criar esse novo campo, não poderia checar o conteúdo do campo logradouro? Se este campo não for vazio a tag <endereço_informando> recebe o valor "S" caso contrario recebe o valor "N".

Bom dia Joelcio, Favor anexar a unit alterada para que possamos analisar e estando tudo OK vamos enviar para o repositório.

Bom dia a todos, Vou fechar este tópico pois ele já possui 4 paginas, por favor criem novos tópicos para assuntos novos. Obrigado pela compreensão de todos.

Bom dia, Procurou por essa cidade no arquivo Cidades.ini? Se ela não consta, não tem como emitir. Neste caso se faz necessário descobrir qual é a empresa (provedor) contratada pela prefeitura. Sabendo qual é o provedor, é preciso saber se o componente ACBrNFSe já possui ele implementado, se sim basta acrescentar a cidade em questão no arquivo Cidades.ini aos moldes das demais cidades que são atendidas pelo mesmo provedor. Talvez seja necessário também incluir as URLs de homologação e produção dessa cidade no arquivo INI do provedor. Agora se o provedor não esta implementado no componente, você vai ter que ir em busca de mais informações.

Roberto, Tente da seguinte forma: Em ACBrNFSeConfiguracoes, faça a seguinte alteração (incluir a linha em negrito): FConfigGeral.QuebradeLinha := trim(FPIniParams.ReadString('Geral', 'QuebradeLinha', '')); if FConfigGeral.QuebradeLinha = 'ENTER' then FConfigGeral.QuebradeLinha := #13#10; Em pnfsNFSeW_ABRASFv1, faça a seguinte alteração (incluir o valor False que esta em negrito): Gerador.wCampoNFSe(tcStr, '#32', 'Discriminacao', 01, 2000, 1, StringReplace(FNFSe.Servico.Discriminacao, ';', FQuebradeLinha, [rfReplaceAll, rfIgnoreCase] ), DSC_DISCR, False); Esse parâmetro acrescentado no final faz com que o ParseTextoXML seja false e com isso o FltrarTextoXML não seja executado, desta forma os caracteres #13#10 não serão removidos da tag <Discriminacao>. Bom, acredito que agora vai resolver o problema da quebra de linha no campo desejado. Se funcionar o XML do RPS tem que ficar com a quebra de linha como você deseja. Ai o próximo passo é encontrar uma solução no que diz respeito a assinatura, que acaba removendo a quebra de linha.

Bom dia Roberto, Assim que eu gosto, pessoas que estudam os fontes dos componentes. Então precisamos procurar a melhor solução para esse problema.

Bom dia, Será necessário fazer uma alteração no DACTE feito em Fortes Report. Não é difícil, você quer colaborar em fazer essa alteração?

Bom dia Sandro, Sim, mas precisamos de mais material, tais como os schemas de validação, XML de exemplos, ... E contamos com a colaboração de todos.

Bom dia Paulo, Muito obrigado pela colaboração, ainda hoje vou analisar e estando tudo correto vou enviar para o repositório.

Bom dia, Favor atualizar os fontes e faça novos testes. Esse erro em "branco" é porque o componente não conseguiu ler corretamente o retorno.

Bom dia Roberto, Se no arquivo RJ.ini tivermos: QuebradeLinha=#13#10 E ao alimentar o componente mais precisamente o campo Discriminação informarmos: Serviço 1;Serviço 2;;Serviço 3 (por exemplo). Ao gerar o XML teremos: Serviço 1#13#10Serviço 2#13#10#13#10Serviço 3 Mantendo a linha: Gerador.wCampoNFSe(tcStr, '#32', 'Discriminacao', 01, 2000, 1, StringReplace(FNFSe.Servico.Discriminacao, ';', FQuebradeLinha, [rfReplaceAll, rfIgnoreCase] ), DSC_DISCR); Pois esta realiza a troca do ";" ponto e virgula pelo conteúdo do campo QuebradeLinha definido no arquivo INI. O problema agora é com a remoção dos caracteres #13#10 realizado pela rotina que faz a assinatura.

Bom dia, O erro: Falha ao localizar o nó de Assinatura só ocorre quando executamos a aplicação através do Delphi, neste caso basta clicar no botão Continuar.

Bom dia Rubens, O Capicom só funciona se o Identificador foi Id (com o i maiúsculo) no caso de Salvador é id (tudo minúsculo). Neste caso para não ocorrer esse erro, no arquivo INI temos que alterar para zero o valor de URI, mas mesmo assim vai continuar acusando que o Hash esta errado ou inválido.

Para o provedor Saatri tente o seguinte: 1. no programa exemplo aba WebServices temos 3 campos logo abaixo do quadro Proxy, são eles: Senha, Usuário e Frase Secreta. Informe a senha e o usuário criado para essa empresa emitir notas. 2. na aba certificado no campo SSL Lib coloque o valor libCapicomDelphiSoap. Refaça os testes.

Bom dia Diego, O erro: Falha ao localizar o nó de assinatura é normal uma vez que você esta executando a aplicação através do Delphi, basta clicar no botão continuar. Já o erro de falha de validação é preciso saber o que de errado no XML, tag faltando, tag com nome errado, tag fora do lugar ou valor da tag incorreto.

Bom dia Rafael, Compare o seu XML com este: 1718060455011000018856000000000000027-rps.xml

Se o provedor segue a versão 2 do layout da ABRASF você pode testar os 3 botões: [Enviar Lote Rps (Enviar)], [Enviar um Rps (Gerar)] e [Enviar Lote Rps (EnviarSincrono)]. Agora se o provedor segue a versão 1, só podemos usar o primeiro: [Enviar Lote Rps (Enviar)].

Bom dia Rafael, Você esta com todos os fontes de todas as pastas atualizados?

Bom dia Kartter, O que você acha de abrir o arquivo Abaco.ini e dar uma olhada na seção [Assinar]? ; 0 = False / 1 = True (se True então assina) [Assinar] RPS=0 Lote=1 Isso responde a sua pergunta?

Bom dia, Tenho uma lista com 81 provedores, dos quais 28 seguem a versão 1 do layout da ABRASF, 40 seguem a versão 2 e 13 tem o seu próprio layout. Os provedores que seguem a versão 1 do layout da ABRASF não possuem os serviços: Gerar, EnviarSincrono e Substituição. Já os que seguem a versão 2 tem todos os serviços exceto o de ConsultaSituacao. A priori, mas pode acontecer do provedor não disponibilizar algum serviço como por exemplo o Cancelar, neste caso para efetuar o cancelamento de uma nota é preciso entrar em contato com a prefeitura ou efetuar o seu cancelamento via site. Para saber quais serviços disponíveis é preciso abrir o arquivo INI do provedor em questão e verificar quais serviços esta definido a estrutura do envelope utilizado para o envio do XML para o webservice. Os erros de "SoapAction não definido" é uma prova que o respectivo serviço não existe para o provedor em questão. Idem para a mensagem de erro onde mostra o serviço e a mensagem "não implementado". Quanto a mensagem de erro http 500, qual consulta você tentou executar? Pois o componente possui 4 métodos de consulta: ConsultarSituacao, ConsultarLoteRps, ConsultarNFSePorRps e ConsultarNFSe. No caso do provedor Saatri que se utiliza a versão 2 do layout da ABRASF não devemos utilizar o método ConsultarSituacao pelo simples fato desse método não existir na versão 2.

Bom dia Roberto, A intensão de ter no XML os caracteres #13#10 é para que ao abrir o XML através de um navegador o conteúdo das tags: Discriminacao e Descricao sejam apresentados com quebra de linha? Ou se não fizer isso na impressão do DANFSE não sai com a quebra de linha? Se é na impressão então devemos fazer as devidas correções neste e não na geração do XML.