Clipeus

Sim, essa propriedade ajuda. Obrigado, tinha me esquecido dela. Vou usa-la também como forma de garantir que o problema não volte a ocorrer. Mas, independente da largura do código, quando selecionamos uma fonte através da propriedade "Danfe.Fonte.Nome", ela deveria ser aplicada ao documento inteiro, não? Fiz um teste selecionando as 3 fontes disponíveis no componente e o quadro com a relação dos itens fica sempre em "Arial". Com a alteração que sugeri resolve, todo o DANFe ficará com a fonte que estiver configurada...

Tive um problema em um cliente, que relatou que o código do produto não estava cabendo na coluna correspondente no DANFe, fui verificar melhor e identifiquei que no DANFe o quadro "Dados do Produto" estava utilizando uma fonte diferente da fonte que estava configurada no componente ( uso "TimesNewRoman" e esse quadro estava com a fonte "Arial" ). Fui verificar no código fonte do componente e identifiquei que existe um "laço for" para modificar as propriedades Font.Name, Font.Size, etc de todos os controles que estão no DANFe. Mas esse laço não consegue mudar as fontes dos itens, pois o código está escrito para percorrer as bandas que estão no nível mais alto, nesse caso, a banda que relaciona os itens estão dentro de um TRLSubDetail. A solução que encontrei foi bem simples: transformar esse trecho que percorre os controles em uma função recursiva, para que seja alterado "em cascata" os controles que estão contidos em outras bandas internas (que é o caso da SubDetail) Segue o código fonte com as alterações tanto para o formato Retrato quanto para Paisagem. Segue tb uma imagem mostrando como estava o DANFe antes e depois da correção.ACBrNFeDANFe-Fortes.zip Obs: Fiz a correção apenas para o Fortes, não uso o Fast e não sei se o mesmo erro ocorre no Fast.

Também estava com o mesmo problema, em um certificado emitido pela VALID, mas apenas copiando as DLLs da pasta XMLSec não resolveu... Consegui resolver da seguinte forma: - Exportei o certificado pelo Internet Explorer (com a chave privada) - Removi o certificado pelo Internet Explorer - Baixei o instalador de certificados da VALID (http://www.validcertificadora.com.br/instalador) - primeiro link disponível. - Executei o instalador e selecionei o arquivo que exportei no começo.

Ok, @hleorj, compreendo. Nunca utilizei o do fast, por isso não tenho como dizer se ele também funcionava assim ou não, mas ficarei acompanhando as atualizações para o caso de acharem que o melhor é fazer essa propriedade ocultar toda a banda... em tempo: talvez fosse mais interessante dividi-la em duas propriedades: ExibeCampoFatura -> Se true aparece a banda, se false não aparece ImprimeDadosFatura -> Se true imprime os campos dentro da banda fatura, se false não imprime De qualquer forma, obrigado!

Olá @hleorj Ontem, ao atualizar um cliente que estava com o sistema desatualizado, ele reclamou justamente isso, que na versão anterior que ele usava não imprimia o quadro fatura com a descrição da forma de pagamento (a vista/a prazo/outras) e que agora passou a imprimir. Me mostrou alguns pdfs e realmente não imprimia. Hoje, outros clientes também reclamaram a mesma coisa... Fui tentar buscar no SVN a revisão que desde quando a propriedade ExibeCampoFatura foi criada (isso na revisão 10226) ela realmente funcionava para ocultar ou não a banda "Fatura". Somente a partir da revisão 10834 é que passou a não mais ocultar a banda, e sim, alguns dados que estão dentro da banda. Li os posts que estão no comentário da revisão 10834 mas não ficou claro o motivo da banda "Fatura" ter que ser impressa mesmo quando o ExibeCampoFatura estiver setado para false. Alterei para testar aqui na versão atual, colocando novamente no inicio da procedure AddFaturaReal a linha que trata a visibilidade da banda, ficando assim: procedure TfrlDANFeRLRetrato.AddFaturaReal; begin rlbFaturaReal.Visible := fExibeCampoFatura; //SOMENTE ESSA LINHA QUE ACRESCENTEI!! case FNFe.Ide.indPag of ipVista : RlbDadoPagamento.caption := ACBrStr('PAGAMENTO À VISTA'); ipPrazo : RlbDadoPagamento.caption := ACBrStr('PAGAMENTO À PRAZO'); ipOutras: RlbDadoPagamento.caption := 'OUTROS'; end; ..... E o DANFe funcionou sem problemas para ocultar todo o quadro da fatura, como era antes. Testei com um XML contendo duplicatas e outro sem as duplicatas e funcionou normalmente, não dando nenhum problema parecido com o que estava relatado no post que originou a revisão 10834. Estou postando isso, pois como também um outro usuário comentou lá no post, dessa forma, ganha-se um bom espaço para relacionar mais itens na mesma página, trazendo economia de papel para o cliente, e claro, ouvimos menos reclamações também Por acaso, teria algum problema em voltar a funcionar como sempre era, ou seja, se setar o ExibeCampoFatura para False, o quadro Fatura não ficará visível? Pessoalmente, pelo nome da propriedade, eu acredito que faz mais sentido esse comportamento...

Bom dia Henrique! Desculpe novamente na demora em responder, estou com um familiar hospitalizado e minha rotina diária está um pouco alterada. Vou verificar para alterar para Fast também e depois eu posto aqui. Com relação ao código abreviado, realmente ficou fora do padrão, mas como comentei, foi a melhor forma que encontrei para minimizar o número de linhas que ocupa no Danfe, e, acredite, cada caracter a mais estava fazendo uma grande diferença. Segue em anexo um XML que poderá usar para estudo e alguns DANFe em PDF que gerei com todas as possibilidade (abreviado no padrão, sem abreviar e abreviado como eu tinha proposto). Veja que embora só tinha 5 produtos na nota, em alguns casos passou a imprimir 2 paginas de DANFe. No cliente mesmo acontece de ter notas com 20 ou mais itens. O que eu imaginei e até me proponho a fazer é o seguinte: - Criar uma nova propriedade, chamada "SeparadorDetalhamentosEspecifico", que por padrão será a string " - ". Assim, continuaria a ter um "IF", mas somente para abreviar. - E se for generalizar mais ainda, também daria para criar uma outra propriedade "AbreviarDetalhamentosEspecifico", e com isso aplicar o mesmo funcionamento para os outros tipos de detalhamento também. Vejam o que acham melhor que me proponho a modificar, mas penso que é muito viável mesmo a impressão abreviada, pelo menos nos medicamentos. []'s XML e Testes com DANFe.zip

Estive ausente nos últimos dois dias e só agora pude baixar e testar as mudanças feitas e unificação das propriedades QuebraLinhaEm... para uma genérica, ficou melhor sim, mas fiz outras modificações: 1) No Fortes, modelo Paisagem, não havia sido aplicada a refatoração para o detalhamento dos medicamentos. 2) No caso específico de Medicamentos, quando estiver configurado para não efetuar a quebra de linha, abreviei as strings fixas, pois como o objetivo é fazer com que o detalhamento ocupe o menor número de linhas possível, as strings originais acabavam ocupando vários caracteres quebrando automaticamente em várias linhas as informações. Com isso, um danfe em formato paisagem (por ex) com apenas dois ou três produtos acaba gerando duas páginas, mesmo com a quebra linha configurada para "false". Pessoalmente, abreviado achei que ficou mais eficiente, pois em alguns clientes que usam medicamentos, passou a gerar mais uma página desnecessariamente quando as strings estão completas. Se for possível subir no SVN assim eu ficaria grato! Espero ter contribuído com o projeto! Segue anexo arquivos alterados. []s Luis ACBrNFeDANFeRLRetrato.pas ACBrNFeDANFeRLPaisagem.pas

Criei uma nova propriedade para o DANFe, para permitir escolher se os dados do medicamento (lote,fabricação,validade,...) serão impressos com quebra de linha ou não (tal como existe para os dados do veículo). Nova propriedade: QuebraLinhaEmMedicamentos:boolean -> padrão "True" Segue em anexo as units que foram alteradas para que possam analisar e subir no SVN se possível. Grato. ACBrNFeDANFeRLClass.pas ACBrNFeDANFeRL.pas ACBrNFeDANFeRLPaisagem.pas ACBrNFeDANFeRLRetrato.pas

Daniel, com essa última alteração no trunk2 passei a ter problemas com diferimento de 100%. Comparei com o que eu estava usando no trunk e notei que lá há um tratamento para identificar se deve ou não incluir o campo vICMS. Alterei para ficar exatamente igual ao que faz no trunk e aceitou normalmente em SP também. Segue em anexo a unit do TRUNK2 alterada, ok? Obrigado! pcnNFeW.pas

Tive esse problema também e vi que eu não estava ativando a comunicação com a porta serial, veja se resolve com esses comandos (eu coloquei logo quando entro no sistema, não precisei alterar nada no fonte) : TACBrNFeDANFeESCPOS1.Device.Porta := 'COM4'; TACBrNFeDANFeESCPOS1.Device.Baud := 38400; TACBrNFeDANFeESCPOS1.Ativar; Confirme pelo programa "TM-T120 Utility" a porta e velocidade que está configurada.

O erro era por causa da versão do Fortes que eu tinha instalado, atualizei para a 3.72b e está ok agora. Segue arquivo com outras alterações. Além do alinhamento que estava errado, acrescentei: - Ao lado da quantidade total de itens, a informação do Sub-Total (tag ICMSTot.vProd ) - Uma linha com o valor total do desconto (somente se tag ICMSTot.vDesc>0) - Uma linha com o valor total do frete (somente se tag ICMSTot.vFrete>0) Só não consegui repassar essas alterações para o form usado pelo Lazarus. ACBrDANFCeFortesFr.zip

Olá, Fiz algumas mudanças no componente ACBrDANFCeFortesFr, pois além de estar desalinhado, notei que não estava imprimindo no total os valores referente ao desconto e/ou frete, deixando um pouco confuso o total. A alteração que fiz imprimirá no final o sub-total (soma dos produtos), valor total do frete (se houver), valor total do desconto (se houver) e valor total final. No arquivo anexo estão as mudanças que fiz, mas não consegui alterar o layout para o lazarus (não tenho ele instalado). Abraços ACBrDANFCeFortesFr.zip

Obrigado pelas respostas, vou fazer um teste com o Fortes e QR também

Bom dia, Pesquisei e li várias mensagens aqui no fórum nos últimos dias para tentar entender as formas possíveis para impressão da NFCe e pensei que para facilitar a busca e centralizar melhor essa informação, poderia ser criado e mantido um tópico no estilo do que foi feito para o ACBREcf Pelo que eu entendi, atualmente a impressão da NFCe é compatível com os componentes : TACBrNFeDANFeESCPOS Apenas para impressoras térmicas não fiscais compatíveis com o padrão ESC/POS. Foi testado (oficialmente) apenas com impressora não fiscal EPSON (qual modelo?) e a comunicação é direta, através de porta serial ou USB (confere?) TACBrNFeDANFEFR Necessita do componente Fastreport e realiza a impressão via spooler do windows (se o fabricante da impressora disponibiliza driver). é isso mesmo? Grato

Pessoal, Fiz algumas modificações no arquivo do Santander para passar na homologação e adicionei também a procedure para tratar a importação do retorno de 240 posições. Segue anexo o arquivo que alterei para que possam verificar e subir no SVN se estiver tudo correto. Grato. ACBrBancoSantander.pas

Verifiquei no ACBRSpedFiscal e nele não estava duplicando, comparei os dois fontes e fiz algumas modificações que pelo meus testes no DEMO resolveu ( o arquivo gerado tanto como concomitante como não concomitante ficou exatamente igual) Estou anexando os arquivos que alterei, para que possam verificar e subir no SVN se estiver correto. Grato. ACBrSpedPisCofins.pas ACBrEPCBloco_A_Class.pas ACBrEPCBloco_C_Class.pas

Pessoal, desculpem "ressuscitar" esse tópico antigo, mas pesquisando foi o único que encontrei e não estava apresentando uma conclusão/solução ainda. Estou com um problema no meu aplicativo quando uso a opção de "WriteBloco_C( False )" (a cada n notas) e "WriteBloco_C( True )" ( ao final do loop de notas ): Está gravando sempre os registros C001 e C010. Fazendo um teste com o DEMO do ACBrSPEDPisCofins notei que ao gerar com a opção de "Gerar Concomitante" selecionada também está duplicando os registros de A001, A010, C001 e C010. Para reproduzir esse problema no DEMO, basta, por exemplo, configurar o campo "Num.Notas ©" para 10, o campo "Buffer Notas" como 2 e clicar no botão "Todos os Blocos". Grato,

É verdade, tem o caso do produtor rural também.. Acho que também irei optar por imprimir em todas as notas, pelo menos inicialmente. Obrigado pelos comentários! Abraços,

Pessoal, não é uma dúvida sobre como utilizar o componente, mas sim sobre quando utilizar : "Somente para vendas ao consumidor final" Como estão fazendo para identificar se é ou não uma venda de consumidor final no caso de NFe? Pensei em identificar pelo tipo de pessoa (fisica/juridica) do cliente: PF sempre é consumidor final, mas PJ pode ou não ser consumidor final (pode comprar para revenda ou para consumo/uso). Pensei em vincular também o CFOP, mas pelo que sei, ele não será diferente se uma PJ estiver comprando para revenda ou para uso/consumo. Pensei em colocar para o usuário escolher a cada venda (pelo menos se for para PJ) se é ou não de consumidor final, mas acho complicado isso ( muito fácil de erros por parte do usuário ) Será que tem alguma forma de identificar automaticamente? Como vocês estão lidando com isso?

Aparentemente consegui identificar o problema, não encontrei o uso da função estado em algum evento do ACBREcf, mas identifiquei que o usuário estava sendo "rápido demais" e pressionando vários "ENTER" em uma determinada janela que mantinha o foco no botão de "OK" e provavelmente o código "OnClick" desse botão estava sendo executado mais de uma vez (dentro desse botão havia uma chamada para o EstadoECF). Alterei para desabilitar o botão assim que entra no OnClick dele e não tive mais o problema. Não cheguei a precisar apelar para alterar a velocidade do ECF através do EnviaComando...rs Obrigado!

Sinceramente, não sei..rs Mas é que não consegui localizar nenhuma chamada ao ACBr.Estado em algum evento programado (que poderia justificar o erro "Componente ACBrECF ocupado" ). Tenho apenas a sequencia "ECF.FechaRelatorio" e depois um "ECF.Estado", e pelo log parece ser esse o problema : Em uma ultima tentativa pensei em aumentar a velocidade para ver se ajuda em algo..rs Mas vou procurar mais uma vez em meu código se encontro algum uso do ECF em algum evento, depois posto aqui o resultado. Obrigado!

Pessoal, Encontrei no manual da Bematech a seguinte informação : Alguem já usou essa configuração e pode confirmar se funciona em qualquer ECF da Bematech? Pois pelo que eu vi ela sempre usava 9600 e não tinha como mudar. Para usar esse comando no ACBr basta fazer o comando abaixo? ACBrECF.EnviaComando(CHR(27)+CHR(62)+CHR(56)+CHR(51)); // 115200 É que estou tendo um problema apenas na Bematech que de vez em quando aparece a mensagem "Componente ACBrECF ocupado". Encontrei esse problema em outros tópicos do forum e estou verificando as dicas deles para ver se consigo sanar, mas como por enquanto não identifiquei nenhuma das situações dos tópicos pensei em aumentar a velocidade da porta para ver se resolve. Obrigado.

Pessoal, consegui baixar colocando o "https://" antes do link que foi divulgado pela receita, ficando assim : https://ccd.serpro.gov.br/serproacf/docs/icpbrasilv2.cer https://ccd.serpro.gov.br/serproacf/docs/acserprov3.cer https://ccd.serpro.gov.br/serproacf/docs/serproacfv3.cer

Sim, Daniel, do que eu eu pude ler a respeito foi o que entendi, que é decisão do estabelecimento participar ou não. Também que entendi que esse desconto é "aleatório". Minha dúvida é se gravando na requisição do TEF o 706-000 sempre como '3' (saque+sorteio), como está hoje, não irá criar uma possibilidade de algum cupom aparecer com o desconto "sorteado", sendo que o estabelecimento não tem o cielo premia? Por isso que questionei se não é o caso desse campo (706-000) ter o seu valor definido através de uma propriedade. Pois assim, criamos uma forma de configurar para cada cliente se ele quer ou não que na requisição do TEF fique "habilitado" a possibilidade de desconto.

Pessoal, pelo que entendi, um dos beneficios do Cielo Premia é que pode dar um prêmio instantaneo ao comprador na forma de desconto, e nesse caso, a loja irá "arcar" também com esse desconto ( ou seja, ela irá receber da operadora o valor liquido ), certo? Se for isso mesmo, alguem sabe me dizer se todas as lojas são "obrigadas" a participarem do Cielo Premia ou é opcional ? Pergunto isso, pois se for opcional, acredito que o controle do campo 706-000 gerado na requisição do TEF deveria ficar em uma propriedade do componente, e não dentro do código como está atualmente, pois poderemos ter como clientes lojas que estão participando e lojas que não estão participando, e atualmente sempre ficará gravado o valor '3' ( sujeitando assim a loja a ter um desconto ) Obs : já teve essa sugestão de deixar como propriedade no tópico viewtopic.php?f=16&t=6677&p=38583&hilit=706#p38583, mas como esse tópico era sobre o cliSiTef, achei melhor abrir outro.