Rodrigo Crovador

Diferente do restante, esta propriedade do retorno não é tratada e permanece em UTF8, ou seja, o desenvolvedor tem que trata-la em sua aplicação: Acho (bem no achismo mesmo) que esse foi o motivo de terem adicionado a decodificação em algum momento. Se for esse o caso, tratar apenas este ponto seria um caminho de atender ambos. Aqui no meu caso não utilizo, mas fica a quem precisar.

@EMBarbosa @Daniel Simoes @Diogo Loff Acredito que o problema tem ocorrido especificamente com o unit do provedor nacional. Especificamente no tratamento do retorno da consulta da NFSE por chave, o retorno está sendo convertido propositalmente logo após a descompressão, o que aparentemente "mata" o String binário do AnsiString e compromete o UTF8. if NFSeXml <> '' then NFSeXml := DecodeToString(DeCompress(DecodeBase64(NFSeXml)), true); Este é o único método dessa maneira. os demais não fazem a conversão (Emitir é um exemplo, a linha está comentada): if NFSeXml <> '' then begin // NFSeXml := DecodeToString(DeCompress(DecodeBase64(NFSeXml)), True); NFSeXml := DeCompress(DecodeBase64(NFSeXml)); LerNFSe(NFSeXml); end; Aqui tenho usado sem a conversão e tem funcionado sem problemas. O pessoal comenta que "estraga" os acentos, mas isso é apenas no DEBUG da IDE: as propriedades do compoenente carregam os valores devidamente codificados e os métodos "Salvar" também geram arquivos corretos. Se há um ponto que talvez necessite deste tratamento, seria no XML do respose (não apliquei na unit em anexo): Response.XmlRetorno := DecodeToString(NFSeXml); Poderiam validar isso? PadraoNacional.Provider.pas

Depende um pouco do que se refere como XML puro. Se for o retorno do ambiente nacional, ele é puramente em UTF8. Se a IDE não tiver suporte a UTF8 no debug, ela fará a conversão para o formado suportado para exibir, mas somente no debug da IDE. Os arquivos gerados pelo componente ficam com a acentuação correta pois é feito o tratamento antes de salvar o XML ou carregar os valores.

Notei que na unit PadraoNacional.Provider, procedure TratarRetornoConsultaNFSeporChave foi adicionado o seguinte: if NFSeXml <> '' then NFSeXml := DecodeToString(DeCompress(DecodeBase64(NFSeXml)), true); O DecodeToString está mudando o encode, saindo do UTF8, o que gera o erro indicado no tópico. Se mantido assim: NFSeXml := DeCompress(DecodeBase64(NFSeXml)); O erro não ocorre mais. Visualmente na IDE o texto do XML fica "parecendo que está com erros de acentuação", mas tanto o XML salvo quanto o valor das propriedades ao carregar o XML ficam na formatação correta. A duvida seria o motivo do DecodeToString ter sido adicionado neste ponto.

Tive um problema semelhante com um provedor que utiliza o padrão nacional. O que identifiquei na época é que a função Decompress da unit ACBrCompress retorna o conteúdo do XML em Ansi, o que pode comprometer a conversão para UTF8 posteriormente: function DeCompress(const ABinaryString: AnsiString): AnsiString; var MS: TMemoryStream; begin MS := TMemoryStream.Create; try WriteStrToStream(MS, ABinaryString); MS.Position := 0; Result := DeCompress(MS); finally MS.Free; end; end; A solução que adotei foi mudar o retorno desta função para WideString e adaptar as demais responsáveis pela conversão para WideString também. (DecodeToString e UTF8ToNativeString, ambas da ACBRUtils.Strings). Desta maneira não tive mais problemas com a conversão (Delphi 10.3). Não sei o impacto quanto as demais versões. Talvez atenda a situação com um impacto menor.

Boa tarde Italo. Segue o arquivo atualizado com os endereços de Itatiba/SP. No caso do schema, realmente foi necessário alterar o schema para HTTP. Caso contrário haverá recusa do webservice de produção com a mensagem a seguir: Código Erro : E160 Mensagem... : Arquivo em desacordo com o XML Schema.; Informacoes personalizadas: Nao foi possivel deserializar o xml de dados. Correção... : Consulte o Manual da NFS-e para saber quais sao as versoes de XML Schema suportadas pelo sistema. Mudar apenas o Cidades.ini não seria suficiente pois os schemas são HTTP, mas o endereço do webservice é HTTPS. Seria muito mais fácil se o provedor alterasse a validação interna do servidor para HTTPS, mas até eles terem essa iniciativa, foi a única maneira de transmitir o arquivo com sucesso. Depois que abri o chamado no suporte do provedor sobre o assunto, eles atualizaram o XSD que existia para download com o endereço HTTP. fintelISS.ini

Boa tarde! Depois de todo esse tempo finalmente consegui homologar com sucesso a cidade de Paracambi - RJ. Para tal foi necessário mais alguns ajustes e flexibilizações no componente para atender o provedor. Segue as modificações: ACBrNFSeConfiguracoes.pas Linha 687 e 728: Além dos arquivos de XSD diferentes por cidade, o provedor também utiliza namespace diferentes para cada uma delas, alternando até o endereço de HTTPS para HTTP em alguns casos. A única maneira de tratar foi replicar a técnica de criar parâmetros com o código da cidade no arquivo. Com a mudança, os parâmetros (Namespace) Produção, (Namespace) Homologacao e (XML) NameSpace também reconhecem o sufixo "_CodIBGE". ACBrNFSeWebServices.pas Linha 1767: Adicionado o FintelISS ao case, pois a assinatura do RPS é feita com o namespace na TAG <Rps>. Se remove-lo, invalida a assinatura. pnfsNFSeW_ABRASFv2.pas Linha 356, 479 e 503: Limpeza, FintelISS não utiliza a procedure "GerarServicoValores". 677: Os campos "DescontoIncondicionado" e "DescontoCondicionado" não existem no XSD do provedor. 723 a 727: Os campos de valores "ValorPis", "ValorCofins", "ValorInss", "ValorIr" e "ValorCsll" constam como não obrigatórios no XSD, porém se não enviados, a nota é recusada. Solicitei correção do XSD por parte do provedor, mas não tenho ideia de quando farão, e se farão... 987: Removido o FintelISS do case para manter o DefTipos no formato necessário para o provedor. FintelISS.ini Linha 21, 22 e 50: Adicionado a parametrização da cidade de Paracambi - RJ nfseV202.xsd Correção do link do xmlns de https para http. trunk2.zip

Olá. Faz algum tempo que não envio nenhuma contribuição então o post vai ficar um pouco grande . Essa semana fiz a homologação do provedor FintelISS na cidade de paracambi/RJ. O provedor segue abrasf 2.02. Para atender o layout foi necessário algumas modificações. Irei cita-las por arquivo modificado. Os arquivos .pas estão em anexo, exceto os INI pois podem estar mais recentes quando for validar. A exceção fica para o fintelISS.INI que é novo. Também adicionei os XSD do provedor para as cidades que tinha disponível. ACBrNFSeConfiguracoes.pas: - Linha 718: os arquivos XSD do provedor são exclusivos das cidades (targetNameSpace aponta para o endereço do webservice da cidade), ou seja, cada cidade terá o seu XSD. Para não ter de criar um INI do provedor para cada cidade, adicionei a substituição do valor %NomeURL_H% e %NomeURL_P% no Namespace do XML. Outros provedores poderão usar caso necessário. fintelISS.INI (novo): - atualmente 2 arquivos ini acompanham o exemplo, sendo um exclusivo para itatiba (fintelISS_itatiba) e outro para Ponta Grossa (fintelISS_PontaGrossa). Com o novo ini, não há necessidade de separar por cidade, ambos podem ser descartados. pnfsNFSeW_ABRASFv2.pas: - Linha 153: mantive o provedor neste IF, mas sem a verificação da versão 2.01, pois a 2.02 também solicita que o grupo seja "TomadorServico". - Linha 277: idem acima, fechamento do mesmo grupo. Desde que miguei para o trunk 2.0, um de nossos clientes em Vitória/ES começou a ter problemas com a assinatura digital, onde a mesma era dada como inválida quando utilizado a biblioteca xsLibXml2 para assinatura. O mesmo não ocorria com o Capicom. Depois de vários testes junto do validador da receita federal, descobri que a xsLibXml2 tem problemas em lidar com a assinatura de um XML onde a tag que contem a URI não era única. No caso de Vitória, a uri ficava na tag <rps>, a qual aparece duas vezes no XML e gera os problemas na assinatura. Para sanar o caso, mudei a URI para outra tag do XML: <InfDeclaracaoPrestacaoServico> - Linha 768: Adicionado o provedor proVitoria ao IF. - Linha 807: Adicionado o provedor proVitoria ao IF. ISSDigital.ini: - Adicionado a url para o município de pará de minas [URL_P] ;Para de Minas/MG RecepcaoLoteRPS_3147105=https://parademinas.quasar.srv.br:8444/nfe/snissdigitalsvc?wsdl [URL_H] ;Para de Minas/MG RecepcaoLoteRPS_3147105=https://parademinas.quasar.srv.br:8444/nfe/snissdigitalsvc?wsdl Pronim.ini - Adicionado a url de Catanduva/SP - Alterado a url de Assis Chateaubriand/PR (somente produção. Na epoca não me foi passado a url de homologação). [URL_P] ; Catanduva/SP RecepcaoLoteRPS_3511102=http://nfse.catanduva.sp.gov.br/NFSEWS/Services.svc ; Assis Chateaubriand/PR RecepcaoLoteRPS_4102000=http://177.66.110.164:8184/nfse.portal.integracao/Services.svc [URL_H] ; Catanduva/SP RecepcaoLoteRPS_3511102=http://nfse.catanduva.sp.gov.br/NFSEWSTESTE/Services.svc WebISS.ini - Adicionado a url de Aracaju/SE [URL_H] RecepcaoLoteRPS_2800308=https://%NomeURL_P%.webiss.com.br/servicos/wsnfse/nfseServices.svc [URL_P] RecepcaoLoteRPS_2800308=https://%NomeURL_H%.webiss.com.br/servicos/wsnfse_homolog/nfseServices.svc Cidades.INI - Atualização do provedor de algumas cidades. Como modifiquei o ini do fintelISS, já revisei as cidades que constavam no ini. As que saíram do provedor fintelISS não fui atrás das novas configurações. Itatiba permanece, então adicionei as urls necessárias. [3147105] Nome=Para de Minas UF=MG Provedor=GINFES -> Mudou para ISSDigital [4113205] Nome=Lapa UF=PR Provedor=fintelISS -> Mudou para IPM [4119905] Nome=Ponta Grossa UF=PR Provedor=fintelISS -> Mudou para ELOTECH [4103107] Nome=Bocaiuva do Sul UF=PR Provedor=fintelISS -> Mudou para GovBR [3523404] Nome=Itatiba UF=SP Provedor=fintelISS NomeURL_H=https://iss.itatiba.sp.gov.br NomeURL_P=https://iss.itatiba.sp.gov.br - Novas cidades adicionadas [3303609] Nome=Paracambi UF=RJ Provedor=fintelISS NomeURL_H=https://iss.paracambi.rj.gov.br NomeURL_P=https://iss.paracambi.rj.gov.br [2708006] Nome=Santana do Ipanema UF=AL Provedor=DBSeller NomeURL_H=https://santanadoipanema.nfse.srv.br NomeURL_P=https://santanadoipanema.nfse.srv.br Por fim, uma dúvida: a consulta de NFSE por RPS (ConsultarNFSeporRps) exige que os RPS estejam carregadas no componente (ACBrNFSe.pas, linha 550), sendo que para realizar a consulta, somente o protocolo é o suficiente para o componente. Sabe me dizer se esta validação tem algum propósito especial? Estou pensando em remove-la permanente ou parametrizar no componente. Hoje em meu repositório local ela está desativada e as consultas ocorrem normalmente. ACBR - TRUNK2.zip

Creio que as cidades que a SigCorp está implementando recentemente sejam abrasf também. Exemplo: NFS-e Nova Serrana.

Boa tarde. Depois de MUITO tempo finalmente consegui atualizar as aplicações aqui da empresa para o trunk2 . Durante a conversão identifiquei algumas cidades que estavam apontando para o provedor incorreto ou não constavam no arquivo. Segue abaixo as cidades: Alteradas: [3133808] Nome=Itaúna UF=MG Provedor=GINFES Nova: São Gonçalo do Pará Cidades.INI: [3161809] Nome=São Gonçalo do Pará UF=MG Provedor=WebISSv2 NomeURL_H=homologacao NomeURL_P=saogoncalodoparamg WebISSv2.ini [URL_P] RecepcaoLoteRPS_3161809=https://%NomeURL_P%.webiss.com.br/ws/nfse.asmx [URL_H] RecepcaoLoteRPS_3161809=https://%NomeURL_H%.webiss.com.br/ws/nfse.asmx Um ponto que percebi e que me parece haver uma duplicidade de provedores do fonte (Sigcorp e SIGISS), creio que os dois se referem a mesma empresa, sendo que o SigISS não possui nenhuma implementação. Como precisava implementar uma cidade neste provedor, segui o que estava sendo usado (SigCorp). Tive de modificar parte do INI do provedor, pois estava fixo para o município de Avaré - SP. INI do provedor em anexo. Cidades.INI [3145208] Nome=Nova Serrana UF=MG Provedor=SigCorp NomeURL_H=novaserrana NomeURL_P=novaserrana [3504503] Nome=Avare UF=SP Provedor=SigCorp NomeURL_H=avare NomeURL_P=avare Depois de anos no trunk1, é muito bom poder voltar a contribuir . SigCorp.ini

Boa tarde a todos. Faz algum tempo que não passo por aqui Bom, vamos lá. Não migrei ainda para o trunk2 pois são muitos clientes a atualizar, mas farei o possível para ajudar. O atributo ID da tecnos é realmente grande, conforme citado no manual da Tecnos (http://help.nfse-tecnos.com.br/main_ws/contribuinte/notaeletronica.aspx). A formatação é a seguinte: <LoteRps Id="12013915933760001020000000000000001" versao="20.01"> <!--identificador do Lote de Rps, por padrão é esperado a composição--> <!--1 - identificação de envio de lote sincrono--> <!--0000 - ano do lote enviado no formato AAAA--> <!--00000000000009 - numero do CPF/CNPJ do contribuinte formatado com 14 posições--> <!--0000000000000009 - número sequencial do lote formatado com 16 posições--> <InfDeclaracaoPrestacaoServicoId="1915933760001020000000000000007"> <!--identificador do Lote de Rps, por padrão é esperado a composição--> <!--1 - Tipo de operação, no caso envio--> <!--91593376000102 - Documento do prestador formatado com 14 posições--> <!--0000000000000007 - Número do RPS formatado com 16 posições--> Verifiquem no XML de vocês se está tudo certo com os ID's e consultem também o layout no link acima. Caso esteja, recomendo procurar o suporte da tecnos por email. Demoram um pouco mas respondem e são prestativos.

Boa tarde Italo. Quando possível, adicione o município de Valença / RJ (IBGE: 3306107) ao provedor Betha. Obrigado!

Boa tarde Italo. Quando possível, adicionar o município de Camaquã / RS (Ibge: 4303509) ao provedor Pronim (Pron!m). Ambiente Produção: http://portal.camaqua.rs.gov.br/nfsews/Services.svc Ambiente Teste: http://portal.camaqua.rs.gov.br:8181/nfsewsteste/Services.svc Pagina com o XSD: http://portal.camaqua.rs.gov.br/nfse/

Entendo. Também estou com este problema e um dos clientes porém estou a espera de liberação de acesso ao ambiente para baixar o certificado a pelo menos 1 mês, então não consegui entrar em contato com o suporte ainda.

Diego, boa tarde. Você tentou contato com o provedor conforme indicado anteriormente?