Douglas Colombo

Minha rotina Rotina do exemplo do "AcbrNFe"

Olá, mas qual o caminho deste exemplo, não teria como compartilhar? O exemplo está neste caminho talvez? Exemplos\ACBrDFe\ACBrNFe\Delphi porem não estou encontrado, pois a forma que imprime ali é igual a que eu já tenho hoje.

@Juliomar Marchetti teria talvez um exemplo de funcionando, pois não consegui encontrar por aqui o que foi alterado e como adequar esta questão. Poderia me auxiliar?

Conferi no change-log do ACBrNFe-change-log.txt e não encontrei nada relacionado a esta mudança. Conferi também no ACBrNFeDANFEFR-change-log.txt e também não encontrei.

Poderia me mandar o link do log ou aonde encontra-lo? eu atualizo meus fontes pelo GITHUB do ACBR atualmente. Mas é apenas uma mova propriedade ou preciso alterar a lógica da rotina, teria algum exemplo em relação a esta alteração?

Olá, nas últimas atualizações do ACBR, a impressão agrupada de NFe parou de funcionar. Houve alguma alteração nesta rotina, talvez? Pois antes eu conseguia gerar um único PDF com todas as DANFES, agora ele gera para cada DANFE, um arquivo PDF. Te, alguma propriedade nova ou nova configuração, talvez? Na imagem, foi gerado 3 PDFS, sendo que era para ficar tudo unificado em um único: Minha rotina que antes agrupava: Desde já agradeço a atenção.

Era Schemas mesmo... atualizei deu certo.

Boa tarde, tudo bem? para NFCe emitida no RS com pagamento em PIX, estamos alterando: cAut = endtoendID da transação pix tPag = 17 Porem a receita está retornando: Alguém passou por isto também? Será problema de schemas? OBS: Atualizei os fontes do ACBR pelo github e reinstalei ele... porem o problema persiste.

Bom dia, estou com o mesmo problema em um cliente do MT ao emitir uma NFE... porem não sei dizer se a nota foi emitida pois tenho de retorno apenas este erro: Aconteceu no outro dia algumas vezes, clonei a nota e reemiti com outra sequência, então funcionou e não aconteceu mais. Porem voltou a acontecer hoje.

Bom dia, estou passando pela mesma situação, porem meus lotes possuem apenas 1 NFe em cada. Isto acontece para vários clientes, estão emitindo normalmente as notas e volta e meia, alguma no meio da este problema, retorna o XML da NFe sem a tag: <protNFe versao="4.00"> E automaticamente sem tudo que está dentro dela. Então no momento de imprimir o PDF, fica a mensagem por cima do PDF "SEM AUTORIZAÇÃO DE USO DA SEFAZ". Porem, ao consultar diretamente a nota pela chave de acesso na receita, lá está o número do protocolo e sua data e hora. Isto acabou virando um problema meio crônico pois acontece em todos clientes porem somente as vezes e não estou conseguindo contornar. Alguém conseguiu solucionar esta questão, talvez?

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