Italo Giurizzato Junior

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/

Boa tarde Valdir, O provedor ISSCuritiba segue a versão 1 do layout da ABRASF. Na versão 1 esta previsto apenas um modo de envio que é o modo de envio assíncrono. Ele permite o envio de um lote de até 50 Rps. Outro detalhe importante é que após o envio devemos consultar a situação do lote e não consultar o lote. Ao consultar a situação do lote passos passando o numero do protocolo retornado pelo envio do lote temos como resposta umas das 4 situações: 1 - Lote não enviado (é bem provável que o numero do protocolo informado não se refere a nenhum lote enviado) 2 - Lote aguardando processamento 3 - Lote processado com falhas 4 - Lote processado com sucesso Se retornar a situação 2 devemos aguardar alguns segundos e realizar uma nova consulta. Se retornar a situação 3 ou 4 devemos Consultar o Lote, teremos como resposta a lista de rejeições caso a situação seja 3 ou a lista de notas caso a situação seja 4. O componente ACBrNFSeX possui uma propriedade de configuração chamada ConsultaLoteAposEnvio que automatiza todo esse processo. Inclusive é possível definir um tempo de espera entre o envio e a primeira consulta (AguardarConsultaRet), o tempo de espera entre uma consulta e outra (IntervaloTentativas) e a quantidade de consultas (Tentativas). Veja bem isso não vai acelerar o processo, mas sim automatizar ele.

Boa noite Sandro, Favor testar com esta unit em anexo: IPM.Provider.pas

Boa noite Marcelo, Notei que os seus fontes estão desatualizados e o programa exemplo não esta configurado para consultar a nota após o cancelamento. Atualize os fontes e marque a opção para consultar a nota após o cancelamento e faça um novo teste.

Gabriel, Não copie fontes do ACBr para dentro de pastas dos seus projetos, você só vai ter dor de cabeça. Outra coisa não tenha copias dos fontes do ACBr no mesmo HD, isso também pode trazer problemas, principalmente se o Delphi tiver acesso a essa cópia. Se quer ter uma cópia faça em um HD externo e o deixe desconectado da maquina.

Boa tarde Sandro, Isso esta ocorrendo com o programa exemplo? Se sim, acredito que você tenha alterado o arquivo ACBr.inc

Boa tarde Igor, Simplesmente esquece o Capicom ele não tem suporte para a criptografia TLS 1.2 Ou você usa o OpenSSL ou o WinCrypt. Vou fechar esse tópico pois entendo que o problema foi sanado.