Italo Giurizzato Junior

Bom dia, Por favor não coloque na mesma postagem dois ou mais assuntos, pois corremos o risco de tratar de uma e não tratar dos demais. Vamos sempre seguir as recomendações, assuntos diferentes, postagens distintas. O problema inicial é o envio do Rps, enquanto isso não for resolvido não adianta querer consultar, cancelar, etc. Analisando os XMLs gerados ao envia para o ambiente de produção, consta que o Rps foi rejeitado pois o CPF/CNPJ do tomador do serviço esta incorreto. Por outro lado ao enviar para o ambiente de homologação o webservice não retornou o protocolo que atesta o recebimento do Rps em seu webservice. Favor entrar em contato com o provedor e solicitar a URL do ambiente de homologação para a cidade de Viamão/RS.

Bom dia Carlito, Por favor faça os testes usando o programa exemplo, pois acredito que o problema esteja na configuração. O componente esta pegando os schemas errados para fazer a validação.

Boa noite, Muito obrigado pela colaboração, já inclui na minha lista de tarefas.

Boa tarde Valdir, Abra o arquivo ACBrNFSeXServicos.ini e altere as URLs da cidade de Bacabal/MA por estas: ProRecepcionar=https://abrasfbacabal.sigcorp.com.br/servico.asmx HomRecepcionar=https://testeabrasfbacabal.sigcorp.com.br/servico.asmx

Boa tarde, Faça um teste alterando o arquivo ACBrNFSeXServicos.ini trocando as URL da cidade Viamão/RS por estas: ProRecepcionar=http://viamao-portais.govcloud.com.br/NFSe.portal.integracao/services.svc HomRecepcionar=http://viamao-portais.govcloud.com.br/NFSe.portal.integracao.teste/services.svc Não esqueça de após alterar o arquivo devemos executar o Compila_RES.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia, Já inclui na minha lista de tarefas.

Bom dia a todos, Em vez de criar um enumerador para cada versão do layout pelo provedor como eu estava idealizando, depois de uma reunião e alguns testes resolvemos trabalhar com dois enumeradores, um fazendo referencia ao provedor e outro a versão do layout. Como é no arquivo ACBrNFSeXServicos.ini que informamos qual é o provedor que atende uma terminada cidade, é nesse mesmo arquivo que vai constar a versão do layout utilizado. Como esta hoje: [3131307] Nome=Ipatinga UF=MG Provedor=Actcon_202 Como vai ficar: [3131307] Nome=Ipatinga UF=MG Provedor=Actcon Versao=2.02 Esse é um exemplo. Caso não seja informado o campo Versao o componente vai assumir a versão 1.00 Para deixar a versão somente com dígitos a minha proposta é definir as seguintes faixas de versões. De 1.00 até 1.99 serão utilizados para definir a versão dos provedores que seguem a versão 1.xx do layout da ABRASF. De 2.00 até 2.99 serão utilizados para definir a versão dos provedores que seguem a versão 2.xx do layout da ABRASF. De 9.00 até 9.99 serão utilizados para definir a versão do layout de um provedor que tem o seu layout próprio.

Bom dia Elias, Muito obrigado pela colaboração, já inclui na minha lista de tarefas.

Boa tarde Matheus, Configura o componente para salvar os arquivos Soap e anexa eles também de ambos os componentes. Qual é o erro que esta ocorrendo no método Validar? Qual é a configuração (valor de SSLLib, .... e SSLType)?

Boa tarde Guto, Isso esta ocorrendo com o componente novo? Qual é a configuração que esta na aba Certificado do programa exemplo e o valor de SSLType?

Boa tarde Lucio, Vendo o manual que você anexou também achei muito estranho, pois o provedor RLZ que temos implementado no componente ele segue a versão 2 do layout da ABRASF. Por favor tente descobrir se esse provedor possui 2 webservices, um que segue o layout da ABRASF e outro que tem o seu próprio layout. Se isso se confirmar, providencio uma alteração no componente para que ele gere o XML corretamente dependendo da cidade.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde Tonny, Vai ser necessário entrar em contato com o provedor e expor o problema. Não temos como saber o que esta ocorrendo.

Boa tarde, Você poderia fazer um teste de envio do Rps e anexar os arquivos Soap de envio e de retorno para que eu possa analisar? De todas as cidades que você necessita seria muito bom.

Boa tarde, Quanto ao ambiente de homologação o provedor IPM tem ou não tem não sei lhe responder. Veja se você consegue um contato com eles e questione sobre isso.

Boa tarde Junior, O método Emitir abstrai a forma de envio de cada provedor. Se o provedor segue a versão 1 do layout da ABRASF, esse método vai retornar somente o numero do protocolo. A minha sugestão é que você atribua o calor True a propriedade de configuração: ConsultaLoteAposEnvio. Isso faz com que todo o processo seja automatizado pelo componente. A ideia é que no final você tenha o XML da NFS-e.

Boa tarde Vitor, Já inclui na minha lista de tarefas para analisar.

Bom dia Junior, No programa exemplo eu aconselho a usar esse botão para emitir a nota.

Bom dia rlind, Por favor não fique criando um monte de postagem no mesmo tópico, pois que me parece o seu problema inicial foi resolvido. Você agora esta questionando sobre ambiente de homologação, retorno e DANFSE. Procure criar um tópico para cada problema que você esteja enfrentando. Vou fechar esse tópico e obrigado pela compreensão.

Bom dia asterix, Se todas as cidades vão migrar para o novo sistemas deles o que eu preciso saber: Como devemos enviar o Rps e como é o retorno do envio; Como devemos consultar e como é o retorno; Como devemos pedir o cancelamento de uma nota e como é o retorno; Fazendo esses ajustes, deixamos como padrão no componente.

Boa tarde, Esse provedor esta complicado, pois dependendo da cidade ou da versão o retorno do webservice é diferente, hora retorna somente um resumo, hora retorna o XML completo da NFS-e Precisamos definir corretamente o retorno para as versões: IPM, IPM_110 e IPM_120.

Olá pessoal, Gostaria da opinião de vocês com relação a nomenclatura dos enumeradores dos provedores. O componente ACBrNFSeX atende por volta 110 provedores dentre deles temos provedores que seguem a versão 1 do layout da ABRASF outros seguem a versão 2 e temos os que possuem o seu layout próprio. No inicio fomos definindo os enumeradores em função do seu nome e depois acabamos descobrindo que existem provedores que tem webservice tanto na versão 1 quanto na versão 2 do layout da ABRASF e outros que tem um webservice para o layout próprio e outro para o layout da ABRASF. Sem contar com alguns provedores que tem variações na mesma versão como é o caso do Provedor Pronim que tem na versão 2 a varia~]ao 2 e 3, ou seja, proPronim_202, proPronim_203. A minha sugestão é padronizar a nomenclatura. Todos os provedores que seguem a versão 1 do layout da ABRASF passariam a ter no final do seu nome "_100a", por exemplo: proGinfes_100a Isso deixa claro que o provedor Ginfes segue a versão 1 do layout da ABRASF. Os que seguem a versão 2 passariam a ter no final do seu nome "_200a", ou "_202a" ou "_204a" dependendo da variação. Já os provedores que tem layout próprio passariam a ter no final do nome "_100p", pro exemplo o provedor Equiplano passaria ter o enumerador: proEquiplano_100p. Note que se tratando de provedor que possui um layout próprio tem no final do seu nome a letra "P" em minúscula que significa Próprio. Já os provedores que seguem a ABRASF passariam a ter no final do seu nome a letra "A" em minúscula que significa ABRASF. O que vai ocorrer com as aplicações caso venhamos a tomar essa medida: As aplicações que usam os enumeradores como tomada de decisão vai ocorrer quebra de código, consequentemente seja necessário fazer o ajuste necessário para voltar a compilar. Por exemplo: If Provedor = proGinfes then Ocorreria erro de compilação uma vez que o enumerador foi alterado. Correção: If Provedor = proGinfes_100a then Quero deixar claro que essa alteração não foi feita, estou apenas compartilhando com vocês a minha intensão de realizar essa padronização na nomenclatura dos enumeradores dos provedores. Quero a opinião de vocês.

Boa tarde Maurício, Seria interessante você informar também a cidade para que possamos realizar os mesmos testes com a mesma cidade usando sempre o programa exemplo.

Boa tarde Lucio, Porque você quer criar um novo arquivo INI para o provedor RLZ ? Lhe convido a iniciar os testes com o novo componente de emissão de NFS-e: ACBrNFSeX O componente ACBrNFSe não vai mais ter manutenção. Manual de Migração https://www.projetoacbr.com.br/forum/topic/63017-manual-de-migração-para-o-novo-componente-de-emissão-de-nfs-e/ Mudanças Como ocorreu mudanças na maneira de executar os métodos bem como a leitura dos retornos, favor ler o artigo: https://www.projetoacbr.com.br/forum/topic/63966-mudanças-no-retorno-dos-métodos-do-novo-componente-de-nfs-e-acbrnfsex/