Valdir Dill

Boa tarde, Em contato com a SEFAZ-RN, informaram que o problema foi sanado e passa a valer a nova URL, como era para ser. Fizemos um teste enviando uma nota e foi autorizada noralmente. Obrigado

Bom dia, Sim @Daniel Simoes. Também estou com esse mesmo erro. O mesmo cliente emitindo NFCe para essa SEFAZ-RN, mas sem ter atualizado aplicação, ou seja, sem que os ajustes do Acbr tenham sido incorporados, a nota é autorizada. Mas com tudo atualizado, ocorre o erro erro" endereço do site da uf da consulta via qrcode diverge do previsto" . A mudança estava mesmo prevista para 18.05 e ainda consta lá na SEFAZ -> https://www.sefaz.rn.gov.br/materia/atencao-desenvolvedores-nfc-e/

Bom dia, Encontrei uma solução. Talvez não seja a melhor, mas funciona. Caso alguém tenha alguma contribuição para melhorá-la... De toda forma, posto-a para ajudar quem passar por dificuldade similar. - No evento beforePrint do RLReport: VImprimiuFooterDoGrupo := true; - No evento beforePrint da btHeader: PrintIt := VImprimiuFooterDoGrupo; - No evento afterPrint da btHeader: VImprimiuFooterDoGrupo := false - No evento afterPrint da summary: VImprimiuFooterDoGrupo := true; Obrigado!

Bom dia, Estou dificuldades em um relatório de contas a receber, com Fortes Report e com as seguinte estrutura: - Um TRLGroup - O TRLGroup contem: - Uma banda btHeader - Uma banda btDetail - Uma banda btSummary - Na banda btHeader é impresso o nome do cliente - O dataFields do RlGroup é o campo CODIGO_CLIENTE A ideia é que o relatório liste as contas de todos os clientes, mas agrupadas por cliente e, em cada grupo, mostre o valor total (banda summary). O relatório funciona bem, exceto por um probleminha: quando muda de página, dependendo do espaço que tem no final da página, ele imprime a btHeader e a btDetail na página atual. Isso deveria fazer com que o início da próxima página trouxesse apenas a btSummary do cliente Adilson, cuja btHeader já foi impressa no final da página anterior. Porém, o que acontece é que na página seguinte, ele imprime a btHeader do próximo cliente (Alberto) e depois o summary do Adilson. Na sequência, vai imprimir os dados do cliente Alberto e repete a btHeader de Alberto. Como eu poderia fazer para impedir que a btHeader de Alberto fosse impresso na página 2, sem que antes seja impresso o summary de Adilson? Em anexo um exemplo do que acontece. Obrigado

Boa noite, @Juliomar Marchettiqual seria o exemplo do Acbr? Eu analisei o ACBrHTTPTeste. Mas, pelo que entendi, só funciona com certificado A1. Com A3 não consegui. Poderia passar mais detalhes? Obrigado

Boa tarde O tíquete que retorna não é o que você vai usar na rota que faz o download. O código para baixar o json vem no webHook. Eu tinha conseguido chegar até o ponto de receber o código para download, mas o download não funcionava. Não retornava nada. Agora nem o webHook está mais funcionando. Não dá erro nenhum, mas a API não envia o body para o webHook. Acredito que estejam ajustando. Espero ter ajudado.

Boa noite, Estamos com problema ao consumir esta url -> https://piloto-cbs.tributos.gov.br/servico/calculadora-consumo/api/calculadora/dados-abertos/aliquota-uf?codigoUf=29&data=2025-01-01 O erro que ocorre é "The requested URL was rejected. Please consult with your administrator". O problema não ocorre em toda consulta, apenas se for acionada mais de uma vez num período inferior a, mais ou menos, 30 minutos. Imagino que essa rota tem um limite de consultas anônimas. Alguém tiver mais informações sobre a situação e se há como utilizar essa rota com mais consultas por hora, por favor, compartilhem. Obrigado!

Boa tarde, Só vincular com a classe ->IBSCBS.tpOper := ACBrNFSeXConversao.togNenhum;

Esse exemplo do demo não traz a situação. Veja o arquivo anexo é de uma consulta por chave DPS. Troquei umas mesnagens com o Italo há alguns dias e, pelo que entendi, não é possível fazer uma consulta de situação de NFSe, assim como se faz com outros DFes. A solução que encontramos para casos assim foi: 1 - Consulta a nota pelo DPS. Se retornar uma chave de NFSe, então é porque ela foi autorizada em algum momento. Mas isso não significa que seu status atual é ainda autorizada. 2 - Fazemos uma consulta para ver se essa nota está cancelada, assim: ACBrNFSeX1.ConsultarEvento(FDQNFSe.FieldByName('CHAVE_NFSE').AsString, ACBrNFSeXConversao.teCancelamento, 1); With ACBrNFSeX1.WebService do begin With ConsultarEvento do begin VRetObj := TJSONObject.ParseJSONValue(XmlRetorno) as TJSONObject; VRetArr := VRetObj.GetValue('eventos') as TJSONArray; if StrTotpEvento(VG.FOKTrue, VRetArr.GetValue<String>('[0].tipoEvento')) <> ACBrNFSeXConversao.teCancelamento then //só para garantir que no futuro essa consulte mude e quebre o código aqui. begin ChamaErro('A consulta ao evento ocorreu com sucesso, mas retornou um evento (' + VRetArr.GetValue<String>('[0].tipoEvento') + ') diferente de cancelamento.'); exit; end; //esse duplo DecodeBase64( foi copiado da PadraoNacional.Provider.pas. Pelo que parece, no caso do evento, o WS devolve o valor do XML duplamente decodado. VXML := DecodeBase64(DecodeBase64(VRetArr.GetValue<String>('[0].arquivoXml'))); //não faz o UnZip( pqe vai gravar no BD zipado. ShowMessage('Sim a nota está cancelada.'); ........ end; Espero ter ajudado!

ACBrNFSeX1.ConsultarNFSePorChave(VChaveNFSe); With ACBrNFSeX1.WebService do begin With ConsultaNFSe do begin if Sucesso then begin Var VRetorno : TJSONObject; VRetorno := TJSONObject.ParseJSONValue(XmlRetorno) as TJSONObject; VXML := UnZip(DecodeBase64(VRetorno.GetValue<String>('nfseXmlGZipB64'))); VRetorno.Free; end; end; end;

Boa tarde, Só para contribuir, ok? Aqui nós dependemos do Enterprise, que custa 2 vezes mais, rs.. justamente e tão somente por causa do Firedac. Então, se você vai ter que refazer todo seu código para utilização de novos componentes, eu recomendaria usar o Zeos, por exemplo, que é free. E aí você pode ficar no Rad Professional. Acredite, não é apenas o valor de aquisição da licença atual. Você vai ter esse custo, pelo menos a cada 2 a 3 anos, pois as versões Delphi depois do 7, sempre vêm com bugs e são corrigidos em updates futuros. Se você não tiver mais suporte da licença, precisa comprar de novo. Aí você começa a usar e vai criando dependência. Compra hoje e daqui 2,3, ... anos você se obriga a comprar novamente. Pelo menos nossa experiência está sendo assim. Nós não temos como fugir do Firedac, pois o custo seria maior por conta do tamnanho que o sistema está hoje. Se nao fosse isso, com certeza nossa opção seria o Delphi Pro + Zeos. Esperto ter ajudado! Abraços

Boa tarde, Alguém conhece alguma rotina ou componente (Delphi) que vabilize saber onde (coordenadas) se clicou em um .pdf? Já tivemos algum progresso utilizando com API Hook, mas não conseguimos fazer funcionar legal. Queremos fazer um assinador de .pdf com certificado digital. Estamos usando a dll ChilKat, mas ela não tem essa opção. Assinar funciona tudo beleza, mas para posicionar o quadro da assinatura é preciso enviar os valores (margens). Funciona, mas se pudéssemos abrir o pdf para o operador clicar em uma área livre do documento e aí retornar as coordenadas de onde foi clicado, seria muito mais prático. Assim como fazem o Adobe, gov.br, ... Obrigado!

Boa tarde, Temos um caso aqui que é parecido (se não for igual) ao do colega @bfbraz Um MDFe que foi autorizado e encerrado no dia 18/04. Quando efetuamos a consulta dele com -> ACBrMDFe1.Consultar, ele retora ACBrMDFe1.WebServices.Consulta.cstat = 132, ou seja, encerrado. Porém o ACBrMDFe1.WebServices.Consulta.procEventoMDFe.Count é igual a 0. Aí nossa regra de negócios, ao buscar os eventos vinculados ao MDFe, não encontra o cancelamento e, por conseguinte, não consegue tratar. Até poderia pegar só o ACBrMDFe1.WebServices.Consulta.cstat, mas aí não temos os demais dados (data de encerramento, protocolo de encerramento,...). Obrigado!

Bom dia, Estávamos com esse erro desde sexta passada, que foi quando iniciou a obrigatoriedade das MEIs usarem o novo serviço. Mas, de ontem para cá, está melhorando gradativamente. Às vezes precisa fazer 2 ou 3 tentativas e ocorre esse erro, mas depois vai. É instabilidade no WS mesmo. Abs.

Boa tarde, Pela quantidade de componentes acredito que não seja a causa. Temos 5 componentes de terceiros, além é claro dos componentes Acbr. De toda forma, vamos tentar implementar sua sugestão sobre os paths (fontes e .dcus) assim que possível. Obrigado!

Boa tarde, Agradeço pela sugestão, mas não é a solução. Já havia tentado isso. Coincidência ou não isso acontece desde que instalamos o Delphi 10.4. Mas tranquilo, vamos tocando assim mesmo, rs. Obrigado!

Bom dia, Estou com uma dúvida/dificuldade não relacionada diretamente ao Acbr e sim ao Delphi... É assim: em uma classe declarada em uma unit qualquer, quando se clica com o mouse sobre o nome da classe e se estando com o ctrl pressionado, deveria abrir aquela unit onde eh criada aquela classe, certo? Ou então quando se posiciona o mouse sobre a classe, deveria aparecer um "popup" com o nome da unit onde aquela classe está declarada, correto? O problema é que aqui, isso ocorre, às vezes sim e, às vezes não... Nos faz falta isso, pois é algo bastante usado... No print anexo, peguei como exemplo a AcbrJSON.pas, mas poderia ser qualquer outra unit/classe, pois acontece em várias outras. O problema também não é a unit em si e sim a classe. Note que no segundo print, temos outra classe na mesma unit e nesta classe funciona direitinho, ou seja, mostra a unit onde a classe é criada. Alguma sugestão?] Obrigado!

Bom dia, Por motivos que não se faz necessário explicar aqui, nem sempre conseguimos atualizar o ACBrNFeServicos.ini em atualizações da nossa aplicação. Aí, pode ocorrer da versão da aplicação estar atualizada, mas o ACBrNFeServicos.ini não estar. Ele pode existir na pasta, mas desatualizado. Ocorrendo essa situação, nos surge a seguinte duvida: se o arquivo ACBrNFeServicos.ini estiver na pasta da aplicação, o Acbr vai sempre obrigatoriamente ler os endereços de WS do arquivo ou isso dependerá de DMDocEletr.ACBrNFe1.Configuracoes.Arquivos.IniServicos estar setado com "ACBrNFeServicos.ini"? Por exemplo, se DMDocEletr.ACBrNFe1.Configuracoes.Arquivos.IniServicos = '', mas ACBrNFeServicos.ini existir na pasta da aplicação, o que vai acontecer? O componente vai usar o arquivo mesmo assim ou vai buscar as URLs no .res que vai empacotado na aplicação? Obrigado!

Ok. Corrigido. Obrigado!

Bom dia, Estamos tendo o erro do print anexo quando se tenta consultar ACBrIBGE1.BuscarPorNome( ... O problema só ocorre se o ACBrIBGE.txt não existir ou, pelas configurações do CacheDiasValidade, for necessário atualizá-lo. Testamos inclusive no demo do componente. Obs.: se eu colocar o endereço https://servicodados.ibge.gov.br/api/v1/localidades/estados/41/municipios no browser, não dá erro e mostra a lista de cidades certinho.

Bom dia, Acredito ser instabilidade no WS. Também tivemos esse problema e logo em seguida, sem alterar nada, a nota foi aceita.

Boa tarde, Deixe-me ver se entendi. Devemos fazer a consulta das notas emitidas contra o cliente através do DistribuicaoDFePorUltNSU para listá-las. Em seguida ele (o usuário) manifesta as notas e aí deve ser feita uma nova DistribuicaoDFePorUltNSU para que desta vez o XML da nota retorne ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Items[I].XML, seria isso? Obrigado!

Boa tarde, Acho bem positiva a ideia. Ficaria bem mais transparente. Temos essa situação de usar os enumeradores (If Provedor = proGinfes then), mas acho seria muito simples adaptar o código à nova nomenclatura. Obrigado!

Já estamos testando/usando o AcbrNFSeX há algumas semanas. Por um lapso esquecemos que o novo componente não usa mais o cidades.ini para ver URLs, conforme inclusive está informado na documentação de migração de componente antigo para o novo. Peço desculpas... Obrigado!

Bom dia, No cidades.ini ainda está marcando esse município como vinculado ao provedor antigo, Fiorilli. [2101202] Nome=Bacabal UF=MA Provedor=SigCorp NomeURL_H=testeabrasfbacabal.sigcorp NomeURL_P=abrasfbacabal.sigcorp Obrigado.