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));