Rodrigo Crovador

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?

Também estou com o mesmo problema Diogo, porém estou tendo dificuldades na comunicação com o meu cliente. Sugiro que tente contato com a Tecnos a respeito, pois sem a informação do cliente não tenho como contata-los.

Boa tarde André. Sim é isso mesmo. Por algum motivo o Tecnos trocou o envio convencional pelo envio síncrono. O síncrono está apenas na nomenclatura, o envio é mesmo de RPS em lote.

Segue ajuste. pnfsNFSeW.pas

Certo, agora parece que a estrutura do XML está ok, O próximo passo seria você verificar a consistência dos dados. Consulte no site de emissão da Tecnos como está os dados da empresa, como por exemplo a razão social. Outra opção é baixar o certificado digital da Tecnos novamente. Se não me engano usam diferentes para ambiente de teste e produção

Bom André, dei uma olhada no XML. Vamos desconsiderar o que a Tecnos disse por enquanto, há alguns detalhes para ajustar antes de tratar isso. Está ocorrendo algum problema no momento que é feito o tratamento da função RetornaConteudoEntre, a qual organiza o seu XML para montar o envelope SOAP. procure os locais da chamada desta função e use o debug para verificar o motivo da função não conseguir copiar o conteúdo do seu XML. Para entender melhor o que está acontecendo, veja o XML gerado na pasta GER, o qual é enviado para o provedor. Ele para na tag <InfRps onde deveria preencher com as NFSE. Ao invés disso, deixa a tag aberta e começa a fechar as demais. Se observar o conteúdo da pasta RPS, verá que a nota foi gerada perfeitamente, foi o momento de alocar no lote que ocorreu o problema.

É, acontece com os melhores clientes rs. Desse outro erro, so com o XML mesmo :/

André, poste o xml que acbr está gerando aqui por favor. Oculte os dados que achar necessário mas mantenha a estrutura que foi gerado.

Bom dia André. A assinatura do RPS não é necessária conforme layout da Tecnos. A assinatura obrigatória mesmo é do Lote como um todo, a qual está configurada como obrigatória nas revisões superiores a abril do ACBR. Teria de avaliar melhor a causa da rejeição do seu XML. Não indico a prefeitura, pois na maioria nos casos eles não tem conhecimento por ser terceirizado. De uma olhada no help da Tecnos (http://help.nfse-tecnos.com.br) para comparar o XML que está gerando ou tente contato por email com eles. Demoram um pouco mas costumam responder ( [email protected])

Italo, boa tarde. Estou enviando um ajuste no provedor Tecnos referente a uma modificação que foi feita em abril. Estou desfazendo a modificação. Uma breve explicação do porque: No layout utilizado pela Tecnos, há 2 ID, um identificando o lote e outro identificando o RPS. Ambos possuem um formato específico que não permite o uso do mesmo ID com a adição da palavra rps como e feito em alguns provedores, conforme abaixo: O componente hoje possui apenas um atributo ID. Como criar outro atributo poderia confundir alguns usuários e levaria mais tempo, optei na época por deixar o atributo ID do componente (InfID.ID) como o ID do RPS e montar o ID do lote manualmente, pois este era único no lote todo. Este mesmo ID é usado na nomeclatura dos RPS quando a opção de salvar está ativa. Na revisão de abril quando foi alterado alguns detalhes do provedor durante testes do processo de cancelamento, na unit pnfsNFSeW.pas foi alterado o formato do ID, deixando de gerar o ID do RPS para gerar o ID do lote. Não sei se alguém mais atualizou depois disso mas tive muitos problemas com isso, desde o nome do arquivo duplicado ao tentar salvar localmente como ID duplicado na validação do provedor. Não sei dizer se alguém produziu algo se utilizando do ID, portanto não sei dizer ate onde pode impactar outros usuários, mas voltar a forma anterior foi necessária para atender o layout. Quem tiver dúvidas, segue o layout: http://help.nfse-tecnos.com.br/main_ws/contribuinte/notaeletronica.aspx Em anexo os arquivos alterados: pnfsNFSeW.pas: retornar a forma anterior de formatação do ID, ID do RPS. pnfsNFSeG.pas: ajuste na formatação do ID do lote, pois este copia parte do ID do RPS. pnfsNFSeG.pas pnfsNFSeW.pas

Italo, boa tade. Você poderia adicionar uma nova cidade no provedor Tecnos? Segue os dados: Encantado / RS / IBGE = 4306809 Homologação: http://homologaencan.nfse-tecnos.com.br/ Produção: http://encantado.nfse-tecnos.com.br/

Boa tarde Leonardo. Não está implementado mesmo.

Não, na ocasião o cliente utiliza o envio do link de consulta no site por email apenas. Mas caso carregue os dados da NFSE no componente, você poderá utilizar qualquer um dos métodos de impressão já implementados no componente.

Ele não consegue alimentar a NFSE gerado devido ao webservice não retornar a NFSE aprovada. Sem este retorno, a unica fonte que você pode encontrar essa NFSE seria no próprio XML enviado ou nas propriedades do próprio ACBR.

Bom neste caso teria de implementar mesmo. O cliente que utilizei como exemplo quando desenvolvi este processo era um caso bem singular que dificilmente difere os dados da nota, então não me surpreende ele não ter problemas até então com recusa por informação incorreta. O único cuidado seria de que o provedor e bem específico em geral, então e bem provavel que no método que trate o retorno do WS você tenha de personalizar o tratamento para o EgoverneISS.

Não está implementada, pois o provedor retorna apenas um protocolo para ser usado via interface web. Veja o link do primeiro post.