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.