Painel de líderes

O ACBr suporta impressoras USB ? Durante muito tempo, a resposta a essa pergunta foi: NÃO, você precisa usar a Porta COM, Spool do Windows (RAW), Compartilhamento de Rede ou algum outro método... Porém agora isso mudou... Agora componentes que usam o ACBrDevice, como por exemplo o ACBrPosPrinter (para Impressoras Não Fiscais) e o ACBrETQ (para Impressoras de Etiquetas), possuem suporte a portas USB de maneira nativo do Windows... Ou seja, sem a necessidade de DLLs externas... Isso significa que caso o seu equipamento esteja conectado ao PC, por uma Porta USB... Você poderá conectar os componentes do ACBr, simplesmente definindo na Propriedade Porta algo como "USB" Exemplos de uso: ACBrPosPrinter1.Porta := 'USB' - Tenta descobrir qual é a Primeira Impressora de Bobinas plugada na USB e faz uso dela, se encontrar.. ACBrPosPrinter1.Porta := 'USB:Elgin' - Tenta conexão em alguma Impressora USB, listada como sendo do Fabricante 'Elgin' ACBrPosPrinter1.Porta := 'USB:Sweda, SI-300S' - Tenta conexão na Impressora USB, do Fabricante "Sweda" e do Modelo "SI-300S". ACBrETQ1.Porta := 'USB' - Tenta descobrir qual é a Primeira Impressora de Etiquetas plugada na USB e faz uso dela, se encontrar.. ACBrETQ1.Porta := 'USB:Zebra, GC420t' - Tenta conexão com a Impressora USB do Fabricante "Zebra", e modelo "GC420t" Observe que essa nova implementação é totalmente diferente do método de Hook, onde usávamos a DLL do Fabricante, como túnel USB... Nesse novo cenário a comunicação USB é feita diretamente usando a API do Windows, ou seja, sem necessidade de DLLs externas. Para compreender um pouco mais, sobre esse método veja esse artigo O método de Hook ainda está disponível, usando o prefixo de porta, 'DLL:' Como os Equipamentos são identificados ? Todo Equipamento USB, possui um código de identificação do Fabricante, chamado de Vendor ID (VID), e também do Produto chamado de Product ID (PID). Essa numeração é controlada pela USB.ORG, e você pode encontras uma lista de Todos os "Vendors ID", nesse link A classe TACBrUSBIDDataBase, mantêm um Banco de Dados interno, chamado ACBrUSBID.ini, com o mapeamento dos principais Equipamentos do Mercado Brasileiro.. Esse Banco de Dados é um simples Arquivo do tipo INI, que é compilado como resource e adicionado ao componente... Clique aqui para ver o layout do Banco de Dados no Formato INI, observe os comentários no inicio do arquivo, com algumas instruções de como inserir novos equipamentos nele. Se você distribuir o arquivo ACBrUSBID.ini, na mesma pasta do Executável da sua aplicação, a classe TACBrUSBIDDataBase fará uso desse arquivo, ao invéz de usar o resource interno... Isso pode ser muito útil para atualizar a lista de Dispositivos conhecidos, sem necessitar compilar uma nova versão do programa, apenas atualizando o ACBrUSBID.ini Como posso listar os equipamentos identificados pelo ACBr ? Use a Força, leia os fontes... Vamos ver trechos de código, do Demo PosPrinterTeste {$IfDef MSWINDOWS} // Os métodos abaixo, somente estão disponíveis para compilação em Windows // Carrega a lista de Impressoras detectadas em: ACBrPosPrinter1.Device.WinUSB.DeviceList ACBrPosPrinter1.Device.WinUSB.FindUSBPrinters(); // Varre a lista de Impressoras USB detectadas, e adiciona as mesmas, nas opções de Porta for K := 0 to ACBrPosPrinter1.Device.WinUSB.DeviceList.Count-1 do cbxPorta.Items.Add('USB:'+ACBrPosPrinter1.Device.WinUSB.DeviceList.Items[K].DeviceName); {$EndIf} Como o ACBr nomeia os dispositivos ? O "DeviceName" será calculado, de acordo com as informações disponíveis no banco de Dados... Primeiro o ACBr usa a API do Windows para captura informações do VID (Vendor ID ou Fabricante) e o PID (Product ID ou Modelo), dos Equipamentos listados... Se o ACBr falhar nessa tarefa, o equipamento será ignorado (não será listado) Se for capturado com sucesso a descrição em FriendlyName, então ela será usada.. Caso contrário, o ACBr tentará compor o nome, baseado no VID e PID Se o VID do Fabricante for encontrado na sessão [Vendors] de ACBrUSBID.ini, então o VID será substituído pela Descrição do Fabricante... Observe que na sessão [Vendors], temos vários fabricantes que não são conhecidos no mercado Brasileiro, mas são de equipamentos OEM, de Empresas nacionais... Nós procuramos manter o nome Original do Fabricante, de acordo com a tabelas de VID da OSB.ORG Se o VID não tiver equivalência na relação de [Vendors] de ACBrUSBID.ini, então ele será listado com o próprio número VID, que são 4 algarismos em Hexadecimal... Exemplo: "0b1b" Procuramos pelo PID do Equipamento, na sessão específica do Fabricante. Se não houver uma chave com o PID, então o ACBr usará o próprio número PID, para Nomear o Modelo. O PID também é composto do 4 algarismos em Hexadecimal... Exemplo: "0001" Se encontrar uma entrada com o PID, dentro da sessão do Fabricante, então o ACBr usará a Descrição do Modelo, e poderá desprezar a descrição do Fabricante, se a Descrição do modelo possuir uma vírgula, Exemplo: 7008=Elgin, I9;1;1... Nesse caso será desprezada a descrição do Fabricante "20d1-Dascom" e será usada apenas a descrição do Modelo, "Elgin, I9". Detecção automática de Porta e Protocolo Como agora temos um Banco de Dados, que informa além da Descrição do equipamento, qual é o Tipo do mesmo e qual o protocolo que ele usa, então os componentes ACBrPosPrinter e ACBrETQ, podem fazer uso dessas informações... Ou seja, se o equipamento for detectado com sucesso, no momento da Ativação da Porta (durante a chamada ao método "Ativar"), será usado o Protocolo Definido no Banco de Dados. Se for detectado que o equipamento USB é na verdade uma porta COM virtual, então o ACBr irá preferir fazer uso da Porta COM virtual, chaveando para mesma, de forma transparente... Pois dessa forma ele tem um melhor suporte a leitura de informações do equipamento. Se for detectado que a porta USB possui um equipamento incompatível com o componente em questão, isso também será alertado... Exemplo, você tentar conectar em uma porta 'USB:Zebra, GC420t' no componente TACBrPosPrinter, então um erro será emitido, pois esse equipamento não é uma impressora de Bobinas Como a mágica funciona ? Reparem que foi adicionado ao repositório a Unit ACBrWinUSBDevice.pas, essa Unit implementa chamadas a SetupAPI do Windows, para detectar os Dispositivos USB que estão listados em uma determinada Classe de Equipamentos (Class GUID)... O estudo desse artigo, foi fundamental, para a criação dessa Unit. Uma vez capturada o nome da Interface do Equipamento USB (em TACBrUSBWinDevice.DeviceInterface), podemos acessá-lo usando funções de manipulação Arquivos da API do Windows, como: CreateFile, WriteFile, ReadFile. Nem todos os dispositivos USB implementam suporte aos métodos ReadFile ou WriteFile... ou seja, pode não funcionar em alguns dispositivos.. Se você souber qual é o nome da Interface USB do equipamento, poderá informar ela diretamente na propriedade "Porta" dos componentes... Exemplo: ACBrPosPrinter1.Porta := '\\?\usb#vid_1c8a&pid_3002#0000000000022#{28d78fad-5a12-11d1-ae5b-0000f803a8c2}'; Para dúvidas, suporte ou correções, por favor crie um novo tópico, clicando aqui Para testar, baixe uma nova versão do PosPrinterTeste.exe

Olá Pessoal, Venho informa-los que já esta disponível em nosso repositório o mais novo componente que agora se integra a suíte ACBr. ACBrNF3e - Nota Fiscal de Energia Elétrica Eletrônica. Esse componente segue os moldes dos demais componentes que emitem DF-e - Documentos Fiscais Eletrônicos. "O Projeto NF3e tem como objetivo a implantação de um modelo nacional de documento fiscal eletrônico (modelo 66) que venha substituir a sistemática atual de emissão da Nota Fiscal/Conta de Energia Elétrica (modelo 6), com validade jurídica garantida pela assinatura digital do emitente, simplificando as obrigações acessórias dos contribuintes e permitindo, ao mesmo tempo, o acompanhamento da emissão em tempo real pelo Fisco." Para saber mais sobre o NF3e convido a todos a visitarem o Portal da Nota Fiscal de Energia Elétrica Eletrônica - SVRS. Temos também em nossa biblioteca toda a documentação referente a esse novo modelo de documento fiscal, clique aqui para acessar nossa biblioteca. O que foi disponibilizado: Fontes do componente ACBrNF3e e os fontes do componente ACBrNF3eDANF3eESCPOS (usado para imprimir o DANF3E). Notem que existe a Nota Técnica 2020/001 onde apresenta 3 layouts de DANF3E, sendo dois no tamanho A4 (Retrato) e um a ser impresso em bobina. Convido a todos a contribuir com a implementação dos DANF3E tamanho A4 (Retrato) e refazer o layout em bobina segundo essa nova NT. Esta disponível também os pacotes de instalação dos dois componentes mencionados acima, tanto para o Delphi quanto para o Lazarus. E como de costume, também foi disponibilizado o programa exemplo tanto para o Delphi quanto para o Lazarus. Observação: O ACBrInstall_Trunk2 ainda não reconhece esse componente, logo a sua instalação deverá ser realizar através dos pacotes disponibilizados. Assim que possível estaremos disponibilizando uma nova versão do ACBrInstall_Trunk2 que vai instalar o ACBrNF3e e o componente para imprimir DANF3E automaticamente.

O ACBrMTER não usa nenhuma DLL... ele mesmo implementa a comunicação com os equipamentos pelo protocolo do mesmo... O Micro Terminal da Gertec usa o protocolo PMTG o

Bom dia Joabe, O componente responsável por imprimir o DACTE feito em Fortes Report se encontra na pasta: ...\Fontes\ACBrDFe\ACBrCTe\DACTE\Fortes Note que não existe nenhuma Unit que traga alguma menção a Paisagem somente Retrato, por exemplo: ACBrCTeDACTeRLRetrato.pas. Apesar de existe a propriedade de configuração tiPaisagem não temos implementado esse modelo. Se desejar contribuir com o projeto e implementar ficaremos gratos.

Pessoal, o problema foi achado... Eu criei uma SQL em runtime no meio da impressão e não dei o FREE no final do processo. Nada a ver com o componente... Obrigado mais uma vez Daniel. O tópico pode ser encerrado.

@Daniel Simoes Bom Dia, atualizei meu componente, com a ajuda do amigo Eric.Developer , achei o problema no libacbrboleto64.so junto ao Harbour em Linux, agora está funcionando bem. voltei então para libnfe e apos inúmeros testes observei que o problema ocorre quando informo SSLCryptLib=1... falha no nucleo porem, se deixo ele como SSLCryptLib=0 passa e apresenta um erro dizendo que o certificado esta vencido conforme o log em anexo ... acho que agora já estamos chegando perto de resolver ... obrigado pela paciência e empenho em ajudar.... ACBrLibNFE-20191224.log acbrlib.ini

Bom dia. O Banco Central publicou informações sobre os planos de implantação dos Pagamentos Instantâneos no Brasil, o qual tem previsão de implementação em Novembro/2020. Os Pagamentos Instantâneos são as transferências monetárias eletrônicas na qual a transmissão da ordem de pagamento e a disponibilidade de fundos para o usuário recebedor ocorre em tempo real e cujo serviço está disponível durante 24 horas por dia, sete dias por semana e em todos os dias no ano. As transferências ocorrem diretamente da conta do usuário pagador para a conta do usuário recebedor, sem a necessidade de intermediários, o que propicia custos de transação menores. Conforme texto do BC, apresenta as seguintes vantagens... Sua implementação deve, além de aumentar a velocidade em que pagamentos ou transferências serão feitos e recebidos, também tem o potencial de alavancar a competitividade e a eficiência do mercado; baixar o custo, aumentar a segurança e aprimorar a experiência dos clientes; promover a inclusão financeira e preencher uma série de lacunas existentes na cesta de instrumentos de pagamentos disponíveis atualmente à população. Esse modelo está em linha com a revolução tecnológica em curso, possibilita a inovação e o surgimento de novos modelos de negócio e a redução do custo social relacionada ao uso de instrumentos baseados em papel. Para mais detalhes, clique aqui e acesse o portal do Banco Central. Att.

Bom Dia, a todos O EDI são arquivos de troca de informações entre o cliente e a transportadora cadastrada, é utilizado por algumas empresas tais como: Acor, Ypê dentre outras, para agilizar o processo de troca das informações relacionadas com os seguintes arquivos: CONEMB => Conhecimentos (CT-e) gerados pela transportadora OCORREN => Ocorrências fatos que geraram uma Devolução, re-entrega, etc. DOCCOB => Documento pelo qual a transportadora efetua a Cobrança dos serviços prestados NOTFIS => Romaneio referente as notas fiscais que serão ou deverão ser embarcadas pela transportadora. Então resolvi criar um componente para gerar estes arquivos, já faço uso dele a algum tempo e agora que está funcionando em alguns clientes meus, estou fazendo a doação do mesmo ao projeto ACBr, se assim a equipe achar viável. O componente está preparado para gerar os arquivos nas seguintes versões: 3.0, 3.0a, 3.1 e 5.0. Em anexo os arquivos para análise, estão separados de acordo com as pastas do projeto. Desde já obrigado pela atenção. Miguel Carlos. EDI.zip

Atualize novamente por favor. O instalador foi revertido pra versão anterior.

Boa Tarde, Gostaria de agradecer a equipe que se envolveu na solução do meu problema..... pois o resultado final foi perfeito.... tudo funcionando perfeitamente bem.... Um Feliz Natal para todos.....

Acho que agora consegui. Recebi esta mensagem no campo das respostas: [Status] CStat=107 CUF=33 DhRecbto=24/12/2019 15:08:49 Msg=Servico em Operacao TMed=1 VerAplic=SVRS201805211008 Versao=4.00 XMotivo=Servico em Operacao XObs= tpAmb=2 Vou continuar trabalhando aqui na integração. Grato desde já.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Elton, bom dia! Muito grato pela informação. Foi resolvido quando copiei as DLLs da pasta XMLSec para a SysWOW64... Apesar de eu ter feito antes, havia copiado as dlls da pasta LibXml2 e não da XMLSec... Mais uma vez, muito grato.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Não existe limite de altura em impressora de bobina, pois se houve-se em escpos também daria o problema. E como disse não parece ser problema no ACBr e sim no driver da impressora.

Bom dia, Testei e está funcionando corretamente . Obrigado !

Muito Obrigado pelo retorno Italo.

Em primeiro lugar verifique se está utilizando a última versão dos componentes e instalador. Vários problemas foram corrigidos recentemente relacionados a cópia das DLLs. Pela imagem de erro o mais certo é que outras dlls estão sendo usadas. Visto que seu Windows é 64 bits, as DLLs de 32 bits usadas pelo ACBr devem estar na pasta SysWOW64 e não em System32. Desinstale o ACBr e tenha certeza que o Delphi funciona corretamente sem ele antes de instalar novamente.

Rapaz eu acho que vi o erro aqui e era na classe do Java que tava desatualizada, eu enviei uma correção, baixe novamente e teste fazendo favor.

Sim pois como SSLCryptLib = 0 não tem nenhuma classe para consumir o certificado. Pelo visto é algo em relação ao carregamento da dll do OpenSSL, checa se a versão do OpenSSL é maior que 1 e menor que 1.1 e checa se a mesma é x86 ou x64 de acordo com a biblioteca que esta usando, Ex.: se sua biblioteca que esta usando é x86 a do OpenSSL também tem quer ser e vice e versa.

Muito obrigado pela report. Com sua ajuda consegui identificar o problema e fiz uma possível correção. Subi as alterações para o SVN na Revisão 18606. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Bom dia Alex, Que eu saiba não existe nada que nos retorne o numero do ultimo lote enviado. Acredito que a solução seria entrar em contato com o provedor e solicitar o numero do ultimo lote enviado.

Bom dia Jonathan, É uma NF-e ou NFC-e? Qual é o valor que você atribuiu para indFinal ?

Bom dia Rene, Por favor entre em contato com a Prefeitura e solicita um XML de exemplo. O XML que necessito é o que contem o a tag Envelope e não o XML do RPS, pois este o componente esta gerando e validando sem nenhum problema.

Bom dia Daniel! Bem, vamos aos testes: SATTeste - rodou tudo ok. Meu aplicativo - voltei até a versão anterior do ACBR que funcionava (revisão 1750) - pau na saída. Não vai ter jeito... Vou reavaliar todo o processo de impressão... rssss... Agradeço a atenção Daniel. Boas festas pra vc e família. Abraço!

Creio que seja algo na sua aplicação... afinal, não há relatos semelhantes no fórum... Teste com o Demo do ACBr... O SATTeste... se conseguir reproduzir o problema nele, favor informar o passo a passo...

Muito obrigado pela contribuição. Fiz a implementação baseada nela com algumas modificações. Subi as alterações para o SVN na Revisão 18602. Pelo que vi está tudo certo. Mais uma vez obrigado. Estou fechando esse tópico que já serviu ao seu propósito. Queira por favor atualizar, testar e reportar qualquer problema em um novo tópico.

Agora o ACBr está pronto para a versão 014. Conforme mencionado no tópico abaixo:

se tu vende, tu tem o xml e não baixa, somente consegue baixar as de entrada que alguém emite contra você ! e não é pra 100% das notas é para baixar as que perdeu, extraviou, não conseguiu receber, pois o seu fornecedor é obrigado por lei a enviar ela. olhe o exemplo do svn do acbrnfe que está lá como baixar as notas emitidas contra você e tem uns tópicos aqui no fórum explicando . mas tem que ver senão é só para o SAC

Fala Daniel! Boa tarde... A versão anterior funcionava normalmente. Olhando no demo, notei q existem novas propriedades... Vou olhar todas certinho e depois posto o resultado, ok? Muito obrigado por enquanto.

Movendo para subfórum mais adequado. Talvez você tenha mais sucesso buscando ajuda num fórum dessa biblioteca.

A sugestão não parece correta... o UnlimitedHeight foi criado justamente para dar suporte a relatórios sem tamanho de página...

Enviei um e-mail para o pessoal da Kaspersky, pedindo providências. Mandei um e-mail agora, inclusive mencionando esse post e a dificuldade de todos os usuários.

Nesta sequencia, funcionou beleza... Obrigado...

Jovem, 1 - Eventos de Tabelas 2 - Eventos Não Periódicos 3 - Eventos Periódicos

Ricardo, Nos arquivos em anexos não tem um XML de exemplo de cancelamento. Dessa forma fica difícil de descobrir o que esta errado.

Boa tarde Srs... A titulo de conhecimento: 20/12/2019 - ATENÇÃO: SVRS - Desativação dos protocolos SSL, TLS 1.0 e TLS 1.1. A Sefaz Virtual do Rio Grande do Sul (SVRS), para garantir o bom funcionamento do Ambiente de Autorização dos Documentos Fiscais Eletrônicos, deverá desabilitar os protocolos de comunicação mais antigos a partir do dia 16/01/2020. Esta mudança é necessária, não só pela simplificação do ambiente e aumento da segurança, como também pela inviabilidade de configuração dos protocolos de comunicação mais antigos em nova versão do sistema operacional dos servidores. Período de desativação: - Protocolos SSL e TLS 1.1: entre os dias 16 e 21/01/2020. - Protocolo TLS 1.0: entre os dias 21 e 30/01/2020. A partir do dia 30/01/2020, o Ambiente de Autorização dos DF-e deverá suportar unicamente o protocolo de comunicação TLS 1.2, conforme previsto na documentação técnica, vide NT 2016.002 da NF-e e NT 2017.002 do CT-e. fonte: http://www.cte.fazenda.gov.br/portal/informe.aspx?#87

No dia 13/11/2019 a SEFAZ-CE publicou no DOE, o decreto 33.351 o qual determina que estabelecimentos enquadrados no CNAE 4711-3/01, além daqueles que são atacadistas e ainda possuem ECFs em funcionamento, passam a ser obrigados a partir desta data, a identificar o CPF/CNPJ ou Identificação válida para os estrangeiros em todos os documentos fiscais emitidos (ECF, CFe, NFe e NFCe) Abaixo, transcrição do texto do decreto. § 1.º Os estabelecimentos enquadrados na CNAE-Fiscal 4711-3/01 (Comércio varejista de mercadorias em geral, com predominância de produtos alimentícios – hipermercados), bem como os contribuintes atacadistas usuários de equipamento Emissor de Cupom Fiscal (ECF), ficam obrigados a indicar no documento fiscal o número da inscrição no CPF ou no CNPJ do comprador ou destinatário ou, tratando-se de estrangeiro, do documento de identificação admitido na legislação civil, em todas as operações em que haja a emissão de cupom fiscal, CF-e, NF-e e NFC-e. Fonte DOE CE: http://imagens.seplag.ce.gov.br/PDF/20191113/do20191113p01.pdf