Jhoni Conzatti

O XML não obriga, o cliente não quer informar (e pode não informar) o seu telefone no XML da NF-e: nesse caso ele deseja que não apareça o rótulo "TEL:" na Danfe. Segundo o cliente, não faz sentido aparecer o rótulo se não existe essa informação para exibir. Eu, por outro lado, estou inclinado a concordar com o cliente. Eu penso que, se o telefone deve ser obrigatório na DANFE, então a SEFAZ deveria pelo menos obrigar informar também no XML, para ficar coerente.

Apenas para deixar registrado, devo informar ao cliente que o telefone é obrigatório na DANFe e portanto deve sempre informar no XML da NF-e.

Certo, mas não faz sentido mostrar o rótulo "TEL:" quando não existe a informação do telefone do emitente no XML da NF-e para ser impresso na DANFe.

Segundo o manual na NFe/NFCe o campo telefone do emitente (tag emit.enderEmit.fone) é opcional (ocorrência 0-1).

Bom dia, O rótulo "TEL:" é impresso na DANFe mesmo que não tenha essa informação no XML. Acredito que isso realmente não faça sentido e um cliente nosso reclamou. Usamos o Fortes Reporte CE, então já realizei o ajuste nas danfes A4 nas orientações paisagem e retrato: fontes em anexo. Na imagem abaixo, tem um exemplo de DANFe antes do ajuste que eu fiz: Nesta outra imagem a seguir, tem um exemplo de DANFe depois do ajuste que eu fiz: Nas units ACBrNFeDANFeRLRetrato e ACBrNFeDANFeRLPaisagem, no método ```DefinirEmitente``` foram incluídos o seguinte tratamento: if NaoEstaVazio(Fone) then begin sTemp := 'TEL: ' + FormatarFone(Fone); rlmEndereco.Lines.add(sTemp); end; ACBrNFeDANFeRLPaisagem.pas ACBrNFeDANFeRLRetrato.pas

Bom dia, Primeiramente parabéns pelo código @Márcio Baroni Está fácil de entender e acredito que pode me ajudar. Notei, no entanto, que você cria um servidor HTTP local na porta 3000 para a URI de redirecionamento do OAuth 2.0. Achei interessante essa abordagem, eu nunca antes, havia cogitado essa possibilidade. Sempre pensei que fosse necessário criar um servidor acessível na internet para poder rodar o serviço de redirecionamento da autorização do OAuth 2.0. Nesse sentido, em outras situações que precisei da autorização com o OAuth 2.0, acabei criando um serviço com o servidor HTTP instalado em algum VPS. Mas se o http:\\localhost realmente funciona (assim como você o fez), então o servidor VPS não seria necessário.

Acabei de testar no cliente e funcionou em o driver do link que o @Vitor G Silva passou. Vou guardar esse link para instalar nos outros clientes que usam essa marca tbm.

Muito obrigado @Vitor G Silva Vou testar no cliente

Entendi, até encontrei um programa para registrar a logotipo nessa impressora... mas vai demandar tempo de suporte, então vou sugerir ao cliente deixar sem logo mesmo nesse caso em que for usar comando esc/pos. Por fim, consegui resolver o meu problema com o componente de impressão esc/pos do ACBr. No entanto, outro problema é que esse componente não gera PDF. Nesse caso, preciso usar o componente fortes para gerar PDF e anexar o arquivo no e-mail junto com o xml e depois mudar em tempo de execução a propriedade DANFE do ACBrNFe para ESC/POS para poder imprimir. Como o problema não acontece com a maioria das impressoras de bobina então deixei esse comportamento configurável: o suporte poderá configurar se usa ou não esc/pos para a impressão. Espero que isso também possa ajudar o @Renato Chiari. Peço que caso consiga resolver de outra forma, ainda usando o Fortes, por favor reporte aqui. A impressão que tive é que realmente existe algum bug no fonte do Fortes Report CE para com essa impressora, visto que da forma abaixo a impressão sai da forma correta, como se faltasse inicializar alguma informação das propriedades dessa impressora: alguma propriedade que não existe na maioria.

Refere-se a logo? Você quer dizer um papel pré-impresso com a logo?

Configurei 48 colunas... agora imprimiu qrcode e estilos de fontes com ESC POS com essas configurações, mas não imprimiu o logo tipo.

Boa tarde @Juliomar Marchetti Eu tentei usar o esc pos com essa impressora, mas não deu certo, pois não imprime os estilos de fontes, qrcode e logo tipo.

Boa tarde, eu estou tendo exatamente o mesmo problema com esse mesmo modelo de impressora. Se ainda tiver os drivers me ajudaria também No meu caso, assim mostra no preview: Mas a impressão sai assim: Fiz testes com o exemplo do ACBr, inclusive configurei as margens e largura da página em tempo de execução conforme orientação do @Juliomar Marchetti Toda ajuda é bem vinda, pois temos 4 clientes com essa marca de impressora.

Bom dia, Acabei de testar com o projeto exemplo do ACBrNFe e o resultado é satisfatório. Sobre o comportamento, que agora já está resolvido, a maior questão é que quando o componente ACBrNFeDANFCeFortes está com os seguintes valores de propriedades: ACBrNFeDANFCeFortes.Impressora := ''; ACBrNFeDANFCeFortes.MostraPreview := False; ACBrNFeDANFCeFortes.MostraSetup := False; ACBrNFeDANFCeFortes.MostraProgress := False; Nessas condições, mesmo com a propriedade MostraSetup com valor False, o setup insiste em ser exibido na tela. O mesmo não acontece para o componente ACBrNFeDANFeRL, ou seja, com as mesmas condições o setup não é mostrado em tela (ele usa uma impressora qualquer, no meu caso foi a padrão). Ao analisar o fonte, percebi que o componente ACBrNFeDANFeRL usava a função TDFeReportForte.AjustarReport para configurar essa e outras propriedades do relatório. Como o ACBrNFeDANFeRL estava com o comportamento que eu esperava, então acredito que a mesma função pode ser usada em outros componentes de DANFe/DANFCe em FortesReport para carregar essas propriedades de maneira consistente. Em resumo: se a propriedade MostraSetup do componente tem valor False, então o setup para selecionar impressora não deve ser exibido na tela. Muito obrigado

Boa tarde @Juliomar Marchetti O vídeo é importante para entender o contexto, me diga, qual é o problema que não consegues ver para ver se consigo resolver aqui. O caso é que todas as linhas excluídas são substituídas por uma única que já faz o correto tratamento com a função TDFeReportForte.AjustarReport Caso não seja realmente possível ver o vídeo, então vou elaborar alguns prints para você entender o bug.

Olá pessoal, No vídeo abaixo demonstro um problema para impressão de DANFCe com o componente ACBrNFeDANFCeFortes. O componente está configurado para mandar o documento diretamente para a impressora padrão do Windows, mas mesmo assim está abrindo a tela para escolher uma impressora instalada no Sistema Operacional. https://drive.google.com/file/d/1UvCUqs5rQg4-2LnJ3lWcv-yEU5s1Y_4q/view?usp=sharing Notei também algum penitencial problema no componente ACBrNFeDANFCeFortesA4 (conforme demonstrado no vídeo acima). Os fontes dos componentes ajustados estão em anexo: ACBrDANFCeFortesFrA4.pasACBrDANFCeFortesFr.pas

Atualizei os fontes e rodei os testes: está resolvido Muito obrigado

Para todos os XMLs de inutilização processados pelo sefaz, que possuem a tag procInutNFe como nó raiz

não serve para Delphi 7... talvez, se usar o método LowerCase(parametro: string), funcione para todos

Segue a unit com a solução demonstrada em vídeo aplicada: ACBrNFe.Inut.pas

@Juliomar Marchetti segue anexo. 42240352260100015255009000000847000000847-procInutNFe.xml

Boa tarde, @Italo Giurizzato Junior Desculpe por antes, eu disse que o problema do xJust estava resolvido, não tinha testado adequadamente (só olhei o fonte e julguei que estava resolvido). Ainda não está. Gravei um vídeo com debug da situação: https://drive.google.com/file/d/1TnwNSnueM8FndHsRQs9yiOT5X_nCAzpY/view?usp=sharing

Boa tarde Italo, você tem razão. Realmente a unit ACBrNFe.Inut.pas não estava com a alteração referente a xJust aplicada. Estava com alterações locais e tentei corrigir o conflito, mas devo ter feito algo errado na hora usar as alterações que vieram do remoto para esta unit. Isto está resolvido agora, muito obrigado

Bom dia, Acabei de atualizar os fontes e percebi que já aplicaram alguns dos ajustes que eu sugeri. Obrigado e parabéns pela rapidez Foi ajustado o bug na função para Ler XML de inutilização de número de NF quando já homologada pelo SEFAZ. No entanto, teve outro problema, referente a justificativa da inutilização que ainda permanece (se for contemplado depois, então pode ignorar):

Olá Daniel, inicialmente eu havia percebido esse problema de acentuação na DANFCe, mas logo vi que foi resolvido e atualizei meus fontes. As contribuições que sugeri acima não incluem o problema de acentuação, tratam-se de outros ajustes que achei necessário na impressão de DANFe e DANFCe com FPDF. Além disso, corrigi um bug na função para Ler XML de inutilização de número de NF quando já homologada pelo SEFAZ (XML de exemplo em anexo no post inicial). No post inicial, há em anexo um arquivo PDF detalhando os ajustes realizados bem como os fontes com os mesmos ajustes aplicados.