Italo Giurizzato Junior

Bom dia Sergio, Se a propriedade Configuracoes.Arquivos.Salvar estiver com o valor True o arquivo *-procInutNFe.xml será salvo em disco automaticamente.

Bom dia Sergio, Acredito que você esteja carregando o XML errado. O correto é *-procInutNFe.xml

Bom dia Alexandre, Favor anexar a Unit alterada para que possamos analisar e estando tudo OK, vamos enviar para o repositório.

Bom dia Bruno, O serviço DistribuicaoDFe disponibilizado pelo Ambiente Nacional, lhe permite baixar documentos emitidos por outras pessoas e não os documentos emitidos por você. Vou exemplificar. Eu sou a empresa que realizou a venda dos materiais, portanto eu emiti a Nota e posso ou não ter enviado o evento de Carta de Correção ou de Cancelamento. Entenda que os eventos também são tratados pela SEFAZ como documentos. Você é a empresa que comprou os materiais, portanto você é o destinatário que pode ter enviado ou não um dos eventos de Manifestação do Destinatário. Se EU utilizar o DistribuicaoDFe vou baixar os documentos emitidos por VOCÊ, que neste caso são os eventos de Manifestação do Destinatário que enviou para SEFAZ referente as Notas que EU emiti contra o seu CNPJ. Se VOCÊ utilizar o DistribuicaoDFe ira baixar os documentos emitidos por MIM, que neste caso são as Notas e os eventos de Carta de Correção ou de Cancelamento. Você jamais vai baixar os eventos de Manifestação do Destinatário pelo DistribuicaoDFe, uma vez que estes documentos foram emitidos por você. Consta na legislação que, quem emite um documento deve guarda-lo pelo prazo legal, ou seja, se você enviou para a SEFAZ um evento de Manifestação do Destinatário, o XML com as informações do evento, assinado e com o protocolo que atesta que a SEFAZ recebeu, processou com sucesso e o vinculou a Nota deve ser salvo em disco ou no banco de dados e permanecerá guardado pelo prazo estipulado que normalmente é de 5 anos. Sendo assim não faz nenhum sentido você quere baixar um XML de um documento emitido por você. Dito tudo isso, você concorda que, se é você quem emitiu os eventos de Manifestação do Destinatário, você possui os XMLs dos mesmos e nesses XMLs temos a data de emissão e o tipo de evento? Eu sei perfeitamente que se você acessar o Portal Nacional da NF-e e consultar a Nota que EU emiti, VOCÊ vai ver os dados da Nota bem como todos os eventos vinculados a mesma, não importando quem foi que enviou tais eventos. Mas não é assim que o DistribuicaoDFe funciona. Abaixo temos uma tabela do que cada pessoa (ator) que venha a fazer parte de uma nota pode baixar através do DistribuicaoDFe.

Leandro, Você configurou o que no parâmetro Webservices?

Boa tarde, Acredito que será necessário reinstalar a suíte ACBr, para que tenha efeito a sua alteração.

Boa tarde Leandro, Mas esse provedor possui esse serviço em seu webservice? Se não possui você vai ter que usar o que esta disponível (Enviar e Gerar).

Boa tarde Maiquel, O componente simplesmente não grava o XML ou ele grava em uma pasta totalmente diferente da que foi configurada? A propriedade Configuracoes.Arquivo.Salvar esta com o valor True?

Boa tarde Maiquel, Sim, fiz no Fortes, pois não trabalho com o Fast Report.

Boa tarde, Você deve ter arquivos do ACBr antigos em alguma pasta que o Delphi esteja tendo acesso. Execute o ACBrInstall_Trunk2 com a opção de apagar arquivos antigos marcada.

Boa tarde a todos, Se entendi direito se você utilizar o certificado digital, não precisa usar os métodos Login e Logout? Se sim, tentaram executar os demais métodos?

Boa tarde ALA, Favor atualizar os fontes e reinstale a suíte ACBr, por fim faça novos testes.

Boa tarde Carlos, Favor atualizar os fontes, reinstalar a suíte ACBr e faça novos testes.

Maiquel, Favor atualizar os fontes, reinstale a suíte ACBr e faça novos testes.

Pelo o que eu entendi as informações do encerrante devem ser informadas no grupo <encerrante> e no grupo de observações do contribuinte, correto? Em vez disso não seria mais simples constar no decreto que as informações contidas no grupo <encerrante> devem ser impressas no DANFE da NFC-e.

Bom dia Brito, Estamos estudando a implementação desse provedor, mas como lhe disse vai ser demorado.

Bom dia, Primeiramente tenha uma coisa em mente. O componente gera e envia o XML do RPS, por outro lado o XML da NFS-e é gerado pelo webservice do provedor. Se você passa todas as informações corretas no XML do RPS e o provedor retorna o XML da NFS-e faltando alguma informação, o problema esta no provedor e não no componente. Pois o componente ao obter o retorno, simplesmente extrai o XML da nota e salva separadamente no disco. Se esses XMLs que você anexou são exemplos do provedor, note que no XML de envio consta o valor do ISS que é de 7,84 já o XML de retorno o valor do ISS é de 0,00 Outra coisa estranha é o valor do serviço ser de 0,10 (dez centavos) e o valor do ISS ser de 7,84

Bom dia Matheus, Você vai precisar mudar, deixar de usar o Capicom e passar a utilizar o WinCrypt, pois a SEFAZ esta desativando os protocolos: SSL, TLS 1.0 e TLS 1.1 Só vai aceitar o protocolo TLS 1.2

Bom dia Maiquel, Se não ocorre a impressão do DANFSE das notas enviadas para esse provedor, esta meio estranho essa exigência. Será que essa informação não deve constar no XML? Por exemplo, em vez de informar o nome do tomador, devemos informar essa frase quando se tratar de ambiente de homologação.

Bom dia Maiquel, Desculpe não entendi, ao cancelar uma NFS-e a principio são gerados 2 XML, o do pedido de cancelamento e o seu respectivo retorno. Com que nome esses XMLs são salvos?

Boa noite Robinho, Primeiramente peço que atualize mais uma vez os fontes e reinstale a suíte ACBr, pois foi detectado que alguns métodos estavam com a versão errada. Segundo nos testes que fiz não apresentou esse erro e sim: Integrador não cadastrado.

Olá pessoal, No dia 20/12/2019 foi publicado o Decreto de numero 47.799 que trata sobre a venda de combustíveis a consumidor final em estabelecimento comercial varejista de combustíveis automotivo. O decreto possui dois artigos, o primeiro se refere a obtenção das informações referente ao encerrante e o segundo diz onde as informações do mesmo deve ser informadas no XML. Para ler na integra o decreto clique aqui. Minhas considerações: 1. Esse decreto só serve para informar que se tratando de venda de combustível para consumidor final devemos informar no XML da NFC-e os dados referente ao encerrante, visto que essas informações ficou a critério de cada UF exigir ou não. 2. O decreto é de 19/12/2019, mas na Nota Técnica 2015/002 já estava previsto que a obtenção dos dados referente ao encerrante deveria ser via hardware, logo não deve ser digitados. Final da página 4 da referida NT: C. Grupo de Combustível: Informação de “Encerrante” Dentro do grupo de informações relacionado com as operações de combustíveis, foi incluído o subgrupo de “encerrante” que permite o controle sobre as operações de venda de combustíveis, de forma semelhante à atualmente em vigor. Observação do grupo <encerrante>: Informações do grupo de “encerrante” disponibilizado por hardware específico acoplado à bomba de combustível, definido no controle da venda do Posto Revendedor de Combustível. 3. No segundo artigo do decreto diz que temos que informar os seguintes dados: nBico, nBomba, nTanque, vEncIni e vEncFin no grupo de informações do contribuinte, ou seja, no campo xCampo devemos colocar o nome do campo, por exemplo nBico e no campo xTexto o numero do bico propriamente dito. Mas acontece que na NT que eu me referi na mesma página temos os campos que compõe o grupo <encerrante>, são eles: nBico, nBomba, nTanque, vEncIni e vEncFin. Duvida cruel: Se tratando de Minas Gerais as informações referente ao encerrante devemos informar no grupo <encerrante> conforme layout apresentado na Nota Técnica 2015/002 ou devemos colocar essas informações no grupo de observações do contribuinte? Se no layout da NF-e/NFC-e já existe um grupo especifico para tais informações pra que informar em outro lugar? Desenvolvedores, que possuem clientes que comercializa combustível no varejo, favor ficar a tento a isso. Não sei se cabe a uma consulta ao órgão competente. Data de inicio da exigência dessas informações no XML: 01/04/2020 Pela data deve ser tudo mentira. Não se faz necessário alterações no componente ACBrNFe.

Por favor atualize mais uma vez os fones e reinstale a suíte ACBr. Fiz algumas alterações, agora ao obter o retorno o componente vai salvar em disco o xml de cada guia retornada. Fiz uma alteração no programa exemplo, inclui um botão especifico para carregar e imprimir a guia versão 2.00 que é retornada em formato XML.

Boa tarde, Já estou verificando, notei que vou ter que fazer algumas melhorias. Por favor atualize todos os fontes de todas as pastas, reinstale a suíte ACBr e faça um novo teste. Pois não tive o problema mencionando por você.