Victor H. Gonzales - Panda

Boa tarde, Por padrão a impressão do cupom NFCe possui a configuração de 80mm, caso necessário ajustar essa largura precisamos informar o novo valor na propriedade LarguraBobina: <ACBrNFCeDANFeFPDF>.LarguraBobina := 65; //equivale a 65mm <ACBrNFCeDANFeFPDF>.LarguraBobina := 80; ou 302; //equivale a 80mm <ACBrNFCeDANFeFPDF>.LarguraBobina := 90; //equivale a 90mm Obs: LarguraBobina = 302 equivale a mesma coisa que a configuração de 80mm, somente para compatibilidade do create da classe que o valor padrão é 302 dos componentes.

Boa tarde Comunidade, As alterações do Informe Técnico já foram aplicadas ao componente, Monitor e ACBrLib. A previsão da SEFAZ para vigência Homologação / Produção é 01/07/2024, nesse momento você pode testar os novos meios de pagamento na geração do XML e deixar uma flag no seu sistema para quando chegar a hora de utilizar a nova tabela o seu sistema já está pronto. As classes do ACBr já fazem a escrita do XML, Leitura e impressão. Exemplo : Caso receber a rejeição 436 : Código do meio de pagamento inexistente, é porque ainda não está liberado a nova tabela para o uso. Uma observação ao Meio de Pagamento 05 fpCreditoLoja, que teve sua descrição alterada de Credito Loja para Private Label, isso devido ao fato de agora temos o enumerador 21 fpCreditoEmLojaPorDevolucao Crédito em Loja, que tem a finalidade "Crédito em loja decorrente de valor pago anteriormente, de devolução de mercadoria etc.". Eles possuem nomenclaturas parecidas, mas possuem finalidades diferentes, o que foi alterado foi a descrição e não código ou enumerador dos mesmos. De forma mais explicativa, o enumerador CreditoEmLojaPorDevolucao associa de forma mais clara as ocorrências relacionadas a esta forma de pagamento, tais como quando o cliente teve um crédito gerado por uma devolução de uma compra feita anteriormente, já o já existente CreditoLoja visa ser utilizado nas situações onde de fato é utilizado crediário ou cartão próprio da loja, ou seja, o chamado private label.

Por favor atualize seus fontes, pelo SVN do ACBr... Já subimos para o nosso repositório de fontes, modificações que podem corrigir algum dos itens referentes a esse tópico... Por favor atualize seus fontes, faça testes, e se possível comente em uma nova resposta, se o problema foi resolvido... Dúvidas, sobre o uso do SVN ? Clique aqui e veja um vídeo

Qual o CEP utilizado para testes?

não é o caso de usar o LayoutVersaoArquivo = 002 ?

Então emita nfe e não nfce pois os modelos de impressão são diferentes. A emissão pelo tipo de documento está errada

Fiz um teste de impressão utilizando o FastReport, não foi detectado nenhuma marca dagua, ou mensagem estranha na impressão que não fosse o padrão. porem fiz um ajuste que estava faltando um literal (Quadrado Vermelho).

tenta acessar o discord novamente

tem alguma coisa errada nesse boleto: 1: não existe mais Sacador / Avalista a alguns anos, esse é o Beneficiário Final 2: o intermediário, quando se faz uma transação geralmente boleto vinculado por exemplo, o Banco é o Beneficiário, o emitente é o Beneficiário Final. o que induz que esse intermediário do seu boleto é o beneficiário do mesmo. mas essa ficha sua está fora do padrão da febraban

https://cmsarquivos.febraban.org.br/Arquivos/documentos/PDF/Convenção da Cobrança - 05_02_2021_f.pdf página 27

o envio está sendo feito Sincrono? caso não, a chave consulta é idêntica a enviada originalmente?

Boa tarde Comunidade ACBr, no commit 33681 foi unificado o comportamento do componente ACBrNFe no que diz respeito a geração de PDFs. Desta forma para qualquer um dos geradores suportados, o comportamento de geração dos arquivos em PDF será respeitado igualmente, não havendo distinção de regras entre eles, o que causava problema ao se trocar de gerador e também dificultava o suporte. Esta mudança foi aplicada para preservar a compatibilidade entre os geradores, para que todos tenham a mesma regra de negócios aplicada, e também caso haja uma das configurações abaixo sejam aplicadas com sucesso a cada arquivo gerado de forma individualmente. Configurando : <ACBrNFe>.DANFE.UsaSeparadorPDF := True; <ACBrNFe>.Arquivos.SepararPorAno := True; <ACBrNFe>.Arquivos.SepararPorMes := True; <ACBrNFe>.Arquivos.SepararPorDia := True; <ACBrNFe>.Arquivos.SepararPorCNPJ := True; o sistema irá criar os arquivos com base nas informações do XML como exemplo : [CNPJ] [ANO] [MES] [DIA] C:\ACBr\pdf\9999999000191\2024\05\18\XXXXXXXXXXXXXXXXXXXXXXXXX.pdf C:\ACBr\pdf\9999999000191\2024\05\19\XXXXXXXXXXXXXXXXXXXXXXXXX.pdf C:\ACBr\pdf\9999999000191\2024\05\19\XXXXXXXXXXXXXXXXXXXXXXXXX.pdf C:\ACBr\pdf\9999999000191\2024\05\19\XXXXXXXXXXXXXXXXXXXXXXXXX.pdf C:\ACBr\pdf\9999999000191\2024\05\20\XXXXXXXXXXXXXXXXXXXXXXXXX.pdf Como era Antes O PDF era gerado usando como base o primeiro arquivo carregado ou conforme o gerador selecionado, eram gerado todos os PDF dentro do mesmo arquivo. Como ficou Agora É gerado um arquivo único com seu respectivo documento na respectiva estrutura conforme a configuração do componente, não há a possibilidade de gerar um arquivo com vários PDF juntos, o sistema irá gerar vários PDF cada um com seu documento fiscal respectivo. Eventos Para a impressão correta dos eventos, é necessário que a nota fiscal esteja também carregada no componente, e não somente o evento, pois existem informações que são necessárias abstrair do XML do Documento Fiscal. O não carregamento da NFe que originou o evento, pode ocasionar erros no fluxo de impressão ou campos faltando o preenchimento.

exato... quase todos os relatórios exigem o FastScript de alguma forma, pode não subir algum raise, mas ele não é executado com todos os recursos que ele é programado, podendo não ter o resultado como o esperado. os Exportadores só estão disponíveis na versão comercial do Fast, estamos pensando talvez em mudar isso, porem como o @EMBarbosa falou, o relatório pode não funcionar com a versão do Getit (versão basic) por falta de carregar todos os scritps, então pode ocorrer erros silenciosos. Dificil o FR3 hoje ou componente que não está com FastScript ativo.

o CaracTitulo você vai usar para informar se é carteira Vinculada ou Carteira Normal.

Servidores do RS devem voltar a normalidade todos os serviços nos proximos dias.

Carteira geralmente é 17 variação é 35 (modalidade) segue o mesmo padrão do CNAB

pelo o que andei olhando o Tomate ele pega vários equipamentos e só coloca o nome deles, não é bem um fabricante. então deve ser um protocolo genérico ESCPos possivelmente ESC/Epson.

Fonte : Portal da Nota Fiscal Eletrônica (fazenda.gov.br)

Por favor atualize seus fontes, pelo SVN do ACBr... Já subimos para o nosso repositório de fontes, modificações que podem corrigir algum dos itens referentes a esse tópico... Por favor atualize seus fontes, faça testes, e se possível comente em uma nova resposta, se o problema foi resolvido... Dúvidas, sobre o uso do SVN ? Clique aqui e veja um vídeo

Você precisa verificar isso com o banco, esse Jump já está em vigor no componente a quase 10 anos, e está válido conforme o manual da Febraban.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Se olhar na classe do Banco em questão, não tem implementado o Transacao240 o certo de quando foi implementado essa classe, era ter subido um raise no 240

não tem cnab240 nessa classe, somente 400

Por favor atualize seus fontes, pelo SVN do ACBr... Já subimos para o nosso repositório de fontes, modificações que podem corrigir algum dos itens referentes a esse tópico... Por favor atualize seus fontes, faça testes, e se possível comente em uma nova resposta, se o problema foi resolvido... Dúvidas, sobre o uso do SVN ? Clique aqui e veja um vídeo