Ir para conteúdo
  • Cadastre-se

Painel de líderes

Conteúdo popular

Showing content with the highest reputation since 07-12-2012 em todas as áreas

  1. Olá pessoal, Com o intuito de acabar com a dependência da CAPICOM, nos fontes do Projeto ACBr, apliquei um amplo refactoring, nas Units de ACBrDFeSSL e suas derivadas... O que é CAPICOM ? https://en.wikipedia.org/wiki/CAPICOM Porque usávamos a CAPICOM ? Usar diretamente as APIs do Windows não é uma tarefa simples.... A CAPICOM, facilita um pouco, as tarefas que podem ser feitas com a WinCrypt (ou MS Crypto), para acesso a certificados digitais instalados no Windows Quais as desvantagens da CAPICOM ? A Microsoft condenou a mesma como obsoleta. (esse é o principal motivo) Ela precisa ser registrada no Windows para funcionar Não suporta 64 bits O que será usado no lugar da CAPICOM ? Usaremos diretamente as APIs do Windows, ou seja, a WinCrypt (também conhecida como "MS Crypto" ou "CAPI"). Ou seja, encaramos o desafio e agora usamos apenas métodos da WinCrypt para acessos a Certificados Digitais no Windows. Para facilitar o acesso a API WinCrypt, estamos usando as Units do diretório: "Fontes\Terceiros\CodeGear\", mas especificamente a Unit "ACBr_WinCrypt.pas". Quais as vantagens da WinCrypt ? Ela está presente de forma nativa, em todas as versões do Windows (desde o Windows XP), ou seja, não requer instalação. Possui versões 32 e 64 bits Não requer registro da DLL Não requer a instalação de pacotes .NET ou Java Onde posso encontrar a WinCrypt ? Ela já está instalada, de forma nativa, no seu Windows... com o nome: "crypt32.dll" Se o seu Windows é 64 bits, você encontrará a mesma em: 32 bits: "C:\Windows\SysWOW64" 64 bits "C:\Windows\System32" Se o seu Windows é 32 bits, você encontrará a mesma em: "C:\Windows\System32" O suporte a Delphi7 será mantido ? SIM. Apesar de já anunciarmos o fim do Suporte a D7, tivemos o cuidado de testar as alterações no D7. Para isso, adaptamos as units da pasta "Fontes\Terceiros\CodeGear\" para o suporte a D7... Como configurar para usar a WinCrypt e não a CAPICOM ? A maneira mais simples é configurar a seguinte propriedade: ACBrNFe1.Configuracoes.Geral.SSLLib := libWinCrypt; Na verdade, a propriedade ACBrDFe.Configuracoes.Geral.SSLLib passou a ser virtual... ou seja, ela configurará de forma indireta, as 3 novas bibliotecas de TDFeSSL... Se você ler os fontes, quando rodamos o código acima, o seguinte código será executado. procedure TGeralConf.SetSSLLib(AValue: TSSLLib); case AValue of ..... libWinCrypt: begin SSLCryptLib := cryWinCrypt; SSLHttpLib := httpWinHttp; SSLXmlSignLib := xsMsXml; end; end; Se você deseja uma configuração diferenciada, poderá configurar as bibliotecas individualmente...Exemplo: ACBrNFe1.Configuracoes.Geral.SSLCryptLib := cryWinCrypt; ACBrNFe1.Configuracoes.Geral.SSLHttpLib := httpWinINet; ACBrNFe1.Configuracoes.Geral.SSLXmlSignLib := xsXmlSec; Como remover completamente, as Units da CAPICOM dos meus fontes ? Abra o arquivo \ACBr\Fontes\ACBrComum\ACBr.inc e altere a seguinte linha: {.$DEFINE DFE_SEM_CAPICOM} para: {$DEFINE DFE_SEM_CAPICOM} Ou seja, remova o "." do inicio O que mudou em ACBrDFeSSL ? Muita coisa.... (veja abaixo o trecho do "Change-Log").. Estudar os fontes do projeto Demo "\ACBr\Exemplos\ACBrDFe\ACBrNFe\Delphi", é a melhor maneira de conhecer as modificações. Veja abaixo, um resumo ilustrado: 1 - Agora você pode criar a sua própria janela de escolha de Certificado Veja esse exemplo de código, extraído de ACBrNFe_Demo. onde usamos o método "ACBrNFe1.SSL.LerCertificadosStore", para carregar todos os certificados da Store, definida em "ACBrNFe1.SSL.StoreName", após isso, as informações dos certificados podem ser obtidas em "ACBrNFe1.SSL.ListaCertificados" ACBrNFe1.SSL.LerCertificadosStore; For I := 0 to ACBrNFe1.SSL.ListaCertificados.Count-1 do begin with ACBrNFe1.SSL.ListaCertificados[I] do begin 2 - Agora você pode selecionar as bibliotecas de TDFeSSL, individualmente CryptLib: Permite definir qual será a biblioteca de Criptografia. Ela possui métodos como:"SelecionarCertificado", "CarregarCertificado", "CalcHash". além de propriedades como "DadosCertificado" e "ListaCertificados". TSSLCryptLib = (cryNone, cryOpenSSL, cryCapicom, cryWinCrypt) HttpLib: Usada para acesso HTTP e HTTPs, permitindo informar o Certificado na conexão. Possui métodos como: "Enviar" e propriedades como: "HTTPResultCode" e "InternalErrorCode" TSSLHttpLib = (httpNone, httpWinINet, httpWinHttp, httpOpenSSL, httpIndy); XMLSignLib: Usada para validar XMLs (contra um Schema), assinar um XML, Validar a assinatura existente em um XML. Possui métodos como: "Assinar", "Validar" e "VerificarAssinatura" TSSLXmlSignLib = (xsNone, xsXmlSec, xsMsXml, xsMsXmlCapicom); 3 - Independência das configurações de segurança do I.E. Isso pode ser obtido, se você utilizar SSLHttpLib = "httpWinHttp" ou "httpOpenSSL" Você poderá definir nos seus fontes, independente das configurações do Internet Explorer, configurações como o Tipo de segurança e TimeOut da tentativa de conexão. Essa funcionalidade já estava presente nas Units de acesso que utilizavam o OpenSSL a algum tempo. e agora com a nova Unit que faz acesso a HTTPS, usando a API do Windows chamada "WinHTTP", isso também será possível. O modelo: "httpWinINet" irá usar a API do Windows, chamada "WinINet", a qual já utilizávamos, e ela depende de configurações do I.E. 4 - Carregar o certificado por ArquivoPFX ou DadosPFX, com a WinCrypt ou CAPICOM Essa funcionalidade já estava presente, quando SSLCryptLib = cryOpenSSL. e não estava disponível para CAPICOM. Mas agora isso é possível, com a SSLCryptLib = cryCapicom ou cryWinCrypt. Ou seja, Se você tem um certificado A1, você não precisa instalar o certificado no Windows. Isso pode parecer pouco importante em uma primeira impressão... Mas veja as possibilidades: O certificado A1 poderia estar em um Banco de dados, ou em um Servidor Web, e ser carregado de forma dinâmica pela sua aplicação, independente de ser instalado manualmente no Windows. 5 - Compilar seu Executável em 64 bits Lembre-se que quando você compila o seu programa em 64 bits, todas as DLLs externas de qual ele necessitar, também devem ser de 64 bits. Portanto para isso, você não poderá usar a XMLSignLib = xsMsXml, pois a biblioteca da Microsoft para assinatura de XMLs "MSXML" não possui versão 64 bits. Mas observe que agora você pode usar a biblioteca WinCrypt com a XmlSec, basta configurar corretamente as bibliotecas de criptografia. Nota: Ainda não conseguimos, fazer com que a XMLSec possa usar certificados A3, mas isso deverá ser possível no futuro, pois a XMLSec tem suporte a "MSCrypto" Diagrama de Classes Como posso ajudar ? (Tarefas a serem efetuadas) 1 - Fazer a XmlSec funcionar usando a "mscrypto" Ainda não conseguimos fazer a XMLSec, usar a MSCrypto, atualmente ele apenas usa a "openssl". Porque isso é importante ? Temos vários problemas, com a msxml, como por exemplo: A Microsoft não distribui a mesma, de forma nativa, com o Windows (arquivo msxml5.dll) Ela não suporta 64 bits A licença de uso dassa biblioteca, é valida apenas para quem tem o Office instalado... Portanto, seria ótimo se pudéssemos ficar livres da MSXML, mas para isso, precisamos fazer o ACBr conseguir usar a XMLSec com suporte a MSCrypto (hoje ele só suporta OpenSSL)... Na verdade, já podemos usar WinCrypt + XmlSec, mas apenas para certificados A1, pois o ACBr é capaz de exportar o certificado A1 do Windows, para que o mesmo seja usado pelo OpenSSL. (ele fará isso internamente, e de forma transparente para o usuário) Quando conseguirmos fazer a XmlSec usar a MSCrypto (ou WinCrypt), conseguiremos compilar a aplicação em 64 bits, e com suporte a certificados A3 2 - Compilar os fontes da XMLSec no Windows, em 32 e 64 bits Hoje o único site que distribui a XMLSec já compilada para Windows é https://www.zlatkovic.com/libxml.en.html (Thanks Igor). Entretanto, podemos notar que os binários estão defasados, e não há uma versão 64 bits, com suporte a "mscrypto" Veja como ficou o "Change-Log" do refactoring em ACBrDFeSSL -- ACBrDFeSSL -- [*] Amplo refactoring promovido, separando a classe "TDFeSSLClass" em 3 novas classes: "TDFeSSLCryptClass" - para Carregar certificados e efetuar criptografia "TDFeSSLHttpClass" - para comunicação HTTP/HTTPS com suporte a Certificados "TDFeSSLXmlSignClass" - Para Validar XMLs, validar assinaturas e Assinar XML com Certificados [+] "TSSLLib", adicionado os tipos "libWinCrypt, libCustom" [+] Criada nova classe "TDadosCertificado", para conter os dados do certificado carregado [+] Criada nova classe "TListaCertificados",para conter uma lista de Objetos do tipo TDadosCertificado, com todos os certificados de uma "Store", e após a chamada do método "TDFeSSL.LerCertificadosStore" [+] Adicionada propriedade "TDFeSSL.StoreName: String", usada apenas no Windows. Nome da Store a ser aberta, padrão "MY" [+] Adicionada propriedade "TDFeSSL.StoreLocation: TSSLStoreLocation", usada apenas no Windows. Default "slCurrentUser". TSSLStoreLocation = (slMemory, slLocalMachine, slCurrentUser, slActiveDirectory, slSmartCard); [+] Adicionado o método: "TDFeSSL.LerCertificadosStore", apenas Windows, para carregar todos os Certifcados de "TDFeSSL.StoreName" para a lista de Objetos: "TDFeSSL.ListaCertificados" [+] Adicionado a propriedade "TDFeSSL.DadosCertificado", para permitir acesso aos dados do certificado carregado [+] Adicionada a propriedade "TDFeSSL.SSLCryptLib: TSSLCryptLib" default cryNone; para definir a classe de criptografia TSSLCryptLib = (cryNone, cryOpenSSL, cryCapicom, cryWinCrypt); [+] Adicionada a propriedade "TDFeSSL.SSLHttpLib: TSSLHttpLib" default httpNone; para definir a classe de comunicação HTTP/HTTPS TSSLHttpLib = (httpNone, httpWinINet, httpWinHttp, httpOpenSSL, httpIndy); [+] Adicionada a propriedade "TDFeSSL.SSLXmlSignLib: TSSLXmlSignLib" default xsNone; para definir a classe de assinatura de validação de XML TSSLXmlSignLib = (xsNone, xsXmlSec, xsMsXml, xsMsXmlCapicom); [+] Adicionada a propriedades "TDFeSSL"SSLType: TSSLType" default LT_all; para permitir definir o tipo de criptografia em HTTPS sendo: TSSLType = (LT_all, LT_SSLv2, LT_SSLv3, LT_TLSv1, LT_TLSv1_1, LT_TLSv1_2, LT_SSHv2) suportado apenas em TDFeHttpOpenSSL e TDFeHttpWinHttp -- ACBrDFeConfiguracoes -- [+] Adicionada as propriedades: property SSLCryptLib: TSSLCryptLib property SSLHttpLib: TSSLHttpLib property SSLXmlSignLib: TSSLXmlSignLib [*] Propriedade "SSLLib: TSSLLib" passou a ser virtual, e mantida por compatibilidade. Ajusta-la irá produzir ajustes em "SSLCryptLib", "SSLHttpLib" e "SSLXmlSignLib". Exemplo: if SSLLib = libOpenSSL then begin SSLCryptLib := cryOpenSSL; SSLHttpLib := httpOpenSSL; SSLXmlSignLib := xsXmlSec; end; -- ACBrDFe -- [+] Adicionado suporte a configurações de "SSLCryptLib", "SSLHttpLib", "SSLXmlSignLib" -- ACBrDFeOpenSSL -- [*] Amplo refactoring. Removido código referente a comunicação HTTP/HTTPs que foi migrado para "ACBrDFeHttpOpenSSL" [*] Removido código referente a assinatura digital e Validação de XML, que foi migrado para "ACBrDFeXsXmlSec" -- ACBRDFeWinCrypt -- [+] Nova Unit, para manipular Certificados do Windows e efetuar assinatura digital, usando a Win API WinCrypt (MSCrypto/CAPI) -- ACBrDFeCapicom -- [*] Refactoring, para usar boa parte do código de "ACBRDFeWinCrypt" -- ACBrDFeHttpOpenSSL -- [+] Adicionada nova Unit, derivada de ACBrDFeOpenSSL, criando implementação da classe de TDFeSSLHttpClass para comunicação http e https, usando a Synapse e OpenSSL -- ACBrDFeHttpWinApi -- [+] Adicionada nova Unit, derivada de ACBrDFeCapicom, criando implementação da classe de TDFeSSLHttpClass para comunicação http e https, usando as APIs do Windows WinHttp ou WinINet -- ACBrDFeHttpIndy, ACBrDFeCapicomDelphiSoap -- [*] Unit renomeada de "ACBrDFeCapicomDelphiSoap" para "ACBrDFeHttpIndy", e refatorada para não depender da CAPICOM -- ACBrDFeXsXmlSec -- [+] Adicionada nova Unit, derivada de ACBrDFeOpenSSL, criando implementação da classe de TDFeSSLXmlSignClass usando a Lib XMLSEC -- ACBrDFeXsMsXml -- [+] Adicionada nova Unit, derivada de ACBrDFeCapicom, criando implementação da classe de TDFeSSLXmlSignClass usando a Lib MSXML -- ACBrDFeXsMsXmlCapicom -- [+] Adicionada nova Unit, derivada de ACBrDFeCapicom, criando implementação da classe de TDFeSSLXmlSignMsXml usando a Lib MSXML e CAPICOM -- ACBrDFeException -- [+] Adicionado o exception "EACBrDFeExceptionNoPrivateKey" -- ACBrDFeUtil -- [+] Adicionado o método "SignatureElement: String" (por DSA) Obrigado... e considere nos ajudar, contratando o SAC, por pelo menos 1 mês http://www.projetoacbr.com.br/forum/sacv2/sobre/ http://www.projetoacbr.com.br/forum/sacv2/questoes_importantes/ http://www.projetoacbr.com.br/forum/sacv2/cadastro/ Fique atento.... Em breve, organizaremos um Webinar sobre essas modificações
    93 pontos
  2. Olá pessoal, Quem atualizou os fontes e reinstalou a Suite ACBr, pode ser que esteja recebendo essa mensagem de erro no momento que vai gerar a NF-e / CT-e / MDF-e / BP-e. Porque esta mensagem esta aparecendo para alguns e para outros não? Simples, quando o XML é gerado com base em alguns dados do documento fiscal é gerado a chave do mesmo. Essa mensagem de erro é devido a uma validação que foi implementada na função que gera a chave. Essa validação visa garantir que a sua Nota (por exemplo) não seja rejeitada pela regra de validação B03-10 que consta na Nota Técnica 2019/001. Como vocês podem ver na imagem acima, a aplicação dessa regra é obrigatória, ou seja, todas as SEFAZ-Autorizadoras devem implementar essa regra. Ela será implementada no dia 01/07/2019 no ambiente de Homologação e no dia 02/09/2019 no ambiente de Produção. A validação que foi implementada ao gerar a chave é exatamente a descrita na regra, ou seja, o valor de cNF não pode ser igual a nNF e a nenhum dos números listados na regra. Por curiosidade resolvi pegar o Manual da NF-e mais antigo que tenho (Março de 2009) veja o que esta escrito na definição do campo cNF: O Manual deixa claro que o numero atribuído a cNF tem que ser um numero aleatório. Portanto quem costuma atribuir a cNF o mesmo numero atribuído a nNF esta fazendo errado e agora não vai ter perdão, pois se insistir a SEFAZ não vai aceitar a nota. Mas a regra B03-10 da Nota Técnica 2019/001 não se refere apenas a NF-e / NFC-e? Sim, mas tenham certeza que essa regra de validação em breve vai ser implementada para os demais DF-e - Documentos Fiscais Eletrônicos. Alguém duvida disso? O que devo fazer para que a minha aplicação não pare com a mensagem de erro: Código Numérico inválido, Chave não Gerada ? Muito simples, vou dar como exemplo o fragmento de código da minha aplicação: Como é hoje, note que eu já gerava o código como sendo um numero aleatório: NotaFiscalVenda := (DM_VEN.NotasDocumento.AsInteger + 1); CodigoChave := Random(99999999) + 1; // +1 para garantir que não seja zero Como vai passar a ser, para ter uma garantia maior ainda: NotaFiscalVenda : =(DM_VEN.NotasDocumento.AsInteger + 1); CodigoChave := GerarCodigoDFe(NotaFiscalVenda); A função GerarCodigoDFe esta definida na Unit ACBrDFeUtil, logo você vai ter informar essa Unit em Uses do seu Form. Note que ela recebe como parâmetro o numero da nota, pois a função vai gerar o código aleatoriamente e vai validar o mesmo e pela regra o código não pode ser igual ao numero da nota. De forma semelhante você terão que fazer o mesmo nas suas aplicações que emitem CT-e, MDF-e e BP-e. É preferível fazer essa correção na aplicação agora do que receber dezenas ou até centenas de ligações de clientes que não estão conseguindo autorizar os seus documentos na SEFAZ. Fica ai a dica.
    50 pontos
  3. Boa tarde a todos, Já esta disponível em nossa biblioteca a Nota Técnica 2019/001 que trata sobre novas regras de validação. Resumo da NT: · Dificultar utilização de código de segurança fraco · Melhorar o controle de documentos referenciados e da identificação do destinatário · Descrever benefícios fiscais e informações da tributação do ICMS com mais precisão · Criação de valor máximo para a base de cálculo do ICMS, por unidade federada · Melhor gerenciamento de informações sobre o destinatário, tanto no serviço de autorização de NF-e quanto no serviço de registro de EPEC Datas previstas para entrada em vigor: 01/07/2019 - Ambiente de Homologação; 02/09/2019 - Ambiente de Produção. Alterações no componente: Nenhuma, visto que essa NT trata de novas regras de validação a serem implementadas pelas SEFAZ-Autorizadoras. Novas Regras de Validação: Criada a Regra de Validação B03-10, para dificultar a utilização de um código de segurança fraco, ou seja, o valor de cNF não vai poder ser igual ao valor de nNF e sim um numero aleatório. Criadas regras de validação a documentos referenciados:  Regra de Validação BA10-40 foi alterada, possibilitando a utilização do CNPJ 8 (somente os 8 primeiros dígitos) com o objetivo de identificar que a nota foi emitida pelo mesmo contribuinte, a critério da unidade federada. Criada a Regra de Validação BA10-50, exigindo que uma contranota de produtor rural somente possa referenciar uma nota emitida por outro produtor rural, a critério da unidade federada. Criada a Regra de Validação BA20-20, impedindo que seja referenciado um documento fiscal de uso exclusivo para operações internas em uma operação destinada a outra unidade federada ou para o exterior. Criada a Regra de Validação BA20-30, impedindo referência a um Cupom Fiscal, a critério da unidade federada. Criadas regras de identificação do destinatário: Criada a Regra de Validação E03a-30, impedindo o uso simultâneo de IE e de identificação de estrangeiro para o destinatário. Criada a Regra de Validação E14-30, impedindo informação de país de destino “Brasil” em operações destinadas ao estrangeiro. Criada a Regra de Validação E16a-40, exigindo a indicação de “operação com consumidor final” quando se indica que a operação é destinada a não contribuinte. Criadas regras de validação tornando obrigatória a informação do Motivo da Desoneração e do Valor do ICMS desonerado, caso seja informado o Código do Benefício Fiscal: Criada a Regra de Validação I05f-10, impedindo a informação de um código de benefício fiscal juntamente com um CST que não prevê benefício fiscal, a critério da unidade federada. Criada a Regra de Validação I05f-20, impedindo a informação de um código de benefício fiscal que não corresponda ao CST utilizado, a critério da unidade federada. Criada a Regra de Validação I05f-30, exigindo que seja informado o valor do ICMS desonerado ou o motivo de desoneração quando se utiliza um código de benefício fiscal, a critério da unidade federada. Criada a Regra de Validação N07-10, exigindo informações sobre o diferimento quando se utiliza um CST de diferimento, a critério da unidade federada. Criada a Regra de Validação N12-84, exigindo o código de benefício fiscal quando se utiliza um CST de benefício fiscal, a critério da unidade federada. Criada a Regra de Validação N12-88, exigindo que o CST corresponda ao tipo de código de benefício fiscal informado, a critério da unidade federada. Criada a Regra de Validação N12-90, exigindo valor do ICMS desonerado e o motivo da desoneração, a critério da unidade federada. Criada a Regra de Validação N18-10, exigindo a informação do percentual da margem de valor Adicionado do ICMS ST Informada caso a modalidade de determinação da BC da ST seja MVA, a critério da unidade federada. Criada a Regra de Validação N18-20, não permitindo informação do percentual da margem de valor Adicionado do ICMS ST Informada caso a modalidade de determinação da BC da ST não for MVA, a critério da unidade federada. Criada a Regra de Validação W03-20, impedindo a informação de um valor de Base de Cálculo superior ao valor máximo estabelecido pela respectiva SEFAZ. Emitente: Criada a Regra de Validação 1C03-10, impedindo a informação de Razão Social do emitente diferente da existente no cadastro da SEFAZ. Destinatário: Criadas as Regras de Validação 5E17-10, 5E17-20, 5E1730, 5E17-40, 5E17-43, 5E17-46, 5E17-50, 5E17-60, 5E17-63, 5E17-70 e 5E17-80, para verificar se o destinatário está sendo informado corretamente ou se está em situação que o impeça de constar na NF-e como destinatário na operação com mercadoria ou prestação de serviços.  Serviço Autorização EPEC: Criadas as Regras de Validação 6P31-10, 6P31-20, 6P31-30, 6P31-40, 6P31-43, 6P31-46, 6P31-50, 6P31-60 e 6P31-63, para verificar se o destinatário está sendo informado corretamente ou se está em situação que o impeça de constar na NF-e como destinatário na operação com mercadoria ou prestação de serviços.
    42 pontos
  4. Olá Estamos disponibilizando na última versão do componente ACBrBoleto a funcionalidades de integração via WebService (Registro On-Line de Boletos), esta funcionalidade já estava disponível nos fontes da pasta Branches (para testes) e passamos para a pasta Trunk2 para que seja possível a homologação por mais usuários do Projeto ACBr. Lembrando que não são todos os bancos que disponibilizam este tipo de serviço via WebService, sendo que os bancos listados abaixo já foram implementados no projetos até o momento, sendo necessário a homologação e testes por empresas que realmente possuam cadastro com o Banco para este tipo de serviço... Pois sem um pré-cadastro para esse serviço não é possível realizar todos os testes em homologação. A estrutura do WebService no componente ACBrBoleto foi implementada nos moldes dos componente ACBrDFe, sendo assim, mesmo NÃO existindo um padrão entre os Bancos, será possível implementar todos utilizando essa estrutura como base. Se alguém desejar contribuir com outros Bancos, poderá analisar os fontes e seguir o mesmo modelo, toda contribuição é bem-vinda!!! Cada Banco exige dados específicos para integração, sendo assim disponibilizamos junto ao Exemplo demonstração (DemoACBrBoleto) o arquivo “configWebService.txt” com as orientações de configuração para integração On-Line. BANCOS SUPORTADOS POR WEBSERVICE / API: Banco do Brasil Caixa Econômica Itaú Sicred CrediSis PenseBank Inter Bancoob (Sicoob) Santander Safra ATENÇÃO: Sistemas que utilizam classes de ENUMERADOS dependentes do Projeto ACBrBoleto precisam declarar em seus USES a classe “ACBrBoletoConversao”, pois todas foram migradas para esta Unit. Então se tiver erros de classe do ACBrBoleto não declaradas no seu projeto, basta declarar esta nova Unit… Veja onde ficam as novas configurações para Integração Online: CedenteWS: Configurações: Após configurar os dados de acordo com a recomendação de cada Banco, basta adicionar os Títulos e utilizar o botão: “Registrar Boleto On-Line”. No exemplo, também demonstra como capturar a lista com os retornos de cada Registro de Boleto. Uso com ACBrMonitorPlus Para quem utiliza o ACBrMonitor as configurações para integração WebService / API podem ser realizadas na seguinte tela: O métodos para envio é: https://acbr.sourceforge.io/ACBrMonitor/BOLETOEnviarBoleto.html Uso com ACBrLibBoleto Para quem utiliza a lib ACBrLibBoleto.dll as configurações para integração WebService / API podem ser verificadas na documentação, seção [WebService]: https://acbr.sourceforge.io/ACBrLib/ConfiguracoesdaBiblioteca18.html O métodos para envio é: https://acbr.sourceforge.io/ACBrLib/Boleto_EnviarBoleto.html Qualquer dúvida ou contribuições que venham a surgir no processo de homologação favor criar um novo tópico na seção referente a Boleto. https://www.projetoacbr.com.br/forum/forum/8-acbrboleto/?do=add
    41 pontos
  5. Depois de muita conversa interna e requisição de uma parte dos usuários ACBr, resolvemos estender o suporte ao Delphi 7 até Janeiro de 2017. Por que? Nossa principal motivação foi porque muita gente está pensando que quando chegasse o fim de agosto a compatibilidade com o Delphi 7 será simplesmente removida e seus aplicativos vão parar de funcionar. Infelizmente, algumas pessoas estão usando isso com um oportunismo, fazendo "terrorismo" nos usuários do projeto ACBr. Queremos que entendam que não é fácil manter a compatibilidade do projeto em tantas versões diferentes. E não estamos recebendo muita ajuda nessa área. É difícil manter compatibilidade com versões UNICODE quando nós mesmos não usamos. Mas então em janeiro meu aplicativo Delphi 7 deixará de funcionar com o ACBr? Não!!!! Seu aplicativo vai continuar funcionando. Isso é mentira, falácia, balela, uma grande prosopopéia para acalentar bovinos (conversa pra boi dormir). Então o ACBr não vai mais enviar alterações e correções de acordo com a legislação? Claro que vamos continuar enviando alterações e correções. Então não entendi... Pois é... Isso é o que a gente está tentando esclarecer... Deixa eu tentar... Como é o processo atualmente: Sempre que antes de enviar uma correção, alteração ou inclusão de nova característica, precisamos avaliar se vai funcionar no Delphi 7. Mas a maioria de nós não utiliza mais o Delphi 7. Então depois fazemos a correção, testamos na versão que utilizamos. Daí precisamos, por exemplo disparar uma máquina virtual, esperar ela carregar, copiar o novo código para a VM, fazer os testes no Delphi 7, voltar a máquina normal e só depois enviar ao SVN. Como queremos que seja o processo após janeiro de 2017: Fazemos a correção que precisamos, testamos nas versões que suportamos, e enviamos ao SVN. Mas e o Delphi 7? Os componentes até essa data vão continuar funcionando no seu Delphi 7. Mas a partir dessa data você deverá ter cautela para atualizar via SVN. Eventualmente, sem intenção, uma quebra de compatibilidade pode acontecer. Neste caso você sempre terá a opção de voltar para uma revisão que esteja funcionando. Mas se preferir poderá fazer algo: Corrigir você mesmo o problema; Encontrar algum voluntário para corrigir; Atualizar para uma IDE suportada; Quais as IDE suportadas? Lazarus ou Delphi 2009 ou posterior.
    40 pontos
  6. É com prazer que anunciamos que o Dia do ACBr já tem data para acontecer. Em virtude das eleições que deverão ocorrer em outubro, sendo o primeiro turno no dia 07/10 e o segundo no dia 28/10, foi decidido que nosso encontro passará a ocorrer no dia 10/11/2018, desta forma todos poderão realizar seu voto e participar de nosso evento. O Dia do ACBr será realizado nas dependências do Parque Tecnológico de Sorocaba (PTS) situado na cidade de Sorocaba-SP, o qual conta com um amplo e moderno espaço. Vocês não podem perder, reserve esta data na sua agenda. O Evento Contaremos com palestras e workshops com diversos assuntos relacionados aos componentes ACBr, Object Pascal(Delphi/Lazarus), além do ACBrMonitorPlus e nossa novidade, a ACBrLib, entre outros temas relacionados ao nosso universo. Abaixo estão relacionados os palestrantes já confirmados: Daniel S. de Almeida (Fundador do Projeto ACBr) Italo Jurisato Jr (Responsável pelos componentes ACBrNFSe, ACBrBPe, ACBrCTe e ACBrMDFe) Rafael Teno Dias (Responsável pelo ACBrFramework e ACBr libs) José M. S. Junior (Responsável pelo ACBrBoleto e atual mantenedor do ACBrMonitorPlus) Juliomar Marchetti (MVP Embarcadero) Régys Borges da Silveira (MVP Embarcadero) Marcos Douglas B. Santos, responsável pelo blog Object Pascal Programming. Um momento que deverá ser bastante interessante é o Pergunte ao Desenvolvedor, no qual os participantes terão a oportunidade de realizar perguntas diretamente a vários moderadores do projeto ACBr. Além da oportunidade de um dia focado no universo ACBr, será uma grande oportunidade para conhecer os principais mantenedores do projeto, além de ampliar ainda mais seu Networking e conhecer casos de sucesso com o projeto ACBr. Sugestões de Palestras e Palestrantes Os usuários do fórum podem se candidatar para realizar palestras ou sugerir temas que gostariam que fossem abordados durante o evento, assim como indicação de palestrantes. Para se candidatar a palestras você deverá: Enviar resumo do assunto da palestra Descrever a relevância do tema proposto para a comunidade Opcionalmente enviar vídeo e outros materiais sobre o tema proposto Breve Currículo pessoal Para sugerir um tema/palestrante você deverá: Descrever a relevância do tema para a comunidade. Indicar o palestrante que gostaria que realizasse a palestra* (opcional). *Nota: As sugestões de palestrantes não garantem que os mesmos estarão palestrando no evento, somente sinaliza a equipe de organização o interesse da comunidade em ouvir o mesmo. Fique atento, em breve lançaremos nossa página para inscrições e noticias do Dia do ACBr.
    37 pontos
  7. 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
    32 pontos
  8. Para evitarmos diversos tópicos sobre o mesmo assunto, as alterações relativas a versão 4.00 da NFe/NFCe deverão ser concentradas neste tópico. Os fontes do componente já foram atualizados para permitir gerar os XMLs para essa nova versão. Também já foram ajustados para não gerar o SOAP Header quando configurado para a versão 4.0(ve400). Assim que os schemas e webservices forem disponibilizados pelo SEFAZ, iniciaremos os testes com o componente. Mais informações sobre as mudanças podem ser obtidas na NT 2016.002 - http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=c4S6yXTKpXY= Apenas como informação, neste manual fiquei com dúvida em dois campos: descANP - Campo numérico com tamanho de 2 - 95? O campo tem a seguinte descrição: Descrição do produto conforme ANP, então provavelmente deve ser do tipo carácter e não numérico. O campo vBCFCPSTRet possui o mesmo ID de outro campo na versão 3.10 - N27a - V3.10 vICMSDeson / V4.00 vBCFCPSTRet
    31 pontos
  9. Olá Pessoal, É com grande alegria e satisfação que a Equipe ACBr depois de quase 1 ano de trabalho comunica que já se encontra disponível para todos o novo componente para emissão de NFS-e. Por conta de varias melhorias e quebra de código optamos por manter o componente atual e disponibilizar o novo com um outro nome: ACBrNFSeX e também um novo componente para impressão do DANFSE: ACBrNFSeXDANFSERL (Fortes Report). Já esta disponível no repositório Trunk2 os fontes dos componentes bem como os pacotes de instalação (para o Delphi e Lazarus) e o programa exemplo para o Delphi). Em breve vai estar disponível o DANFSE feito em Fast Report, programa exemplo para o Lazarus e a atualização do ACBrInstall com a opção de instalação do novo componente. Estamos também elaborando um manual de migração que terá como objetivo ajudar os desenvolvedores que utilizam o componente atual a migrar para o novo. Esse manual vai apresentar as propriedades de configuração bem como os campos que não existem mais ou que tiveram seus nomes alterados e varias outras informações valiosas. Acreditamos que com o manual e o programa exemplo do novo componente qualquer desenvolvedor vai ser capaz de migrar a sua aplicação para o novo componente em uma semana, digo isso pois sempre aconselhamos que todos estudem o programa exemplo. O que esperar do novo componente: 1. Código mais limpo, removemos a maioria dos IF e CASE que antes eram utilizados para sanar a falta de padronização entre os provedores; 2. Um único método de emissão de NFS-e, que detecta automaticamente o modo de envio correto para cada provedor; 3. Leitura dos retornos padronizado; 4. Mais veloz; 5. Eliminação dos arquivos INI de provedores e o Cidades.ini, simplificando bastante os arquivos a serem distribuídos juntamente com o executável. 6. A implementação de novos provedores que seguem a versão 1 ou 2 do layout da ABRASF tendo todas as informações necessárias se faz em menos de 1 hora. O que vem pela frente: 1. Inclusão da NFS-e no ACBrMonitor Plus, desta forma os desenvolvedores que se utilizam dessa ferramenta em fim vão poder emitir também a NFS-e. 2. Desenvolvimento da ACBrLibNFSe, uma DLL para os desenvolvedores que preferem usar a DLL em vez do ACBrMonitor. Noticia: Nós achamos que o Projeto ACBr tem os melhores componentes disponíveis pelo melhor preço: grátis. Se você concorda, por favor espalhe essa noticia.
    30 pontos
  10. Olá pessoal, Acabei de enviar para o SVN, modificações para que o ACBrDFe e ACBrDFeOpenSSL suportem comunicação segura usando TLS 1.2 O componente ACBrNFe, já irá tentar ajustar a comunicação para TLS 1.2, se detectar que a versão é superior a 3.1 Atualizando o OpenSSL Para usar TLS 1.2, é necessário ter a versão do OpenSSL superior a 1.0.1, normalmente a versão usada é a 0.9.8.14, e portanto ela precisa ser substituída. Se você tentar utilizar uma versão inferior, o ACBrDFeOpenSSL acusará o seguinte erro: Porém não basta apenas baixar e copiar uma nova versão das DLLs do OpenSSL (libeay32.dll e ssleay32.dll). O problema, é que a libxmlsec, que se encontra na pasta: "ACBr\DLLs\XMLSec", não é compatível com OpenSSL superior a 0.9.8... e se você simplesmente atualizar as Libs do OpenSSL no seu sistema, provavelmente o ACBrNFe, passará a acusar Exceptions no momento de assinar o XML A solução, é utilizar um novo conjunto de DLLs, da OpenSSL e libXmlSec, libXML, e demais... você pode achar essas DLLs em: ftp://ftp.zlatkovic.com/libxml/ Essas DLLs foram compiladas com "MinGW", e portanto elas precisarão das DLLs de RunTime, da MinGW. Para sua conveniência, copiamos todas as DLLs necessárias para a pasta: \ACBr\\DLLs\XMLSec\MinGW. Observe que temos a versão 32 e 64 bits dessas DLLs... quais eu devo usar ? Em resumo, use 32 se o seu Compilador é 32 bits, e 64 apenas se você estiver usando um Compilador que gere .EXE em 64 bits... Leia esse tópico, para compreender melhor: Copie TODAS as DLLs (e não somente algumas) da pasta "\ACBr\DLLs\XMLSec\MinGW\32" ou "\ACBr\trunk2\DLLs\XMLSec\MinGW\64" (conforme o seu compilador), para o seu diretório de DLLs... (se não tem certeza para onde você deve copiar as DLLS, leia com atenção o Post indicado anteriormente) Outro problema, é que a MinGW, gera as DLLs com uma nomenclatura ligeiramente diferente do VisualC, exemplo: libxmlsec1.dll com MinGW, e "libxmlsec.dll" com VisualC. Portanto, o ACBr teria dificuldades em encontrar essas DLLs e carrega-las de forma dinâmica. Precisamos portanto, informar ao ACBr, que usaremos o conjunto de DLLs no formato da MinGW... Isso é feito, editando o arquivo: ACBr.inc. Repare que lá no final do ACBr.inc, temos a seguinte linha: {.$DEFINE USE_MINGW} Apenas remova o ".", alterando para: {$DEFINE USE_MINGW} Pronto... com isso você estará pronto para usar o ACBr com OpenSSL e TLS 1.2, seja em 32 ou 64 bits... Obrigado... e considere nos ajudar, contratando o SAC ocasionalmente: http://www.projetoacbr.com.br/forum/sacv2/sobre/ http://www.projetoacbr.com.br/forum/sacv2/questoes_importantes/ http://www.projetoacbr.com.br/forum/sacv2/cadastro/
    30 pontos
  11. Saudações Digitais comunidade ACBr! Com total entusiasmo que anunciamos que o componente ACBrOFX está integrado a suíte de componentes e ao instalador do ACBr. Mais um componente para agregar valor para toda a comunidade da automação comercial do Brasil. Agradecemos a contribuição dos membros: Tiago Passarella, [email protected], Leonardo Gregianin. Finalidade do componente? Auxiliar a conciliação bancária, que é um modo de controle administrativo e contábil em uso nas empresas, dos seus saldos bancários em dinheiro mantidos em contas correntes de instituições financeiras ou bancos. O que é arquivo OFX? Open Financial Exchange (OFX ) é arquivo texto em um formato de fluxo de dados para troca de informações financeiras que evoluiu dos formatos de arquivo Open Financial Connectivity (OFC) da Microsoft e Open Exchange, o que pode ser traduzido como Intercâmbio Financeiro Aberto e Conectividade Financeira Aberta. Mas se este tipo de arquivo é utilizado por bancos, o que você, que gerencia uma empresa, tem a ver com isso? A questão é que com esse tipo de documento que se torna possível exportar o extrato bancário, acessados pelo internet banking. Ou seja, quando você obtém essas informações importantíssimas para o seu negócio, de maneira digital, é por meio do arquivo OFX. Em outras palavras, esse formato de documento é um grande aliado do controle financeiro do seu negócio. Propriedades Significados BankID Banco BranchID Agência AccountID Conta AccountType Tipo de Conta BankName Nome do Banco DateStart Data de Inicio DateEnd Data de Fim FinalBalance Balanço Final
    29 pontos
  12. Olá pessoal, Para quem ainda não sabe estou promovendo um Refactoring no componente ACBrNFSe. Ele praticamente foi reescrito do zero e infelizmente teremos algumas quebras de código quando ele for liberado. Mas vamos falar de coisas boas. Hoje temos que disponibilizar para os nossos clientes além do executável, DLLs, os famosos arquivos INI, o arquivo Cidades.ini e os arquivos INI dos provedores. Pois bem, isso acabou. Os arquivos INI referente aos provedores se transformaram em Unit, ou seja, fazem parte do fonte do componente. O conteúdo do arquivo Cidades.ini migrou para o arquivo ACBrNFSeServicos.ini que é transformando no ACBrNFSeServicos.res através do BAT: Compila_RES. O arquivo ACBrNFSeServicos.res é incorporado ao executável, logo vocês só vão precisar distribuir o executável e as DLLs para os seus clientes. O que vocês acharam dessa mudança? Ainda não esta 100%, em função das diferenças dos provedores, mas criei um novo método chamado Emitir que tem por finalidade gerar o XML do RPS, assinar se necessário, gerar o Lote e assinar se necessário, enviar, aguardar o retorno do XML da NFSe. Independente do serviço que o provedor se utiliza para recepcionar o XML do RPS. Vou dar um exemplo: O provedor 4R que segue a versão 2 do layout da ABRASF implementou somente o método EnviarLoteRpsSincrono para recepcionar o RPS, sendo que no Manual da ABRASF versão 2 estão previstos os métodos: EnviarLoteRps, EnviarLoteRpsSincrono e GerarNfse. Por outro lado o provedor ISSJoinville que também segue a versão 2 do layout da ABRASF implementou somente o método EnviarLoteRps. Se vocês tem clientes cujas cidades utilizam o provedor 4R e tem clientes em Joinville, ou vocês tem duas aplicações ou a aplicação tem uma tela de configuração para definir qual método a ser utilizado. O método Emitir vem para tentar resolver esse problema da seguinte forma: se o provedor for 4R ele vai se utilizar do método EnviarLoteRpsSincrono automaticamente, agora se for ISSJoinville vai usar o EnviarLoteRps. Desta forma não precisamos de nos preocuparmos com qual o método devemos usar para enviar o RPS para o webservice. Acredito que vai ficar muito bom e pratico. O que vocês acham? Muita coisa já foi feita e muito mais precisa ser feito. Para que vocês tenham uma ideia foi criado 32 Units, ou seja, uma para cada provedor que segue a versão 1 do layout da ABRASF, mais 53 Units para os provedores que seguem a versão 2 do layout da ABRASF e mais 19 Units para os provedores que tem o seu próprio layout. Até o final deste mês de outubro estarei disponibilizando o programa exemplo compilado para que vocês possam fazer mais testes. Em breve vou explicar como vão ser os testes e como reportar os resultados. Antes que eu esqueça, esse Refactoring visa poder incluir a emissão da NFS-e no ACBrMonitor Plus e a criação do ACBrLibNFSe (DLL). Um forte abraço a todos.
    28 pontos
  13. Olá pessoal, Como muitos devem saber, os fontes do Projeto ACBr, são hospedados no SourceForge, um gigantesco portal que hospeda vários Projetos de Código aberto mundialmente... Ficamos muito contente em receber um comunicado do Source Forge, que nos confere as insígnias abaixo... Esta é uma grande conquista, pois nosso projeto se qualificou para esses prêmios entre mais de 500.000 projetos de código aberto, existentes no SourceForge. O SourceForge recebe cerca de 30 milhões de usuários por mês procurando e desenvolvendo software de código aberto. Community Leader Community Choice Open Source Excellence SourceForge Favorite
    27 pontos
  14. Ajustamos os fontes do ACBr, para que eles fiquem compatíveis com o OpenSSL 3.x... Os ajustes já estão no SVN Como essas mudanças são feitas no núcleo de comunicação segura do ACBr, agradecemos a ajuda nos testes, e por favor reportem se notarem algo estranho, mesmo no uso de versões mais antigas, como o OpenSSL 1.1.1 O que é o OpenSSL ? O OpenSSL é uma famosa biblioteca usada para comunicação segura e criptografia... no ACBr, usamos ela para vários de nossos componentes que usam HTTPS, como por exemplo, o ACBrPIXCD... Página do OpenSSL https://www.openssl.org/ Você pode encontrar as DLLs do OpenSSL, em nosso SVN: http://svn.code.sf.net/p/acbr/code/trunk2/DLLs/OpenSSL/ Porque fizemos essa mudança ? Recentemente o OpenSSL passou por um processo de refatoração, o que gerou a série 3.x... e as versões anteriores, estão sendo descontinuadas, e deixarão de receber correções de segurança e novas melhorias Suporte a protocolos mais Seguros, como TLS 1.3 Em ambientes Linux, o OpenSSL 3.x já é instalado por padrão, e é difícil fazer o downgrade, para a versão 1.1.x O que muda nos meus fontes ? Esperamos que nenhuma modificação seja necessária nos seus fontes. Nossa implementação é compatível com OpenSSL 0.9.x a 3.x, ou seja, os fontes do ACBr, tentam detectar a DLL mais nova do OpenSSL de forma automática.... Geralmente a biblioteca será procurada primeiro, na mesma pasta da Aplicação ou no Path do Sistema Operacional, dando sempre preferência as DLLs das versões mais novas... Ou seja, ele primeiro procurará pela DLL da versão 3.x, e depois da versão 1.1.x, 1.0.x, 0.9.x e assim por diante Como posso saber, qual DLL do OpenSSL o ACBr carregou ? Use as linhas abaixo, para ver a Versão e o Path completo, das DLLs carregadas na memória mResp.Lines.Add('Versão OpenSSL'); mResp.Lines.Add( OpenSSLExt.OpenSSLVersion(0) ); mResp.Lines.Add( ACBrOpenSSLUtils.OpenSSLFullVersion ); mResp.Lines.Add( OpenSSLExt.SSLUtilFile ); mResp.Lines.Add( OpenSSLExt.SSLLibFile ); mResp.Lines.Add('------------------------------'); Como atualizo a DLL para a versão 3.x ? Basta copiar as novas DLLs, para a mesma pasta do seu .exe... Se você compila seu sistema em 32 bits, aqui estão as DLLs: http://svn.code.sf.net/p/acbr/code/trunk2/DLLs/OpenSSL/3.1.3/x86/ Nota: mesmo que o Windows seja 64 bits, a DLL precisa acompanhar a arquitetura em que seu .EXE é compilado Eu preciso atualizar ? Não necessariamente, mas recomendamos que você use no mínimo a versão 1.1.x, por motivos de segurança Não creio que a atualização, gere mais performance, no uso da biblioteca...
    26 pontos
  15. Olá Pessoal, O método Consultar agora possui um novo parâmetro chamado: AExtrairEventos. function Consultar(const AChave: String = ''; AExtrairEventos: Boolean = False) ; Boolean; Para quem utiliza os métodos direto da classe WebServices, deve acrescentar a seguinte linha: (...).WebServices.Consulta.ExtrairEventos := True ou False; O que ocorre quando o campo ExtrairEventos possui o valor True? Simples, quando realizamos um consulta a um DF-e além de retornar a sua situação é retornado também alguns eventos vinculados a ele, como por exemplo o evento de cancelamento. Se o valor de ExtrairEventos for True o método Consultar vai se encarregar de verificar se no retorno contem eventos, caso afirmativo eles serão extraídos e salvos em disco nas pastas conforme o seu tipo. Por exemplo, se no retorno tivermos o evento de cancelamento, será salvo na pasta: ...\Evento\Cancelamento o arquivo *-procEventoNFe.xml (caso estejamos consultando uma NF-e). Essa nova funcionalidade esta disponível nos componentes: ACBrBPe, ACBrCTe, ACBrMDFe, ACBrNF3e e ACBrNFe. Em breve tanto o ACBrMonitor quanto o ACBrLib vão passar a ter também essa funcionalidade. O que eu ganho com essa nova funcionalidade no método Consultar. Vamos supor que o seu cliente venha perder o XML da nota por exemplo, neste caso basta você ler os dados da nota do banco de dados, gerar e assinar o XML e por fim realizar uma consulta com o XML carregado, desta forma ao realizar a consulta a SEFAZ vai retornar o protocolo de autorização e o componente se encarrega de atualizar o XML acrescentando o protocolo nele, deixando-o assim um documento com validade jurídica. Mas se o seu cliente perder o XML de um evento como por exemplo o de cancelamento, não tinha como refazer o mesmo, pois não temos um método para consultar eventos, aliais a SEFAZ não possui um serviço para esse fim. Como dito acima o Consultar além de retornar a situação do documento e retorna também alguns eventos. Antes o componente ignorava esse conteúdo, mas agora foi implementado a extração dos eventos. Resumindo caso o seu cliente venha perder o XML de um evento (*-procEventoNFe.xml), lembre-se que o método Consultar pode recuperar ele novamente, desde que esse tipo de evento que foi perdido é retornado pelo Consultar. Espero que tenham gostado dessa nova funcionalidade.
    26 pontos
  16. Terça, 07/05/2019 Se você está atento as notícias que enviamos periodicamente em nossos Boletins e publicamos aqui nessa área de Notícias do Fórum, já deve ter se preparado e atualizado seus sistemas... mas se ainda não o fez, por favor leia esse artigo, para evitar a parada da emissão de NFe/NFCe em seus clientes finais. Nas versões 1.00 a 1.10 da NT 2018.005, ficou estabelecido que no dia 07/05/2019 entrarão em vigor a exigência de novas validações relativas a NFe/NFCe. (Você pode achar todas as NTs na Biblioteca de nosso SVN) Porém, essas novas regras foram publicas com alguns complicadores, que podem ocasionar a paralisação da emissão de NFe/NFCe. Algumas Tags, somente podem ser enviadas em Produção, a partir do 07/05/19, porém são obrigatórias a partir dessa data. Hora, isso complica tudo.... Ou seja, se enviarmos a Tag em Produção antes de 07/05, o documento será rejeitado, mas se deixarmos de enviar a Tag após 07/05, o documento igualmente será rejeitado... Então, em outras palavras, o ENCAT espera que você aplique uma parametrização ou faça rollout, em TODOS os seus clientes finais, de um dia para outro!!! Afinal, não é uma boa prática de programação, inserir uma constante Hardcoded, como uma Data (07/05/19), na compilação do sistema final. Sem falar no fato de que não é incomum, algumas UFs não aplicarem a exigência na mesma Data publicada... O ENCAT agiu corretamente quando definiu a exigência das novas Tags, em homologação, em uma data anterior... Isso é ótimo, pois dá tempo para as Sw.Houses se ajustarem e testarem as modificações. Porém, o ENCAT poderia definir que as novas Tags são opcionais em Produção, até a data efetiva da exigência (07/05), quando então, passariam a ser obrigatórias... Isso daria tempo necessário, para as Sw.Houses aplicarem a atualização dos sistemas nos clientes finais, a fim de garantir que a emissão de documentos em produção já esteja funcionando Algumas Tags são exigidas ou não a critério da unidade Federativa Afinal o projeto NFe é ou não nacional ? É extremamente complicado para uma Sw.House saber o que pensa cada UF individualmente... A título de exemplo, a equipe do Projeto ACBr, efetuou uma pesquisa para saber se UFs exigiriam o Grupo de Responsável Técnico e se elas iriam ou não criar um portal para cadastro e identificação das Sw.Houses (idCSRT). Consultamos TODAS as SEFAZ, usando os canais (nem sempre) disponíveis, para submeter uma consulta... O resultado pode ser conferido em nosso Mapa Fiscal mas reparem em quantas UFs não conseguimos obter uma resposta clara... Conforme pode ser acompanhado ao longos das últimas versões da NT 2018.005, a exigência do Grupo Responsável Técnico sofreu diversas alterações, culminando na prorrogação indefinida para as informações relativas IDCSRT, e para as demais informações somente as UFs de AM, MS, PE, PR, SC e TO exigirão em 03/06, as demais UFs ou optaram por não exigir ou também deixaram para data futura.* Se para cada Grupo ou Tag novo, o ENCAT continuar adicionando o famigerado texto "A critério da UF", isso é receita para o CAOS na NFe... Um projeto que até então é o orgulho dos SEFAZ, e exemplo para o mundo todo, pode se perder em um emaranhado confuso de condições, que muitas vezes não são claras... Como eu posso me prevenir ? É necessário manter os fontes do Projeto ACBr atualizados em sua máquina, e permitir que a sua aplicação tenha flexibilidade de configuração da parametrização. Ou seja, permitir que o seu Suporte Técnico possa parametrizar de maneira rápida, a geração (ou não) de novas Tags, conforme o exigido pela UF do usuário final... Já pensou por exemplo, em "descer"para o PC do cliente final, uma parametrização da "nuvem"? Mas a final, quais são as modificações ? Ok.. vamos falar um pouco sobre cada uma delas... Grupo Responsável Técnico Este grupo teve algumas prorrogações ao longo das últimas versões da NT 2018.005, porém as UFs do AM, MS, PE, PR, SC e TO optaram por manter em 03/06/19* a exigência das informações deste grupo (exceto os dados relativos ao idCSRT). Para mais detalhes sobre o assunto acesse em nossa base de conhecimento, o tópico dedicado ao assunto escrito por nosso consultor @Italo Jurisato Junior Veja também, o nosso já citado, Mapa Fiscal ICMS Substituto Estas tags vem trazendo uma série de complicações aos desenvolvedores, desde que passou a ser aplicada já em ambiente de homologação. Com a entrada em produção, será necessário a atualização dos clientes, seja com uma nova versão das aplicações ou de forma mais simples, a parametrização para gerar as tags conforme a UF do mesmo. No tópico a seguir, o consultor @EMBarbosa dá orientações valiosas para minimizar o impacto em seus clientes. Identificação do Local de Retirada e Entrega Para mais detalhes sobre o assunto acesse em nossa base de conhecimento, o tópico dedicado ao assunto, escrito por nosso consultor @Italo Jurisato Junior Ainda não acabou... dia 20/05/19 tem mais mudanças... Fique atento as mudanças previstas para o dia 20/05, que podem impactar na autorização de NFCe... O ENCAT modificou a URL de consulta do QRCode, de praticamente todos os estados, e essas novas URL já são exigidas em homologação e deverão ser obrigatórios em Produção a partir de 20/05 Leia mais sobre esse assunto, no tópico abaixo, criado pela consultora @Juliana Tamizou. *Importante: Somente a exigência do Responsável Técnico será em 03/06/19, todos os demais itens permanecem em 07/05/19, por isso não deixe de se preparar
    25 pontos
  17. Porque a minha aplicação, quando compilada no Trunk2 exige as DLLs do XMLSec ? O Trunk2, tem a habilidade de suportar OpenSSL (XMLSec) e CAPICOM, na mesma aplicação... e no ACBrNFe, existe a Classe TDFeSSL, que permite configurar qual será a biblioteca de SSL em Design ou Run-time Para isso, basta mudar a configuração usando comandos como abaixo: ACBrNFe1.Configuracoes.Geral.SSLLib := libOpenSSL; ACBrNFe1.Configuracoes.Geral.SSLLib := libCapicom; ACBrNFe1.Configuracoes.Geral.SSLLib := libCapicomDelphiSoap; // Mesmo que "libCapicom", mas usando a Indy Porém, para efetuar essa "magica", precisamos compilar todas as Units que dão suporte a CAPICOM e OpenSSL\XMLSec, e elas injetam a dependência de DLLs externas Porque eu usaria o suporte a OpenSSL ? O OpenSSL é ótimo para certificados do tipo A1... pois você não precisa instalar o certificado no Windows... basta apontar o caminho do arquivo PFX e a Senha: ACBrNFe1.Configuracoes.Certificados.ArquivoPFX := edtCaminho.Text; ACBrNFe1.Configuracoes.Certificados.Senha := edtSenha.Text; Porque remover o suporte a uma das bibliotecas de SSL ? A desvantagem, é que a sua aplicação agora ficou dependente de mais DLLs, e para alguns pode ser um problema, distribuir e instalar as mesmas Onde eu encontro as DLLs ? \ACBr\DLLs\OpenSSL \ACBr\DLLs\XMLSec Para onde eu copio essas DLLs ? Você deve copiar TODAS as DLLs das pastas acima indicadas (e não apenas algumas). Você pode copiar para a mesma pasta da sua aplicação .EXE ou para o "System" do Windows Observe que, essas DLLs são 32 bits, e portanto só funcionarão para aplicações compiladas com um compilador 32 bits (que é o padrão para Delphi e Lazarus)... Uma aplicação 32 bits roda em um S.O. 64 bits, mas o oposto não ocorre... Considerando que essa DLLs são 32 bits, então: Se o seu Windows for 32 bits, copie para a pasta: C:\Windows\System32 Se o seu Windows for 64 bits, copie para a pasta: C:\Windows\SysWOW64 Se você estiver instalando DLLs de 64 bits em um Windows 64 bits, então a pasta correta é: C:\Windows\System32 (vai entender... pergunte pra Microsoft) Como eu removo a dependência ? Nunca usou o OpenSSL ? Nunca deseja usar ? Então você pode remover o suporte do ACBr ao OpenSSL/XMLSec, e com isso, remover a dependência de sua aplicação das DLLs do XMLSec.. Edite o ACBr.inc... Observe que no inicio do mesmo, existem as linhas abaixo: {.$DEFINE DFE_SEM_OPENSSL} {.$DEFINE DFE_SEM_CAPICOM} Apenas remova o ".", se quiser ativar a remoção... {$DEFINE DFE_SEM_OPENSSL} Por que mesmo assim, a sua aplicação fica dependente das DLLs do OpenSSL (libeay32.dll, ssleay32.dll) ? O ACBr usa o OpenSSL para várias outras tarefas, como: criptografia e assinatura (ACBrEAD), comunicação segura (ACBrMail, ACBrHttp)... e outras... Então hoje, elas sempre serão necessárias... essa dependência já existia no "Trunk1"
    25 pontos
  18. 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
    24 pontos
  19. Desabafo do Menino Ney do TI "Configurar TLS, servidor fora, erro de schemas XML. Você pode achar que eu te acho exagerada, e, às vezes, você exagera mesmo. Mas a real é que eu sofro com essas suas Notas Técnicas e Manuais. Agora, na boa, você não imagina o que eu passo quando atendo o telefone às 22:00hrs só porque o caminhão tem q sair. Quando eu não faço as alterações de layout, não é porque eu sou preguiçoso, mas porque apenas não quero mexer no que está funcionando. Quando eu pareço nervoso, não é porque eu sou um moleque mimado. Mas é porque eu ainda não encontrei uma maneira de resolver os problemas que você vive criando. Dentro de mim ainda existe um menino do TI. Às vezes, ele encanta o mundo (consertando a impressora). E, às vezes, ele irrita todo mundo (quando esquece de atualizar os schemas). E minha luta é para manter esse menino do TI vivo. Mas dentro de mim, e não dentro do código. Você pode achar que o seu server SEFAZ não cai. Mas a verdade é que ele cai pra c****. Apenas está fora do ar, Direi ao usuário. Isso dói muito mais que bater o dedinho no pé da mesa. Eu demorei para corrigir as rejeições. Eu demorei para alterar o layout e adaptei o software para 4.0. Mas hoje eu tô aqui, de cara limpa, de peito aberto. Você caiu novamente. Mas foi eu que tive que explicar o porque ao usuário. Você pode continuar criando NTs. Ou pode parar de inventa-las e me ajudar a ter tempo para terminar o relatório do cliente. Porque quando compila, parça, o Brasil inteiro comemora comigo".
    24 pontos
  20. Veja abaixo notícia do Portal da NFe: Suspensão dos serviços "ConsNSU" e "ConsChNFe" da NT 2014.002 Devido ao excesso de utilização indevida do WebService de Distribuição de DF-e de Interesse dos Atores da NF-e (NFeDistribuicaoDFe), serão temporariamente suspensos os pedidos "ConsNSU - Consulta DF-e Vinculado ao NSU informado" (item "b" da seção 3.4.1 da NT 2014.002 versão 1.11) e "ConsChNFe – Consulta de NF-e por chave de Acesso Informada" (item "c" da seção 3.4.1 da NT 2014.002 versão 1.11). O pedido "distNSU – Distribuição de Conjunto de DF-e a partir do NSU informado" (item "a" da seção 3.4.1 da NT 2014.002 versão 1.11) continuará funcionando normalmente. Os pedidos suspensos serão reestabelecidos assim que regras de uso indevido forem implementadas, garantindo o funcionamento para todos os usuários. Assinado por: Receita Federal do Brasil Fonte: http://www.nfe.fazenda.gov.br/portal/informe.aspx?ehCTG=false&Informe=A6qvFRVbPSA= Observação: O componente ACBrNFe possui 3 métodos referente ao DistribuicaoDFe: DistribuicaoDFePorUltNSU - este continuará funcionando conforme noticia acima, pois ele se refere ao item "a" da seção 3.4.1 da NT 2014.002 versão 1.11 DistribuicaoDFePorNSU - este não vai funcionar conforme noticia acima, pois se refere ao item "b". DistribuicaoDFePorChaveNFe - este também não vai funcionar conforme noticia acima, pois se refere ao item "c". Relembrando: O método DistribuicaoDFePorUltNSU faz a pesquisa com base no ultimo NSU informado, devemos sempre usar como ultimo NSU o valor do campo ultNSU retornado na execução anterior do método. O método DistribuicaoDFePorNSU faz a pesquisa com base no NSU informado, devemos usar esse método somente quando detectarmos que um documento esta faltando. O método DistribuicaoDFePorChaveNFe faz a pesquisa com base na chave da nota informado, devemos usar esse método somente quando detectarmos que o documento referente a essa chave esta faltando. O DistribuicaoDFePorUltNSU retorna um lote de até 50 documentos já os outros 2 retorna somente um documento, logo não devemos utiliza-lo dentro de um loop.
    23 pontos
  21. Olá Pessoal, O componente ACBrNFe já esta pronto para atender as alterações previstas nas Notas Técnicas 2020/006 e 2020/007. O que mudou? Referente a NT 2020/006: Inclusão do campo <indIntermed> = Indicador de intermediador/marketplace os valores aceitos são: iiSemOperacao, iiOperacaoSemIntermediador, iiOperacaoComIntermediador. Usar o valor iiSemOperacao para a tag não ser gerada. O campo <tPag> = Meio de Pagamento passou a ter novos valores são eles: fpDepositoBancario, fpPagamentoInstantaneo, fpTransfBancario, fpProgramaFidelidade, fpRegimeEspecial. Inclusão do grupo <infIntermed> (atenção na NT consta como intTran) esse grupo só deve ser gerado nos casos de operação não presencial pela internet em site de terceiros (Intermediadores). O grupo contem os campos: <CNPJ> = CNPJ do Intermediador da Transação (agenciador, plataforma de delivery, marketplace e similar) de serviços e de negócios. e <idCadIntTran> = Identificador cadastro no Intermediador, devemos informar o Nome do usuário ou identificação do perfil do vendedor no site do intermediador (agenciador, plataforma de delivery, marketplace e similar) de serviços e de negócios. Esta previsto para o dia 01/02/2021 a liberação do ambiente de homologação e 05/04/2021 o ambiente de produção. Referente a NT 2020/007: Criação do Evento gerado pelo Emitente ou Destinatário informando o Transportador interessado pela NF-e. O texto abaixo foi extraído da NT: "No momento da emissão da NF-e, muitas vezes o emitente ainda não definiu o Transportador que ficará responsável pela entrega da mercadoria, impedindo, portanto, que essa informação conste em campo específico da NF-e (tag: CNPJ/CPF, id: X04/X05), ou mesmo no grupo de pessoas autorizadas a acessar o XML da NF-e (tag: autXML, Id: GA01). Em vários outros casos, o responsável pelo transporte é o destinatário e, nesses casos, o Emitente não tem condições de informar o Transportador no XML da NF-e. O objetivo desta Nota Técnica é permitir que o Emitente informe a identificação do Transportador a qualquer momento, como uma das pessoas autorizadas a acessar o XML da NF-e. No caso em que o transporte não é de responsabilidade do Emitente, o Destinatário poderá gerar o evento, com o mesmo objetivo de autorizar que o Transportador fique autorizado a acessar o XML da NF-e. Nos casos de Redespacho ou Subcontratação, definido o transportador contratado, este poderá também autorizar outro transportador participante da mesma operação de transporte a acessar o XML da NF-e. O Transportador precisa dos dados da NF-e para instrumentalizar seus processos de transporte e, a partir da geração deste evento, possibilita o transportador em buscar o XML da NF-e no Ambiente Nacional, por meio do “Web Service de Distribuição de DF-e de Interesse dos Atores da NF-e”, conforme documentado na NT2014.002." Para o envio desse novo tipo de evento temos: 1. tipo do evento = teAtorInteressadoNFe 2. campos novos: <cOrgaoAutor> = Código da UF do Autor do Evento, <tpAutor> = tipo de autor que pode ser: taEmpresaEmitente, taEmpresaDestinataria, taEmpresa, taFisco, taRFB, taOutros, <verAplic> = Versão do aplicativo do Autor do Evento, <CNPJ/CPF> da pessoa autorizada a acessar o XML da NF-e, e <tpAutorizacao> = tipo de autorização que pode ser: taNaoPermite, taPermite (0 – Não permite; 1 – Permite o transportador autorizado pelo emitente ou destinatário autorizar outros transportadores para ter acesso ao download da NF-e). Esta previsto para o dia 01/02/2021 a liberação do ambiente de homologação e 05/04/2021 o ambiente de produção. As duas Notas Técnicas estão disponíveis em nossa biblioteca: Quando o componente vai ser liberado com as alterações? Ultima semana de janeiro ou seja após o dia 25/01/2021, uma vez que só vai ser possível testar após o dia 01/02/2021. Vou ter que fazer alterações na minha aplicação? Tudo vai depender de quem são os seus clientes.
    23 pontos
  22. Boa tarde, Conforme pôde ser observado por um grande número de membros da comunidade, desde os últimos dias de abril vinha ocorrendo na maioria das UFs a rejeição Endereço do site da UF de Consulta por chave de acesso diverge do previsto ao tentar enviar a NFCe em ambiente de homologação. Motivo da Rejeição Conforme foi divulgado posteriormente pela SEFAZ, de forma não oficial, ou seja, sem a publicação de NTs ou outras informações nos portais relativos a NFCe, esta rejeição passou a ocorrer devido a implementação da regra ZX03-20 existente na NT 2016.002 versão 1.61, a qual determina a validação da URL de Consulta por Chave de Acesso conforme tabela disponibilizada no portal do ENCAT. Estas validações entraram em vigor em ambiente de homologação no dia 22/04/2019 e em produção entrarão em 20/05/2019. Solução Os fontes do ACBr e por consequência o ACBrMonitorPlus SAC, foram atualizados com as URLs corretas conforme documentação disponível na página do ENCAT. Porém, em alguns casos, os endereços indicados pelo ENCAT ainda sim estavam incorretos. Com base no feedback de diversos usuários de nossa comunidade, novos ajustes foram enviados para o SVN do ACBr, no arquivo ACBrNFeServicos.ini Dicas para Minimizar o Impacto em seus clientes Se você utiliza o componente ACBrNFe para emissão da NFCe, procure sempre disponibilizar na mesma pasta do seu binário (executável) o arquivo ACBrNFeServicos.ini. Desta forma, o componente ACBrNFe, irá fazer uso do arquivo ACBrNFeServicos.ini existente no diretório, ao invés de usar as URLs internas, que são compiladas como "Resource", e anexadas ao componente... Isso é extremamente vantajoso, pois lhe confere grande agilidade na resolução de problemas de URLs... Caso sejam detectadas novas alterações de URLs, basta realizar a substituição do arquivo ACBrNFeServicos.ini, evitando portanto a necessidade de atualizar toda a aplicação. Eu não distribuo o ACBrNFeServicos.ini em meus instaladores? Preciso recompilar e atualizar meus clientes para que as novas URLs entrem em vigor ? Se você não quer ou não pode distribuir o ACBrNFeServicos.ini, na mesma pasta da sua aplicação, então não há outra maneira a não ser disponibilizar um novo binário para o seu cliente... Porém antes , faça um teste, é simples e rápido... Apenas copie o arquivo ACBrNFeServicos.ini no mesmo diretório de sua aplicação, e observe que as novas URLs serão utilizadas, pois o componente ACBrNFe irá priorizar o arquivo em disco. Ainda tem Dúvidas? Acesse os sub-fóruns sobre NFCe e crie um novo tópico relatando seu questionamento. Lembre-se que se for usuário do SAC Anual você também pode falar conosco pelo chat ACBr.
    23 pontos
  23. Olá pessoal, Quero comunicar o nascimento do mais novo membro da família ACBr. Estou falando do ACBrGTIN. Esse componente tem como objetivo realizar uma consulta na SEFAZ, onde é informado somente o GTIN do produto a ser consultado (também conhecido como código EAN) e temos como resposta informações cadastradas pelo "Dono da Marca" na GS1. Essas informações podem ser: o tipo do GTIN (que pode ser 8, 12, 13 ou 14) a descrição do produto o código NCM código do CEST. Infelizmente nem sempre teremos um retorno completo. Isso porque nem todas as empresas "Dono da Marca" cadastram os seus produtos na GS1 e muitas que cadastraram não autorizaram a divulgação dos dados. Neste caso podemos ter as seguintes rejeições: 9494: GTIN inexistente no Cadastro Centralizado de GTIN (CCG); 9495: GTIN existe no CCG com situação inválida. Solicitar ao dono da marca que entre em contato com a GS1; 9496: GTIN existe no CCG, mas dono da marca não autorizou a publicação das informações. Entrar em contato com o dono da marca; 9497: GTIN existe no CCG com NCM não cadastrado; 9498: GTIN existe no CCG com NCM inválido; Dica de uso do componente: Utilize ele ao cadastrar novo ou atualizar um produto na sua aplicação. Nunca, jamais mesmo, use o componente no momento da venda. Consta na NT 2022/001 versão 1.00 referente ao WS de Consulta do GTIN (página 6) a seguinte informação: Serão mantidos controles para identificar as situações de “uso indevido”, no consumo excessivo do Web Service em um curto espaço de tempo. As novas tentativas poderão ser rejeitadas com o erro “656–Rejeição: Consumo Indevido” Informação Importante: A Equipe ACBr esta trabalhando para disponibilizar o programa exemplo, bem como o pacote para o Lazarus e uma nova versão do ACBrInstall que permite a instalação no Delphi do novo componente: ACBrGTIN.
    22 pontos
  24. PERGUNTA: Eu uso o ACBr. Posso colocar o ACBr como Reponsável Técnico na emissão de algum documento fiscal eletrônico (ou DF-e, isto é, NF-e, NFC-e, CT-e, MDF-e, etc...) ? Mesmo que você use o ACBrMonitor Plus, a ACBrLib, os componente ACBr, algum programa exemplo que disponibilizamos, a resposta simples é NÃO. Não entenda mal. Reafirmamos nosso compromisso em ajudar os usuários do ACBr a resolver seus problemas no uso dos componentes, bibliotecas ou aplicativos que disponibilizamos na medida do possível. E claro, damos prioridades aos casos reportados por usuários que fazem uso do SAC ACBr. Mas não somos o responsável técnico pelo seu sistema, mesmo que ele use qualquer ferramenta que provemos. Talvez você queira entender um pouco mais, então vamos a uma resposta longa sobre isso. Vamos usar como exemplo a NF-e e NFC-e que são de longe os DF-es mais utilizados. Se você ler a nota técnica 2018.005 da NF-e/NFC-e vai encontrar o item "2 Sobre a Identificação do Responsável Técnico". Nesse item há a seguinte frase no parágrafo que explica o que é essa informação (grifo é meu): Veja que a primeira frase menciona que o "responsável técnico" pode não ser simplesmente um desenvolvedor, mas a empresa responsável tecnicamente pelo sistema de emissão. O que neste caso é vocês. Vocês respondem perante seu cliente e perante as autoridades pela emissão do documento fiscal. Os produtos do projeto ACBr (seja algum componente, o ACBrMonitor, ou uma ACBrLib) nesse processo é apenas uma ferramenta parte do seu software e não o sistema em si. Ou seja, é um framework/biblioteca/componente que ajuda seu sistema e sua empresa a emitir os documentos. Veja, não disponibilizamos sistemas para emissão, apenas ferramentas para ajudar na emissão. Isso fica mais claro quando lemos o restante do parágrafo, porque ele explica não só o que é o "responsável técnico", mas também o objetivo dessa informação ser necessária. Veja: A ideia é a SEFAZ poder entrar em contato com o responsável pelo emissor em caso de dúvidas ou problemas na emissão. Em caso de anomalias na emissão, com quem a SEFAZ teria que entrar em contato? Por exemplo: Em uma das reuniões do ENCAT, um sistema tentou retransmitir uma nota com erros no XML, por 70.000 vezes... ou seja, mesmo recebendo o erro de rejeição por XML inválido, a aplicação ficou em algum Loop, tentando retransmitir o XML que já sabia era rejeitado... Isso é praticamente um ataque de DDOS, nos servidores do SEFAZ... Quem a SEFAZ teria que contatar se essa empresa fosse seu cliente? É evidente que em caso de dúvidas ou problemas sobre o uso nas empresas que são seus clientes eles deverão entrar em contato com a sua empresa. Afinal de contas, nós não sabemos como seu sistema funciona, nem conhecemos os seus clientes. Ainda mais, o ACBr, (quero dizer ACBrMonitor, ACBrLib, ou qualquer componente ou biblioteca que fornecemos), por si só nunca faz uso de um WebService. Qualquer WebService é acionado por sua aplicação. Ela, a sua aplicação, é responsável pela emissão. Chamar o ACBr de responsável seria basicamente o mesmo que colocar como responsável a Microsoft porque você usa o Windows nos seus clientes, ou a biblioteca OpenSSL porque você a usa pra assinar os documentos. Existe mais um detalhe, o item "2.1 Código de Segurança do Responsável Técnico - CSRT" que nos ajuda a entender. Esse item fala do credenciamento do software emissor de DF-e na SEFAZ da UF e da empresa responsável. Se sua UF já tem esse cadastro, ou algum cadastro similar como era o caso do PAF-ECF, sem dúvida você entende que é sua empresa e seu software que deve ser cadastrado, independente de usar ou não alguma ferramenta de terceiros em seu sistema. Peraí! Tem mais! No terceiro parágrafo há a seguinte explicação sobre o CSRT, que pode ser exigido em formato de hash: Mais uma vez, se essa é uma informação conhecida somente entre a empresa desenvolvedora e Fisco, não teria como ser disponibilizada por nós. Senão, poderíamos nos passar por você. Seria como você dar seu RG ou Passaporte para outra pessoa se passar por você. Então para pra deixar isso claro pra qualquer pessoa com dúvida no futuro: O projeto ACBr não se responsabiliza por mal uso de nenhum dos programas, bibliotecas, componentes, ou códigos fontes disponibilizados. Usar qualquer um desses, incluindo o ACBrMonitor Plus, não dá direito a ninguém colocar o Projeto ACBr como responsável técnico, ou de qualquer outra forma responsável perante clientes ou autoridades. Se alguém pensar diferente, informamos que não tem licença para utilizar o que provemos. Pedimos o favor de ler com cuidado as licenças LGPL e GPL que usamos.
    22 pontos
  25. Após uma atualização do Windows Update nos sistemas operacionais Windows 8 a 10, vários usuários começaram a ter problemas na conexão segura com o SEFAZ.... Onde geralmente foram exibidos os erros abaixo: Erro: 12175 - Um ou mais erros foram encontrados no certificado Secure Sockets Layer (SSL) enviado pelo servidor Erro: 12169 - O certificado SSL é inválido Erro: 12186 - Falha ao obter a Chave Privada do Certificado para comunicação segura Estes erros indicam uma falha na validação do certificado do servidor da SEFAZ, e entre as diversas causas que podem disparar este erro, podemos citar: Falta da cadeia de certificados instalado no cliente. Cadeia de certificados desatualizados. Erro no componente de validação do Windows. Erro no certificado da SEFAZ. SEFAZ enviou um certificado invalido. O problema foi confirmado pelo SEFAZ do PR, no comunicado abaixo: Para os usuários do Projeto ACBr, esse problema afetou apenas quem utiliza os componentes configurados com as bibliotecas Wincrypt ou CAPICOM pois os mesmo utilizam o sistema de validação do Windows. O problema não afetou usuários que usam a biblioteca OpenSSL. Em decorrência do problema, aplicamos um ajuste nos fontes da ACBrDFeSSL, visando ignorar erros na validação do certificado. Com isso a comunicação Segura ocorrerá normalmente... Os fontes alterados já se encontram no SVN... e excepcionalmente, efetuamos uma nova compilação do ACBrMonitorPLUS v 1.2.0.52, para os usuários do SAC Saiba mais sobre comunicação Segura do ACBr
    22 pontos
  26. Olá pessoal, Na postagem "Como obter o XML do Fornecedor" mostrei o uso do método DistribuicaoDFePorChaveNFe, nessa nova postagem vou mostrar mais dois métodos: DistribuicaoDFePorUltNSU e DistribuicaoDFePorNSU. Vamos a sintaxe, que por sinal é semelhante ao do DistribuicaoDFePorChaveNFe. DistribuicaoDFePorUltNSU( <código da UF do destinatário>, <CNPJ do destinatário>, <numero do ultimo NSU> ) DistribuicaoDFePorNSU( <código da UF do destinatário>, <CNPJ do destinatário>, <numero do NSU> ) Primeiramente vamos entender o que vem a ser esse tal de NSU. NSU - numero sequencial único, é um numero atribuído pelo Ambiente Nacional ao documento ora compartilhado pelas SEFAZ-Autorizadora. Exemplo: o emitente da nota é do Estado de São Paulo, logo a nota é enviada para a SEFAZ-SP esta por sua vez vai compartilhar com o Ambiente Nacional as notas que foram autorizadas, o Ambiente Nacional por sua vez atribui um NSU para cada nota que receber. Na verdade o Ambiente Nacional gera um resumo da nota e atribui o NSU a esse resumo primeiramente e não a nota propriamente dita. Um NSU só será atribuído a nota quando o destinatário enviar o evento de Manifestação do Destinatário. Lembre-se o NSU da nota será um numero diferente do NSU do resumo dela, e por ser gerado após o envio do evento de Manifestação do Destinatário, podemos concluir que o NSU da nota é maior que o NSU do resumo. Vamos agora entender como funciona os dois métodos mencionados acima. O método DistribuicaoDFePorNSU é o mais simples de entender, pois este simplesmente baixa o documento que possui o NSU informado. Note que usei o termo documento, pois o webservice DistribuicaoDFe pode retornar os seguintes tipos de documentos: Resumo de Nota, Nota Completa, Resumo de Evento e Evento Completo. Se o NSU informado no método DistribuicaoDFePorNSU for o NSU de um resumo, o que teremos como retorno será o XML do resumo e não o XML da Nota. Por outro lado o método DistribuicaoDFePorUltNSU nos retorna uma lista com até 50 documentos, cujos NSU são superiores ao NSU informado. Exemplo: DistribuicaoDFePorUltNSU( 35, 12345678000123, 450 ) ===> 450 é o valor do Ultimo NSU. Ao executar o método, como dito anteriormente poderá nos retornar uma lista com até 50 documentos, pois bem suponha que retorne 50, os NSU desse documentos retornados serão, 451, 452, 453, ...., 498, 499, 500. Lembre-se que nessa lista podemos ter Resumos de Notas, Notas Completas, Resumo de Eventos e Eventos Completos. Através de uma propriedade chamada Schema nos traz a informação do tipo de documento retornado. Temos também outras duas propriedades muito importantes, são elas: UltNSU e MaxNSU. A propriedade UltNSU nos informa o numero do NSU referente ao ultimo documento da lista, já a propriedade MaxNSU nos informar o maior NSU existente no Ambiente Nacional. Continuando o exemplo acima, vamos supor que após a execução os valores de UltNSU e MaxNSU são respectivamente 500 e 750. Era de se esperar mesmo que o valor de ultNSU seja 500 pois informamos 450 e foi retornado 50 documentos, logo o NSU do ultimo é 500. A próxima vez que formos executar o DistribuicaoDFePorUltNSU devemos informar o valor 500, para que ele retorne os documentos a partir de 501 que é o próximo da lista. E devemos repetir o procedimento até que o valor de ultNSU seja igual a maxNSU, desta forma vamos ter baixado todos os documentos disponibilizados pelo Ambiente Nacional. Lembre-se que o valor de MaxNSU tende sempre a crescer a medida que novas notas forem emitidas e compartilhadas com o Ambiente Nacional e a medida que o destinatário for enviando o evento de Manifestação do Destinatário. Entre uma execução e outra do DistribuicaoDFePorUltNSU você pode realizar a manifestação referente a cada resumo de nota obtido, ou seja, enviar o evento de Manifestação do Destinatário. Desta forma a medida que você vai avançando na lista o Ambiente Nacional já vai liberando a Nota Completa (notas manifestadas) e disponibilizando ela na lista. O DistribuicaoDFe não serve apenas para que possamos obter o XML do fornecedor, mas também descobrirmos se existe alguma empresa emitindo notas contra o nosso CNPJ sem no nosso consentimento. Você descobre isso através do DistribuicaoDFePorUltNSU e pode avisar a SEFAZ enviando o evento de Manifestação do Destinatário: Desconhecimento da Operação. Esse evento diz a SEFAZ que você não comprou desse fornecedor. Para saber mais sobre Manifestação do Destinatário vide a Nota Técnica 2012/002 versão 1.02 e para saber mais sobre o Distribuição DFe vide a Nota Técnica 2014/002 versão 1.02b, ambas estão disponíveis no Portal Nacional da NF-e.
    22 pontos
  27. Olá pessoal, Lá vamos nós mais uma vez, só que agora é a vez de algumas melhorias no CT-e. E quais são as novidades da versão 4.00 do CT-e? Eliminação do SOAP Header dos Webservices Não precisamos se preocupar pois o componente vai se encarregar de não gerar o grupo <Header> ao montar o Envelope a ser enviado para o WebService da SEFAZ. Eliminação da Denegação e do CTe de Anulação Com essa nova versão não teremos mais como emitir um CT-e de Anulação, somente CT-e Normal, CT-e Complementar e CT-e de Substituição. O Manual não diz o porque, mas acredito que essa alteração vem de encontro com o DC-e (Declaração de Conteúdo Eletrônico). Quanto a Denegação o que tudo indica nenhum CT-e vai ser Denegado, ou seja, ou ele vai ser autorizado ou rejeitado. Eliminação do Serviço de Autorização Assíncrono O envio do CT-e passa a ser no modo síncrono e unitário, ou seja, somente um CT-e por vez será enviado para o WebService e já teremos como resposta o protocolo de autorização ou a rejeição. Ampliação do Nro Seq dos Eventos Antes um tipo de evento que poderia ser enviado mais de uma vez (por exemplo Carta de Correção) estava limitado a 20, agora o limite é 999. Eliminação do serviço de inutilização Com a versão 4.00 não teremos mais como inutilizar um numero de um CT-e que não foi enviado para a SEFAZ, acredito que caso ocorra um pulo, por exemplo, foi enviado o CT-e de numero 500 e por algum problema foi enviado o CT-e de numero 505, vai ser possível em seguida enviar os CT-e de números 501, 502, 503 e 504 para depois voltar a sequencia normal ou seja emitir o CT-e de numero 506 em diante. Sobre os prazos A versão 4.00 vai estar disponível a partir de 04/2023 em ambiente de Homologação e a partir de 06/2023 em Produção. Quanto as Soluções ACBr Haverão ajustes no componente ACBrCTe para atender a versão 4.00, oque naturalmente se refletirá nas versões posteriores da ACBrLibCTe e do ACBrMonitor. Fiquem atentos as atualizações dos fontes do ACBr e não percam o bonde. Quanto a minha Aplicação? Com certeza a sua aplicação deve ter uma opção para emitir CT-e de Anulação e Inutilização de Números, pois bem essas opção não poderão mais poder ser utilizadas com a nova versão. Sugerimos que apresente uma mensagem ao usuário informando que essa opção não esta mais disponível na versão 4.00 do CT-e. Se a sua aplicação permitia o envio de um lote de CT-e, agora só será possível enviar um de cada vez, logo você vai ter que mudar isso. Com certeza a sua aplicação envia eventos, fique atento a esta questão: para os tipos de eventos que permite enviar mais do que 1 para o mesmo CT-e, lembre-se que agora o limite passou de 20 para 999. Leitura recomendada: Temos os manuais (que são 3) da versão 4.00 em nossas biblioteca. http://svn.code.sf.net/p/acbr/code/tools/DFe/CTe/
    21 pontos
  28. Configurações do ACBrMail para os principais serviços de emails do mercado outlook e hotmail smtp: smtp.office365.com porta: 587 tsl : true; ssl : false; Referência: Microsoft hotmail O smtp.live.com, utilizado anteriormente para o hotmail, parou de funcionar. Para utilizar o smtp.office365.com: 1. Ao entrar no hotmail, embaixo tem a opção atualizar para microsoft office365 premium. 2. Depois, crie uma conta grátis que já atualiza o hotmail para receber email office365. office365 smtp alternativo: smtp-legacy.office365.com gmail smtp: smtp.gmail.com usuario: [email protected] porta: 465 tsl : true; ssl : true; é necessário criar uma senha para a aplicação, portanto não é permitido mais utilização da senha principal da conta. 1. Ativar a verificação em duas etapas. 2. Criar uma senha para a aplicação. https://myaccount.google.com/apppasswords yahoo smtp: smtp.mail.yahoo.com.br porta: 587 tsl : true; ssl : false; password: não use a senha padrão da conta, precisará criar uma exclusiva para sua aplicação. siga os passos abaixo: criada pelo link https://login.yahoo.com/account/security#less-secure-apps e depois 'Gerenciar Senha de app', selecione 'Outro app' ,der um nome ao app, e clique gerar senha.; Veja ainda, a dica desse Post sendgrid smtp : smtp.sendgrid.net usuario: nome da conta senha : senha da conta tsl : true; ssl : false; porta: 465 Autor: @Aurino Locaweb From := '[email protected]'; FromName := 'Nome do Remetente'; Host := 'email-ssl.com.br'; Username := '[email protected]'; Password := 'Sua_Senha'; Port := '465'; SetTLS := False; SetSSL := True; Locaweb2 From := '[email protected]'; FromName := 'Nome do Remetente'; Host := 'email-ssl.com.br'; Username := '[email protected]'; Password := 'Sua_Senha'; Port := '587'; SetTLS := True; SetSSL := False; SparkPost From := '[email protected]'; FromName := 'Nome do Remetente'; Host := 'smtp.sparkpostmail.com'; Username := 'SMTP_Injection'; Password := '8a93c971789791b0102d889dd8f5f9b40507288d'; // Sua API Key Port := '587'; SetTLS := True; SetSSL := False;
    21 pontos
  29. Olá pessoal, Sei que todos estão muito atarefados com seus programas por aí... Maaaasssss.... Precisamos de sua atenção para uma alteração nos componentes!!! Atualmente temos uma falta de padronização nas unidades de medidas das margens das impressões dos documentos fiscais. Cada impressão Report tem margens medidas com um formato. Isso não está bom. Note a tabela a seguir com as unidades de medidas das margens atual: DF-e Fortes Fast LazReport ESCPOS NF-e (Paisagem, Retrato, Inut, Evento, Simplificado) cm cm nd X NFC-e mm mm X X NFC-e (A4) cm mm X X SAT mm X X X CT-e (Evento) cm nd X X CT-e (A5, Retrato) nd nd X X CT-e (Inut, Inut Retrato) nd nd X X GNR-e nd nd nd X MDF-e (Retrato, Evento) cm nd X X NFS-e cm nd X X BP-e X X X X Legenda: mm – milímetros cm – centímetros nd – O componente poderia, mas não está atualizando as margens do report X – Não possui impressão nesse formato ou não interage com as margens. Nota: Os modelos em ESCPOS que existem não consideram as propriedades de margem. Afinal, não faz muito sentido mesmo. Como podem ver na tabela acima, muitos componentes não estão atualizando as margens. Isso significa que mesmo que configure uma margem, ela será simplesmente ignorada. Então a ideia é fazer com que esses componentes imprimam de acordo com a configuração. Além disso, queremos evitar qualquer possível confusão e por isso vamos padronizar as unidades de medidas. A unidade de medida escolhida foi milímetros (mm). Alguns dos motivos foram: A unidade de medida mm funciona bem tanto para impressões grandes (por exemplo A4) como para bobinas (80 mm); As pessoas estão acostumadas com mm porque é a unidade padrão de todos os geradores de relatório usados atualmente (Fast Report, Fortes Report, LazReport ...); Devido ao ponto anterior, usar mm vai nos poupar código de conversão de unidades; Mesmo que tivéssemos escolhido centímetros (cm), haveria quebra de compatibilidade por causa do SAT e NFC-e; Quando as alterações vão entrar em vigor? A previsão é que dia 14 de outubro, as alterações sejam enviadas ao SVN. Acreditamos que isso dá tempo suficiente, para conseguirmos avisar a todos e para que todos possam se preparar. As alterações já foram enviadas ao SVN. Veja nota no fim desse post. O que eu preciso verificar no meu aplicativo? A primeira coisa é verificar se você tem configuração de margem (seria bom que tivesse). Em caso afirmativo, como você está armazenando? Em que unidade está armazenando? cm ou mm? Vai ser necessário fazer alguma conversão? Verifique como você deseja manter a configuração? De posse das informações acima, faça um teste imprimindo todos os documentos que você usa. Isso vai ajudar você a prevenir qualquer problema antes de enviar o executável para o cliente. Sugerimos você a imprimir tanto antes como depois das alterações no componente. Assim você vai ter algo para comparar as impressões e ajustar as margens caso necessário. O que eu preciso fazer caso use o ACBrMonitor Plus? A nossa ideia é minimizar o impacto para quem usa o ACBrMonitor. Vamos colocar as informações o próximo post logo abaixo. Se ficarmos atentos a essas alterações, as impressões vão seguir o mesmo padrão e ninguém mais vai precisar se confundir. Atualização- 17/10/2019 As alterações já foram enviadas ao SVN. Agora todos os reports seguem o mesmo padrão: DF-e Fortes Fast LazReport ESCPOS NF-e (Paisagem, Retrato, Inut, Evento, Simplificado) mm mm mm X NFC-e mm mm X X NFC-e (A4) mm mm X X SAT mm X X X CT-e (Evento) mm mm X X CT-e (A5, Retrato) mm mm X X CT-e (Inut, Inut Retrato) mm mm X X GNR-e mm mm mm X MDF-e (Retrato, Evento) mm mm X X NFS-e mm mm X X BP-e X X X X Caso encontre algum problema, queira por favor criar um novo tópico.
    21 pontos
  30. Olá amigos, depois de mais um cliente ter perdido o certificado resolvi que ia tentar descobrir oque estava causando isso, e depois de muita peleja(são 4:00 da manhã ), acho que consegui chegar ao causador do problema, pelo menos tive sucesso em excluir um certificado por diversas vezes assinando um XML. E como muito se falava, não é diretamente o ACBR que está excluindo o certificado, pelo que constatei é a MSXML que está "reiniciando" o certificado e somando isso a mais algum problema está causando a exclusão. Se você assinar um XML e deixar o administrador do token aberto, verá que no momento da assinatura, no trecho "xmldsig.sign(dsigKey, CERTIFICATES);" o token muda de: Operacional >> Ausente >> Presente >> Operacional, como se o cartão fosse removido e inserido novamente. Pensei aí tem coisa! Tentei remover o cartão durante a assinatura mas não consegui simular a exclusão do certificado, imaginei que não estava sendo rápido o suficiente. Então coloquei um loop no trecho do ACBR que pega a chave privada do certificado, antes de executar a assinatura, percebi que até aí o PIN do certificado não era solicitado, somente mais a frente quando ocorre a assinatura com "xmldsig.sign(dsigKey, CERTIFICATES);". Porém quando removi o certificado da leitora e inseri novamente dentro do loop(o mesmo que a MSXML faz durante a assinatura) foi me solicitado o PIN e logo depois veio a mensagem: "O conjunto de chaves não está definido", olhando no administrador do token que estava aberto pude ver o certificado sendo excluído: O PIN que ele me solicitou foi para excluir o certificado! O que imagino que esteja acontecendo é que se você chamar o método Assinar repetidamente, antes de dar tempo do cartão ficar operacional novamente, o certificado pode ser excluído. Isso explicaria o porque da exclusão ser esporádica e também não acontecer com todos os sistemas, pois dependeria da lógica usada por cada um para assinar, como assinaturas em sequência ou mesmo mais de uma thread acessando o certificado. Fiz um vídeo mostrando o momento da exclusão, note que não consegui excluir na primeira tentativa, porque demorei muito pra inserir o cartão, estava com uma mão ocupada filmando, ia editar isso mas tô com muito sono. MODERAÇÃO: vídeo removido a pedido do usuário Vou dormir um pouco e amanha ver se me aprofundo no problema.
    21 pontos
  31. Regras e orientações gerais do Fórum Olá Pessoal, Com o objetivo de deixar o nosso fórum mais dinâmico e organizado para cumprir o objetivo de ser uma ajuda a todos os usuários do projeto ACBr, estamos deixando aqui algumas regras e orientações para todos nós. Todos devem se familiarizar com essas. Também queremos lembrar que essas são regras e orientações gerais para todo o fórum. Para regras específicas do ACBrSAC, queira ver esse tópico sobre o funcionamento do SAC. As orientações estão no próximo post desse tópico. Então vamos primeiro às regras: 1 - Assumiremos boa fé - Vamos procurar assumir boa fé ao lidar com violações, isto é, que o usuário não teve má intenção. Vamos procurar advertir ou banir apenas usuários que repetidamente ou flagrantemente violam as regras. Contudo, isso não dá direito a nenhum usuário abusar dessa liberdade. 2.1 - Não faça SPAM - Temos uma área específica para Classificados, então qualquer propaganda ou requisição de produtos e serviços deve ser postada lá. Usuários que postarem spam fórum terão suas mensagens removidas e podem ser banidos imediatamente sem prévio aviso. Se um post que é considerado apropriado incluir links consideradas spam, esses links serão removidos. 2.2 - Permaneça no assunto - Quando tiver uma dúvida diferente do assunto no tópico, poste em novo tópico. Não use algo equivalente a "aproveitando o gancho... [dúvida não relacionada com o tópico aqui]". 3.1 - Não faça flooding - Inundar o fórum com posts repetidos, com a mesma dúvida ou as mesmas palavras é chamado de flooding. Isso é proibido. Apenas um post feito no lugar certo é suficiente. Pesquise antes de postar, talvez sua dúvida já está respondida em outro post. 3.2 - Não faça "bump" de forma excessiva (postar simplesmente para que um tópico vá para o topo da lista). Isso é considerado flooding. 3.3 - Use o botão "Editar"- Não faça posts seguidos para corrigir algo que acabou de escrever. Para isto existe o botão "Editar" logo abaixo de seu post. Isso também é considerado flooding. 4 - Proteja sua privacidade - Não publique qualquer informação sensível. Moderadores poderão remover informações pessoais de mensagens para proteger sua privacidade. 5.1 - Respeite os direitos autorais - Não há objeção de se postar algum trecho de algo para desenvolver o seu post. No entanto, em vez de publicar em sua totalidade um texto de outra pessoa, coloque um link para o conteúdo. A não ser, é claro, que você seja o detentor ou tenha a permissão do detentor dos direitos autorais. 5.2 - Nada de pirataria - É proibido fornecer ou pedir informações sobre como obter ou fornecer ilegalmente qualquer coisa, seja software ("warez", "Crackz"), música, produtos, etc. 6.1 - Respeite os outros membros - Não use linguagem obscena, racista, discriminatória, indecente, lasciva, suja, ou excessivamente violenta. Isso também inclui as imagens e assinaturas dos usuários que podem ser alteradas ou removidas pela equipe de moderação. 6.2 - Não assedie, insulte, provoque, humilhe, constranja ou ataque pessoalmente outros. Seja amigável mesmo que os outros não sejam. 6.3 - Mostre respeito pelo modo de escrever. Escreva de modo claro, gramaticalmente e semanticamente correto. Não escreva TUDO EM MAIÚSCULAS ou tudo em negrito. Isso é lido como se estivesse gritando e é considerado rude. 6.4 - Assinaturas: É permitido o uso de uma imagem nas assinaturas. Apenas mantenha a imagem com no máximo 175 pixels de altura e 540 pixels de largura. O motivo destas limitações é que não queremos assinaturas que tirem a atenção dos posts nem que quebrem o layout do fórum (mesmo o layout mobile). Somos um fórum de programação e automação comercial, não de design. 7 - Ajude os moderadores - Se você observar alguém quebrar uma regra, ou se comportando de uma ou outra forma questionável, alerte um moderador ou um administrador. Há opções de denúncia nos posts. Não tente lidar com eles sozinho. 8 - Os administradores e moderadores usarão bom senso e têm a palavra final na interpretação e execução destas regras. 9 - Os administradores poderão modificar essas regras para que se tornem mais práticas e/ou claras para todos. Não seja um chato: Ou adicionaremos algumas imagens e mensagens bem constrangedoras ao seu perfil e avisaremos a todos os seus amigos por e-mail, facebook e twitter... Brincadeirinha: Mas tenham certeza que vamos fazer as regras valerem. Mesmo que isso inclua punições. Como podem ver não criamos uma lista extensa de regras. Acreditamos que o bom senso e um ambiente profissional é do desejo de todos os usuários do ACBr e confiamos que todos tem se esforçado pra fazer o melhor. Assim esperamos que isso não se torne necessário. Agradecemos sua cooperação. Equipe de Moderação.
    21 pontos
  32. O antigo componente ACBrNCM, havia sido desativado, pois o WebService que ele consultava, foi desativado... Recentemente, achamos um novo WebService, da SisComex: https://portalunico.siscomex.gov.br/classif/api/publico/nomenclatura/download/json Tendo isso em mãos, reescrevemos todo o componente ACBrNCM, para fazer uso desse novo WebService, e adicionamos recursos incríveis nele... Veja o que foi descrito no arquivo ACBrTCP-change-log.txt Os Demos em Delphi e Lazarus, já foram atualizados, e demonstram bem as novas possibilidades de Filtro por Descrição ou Código... Agradeço a contribuição de @maiko_bito... Nosso Consultor @EliasCesar, fez um ótimo trabalho introduzindo no componente o sistema de Cache local e Busca binária e Ordenação... Eu mesmo, fiz a revisão final... Atualizem seus fontes e nos dê um Feedback, sobre essa nova implementação
    20 pontos
  33. 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.
    20 pontos
  34. 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
    20 pontos
  35. Boa tarde Pessoal, Primeiro foi o CT-e e o MDF-e a ter o seu layout alterado para contemplar um novo grupo: <infRespTec> Informações do Responsável Técnico, agora esta chegando a vez da NF-e. Os 3 componentes já estão preparados para gerar esse grupo. Alguns desenvolvedores já estão gerando o grupo <infRespTec> para o CT-e e MDF-e, tanto em homologação quanto em produção. No caso da NF-e as datas previstas são: para o ambiente de homologação é 25/02/2019 e para produção é 29/04/2019 alterado para 03/06/2019 (conforme consta na versão 1.30 da NT 2018/005). Quero deixar claro que essas datas se referem ao prazo para que as SEFAZ finalizem a implementação em seus webservices, portanto somente a partir dessas datas é que poderemos enviar o XML da NF-e com esse grupo. Portanto, a partir do dia 25/02/2019 teremos um prazo de 3 meses para realizar os testes em ambiente de homologação. Outra coisa importante a ser dita é que esse grupo é opcional, mas vai ficar a critério de cada UF torna-lo obrigatório ou não. Quais são as informações que compõe esse grupo? O grupo <infRespTec> é composto pelos campos: CNPJ da empresa que desenvolveu o software, xContato é o nome da pessoa responsável pelo software, email e fone dessa pessoa ou da empresa. Caso você opte por gerar esse grupo independente da UF exigir ou não, as 4 informações acima deveram constar. Como dito acima os componentes ACBrNFe, ACBrCTe e ACBrMDFe já estão preparados para gerar o grupo <infRespTec>, para que isso ocorra basta acrescentar na sua rotina que alimenta o componente com os dados que vão fazer parte do XML as seguintes linhas... O exemplo abaixo é para a NF-e: with ACBrNFe.NotasFiscais.Add.NFe do begin (...) infRespTec.CNPJ := xCNPJ_RespTec; // CNPJ da Empresa infRespTec.xContato := xContato_RespTec; // Nome do Contato infRespTec.email := xEmail_RespTec; // email do Contato ou Empresa infRespTec.fone := xFone_RespTec; // fone do Contato ou Empresa end; As linhas em negrito acima são exatamente iguais para o CT-e e MDF-e. Nas Notas Técnicas da NF-e, CT-e e MDF-e que se refere a esse grupo tempos ainda mais dois campos: idCSRT e hashCSRT que vão ficar para uma segunda etapa. O CSRT - Código de Segurança do Responsável Técnico, trata-se de um código alfa numérico que será fornecido pela SEFAZ através de uma página própria ou por um webservice, conforme consta na Nota Técnica. Sendo assim, enquanto a SEFAZ não criar essa página ou webservice não temos como solicitar o CSRT e portanto não podemos incluir no XML o idCSRT que é um numero sequencial e o hashCSRT que é o resultado do hash (SHA1 - Base64) da concatenação do CSRT mais a chave do documento. Os componentes já possuem no rol de configurações, as propriedades idCSRT (Integer) e CSRT (String), nessa primeira etapa devemos atribuir o valor zero a idCSRT e uma string vazia para o CSRT, para que os campos: idCSRT e hashCSRT não sejam gerados. Os valores padrões estabelecidos pelo componente são: idCSRT = 0 e CSRT = '' (string vazia). Reforço que o preenchimento dessas propriedades só devem ser feitas a partir do momento que a SEFAZ lhe fornecer o idCSRT e o CSRT. Vamos supor que as UF: x, y e z venham a exigir o grupo <infRespTec> e criem uma pagina ou webservice para fornecer o CSRT, caso você tenha clientes usando ou seu software para emitir NF-e ou CT-e ou MDF-e será necessário solicitar o CSRT em cada uma das UF. Resumindo o CSRT fornecido pela UF x só é valida para os seus clientes dessa UF que usam o seu software. Quais são as UF que vão exigir o grupo <infRespTec> não sabemos, logo devemos ficar atentos. A minha sugestão é que o seu software gere esse grupo independente da UF exigir ou não, pois o dia que ela resolver exigir você não vai precisar fazer nada, pois já consta no XML o grupo. A questão agora é quanto ao CSRT, como dito anteriormente, vai ficar para uma segunda etapa visto que, se faz necessário a SEFAZ criar a página ou webservice. O meu conselho é que no seu software na tela de configuração tenha os campos: idCSRT e CSRT para que você possa informa-los assim que obter. Detalhe importante, os campos idCSRT e hashCSRT só serão gerados no XML e de forma automática dentro do grupo <infRespTec> a partir do momento que as propriedades de configuração: idCSRT e CSRT passarem a ter valores validos. O texto ficou longo, mas espero ter passado todas as informações necessárias para que vocês possam fazer as alterações em seus softwares e desta forma ficarem em conformidade com as nas Notas Técnicas. Para quem não leu as NT, por favor leiam. NT 2018/005 versão 1.20 - Alteração do layout da NF-e https://sourceforge.net/p/acbr/code/HEAD/tree/tools/DFe/NFe/NT/2018/ NT 2018/002 versão 1.01 - Alteração do layout do CT-e https://sourceforge.net/p/acbr/code/HEAD/tree/tools/DFe/CTe/NT/2018/ NT 2018/002 versão 1.02 - Alteração do layout do MDF-e https://sourceforge.net/p/acbr/code/HEAD/tree/tools/DFe/MDFe/NT/2018/
    20 pontos
  36. Olá pessoal, Depois de um empolgante trabalho em conjunto entre a equipe do ACBr e do Fortes Report CE... Temos o orgulho de apresentar a nova versão do Fortes Report CE, trazendo os seguintes benefícios: Diversos bugs corrigidos Suporte a Lazarus Suporte a D7 a Tokyo 10.2.2 em um único Package Instalador automatizado (frceInstall.exe) O Fortes Report CE poderá ser baixado pelo SVN ou GIT, ou ainda, baixado pelo FRCEInstall.exe, usando a integração com o SVN Para baixar o Fortes Report CE por SVN, use o endereço: https://github.com/fortesinformatica/fortesreport-ce/trunk Para baixar o Fortes Report CE por GIT, use o endereço: https://github.com/fortesinformatica/fortesreport-ce.git Lembre-se que você precisará remover qualquer outra versão do Fortes Report que existir em sua máquina antes de instalar a nova versão... Isso implica em: Remover o Package da versão antiga do Delphi Remover os diretórios da versão antiga do Lib Path do Delphi Apagar os fontes e DCUs, e BPLs da versão antiga Todos os pacotes do ACBr, que fazem referencia ao Fortes Report, estão nesse momento, sendo alterados para fazer uso do novo nome de pacote adotado pelo Fortes Report CE Delphi: frce.dpk; Lazarus: frce.lpk
    20 pontos
  37. Não é justo. Não é lícito. Não é aceitável. Quando você bombardeia este fórum com questionamentos relativos aos componentes da suíte ACBr, com certeza, você não conhece o mínimo necessário e aceitável que lhe dê embasamento para tal. Com toda certeza, você já recebeu algum benefício aqui, mesmo que seja na forma de resposta à sua dúvida imbecil, afinal, quem de nós “magros” conhecedores do “object pascal” não fez um questionamento, torpe? Eu mesmo, fiz muitos, e, por inúmeras vezes o erro estava tão perto de mim que, minha “ânsia” por solução transferia algo que não poderia defender-se uma culpa que só minha. · Vejo hoje, questionamentos como os que um dia fiz, e, para você que impugna um componente merecedor de todos os méritos dos quais faz jus, é prudente que leia a história desta suíte, especialmente destes baluartes que o criaram, em especial, Daniel Simões, André de Freiras Moraes, Isaque Pinheiro, entre outros, e, dentre os quais posso destacar, Ítalo, Juliomar, EMBarbosa, Rafael Dias, Regys Silveira e, não poderia faltar a musa moderadora Juliana Tamizou. · Para aqueles que são moderadores e que não mencionei, meu respeito, minha admiração. Para você que está chegando agora, calma, muita calma, aqui não tem nenhum empregado seu, aqui tem sim, colaboradores, pessoas como você, e, muito diferente de você, pessoas que despende muito do seu tempo para permitir que você consiga se destacar no seu segmento. Por favor, não me queira mal, eu já fui assim igual a você, que, ao ler um texto como este pense, “que babaca”, mas é isso mesmo, sou babaca, sou assim, sou ACBr. Antes de tecer suas críticas, pense no quando estes caras que fiz questão de frisar lhe permitiram auferir lucros e, nem por isso lhe cobram um centavo se quer. Pense nisso!
    20 pontos
  38. Olá comunidade do ACBr, É com muita satisfação, que anunciamos a criação de um novo componente, o ACBrAbecsPinPad, no Package ACBrSerial O que faz o ACBrAbecsPinPad ? Esse componente permite que você se comunique de forma direta, com PinPads que sigam o protocolo ABECS. Com ele você poderá realizar tarefas como: Limpar e Exibir Mensagens no Display Exibir imagens PNG, JPG, GIF no Display (útil para exibição de QRCode, Animações e Logos) Efetuar Perguntas padrões no PinPad, e coletar a resposta dos usuários (os tipos de perguntas, são padronizados pela ABECS) Exibir Menus no PinPad (útil para pesquisa de satisfação) Coletar Informações do PinPad, como: Num.Serial, capacidades da Tela, Memória disponível, etc No mercado nacional, todos os PinPads comercializados, precisam seguir essa especificação. Você pode encontrar a especificação do Protocolo ABECS, nesse Documento Não é o intuito desse componente, contemplar os métodos de captura de cartão e senha, pois isso exige o conhecimento de tarefas complexas, e chaves para a comunicação segura... Essas tarefas já são realizadas pelas bibliotecas de TEF como a PayGo O que é um PinPad ? O Pin Pad pode ser definido como um equipamento eletrônico de pagamento que faz a leitura de cartões e que conta com um teclado para que o cliente possa digitar a senha (se necessário) e, assim, validação da transação financeira. O Pin Pad não é um aparelho autônomo. Ele precisa estar conectado a outros elementos para funcionar, tais como um PC ou um PDV Android. De modo geral, eles aceitam diferentes tipos de cartões — a exemplo dos de crédito, débito, vale-alimentação e vale-refeição — e das mais variadas bandeiras. Fonte: https://zoop.com.br/blog/pagamento/o-que-e-pin-pad/ Veja um exemplo do Equipamento: Q25 da Tectoy Onde posso achar o novo componente ? Os fontes já estão disponíveis no SVN do ACBr. Demos em Lazarus e Delphi já estão disponíveis na pasta: \ACBr\Exemplos\ACBrSerial\ACBrAbecsPinPad... A versão mínima do Delphi é a 10.3.x, isso ocorre porque as versões anteriores não suportam Imagem PNG, e o Pinpad não suporta Imagem em formato BMP. O que preciso para testar ? Qualquer PinPad, que seja compatível com ABECS. Lembrando que todos os PinPads vendidos no mercado brasileiro o são. A versão da ABECS que nos baseamos a 2.12, entretanto ele deve ser compatível com versões inferiores... Você pode ver a versão da biblioteca ABECS embarcada no seu PinPad, quando o mesmo é inicializado. Por norma da ABECS, o PinPad deve possuir cabo USB, mas disponibilizar uma Porta Serial, quando conectado ao equipamento.Portanto, sempre usaremos a comunicação Serial do ACBr, para "falar" com o PinPad É importante que você instale o Driver do Fabricante do equipamento, antes de iniciar os testes, pois o driver genérico do Windows, pode não funcionar adequadamente... O ACBrAbecsPinPad está disponível em Lib (DLL) ? Não no momento, mas há planos futuros... Quem é a ABECS ? A Abecs atua desde 1971 como representante oficial do setor de meios eletrônicos de pagamento no Brasil. É responsável pela interlocução do setor perante o mercado, os órgãos públicos e a sociedade. Congrega atualmente mais de 90 empresas desse segmento, representando assim mais de 96% do mercado. Entre seus associados estão instituições financeiras, bancos digitais, adquirentes, bandeiras, fintechs, marketplaces, empresas de tecnologia, entre outras que atuam no sistema de pagamentos. É a interlocutora do setor em assuntos regulatórios e promove a autorregulação desde 2008. Consolida e divulga o balanço de dados do setor, realiza anualmente o Congresso de Meios Eletrônicos de Pagamento (CMEP), fomenta o desenvolvimento do mercado em seus comitês e grupos de trabalho e promove campanhas que incentivam o uso consciente do cartão, entre outras atribuições. https://abecs.org.br/quem-somos Exemplo do componente ACBrAbecsPinPad carregando e exibindo uma imagem no PinPad
    19 pontos
  39. Tendo em vista o grande número de dúvidas(aqui no fórum e também no nosso canal do Discord) sobre como configurar os PSPs no componente ACBrPIXCD, estou criando esse tópico para auxiliar nesse procedimento. Irei utilizar como base nosso demo do componente, que está disponível no SVN, em: "...\trunk2\Exemplos\ACBrPIXCD\". 1. Configurando Recebedor e PSP Atual 1.1. Configurações utilizando o componente Para configurar o Recebedor e o PSP atual, utilizando o próprio componente ACBrPIXCD, preencha as seguintes propriedades: ACBrPixCD1.Recebedor.Nome := ''; ACBrPixCD1.Recebedor.CEP := ''; ACBrPixCD1.Recebedor.Cidade := ''; ACBrPixCD1.Recebedor.UF := ''; ACBrPixCD1.PSP := ; ACBrPixCD1.Ambiente := ; Além dessas configurações básicas, também é possível configurar o caminho do arquivo de log, o nível do log gerado e, caso sua rede utilize proxy, será necessário configurá-lo nas propriedades a seguir: ACBrPixCD1.Proxy.Host := ''; ACBrPixCD1.Proxy.Port := ''; ACBrPixCD1.Proxy.User := ''; ACBrPixCD1.Proxy.Pass := ''; ACBrPixCD1.ArqLOG := ''; ACBrPixCD1.NivelLog := 0; Obs: Níveis de log: 0 - Nenhum 1 - Baixo 2 - Normal 3 - Alto 4 - Muito Alto 1.2. Configurações utilizando o aplicativo de demonstração Na aba "Configurações > PIX" preencha os dados solicitados e selecione o PSP que irá utilizar, conforme imagem abaixo: 2. Solicitando as credenciais do PSP Esse procedimento é feito de diferentes formas para cada PSP. Selecione o PSP desejado:
    19 pontos
  40. Olá pessoal... É com muita satisfação, que convidamos todos vocês, usuários e entusiastas do Projeto ACBr, para ingressar no nosso Servidor no Discord O que é o Discord ? Basicamente, o Discord, é uma Ferramenta para Chats, omnichannel, ou seja, você pode acessá-lo do Navegador, Windows, Mac, Android, IPhone, etc... Ele é muito utilizado na comunidade de Gamers, por sua facilidade em integrar equipes, com recursos de comunicação por Texto, Voz e Transmissão de Telas... sendo realmente muito fácil de usar... Você pode saber mais sobre ele em: https://discord.com/ Como eu ingresso ? Muito simples.. clique nesse Link de Convite , para o nosso Servidor Se ainda não tiver... você precisará criar uma Conta no Discord... o que é rápido e gratuito... Como usar o Discord ? Quando você ingressar no nosso Servidor, será convidado a conhecer e concordar com as Regras de uso e boa etiqueta do Servidor... e depois disso, direcionado para o Canal #novos-membros... onde o nosso primeiro Bot (MEE6 ACBr), lhe dará as boas vindas... Pronto.. Fique livre para navegar e postar nos nossos canais abertos... Fique por dentro das novidades... Nossos Bots replicam no canal #anúncios-e-notícias vários vídeos e Tweets, de interesse aos Desenvolvedores de Automação Comercial... No canal #anúncios-commit, você pode ficar por dentro de tudo que está sendo enviado para o repositório de Fontes do Projeto ACBr (SVN) Porque adotamos o Discord ? Como nossos assinantes do ACBr Pro devem saber, usávamos uma outra ferramenta de Chat, chamada Flock (leia mais aqui)... Ocorre que a empresa produtora do Flock, simplesmente mudou a regra do Jogo, e resolveu nos tarifar por todos os usuários Convidados (Guests).. o que tornou o Flock totalmente inviável para nós... Bom.. não gostamos do ocorrido, mas percebemos que isso poderia ser uma ótima oportunidade de mudança e Crescimento.... Testamos e pesquisamos algumas outras ferramentas de Chat, como: Slack: https://slack.com/intl/pt-br/ Muito bacana, e muito usado no mundo corporativo... O Flock que usávamos, tenta ser um clone do Slack, então essa foi nossa primeira tentativa... Porém o Slack possui muitos recursos bloqueados na versão Free, e a versão Pro é cara demais.. Rocket Chat: https://rocket.chat/pt-br/ Uma Ferramenta Open Source, com características que competem a nível de igualdade ao Slack, e com opção de Hosting próprio... Fantástico, ficamos muito divididos... mas notamos que seria bastante trabalhoso, configurar o Rocket Chat... e nossos custos com Hosting poderiam crescer rapidamente, devido o tamanho da comunidade do Projeto ACBr Discord: https://discord.com/ No Discord, nos sentimos em casa... a maioria dos Devs do ACBr, já usa e admira o Discord (pra Games, é claaro)... Com a ajuda desse excelente artigo e outros, conseguimos configurar o Discord com uma cara mais "empresarial", organizando-o em vários Grupos e Canais de texto e voz O Discord é capaz de suportar grandes comunidades como a do Projeto ACBr... e tem uma infinidade de Bots e integrações, que nos deixou extremamente empolgados... O Discord do Projeto ACBr, será aberto a todos ? Parte dele Sim.. Temos dois Grupos de Canais ACBr Comunidade e ACBr Pro... O grupo ACBr Comunidade sempre será totalmente aberto ACBr Comunidade ACBr Pro E como fica o suporte do Chat do ACBr Pro ? Melhor do que nunca... Estamos levando o ACBr Pro muito a sério, e desejamos uma interação mais direta e rápida, com nossos usuários desse seleto grupo... A assinatura do ACBr Pro, é válida por um ano, e compreendemos que as empresas/assinantes que fazem parte desse Plano, estão realmente comprometidas com os ideais e objetivos, que mantém vivo o Projeto ACBr. Então, nossos desenvolvedores e consultores estarão sempre atentos aos questionamentos dos Usuários nos Canais no Grupo exclusivo do ACBr Pro, onde monitoramos as perguntas, e faremos o máximo esforço possível, para responde-las o quanto antes... Estamos ainda, criando Bots, para facilitar você encontrar artigos e vídeos, em nossa extensa base de conhecimentos desse Fórum e do nosso canal no Youtube
    19 pontos
  41. 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:
    19 pontos
  42. Porque devo assinar digitalmente meus executáveis ? O Produto final de quase todo desenvolvedor de Software para Windows, é gerar um arquivo compilado e executável, ou seja, um arquivo com a extensão .EXE ou .DLL As versões recentes do Windows, incorporaram recursos de segurança, como o SmartScreen, que podem causar alertas quando Binários não assinados são executados... O mesmo pode ocorre com módulos de Segurança de terceiros, instalados na máquina, como por exemplo: Antivírus e módulos de segurança bancários... Para evitar mensagens assustadoras, como a exibida abaixo, é necessário Assinar digitalmente o seu binário, com um certificado emitido por uma Autoridade Certificadora válida A título de exemplo, todos os binários distribuídos pelo Projeto ACBr, na área de Download do SAC ACBr, são assinados digitalmente com um certificado do Projeto ACBr... Reparem que não somente o Executável final, mas o instalador, também deve ser assinado.. Abaixo, temos a imagem de quando é executamos o Instalador do ACBrMonitorPLUS SAC Bem melhor, não ? Repare que o Fornecedor do binário, fica bem identificado na mensagem... Isso além de trazer mais confiança para o usuário final, ajuda os programas de segurança, a classificar de forma positiva, o seu Executável ou instalador, evitando bloqueios indevidos. Ok, gostei... mas como fazer para assinar meus executáveis ? O primeiro passo é comprar um Certificado do tipo "Code Signing"... Garanto que agora você pensou algo como: - Humm.. será que posso usar o meu certificado A1 ou A3 ? A resposta é NÃO... os certificados que usamos para os Documentos Fiscais eletrônicos brasileiros, não tem as características esperadas pelo Windows, para assinatura e validação de binários... Quanto aos certificados gerados de forma local, ou seja, os Self-Signed Certificates, eles funcionarão para a assinatura... e podem ser ótimos para testes... Mas eles não devem garantir o nível de confiabilidade ao seu binário, pois eles não são gerados por uma Autoridade Certificadora válida Algumas empresas Brasileiras, vendem o certificado do tipo Code Signing.. Veja por exemplo esse link... Porém o preço é praticamente "o valor de um Rim esquerdo"... (ps: veja mais empresas brasileiras, no post a seguir) Você pode comprar o Certificado do Tipo OV, que é bem mais barato... Na página da KSoftware tem um interessante artigo, descrevendo a diferença da versão OV x EV Eu preferi comprar nesse site gringo, porém isso pode exigir que você tenha um bom conhecimento de Inglês, pois o todo o processo de compra será feito em Inglês. Esse certificado, também exige um processo de validação... ou seja, a Empresa que irá emitir o certificado, precisa saber se você é você mesmo... A validação foi feita pela empresa Sectigo... eles enviam e-mails com links para você subir a documentação necessária... Como o certificado será emitido para uma Entidade Pessoa Jurídica, na etapa de envio de documentos de prova de identidade... eu enviei um PDF com o resultado da consulta de meu CNPJ, na Receita... Na etapa final de validação, eles efetuam uma ligação para o telefone de sua empresa, para fornecer um Token, que deve ser usado para gerar o certificado... portanto, o número de telefone na documentação que você enviar, deve ser um número que você possa atender... Achei o Site de Validação da Sectigo, bastante confuso... Eu preferi comprar a opção de 4 anos, para evitar esse penoso processo de compra, e pelos descontos oferecidos... Após todas as validações de identidade, eles lhe enviarão um Link para baixar o certificado em sua máquina... Será criado um arquivo PFX, e o processo de geração do Certificado na sua máquina, é muito semelhante a dos Certificados A1 brasileiros... Ufa.. já tenho o meu certificado em PFX... Como eu assino os binários ? Existem algumas ferramentas disponíveis... na página da KSoftware, você pode ler um tutorial, de como assinar usando o KSign Você poderá assinar binários facilmente, usando a interface gráfica deles: Para automatizar o processo de assinatura, você provavelmente ira preferir usar um utilitário de Linha de Comando... Repare que na mesma pasta onde o KSign foi instalado, existe o utilitário signtool.exe Use esse utilitário com a seguinte sintaxe: signtool.exe sign /du "http://seusite.com.br" /d "Descrição do seu Programa" /f "C:\Path\SeuCertificado.PFX" /p SenhaCertififcado /t "http://timestamp.comodoca.com" SeuBinario.exe sign -> Comando para assinatura /du -> Informa a URL do seu Site /d -> Informa uma descrição resumida do seu Programa /f -> Informa o Path completo para o seu Certificado (arquivo PFX) /p -> Informa a Senha para abertura do seu Certificado /t -> Informa um Servidor de Time Stamp, para que fique gravada a Data / Hora da assinatura Mas como assinar um Binário Windows, de dentro do Linux ?? Todo processo de Build e Deploy dos binários do ACBr, é executado em um Linux OpenSuse. A compilação de todas as plataformas que suportamos ocorre com Cross-Compiling, e automatizamos o processo de Build e Deploy, com o uso de Jenkins e Shell Scripts, Para transmitir o binário para fórum, criamos alguns utilitários que consomem a API do Invision Power Board Para a assinatura dos binários, creio que seria possível usar o próprio signtool.exe, com Wine... mas encontramos um interessante utilitário nativo em Linux, chamado osslsigncode, repare que a sintaxe é muito semelhante a do signtool.exe... osslsigncode sign -pkcs12 /path/SeuCertificado.pfx -pass SuaSenha -n "Descrição do seu Programa" -i http://seusite.com.br -t http://timestamp.comodoca.com -in SeuBinario.exe -out SeuBinario.exe.sign (como passo final, apague o arquivo original, SeuBinario.exe e renomeie SeuBinario.exe.sign para SeuBinario.exe)
    19 pontos
  43. Bom dia a todos, Alguns desenvolvedores relataram problemas com os eventos, mais precisamente aqueles que carregam o XML do evento gerado pelas suas próprias aplicações. Detectamos que a SEFAZ sem querer querendo, resolveu utilizar códigos para novos eventos, códigos estes usados por outros eventos de outros tipos de Documentos Fiscais Eletrônicos. Como exemplo o código do evento Cancelamento por Substituição da NFC-e é o mesmo do evento de Encerramento do MDF-e. A função que converte o código em um enumerador acaba pegando o primeiro que ela encontra na lista, retornando um enumerador que não tem nada haver. A solução encontrada foi criar uma função de conversão para cada tipo de Documento Fiscal Eletrônico. Antes tínhamos a função StrToTpEvento, agora temos: StrToTpEventoNFe, StrToTpEventoCTe, StrToTpEventoMDFe e StrToTpEventoBPe. A função original: StrToTpEvento foi renomeada para StrToTpEvento_Old, função esta que não devemos mais utilizar pelo problema descrito acima. Pelo fato dela ter sido renomeada, quem a utiliza diretamente em alguma unit com certeza vai ocorrer erro de compilação. Para resolver esse problema, basta trocar o nome da função para a correspondente e se necessário incluir no uses uma das seguintes units: pcnConversaoNFe ou pcteConversaoCTe ou pmdfeConversaoMDFe ou pcnConversaoBPe. Observação: isso se você utiliza a função StrToTpEvento em alguma unit da sua aplicação, caso contrario não precisa se preocupar. Outra alteração que foi feita e que pode provocar uma exceção durante a execução da sua aplicação diz respeito ao código do documento fiscal. Desde o inicio nos manuais o ENCAT nos orienta a atribuir ao código do documento fiscal um numero aleatório, mas tem muitos desenvolvedores que simplesmente atribui o mesmo numero do documento fiscal. Exemplo da NF-e: O código do documento fiscais é o campo cNF que acaba recebendo o mesmo valor do numero do documento fiscal que é o campo nNF. Foi publicado a Nota Técnica 2019/001 que esta em anexo, nela temos a regra B03-10 que vai passar a comparar esses dois campos (cNF e nNF). A data de inicio dessa validação nas SEFAZ é: 01/07/2019 - Ambiente de Homologação e 02/09/2019 - Ambiente de Produção. A principio essa regra é valida somente para a NF-e e NFC-e, mas com certeza vai se estender para os demais tipos de documentos fiscais eletrônicos. Logo resolvemos incluir na função que gera a chave do documento a mesma validação a ser executada na SEFAZ, desta forma se os valores informados nos campos referente ao código e numero passarem pelo nosso validador, com certeza a sua nota não vai ser rejeitada na SEFAZ, quando essa regra for ativada. Vale lembrar que a regra B03-10 será obrigatória em todas as UF. Lembre-se, ao tentar emitir uma nota se aparecer a seguinte mensagem: Código Numérico inválido, Chave não Gerada, isso significa que o numero informado como código é exatamente igual ao numero do documento fiscal, no caso da NF-e /NFC-e (cNF = nNF). O valor de nNF tem que ser um numero sequencial. O valor de cNF tem que ser um numero aleatório. Na unit ACBrDFeUtil, criamos a função abaixo: function GerarCodigoDFe(AnDF: Integer): integer; Nela passamos como parâmetro o numero do documento fiscal, ou seja, o numero da nota (por exemplo) e ela gera aletoriamente e retorna o código para ser atribuído ao campo código (cNF, se tratando da NFe/NFCe). Essa função além de gerar o código aleatoriamente conforme orientação do ENCAT já valida conforme a regra B03-10. Observação: a função que gera a chave é utilizada pelos componentes: ACBrNFe, ACBrCTe, ACBrMDFe e ACBrBPe, logo a função que gera o código pode ser utilizada pelos desenvolvedores de qualquer um desses tipos de documentos fiscais. Prevenir é melhor do que remediar. NT2019_001 v1.00 - Regras de Validacao.pdf
    19 pontos
  44. Olá pessoal, Com a NT 2018.005 foi introduzida uma nova rejeição para NFe: 938 - Rejeição: Não informada vBCSTRet, pST, vICMSSubstituto e vICMSSTRet. Os detalhes dessa rejeição foram alterados nas várias versões da NT, mas infelizmente isso já está causando algum problema (como podem ver nesse tópico aqui). Como é uma rejeição facultativa e cada UF tem uma legislação, tivemos que adicionar uma nova propriedade no componente ACBrNFe para lidar com a situação. A nova propriedade se chama ForcarGerarTagRejeicao938. Após atualizar os componentes, não esqueça de reinstalar. Vamos a uma explicação mais longa... O problema Como a descrição da rejeição explica, algumas UFs podem exigir a informação de algumas tags, como vICMSSubsituto, isso mesmo quando o valor da tag for zero. Por padrão o ACBrNFe não gera tags facultativas que são informadas com valor zero. E esse é o caso da tag vICMSSubstituto. Mas como essa é uma tag facultativa, não devia ser obrigatório para algumas UFs informá-la. E por isso, não podemos obrigar o ACBrNFe informar sempre. Assim a ideia é termos uma configuração que você possa alterar. Poderemos com essa propriedade forçar gerar a tag de acordo com a necessidade de seu cliente ou da UF dele. A solução A propriedade (ou configuração) criada ForcarGerarTagRejeicao938 foi adicionada no ACBrNFe de modo que pode ser acessada como no código abaixo: ACBrNFe1.Configuracoes.Geral.ForcarGerarTagRejeicao938:= fgtNunca; Ou talvez no Object Inspector como abaixo: Importante: Embora a propriedade esteja disponível para ser alterada no Object Inspector, você provavelmente vai querer parametrizar isso no seu aplicativo. Afinal, talvez você precise alterar essa propriedade de um cliente para outro, ou de uma data para outra. As opções são: fgtNunca -> Se o valor for zero, não vai forçar a geração da tag nunca; fgtSomenteProducao -> Força a tag ser gerada no ambiente de produção mesmo que o valor seja zero; fgtSomenteHomologacao -> Força a tag ser gerada no ambiente de homologação mesmo que o valor seja zero; fgtSempre -> mesmo que o valor seja zero, a tag será gerada sempre; A configuração padrão é fgtNunca conforme o comportamento do componente antes dessas alterações. Qual opção eu devo escolher? Como explicado, essa configuração foi necessária por causa de problemas em certas UFs. Então para escolher a melhor opção você precisa saber o que está sendo exigido no Webservice que você está acessando. Por exemplo, se você não está recebendo a rejeição, não há necessidade de alterar a configuração. Mas se está recebendo somente em homologação, quer dizer, a tag está sendo exigida somente em homologação, use a opção fgtSomenteHomologacao. E assim por diante.
    19 pontos
  45. Altere essas configurações no internet explorer
    19 pontos
  46. Lembrei disso hoje... e decidi procurar se o Post n.1 ainda existe... SIM, ele ainda está no Fórum da DevMedia, o qual eu frequentei por um bom tempo, e foi o espírito de cooperação dos usuários do fórum, que me motivou a criação do Projeto ACBr... Reparem no Post, que ainda não há menção do nome ACBr, e a ideia inicial, era fazer uma classe de Suportes a ECF (Emissor de Cupom Fiscal)... https://www.devmedia.com.br/forum/classe-para-acesso-direto-a-ecf-em-linux-windows/229474 Na abertura do último Dia do ACBr, eu menciono um pouco sobre a criação do Projeto... Classe para acesso Direto a ECF em Linux/Windows 03/05/2004 Ola, para todos.... Estou desenvolvendo uma Classe Multiplataforma para acesso direto a diversas Impressoras Fiscais. Na verdade o projeto ainda está engatinhando, mas já tive sucesso em Comunicação com a Bematech em Windows e Linux. Entretanto, como muitos programadores também necessitam ou já fazem acesso a ECF, resolvi usar a ideia de tornar isso um projeto OpenSource. P1 - Porque fazer mais uma biblioteca de acesso a ECF ? A ideia é fazer uma Classe que possa rodar em Linux / Windows. algo que nao existe hoje.... Alem de não exigir nenhuma DLL ou SO, a fim de evitar o ´inferno das DLL´s´ P2 - Como fazer acesso aos ECFs ? Como a classe deve rodar em Linux, fica descartado o uso de DLL´s... Todas as impressoras fiscais (pelo menos as que já programei) possuem manuais descrevendo os codigos de comandos e protocolos seriais. Atualmente acesso as impressoras: Bematech, Daruma, Schalter, Sweda, Mecaf (e compativeis) de forma direta, em DOS, usando a linguagem CLIPPER 5.02e.+Clipper Tools... O Executável não depende de nenhum arquivo externo ou device driver no CONFIG.SYS. A ideia é migrar as funçoes de Clipper para Delphi, usando um componente de acesso a Serial. P3 - Qual componente fará acesso a serial ? Dos que testei, apenas a classe SynaSer http://www.ararat.cz/synapse/ é multiplataforma (Kylix) P4 - Porque rodar em Linux ? Já pensou oferecer para os seus clientes uma solução de Aplicacação Comercial totalmente legalizada ? e sem pagar uma fortuna por isso ? Sem falar na estabilidade e segurança do Linux.... Qual usuário consegue apagar o sistema ? (alem do Root é claro Caracteristicas do projeto: - Deve ser OpenSource e com a distribuição dos fontes: - Deve ser Multi-plataforma (Windows ( CLX / VCL ) / Linux) - Nao deve depender de nehuma DLL ou SO. - Deve suportar as diferença entre os diversos modelos de ECF - As Classes Filhas devem tratar de forma transparente as pequenas diferenças na programaçao de Versoes diferente do mesmo Modelo de ECF. Ex: A classe TECFBematech deve ser capaz de trabalhar com todas as versoes da Bematech FI Vantagens do Projeto: - Total controle da Aplicação: Já vi DLL´s que simplesmente param o processamento do programa (Quem já homologou TEF discado, sabe o que eu quero dizer...) - Facil distribuição: Não precisa distribuir e instalar nenhuma DLL - Livre-se do Inferno das DLL´s Quando o usuário instala outro programa que usa a mesma DLL que você usa, porém em uma versão antiga (causando Bugs no seu programa) - Multiplataforma: Linux / Windows - Programação Limpa e Clara. Basta criar uma classe TECF com o modelo apropriado. O Codigo fonte sempre se refere a Classe criada, sem se preocupar com o Modelo Desvantagens do Projeto: - Se o hardware mudar, ficamos dependendo de novas informaçoes do fabricante, ou até mesmo de um modelo do equipamento para testes... - Geralmente as DLL´s incorporam novos Hardwares do mesmo fabricante.... Aqui teremos que implementar um novo filho da classe TECF para cada Hardware novo (somente se o novo hardware nao for compativel com o antigo) Estou lançando a ideia para ver a aceitação... Existe algum disposto a colaborar ? Posso enviar os fontes por e-mail para que estiver interessado... Em breve farei uma pagina para download do projeto... (Ou se alguem estiver disposto a fazer... ) A ser desenvolvido: - Terminar a implementação da Classe TECFBematech - Implementar as demais Classes (Daruma, Schalter, Sweda, Mecaf) - Criar Classe para Manupilação de TEF Discado para interagir com TECF Na verdade, nunca fiz nenhum projeto OpenSource... Gostaria de sugestões... Duvidas: - Como / Onde hospedar o projeto ? - Como cordernar ?.... - Como fica a questão legal de OpenSource ? É preciso registrar isso em cartório ? Ps: Srs Moderadores, desculpe postar essa msg em 2 áreas, mas acredito que seja do interesse...
    18 pontos
  47. Olá, Recentemente diversas empresas estão emitindo boletos com QrCode para pagamento via PIX (Boleto Híbrido), ficando a critério do pagador escolher a forma de pagamento através da ficha de compensação "Código de Barras / Linha Digitável' ou com o PIX "QRCode". Mas até então isso não estava formalizado pelo Banco em si, ou seja, o controle de Baixa do título caso seja pago por PIX ficaria a cargo da própria empresa, como ocorre no fluxo de várias API hoje disponíveis no mercado... Porém, o Banco do Brasil foi o pioneiro em disponibilizar esse tipo de integração em sua própria API, assim ao registrar um Título pode ser definido se será gerado também uma chave PIX dinâmica referente aquele título, com isso o controle da forma de pagamento fica com o Banco, independente se for pago via PIX ou Boleto. Isso facilita muito o controle por parte da empresa beneficiária e viabilizou a implementação desse tipo de integração via API também no componente ACBrBoleto. No componente ACBrBoleto já existia a possibilidade de Registro Online de Boletos para alguns Bancos, inclusive o Banco do Brasil via WebService, mas essa API se trata de um novo Serviço, portanto são configurações e funcionalidades distintas no componente ACBrBoleto. Neste tópico vamos descrever como realizar a homologação e utilizar a API do Banco do Brasil através do componente ACBrBoleto. 1- Primeiro passo é realizar o Cadastro do seu Aplicativo no ambiente Sandbox BB, com isso será fornecido as credenciais para autenticação da API em ambiente de homologação. Utilize o Serviço API Cobrança: https://developers.bb.com.br/home Documentação da API e como utilizar o ambiente Sandbox para cadastrar a aplicação: https://apoio.developers.bb.com.br/referency/post/5ffc477c3b02bd0012ecaa1a 2- Após o Cadastro poderá obter o ClientID e ClientSecret que precisará configurar no componente ACBrBoleto, cada emitente terá seu próprio ClientID e ClientSecret. No componente ACBrBoleto configure em: Banco / TipoCobranca=cobBancoBrasilAPI No componente ACBrBoleto configure em: Cedente / CedenteWS ClientID=Informe o ClientID gerado no Ambiente Sandbox BB ClientSecret=Informe o ClientSecret gerado no Ambiente Sandbox BB Scope=cobrancas.boletos-info cobrancas.boletos-requisicao KeyUser=developer_application_key IndicadorPix=True //Para utilização do PIX pela API - Banco do Brasil é necessário que o emitente tenha chave PIX cadastrada no BB, caso for utilizar somente a emissão tradicional pela API enviar False nesse parâmetro. Em Configurações / WebService - Configure da seguinte Forma: Na opção de Ambiente escolher de acordo com a operação que esteja fazendo (Homologação ou Produção) necessário coerência com as chaves contratuais junto ao BB. As operações homologadas para a API BB são de Inclusão e Consulta [tpInclui, tpConsulta, tpBaixa, tpAltera] SSLHttpLib utilizar cryOpenSSL SSLType utilizar LT_TLSv1_2 3 - Com essas configurações já é possível realizar o registro de um título no BB via API. O Título deve ser incluso normalmente como no processo tradicional do componente, mas ao invés de gerar uma remessa, utiliza-se o o método "EnviarBoleto" - (botão no Aplicativo ACBrBoleto Demo: [Registrar Boleto On-Line]) . Este botão possui exemplos de como obter o Retorno da API. Se o título foi registrado sem nenhuma rejeição, automaticamente será atualizado a chave PIX junto ao Título. Particularidades BB via API: obs: API possui envio Síncrono Carteira=17 EspecieDoc=DM Modalidade=35 CodigoCedente=Informar Código Cedente Convenio=Informar o Convenio 4- Para imprimir o Boleto: Obs: Quando utilizado PIX, é necessário que além das informações tradicionais, sejam informadas no título o retorno do registro "QrCode" na propriedade "EMV", esse campo corresponde a String de geração do QRCode PIX gerada pelo Banco. ex: Titulo.qrcode.emv := FRetornoConteudoEMV; Impressão em FortesReport: Utilize o Layout "PadraoPIX" Impressão em FastReport: Selecione o arquivo "BoletoPIX.fr3" no diretório "Report" junto ao ACBrBoleto Demo. Segue o Modelo de Boleto Híbrido Impresso: 5- Consulta de Títulos via API Na aplicação ACBrBoletoDemo temos o botão "Consultar Boleto" com código exemplo de como passar os parâmetros para realizar uma consulta na API, o retorno será gerado em uma lista para posterior validação de cada Título. Obs: A homologação deve ser feita também junto ao Banco, inclusive enviando os modelos das Fichas de Compensação emitidas para validação. Todos os testes foram realizados em ambiente de homologação, então é importante a validação completa antes de emitir em ambiente de produção.
    18 pontos
  48. 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.
    18 pontos
  49. Pessoal já esta disponivel a versão das biblioteca ACBr com suporte a multithread. Inicialmente as dll da ACBrLib foram planejadas para serem simples e de facil uso, mas com o passar do tempo foi percebido que alguns usuário precisavam de algum suporte extra, principalmente para que quer usar as lib para API web. Por isso fizemos esta versão nova das bibliotecas visando atender melhor este tipo de ambiente, com este lançamento já possivel usar as bibliotecas em ambientes multithreads ou se necessario ter 2 instancias da lib com configurações distintas. As vantagens e desvantagens você ve abaixo. Pros Múltiplas instancias da lib, pode ter 2 libs carregada simultaneamente com configurações diferentes. Pode ser usada em thread separada da principal, facilitando assim seu uso em serviços. Contras Precisa que seja usado um ponteiro para controlar a instancia da lib Precisa sempre passar o ponteiro da instancia para executar um metodo. Não iremos descontinuar a versão single thread que já usa assim e te atende bem pode continuar usando, agora quem precisa de multithread pode agora utilizar esta nova versão. Para quem baixa do site basta usar as dll que estão na pasta MT e atualizar sua classe com os novos parâmetros ou se usar as classes disponibilizadas pelo projeto basta atualizar elas para sua variante MT. Para quem compila dos fontes vai ver que tem novos modos de compilação terminados com MT basta compilar com este modo. É recomendado a uso na lib com MT caso você tenha as seguintes necessidades. Precisa imprimir de forma simultanea o pedido na cozinha e no balcão. Tem uma API concentrada de envio de NFe e/ou Boleto que usa varias empresas e de forma simultâneas. Exemplo de alteração das chamadas para usar a versão MT. Os demos também foram atualizados para funcionar com a versão multithread basta utilizar os demos com MT no nome Ainda temos mais modificações para atender melhor vocês, fiquem ligados nas próximas novidades da ACBrLib.
    18 pontos
  50. Sempre acreditei que a informação deve ser algo democrático e acessível... Pensando nisso, tornei pública a nossa área de Base de Conhecimentos Nela você encontrará excelentes artigos, escritos pelos nossos experientes Consultores, e que tornarão o uso dos os componentes ACBr algo mais simples e funcional... Espero que gostem... e fiquem a vontade para sugerir novos artigos...
    18 pontos
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.