Painel de líderes

Bom dia @Italo Jurisato Junior Não, são UF's que não consigo certificado para teste. Obrigado, vou reverter aqui, não tinha me atentado ao tópico da Juliana.

Use o método DistribuicaoDFePorUltNSU. Nele você passe o NSU = 0. Com isso, você terá como resposta os NSU's dos últimos 90 dias. Detalhe: O DistribuicaoDFePorUltNSU retorna apenas 50 NSU's por vez. Então caso tenha mais do que 50 você terá que executar mais de uma vez. E a cada execução, você passa o último NSU que você recebeu. Aí você me pergunta; como eu sei que tem mais do que 50 pra eu baixar? Simples, existe uma propriedade que consta o número máximo de NSU que tem no WebService. Então resumindo a lógica seria mais ou menos assim: iUltimoNSUGravado := GetUltimoNSUGravado; repeat ACBrNFe1.DistribuicaoDFePorUltNSU(IdEstado, aCNPJ, iUltimoNSUGravado); cStat := ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.cStat; if cStat = 138 then {Documentos encontrados} begin iMaxNSUWebService := StrToIntDef(ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.maxNSU, 0); for i := 0 to Pred(ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Count) do begin {Aqui você processa NSU por NSU. Inclusive grava o NSU no banco de dados} end; end; iUltimoNSUGravado := GetUltimoNSUGravado; until (iUltimoNSUGravado = iMaxNSUWebService);

Bom dia fiz um pequeno ajuste, para resolver o problema de algumas logos de Banco que estavam saindo um pouco cortadas na parte superior. Em anexo arquivo modificado. ACBrBoletoFCFortesFr.dfm

Eu novamente. Me informei com outra pessoa do banco no qual me disseram ser uma informação não necessária e que não afeta em nada caso não informada, foi uma precipitação da pessoa que cobrou o campo no arquivo, então segue o barco srsrs

Acredito que o problema seja as tags que está enviando para o evento S1210. Note que algumas tags não pertencem a esse evento. A tag [evtBenPrRP] pertence ao evento S1207. Para o envio do evento S1210 é necessário o envio prévio de eventos anteriores. A tag [DmDev] também pertence ao evento S1207, por isso o erro de Schemas.

Boa tarde Daniel! Falha minha! durante minhas férias o outro programador alterou a pasta do nosso ACBR. Olhei várias vezes isso ontem e não notei. Obrigado!

Era o antivirus AVG. Desculpe o transtorno.

As NFC-e emitidas em contingencia, você se refere a off-line, correto? Se sim, note que elas não foram enviadas para a SEFAZ. Sendo assim não vejo a necessidade de corrigir esses XMLs.

Me parece ser o mesmo problema deste post:

Bom dia. Moderação: Movido para sub-fórum adequado. Att.

Nessa caso, basta você tratar o retorno... algo como MeuPeso := StrToInt( Trim( ACBrBAL1.UltimaResposta) ) / 1000

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

Muito obrigado, era isso... em todos os estados estava indo....menos no matogrosso! tem como corrir os xml das notas que foram emitdas em contingencia desse erro?

Obrigado Daniel Simões. Funcionou.

Futicando no fórum achei uma solução, renomear o arquivo com Renamefile!

Olá, Sobre a questão dos nomes de arquivos, boa parte dos moderadores e devs não acham apropriado alterar esses nomes. Para não criarmos uma polêmica vamos tratar nesse tópico apenas das outras alterações propostas. Se você realmente achar esse recurso muito importante, por favor, crie um novo tópico só sobre isso. Assim, poderemos pedir que tanto outros devs como usuários do ACBr de modo geral possam opinar. Sobre as mensagens, eu enviei ao SVN na revisão 17056. A única linha que não alterei foi a que altera "FNFe.Ide.verProc". Porque a string é ACBrNFe. Não existe ACBrNFCe. Ainda assim, deixei um comentário, caso tenhamos outros motivos para ajustar isso. Queira por favor, atualizar e testar.

Bom dia Udenilson, Para mais informações sobre o Distribuição DF-e, por favor leia: Como obter o XML do Fornecedor.

Correção do nome das propriedades indSubstPatr e indSubstPatrObra para correta leitura do xml de retorno. pcesS5011.pas

Bom dia @MFincotto, Você chegou a testar nessas UF com as URLs que se encontram atualmente no arquivo ACBrNFeServicos? Se sim, qual foi o resultado?

@MFincotto No caso da BA já está correto, não constam no arquivo as URL para o QR-Code 2.00, nesse caso são usadas as URL de versão anterior que são as mesmas citadas por você. Para GO e MG, chamo atenção para o trecho do tópico citado pela Juliana: Como não tivemos relatos de problemas desde o dia 20, exceto nos casos de usuários com o arquivo desatualizado, tudo leva a crer que as URL estão corretas no arquivo. Aguardamos novos feedbacks.

@Italo Jurisato Junior Localizamos uma pequena falha na formatação de uma data, segue correção conforme manual. No manual solicita que a data seja em formato YYYY-MM-DD. pcesGerador.pas

Bom dia, Muito obrigado pela colaboração, já enviei para o repositório.

Bom dia, Em qual momento ocorre esse erro? É o componente que esta lhe apresentando essa mensagem ou você esta pegando o XML e tentando validar ele em algum site? Pois pelos os XMLs que você anexou, o XML assinado do BPe foi gerado, foi enviado, a SEFAZ retornou o protocolo de autorização e o XML assinado foi atualizado, ou seja, agora ele tem o protocolo de autorização. Foi gerado o XML do evento de pedido de cancelamento, ele foi enviado, a SEFAZ retornou o protocolo de homologação do cancelamento e foi gerado o arquivo *-procEventoBPe.xml que contem o pedido e o protocolo, até ai perfeito. Foi solicitado uma consulta por chave, o XML foi gerado e enviado, a SEFAZ retornou o resultado dessa consulta, no XML de retorno temos a situação atual (cancelado), o protocolo de autorização e por fim o pedido de cancelamento com o protocolo de homologação do mesmo. Resumindo, fazendo uma analise pelos arquivos XML, tudo ocorreu conforme o esperado.

Bom dia, obrigado pela atenção pessoal, segue abaixo as informações que tem dado "conflito" no envio : Boleto.Cedente.CodigoTransmissao := '01770733867801300144'; Boleto.Cedente.Modalidade := '101'; Boleto.Cedente.Convenio := '7338678'; Boleto.Cedente.CodigoCedente := '7338678'; Do resto são informações que não deram inconsistências. Ontem revalidei a linha digitavel e mandei novamente um PDF do boleto para o banco, indicando os dados que eles diziam ser inconsistentes, agora é aguardar. Obrigado mais uma vez.

Obrigado por este retorno, era a dúvida que estava me matando!!!

Apliquei modificações que devem atender a sugestão... Mas preservei uma funcionalidade, que acho importante... O programador, poder introduzir um valor na calculadora, antes de Chamar o Execute... Exemplo: procedure TfrExtenso.Button1Click(Sender: TObject); begin ACBrCalculadora1.Valor := 123; ACBrCalculadora1.Execute; end; commit: 17052

Daniel, Entrei em contato com a SkyTef agora vou esperar as instruções. Obrigado

Minhas Desculpas Italo e comunicade.. realmente não obtive.. Fiquei meio perdido no fórum. Abraço e saudações

Boa tarde Freitas, Esse fórum é para tratar sobre o componente ACBrNFSe - Nota Fiscal de Serviço Eletrônica, não tem nada haver com o seu problema que é NF-e e pelo que entendi você utiliza o ACBrMonitor. Peço que tenha mais cuidado quando postar, pois você pode acabar postando em lugar errado e não ter resposta para sanar o seu problema.

Boa tarde Luís, Por favor atualiza mais uma vez e faça um novo teste.

Boa tarde Paulinho, Favor anexar o XML assinado e autorizado desse MDF-e. Devemos ter em mente que a Data/Hora de Emissão se refere a Data/Hora da UF do Emitente, já a Data/Hora de Autorização de Uso se refere a Data/Hora da SEFAZ-Autorizadora que neste caso é a SEFAZ-Virtual do Rio Grande do Sul. Se Rio Grande do Sul em relação a UF do Emitente esta 1 hora a mais, isso é devido ao fuso horário. Como lhe disse, o outro sistema diminuía em uma hora o horário de Autorização para ficar dentro do mesmo fuso horário. Que ao meu ver não é o correto, pois esta sendo alterado uma informação que foi gerada pela SEFAZ.

A Sefaz-RS emitiu um comunicado: https://portalspedbrasil.com.br/forum/nfc-e-breaknews-comunicado-urgente-da-sefaz-rs/

O ACBR nao tem essa integração, fiz na munheca com a ajuda da própria Mamut. Entre em contato com eles que te ajudam nisso. Não há a necessidade de te enviar codigos pois eles ja possuem exemplos em Delphi.

Algumas razões possíveis: - Não foi compilado o ACBrNFeServicos.res depois de alterar o ACBrNFeServicos.ini; - O compilador encontrou um ACBrNFeServicos.res desatualizado e usou ele em vez do correto; - Existe um arquivo ACBrNFeServicos.ini desatualizado no diretório da aplicação

Provavelmente o seu método CriaConexao está sendo chamado mais de uma vez, antes de ser chamado o método DestroiConexao.

Boa tarde pessoal, Mais um super palestrante confirmou presença no Dia do ACBr 2019, Thulio Bittencourt, clique aqui e saiba mais. Att. E ainda tem mais, Também contaremos com a presença de William Duarte, mais um ótimo palestrante a nos prestigiar . Clique aqui e conheça mais. Att.

Boa tarde Pessoal, Os documentos: CT-e - Conhecimento de Transporte Eletrônico e CT-e OS - Conhecimento de Transporte Eletrônico Outros Serviços, possuem um evento chamado: Prestação do Serviço em Desacordo. O autor desse evento, ou seja, que envia ele para a SEFAZ é o tomador do serviço. Esse evento, permite ao tomador informar ao Fisco que o CT-e/CT-e OS que o relaciona esta em desacordo com a prestação do serviço. O tomador tem um prazo máximo de 45 dias a contar da data de autorização do CT-e/CT-e OS para enviar o evento. Detalhe importante: O evento tem que ser enviado para a SEFAZ do emitente do CT-e, supondo que o emitente seja de São Paulo devemos: 1. Configurar o componente para a UF do Emitente (Configuracoes.webservices.UF := 'XX'; // onde XX é a UF do Emitente do CT-e) 2. Ao alimentar o componente informar em cOrgao a UF do Emitente do CT-e. Como montar a rotina para enviar o evento: ACBrCTe1.EventoCTe.Evento.Clear; with ACBrCTe1.EventoCTe.Evento.Add do begin infEvento.nSeqEvento := 1; // Para o Evento de Prestação do Serviço em Desacordo nSeqEvento sempre = 1 InfEvento.cOrgao := UFtoCUF(xUF); // Devemos informar a UF do Emitente do CT-e infEvento.chCTe := Copy(ACBrCTe1.Conhecimentos.Items[0].CTe.infCTe.Id, 4, 44); infEvento.CNPJ := xCNPJ; // CNPJ do Tomador infEvento.dhEvento := now; infEvento.tpEvento := tePrestDesacordo; infEvento.detEvento.xObs := trim(sOBS); // minimo 15, máximo 255 caracteres end; iLote := 1; // Numero do Lote do Evento ACBrCTe1.EnviarEvento(iLote); No exemplo acima o XML do CT-e/CT-e OS foi carregado, mas não se faz necessário, caso não deseja carregar o XML basta informar a chave (44 dígitos) ao campo chCTe. No campo xObs deve constar uma observação do tomador que justifique o desacordo do serviço prestado. Em caso de dúvidas, clique aqui para criar um novo tópico.

Não dessa maneira... mas sabendo o nome do XML retornado pelo ACBr ( que e informado na resposta), você poderia comandar um Rename do arquivo...

Este erro é por motivo do D7 esta achando as .bpl nos caminhos do xe2 siga os passo no meu blog http://isaquesp.blogspot.com.br/2011/09/varias-versoes-do-delphi-instaladas-sem.html que resolverá seu problema e ainda poderá usar o ACBr nas duas versões do delphi sem conflito. Entenda: Você tem o D7 e XE2 instalados na sua maquina, com certeza o XE2 instalado por último. Ao executar o D7 ele busca informações no path do XE2, mas o XE2 não tinha o ACBr instalado, por este motivo não tinha BPL, compilado no XE2, dai o D7 só achava as BPLs que foram geradas por ele. Depois vc resolveu instalar o ACBr no XE2, gerando as BPLs para este (XE2), mesmo desinstalando as BPLs não são apagadas Ao executar o D7 agora ele vai novamente no path do XE2, e encontra, as tal BPLs, dai o que acontece? Corta pra mim... o erro acima reportado por vc. Executando os passos postado no meu blog, cada delphi ao ser executado seta o path dele, sobrepondo o path do sistema, fazendo com que cada delphi só busque as BPLs no path definido, te possibilitando estar com os dois delphi abertos ao mesmo tempo e cada um compilando e buscando as BPLs do seu path, e ainda os dois usando o mesmo fonte do ACBr. Espero que este post esclareça de uma vez por toda, as dúvidas de MUITOS que tem duas ou mais versões do delphi instaladas no computador.