charles.libano

Prezados, MG e RJ estão validando esta regra que deveria não ser validada, visto que não publicaram nada a respeito. No caso de MG, já reportei ao desenvolvimento da SEF/MG agora há pouco e estão verificando. No caso do RJ, não tenho contato com alguém de lá para reportar. Sugiro este tópico ficar aberto até sabermos da solução final de cada UF. Charles

Júlio prontamente me ligou da Tanca para atualizarmos o firmware e vamos fazer isso amanhã. Obrigado pela atenção. Reportarei aqui assim que tudo estiver concluído. Charles

Que boa notícia. A impressora é excelente.

Daniel, Fiz diferente, para manter o padrão do meu código-fonte: Alterei a propriedade ImprimirQrCodeLateral para False para esta impressora. Desta forma, continuo usando EscPos por padrão, porém, o "efeito tabela" se resolve. Obrigado pela ajuda. Pode encerrar o tópico. Charles

Bom dia. Entrei em contato com a Tanca (representante da Jetway). Me enviaram um link de um exemplo, com a seguinte resposta: "Utilize esse aplicativo Exemplo Delphi (https://www.tanca.com.br/assets/conteudo/drivers/TP-650/Exemplo_TP650_Delphi.zip) para emular a impressão de um cupom, e verifique se a impressão sairá com o layout correto. Apesar de todas as impressoras serem compatíveis com ESCPOS, sempre tem que fazer um ajuste ou outro, sendo assim, sugiro que ative o modo debug e utilize os comandos desse exemplo para realizar os ajustes na sua aplicação." Vejam que o exemplo está em baixo nível. Eu programava assim no Delphi 2 em 1996. Então, fica inviável até para eu entender... Eu preciso liberar essa impressora para uso. Existe uma forma de imprimir a NFCe nela através do ACBr sem usar o EscPos? Obrigado. Charles

Bom dia, amigos. Estou integrando a impressora Jetway JP-500 e estou tendo um problema ao imprimir a NFCe em EscPos nela. Quando imprime, ela imprime uma tabela de formatação que, além de ficar feio o DANFCe, também impossibilita a leitura do qrcode. Para comparar, estou enviando o mesmo documento feito numa Elgin i9 e nesta JP-500. Vejam que na Elgin i9 não sai esta tabela ou quadro... -500. Sabem como faço para corrigir este problema? A configuração que estou usando nela é esta abaixo (reconhecida pelo ACBr ao buscar portas): Modelo: ppEscGPrinter Porta: USB:Tanca,TP-550 Desde já agradeço a atenção. Charles

Resolvido. Com a dica do @BigWings Obrigado. Charles

Bom dia a todos. Instalei meu novo Delphi 10.4.1 Sydney e ao instalar o ACBr através do ACBrInstall_Trunk2.exe está ocorrendo um erro no pacote ACBr_TCP.dpk (unit ACBrIBGE.pas). Quando ocorrem erros deste tipo, sempre abro o pacote separado na IDE do Delphi e compilo, até remover qualquer erro. Porém, desta vez, o pacote está compilando normalmente na IDE. Vou anexar log e print da IDE compilando para ajudar. No Delphi 10.4 anterior, funcionava perfeitamente o instalador. Obrigado. Charles log_Delphi_10.4_Sydney_Win32.txt

Existem 2 formas de integrar. Todos os provedores de pagamento digital (PicPay, Ame, Mercado Pago) solicitam que, no endpoint da API que gera o QR Code, você forneça uma url de callback, para eles lhe responderem quanto à aprovação do pagamento (quando o cliente pagar via app deles no celular). Então, você pode fazer das seguintes formas: 1 - automatizado: sua url de callback grava no seu servidor a resposta. Vc cria um objeto no PDV no Padrão de Projeto Observer, que tão logo o cliente pague, vc lê (através do Redis por exemplo) e conclui a transação no PDV. 2 - manualmente, criando uma função de capturar resultado. Cliente paga, o callback grava o resultado e então vc lê este resultado. Espero ter ajudado. Charles

Amigos, Por desencargo de consciência, me tirem uma dúvida. Minha configuração atual é: oACBrNFE1.Configuracoes.Geral.SSLCryptLib := cryWinCrypt; oACBrNFE1.Configuracoes.Geral.SSLHttpLib := httpWinHttp; oACBrNFE1.Configuracoes.Geral.SSLXmlSignLib:= xsLibXml2; oACBrNFE1.SSL.SSLType := LT_TLSv1_2; Já está correto? Estou livre de ficar paralisado com a desativação do ssl? Obrigado. Charles

Ítalo, Boa tarde. Fiz a alteração, reinstalei o ACBr e funcionou perfeitamente. Acho que esta alteração poderia subir para os fontes, já que não prejudica outras funcionalidades e corrige o erro da SEFAZ. Obrigado pela ajuda. Charles

Bom dia a todos. Fiz um teste agora e em MG o cancelamento ainda está retornando com ns0 fora do padrão. Alguém pode me ajudar a resolver este problema? Acho que seria bom colocarmos no ACBr esta "correção do erro de MG". Quando consultamos no DFe uma NFCe de MG que foi cancelada, o retorno deveria vir o XML da transmissão com o protocolo do evento de cancelamento abaixo. Porém, pelo erro da SEF/MG, este retorno não vem, o que invalida o xml -NFeDFe.xml Se não for possível colocar nos fontes do ACBr, alguém pode me instruir como colocar nos meus fontes locais, pois a abstração é tamanha que nem sei onde mexer no ACBr nesta parte... Obrigado e desculpe a insistência, mas é crucial para meu sistema se manter correto sem grandes alterações, já que a equipe sou eu. rsrsrsrs. Charles

Amigos, O Coordenador da NFCe de MG está de férias. Retorna somente no próximo mês. Assim sendo, não há outra alternativa a não ser removermos manualmente os name spaces errados. Há possibilidade de atualizar os componentes para estender esta funcionalidade de "corrigir" os erros da SEF/MG e então retornar -NFeDFe.xml corretamente através do ACBr? Não sei fazer isso... Obrigado. Charles

Analisando melhor, o XML que você anexou não é o XML da NFe e sim o XML NFeDFe que agrupa o XML da NFe e a lista de eventos do mesmo: Ele é gerado com a extensão *-NFeDFe.xml. Você deve ter também um XML *-nfe.xml que é o XML da NFe com o protocolo de autorização apenas. Eu uso realmente como arquivo final o -NFeDFe.xml, renomeando-o. Ele terá NFe + eventos protocolados, ou seja, é um arquivo válido. O ACBr está montando normalmente o arquivo para os dois estados, mas como o retorno de MG vem fora do padrão (contendo os prefixos ns0:) acaba tornando o XML inválido. Há 2 meses, tivemos uma atualização do ACBr que removia os NameSpaces de MG no retorno da transmissão, devido aos retornos estarem vindo fora do padrão. Há possibilidade de atualizar os componentes para estender esta funcionalidade de "corrigir" os erros da SEF/MG e então retornar -NFeDFe.xml corretamente através do ACBr? Fazer uma reclamação na SEFAZ-MG a respeito dos prefixos, ou retirar manualmente os mesmos. Estou tentando telefonar diretamente para o Coordenador da NFCe de MG, para solicitar a correção deste erro através da STI. Obrigado pela ajuda. Charles

@BigWings O XML que anexei foi feito com a propriedade False, ou seja, mantinha o original e o do cancelamento. Porém, quero o arquivo xml completo, ou seja, faço uma consulta ao DFe e ele me retorna a NFe autorizada, acrescida abaixo do protocolo do cancelamento. (Em MG isto não está funcionando) Entendi que colocando a propriedade True, isto aconteceria automaticamente, ou seja, o ACBr pegaria a NFe original e colocaria abaixo dela o protocolo do cancelamento, ficando exatamente igual ao anexo que enviei do RJ. Mas isso não aconteceu. Como em MG tudo ainda é novo, os contadores se confundem com 2 xml, sendo um deles da NFe transmitida e outro do cancelamento da mesma. Não há como manter 2 arquivos por enquanto. Alguma sugestão? Obrigado. Charles