Rosemir

show Italo, então está explicado, tem que ajustar quando o canhoto esta rodapé, rsss vou dar uma olhadinha sim e quando conseguir corrigir eu posto aqui novamente (inicio da semana provavelmente). por enquanto muito obrigado

Oi Italo, anexo sim, até antes de te enviar, fiz mais um teste aqui, reinstalei o acbr para garantir que pegou a alteração (como expliquei acima estou com essa dificuldade), build no projeto e testei novamente, funcionou certinho, vou anexar o PDF também. ACBrCTeDACTeRLRetrato.dfm 43230748259736000105570010000359531306826125-cte.pdf

Foi alterado somente o .pas Um problema que lembrei agora, venho enfrentando isso com o componente a algum tempo, é ter que reinstalar o ACBr sempre que preciso alterar alguns fontes. Talvez seja o mesmo problema seu ali.

Bom dia Italo, segue em anexo 43230748259736000105570010000359531306826125-cte.xml

Voltando aqui com a solução, depois de descobrir o problema, tive que batalhar aqui para achar as definições corretas para quantificar o numero de chaves de acesso a partir da segunda pagina e tive que fazer também um ajuste ao dimensionar a banda. O componentes esta fixo para adicionar 70 chaves por coluna e por página, porém, não cabe tudo isso. No máximo 58. Fiz um ajuste também onde é definido a altura dos memos "rlDocOrig_tpDoc1" e "rlDocOrig_tpDoc2", pois eles são definidos dinamicamente da seguinte forma: rlDocOrig_tpDoc1.Height := Round(rlDocOrig_tpDoc1.Lines.Count * 12); rlDocOrig_tpDoc2.Height := Round(rlDocOrig_tpDoc2.Lines.Count * 12); O que fiz foi adicionar 10 a esse calculo para ficar um pouco mais alto, ficando da seguinte forma: rlDocOrig_tpDoc1.Height := Round(rlDocOrig_tpDoc1.Lines.Count * 12) + 10; rlDocOrig_tpDoc2.Height := Round(rlDocOrig_tpDoc2.Lines.Count * 12) + 10; Fiz testes com 100, 200, 300, 400 e 500 chaves de acesso, funcionou certinho. Segue em anexo o arquivo alterado para que algum moderador possa subir para o repositório. Espero ter ajudado. ACBrCTeDACTeRLRetrato.pas

Olá amigos, gostaria de trazer o problema e também a solução, porém, não consegui resolver. Enquanto continuo tentando descobrir o problema, já deixo aqui no fórum caso alguém posso tentar nos ajudar aqui. Eu tenho um CT-e com 242 chaves de acesso, autoriza tudo certinho, problema apenas quando tenta imprimir o DACT-e, ele imprime a primeira pagina corretamente, com 20 chaves de acesso (10 em cada coluna), mas imprime a segunda e terceira pagina somente com o cabeçalho (restante da pagina em branco), ai na quarta página imprimir a pagina cheia (cabeçalho e o restante com chaves de acesso), na quinta página com o que deveria ser o restante das chaves. Tenho 2 problemas: 1) imprime 2 páginas em branco com apenas o cabeçalho 2) constatei que não mostrou no DANF-e todas as chaves de acesso, faltou 10 chaves de acesso Tentei mudar algumas configurações de margem, mas o problema persiste. Vou anexar o PDF para facilitar a visualização. 43230748259736000105570010000359541007142256-cte.pdf

Olá, gostaria de sugerir uma nova opção para a impressão da NFC-e, quando o componente ACBr estiver configurado para imprimir os itens em uma linha. Fiz alguns testes aqui e ficou bem legal. O motivo da minha sugestão, é porque da forma que está, só funciona bem para fonte tamanho 7, se o cliente quiser usar fonte 6 por exemplo, apenas diminui a fonte, mas não ocupa o espaço a mais que tem disponível, onde na verdade poderia estar mostrando mais caracteres na descrição do item. A ideia principal é criar no componente uma opção para configurar a quantidade de caracteres que deseja imprimir na linha, pois pode variar de acordo com o tamanho de margem e tamanho da fonte, dessa forma ficaria bem flexível. No meu caso, fiz um teste utilizando fonte 6 e esta nova configuração, utilizaria 49 caracteres. O que fiz no código fonte, além de criar o parâmetro, foi dividir a linha do item em 3 partes: 1ª parte seria o SEQ, 2ª parte vai ser o código do produto e descrição (fiz desta forma porque pode estar configurado para imprimir o código do produto ou código de barras - EAN) e na 3ª parte os valores. O SEQ no caso cai ser sempre fixo, vai utilizar 3 caracteres e 1 espaço em branco para separar. Os valores (un, qtde, valor e total), pode variar, então nessa parte, vai usar o que for necessário. E a 2ª parte, o que fica no meio, vai ocupar o que tiver de caracteres disponíveis, sendo que se ficar menor, vai preencher com brancos, para que a linha toda fique sempre com a mesma quantidade de caracteres. Veja no anexo como ficou a impressão e veja a seguir como ficou o código fonte: procedure TACBrNFeDANFCeFortesFr.FormataTextoItemParaUmaLinha(out LinhaItem: string); var UmProd: TProd; CaracteresCodigoDescricao: integer; LinhaItemSeq, LinhaItemCodigoDescricao, LinhaItemValores: string; begin UmProd := ACBrNFeDANFCeFortes.FpNFe.Det.Items[fNumItem].Prod; LinhaItemSeq := IntToStrZero(UmProd.nItem, 3) + ' '; LinhaItemValores := ' ' + ACBrNFeDANFCeFortes.FormatarQuantidade(UmProd.QCom, False) + ' ' + Trim(UmProd.uCom) + ' X ' + ACBrNFeDANFCeFortes.FormatarValorUnitario(UmProd.VUnCom) + ' ' + FormatFloatBr(UmProd.vProd); if ACBrNFeDANFCeFortes.QuantidadeCaracterLinhaItem > 0 then begin CaracteresCodigoDescricao := ACBrNFeDANFCeFortes.QuantidadeCaracterLinhaItem - Length(LinhaItemSeq) - Length(LinhaItemValores); LinhaItemCodigoDescricao := PadRight(copy(ACBrNFeDANFCeFortes.ManterCodigo(UmProd.cEAN, UmProd.cProd) + ' ' + UmProd.xProd, 1, CaracteresCodigoDescricao), CaracteresCodigoDescricao, ' '); LinhaItem := LinhaItemSeq + LinhaItemCodigoDescricao + LinhaItemValores; end else begin LinhaItem := LinhaItemSeq + ACBrNFeDANFCeFortes.ManterCodigo(UmProd.cEAN, UmProd.cProd) + ' ' + '[DesProd]' + LinhaItemValores; LinhaItem := AjustarDescricaoAteTamanhoMaximo(UmProd, LinhaItem); end; end; Seque em anexo também os fontes alterados. Agradeço se puderem avaliar a minha sugestão, lembrando que esta alteração não irá interferir em nada no que já funciona, pois por padrão a nova propriedade virá zerada e não executará o código que criei. ACBrNFeDANFEClass.pas ACBrDANFCeFortesFr.pas

@EMBarbosa. agradecido, testei aqui e está tudo certo. Att. Rosemir

ok, fico no aguardo, agradecido

Minha situação é a seguinte: quando realizo a impressão da DANF-e, onde no XML foi preenchida a inscrição na SUFRAMA, o próprio componente adiciona nas informações complementares o testo "INSCRIÇÃO SUFRAMA: 9999999999", porém, quando o componente coloca apenas essa informação, ao concatenar com as informações complementares do usuário, não está quebrando a linha. Percebi que na unit "ACBrNFeDANFEClass.pas", no método "ManterSuframa()", não é colocado o ponto-e-vírgula no final do texto. Aproveitei e alterei também o método "ManterProtocolo()" que resultaria no mesmo problema. Apenas adicionando o ";" no final já irá quebrar a linha, pois existe um tratamento pra isso. Segue em anexo o fonte alterado, agradeço se puderem analisar e subir a alteração. ACBrNFeDANFEClass.pas

Tenho um cliente que manda fazer na gráfica uma folha personalizada, já com a logo e o destaque do canhoto "picotado". Ele utiliza a impressão em formato paisagem e utilizamos o Fortes para a impressão. Como normalmente as notas deles não ultrapassam o limite de apenas uma página, estava tudo ok para ele, porém, agora que precisou, começou a ter problemas. O que acontece na verdade é que a partir da segunda página, o canhoto não é impresso e o layout é redimensionado de tal forma que ocupe sempre toda a segunda página. Como a logo da empresa já vem impressa no papel que vem da gráfica, ela tem uma posição específica. Quando o layout vem todo para a esquerda, por não ter mais o canhoto, a impressão fica por cima da logomarca. Se a segunda página exibisse também o canhoto, resolveria o problema, mas não acho legal, pois não tem necessidade de imprimir um canhoto para cada página. Lembrando que a logo não é impressa pela impressora, vem pré-impresso da gráfica. Então, fiz uma alteração bem simples no componente, adicionando um parâmetro na unit "ACBrNFeDANFEClass.pas" chamado "ExibeCanhotoEmBrancoSegundaPagina" e na unit "ACBrNFeDANFeRLPaisagem.pas", alterei para exibir mesmo assim o panel do canhoto, mas não exibir os componentes adicionados a ele. Isto fará com que a partir da segunda página, o canhoto continuará a não ser exibido, mas manterá o espaço ocupado por ele. Talvez esta seja uma necessidade muito específica, mas talvez possa atender a mais clientes. Agradeço se puderem opinar sobre a alteração ou sugerir alguma outra alternativa. Segue em anexo fontes alterados e uma imagem de como fica a impressão sem esta minha alteração. ACBrNFeDANFEClass.pas ACBrNFeDANFeRLPaisagem.pas

Obrigado pelo retorno, agora já rodando nos clientes, percebi que utilizando OpenSSL fica melhor realmente. Mas criei uma configuração para escolher entre OpenSSL e Wincrypt, fica mais flexível. Grato pela ajuda

Bom dia, entendi, vou criar uma configuração em meu sistema para escolher qual utilizar, assim fica mais tranquilo do que escolher uma e deixar fixo. Muito obrigado.

Antes tarde do que nunca...rssss Estou nesse momento abandonando a "capicom" para começar a utilizar a "libWinCrypt". Consegui fazer todos os procedimentos indicados, utilizando as propriedades padrão "libWinCrypt" e salvando agora o certificado digital diretamente no banco de dados. Eu utilizo o Windows 10 no meu computador, testei a consulta de status do serviço, consulta do status da NF-e, enviei, tudo funcionando certinho em ambiente de produção e homologação. Testei em outro computador também com o Windows 10 e também tudo funcionando certinho. Quando fui testar em um terceiro computador, ocorreu erros na comunicação com a SEFAZ. Testei em outros 2 computadores, um com windows 7 e o outro com windows 8.1 e os erros são os mesmos. Porém, só ocorre em ambiente de homologação. Em produção só não consegui testar o envio, mas consulta de status do serviço e consulta do status da NF-e estão funcionando. Atualizamos o Windows para ter certeza que não seria algo nesse sentido. Erro ao consultar o Status do Serviço em homologação com windows 7 ou 8.1: Erro ao enviar a NF-e em ambiente de homologação com windows 7 ou 8.1 Vou continuar meus testes e se descobrir algo posto aqui novamente. Desde já agradeço qualquer ajuda dos colegas do fórum.

Exatamente, onde consta isso no manual? É fácil falar que está lá e mandar os outros procurarem, se achar achou, kkkk. No meu caso é igual ao seu exemplo, o cliente é do mesmo estado e mandou entregar a mercadoria em uma obra em outro estado, mas não necessariamente precisa ser uma construtora, a empresa pode estar construindo uma filial naquele estado, por exemplo. Mas claro que poderia ser este outro exemplo do depósito. A principio a única forma encontrada, seria emitir com CFOP iniciado em 5 e mandar a mercadoria normalmente para o outro estado com esta nota, mas ainda tenho que ver a questão do MDF-e se não vai dar problema, mas pelo que lembro não tem validação quanto a isso. sim, essa é a única forma que encontramos por enquanto, emite com CFOP iniciado em 5 e manda essa nota para o outro estado, mesmo que o transporte da mercadoria seja interestadual.

Boa tarde @Fernando Di Pace Agradeço pelo retorno, mas no meu caso é apenas NF-e, trata-se de uma indústria que está vendendo. Essa indústria está em SC e o cliente dela também está em SC. Mas a mercadoria vai ser entregue em SP.

Sim, dessa forma consigo emitir, já tinha feito o teste, é uma venda presencial, o CFOP vai ser sempre iniciado em 5 (que não é o meu caso, inicia com 6), conforme nosso amigo @Joas Vilas Boas Fernandes mencionou. Acredito que a única forma é emitir com o CFOP que inicia com 5, já que o destinatário é do mesmo estado e destacar certinho o endereço de entrega, que vai ser em outro estado. Estou aguardando uma resposta da parte da contabilidade, qualquer novidade, eu posto aqui.

É que no meu caso, o cliente é do mesmo estado, mas a entrega é em outro estado e ainda a operação é com contribuinte (possui inscrição estadual), seria essa a situação do seu exemplo?

No meu caso refere-se a NF-e.

A orientação deles é que está no manual de orientação do contribuinte. Pedi para eles mandarem uma NF-e com o mesmo exemplo. Mas me mandaram uma situação diferente, onde o emitente é de SP, o destinatário de SC e a entrega é em SP. O CFOP utilizado foi 5102. Nesse caso autorizou, mas pelos testes que fiz, somente autoriza se for operação com consumidor final não contribuinte. Fiz o teste com consumidor final não contribuinte, mas com o emitente e destinatário em SC e a entrega em SP (que é o que preciso), mesmo assim não autoriza.

Olá pessoal, eu tenho uma situação onde o emitente da NF-e é de SC e o destinatário também é de SC. A operação é uma venda, mas a entrega do produto é em SP. O contador instruiu a colocar os dados do destinatário (endereço) como sendo SC e utilizar a CFOP 6.102. O que retorna é a Rejeição 523: CFOP não é de Operação Estadual e UF emitente igual à UF destinatário Claro que é bem óbvio que está ocorrendo esse erro pelo fato de o endereço do destinatário ser do mesmo estado do emitente e o CFOP utilizado é de operação interestadual. Mas a pergunta é o seguinte, alguém sabe como proceder nesta situação? Pois a contabilidade diz que é assim que tem que emitir, rsss. Deve ter alguma forma legal. Desde já agradeço pela ajuda.

Para resolver o meu problema, a sugestão seria remover a geração do local de retirada e entrega no layout paisagem, embora fico aqui me preocupando com quem precisa dessa funcionalidade. Mas retirando e deixando a critério de cada um decidir como implementar esse texto, deixaria mais flexível a todos. Se observar abaixo, a única diferença para o método "DadosAdicionais" do retrato, é a questão dos endereços. procedure TfrlDANFeRLPaisagem.DadosAdicionais; var sProtocolo, sSuframa : String; begin rlmDadosAdicionaisAuxiliar.Lines.BeginUpdate; rlmDadosAdicionaisAuxiliar.Lines.Clear; // Protocolo de autorização, nos casos de emissão em contingência if (FNFe.Ide.tpEmis in [teContingencia, teFSDA]) and (FNFe.procNFe.cStat = 100) then begin sProtocolo := ACBrStr('PROTOCOLO DE AUTORIZAÇÃO DE USO: ') + FNFe.procNFe.nProt + ' ' + DateTimeToStr(FNFe.procNFe.dhRecbto); InsereLinhas(sProtocolo, iLimiteCaracteresLinha, rlmDadosAdicionaisAuxiliar); end; // Inscrição Suframa if FNFe.Dest.ISUF > '' then begin sSuframa := ACBrStr('INSCRIÇÃO SUFRAMA: ' ) + FNFe.Dest.ISUF; InsereLinhas(sSuframa, iLimiteCaracteresLinha, rlmDadosAdicionaisAuxiliar); end; //InsereLinhas(EnderecoRetirada, iLimiteCaracteresLinha, rlmDadosAdicionaisAuxiliar); //InsereLinhas(EnderecoEntrega, iLimiteCaracteresLinha, rlmDadosAdicionaisAuxiliar); InsereLinhas( TACBrNFeDANFeRL(Owner).ManterDocreferenciados(FNFe, FImprimirDadosDocReferenciados ) + ManterInfAdFisco + ManterObsFisco + ManterProcreferenciado + ManterInfContr + ManterInfCompl , iLimiteCaracteresLinha, rlmDadosAdicionaisAuxiliar); rlmDadosAdicionaisAuxiliar.Lines.EndUpdate; end; Mas por outro lado, se colocar a implementação no layout retrato, também pode afetar quem utiliza somente este layout. Posso realizar a alteração, mas ainda não cheguei a conclusão qual seria a melhor forma de resolver: remover no paisagem ou acrescentar no retrato? Por mim seria remover do paisagem, mas claro que precisamos analisar e ver se mais alguém tem algum ponto de vista diferente.

Para manter o padrão, teria que ser desenvolvida a mesma funcionalidade no formato retrato, ou remover do formato paisagem, pois como está, os 2 layouts estão se comportando de forma diferente. A única questão e que não concordo, é gerar na informação complementar do DANFe, um texto que não foi enviado no arquivo XML. Para dar mais liberdade, na minha humilde opinião, é que se desejar imprimir o local de retirada e de entrega, envia junto no arquivo xml, e será impresso normalmente. Dessa forma não teria que ficar criando parâmetros de configuração (mais um entre tantos, rsss). Alguém mais concorda?

Segue o PDF em formato retrato... 42180876344407000106550020000215641000215640-nfe (retrato).pdf

Sim, Retrato no Fortes.