Rodrigo Vian

Boa tarde Italo, Estou acompanhando junto ao Guerreiro a alteração desse provedor pra Limeira. Na página https://limeira.iibr.com.br/dev/dev_dashboard.php tem um exemplo de conteúdo de XML e um token, lá informa que a integridade resultante teria que ser 61aec2215401d0099d85d70a56d72949860ca07c55620c37b49f8f2da7cf9a671afac6c96d95bd74f9304b97cebc6a90cdf9f7134b2a5f41a12629f7d6111ba1 Acabei de atualizar os fontes e vi que a função que gera esse hash da integridade agora está gerando usando também o conteúdo do XML que é um ponto que realmente precisava pra função, mas pra teste se passar o conteúdo dado de exemplo por eles + o token ainda não gera um hash de integridade igual ao deles. Eu consegui fazer gerar certinho fazendo 3 alterações na função disponibilizada: o StringReplace passando como parâmetro isso "'/[^\x20-\x7E]+/'" não dá certo no Delphi, vi com uma pessoa que conhece PHP e isso em PHP seria pra retirar tudo o que não está dentro dessa faixa onde o x20 em hexadecimal é referente ao espaço e x7E em hexadecimal é referente ao ~ sobrando todas as letras maiusculas e minusculas os números e vários caracteres como !"#$%¨*( ) entre outros, com isso pro meu teste eu troquei esse StringReplace retirando tudo o que tem de acento que eu lembrei que é o que essa função em PHP faria segundo o que me disseram pois na faixa não tem nada acentuado, no meu teste não levei em consideração TAB por exemplo. o penúltimo parâmetro do SSL.CalcHash que está outBase64 deveria ser outHexa passei por fim um lowercase pra ficar com as letras minusculas como está o exemplo deles Devido a pressa pode ser melhorado o código mas a alteração que eu fiz está em anexo apenas com o conteúdo da função GerarIntegridade da unit ACBrNFSe, nele está comentado inclusive o conteúdo e token do teste deles, descomentando e debugando esse teste o Result vai gerar exatamente o valor que eles geraram lá na página. Dito tudo isso, da forma que testei o componente ficaria praticamente igual ao sugerido por eles, mas em teste feito nem assim o erro da integridade se resolve, mas teremos um XML com o conteúdo como deveria estar segundo o que nos foi passado. AlterFuncaoGerarIntegridade.txt

Boa tarde Aluísio, Desculpe a demora mas só vi hoje a sua mensagem que aliás vim aqui porque voltei a ter o problema mas no meu caso quando a nota tem desconto, isso porque o ISSDSF em Campo Grande não tem campo destinado para desconto e aí qualquer forma de tentar lançar o valor esse erro voltava a acontecer, no seu caso tem desconto? Ainda está com esse problema? Olá Vitor, Como disse no post acima, no seu caso tem desconto lançado na nota? Ainda está com esse erro?

Bom dia, Meses não é postado nada nesse tópico mas gostaria de saber se mais alguém não está conseguindo hoje consultar status de serviço no ambiente de homologação para SP, meu executável acusou erro então tentei com o exe demo do ACBr e o erro é o mesmo, atualizei os fontes terça agora dia 03/07. No exe demo se eu troco o estado para RS apenas para testar a consulta em homologação dá certo, mesmo para SP em ambiente produção também está funcionando, o erro ocorre com SP e homologação. Alguma configuração que tenha que estar diferente da que eu fiz? Obrigado.

Opa Italo, Sem problemas não demorou não, vou fazer os testes o quanto antes, qualquer coisa te aviso mas vai dar certo sim Vlw

Ok Italo, agradeço muito se der, pois vai me economizar um bom tempo toda vez que eu atualizar os fontes do ACBr. Muito obrigado mesmo.

Boa tarde, Pesquisei mas não encontrei nada esclarecedor, caso já exista um tópico falando a respeito me desculpem e se puder passar o link agradeço Temos um cliente que gera o arquivo XML assinado e eles importam no site da prefeitura de Natal, no nosso executável para gerar esse XML uso o método "GerarLote". Sempre que eu atualizo o ACBr, eu tenho que ir em alguns locais e comentar no fonte do ACBr os pontos que limitam em 50 RPS como sendo o máximo permitido. Sei que o que faço está totalmente errado, mas fiz isso em um momento onde tive que liberar as pressas pro cliente e de lá pra cá me habituei a sempre repassar os pontos e comentar os trechos que limitam. Hoje com um pouco mais de tempo procurei e não achei nada a respeito, mas queria saber se existe algum local que eu possa configurar para que não tenha limite de RPS. Olhando no fonte me parece que não é configurável, caso não seja mesmo, existe algum motivo para que seja planejado uma configuração desse tipo um dia? O cliente tem conhecimento do tamanho máximo em Kbytes que o arquivo pode ter. Já passei pra ele que eu poderia fazer o nosso sistema gerar vários arquivos XML de 50 em 50 RPS cada, mas ele não aceitou a ideia de ter vários XMLS gerados para transmitir, já que esse que ele gera com vários (as vezes com aproximadamente 500 RPS) a prefeitura aceita sem problemas. Não que precise mas para ilustrar, abaixo imagem da mensagem que barra o processo no cliente. Obrigado.

Ok Italo, Farei a atualização e verifico sim, muito obrigado.

Bom dia, Procurei antes de abrir esse tópico e me desculpem se já foi tratado em algum local e eu não achei. Eu estava com um problema ao tentar emitir NFS-e via webservice para uma empresa de Manaus, lá o provedor é ABACO. A mensagem de erro era "ERRO:The external object throws an exception." e em contato com o suporte da prefeitura de lá, me pediram o XML e encaminharam para análise junto a equipe de TI. A resposta deles foi que deveria ser adicionado uma letra ao id da tag LoteRps. Tentei passar a letra junto com o número do lote, mas houve erro no schema que letra não era permitida, aí a única saída que encontrei foi alterar em um ponto do fonte do ACBr para testar e funcionou, a nota foi emitida. Gostaria de saber se a alteração que eu fiz é válida para adicionar ao repositório ou se alguém sugere um local ou forma mais correta para atender essa necessidade do provedor ABACO para emissão webservice em Manaus, imagino que ter uma parâmetro que pudessem passar ou não essa letra seria o mais correto, não encontrei então para teste coloquei a letra fixa mesmo. Não desenvolvo diariamente para NFSe mas creio que o fonte não estava muito desatualizado, só sei que não estava atualizado no dia da alteração que eu fiz, segue anexada a unit e abaixo a imagem que destaca o ponto que alterei na linha 348. Obrigado. pnfsNFSeG.pas

Boa tarde Italo, Desculpe a demora, precisei me ausentar, fiz o teste usando esses arquivos ini que anexei, aparentemente está ok, estava dando erros na validação do schema mas que já corrigi as tags que faltavam preencher, agora estou no aguardo do certificado do cliente, mas testando com o certificado de outro obtive a resposta de "...Certificado apresentado nao e valido para o CNPJ informado..." então, creio estar correto. Obrigado.

Boa tarde Italo, A URL de homologação é https://homologacao.webiss.com.br/ws/nfse.asmx e a de produção eles ainda não disponibilizaram, acabei de receber a resposta. Anexei o Cidades.ini com a alteração para Aracaju usar o WebISSv2 e fiz a alteração também no WebISSv2.ini que no momento coloquei tanto na homologação quanto na produção a mesma URL, dá uma olhada por favor pra conferir se ficou correto? Cidades.ini WebISSv2.ini

Já vi que claro não é simples como coloquei na pergunta, dentro do arquivo WebISSv2.ini tem URLs para as 2 cidades habilitadas para a versão 2 do provedor WebISS. Que locais serão necessários alterar em que arquivos ou preciso passar alguns documentos por aqui?

Bom dia, Em Aracaju/SE a partir de 03/10/2017 o provedor WebISS estará recepcionando NFS-e pelo WebServices apenas na versão ABRASF 2.02. Vi que no arquivo cidades.ini já estão como provedor "WebISSv2" apenas as cidades Santa Rita do Sapucaí/MG e Niterói/RJ, para fazer testes em ambiente de homologação basta apenas trocar o provedor que para Aracaju/SE agora está WebISS para WebISSv2? Obrigado.

Pronto funcionou! Esquece a alteração que eu mencionei na unit pnfsNFSeW_ISSDSF, obvio que na grande maioria das vezes é falta de conhecimento da nossa parte aqui, é que infelizmente atrapalha quando estamos correndo contra o relógio, aí não vemos coisas que estão na bem nossa frente. Pra quem passar por esse problema a solução comigo foi, eu estava preenchendo a propriedade "Servico.Valores.ValorDeducoes" com o meu valor de dedução já calculado, era necessário também preencher o "Servico.Deducao" da seguinte forma: "with Servico.Deducao.Add do begin NumeroNFReferencia := IdentificacaoRps.Numero; DeducaoPor := dpPercentual; PercentualDeduzir:= 83; ValorTotalReferencia := cdsRegistrosVALOR.AsFloat; ValorDeduzir := cdsRegistrosVALOR.AsFloat*(83/100); end;" Problema resolvido.

Tentei fazer um teste só pra ver no que dava mas ainda não funcionou, expliquei na imagem o nó que testei mas sem sucesso. Não consigo gerar uma nota com dedução para esse provedor através do ACBr?

Quase tudo certo Italo, De fato com a alteração que eu fiz funcionou a assinatura mas é como se a dedução que eu coloquei tivesse sido zerada. A nota gerou mas sem dedução nenhuma, mexendo ali onde eu mexi o componente zera a dedução?

Boa tarde Italo, Só vou conseguir testar no cliente mais tarde, mas em ambiente de homologação parece que o erro é corrigido quando o conteúdo da assinatura desconsidera o valor de dedução. Esse cliente trabalha com 83% de dedução sobre o valor do serviço, se eu deixo zerada a dedução esse erro não ocorre, colocando valor ocorre. Notei que o conteúdo da assinatura é montada levando em conta o valor da dedução, então fui na unit pnfsNFSeW_ISSDSF e na variável sValorServico na linha 326 que abate do valor do serviço o valor de dedução eu retirei essa subtração deixando o valor cheio do serviço, e a próxima variável que é a sValorDeducao na linha 329 também forcei ir zero, assim, quando a assinatura foi formada ficou igual ao que o retorno indica como deveria ser. Teste feito, serviço no valor de R$579,03 com dedução de 83% informei como dedução R$480,59. A assinatura montada fica com o seguinte conteúdo: "00009806008NF 00000000832620170809T NN000000000009844000000000048059065201000224667503000183", em vermelho é o valor do serviço com a dedução abatida e após o valor da dedução. O erro que retorna é o que me fez abrir o tópico, o texto do erro completo é o seguinte: "Assinatura do RPS incorreta. Codigo Hash gerado para o campo assinatura do RPS esta invalido. O codigo hash '0e20f4400f26ff0b684dc98e35333e11f6538b96' gerado para o campo Assinatura do RPS nao esta valido. O campo Assinatura deveria estar com o conteudo '00009806008NF 00000000832620170809T NN000000000057903000000000000000065201000224667503000183' convertido no padrao SHA1 para o valor '19cdafeb2bee46bfaff63b74fc5bb58c0fa5889e'", em vermelho destaquei que o sugerido era que no valor do serviço não houvesse abatimento da dedução e que o valor de dedução não deveria compor a assinatura. Sabendo disso testei fazendo a alteração na unit pnfsNFSeW_ISSDSF, e a assinatura montada ficou exatamente como o retorno acusa que deveria ser. No momento vou compilar um executável com as alterações e ver se gerar nota no cliente e o valor da dedução estiver certinho confirmo pra você ver se pode corrigir e colocar em próxima atualização ok?

Boa tarde Italo, Então, realmente aquele trecho "...20170809T NN000000..." o "T" é em função do tipo de tributação e o "NN" é em função do ISS retido, fiz os seguintes testes: Enviei como tributável e ISS retido = Não, no retorno o erro veio "...00000000832620170809T NS0000000000..." Enviei como tributável e ISS retido = Sim, no retorno o erro veio"...00000000832620170809T NN0000000000..." Enviei como Não tributável e ISS retido = Não, no retorno o erro veio"...00000000832620170809N NN0000000000..." Sempre que muda se é tributável ou o ISS retido aquele trecho do erro altera, mas sempre tem esse erro. Esse cliente é tributável, pois tenho uma nota gerada no método antigo e no rodapé está que é tributável, em relação ao ISS retido o exemplo que estou testando realmente não é, então devo mesmo enviar como o teste (1). Amanha vou começar a testar alterando outras propriedades, pois essas que alterei não resolveram o problema, se eu conseguir algo eu posto aqui, se alguém tiver uma luz posta aqui que eu agradeço muito.

Bom dia Italo, Cidade de Campo Grande - MS provedor IssDSF. Estranho é que (e não sei se vem ao caso), testes que fiz dia 10/08 eu tinha um único erro sendo de tributação inválida, aí retomei os testes ontem com a tributação correta e agora apareceu esse erro, comento pois não sei se pode ter relação.

Boa tarde, Alguém passando por esse problema hoje? Estou implantando NFS-e para Campo Grande e o único erro que está retornando é esse "Assinatura do RPS incorreta. Codigo Hash gerado para o campo assinatura do RPS esta invalido. O codigo hash '0e20f4400f26ff0b684dc98e35333e11f6538b96' gerado para o campo Assinatura do RPS nao esta valido. O campo Assinatura deveria estar com o conteudo '00009806008NF 00000000832620170809T NN000000000057903000000000000000065201000224667503000183' convertido no padrao SHA1 para o valor '19cdafeb2bee46bfaff63b74fc5bb58c0fa5889e'.", o cliente usa certificado A3 e o fonte do ACBr acabei de pegar atualização caso fosse algo tratado na ultima semana e o erro persiste. Nunca emiti nota pra esse cliente usando o ACBr, estou tentando atualizar a forma de gerar pois hoje fazemos uso de uma dll do provedor. Procurando no fórum achei falando desse erro mas sem solução dentro de um tópico que não era especifico desse assunto, por isso preferi abrir tópico novo. Alguma dica do que eu poderia ver? Obrigado desde já. 13631432-lista-nfse.xml

Boa tarde ítalo, Sim, coloquei as DLLs do OpenSSL lá e já estão rodando os testes. Aparentemente está dando certo, agora estou no ponto de ajustar informações como tributação correta, entre outros, mas já está tudo correndo bem no que diz respeito ao componente e comunicação com a prefeitura. Muito obrigado até o momento.

O erro não ocorreu mais e o executável com o componente ACBr NFSe abriu no server 2012 quando coloquei a dll libeay32.dll. Aliviado pois agora vou poder começar testes nos clientes.

Vou tentar ser direto, se for necessário vou dando detalhes. Após ter erros pra rodar executável pra gerar NFS-e em servidor de um cliente fiz o seguinte teste. Gerei um executável do zero com apenas um form e nada mais, coloquei o componente ACBr NFS-e, não inseri nenhuma linha de código, bastou o componente estar no executável que é apresentado o erro "Projeto.exe parou de funcionar. Um problema fez com que o programa parasse de funcionar corretamente. Feche o programa." (imagem anexada), se o componente não estiver no executável ele abre normalmente. Esse servidor é um Windows Server 2012, ele não apresenta erro de falta de dll, mas colocando o mesmo executável em servidor de outro cliente (Windows Server 2008) são solicitados os arquivos dll necessários, com isso cada dll que a versão 2008 do Windows Server solicitava eu colocava também no Server 2012, até que o 2008 abriu o executável normalmente com o componente ACBr, mas o 2012 ainda acusa o mesmo erro. Lista de dll que coloquei para abrir no 2008. dbxfb.dll iconv.dll libxml2.dll libxmlsec.dll libxslt.dll zlib1.dll msvcr71.dll Antes de tentar executar no server 2008 eu tentei também abrir o executável na minha maquina que não tem Delphi instalado, essa última dll na minha maquina não foi necessária, mas foi solicitada no Server 2008. Então, alguém já passou por algo semelhante ou tem uma ideia de uma lista básica de dll que devem acompanhar projetos que possuem o componente ACBr NFS-e? Obs.: já tentei colocar o executável na lista de exceções do DEP. já tentei executar o programa através comando pelo DOS. já tentei executar em modo de compatibilidade e como administrador. já tentei registrar as dlls. já tentei usar executável sendo compilado em outra maquina. os fontes do SVN foram atualizados na última sexta-feira 04/08. Desde já agradeço a colaboração.

Bom dia Italo, Atualizei os fontes e copiei o arquivo ABRASFv1.ini atualizado para a pasta da minha aplicação, o XML ainda está sendo gerado vazio, não sei se fiz algo errado, em teste copiei o arquivo ini também para a pasta do programa exemplo e gerando por ele fica vazio também, anexei ambos arquivos XML tanto o que eu gerei na minha aplicação '28-lot-rps.xml' quanto o gerado pelo programa exemplo '13-lot-rps.xml', anexei também o ini que usei nos testes pra verificar se estou usando o correto. 28-lot-rps.xml 13-lot-rps.xml ABRASFv1.ini

Italo, Agora o XML está sendo gerado vazio (anexado), tentei gerar tanto com a minha aplicação quanto com o programa exemplo do ACBr. Eu estava tentando achar no fontes pra ver se facilitava pra você, mas com o telefone na orelha não consegui ir muito longe... Cheguei nesse ponto. Na unit ACBrDFeWebService linha 363 tem esse trecho >> FPDFeOwner.Gravar(ArqEnv, FPDadosMsg, '', IsUTF8); O "FPDadosMsg" está vazio, não passando conteúdo para a função Gravar no parâmetro ConteudoXML. Eu vi que esse "FPDadosMsg" é preenchido na procedure AssinarXML, coloquei um break nela e a execução não está passando lá. Não sei se ajuda isso que eu vi. 20-lot-rps.xml

Atualizado Italo, A mensagem mudou para "URL não definida para: TNFSeGerarLoteRPS.", é configuração de componente ou valor nos arquivos ini? Revisei a nossa conversa e alterei os ini atualizados conforme conversamos.