Valdir Dill

Boa tarde, Funcionando beleza! Obrigado! Agora surgiu uma outra dúvida, rs. Estou fazendo a consulta assim: - VResponseRPS := ACBrNFSeX1.ConsultarLoteRps(VProtoclo, VLote); - VSit := StrToSituacaoLoteRPS(VOK, TNFSeConsultaLoteRpsResponse(VResponseRPS).Situacao); Após a consulta, o valor de VSit está sLoteProcessadoSucesso. Isso indica que o lote foi recebido com sucesso, mas não necessariamente que a nota está autorizada, certo? Como verifico agora se a situação dessa nota é autorizada ou talvez cancelada? Obrigado!

Show. Obrigado.

Boa noite, Sim. Mas o nome do arquivo recebe apenas o sufixo "-NFse", conforme print anexo. Também estou anexando o XML que é salvo nessa pasta \Notas\. Obrigado -nfse.xml

Não sei se tem a ver, mas, na linha AItemIndex := FindObject(AItem, TComparer<TObject>.Construct(CompNFSePorNumero)), após essa linha ser executada, o AItemIndex fica com valor -1. Vide print anexo.

Boa noite, Segui as instruções e parece que houve progresso. O valor de AuxNode agora é diferente de nil e NumNFse tem valor 680, corretamente. Uma dúvida: como recupero o número da nota. Pelo que entendi, deveria pegar essa informação pela ACBrNFSeX1.NotasFiscais.Items[0].NFSe.Numero, isso após fazer a consulta. Mas essa propriedade não está sendo alimentada. Ou seria outra forma? Obrigado.

Boa noite, Sim, mas ele não passa por essa linha NumNFSe := ProcessarConteudoXml(AuxNode, tcStr). Mesmo com F8, ele para na linha 529 (que não tem código). Mas na linha 526, ele não para. Quando para na linha 529, NumNFSe está com valor '' (sem nenhum valor). Obrigado.

Não, ele pula essa linha. Veja o print anexo. No break point dessa linha NumNFSe := ProcessarConteudoXml(AuxNode, tcStr), ele não para. Mas na linha 529 que nem código tem, ele para. O valor de NumNFSe, nesse momento, está sem nada.

Está bastante esquisito. Não estou conseguindo entender direito o debug. Olha só, ao passar por if AuxNode <> nil then, AuxNode tem valor nil. Mas mesmo assim ele entra nesse begin -> if AuxNode <> nil then begin... Além disso, tem vários pontos que o debug não para. Se eu colocar um ponto de parada na linha if AuxNode <> nil then, ele não para ali. Bem estranho.

Sim, são diferentes. Prints anexos.

Boa tarde, Ainda não está trazendo os dados da nota. Testado inclusive no Demo. Print anexo. Não sei se pode ter relação, mas debugando verifiquei que, ao passar pela função TratarRetornoConsultaLoteRps(, em uma das linhas dessa função, ele chama a seguinte: ANodeArray := ANode.Childrens.FindAllAnyNs('CompNfse'); Aí vai para a função FindAllAnyNs( da ACBrXmlDocument.pas. Nesta função, a linha 947 (if Node.LocalName <> Name then continue), o LocalName aparece com valor "access violation...", conforme print anexo.

Show. Obrigado.

Bom dia, Certo, mas qual seria a sugestão nesse caso? Aguardar o provedor corrigir a inconsistência ou há algo que se possa fazer para contornar isso? Obrigado

Boa noite, Não entendi @Rafael Dias. Pelo que você está dizendo, o problema está sendo causado por uma falha no XML retornado pelo provedor, é isso? Obrigado.

Bom dia, Segui essa sua orientação, mas não consegui descobrir qual exatamente é a causa. Os arquivos são salvos em disco. Estou anexando eles aqui. Mas o componente não é alimentado. O que me parece, o problema está no fato da linha 483 da ACBrNFSeXProviderABRASFv1 -> Response.Situacao := ProcessarConteudoXml(Document.Root.Childrens.FindAnyNs('SituacaoLoteRps'), tcStr); Nessa linha o componente busca uma variável "SituacaoLoteRps", mas essa variável não existe no XML retornado na consulta. Obrigado! 637615129589302423-con-lot.xml 637615129589302423-con-lot-soap.xml 637615129589302423-lista-nfse-con-lot.xml 637615129589302423-lista-nfse-con-lot-soap.xml

Bom dia Estou fazendo a consulta de uma nota (ISSCuritiba) enviada anteriormente, da seguinte forma: ... Var VResponseRPS : TNFSeConsultaLoteRpsResponse; VXMLRet : String; begin VResponseRPS := ACBrNFSeX1.ConsultarLoteRps('637615129589302423', '17'); VXMLRet := TNFSeConsultaLoteRpsResponse(VResponseRPS).XmlRetorno; Neste momento VXMLRet tem todos os dados da nota. A dúvida é: como pego o número da nota, código de verificação, data emissão, ...? Quais propriedades do componente devem ser lidas? Tentei várias formas, inclusive alimentar o ACBrNFSeX1.NotasFiscais, mas não está dando certo. Obrigado!

Bom dia Italo. Sim, está configurado as 4 margens. Tanto é que aqui em laboratório e em outros usuários não ocorre problemas. Apenas nesse cliente. Acredito que possa ter relação com alguma configuração que o Fortes pega da impressora no Windows. Obrigado!

Bom dia, Alguma ideia do que pode estar causando esse corte da impressão na margem direita? DANFE em anexo. Testado em nossa máquina e o problema não ocorre. No cliente acontece tanto na impressão de fato, quanto no preview em tela. Será que pode ser configuração da impressora padrão? O que poderia ser? Obrigado!

Boa tarde, Só para registrar um feedback. Não consegui um solução completa, mas deixo registrado como contornei a situação. Fiz a reinstalação do Acbr, marcando a opção (opção deixar somente a LibXX) que o @Juliomar Marchettisugeriu, mas não surtiu efeito. Marquei inclusive a opção "apagar arquivos antigos". Na compilação direta no F9 não funciona de jeito nenhum. Deixei processando por 14 minutos e não saiu do lugar. Como mencionei na abertura do tópico, ele vai progredindo e compilando várias units, mas quando chega na AcbrTEFPayGoWebComum.pas não vai para frente. Não trava, apenas fica "processaaaaaando.....". A solução que achei foi: primeiro faz um build (shift+F9). Ele demooooora também na AcbrTEFPayGoWebComum.pas, mas em 8 minutos termina. Após isso compilo (F9) e vai rapidão. Lembrando que se não vincular a ACBrTEFDClass na uses da minha aplicação, aí o F9 (até sem build) compila em menos de 30 segundos. Obs.: também não é problema de máquina (i5 + 8GB). Obrigado!

Bom dia, Estamos tendo problemas ao tentar complicar uma aplicação para Android. Delphi 10.4. Temos vários units do Acbr vinculadas à aplicação e compila sem problemas. Mas, quando incluímos a ACBrTEFDClass na uses, acontece a situação abaixo detalhada. O problema: Ao tentar compilar, inicia-se o processo normal, mas, quando chega na AcbrTEFPayGoWebComum.pas, o processo não prossegue. Fica "processando" e não conclui. Deixamos por vários minutos e fica sempre nessa tela. Testamos tanto na nossa aplicação, quanto no demo Acbr (print anexo). Alguma sugestão de solução? Obrigado!

Bom dia, Arquivos em anexo. 2021_Junho_CNAB400_UNICRED_TODAS_0000814156_0590_08062021_01 (3).RET GR - COB136 - Layout CNAB 400 - Retorno.pdf MANUAL UNICRED CNAB 240 E 400.pdf

Bom dia, Na leitura de retorno, o Acbr está lendo o nosso número com 17 caracteres, procedure TACBrBancoUnicredES.LerRetorno400(ARetorno: TStringList), linha 251 -> fpTamanhoMaximoNossoNum := 17 e, depois na linha 283 -> NossoNumero := Copy(Linha,46, fpTamanhoMaximoNossoNum); Já na constructor TACBrBancoUnicredES.create(AOwner: TACBrBanco), linha 84, o componente define o tamanho do nosso número como 10 -> fpTamanhoMaximoNossoNum := 10; Fiquei um pouco confuso, pois pelo que li no manual do banco, o nossonumero tem 10 dígitos. Porém o componente está hora usando 10 e hora 17. Podem, por gentileza, me esclarecer sobre isso? Obrigado!

Bom dia, Na leitura de retorno, o Acbr está lendo o nosso número com 17 caracteres, procedure TACBrBancoUnicredES.LerRetorno400(ARetorno: TStringList), linha 251 -> fpTamanhoMaximoNossoNum := 17 e, depois na linha 283 -> NossoNumero := Copy(Linha,46, fpTamanhoMaximoNossoNum); Já na constructor TACBrBancoUnicredES.create(AOwner: TACBrBanco), linha 84, o componente define o tamanho do nosso número como 10 -> fpTamanhoMaximoNossoNum := 10; Fiquei um pouco confuso, pois pelo que li no manual do banco, o nossonumero tem 10 dígitos. Porém o componente está hora usando 10 e hora 17. Podem, por gentileza, me esclarecer sobre isso? Obrigado!

Boa noite, Estamos tendo esse erro abaixo no envio de email pelo AcbrMail. SMTP Error: unable to send Mail data. 554 5.7.1 rejected for policy reason 503 5.5.1 Error: need RCPT command O problema ocorre apenas quando tem anexo. Parece se alguma "desconfiança" do servidor em relação ao anexo. Mas são simples XML. Nada de "perigoso", rs. Alguma sugestão do que pode ser a causa disso? Obrigado.

Boa noite, Não, não invalida. Na tabela anterior havíamos feito isso, ou seja, mexemos nos 27 arquivos antes de liberar para o usuário baixar. E funcionou legal. Mas concluímos que dá bem menos trabalho incluir esse stringReplace que citei na postagem anterior. Abraços

Bom dia, Só para contribuir... O erro ocorreu aqui também. Acontece porque na linha 6093 de todos os arquivos .csv, na tabela 21.1.H e agora também na 21.1.I , traz um texto com duas aspas duplas repetidas. 39233090;01;0;""Ex" 01 - Isso faz com que o quebralinha gere um erro. A solução que adotamos foi -> VLinha := StringReplace(VLinha,'""Ex"','"Ex',[rfReplaceAll]), direto na nossa aplicação, sem mexer nos fontes Acbr. Obrigado