Rodrigo Crovador
-
Total de ítens
94 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Rodrigo Crovador
-
-
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.pasLinha 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.
-
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.svcCidades.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.brPor 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.
-
4
-
-
Em 26/07/2019 at 17:43, jGuto disse:
Boa tarde, até onde eu sei, a SigCorp atende apenas a cidade de Avaré usando o padrão da Abrasf. As outras cidades que ela atende aqui da região é um padrão próprio da SigCorp.
Creio que as cidades que a SigCorp está implementando recentemente sejam abrasf também. Exemplo: NFS-e Nova Serrana.
-
2
-
-
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=saogoncalodoparamgWebISSv2.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.asmxUm 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=avareDepois de anos no trunk1, é muito bom poder voltar a contribuir
.
-
2
-
-
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/
-
Eu estava de férias, só retornei hoje, por isso não entrei em contato, e como passou bastante tempo, e tinha outras pessoas com o problema semelhante, resolvi perguntar para ver se alguém já tinha sido resolvido talvez.
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.
-
O erro exato que está dando para enviar nota para Estrela é esse:
<Codigo>E0800</Codigo><Mensagem>Erro na geracao da assinatura! Conforme nota divulgada e emitida junto a Secretaria da Fazenda e Portal da NFS-e de seu Municipio, torna-se obrigatoria a assinatura digital de Mensagens de Cancelamento e Envio de notas eletronicas enviadas ao sistema da NFS-e. - </Mensagem><Correcao>Erro no processamento do envio</Correcao>Estou anexando o xml de envio e o xml de retorno,Alguém tem alguma ideia?ObrigadoDiego, boa tarde. Você tentou contato com o provedor conforme indicado anteriormente?
-
Boa tarde,
Está dando um problema de assinatura inválida ao enviar a nota para provedor Tecnos, estou colocando como anexo o xml enviado e retorno para ver se alguém tem alguma ideia, tentei atualizar os fontes do ACBR para ver se resolvia, até vi que teve alterações para este provedor, porém mas o erro persiste.
Fico no aguardo.
Diogo
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.
-
Meus queridos, estou consumindo com sucesso a prefeitura de Ivoti.
Não tenho palavras pra agradecer o apoio de vocês.
Só tenho uma última dúvida:
Ao finalizar o EnvioSincrono ele não retorna o Código de Verificação, só o número do RPS.
Depois eu mando consultar e volta tudo certinho...
Isso faz parte do processo Síncrono? É assim mesmo?
Eu aumentei o tempo de sleep lá pra 6 segundos nessa linha:
Sleep(TACBrNFSe( FACBrNFSe ).Configuracoes.WebServices.AguardarConsultaRet);
No mais agradeço demais mesmo pela força...
Valeu!
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.
-
Bom Dia Senhores! Retorno da Tecnos:
Bom Dia André,
Estive analisando seu .XML e percebi algumas inconformidades:
1 - O Id está no formado incorreto para esta Tag, este formato é utilizado na Tag <LoteRps Id="...">
Antes: <InfDeclaracaoPrestacaoServico Id="12014019240950001000000000000000004" xmlns="http://www.abrasf.org.br/nfse.xsd">
Depois: <InfDeclaracaoPrestacaoServico Id="1019240950001000000000000000004" xmlns="http://www.abrasf.org.br/nfse.xsd">
ERROS Retornados:
1 - "Verifique se o item ou codigo informado está correto. Se estiver, proceda a atualização cadastral junto à Prefeitura assim que possível, pois o item ou o código informado não está cadastrado para a sua inscrição municipal.. Item da lista de Serviço, Código CNAE ou Código de Tributação."
1 - "Item da lista de serviço, codigo CNAE ou código da tributação informado para a operação não está cadastrado para o prestador de serviços."
2 - "Informe o código do país que o tomador pertence."
2 - "Código do País não informado para o tomador"
3 - "Apenas contadores podem emitir valor de alíquota inferior a 1."
3 - "Valor de alíquota fora do padrão."
Mando em anexo o .XML que montei a partir do seu com o que estava faltando (Tags <EnviarLoteRpsSincronoEnvio/>, </ListaRps/>, </LoteRps/>) e que usei para fazer esse teste;
Ignorem os erros de preenchimento, eu me viro com isso, mas ainda tem falha na montagem do XML.
Segue ajuste.
-
Ok. Ítalo...
Valeu Rodrigo pelas dicas, estava modificando com as tuas dicas, mas quando vi a interação do Ítalo achei melhor seguir por ele...
Atualizei, e agora mudou o erro...
ERRO: Erro na geracao da assinatura!A Assinatura da nota nao confere com a informacao contida no XML - /Em anexo os XMLs de hoje...
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
-
Boa tarde Italo!
Olha só o que o programador da Tecnos me enviou por e-mail:
Boa Tarde Andre,
O problema está na assinatura, você está assinando a Tag </LoteRps> quando na verdade deveria estar assinando a Tag </InfDeclaracaoPrestacaoServico>;
Você deve assinar nota por nota e não o Lote;
Mando em anexo um .ZIP contendo os layouts de Envio e Cancelamento junto com o Link do nosso Help para que possa usar como modelo e se basear para validar sua assinatura;
HELP: http://help.nfse-tecnos.com.br/main_ws/assinatura/assinaturaEnvio.aspx
Porém já está configurado no ACBrProvedorTecnos para:
ConfigCidade.AssinaRPS := True;ConfigCidade.AssinaLote := False;Quanto a tua solicitação eu marquei pra Salvar as configurações do Webservice...
Vou Anexar uma pasta com todos os XMLs de hoje (foi só uma tentativa de emissão).
Fico no aguardo de uma luz aí...
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.
-
Bah gurizada...
O Cliente não tinha emmitido o Certificado da Tecnos lá no site...
:/
Tem coisas na vida de um programador que ninguém explica...
Agora o erro "evoluiu" para esse:
ERRO: Erro no documento XML (1, 293). - O caractere '<', valor hexadecimal 0x3C, nao pode ser incluido em um nome. Linha 1, posicao 293. /
É, acontece com os melhores clientes rs. Desse outro erro, so com o XML mesmo :/
-
Sim, os fontes estão atualizados, atualizei ontem...
Já fiz todas as combinações de AssinarRPS = False/True com AssinarLote = Flase/True...
Não consigo sair disso...
Já li todo esse outro tópico:
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, seguinte, li todo esse tópico, e não consigo enviar NADA pra Prefeitura de IVOTI.
Estava mandando com o AssinarRPS = False e me dizia que a Secretaria sha lá lá exigia a assinatura.
Modifiquei pra AssinarRPS = True e agora ele me retorna todo o XML dizendo: Não foi possível carregar o arquivo e o conteúdo do XML...
Help!
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])
-
1
-
-
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:
Lote:
<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-->
RPS:
<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-->
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. -
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/
-
Rodrigo, o cancelamento é feito por algum outro método ou não está implementado ?
Obrigado
Boa tarde Leonardo. Não está implementado mesmo.
-
Rodrigo, bom dia.
Quanto à impressão da NFS você utiliza a impressão do próprio metodo do ACBR para a NFS de Osasco ?
Obrigado
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.
-
Eu já implementei a parte que trata os erros retornados pelo webService, porém estou com uma dificuldade no retorno quando é gerada a nota com sucesso.
Esse bloco ele retorna vazio então ele acaba não alimentando o AcbrNFSe.NotasFiscais.
FRetListaNfse := SeparaDados(FRetWS, Prefixo3 + 'ListaNfse');
Sendo prefixo3 gerado pela função configCidade = 'tem:' e
FRetWS = <?xml version="1.0"?>
-<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">-<s:Body>-<EmitirResponse xmlns="http://tempuri.org/">-<EmitirResult xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns:a="http://schemas.datacontract.org/2004/07/Rgm.Eissnfe.Negocio.WebServices.Mensagem"><a:Erro>false</a:Erro><a:MensagemErro i:nil="true"/>-<a:NotaFiscalGerada xmlns:b="http://schemas.datacontract.org/2004/07/Rgm.Eissnfe.Dominio.DataTransferObject.Prestador"><b:Autenticador>OTHVLMTP</b:Autenticador><b:Numero>155485</b:Numero></a:NotaFiscalGerada></EmitirResult></EmitirResponse></s:Body></s:Envelope>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.
-
Hum entendi Rodrigo, pq estou tendo o seguinte problema os erros que dão por exemplo de validação de conteúdo tais como Código de Atividade Inexistente, chave de autenticação inválida... não estão subindo para o usuário como acontece pelo método enviar, com isso só visualizo o erro abrindo o arquivo lista-nfse.xml
Pensei se tem algo para recuperar essa mensagem para apresentar para o usuário ou algo do tipo....
Desde já agradeço pela ajuda !
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.
-
Italo, obrigado.
Já atualizei aqui e deu certo...
Senhores outra dúvida a parte de retorno do webService ela já esta implementada ?!
Ou é acionada por outro método ?!
Não está implementada, pois o provedor retorna apenas um protocolo para ser usado via interface web. Veja o link do primeiro post.
Provedor FintelISS para Paracambi
em ACBrNFSe
Postado · Editado por 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