Painel de líderes

Já pensou em rodar o seu PDV ou ERP em Linux ? Há muito tempo os fontes do ACBr já compilavam em Linux através do Lazarus/FPC, e agora também é possível compilar o ACBr no Linux Ubuntu 64, com o Delphi Rio 10.3.3, usando a Linux FMX Mas quais são as vantagens de rodar em Linux ? Inúmeras vantagens.. o Linux é um Sistema Operacional, Livre, muito estável, seguro e robusto.. Não é a toa que grandes empresas, preferem rodar Linux em seu PDV (Carrefour, Pão de Açúcar, Droga Raia, etc..)... Um Linux bem configurado, é da filosofia Instale e Esqueça, e pode representar uma enorme economia, em atendimento no suporte técnico... Sem falar na evidente vantagem de custos de licenças, quando comparado ao Windows... Se você tiver um profissional "linuxer" na sua equipe, você ainda poderia criar uma distribuição Linux altamente personalizada para as necessidades do seu software, e permitir que o seu PDV/ERP seja carregado automaticamente, sem intervenção do usuário... Devo usar Lazarus ou Delphi ? Em ambos os casos, será necessário adaptações ou reescrita no seu código... Você deve evitar o uso de chamadas diretas a APIs do Windows, ou usar IFDEFs para isolar esses códigos... Você poderá encontrar muito exemplos de IFDEFs, nos fontes do ACBr. Se você já programa em Lazarus, deverá instalar o Lazarus em um Linux e testar a compilação do seu código usando a GTK2 ou QT... Se você programa em Delphi VCL, primeiro deverá converter seu sistema para FireMonkey (FMX)... Isso pode ser uma tarefa difícil se for feita manualmente, pois existem muitas diferenças entre a VCL e a FMX. Mas você pode contar com a ajuda de Ferramentas que ajudam na conversão, como a MidaConverter A Mida, gentilmente nos concedeu uma licença do Mida Converter... com isso, já iniciamos a migração dos Demos do ACBr de Delphi VCL, para Firemonkey.. Você poderá encontrá-los na pasta "Firemonkey", de cada Demo, exemplo: \ACBr\Exemplos\ACBrDFe\ACBrNFe\Firemonkey Veja abaixo, uma Imagem do Demo do ACBrNFe, já convertido para FireMonkey, e rodando no Linux Ubuntu 64 bits, com o Delphi 10.3.3, Linux FMX A FMX é o futuro do Delphi, a Embarcadero está investindo muitos recursos no aprimoramento da FMX... leia mais nessa página . Aplicações FMX são infinitamente mais bonitas que aplicações VCL, e os efeitos visuais que a FMX proporciona, são incríveis... Duvida ? Então veja o vídeo abaixo... Sempre será mais simples, migrar de Delphi VCL para Delphi FMX, do que de Delphi VCL para Lazarus... migrar de IDE é um processo "doloroso" e que necessita muito mais tempo, preparação e aprendizado... Não quero aqui, defender o Delphi ou o Lazarus... Acho que a questão de OpenSource, deve pesar apenas se o preço do Delphi for realmente um impedimento para você... Avalie muito bem o tempo e esforço necessário, em ambos os cenários...

Olá pessoal, É com muita satisfação que comunicamos que agora os Fontes do Projeto ACBr, já foram ajustados para suportar o OpenSSL na versão 1.1.1 Antes de prosseguir, o que é OpenSSL ? "O OpenSSL é um kit de ferramentas robusto, de nível comercial e completo para os protocolos Transport Layer Security (TLS) e Secure Sockets Layer (SSL). É também uma biblioteca de criptografia de uso geral" https://www.openssl.org/ No Projeto ACBr, usamos o OpenSSL para diversas tarefas, como por exemplo: Comunicação Segura: Ele será necessário se você usa o componente ACBrMail, ou os componentes da aba ACBrTCP, que fazem comunicação Segura com sites, pelo protocolo HTTPS. A ACBrDFeSSL, que é usada por todos os componentes de Documentos Eletrônicos do ACBr, também podem usar o OpenSSL para comunicação Segura (como uma das opções) Criptografia: Ele é usado nos componentes ACBrEAD e pela ACBrDFeSSL para calcular e Verificar Hashs e Assinaturas digitais, usando diversos padrões de Criptografia O OpenSSL é uma excelente opção... na verdade, é a minha recomendação de uso, para quem usa certificados do tipo A1 A vantagem principal, é que com o OpenSSL, você está livre da necessidade de sempre manter o seu Windows Atualizado para que a comunicação segura com TLS1.2 funcione. Com o OpenSSL você poderia ter suporte a TLS1.2, mesmo no Windows XP. Como desvantagem, no ACBr, o OpenSSL, apenas suporta Certificados do tipo A1 Porque essa atualização é importante ? O principal motivo, é que as versões anteriores deixarão de ser suportadas e não mais receberão atualizações e correções, conforme podemos ver nessa página Mas outro motivo igualmente importante, é que atualmente é muito difícil de instalar uma versão antiga do OpenSSL em alguns sistemas Operacionais. Isso poderia ser um impedimento, para executar o ACBr em várias distribuições de Linux... A atualização dos fontes não foi um processo trivial, pois a API do OpenSSL recebeu modificações substanciais, desde a versão 1.0.x https://www.openssl.org/blog/blog/2018/09/11/release111/ https://wiki.tizen.org/Security/Tizen_5.X_Migration_from_OpenSSL_1.0.2_to_OpenSSL_1.1.1_guide Preciso atualizar meu cliente Final ? Não necessariamente... o código fonte do ACBr, é esperto o bastante para suportar todas as versões do OpenSSL, desde a série 0.9.8 até a 1.1.1.x. Mas é altamente recomendado que você atualize seus Scripts de Build, para usar e distribuir a última versão do OpenSSL no seu instalador automatizado... (veja como distribuir, abaixo) Lembre-se que se você precisa usar recursos mais novos, como comunicação segura com TLS1.2, precisará ter o seu OpenSSL atualizado, para versões mais novas... Todos os Scripts que geram os instaladores do ACBrMonitorPLUS e os pacotes da ACBrLib, assim o ACBrInstall_trunk2.exe, já foram atualizados para usar e distribuir as DLLs da nova versão 1.1.1.x Como o OpenSSL é distribuído ? Você pode encontrar versões compiladas do OpenSSL para praticamente qualquer Sistema Operacional existente... No SVN do ACBr, você encontrará as últimas versões das Bibliotecas compiladas para Windows em: http://svn.code.sf.net/p/acbr/code/trunk2/DLLs/OpenSSL/ Repare que em cada diretório, temos as pastas x86 (32 bits) e x64 (64 bits)... Se você compila seu programa em 32 bits, então você deve usar a versão 32 bits da DLL O OpenSSL é distribuído em em 2 arquivos. Sempre mantenha os dois arquivos juntos, e sempre use o par de arquivos da mesma versão. No Windows: Até a versão 1.0.x, os nomes dos arquivos eram: ssleay32.dll e libeay32.dll, e não havia distinção nos nomes das DLLs, entre as versões 32 e 64 bits. A partir da versão 1.1.0, os nomes dos arquivos mudaram para: libssl-1_1.dll e libcrypto-1_1.dll (32 bits) e libssl-1_1-x64.dll e libcrypto-1_1-x64.dll (64 bits) Tudo que você precisa fazer, é copiar o par de arquivos (libssl-1_1.dll e libcrypto-1_1.dll) para a mesma pasta do seu binário, ou seja, na mesma pasta onde está o seu .EXE (sim, você poderia copiar esses arquivos para o diretório System do Windows, mas isso deve ser evitado, pois pode causar conflitos com outras aplicações) As DLLs do OpenSSL que estão no repositório do ACBr, são compiladas com o Visual C Studio, portanto, será necessário que na máquina destino, exista as DLLs de RunTime do Visual C. Como centenas de programas tem essa mesma dependência, provavelmente as DLLs de RunTime já estão instaladas no seu Windows... Porém, caso você perceba o erro: "Este aplicativo não pôde ser iniciado porque não foi encontrado vcruntime140.dll", provavelmente o RunTime ainda não foi instalado, a solução nesse caso, é bastante simples, bastando instalar: http://svn.code.sf.net/p/acbr/code/trunk2/DLLs/Diversos/x86/VC_redist.x86.exe Você pode/deve, rodar esse procedimento no seu instalador, automatizado... isso pode ser feito de maneira silenciosa, e sem a intervenção do usuário... Veja esse artigo: No ACBrMonitorPLUS, usamos da seguinte maneira: VC_redist.x86.exe /install /passive /norestart No Linux: libssl.so.x.x.x - exemplos: libssl.so.1.1, libssl.so.10, libssl.so.1.1.1, libssl.so.1.1.0, libssl.so.1.0.2 , libssl.so.0.9.8, etc libcrypto.so.x.x.x - exemplos: libcrypto.so.1.1, libcrypto.so.10, libcrypto.so.1.1.1, libcrypto.so.1.1.0, libcrypto.so.1.0.2, libcrypto.so.0.9.8, etc O OpenSSL já vem instalado por padrão em várias distribuições Linux, caso contrário, use o seu gerenciador de pacotes, e instale o pacote "openssl" Veja mais sobre a distribuição de Bibliotecas em: https://acbr.sourceforge.io/ACBrLib/ComoInstalarDistribuir.html A nova rotina de Carga dinâmica das Bibliotecas do OpenSSL, que foram implementadas na Unit OpenSSLExt.pas, irá procura por vários nomes de arquivos, dando preferência para os arquivos mais novos. Ou seja, ela irá procurar pelas bibliotecas na versão 1.1.1.x, e não encontrando, procurará e pelas bibliotecas na versão 1.0.x ou inferiores Quer saber mais sobre como o ACBr usa o OpeSSL na criação e transmissão de Documentos Seguros ? Então de uma olhada nesse vídeo: Atualização em 12/03/21: A "Mikeysoft" não vem fazendo um bom trabalho no instalador do Visual C++ Runtime... parece que faltam dependências em "VC_redist.x86.exe"... Por isso recomendamos esse instalador: https://github.com/abbodi1406/vcredist/releases .. onde o desenvolvedor criou um instalador único, que roda todas as versões do instalador do Visual C++ Runtime

Precisei de criar um novo modelo de DAMDFe em Fast, exibindo melhor algumas informações do modal aquaviário. Em anexo o arquivo do relatório e o fonte pois precisei criar um CDS para exebição de algumas informações. O arquivo fr3 em vez de alterar os já existentes apenas adicionei o novo. ACBrMDFeDAMDFEFR.pas DAMDFe_Retrato_mod3.fr3

Os exemplos de ini você encontra aqui. https://acbr.sourceforge.io/ACBrLib/Informacoes1.html

A partir desta postagem os fontes ACBr passaram por ajustes, ficando compatível com a versão 1.1.1 da lib OpenSSL. Sendo assim desconsidere as configurações acima, se a sua Distro Linux já utiliza a versão 1.1 da OpenSSL. Se a sua Distro utiliza a versão anterior da OpenSSL , vai funcionar da mesma forma, porém apenas a versão 1.1 será mantida atualizada pelo projeto OpenSSL, até mesmo por isso o ACBr atualizou-a no Projeto. Saiba mais detalhes no post abaixo:

Ainda não temos previsão... Antes, devemos iniciar um refactoring no componente ACBrNFSe... o que deve ocorrer em Fevereiro, e deve levar várias semanas...

Olá pessoal, Alguém já imaginou ou tem a necessidade de imprimir o boleto em uma impressora térmica? Pois bem, o @guilhermekm teve a necessidade, arregaçou as mangas e implementou um novo layout chamado lTermica80mm. Guilherme, muito obrigado pela colaboração, já esta disponível no repositório. Quero também agradecer ao @Doug Dela Bite pelos ajustes feitos na implementação do Guilherme, muito obrigado Douglas. Abaixo o Preview e a impressão do boleto feita em uma Epson TM-T20X. Esse layout esta disponível apenas para o Fortes Report, portanto convido aos mestres em Fast Report a fazerem o mesmo que o Guilherme e Douglas. Estou aguardando o layout para o Fast! Compatibilizei o LFM do Lazarus com o DFM do Delphi, sendo assim é para funcionar sem nenhum problema no Lazarus / Fortes Report. Veja aqui o tópico original:

Olá Pessoal, Já se encontra em nossa biblioteca a NT 2020/001 da NF-e segue abaixo um resumo sobre ela. Resumo: Este documento substituirá as Notas Técnicas(NT) 2012.002 e 2013.001 e tem por objetivo unificar as informações referentes à manifestação do destinatário na Nota Fiscal eletrônica (NF-e) modelo 55 e estender o serviço para ser usado também por Pessoa Física (CPF). A manifestação está prevista na cláusula décima-quinta-A do Ajuste SINIEF 7/2005, a qual permite que o destinatário da Nota Fiscal eletrônica confirme a sua participação na operação acobertada pela Nota Fiscal eletrônica emitida para o seu CNPJ/CPF, através dos eventos tratados a seguir. 3 - Prazos para realização dos eventos de manifestação do destinatário Evento Prazo legal(Ajuste SINIEF 44/20) Ciência da Emissão 10 dias contados a partir da data de autorização da NF-e Confirmação da Operação 180 dias contados a partir da data de autorização da NF-e Desconhecimento da Operação 180 dias contados a partir da data de autorização da NF-e Operação Não Realizada 180 dias contados a partir da data de autorização da NF-e 4 -Obrigados a realização da manifestação do destinatário A cláusula décima-quinta-B do Ajuste SINIEF 7/2005 prevê a obrigatoriedade do registro pelo destinatário da NF-e dos eventos de confirmação da operação, operação não realizada e desconhecimento da operação nos prazos especificados naquele Ajuste. Também está obrigado a realizar a manifestação, de acordo com o Anexo II do Ajuste SINIEF 7/2005, o destinatário de toda NF-e que: I – seja exigido o preenchimento do Grupo Detalhamento específico de Combustíveis, como nos casos de mercadoria destinada a: a) estabelecimentos distribuidores de combustíveis, a partir de 1º de março de 2013; b) postos de combustíveis e transportadores revendedores retalhistas, a partir de 1º de julho de 2013; II - acoberte operações com álcool para fins não-combustíveis, transportado a granel, a partir de 1º de julho de 2014; III – acoberte, nos casos em que o destinatário for um estabelecimento distribuidor ou atacadista, a partir de 1º de agosto de 2015, a circulação de: a) cigarros; b) bebidas alcoólicas, inclusive cervejas e chopes; c) refrigerantes e água mineral. Obs: a NT 2012/003 (item 03.1), publicada em agosto/2012, define quais são os CFOP que obrigam a informação do Grupo de Combustível na NF-e. Os CFOP citados estão relacionados com as operações que envolvem “Combustível derivado ou não de Petróleo e Lubrificantes”. • Como as operações com lubrificantes são exceção à obrigatoriedade de manifestação do destinatário, consta no Anexo II a tabela de Códigos de Produto da ANP relativa a lubrificantes e que não estão obrigados à Manifestação do Destinatário Conclusão: Não existe nenhuma implementação a ser feita no componente, simplesmente agora a pessoa física que possui um e-CPF (Certificado Digital) poderá realizar a Manifestação do Destinatário, ou seja, enviar para a SEFAZ um dos 4 tipos de eventos que engloba a Manifestação do Destinatário. O componente já esta apto a gerar o XML do respectivo evento com o CPF do destinatário em vez do CNPJ.

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.

Olá pessoal, Foi publica a NT 2020/001 do MDF-e e ela já se encontra em nossa biblioteca. Resumo: O projeto MDF-e Integrado tem como objetivo a disponibilização, pelas Secretarias de Fazenda, de uma infraestrutura digital de documentos, legislações e processos voltados para a simplificação da emissão de documentos fiscais eletrônicos de transporte e integração, dentro de um ecossistema digital, que permite às Empresas Transportadoras de Cargas (ETC), Transportadores Autônomos de Cargas (TAC), ANTT, Administradores de Meios de Pagamentos e as próprias Secretarias de Fazenda, o aperfeiçoamento dos seus processos e compartilhamento de informações entre todos estes atores, a partir de um único documento e infraestrutura já consolidada e em uso por todos os envolvidos. Diante desse desafio, as Secretarias de Fazenda e o ENCAT, vêm nos últimos meses e em parceria com os diversos atores intervenientes, adotando uma série de ações estruturantes voltadas para superação das dificuldades atuais enfrentadas pelos órgãos de controle e geração de um ambiente operacional mais eficiente e competitivo, a exemplo das ações descritas abaixo: Aprovação de legislação nacional que normatizou o compartilhamento dos MDF-e dos 27 estados com os órgãos reguladores de transportes; Aprovação de legislação nacional que normatizou a obrigatoriedade de emissão do MDF-e em todas as operações de transporte, sejam elas intermunicipais ou interestaduais; Implantação da plataforma digital e registro de eventos eletrônicos que permitem ao transportador confirmar a entrega da mercadoria ao destinatário, possibilitando assim, a redução do prazo para o recebimento do frete por parte do caminhoneiro; Aprovação de legislação criando a Nota Fiscal Fácil (NFF), que permitirá aos contribuintes que operam com vendas de mercadorias e transportadores autônomos emitirem seus respectivos documentos fiscais de forma simplificada e a partir do seu próprio smartphone, conforme legislação publicada no D.O.U. do dia 19/12/2019 (Ajuste SINIEF No. 37 de 13 de dezembro de 2019); Publicação dessa NT, que estrutura o MDF-e de forma a possibilitar, entre outros benefícios: Geração automática do CIOT, pelo Sistema MDF-e, tanto para as modalidades TAC-Independente como TAC-Agregado; Automação do processo de fiscalização do Piso Mínimo do Frete (Tabela do Frete), nos termos da Resolução ANTT nº 5.849 de 16 de julho de 2019. Geração de informações para facilitar a negociação de direitos de recebimentos de fretes, por parte do TAC, junto a instituição financeira onde possui conta corrente, sem a interferência de atravessadores. Com essa NT temos: - Alterações de schema e regras de validação do MDF-e - Alterações no schema do modal rodoviário no grupo infANTT - Criação do evento de Pagamento da operação de transporte Portanto teremos um evento novo, criação do grupo Produto Predominante <prodPred> na parte geral do MDF-e, alteração no grupo informações do contratante, inclusão dos campos <xNome> e do <idEstrangeiro>, no modal rodoviário foi criado o grupo informações do pagamento do frete <infPag>. Novas Regras de Validação: Se modal rodoviário e indicador de pagamento for a prazo (tag:indPag=1): O grupo de informações a prazo deve ser informado (grupo:infPrazo). Implementação Obrigatória. Gera a Rejeição: 724. Se modal rodoviário, o grupo produto predominante deve estar informado (grupo: prodPred). Implementação Obrigatória. Gera a Rejeição: 725. Se modal rodoviário e MDF-e possuir apenas um DF-e transportado no grupo infDoc: O grupo de informações da carga lotação (infLotacao) deve estar informado. Implementação Facultativa. Gera a Rejeição: 726. Se modal rodoviário e informado grupo de pagamento, rejeitar se CNPJ/CPF do responsável pelo pagamento estiver inválido. Implementação Obrigatória. Gera a Rejeição: 727. Se moda rodoviário e informado grupo de pagamento, rejeitar se CNPJ do IPEF estiver inválido. Implementação Obrigatória. Gera a Rejeição: 728. Vai ocorrer alterações no componente? Sim Vai ocorrer alterações nos schemas? Sim Vou ter que adequar a minha aplicação? Sim Prazos: Ambiente de Homologação: 09/03/2020 Ambiente de Produção: 06/04/2020

Boa tarde @Juliana Tamizou, eu fiz umas alteração simples no fonte do boleto, o que seria o titulo quando da Preview, Report do Fast e Fortes. Fonte unit ACBrBoleto; Adicionei FTituloCabecalho : string; procedure SetTituloCabecalho(const Value: string); property TituloCabecalho : string read FTituloCabecalho write SetTituloCabecalho; procedure TACBrBoletoFCClass.SetTituloCabecalho(const Value: string); begin FTituloCabecalho := Value; end; Fonte unit ACBrBoletoFCFR; procedure TACBrBoletoFCFR.Imprimir; begin inherited Imprimir; // Verifica se a lista de boletos está vazia with FdmBoleto do begin cdsBanco.EmptyDataSet; cdsCedente.EmptyDataSet; cdsTitulo.EmptyDataSet; if PreparaRelatorio then begin frxReport.PrintOptions.ShowDialog := (MostrarSetup) and (not FModoThread); frxReport.PrintOptions.Copies := NumCopias; frxReport.ReportOptions.Name := TituloCabecalho; <-- Adicionado Fonte unit ACBrBoletoFCFortes; procedure TACBrBoletoFCFortes.Imprimir; var frACBrBoletoFortes : TACBRBoletoFCFortesFr; RLFiltro : TRLCustomSaveFilter; RLLayout: TRLReport; begin inherited Imprimir; // Executa verificações padroes frACBrBoletoFortes := TACBrBoletoFCFortesFr.Create(Self); try with frACBrBoletoFortes do begin case LayOut of lCarne : RLLayout := BoletoCarne; lReciboTopo : RLLayout := BoletoReciboTopo; lFaturaDetal : RLLayout := LayoutFaturaDetal; else RLLayout:= LayoutBoleto; end; if (NumCopias > 0) and (RLPrinter.Copies <> NumCopias) then begin RLPrinter.Copies := NumCopias; end; RLLayout.PrintDialog := MostrarSetup; RLLayout.ShowProgress := MostrarProgresso; RLLayout.Title := TituloRelatorio; --> adicionado Inicio if TituloCabecalho <> '' then begin RLLayout.PreviewOptions.Defaults := pdIgnoreDefaults; RLLayout.PreviewOptions.Caption := TituloCabecalho; end else RLLayout.PreviewOptions.Defaults := pdUseDefaults; <-- Adicionado Fim ACBrBoleto.pasACBrBoletoFCFR.pasACBrBoletoFCFortesFr.dfmACBrBoletoFCFortesFr.pasACBrBoletoFCFR.dfm Qualquer duvida manda mensagem ou erro, eu corrijo.

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. Assinado por: Secretaria da Fazenda do Rio Grande do Sul

Muito obrigado, pretendo fazer assinatura ao suporte pago, no entanto tinha essa duvida! Novamente muito obrigado!

Sim continuará funcinonando... não há nenhuma trava ou verificação no ACBrMonitorPLUS... Afinal, isso não faria sentido, em um projeto de código aberto...

Informe na propriedade "DataMulta" do título.

Vou verificar as implementações com relação aos dados do seguro e valor da carga. Se não me engano existem propriedades para ativar ou desativar algumas impressões do DAMDFe.

Olá a todos, tenho me deparado com a seguinte situacao: Erro de timeout 12002 direto, só que aqui a sefaz disse que nao quer aquele modo de gerar uma segunda nota e o cliente levar a que gerou em contingencia pois acontece demais e gera muita inutilizacao ou cancelamento e falaram que o cliente pode ser autuado, o que fazer nesse caso?, uma vez que o cliente precisa levar o danfe e vou ter que mudar pra offline a nota , porém a nota com erro de timeout pode ou não está autorizada na sefaz, e a que o cliente levou em offline a chave não é a mesma da que pode ter sido autorizada, como resolver isso?

Bom dia Leandro, Muito obrigado pela colaboração, ainda esta semana vamos analisar e estando tudo OK, vamos enviar para o repositório.

De acordo com os mesmos, deve-se usar o valor de 0,01.

ATUALIZAÇÃO: As informações abaixo podem ser desconsideradas. Veja o próximo post que mostra que o ACBr é compatível com o OpenSSL 1.1.x. Olá, Como sabemos, diversos componentes do ACBr utilizam a lib OpenSSL para comunicação segura. No Linux utilizamos exclusivamente a lib OpenSSL, até o momento o ACBr é compatível apenas com versões 1.0.v da OpenSSL mas algumas distros do Linux instalam por padrão, a versão 1.1.v, neste caso é necessário baixar e instar a versão anterior para funcionar com o ACBr... Segue abaixo o procedimento para atualização: 1- Para saber qual versão OpenSSl está instalada no Linux, utilize o comando: # openssl version Se estiver utilizando a versão 1_1_v, precisará baixar e instalar a versão 1_0_v. 2- No nosso exemplo estamos utilizamos a distro OpenSuse Leap 15.1, que por padrão é instalada com a versão 1_1_v da OpenSSL. Utilizando a ferramenta de Instalação de Pacotes YaST do OpenSuse, selecionamos a opção: "Software" e "Gerenciamento de Software". Pesquisamos por: "OpenSSL" - Selecione para instalar a versão OpenSSL-1_0_0 que esta disponível no seu repositório (Note que é a versão 1.0.2p), será informado que precisa desinstalar algumas dependências da versão atual. Selecione a primeira opção e dê OK. - Selecione para instalar também a LibOpenSSL-1_0_0. (caso essa dependência não seja adicionada automaticamente no passo anterior). Click em Aceitar para Baixar e Instalar... 3- Confira os pacotes da versão OpenSSL 1_0_0 que precisam estar instalados: obs: Caso esteja obtendo o erro abaixo na tentativa de comunicação com a SEFAZ, significa que está faltando alguma dependência da OpenSSL-1_0_0 para ser instalada, basta instalar todas as dependências conforme está no passo 3.

Qual SEFAZ UF não permite a segunda nota? Para gerar uma nota em contingência deve-se usar a próxima numeração justamente pelo fato de que a primeira nota pode ter ficado em Lote em Processamento e ser autorizada pelo SEFAZ. Como o cliente levou a nota em contingência, em tese, essa é a nota válida. Sendo assim, quando essa nota em contingência for autorizada, a nota anterior enviada em modo normal deve ser cancelada. Se o cliente está de posse da nfc-e com chave incorreta, acredito que deverá ser enviado a ele o xml da nota correta, mas isso é complicado em se tratando de consumidor final.

Você está informando valores zerados para essas tags: Total.ICMSTot.vPIS := 0; Total.ICMSTot.vCOFINS := 0;

Bom dia, essa implementação precisará ser testada com calma para não quebrar outras parametrizações já existentes na impressão dos itens dos produtos.

Bom dia; O acressimo tem que ser rateado entro os itens, o valor deve ser colocado [vOutro] do item.

@José M. S. Junior Boa tarde, já baixei a nova LibBoleto, e vi que foram feitas as alterações, testei e ficou show obrigado a equipe.....

Na verdade fico faltando passar o parâmetro mesmo. Correção já disponível no SVN.

Resolvido Itálo, muito obrigado. Era apenas que o ISSNET pede o cabeçalho de XML <?xml version=\"1.0\" encoding=\"UTF-8\"?> Com isso funcionou de primeira !! uma coisa ridícula, mas são esses detalhes que fazem a diferença. Obrigado novamente !! Gde Abraço, Roberto

Obrigado, vamos validar e retornamos.

Bom dia Jair, O ambiente de homologação do provedor Infisc não funciona, em vez de retornar o resultado do envio, retorna o WSDL do webservice, por outro lado o ambiente de produção retorna o resultado do envio. Para esse provedor a única solução é enviar a nota para o ambiente de produção e depois cancelar pois trata-se de um teste.

Bom dia, Muito obrigado pela colaboração, fiz mais algumas alterações e enviei para o repositório. Nos meus testes também recebo a mensagem de erro acusando erro na assinatura. Favor atualizar todos os fontes de todas as pastas, reinstale a suíte ACBr. Note que fiz uma alteração no arquivo INI do provedor. Favor entrar em contato com o provedor e solicitar um arquivo XML de envio para que possamos comparar e dessa forma tentar descobrir onde esta o erro.

Boa tarde, vamos analisar assim que possível. Obrigado!

Olá pessoal, Aproveitando os últimos minutos do segundo tempo, temos novidades para o inicio do ano que vem. Novidades da versão 1.40 da NT 2019/001 * Modifica a RV N12-94 para deixar mais específica a rejeição, criando assim a RV N12-98 com sua respectiva rejeição; A regra vai ser ativada a partir de 11/05/2020 10/08/2020 em produção, verificando a existência e a vigência do cBenef. Assim, a RV N12-94, a partir dessa data, passará a verificar apenas se o cBenef é compatível com o CST. Essa nova regra permite que determinada UF possa validar apenas a existência do cBenef, caso não opte por validar a compatibilidade com o CST. A criação da RV N12-98 não traz impacto para os sistemas emissores que já estão preparados para a validação da RV N12-94, salvo o possível tratamento da mensagem da rejeição. Rejeição 946: Informado código de beneficio fiscal incorreto ou inexistente na UF. * Adiciona as exceções e modelos para as RV N12-85, N12-86, N12-90, N12-94, N12-97 e N12-98; Criação de Exceções para as Regras de Validação N12-85 (Se informado CST e não informado código de benefício fiscal), N12-86 (Se informado CST e informado código de benefício fiscal), N12-90 (Se CST de ICMS = (20, 30, 40, 41, 50, 70 ou 90)), N12-94 (Se informado CST e informado código de benefício fiscal), N12-97 (Não informados campos de valores do CST 51 (Diferimento)) e N12-98 (Se informado código de benefício fiscal) Trata-se de exceções que já haviam sido criadas e implementadas, tendo sido comunicadas por meio de aviso disponibilizado no Portal Nacional da NF-e. As Rejeições das Regras de Validação N12-85, N12-86, N12-90, N12-94 e N12-97 encontram-se no artigo referente a NT2019/001 versão 1.30 * Informa as Exceções e Datas aplicáveis as UF que ativaram as RV N12-85, N12-86, N12-90, N12-94 e N12-97; e que ativarão a N12-98; Quadro com datas de ativação das RV, respectivas exceções e possíveis modelos para UF que ativaram/estão ativando tais RV. Quadro já disponibilizado no Portal da NF-e. A única diferença é a indicação das opções de modelos (55; 65; ou 55/65). Tal quadro demonstra quais UF estão ativando as RV, bem como as exceções aplicadas e os modelos que de DF-e (55 e 65) em que se aplicam a tais RV. A tabela a seguir substitui a do item anterior (1.8), pois adiciona exceções e modelo aplicável. Na tabela a seguir encontram-se as Unidades da Federação que implementarão as Regras de Validação N12-85, N12-86, N12-90, N12-94, N12-97 e N12-98, previstas nesta Nota Técnica. Na legenda são encontradas as datas de aplicação, as exceções e os modelos aplicáveis (55/65), a critério da UF. Regra de validação - Aplicação e Exceções +----------------------------------------------------------------------------------------------------------+ | UF | N12-85 | N12-86 | N12-90 | N12-94 | N12-97 | N12-98 | +----------------------------------------------------------------------------------------------------------+ | PR | (D1), (55/65) | (D1), (55/65) | (D*) | (D2), (55/65) | (D1), (55/65) | (D3), (55/65) | +----------------------------------------------------------------------------------------------------------+ | RJ | (D2), (55/65) | (D2), (55/65) | (D2), (55/65) | (D2), (55/65) | (D2), (55/65) | (D3), (55/65) | | | (E2, E3) | (E2, E3) | (E2, E3) | (E2, E3) | (E2, E3) | (E2, E3) | +----------------------------------------------------------------------------------------------------------+ | RS | (D2), (55/65) | (D2), (55/65) | (D*) | (D*) | (D*) | (D3), (55/65) | | | (E3,E4) |(E3,E4) | | | | (E3,E4) | +----------------------------------------------------------------------------------------------------------+ |Demais UF | (D*) |(D*) | (D*) | (D*) | (D*) | (D*) | +----------------------------------------------------------------------------------------------------------+ Datas para aplicação das Regras de validação (D), com respectivo Modelo de DF-e: (D*) - Regra de validação não será aplicada; (D1) - Aplicação a partir de 02/09/2019; (D2) - Aplicação a partir de 01/10/2019; (D3) - Aplicação a partir de 11/05/2020 10/08/2020 em Produção (Homologação: 16/03/2020) Aplicação aos Modelos de DF-e: (55); (65); ou (55/65) Exceções constantes nas Regras de Validação, a critério da UF: (E1) - Exceção 1: a RV não se aplica quando Finalidade de emissão da NF-e (tag: finNFe) igual a Devolução de Mercadoria e Identificador de local de destino da operação (tag: idDest) igual a Operação interestadual ou com o Exterior. (E2) - Exceção 2: a RV não se aplica quando Finalidade de emissão da NF-e (tag: finNFe) igual a Devolução de Mercadoria; (E3) - Exceção 3: a RV não se aplica quando Finalidade de emissão da NF-e (tag: finNFe) igual a NF-e de ajuste; (E4) - Exceção 4: a RV não se aplica quando Tipo de Operação (tag: tpNF) igual a Entrada. Observação: A Exceção 1, constante nas respectivas Regras de Validação, aplica-se a todas as UF. Assim, não necessita estar no quadro acima. As datas aqui definidas, juntamente com todas as demais informações a respeito das regras de validação opcionais por UF, podem ser consultadas em tabela publicada no Portal Nacional da NFC-e, na área “Regras de Validação” da aba “Desenvolvedor”. Para contribuintes estabelecidos no Estado do Rio Grande do Sul, as Regras de Validação N12-85 e N12-86 permitirão informar qualquer CST até 31/03/2020 no ambiente de autorização em produção, conforme tabela disponibilizada no Portal da NF-e. Em homologação, o contribuinte já pode testar a validação dessa Regras. A RV N12-94 será desativada para o Rio Grande do Sul a partir da publicação desta NT.  A RV N12-98 será ativada conforme as datas de homologação e produção previstas nesta NT. * Retira o modelo 65 da validação da RV B03-10 Datas de efetivação das modificações: Ambiente de Homologação: 16/03/2020 Ambiente de Produção: 11/05/2020 (10/08/2020) Como se tratam de regras de validação nos WebServices das SEFAZ-Autorizadoras, não se faz necessário nenhuma alteração nos fontes dos componentes e nem na aplicação. Para baixar a NT na integra favor acessar a nossa biblioteca.

Olá pessoal, Foi publicado agora em dezembro/2019 um novo manual de especificação técnica do DANFE da NFC-e, trata-se da versão 5.1 desse manual. O que temos de novidade: 1. algumas correções que deixa mais claro o que pode e o que não pode ser impresso. 2. traz nessas correções as novas tags cMsg e xMsg que poderão estar presentes juntamente com as demais informações referente ao protocolo de autorização gerado pela SEFAZ-Autorizadora e o local correto da sua impressão. 3. apresenta o local correto de imprimir os valores de vFrete, vSeg, vDesc e vOutro que a critério da UF poderão estar discriminados por Itens. A versão 5.1 do Manual de Especificações Técnicas do DANFE da NFC-e se encontra em nossa biblioteca. Convido a todos a lerem. Observação: Os componentes para impressão do DANFE da NFC-e feitos em Fortes Report e EscPos já estão em conformidade com a versão 5.1 do manual, portanto procurem manter os fontes sempre atualizados.

Olá pessoal, Introduzi no componente ACBrPosPrinter, um novo mecanismo de acesso a Impressora Agora poderemos acessar algumas impressoras, usando a Sintaxe: ACBrPosPrinter1.Porta := 'DLL:MARCA'; Onde MARCA, será o nome da Marca do Fabricante da Impressora... Até o momento, temos suporte para as marcas "ELGIN", e "EPSON" A ideia por traz dessa nova sintaxe de Porta, é permitir usar a DLL/SO do Fabricante, para Imprimir diretamente na Impressora... Ok.. o ACBrPosPrinter, já conseguia acessar impressoras Não Fiscais, pela Porta USB, usando a Sintaxe "RAW:" ACBrPosPrinter1.Porta := 'RAW:Nome da Impressora no Windows'; Mas então porque desenvolvemos essa nova forma de acesso ? A nova sintaxe "DLL:", tem algumas vantagens, em relação a sintaxe "RAW:" Não depende da instalação do Driver de Spool da Impressora.. (note porém, que em alguns casos, o Driver de Spool não pode estar instalado, pois ele bloqueia o acesso a USB) Podemos Ler Informações da Impressora (o que não é possível no modo RAW) Entretanto, como foi dito antes, dependemos de DLL exclusiva do fabricante, para o acesso a Impressora pela USB... Quais são essas DLLs ? Para onde eu devo copiá-las ? Vejamos como foi descrito no ACBrSerial-change-Log.txt Creio que isso responde as duas perguntas, correto ? Você pode encontrar as DLLs no nosso SVN, na pasta: \ACBr\DLLs\PosPrinter, ou ainda pela Web: http://svn.code.sf.net/p/acbr/code/trunk2/DLLs/PosPrinter/ Você pode ainda baixar uma versão do Demo PosPrinterTeste, atualizada, compilado em Lazarus/FPC no link abaixo: Como funciona essa nova técnica ? Quem faz todo acesso as Portas suportadas pelo ACBr, é um subcomponente chamado ACBrDevice, e há um bom tempo, esse componente já possui uma possibilidade de Integração por Hooks O que é Hook ? https://pt.wikipedia.org/wiki/Hooking A ideia por trás dos Hooks, é instalar ganchos, em eventos, que nos permitam interceptar algumas ações e chamadas... Veja esse trecho de código FDevice.HookAtivar := PosPrinterHookAtivar; FDevice.HookDesativar := PosPrinterHookDesativar; FDevice.HookEnviaString := PosPrinterHookEnviaString; FDevice.HookLeString := PosPrinterHookLeString; Aqui instruímos o subcomponente ACBrDevice, a chamar nossos eventos, quando ele precisar "Ativar", "Desativar" uma porta e também quando ele for "EnviarString" e "LeString", de uma determinada porta... Então no interior do componente ACBrPosPrinter, implementamos os eventos indicados acima (PosPrinterHookAtivar, PosPrinterHookDesativar, etc) ... Com isso, o ACBrDevice executará um código nosso, ao invés do que ele normalmente executaria... Veja que dentro dos eventos de ativação e desativação usamos uma Classe de Hook (leia mais abaixo) procedure TACBrPosPrinter.PosPrinterHookAtivar(const APort: String; Params: String); begin if Assigned(FHook) then FHook.Open(APort); end; procedure TACBrPosPrinter.PosPrinterHookDesativar(const APort: String); begin if Assigned(FHook) then FHook.Close; end; FHook por sua vez, é uma variável interna ao ACBrPosPrinter, que contem uma Classe de Hook (TACBrPosPrinterHook), e implementa os comandos necessários, para transmitir essas ações, a DLL do fabricante... Veja o exemplo abaixo, como fica a implementação dos Hooks de Ativar e Desativar, da ELGIN... observe que chamamos métodos Externos, da DLL da Elgin, como: "PrtPortOpenW" e "PrtPortClose" procedure TElginUSBPrinter.Open(const APort: String); var errorNo: Integer; begin if Connected then Exit; inherited Open(APort); try errorNo := xPrtPortOpenW(FPrinter, WideString(fpPort)); // <------- A Q U I ------- if (errorNo <> E_SUCCESS) then raise Exception.CreateFmt(CERROR_OPEN, [fpPort, fpPrinterName]); except fpConnected := False; fpPort := ''; raise; end; end; procedure TElginUSBPrinter.Close; var errorNo: Integer; begin if not Connected then Exit; errorNo := xPrtPortClose(FPrinter); // <------- A Q U I ------- if (errorNo <> E_SUCCESS) then raise Exception.CreateFmt(CERROR_CLOSE, [fpPort, fpPrinterName]); inherited Close; end; Com isso, conseguimos usar a DLL do Fabricante, para estabelecer um túnel entre o ACBrPosPrinter e o equipamento... Como posso implementar um Hook para um novo modelo ? Os Primeiros passos, são verificar: Se o Fabricante disponibiliza uma DLL para acesso direto ao equipamento (sem depender do Spooler) Se há nessa DLL, um método que nos permita Escrever e Ler Dados da Porta USB Ou seja, não precisamos de métodos de alto nível, que façam a formatação de caracteres, ou manipulem a impressora... Pois continua sendo o ACBrPosPrinter, quem montará toda a Sintaxe de comandos a serem enviados para a Impressora, usando a linguagem Esc/Pos... e igualmente, será o ACBrPosPrinter que fará a leitura de respostas, quando for necessário... Na DLL da Elgin, temos um ótimo exemplo de método para isso... function PrtDirectIO(printer:Pointer; // Ponteiro com a Impressora instanciada por PrtPrinterCreatorW writeData:PByte; // Buffer com dados a serem enviados writeNum:integer; // Número de Bytes em "writeData" (tamanho do Buffer) readData:PByte; // Ponteiro com o Retorno a ser Lido (Buffer de saída) readNum:integer; // Numero de bytes disponíveis para escrita em "readData" (tamanho disponível no Buffer de Saída) preadedNum:PInteger // Número de bytes realmente escritos em "readData" ): Integer; cdecl; // Status de retorno E_SUCCESS = 0; Tendo isso em mãos, podemos criar uma cópia de uma das Units já existentes, como por exemplo a Unit ACBrEscPosHookElginDLL.pas, e implementar o suporte usando a nova DLL, e efetuar os ajustes referente a nova Marca

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

Boa tarde, Estou tentando consultar o retorno do processamento de um lote enviado ao eSocial e está retornando o erro: Método enviar não implementado em TDFeSSLHttpClass Este erro está ocorrendo na linha 1149 do ACBrDFeSSL : Result := FSSLHttpClass.Enviar(ConteudoXML, AURL, ASoapAction, AMimeType); e a função que está sendo chamada está na linha 821 do ACBrDFeSSL: function TDFeSSLHttpClass.Enviar(const ConteudoXML: String; const AURL: String; const ASoapAction: String; AMimeType: String): String; begin {$IFDEF FPC} Result := ''; {$ENDIF} raise EACBrDFeException.Create('Método "Enviar" não implementado em: '+ClassName); end; Alguém pode me orientar nesse erro ? Grato Pedro

Ok, setando o ssllib, funcionou. Muito obrigado. Pedro

Essa configuração você encontra em ACBreSocial1.Configuracoes.Geral.SSLHttpLib mas você pode setar o ssl lib que já configura automaticamente para você. ACBreSocial1.Configuracoes.Geral.SSLLib := libWinCrypt;

Exatamente... observe que você não deveria checar apenas o codigoDeRetorno... o correto seria também checar se a resposta do SAT tem o mesmo número de sessão da requisição... e é exatamente isso que o ACBrSAT1.ValidarNumeroSessaoResposta:=True; irá fazer... Então você não precisará mais se preocupar com o retorno do SAT Quando o SAT estiver indisponível, você já pegará o problema em: ACBrSAT1.ConsultarStatusOperacional; dessa forma você dificilmente terá problema de indisponibilidade no SAT ao enviar o comando de Venda... Qualquer retorno diferente de 6000, é erro na Venda... considere que o XML foi recusado... pois o você já testou a disponibilidade do SAT com a chamada de ACBrSAT1.ConsultarStatusOperacional

O modo de informação do vale pedágio mudou na versão 3.00. Na versão 1.00 você faria: with ACBrMDFe1.Manifestos.Add.MDFe do with rodo.valePed.disp.Add do begin // dados do vale pedagio end; Já na 3.00 você deve fazer assim: with ACBrMDFe1.Manifestos.Add.MDFe do with rodo.infANTT.valePed.disp.Add do begin // dados do vale pedagio end;