Rômulo da Costa de Souza

Boa tarde Rafael, Vou efetuar os testes e depois retorno com o feedback, obrigado!

Bom dia Italo, estou na revisão 17121, a principio olhei as revisões acima, mas não houve mudanças em relação a isso.

Bom dia, Estou migrando do MsXML para LibXML2, estou testando no Provedor Digifred, porem estou obtendo a seguinte rejeição do provedor ("Codigo = E172", "Mensagem = Arquivo enviado com erro na assinatura.", "Correcao = Acerte a assinatura do arquivo."). O provedor Digifred solicita assinatura do lote, analisando os fontes da unit ACBrDFeXsLibXml2, no método Assinar(), consegui identificar que na hora de capturar a tag SignedInfo do lote, acaba por retornar a tag SignedInfo do RPS, dessa forma ao gerar SignatureValue do lote, acaba por ser a mesma do RPS. Gostaria de trocar uma ideia, para que eu possa fazer a correção, sem que ocorra problemas para quem já esta funcionando. Segue em anexo os exemplos feitos com MsXML e com a LibXML2, desde já Obrigado pela sua Atenção! Exemplos.rar

Bom dia Pessoal, Fiz uma correção em relação a compatibilidade com o serviço de consulta cadastro da versão 4.00. ACBrCTeServicos.ini ACBrCTeWebServices.pas

Boa tarde Pessoal, Gostaria de Compartilhar com vocês a minha solução, sempre utilizei a DLL, porém a partir do dia 25/02/19, meus clientes começaram a obter o erro de DNA inválido, entrei em contato com o pessoal da Farmácia Popular e obtive esse mesmo e-mail. Portanto resolvi implementar a solução utilizando gbasmsb.exe, até então conseguimos estabilizar a comunicação. A forma como estou fazendo é criar um arquivo .bat, com o seguinte parametro " --identificacao ", para obter a identificação do terminal. E para obter o DNA da solicitação " --solicitacao ", desta forma ficou bem parecido como se eu estivesse utilizando a DLL. Porque salvo um .txt com as informações ao executar o .bat e depois só efetuo a leitura do .txt.

Bom dia Pessoal, Olhando a NT 2018 001 v1.00, nela fala o seguinte sobre a rejeição 232: Se informado CNPJ do Destinatário e indicador de IE Destinatário = "ISENTO" ou não informada (tag:indIEDest=2 ou 9): - Destinatário possui IE ativa na UF. Então Analisando o Contexto acredito que Contribuinte ISENTO e Não Contribuinte, que tiverem Insc. Estadual devem informar ao gerar a nota.

Boa tarde pessoal, Também estou obtendo essa rejeição no "RS", olhando nas submissões percebi que foi ajustado na revisão 16541, pelo nosso amigo Italo Jurisato Junior. Olhando nas Notas Técnicas, não consegui encontrar nada de novidade, que venha a alterar a NT2013.005 v1.22, que fala o seguinte "Contribuinte Isento de Inscrição (não deve informar a IE) e Não Contribuinte. Neste último caso, a IE do destinatário pode ser informada ou não, já que algumas UF concedem inscrição estadual para não contribuintes." Alteração da Revisão 16541: if nfe.Dest.indIEDest <> inIsento then => if nfe.Dest.indIEDest <> inNaoContribuinte then Desde já Obrigado pela Atenção!

Bom dia EMBarbosa, Obrigado pela analise, vou testar sim.

Boa tarde Pessoal, Fiz alguns ajustes nas seguintes unit's que utilizam o FastReport: ACBrCTeDACTEFR.pas, ACBrGNREGuiaFR.pas, ACBrMDFeDAMDFEFR.pas, ACBrNFeDANFEFRDM.pas, ACBrNFSeDANFSeFR.pas. Para seguir um padrão nos métodos de Imprimir, ImprimirPDF e PrepareReport. Se for de interesse de todos e realmente vir a contribuir para o projeto, segue em anexo as alterações. DanfesFR.rar

Boa tarde pessoal, Só para informar, aqui no RS, voltou a permitir a emissão das NFe/NFCe com a tag <cEAN/> e <cEANTrib/> em branco no ambiente de produção. Então realmente o pessoal deve ter ajustado a regra pela nota técnica 2017.001 - v1.40. Obrigado e uma boa semana a todos.

Pessoal tentei efetuar os seguintes testes: <cEAN></cEAN>, <cEANTrib></cEANTrib>, retorna a rejeição 883. Depois tentei efetuar um outro teste que seria não informar as tag <cEAN> e <cEANTrib>, retornou a rejeição 999. Pelo que tudo indica, teremos que Informar "SEM GTIN". Para isso acredito que seria interessante criar nos ERP's uma forma de permitir informar "<cEAN/>, <cEANTrib/>" ou "<CEAN>SEM GTIN</CEAN>, <cEANTrib>SEM GTIN</cEANTrib>", para caso a sefaz resolva corrigir a regra pela nota técnica 2017.001 - v1.40, não tenhamos que desfazer os ajustes e até mesmo gerar uma nova versão.

Segue em anexo a nota aceita pela sefaz, com a escrita SEM GTIN. 43181215655245000124650010000050599990679239-procNFCe.xml Rafael, vou tentar efetuar uma nota dessa forma, já retorno.

Fernando Filho o meu medo na verdade é eu efetuar esses ajustes e a sefaz resolver de corrigir isso, claro que hoje não seria um problema podemos adicionar configurações para isso. Vou tentar efetuar esse teste e já entro em contato novamente, Obrigado por enquanto a todos.

Bom dia Fernando Filho, Porém essa validação só deveria começar pelo que eu entendi na nota técnica 2017.001-v1.40 a partir de 06/05/2019. Pelo meu entendimento acredito que esse tratamento deveria ser efetuado dentro do próprio componente, se verificarmos na unit pcnNFeW no método GerarDetProd , temos um código que iria fazer isso, mas foi comentado.

Segue em anexo o arquivo da NFCe, a mesma esta no modo off-line. Pelo fato que, quando o meu sistema não consegue efetuar a emissão ou se obter uma rejeição da sefaz, ele automaticamente ajuste a nota para off-line, isso para não travar os terminais. NFCe-5059.xml

Segundo a nota técnica 2017.001-v1.40, a data de produção entraria dia 06/05/2019. Pelo que analisei o ACBr não fez nenhuma alteração referente a isso, hoje o mesmo esta gerando a tag cEAN e cEANTrib em branco. Acredito que não seja o problema no ACBr, porque até dia 30/11/2018 estava funcionando.

Bom dia Pessoal, Desde ontem venho obtendo a rejeição 883, no estado do RS, verificando pela nota técnica 2017.001 - v1.40, ficou entendido na minha percepção que essa validação começaria a partir 06/05/2019 em ambiente de produção. Alguém mais vem obtendo essa rejeição? Desde já Obrigado pela Atenção.

Bom dia Pessoal, Atualizei os fontes e efetuei os testes, a principio tudo certo.

Bom dia Italo, Obrigado pelo retorno, vou atualizar os fontes e testar, em seguida reporto se vou a funcionar.

Bom dia Italo, Primeiramente obrigado pelo retorno. Só para explicar melhor, no ambiente de homologação e produção os serviços de recepção e consulta funcionam normalmente, apenas o serviço de cancelamento que em ambos não esta funcionando. Segue a sequência e os arquivos do teste que efetuei agora. 1º) Envio do RPS; 2º) Tentativa de Cancelamento da NFSe. Obs.: no meu sistema se der erro, atualizo para o status rejeitado, para permitir a consulta; 3º) Consulta; Envio-10736_0.rar Cancelamento-10736_0.rar Consulta-10736_0.rar

Bom dia Pessoal, Efetuei alguns testes no ambiente de homologação, os serviços de recepção e consulta funcionam normalmente, o serviço de cancelamento, esta dando o mesmo erro do ambiente de produção Erro HTTP: 500 URL: https://e-gov.betha.com.br/e-nota-contribuinte-test-ws/cancelarNfseV02?wsdl, estou utilizando TDFeSSL para envio, desta forma ficasse a dúvida se ambos os ambientes estão com problemas no serviço de cancelamento ou se realmente houve alguma alteração e não estamos sabendo ainda.

Boa tarde, Também estou tendo esse problema na Cidade de Três Passos-RS, pela minha analise, observei que apenas esta gerando os arquivos ped-can.xml, ped-can-soap.xml. Não consigo obter os arquivos de retorno, tudo parece que há algo com essa máquina/internet, já desativei Antivírus e Firewall e mesmo assim não obtive sucesso.

Bom dia Pessoal, Consegui resolver o problema nos meus Clientes, fazendo os seguintes procedimentos, Painel de Controle -> Opções da Internet -> Aba Avançadas: 1º) Restaurar Configurações Avançadas 2º) Redefinir Logo após isso, fui novamente na aba avançadas e deixei selecionado as seguintes configurações Usar SSL 3.0, Usar TLS 1.1, Usar TLS 1.2. Em alguns casos já voltou a funcionar, em outros tive que abrir o IE e efetuar a configuração, logo após isso voltou a funcionar normalmente. Obs.: Funcionou em Windows sem Service Pack e Windows com Service Pack, outro detalhe tive esse problema em Clientes que estavam com o IE8 e 9. Config. do ACBr que utilizo: SSLCryptLib := cryWinCrypt; SSLHttpLib := httpWinHttp; SSLXmlSignLib := xsMsXml; SSLType := LT_all;

Bom dia Pessoal, Efetuei uma analise prévia de ontem para hoje, o que parece que esta ocorrendo essa lentidão é as máquinas que estão com Windows 7 sem Service Pack.

Bom dia, estou tendo o mesmo problema já faz alguns dias no estado do RS, não utilizo o ACBrMonitor.