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

@BigWings Usei o comando: ACBrNFE1.Configuracoes.Geral.AtualizarXMLCancelado := True; Porém, não está sendo respeitado, não grava nada no xml final. Testei em RJ e MG. Alguma sugestão? Obrigado. Charles

Boa tarde a todos. Estou com um erro que vou tentar explicar abaixo: Emito uma NFCe normalmente. Se eu cancelo esta NFCe, para pegar o arquivo dela com o protocolo de cancelamento anexado, utilizo a função ACBrNFe.Consultar Funciona perfeitamente para RJ. Porém, para MG, o arquivo não abre como um XML válido. Estou com os fontes do ACBr atualizados neste instante. Seguem 2 respostas de consulta, uma correta do RJ e a outra inválida de MG. Acontece tanto em homologação quanto em produção. Alguém tem ideia de que erro é esse? Obrigado Charles 33191108900996000101650010000142791774105611-nfe-canc.xml 31191118991455000181650010000003251228813241-nfe-canc.xml

Resolvido com a dica do amigo @BigWings Obrigado. Charles

Olá a todos. Encontrei um erro na impressão do DANFCe em EscPos, quando utilizamos a funcionalidade de imprimir o qrCodeLateral. Fiz testes na Elgin I9 e na Epson TM-T20, ambas apresentaram o problema abaixo: Quando identificado o consumidor com CNPJ, Nome que ocupe 2 linhas, endereço + bairro que ocupe 2 linhas, cidade e uf na outra linha, não sai a linha do número e série da NFCe, nem a data e hora. Eu sugiro corrigir trocando a linha da NFC-e (número e série e data e hora) para vir antes da identificação do consumidor. E cortaria somente as sobras nas linhas da identificação (endereço), que julgo serem menos necessárias que a número/série. Eu mesmo faria esta correção, porém, não sei onde mexer nos códigos-fonte. Senão, terei que usar com qrCode embaixo nas NFCe identificadas o consumidor, o que aumentará em muito o consumo de papel, visto que a maioria dos clientes emitem mais de 1000 NFCe por dia, sendo quase 70% identificadas. Obrigado a todos. Charles

MG gera somente o CSCid 000001 com o mesmo CSC para homologação e produção. Este erro mencionado ocorreu nos contribuintes que fizeram o cadastro através do Fale Conosco na mesma semana que liberaram o acesso ao Siare. Não sei informar o motivo, mas estes contribuintes não conseguem gerar nada em homologação. O que pode tentar (em 1 cliente meu funcionou) é entrar no Siare e gerar novamente o CSC. Como se fosse iniciar o processo. Primeiro gera em homologação e após 2 horas gera produção. Note que o CSC será o mesmo anterior, nada muda, acho que somente grava no servidor de homologação da Sefaz. Charles

Amigos, Fiz o seguinte: Entro na contingência automaticamente ao detectar timeout ou erro de conexão. E para sair, criei 2 formas: tentando a cada meia hora ou então clicando no botão sair da contingência. Ah, e criei um monitor de contingências e pendências de canc/inut, além de editar xml recusados ao autorizar ctg. Fiz tudo ontem. rsrsrsrsrs. Obrigado a todos. Charles

Bom dia. Conseguiram alguma solução para NFCe em MG em produção? Erro 12002 Timeout de requisição. Obrigado. Charles

Bom dia, amigos. Faço todo o processo de contingência corretamente, ou seja, no timeout crio a nfe pendente, faço o clone do xml com nnf + 1, transmito em contingência. Quando retorna, envio as contingências para autorização e cancelo/inutilizo as pendentes. Imagine que emiti 10 nfce em contingência. Mas a dúvida que tenho é como detectar que devo sair da contingência após sefaz retornar ao normal? Se eu ficar tentando a cada nfce, terei que clonar todas e inutilizar ou cancelar muitas. Terei uma pasta de pendentes do tamanho da pasta de contingências a autorizar. Por outro lado, se eu ficar emitindo em contingência direta, pode ser que a sefaz já tenha retornado e eu não percebi na hora. Como vocês fazem esse processo de detectar a hora de sair da contingência? Nos exemplos e vídeos não fica bem claro como detectar a hora de parar de emitir em contingência (sair da contingência e emitir normal). Obrigado. Charles

Coloquei o arquivo na pasta do exe e funcionou perfeitamente. Manterei assim e distribuirei conforme recomendado. Obrigado pela dica. Charles

Os testes que estou fazendo são do RJ homologação. Amanhã cedo farei os testes novamente e aviso vcs. Obrigado. Charles