Douglas Colombo

Sim, entendo @Renato Rubinho assim como o campo do número da DI, o código do produto, ... Existem alguns problemas neste XML, porem uma simples validação na data de despacho para preencher no componente ACBR como null já resolveria, hoje gera erro de conversão e não prossegue o processo de importação. Os demais campos como são texto, mesmo sendo obrigatórios, caso vier em branco não causa o erro que mencionei a cima, seria apenas esta validação para seguir o mesmo padrão dos demais tipos de campos pois não deveria barrar a leitura do XMl somente por conta deste campo data, mesmo seguindo o padrão que comentou do manual da NFe, os demais campos a importação é aceita mesmo estando em branco.

Não somos nós quem geramos, este XML é enviado do despachante da mercadoria para os clientes, não temos envolvimento na geração deste xml pelo despachante no siscomex e ocorre este problema com vários despachantes.

Sim, porem como comentei, este xml não é gerado manualmente, é gerado diretamente do espelho de uma DI (automaticamente), não temos como alterar este padrão de exportação, a única alternativa é tratar na leitura... com um tratamento em caso de erro nesta conversão de texto pra data.

Bom dia, conseguiram verificar? Este xml que eu coloquei é gerado no sistema do siscomex, é uma nota de espelho, não é válida, não é a DI e nem nada, apenas um espelho para ser importada e após emitida pelo comprador. Porem está dando erro conforme documentei no início do tópico. Poderiam revisar para adequar, visto que não é somente este espelho que da o problema, a maioria vem desta forma... https://www.fazcomex.com.br/importacao/nota-fiscal-de-importacao/

É um xml espelho de DI para declaração de importação... veio do SISCOMEX.

Ao efetuar a importação de um XML, ao executar a rotina de LerXml da unit pcnNFeR o campo dDesemb é do tipo TDateTime: Porem neste XML que tenho (que é válido), este campo é string e possui três caracteres: E ao executar esta linha, acaba gerando um erro de conversão: DanfeXml.xml Alguém poderia verificar esta questão, por gentileza? At, Douglas

Bom dia... Esta integração é com a maquininha diretamente ou apenas com a API da pagseguro?

sobre a questão de API varia de banco para banco... Hoje não existe nem um padrão 100% para carregar os arquivos OFX, calcula comunicação de API hehehehe. Sobre a leitura do OFX está funcionando certinho no ACBR, exceto este detalhe que documentei.

Bom dia, ao ler um arquivo OFX do banco bradesco, onde este arquivo possui um lançamento com a descrição PAGTO ELETRONICO TRIBUTO INTERNET --RECEITA FEDERAL/SP, o tipo deste lançamento é "D/DEBITO". Porem, existe uma validação estranha no código que se na TAG de descrição <MEMO> possuir a string "REC" automaticamente o arquivo passa o lançamento para o tipo "C/CREDITO" ficando inconsistente a informação do arquivo: Não existe nenhuma documentação para qual banco foi adicionado este IF para validar se continuará compatível. Vou alterar o código para validar também o valor se além de REC na descrição, o valor do lançamento for negativo (Visto que acredito que esta validação tenha sido feita por conta que o <TRNTYPE> não esteja vindo de forma correta): Desta forma resolveu o problema para lançamentos onde possuem na descrição "REC", como no caso de nosso cliente "RECEITA ...". Ficou apenas de validar se continuará funcionando para o banco em que fizeram este alteração. Lembrando que não encontrei em nenhum local informando pq tem este IF louco ali no meio pelo MEMO, acredito que seja um banco que não está seguindo o padrão do OFX. At, Douglas ACBrOFX.pas

Resolvido. O tamanho do nosso número default está 10 para boletos UNICRED. Alterei manualmente para 12 e resolveu o problema.

Conferindo nos fontes, o CNAB não é pois o próprio ACBR valida qual é o comprimento da linha para definir o cnab.

Pensei talvez em formatação do CNAB do retorno, estou testando isto agora. O Retorno possui CNAB 240.

Olá, estou utilizando o componente TACBrBoleto para efetuar a leitura de um arquivo de retorno do banco UNICRED. Estou enfrentando um problema ao ler o nosso número pela propriedade "list[i].NossoNumero", para estar pegando o nosso número da posição errada no arquivo. Exemplo de nosso número real (744 Posição do título no arquivo de retorno que está sendo lido: Conteúdo que o acbr está retornando na propriedade de nosso número (list[i].NossoNumero = 7): Por conta disto, parece que o componente não está capturando o valor do nosso número da posição correta. Tem alguma configuração talvez que influencie nisto? Desde já agradeço a disposição do pessoal que comentar neste tópico.

Olá pessoal, tudo bem? Ao emitir um MDFe pelo ACBR e tentar imprimi-lo a partir de um XML MDFE válido, está gerando o erro da imagem a baixo na linha em destaque ao carregar o modelo fr3 da damdfe. Alguém tem alguma ideia do que poderia ser? Desde já agradeço a atenção de todos. MDFE_DAMDFeRetrato.fr3

Olá, por gentileza... subam um ajuste na rotina TBoletoW_Sicredi_API.DefinirURL . Esta rotina está obrigando a sempre ter um título dentro do componente carregado mesmo que eu não vá utilizar a operação tpAltera (Que é a única que usa o nosso número). Está obrigando pois tem um comando que solicita o nossoNumero de um título carregado dentro do componente: aNossoNumero := OnlyNumber( ATitulo.ACBrBoleto.Banco.MontarCampoNossoNumero(ATitulo)); No meu caso, fui utilizar a operação tpConsulta, como não tenho nenhum registro dentro do componente, está gerando um AV. Colocar tratamento para validar se ATitulo existir, então funciona para todas as situações da rotina: if (ATitulo <> nil) then aNossoNumero := OnlyNumber( ATitulo.ACBrBoleto.Banco.MontarCampoNossoNumero(ATitulo));

Olá, ao consultar no endpoint *DistribuicaoDFe* as vezes vem notas repetidas (Uma NFe resumida e outra completa, porem a mesma NFe). 1- Quando vem a nota completa, é sinal que ela já foi manifestada? 2- Quando vier apenas o resumo e for feito o manifesto dele, ao fazer um novo get no *DistribuicaoDFe* virá outro registro com outro NSU para esta mesma nota?

Se possível, adicionar mais estas propriedades para manipulação externa ao componente do acbr: frxReport.EngineOptions.SilentMode := True; frxReport.EngineOptions.IgnoreDevByZero := true; frxReport.EngineOptions.IgnoreExprError := true; frxReport.EngineOptions.NewSilentMode := simSilent; frxReport.EngineOptions.EnableThreadSafe := true; Estão dentro da use ACBRNFEDANFEFRDM e são importantes para caso de algum erro no relatório, não fique com a requisição congelada na api do ISAPI DLL e consiga seguir com a vida da requisição dentro do backend...

O problema parece ser ao modificar via programação a propriedade Child de algum componente visual. No nosso caso como o default do relatório já é o "CanhotoCabecalho.Child := CanhotoCabecalhoPadrao" apenas inserindo um if de validação em cima da execução da rotina, já resolve o problema: Mas caso quisermos trocar essa propriedade via programação, vai dar problema na geração do relatório... Então isto seria uma solução temporária apenas, para funcionar a geração do relatório via ISAPI DLL com este modelo da danfe ( DANFeRetrato.fr3 )

Esta é a função dentro do fr3 da DANFE que está com problema ao gerar PDF via ISAPI DLL: procedure InicializaPosicaoCanhoto(); begin if Trim(VarToStr( <Parametros."poscanhotolayout"> )) = '0' then begin if Trim(VarToStr( <Parametros."poscanhoto"> )) = '2' then CanhotoCabecalho.Visible := true else CanhotoCabecalho.Visible := <Parametros."poscanhoto"> = '0'; CanhotoCabecalho.Child := CanhotoCabecalhoPadrao; CanhtoCabecalhoBarra.visible := false; CanhotoRodape.Visible := <Parametros."poscanhoto"> = '1'; CanhotoRodapeBarra.Visible := false; end else begin if Trim(VarToStr( <Parametros."poscanhoto"> )) = '2' then CanhotoCabecalho.Visible := true else CanhotoCabecalho.Visible := <Parametros."poscanhoto"> = '0'; CanhotoCabecalho.Child := CanhtoCabecalhoBarra; CanhotoCabecalhoPadrao.visible := false; CanhotoRodape.Visible := false; CanhotoRodapeBarra.Visible := <Parametros."poscanhoto"> = '1'; end; end;

Identifiquei onde está o problema... nos eventos dentro do DANFE "DANFeRetrato.fr3". Vou ver se consigo identificar qual a função dentro do relatório que está genrado o erro. Outra coisa, a propriedade SilentMode do frxReport assim como a ThreadSafe, precisa estar acessível externamente para que possa ser configurável...

Identifiquei que ao marcar esta propriedade como "frxReport.EngineOptions.SilentMode := True;" não congela mais ao executar o prepareReport, porem também não gera o pdf...

Acredito que seja algo relacionado com threads que provavelmente estão sendo utilizadas para montar/gerar o relatório...

O erro ocorre no comando: "Result := frxReport.PrepareReport();" - Função: "function TACBrNFeFRClass.PrepareReport(ANFE: TNFe): Boolean;" - unit: "ACBrNFeDANFEFRDM". Não gera exceção nada, apenas fica em uma espécie de espera/loop. as propriedades ShowProgress e ShowDialog estão false.

Mas eu gero relatórios via isapi DLL com o fast report... gero relatório de vendas, ficha de clientes, ... porem o danfe está ficando em uma espécie de loop dentro do comando "FDanfe.ImprimirDANFEPDF(FNfe.NotasFiscais.Items[x].NFe);"

Olá, gerei uma dll isapi com o componente TACBrNFe e TACBrNFeDANFEFR do acbr. A emissão da nfe ocorre corretamente e ela fica validada e aparece no site da receita. Porem, ao executar a rotina "FNfe.NotasFiscais.Items[0].ImprimirPDF", congela/trava a rotina. Tentei com "FNfe.NotasFiscais.Items[0].Imprimir" porem ocorre o mesmo problema. Ao executar a mesma rotina em um servidor standAlone, funciona normalmente, alguém sabe o que poderia saber? OBS: No standalone ao executar este comando "ImprimirPDF" apenas é gerado o pdf da nfe na pasta que preenchi nas configurações, não tem nada de visual na aplicação, não abre o exibe o pdf, não exibe o "carregando" do componente para montar o pdf e nem nada, apenas gera o pdf na pasta.