hleorj

@Fábio Eduardo de Souza, vou conversar com outros mantenedores do ABCr. Sobre local de entrega e retirada Grato pela sua compreensão.

@Fábio Eduardo de Souza, Boa tarde Não será possível ter o layout pelo ACBr. Pois a danfe estaria fora do padrão. Mas você poderá desenvolver o seu padrão de danfe. Grato.

@Fábio Eduardo de Souza, bom dia Não será possível ter o layout pelo ACBr. Ps : Abra sempre um novo post , para um assunto Grato

@Fábio Eduardo de Souza, tem como mostrar como era impresso na versão anterior ?

@Igor.Moura, Existe a informação no arquivo xml de <IE>ISENTO</IE> ?

@Mauro Gomes, entendi. O Acbr está com muitas mudanças para conseguir um padrão entre as danfe's desenvolvidas ( fortes e Fast ). Onde teremos, o mesmo conjunto de propriedades e funcionalidades entre elas. Como desenvolvedor , pode ter a sua implementação de Danfe. No futuro , pretendo ( depois de muita conversa com outros mantedores do ACBr ) , remover algumas propriedades ( a ExibeCampoFatura está na lista ). Ps : Sua sugestão acima está em analise .

@Mauro Gomes, Por que colocou na Tag <indPag>2</indPag> ( outros ) , para uma nota de VENDA C/ SUBST. TRIBUT e colocou dados de Fatura -<fat> <nFat>3976</nFat> <vOrig>490.00</vOrig> <vLiq>490.00</vLiq> </fat> -<dup> <nDup>003976-1/1</nDup> <dVenc>2016-05-10</dVenc> <vDup>490.00</vDup> </dup> Existe uma regra simples que a maioria dos desenvolvedores seguem para forma de pagamento igual 2 ( <indPag>2</indPag>) : Notas de devolução, Notas de Simples remessa, Notas de entrada. E outros casos que não sejam de venda. Sempre terão a forma de pagamento outros. Notas fiscais de vendas no geral possuem a forma de pagamento ( PAGAMENTO À VISTA, PAGAMENTO À PRAZO ) E uma das razões para sempre imprimir a Aba Fatura , está no erro conceitual da implementação da forma de pagamento outros.

@Mauro Gomes , os comentários a seguir : Inclusão na linha nº 2031 do código "rlbFaturaReal.Visible := fExibeCampoFatura;" dentro do método "TfrlDANFeRLRetrato.AddFaturaReal" a fim de suprimir a impressão do campo Fatura sem os dados quando a propriedade ExibeCampoFatura for "false"; Inclusão na linha nº 2021 do código "rlbFaturaReal.Visible := fExibeCampoFatura;" dentro do método "TfrlDANFeRLPaisagem.AddFaturaReal" a fim de suprimir a impressão do campo Fatura sem os dados quando a propriedade ExibeCampoFatura for "false"; Não serão implementos no código SVN. pois : // A propriedade ExibeCampoFatura só tem a função de controlar os dados de fatura. // Por padrão, a Banda Fatura, dever ser exibida sempre, para impressão da Tag forma de pagamento. verifique se o seu código esta de acordo com a ultima versão do SVN , post alguns pdf' s do resultado da(s) sua(s) sugestão(ões).

@Luciano Carvalho, detalhe mas o seu problema. O padrão é sempre apresentar a forma de pagamento.( avista , a prazo ou outras ) A propriedade exibicampofatura somente controla os dados de fatura.

@Gr@c@, fique somente no replace do componente, dará um pouco de trabalho nas configurações, mas ganhara muito tempo nos testes. Passei pelo mesmo problema nas minhas atualizações ( D7 -> Dxe3 -> Dxe5 -> Delphi 10 Seattle) Agora só tenho jedi nos meus projetos.

No script do Arquivo fr3

@Gr@c@, não desista o Gexpert.

@josival.alecrim Abra a Unit ACBrNFeDANFeRLRetrato.pas Altere : De rllSERIE0.Caption := ACBrStr('SÉRIE ') + PadLeft(IntToStr(Serie), 3, '0'); Para rllSERIE0.Caption := ACBrStr('SÉRIE ') + IntToStr(Serie);

@Juliomar Marchetti, tem o meu apoio para utilizar somente o padrão ACBr. Pois não esta saindo documentação correta para importação de TXT.

O valor do IPI , não existe em notas de simples nacional. Você poderá devolver o valor do IPI em outros valores. E descrever em informações adicionais : O Valor de outros referente ao valor de ipi da nota.xxx de xx/xx/xxx.

Sem uma propriedade anterior fica mas dificil ainda e eu tenho alguns segmentos que me causariam problemas : Industria de Artigos de Festas -<prod> <cProd>10218-0</cProd> <cEAN>17896585802180</cEAN> <xProd>VELA ENCARTELADA BRANCA N.1 10X1 UND</xProd> <NCM>34060000</NCM> <CFOP>5101</CFOP> <uCom>CX</uCom> <qCom>2</qCom> <vUnCom>8.4859</vUnCom> <vProd>16.97</vProd> <cEANTrib>7896585802183</cEANTrib> <uTrib>UND</uTrib> <qTrib>20</qTrib> <vUnTrib>0.8485900</vUnTrib> <indTot>1</indTot> </prod> Industria de peças em vidros -<prod> <cProd>19165-0</cProd> <cEAN>17898511791650</cEAN> <xProd>CRISTAL INCOLOR 6MM 40X10 - 12 UND</xProd> <NCM>70052900</NCM> <CFOP>5405</CFOP> <uCom>CX</uCom> <qCom>1</qCom> <vUnCom>211.4400</vUnCom> <vProd>211.44</vProd> <cEANTrib>7898511791653</cEANTrib> <uTrib>PC</uTrib> <qTrib>12</qTrib> <vUnTrib>17.6200000</vUnTrib> <indTot>1</indTot> </prod> Faça outra analise de sugestão, pois está : If Prod.UCom <> Prod.uTrib Then begin Não deve ser implementada ao SVN. grato Ps: O time Acbr , adora sugestões.

@jeoronei, Leia a Nota Técnica 2015/002 (v. 1.30)

O procure o suporte do Avast. Ps : Troque o antivirus, por algo melhor que esta bomba relógio.

Na versão Codebase, existia alguma propriedade para controle da linha ? A sua sugestão está colocando a Danfe fora padrão. E eu não quebro um padrão facilmente .

@Marcio Lopes ACBr, Explique em detalhes a sua sugestão, por favor.

Coloque a propriedade QuebraLinhaDetalhamentoEspecifico para false. Bem provável que atenda a sua necessidade. Segue Pdf anexo. Ps: Sempre Inicie um novo post. DANFeRetratoNovo.pdf

@marciotga, ta complicado de entender o seu problema. Da próxima vez que fizer um post. Tenha o trabalho de mostrar corretamente com uma figura. O Time ACBr, oferece sempre um padrão. Caso o padrão não atenda a sua necessidade. fique a vontade nos oferecer o seu tempo de desenvolvimento com novas sugestões.

@Vilmardiogo, Atualize a sua sugestão para a ultima versão do SVN, pois possui algumas diferenças. Por favor abra um novo post com as suas sugestão de atualização. Grato pelas suas sugestões.

Atualizei o SVN.

Sim , quebrou .. @Juliomar Marchetti, o comportamento do padrão entre as Danfe's. A propriedade ExibeCampoFatura só tem a função de controlar os dados de fatura. Por padrão, a Banda Fatura, dever ser exibida sempre. Sugiro que seja revertido o código para manter o padrão implementado.