Douglas Colombo

E não teria a possibilidade de ter uma opção/configuração para agrupar todos os XMLs em um único PDV, visto que carrego todos dentro do componente, uma função neste sentido nativa no próprio ACBR?

Bom dia pessoal, tudo bem? saberiam nos informar algo sobre o recurso como ficará ou o como podemos proceder, implementar no ACBR ou teremos que tratar separadamente dos fontes oficiais do acbr, ... Lembrando que é um recurso bem importante e utilizado por bastante gente.

@Juliomar Marchetti pelo que está documentado no link que mandou, foi removido o recurso de gerar multiplos PDFs no mesmo arquivo. O ACBR não fornecerá mais isto então? Por qual motivo foi tirado, não entendo pois é um recurso importante, principalmente quando usado para impressão ou compartilhamento onde gera um único documento com todos os documentos anexados.

@Juliomar Marchetti ali no exemplo, gerou 4 PDFs de saída... Faltou alguma configuração nova, talvez?

Segue exemplo com o problema relatado. Carreguei 4 xml's e na hora de gerar o PDF, antes gerava um único desta forma, agora geram 4 de saída. NFE-IMPRESSAO-MULTIPLA.zip Agora pretendo atualizar mais seguidamente as próximas versões.

@Juliomar Marchetti acredito que não... normalmente atualizo entre 2 a 3 meses, no máximo.

@Juliomar Marchetti vou montar um exemplo aqui... Mas eu também utilizava normalmente até atualizar os fontes a uns 20 dias atrás. Vou montar o exemplo e depois compartilho aqui.

Boa noite, estou ainda enfrentando este problema. Alguém sabe se é um BUG no ACBR, talvez? Se for, alguém sabe se será corrigido ou se eu posso alterar os fontes e subir a correção para algum local?

@Juliomar Marchetti o problema parece estar nesta rotina TACBrNFeFRClass.ImprimirDANFEPDF: Teve alteração em algo próximo a esta rotina: Que mexeu em algo relacionado, porem não deu para identificar ainda se foi esta alteração que está gerando este BUG:

@fabiofranzini As alterações que comentou foram estas: Porem não deveria ter tido impacto na impressão de multiplos PDF's de DANFE...

@Juliomar Marchetti mas isto é um BUG no ACBR, precisarei ajustar manualmente por aqui ou foi alterado o funcionamento do recurso? Não estou entendendo como solucionar este problema... Em que lugar fica o LOG do SVN?

Exatamente, eu olhei vários exemplos e nenhum está deixando gerar multiplas DANFES no mesmo PDF.

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.