Jump to content

110.png

Curso Gratuito para todos Usuários
+ Super Treinamento Assinando o SAC Anual

botao_campanha_thulio.png

sem_ttulo-620.fw_-e1583866078274.png 

Curso Dominando o ACBrMonitor
Novo Módulo Soluções de Varejo
Assine o SAC ACBr em qualquer plano e tenha acesso

Saiba Mais

Balança SM100 performance surpreendente

Tecnologia Japonesa   Teclado e Visor resistentes a água
Consumo inteligente de etiquetas   Baixo custo de manutenção
Comunicação Ethernet e WIFI independentes

Saiba Mais

Impressora de Etiquetas ELGIN - L42 PRO

Protocolos PPLA, PPLB, ZPL, EPL (automático)
Porta USB padrão Opcionais: Ethernet, Serial, Paralela
Sensor de Etiquetas Móvel Garantia de 18 meses

Saiba mais

Leaderboard


Popular Content

Showing content with the highest reputation since 12/07/2012 in Posts

  1. 93 points
    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
  2. 50 points
    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.
  3. 42 points
    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.
  4. 40 points
    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.
  5. 37 points
    É 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.
  6. 31 points
    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
  7. 31 points
    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
  8. 30 points
    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/
  9. 25 points
    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
  10. 25 points
    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"
  11. 24 points
    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".
  12. 23 points
    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.
  13. 22 points
    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
  14. 21 points
    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.
  15. 21 points
    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.
  16. 20 points
    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
  17. 20 points
    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.
  18. 20 points
    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/
  19. 20 points
    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. 20 points
    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!
  21. 19 points
    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:
  22. 19 points
    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:
  23. 19 points
    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
  24. 19 points
    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. 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.
  25. 19 points
    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" não é simplesmente o 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. O ACBr (seja o monitor, lib ou algum componente) nesse processo é apenas uma ferramenta. É como se fosse 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. 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. 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. Ele é 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.
  26. 19 points
    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.
  27. 19 points
    Altere essas configurações no internet explorer
  28. 18 points
    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.
  29. 18 points
    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...
  30. 17 points
    Olá Pessoal, A SEFAZ-RS resolveu antecipar a liberação do ambiente de homologação. 02/03/2020 Implantada NT 2020.001 em Homologação Informamos que a NT 2020.001 que trata do MDF-e Integrado, encontra-se implantada no ambiente de homologação da SVRS. As regras de validação restritivas 725 e 726 deverão ser ativadas na próxima semana. Quero lembra-los que o componente ACBrMDFe já contempla todas as alterações publicadas na NT 2020/001, o programa exemplo foi alterado para exemplificar os novos campos, grupos bem como o novo evento. Os novos Schemas já estão disponíveis a um bom tempo. Na próxima versão do ACBrMonitor já vai estar disponível a atualização do manual do mesmo que mostra como gerar o arquivo INI do MDF-e com os novos campos e grupos, bem como gerar o arquivo INI do novo evento.
  31. 17 points
    Olá pessoal! Temos o prazer de informar que mais um novo componente foi adicionado ao projeto: ACBrLCDPR. O ACBrLCDPR foi criado para facilitar a geração do LCDPR - Livro Caixa Digital do Produtor Rural. Esse componente segue a mesma ideia de outros componentes para geração de arquivos como ACBrSPEDFiscal, ACBrSPEDPISCOFINS, ACBrSEF2, etc... Com ele você pode gerar o arquivo sem se preocupar com o layout do arquivo. A sua preocupação será apenas com as informações que precisa aprensentar. Como é um componente novo, temos consciência de que alguns ajustes talvez sejam necessários. Todos podem ficar à vontade reportar problemas. Podem fazer isso por criar um novo tópico com ajustes e anexar nele. Crie o tópico no subfórum ACBrTXT -> Outros (ACBrLFD, ACBrSEF2, etc). Mas queremos agradecer ao @Willian Hübner que pôs a mão na massa e fez a doação do componente que serviu como base dessa versão. Queremos também aproveitar a oportunidade para agradecer aos nossos usuários SAC. Seu apoio nos ajuda a continuar avançando.
  32. 17 points
    Bom dia pessoal. Como todos sabem, na maioria das vezes em que o windows se atualiza ele marca aquelas opções de certificados revogados em "Opções da internet > Avançado" e, pelo menos comigo, gera uma grande quantidade de suporte à clientes. O correto é ficar assim: ( ) Usar SSL 2.0 (x) Usar SSL 3.0 (x) Usar TSL 1.0 ( ) Usar TSL 1.1 ( ) Usar TSL 1.2 ( ) Verificar revogação de certificados servidor* (x) verificar se ha assinaturas em programas baixados ( ) Verificar se há revogação de certificados do editor Então no final do ano passado até cheguei a comentar em um tópico se teria como modificar esses dados diretamente pelo delphi, pra facilitar nossa vida, mas não tinha ninguém com essa informação. Pois bem, essa semana tive um tempinho e comecei a mexer com isso e creio que encontrei uma solução, segue abaixo programação para alterar o registro do windows com as opções corretas. Já testado em alguns clientes e até o momento funcionando perfeitamente. (Testado em windows XP, 7, 2003 server) uses Registry; procedure TFPrincipal.FormCreate(Sender: TObject); var Registro: TRegistry; begin //acertando opções da internet (revogados / SSL / TSL) //verificar revogação de certificados do servidor Registro := TRegistry.Create(KEY_WRITE); Registro.RootKey := HKEY_CURRENT_USER; if registro.OpenKey('Software\Microsoft\Windows\CurrentVersion\Internet Settings', true) then begin Registro.WriteInteger('CertificateRevocation', 0); end; registro.CloseKey; //verificar se há certificados revogados do fornecedor if registro.OpenKey('Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing', true) then begin Registro.WriteInteger('State', 146944); end; registro.CloseKey; //Usar SSL 3.0 / Usar TSL 1.0 if registro.OpenKey('Software\Microsoft\Windows\CurrentVersion\Internet Settings', true) then begin Registro.WriteInteger('SecureProtocols', 160); end; registro.CloseKey; registro.Free; end; Espero ajudar o pessoal do ACBr com essa contribuição. Um abraço a todos.
  33. 17 points
    Recentemente recebemos uma Impressora Não Fiscal Bematech MP-100S TH e após diversos testes utilizando nos exemplos do ACBr temos alguns comentários sobre a mesma. Todos os Drivers 32 Bits ou 64 Bits e o Manual da Bematech MP-100S TH podem ser encontrados em: http://www.bematech.com.br/suporte/equipamento/mp-100s-th Sobre a instalação da Bematech MP-100S TH: Foi utilizada a impressora em uma máquina com Windows 10 e nessa máquina, não foi necessário realizar instalação de driver do fabricante, apenas conectando a impressora (já ligada e com papel) e a mesma já emulou uma porta COM automaticamente, ficando assim, pronta para uso com ACBrPOSPrinter. Obs: Caso seja necessário realizar a instalação do Driver USB, o mesmo poderá ser encontrado no site do fabricante, mencionado anteriormente. Para realizar o uso da impressora com Fortes Report, foi necessário primeiramente instalar a Bematech no Windows, utilizando o Driver "BematechSpoolerDrivers", disponível no site do fabricante. Após instalada a impressora no Windows, foi necessário alterar o tipo de formulário disponível em Iniciar > Dipositivos e Impressoras > Selecionado impressora MP-100S TH > Clique com botão direito do mouse e selecionado "Propriedades da Impressora" > aba "Configurações do dispositivo" > Atribuição de Formulário a Bandeja > Selecionado opção "Print width 80mm 30cm" > OK. Sobre a utilização da MP-100S TH: Como já citado anteriormente, os testes foram realizados utilizando os exemplos do ACBr. Para o testes utilizando o componente ACBrPOSPrinter foi utilizado o Demo PosPrinterTeste.exe e para os testes utilizando o Fortes Report, foi utilizado o Demo SATTeste.exe. Testes Demo PosPrinterTeste.exe configurado com modelo ppEscBematech, 48 colunas, e página de código pc850 - A impressão de Tags de Caracter funcionou corretamente, com exceção da Fonte Invertida. OBS: não foi localizado nenhuma informação sobre compatibilidade com a Fonte Invertida no Manual do equipamento. - A impressão de Tags de Alinhamento, Tags Inválidas e Tags de Página de código funcionaram corretamente. - Para as tags de Código de Barras, os códigos STD25, CODE11 e MSI não foram impressos, já os demais imprimiram corretamente e a leitura dos mesmos foi efetuada normalmente também. OBS: o código MSI no aplicativo do fabricante foi impresso corretamente. Os códigos STD25 e CODE11 não aparecem na lista do aplicativo do fabricante e na lista de códigos compatíveis do manual. - As tags de QR Code foram impressas corretamente e a leitura foi efetuada corretamente. - A tag de impressão de logotipo foi impresso corretamente (após ter configurado logotipo pelo aplicativo do fabricante). - A impressão é realizada rapidamente, porém, não possui o corte automático. Testes Demo SATTeste.exe configurado com Largura: 296, Margens - Topo: 2, Rodapé: 20, Esquerda: 0 e Direita: 5 - As impressões realizadas durante esses testes foram cupons de venda com emulador de SAT, onde possui logo, fonte negrito e normal, código de barras, QR Code, caracteres com acentos, quebra de linha e todos os detalhes mencionados foram impressos corretamente. - A impressão é realizada rapidamente. Comparativo MP-100S TH X MP-4200 TH: - Em ambos os modelos a impressão é realizada rapidamente, o tempo de impressão pode ser considerado igual para ambas, pois a diferença encontra-se na MP-4200, que é alguns milésimos de segundos mais rápida. - Em ambos os modelos a Fonte Invertida e os códigos de barras STD25, CODE11 e MSI não são impressos. - Em questão de agilidade, a MP-100S perde um pouco por não possuir o corte automático. O que não faz com que a mesma deixe de ser uma boa opção, uma vez que, ambas funcionam da mesma maneira.
  34. 16 points
    Em função do estado de emergência nacional para conter o surto viral de Corona Virus (COVID-19), O Projeto ACBr comunica aos membros: Conteúdos da área de vídeos do SAC ACBr estarão abertos para todo o público Como a orientação das autoridades de saúde é permanecer em casa, o Projeto ACBr entende que teremos de aproveitar o nosso tempo de uma forma diferente durante a quarentena. Como uma forma de solidariedade, os vídeos do SAC ACBr estarão abertos para todo o público (isso inclui o curso Dominando o ACBrMonitor) por tempo indeterminado. Você só precisa ser cadastrado no fórum para poder acessar livremente todos os nossos conteúdos gratuitamente. Os colaboradores do Projeto ACBr (inclusive os que trabalham em regime presencial) estarão trabalhando remotamente durante o período de Quarentena. Numa forma de zelar pela saúde de nossa equipe, todos os colaboradores do ACBr estarão trabalhando em seus respectivos lares. Dado a esse fato, pedimos a compreensão de todos os membros, que podem haver possíveis atrasos nas respostas do Fórum Aberto, Fórum do SAC e Chat ACBr. Todos os serviços citados continuarão em funcionamento seguindo às prerrogativas requiridas para a prevenção correta. Recomendamos à todos os membros que tomem as devidas previdências de segurança. Lavar as mãos e evitar aglomerações é o essencial, porém para conter a dissiminação do vírus, devemos ficar em nossos lares, abrindo mão de circular em locais públicos como bares, praças, praias, shoppings e etc sem necessidade. Cuidado com o contato com pessoas consideradas dentro do grupo de risco (pessoas idosas, com problemas respiratórios ou problemas graves de saúde em geral), pois o vírus tarda a manifestar seus sintomas, e muitas vezes os infectados acabam passando para outras pessoas antes mesmo de saberem que estão doentes. Independente da sua região, é tempo de estarmos unidos, porém não "juntos". Vamos aguardar esses tempos difíceis passarem para retomarmos nossas atividades normais, e esperamos que todos fiquem bem até lá. https://www.projetoacbr.com.br/forum/video/ https://www.projetoacbr.com.br/forum/video/browse/13-curso-dominando-o-acbrmonitor/
  35. 16 points
    Olá pessoal, Como alguns de vocês já notaram, estamos empenhados em fazer os componentes do projeto ACBr ficarem disponíveis em outras plataformas. Uma das maneiras que queremos fazer isso é por permitir que eles compilem em Delphi para Linux e Android. No entanto com isso precisamos fazer uma alteração nos pacotes existentes. Para que os componentes fiquem de acordo, os pacotes precisam ser separados em Designtime e Runtime. Não vou me delongar nesse necessidade no momento, mas quem quiser mais informações pode ver a documentação oficial do Delphi. Basicamente o significado é o seguinte: Pacote Runtime - O pacote é como se fosse um framework ou library encapsulando requisitos e disponibilizando classes e componentes que podem ser vinculados ao código, mas não a IDE. Pacote Designtime - O pacote é para ser instalado na IDE. Isso significa que ele altera a IDE, disponibilizando componentes ou editores de propriedades que são usados em tempo de design (design time ... dã...). Em menos palavras, é um pacote que joga o componente na lista de componentes do Delphi. Essa alteração já está em andamento e você vai notar vários novos pacotes iniciados por "DCLACBr" nas pastas relacionadas ao Delphi. Mas como temos muitos pacotes há ainda vários que precisam ser alterados para funcionar dessa maneira. Como era? E como está? Os pacotes anteriores eram criados como Designtime e Runtime ao mesmo tempo. Visto que algumas pessoas utilizam os pacotes apenas como runtime estamos mantendo os pacotes atuais como Runtime e movendo o código específico pra criar os pacotes Designtime . São esses pacotes Designtime que iniciam por "DCLACBr". ACBrInstall O ACBrInstall que está no SVN já está preparado para lidar com esses pacotes. Ele vai verificar os pacotes se que são apenas Runtime e procurar o Designtime correspondente. Além disso, você vai notar que o ACBrInstall agora lista outras plataformas por cada instalação do Delphi que você tiver. Mas ainda é preciso ajustes tanto nos componentes como no próprio ACBrInstall para que os pacotes sejam compilados para essas plataformas corretamente e para que os vários "path" do Delphi sejam corretamente configurados. Por exemplo, dependemos do projeto JCL para detectar outras plataformas (como Linux e Android). Como eles ainda não implementaram, talvez nós tenhamos que fazê-lo e disponibilizar para eles. Lazarus O Lazarus não tem tanto problemas com os pacotes serem RunTime e Designtime. Então ele não sofre do mesmo problema do Delphi. No entanto, com as mudanças nos arquivos, alguns pacotes do Lazarus tiveram que ser ajustados. Em especial o pacote ACBr_NFCe_DanfeRL.lpk foi removido. Os componentes dele agora se encontram no pacote ACBr_NFe_DanfeRL.lpk Conclusão Como sempre, uma alteração como essa pode gerar problemas e é por isso que estamos avisando a todos. Fiquem a vontade para criar novos tópicos para relatar problemas ou dificuldades. Apenas pedimos que tenham o cuidado de verificar o seguinte: A pasta inteira do ACBr está realmente atualizada? Você tentou reinstalar marcando a opção de apagar arquivos antigos? Já existe algum tópico sobre o assunto? Bom trabalho aí pessoal!
  36. 16 points
    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. 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.
  37. 16 points
    Boa tarde a todos, Foi publicado no Portal Nacional da NF-e a Nota Técnica 2018/004 versão 1.00 que trata sobre um novo tipo de evento que é o de Cancelamento por Substituição. A liberação do ambiente de homologação para iniciarmos os testes esta prevista para 25/02/2019. A principio esse evento só poderá ser utilizado com a NFC-e. Para mais detalhes favor baixar a NT do Portal e boa leitura (são apenas 12 paginas). Estamos finalizando as alterações no componente ACBrNFe para ser enviando para o repositório.
  38. 16 points
    Foto por David Siglin em Unsplash. Olá pessoal, É bom quando encontramos uma ferramenta que facilita ou melhora nosso trabalho, não? Todos devem ter notado que ultimamente temos enviado vários commits ao SVN de remoção de warnings e hints, muitas vezes mencionando a ferramenta FixInsight. Para quem não conhece, essa ferramenta faz uma análise do seu código e aponta possíveis erros e sugere otimizações. Ela é uma ferramenta muito boa, tanto que foi comprada pela TMS e se tornou TMS FixInsight. Já tem um tempo que conheço a ferramenta e sempre tive o desejo de rodá-la em todo o código do ACBr. Mas devido ao tempo não tinha sido possível. Depois de um incentivo (valeu @Waldir Paim), eu resolvi baixar a versão trial e fazer isso. E que bom que fiz. Gostaríamos de compartilhar com vocês algumas coisas que encontramos no nosso código com a ajuda dessa ferramenta. Encontrando pequenos problemas num código gigante Vamos começar por um código que estava no ACBrValidador. Vejam esse código, onde a função ValidarCEP de baixo chama a função ValidarCEP de cima, e tente encontrar um problema: function ValidarCEP(const ACEP, AUF: String): String; begin Result := ValidarDocumento( docCEP, ACEP, AUF); end; function ValidarCEP(const ACEP: Integer; AUF: String): String; begin ValidarCEP( FormatarCEP(ACEP), AUF ); end; Conseguiu ver o problema? Essa função nunca retornaria que um CEP é inválido se você passasse o CEP como inteiro. Precisava de um “Result := ” no início. Simples? Nem tanto quando lembramos do tamanho do projeto ACBr. Temos mais de 200 componentes e mais de 779 mil linhas de código, contribuídos por dezenas ou talvez centenas de programadores, embora a nossa equipe de commiters seja realmente pequena. Só a unit ACBrValidador.pas em questão tem atualmente cerca de 2070 linhas. Não fica muito mais fácil quando uma ferramenta aponta pra você? [FixInsight Warning] ACBrValidador.pas(294): W521 Return value of function 'ValidarCEP' might be undefined Vamos a outro exemplo no pacote ACBrSerial, componente ACBrECF: [FixInsight Warning] ACBrECFDaruma.pas(4638): W503 Assignment right hand side is equal to its left hand side Veja o código (só a parte interessante): else if StrToIntDef(fsNumVersao, -1) >= 345 then begin RetCmd := EnviaComando( ESC + #240 ); RetCmd := Copy(RetCmd, 92, Length(RetCmd)); RetCmd := RetCmd; //<--- Viu aqui??? for A := 0 to fpAliquotas.Count-1 do begin fpAliquotas[A].Total := RoundTo( StrToFloatDef(Copy(RetCmd,(A*14)+1,14),0) / 100, -2 ); end; end; end; Uma linha que não faz absolutamente nada a não ser gastar espaço, memória e CPU. Uma linha desnecessária a menos no código. E você consegue encontrar um no seu aplicativo código que nunca será executado? Ainda no mesmo pacote, veja esse exemplo:  [FixInsight Warning] ACBrECFDataRegis.pas(1838): W509 Unreachable code Nesse código: if (fsArqPrgBcoTXT <> '') and (not FileExists( fsArqPrgBcoTXT )) then begin Msg := ACBrStr( 'Arquivo '+fsArqPrgBcoTXT+' não encontrado. '+ 'Valores padrões serão utilizados.' ) ; raise EACBrECFErro.Create( Msg ); fsArqPrgBcoTXT := '' ; //Essa linha nunca vai ser executada porque tem um raise acima. end ; Mais uma vez, tente imaginar procurar esse problema num projeto tão grande. Não é facilmente percebido se você não tiver olhos treinados e estiver procurando problemas. Vamos a outro exemplo ainda no componente ACBrECF:  [FixInsight Warning] ACBrECFEscECF.pas(1222): W517 Variable 'CHK' hides a class field, method or property Veja esse código: procedure TACBrECFEscECFResposta.SetResposta(const AValue: AnsiString); Var Soma, I, F, LenCmd : Integer ; CHK : Byte ; begin O problema desse código é que ele confunde uma variável local (CHK) com uma propriedade da classe (TACBrECFEscECFResposta.CHK). É preciso analisar todo código em cada lugar que isso acontece para ter certeza quando você está se referindo a propriedade e quando é a variável. Imagine se você confunde uma com a outra. Uma hora você pensa que sua variável está recebendo valores estranhos. Outra hora você pensa que sua propriedade não está sendo atualizada. Nesse caso específico, a variável foi renomeada para vCHK evitando a confusão com a propriedade CHK. O importante é que quando você for ler o código, não precise ficar pensando “Isso aqui é uma variável ou uma propriedade?”. Veja outro exemplo, agora no ACBrSMS: [FixInsight Warning] ACBrSMSClass.pas(192): W511 Object 'ListaSMS' created in TRY block begin try Self.Clear; if not FileExists(APath) then raise EACBrSMSException.CreateFmt('Arquivo "%s" não encontrado.', [APath]); ListaSMS := TStringList.Create; ListaSMS.LoadFromFile(APath); if ListaSMS.Count = 0 then Exit; //(bla bla bla...) finally FreeAndNil(ListaSMS); end; Não é apropriado esse código. O correto é mover a criação do objeto para fora do try..finally. Pense bem, se o objeto não for construído, você não quer que ele seja destruído. A mensagem ajudou a perceber também que esse bloco poderia ser escrito de outra maneira. Aquele raise não precisava estar dentro do try..finally. Evitando problemas futuros Rodando no pacote ACBrOpenSSL tivemos a seguinte mensagem no componente ACBrEAD: [FixInsight Optimization] ACBrEAD.pas(268): O804 Method parameter 'AChavePublicaOpenSSL' is declared but never used Quer dizer, parâmetro ‘AchavePublicaOpenSSL’ declarado mas não utilizado. Veja abaixo a a parte importante da função: function TACBrEAD.ConverteChavePublicaParaOpenSSH( const AChavePublicaOpenSSL: String): String; Var Buffer, Modulo, Expoente: AnsiString; {...} begin // https://www.netmeister.org/blog/ssh2pkcs8.html CalcularModuloeExpoente(Modulo, Expoente); Buffer := EncodeBufferSSH('ssh-rsa') + EncodeHexaSSH(Expoente) + EncodeHexaSSH('00'+Modulo); Result := 'ssh-rsa '+ EncodeBase64(Buffer); end; É estranho esse método ConverteChavePublicaParaOpenSSH não utilizar o parâmetro da chavePública. Qualquer pessoa que visse o método e tentasse chamar passando a chave pública não teria o resultado desejado. Analisando o código melhor vemos que o componente lê a chave pública por meio do método “LerChavePublica”. Nesse caso o correto seria remover o parâmetro para que não haja nenhuma confusão. E essa mensagem no TACBrBALToledo2090: [FixInsight Warning] ACBrBALToledo2090.pas(107): W508 Variable is assigned twice successively if (Length(wStrListDados[1]) = 16) then wDecimais := 1000; {APENAS BLOCO PROCESSADO} wResposta := wStrListDados[1]; //<---- sobreposto pela linha seguinte wResposta := Copy(wStrListDados[1], 5, 7); if (Length(wResposta) <= 0) then Exit; Veja que os dados de uma linha é sobreposta pela outra. O compilador nunca daria um aviso sobre isso. Mais dois exemplos de mensagens e o código a seguir: [FixInsight Warning] ACBrEscEpsonP2.pas(97): W514 Loop iterator could be out of range (missing -1?) [FixInsight Warning] ACBrEscEpsonP2.pas(100): W514 Loop iterator could be out of range (missing -1?) For I := 0 to Length(cTAGS_BARRAS) do TagsNaoSuportadas.Add( cTAGS_BARRAS[I] ); For I := 0 to Length(cTAGS_ALINHAMENTO) do TagsNaoSuportadas.Add( cTAGS_ALINHAMENTO[I] ); Essa eu não sei como não foi detectada antes. Por algum motivo não está sendo emitida a mensagem estouro quando o valor de I chega a 16 no primeiro caso e 3 no segundo. Encontrando erros gerados por Ctrl+C..Ctrl+V No pacote ACBrPAF veja a mensagem gerada: [FixInsight Optimization] ACBrPAF_T_Class.pas(137): O804 Method parameter 'ACampo2' is declared but never used function OrdenarT2(const ACampo1, ACampo2: Pointer): Integer; var Campo1, Campo2: String; begin Campo1 := FormatDateTime('YYYYMMDD', TRegistroT2(ACampo1).DT_MOV) + TRegistroT2(ACampo1).TP_DOCTO + TRegistroT2(ACampo1).SERIE + TRegistroT2(ACampo1).NUM_ECF; Campo2 := FormatDateTime('YYYYMMDD', TRegistroT2(ACampo1).DT_MOV) + TRegistroT2(ACampo1).TP_DOCTO + TRegistroT2(ACampo1).SERIE + TRegistroT2(ACampo1).NUM_ECF; Result := AnsiCompareText(Campo1, Campo2); end; Essa função é utilizada para ordenar os registros T2 do PAF. Mas veja que ela compara o registro “ACampo1” com ele mesmo. Suspeita: Ctrl+C e Ctrl+V... Quem nunca??... Outra situação diferente, mas relacionada com ordenação apareceu no ACBrSintegra. Na verdade 4 situações no ACBrSintegra, semelhantes entre si. Vou mostrar apenas uma, mas dessa vez a mensagem do FixInsight fica pra depois. Vamos a um jogo dos sete erros entre os ifs e else no código abaixo: function Sort60A(Item1, Item2: Pointer): Integer; var witem1, witem2 : TRegistro60A; begin witem1 := TRegistro60A(Item1); witem2 := TRegistro60A(Item2); if witem1.Emissao>witem2.Emissao then begin if witem1.NumSerie>witem2.NumSerie then Result:=1 else if witem1.NumSerie=witem2.NumSerie then Result:=0 else Result:=-1; end else if witem1.Emissao = witem2.Emissao then begin if witem1.NumSerie>witem2.NumSerie then Result:=1 else if witem1.NumSerie=witem2.NumSerie then Result:=0 else Result:=-1; end else begin if witem1.NumSerie>witem2.NumSerie then Result:=1 else if witem1.NumSerie=witem2.NumSerie then Result:=0 else Result:=-1; end; end; Conseguiu encontrar os erros? Bem, se você procurou diferenças, não deve ter encontrado nada. E não existe mesmo. Veja a mensagem da ferramenta: [FixInsight Warning] ACBrSintegra.pas(3410): W507 THEN statement is equal to ELSE statement São dois if e um else pra fazer a mesma coisa... A correção foi remover o IFs e ELSE.  Agora vamos ao pacote ACBrSPED. Depois de remover muitos e muitos parâmetros desnecessários apontados pelo FixInsight, veja esse código: function CodAjToStr(const AValue: TACBrCodAj): string; begin if AValue = codAjAcaoJudicial then Result := '01' else if AValue = codAjAcaoJudicial then Result := '02' else if AValue = codAjLegTributaria then Result := '03' else if AValue = codAjEspRTI then Result := '04' else if AValue = codAjOutrasSituacaoes then Result := '05' else if AValue = codAjEstorno then Result := '06'; end; A mensagem é a seguinte: [FixInsight Warning] ACBrEPCBlocos.pas(2071): W512 Odd ELSE-IF condition (review lines 2071 and 2073) Viu lá? Os dois primeiros ifs estão comparando AValue com o mesmo valor, "codAjAcaoJudicial". O segundo deveria ser "codAjProAdministrativo". Provavelmente mais um Ctrl+C..Ctrl+V. Mensagens para otimização de código Nem todas as mensagens geradas são de erros. Algumas são mensagens de otimização. Muitos dos commits que temos feito estão relacionados a uma mensagem como estas abaixo: [FixInsight Optimization] ACBrSATClass.pas(776): O801 CONST missing for unmodified string parameter 'CNPJvalue' [FixInsight Optimization] ACBrSATClass.pas(776): O801 CONST missing for unmodified string parameter 'assinaturaCNPJs' Ela pode ser gerada numa função como essa: function TACBrSATClass.AssociarAssinatura( CNPJvalue, assinaturaCNPJs : AnsiString) : String ; begin ...// um código que não altera nenhum dos parâmetros citados end; Essas mensagens estão dizendo que os parâmetros 'CNPJvalue' e ‘assinaturaCNPJs’ do tipo string não estão sendo alterados dentro da função a que eles pertencem. Nesse caso é bem provável que os parâmetros devessem ter um prefixo CONST na sua declaração, como abaixo: function TACBrSATClass.AssociarAssinatura(const CNPJvalue, assinaturaCNPJs : AnsiString) : String ; begin ...// um código que não altera nenhum dos parâmetros citados end; Não vou entrar em muitos detalhes sobre isso, mas usar CONST tem alguns benefícios, principalmente em caso de strings: A execução é mais rápida, porque o compilador pode otimizar o código. No caso de strings, não tem contagem de referências; O compilador garante que você não vai alterar os parâmetros passados gerando um efeito colateral indesejado em quem chamou as funções; O código fica mais legível, porque você pode ler que a intenção é não alterar o parâmetro passado; Como os parâmetros são imutáveis, pode tornar o código mais ThreadSafe; Se quer saber um pouco mais sobre isso, recomendo os seguintes links: All hail the “const” parameters! Is the use of ‘const’ dogmatic or rational? Concluindo... Bom pessoal, ainda temos bastante pra fazer. Contudo, queremos dizer que o FixInsight tem nos ajudado melhorar nosso código. Ficamos tão satisfeitos que entramos em contato com a TMS e eles generosamente nos cederam uma licença da versão Pro pra continuar nosso trabalho. Muito obrigado TMS. Agora, se você quer nossa opinião, essa é uma ferramenta altamente recomendada e está disponível pra toda versão do Delphi a partir do Delphi 2006. Se você tem alguma dúvida, baixe a versão trial e comece agora mesmo a usar no seu código. A versão trial limita as mensagens a 5 por units e funciona por 30 dias. Mas é o suficiente pra se perceber como é muito útil, como aconteceu com a gente. Quer um passo a passo em como utilizá-la? Veja o próximo post logo abaixo.
  39. 16 points
    Olá pessoal, Compartilho com vocês, os Planos de Expansão do Projeto ACBr. Em anexo, está o PDF da apresentação Apresentação - ACBr - Planos de Expansão.pdf
  40. 16 points
    Sabemos que o assunto é sério e que muitas aplicações ainda não estão prontas... (mas não foi por falta de tempo... pois como podemos ver foram 20 meses após a publicação da primeira NT da 4.0) Alguns estados ainda estão fazendo o dever de casa... e é possível notar que vários estão com problemas no ambiente de homologação: http://hom.nfe.fazenda.gov.br/portal/disponibilidade.aspx?versao=0.00&amp;tipoConteudo=Skeuqr8PQBY= 31/07/2017 - 17:11 30/07/2017 - 18:16 O CONFAZ aproveitou a ocasião para criar ainda mais regras de validação, e novas Tags em um XML que atualmente é quase impossível de compreender o significado de todos os campos... Com isso inúmeros problemas foram criados nos WebServices e alguns persistem até hoje... Temos vários relatos aqui no fórum de exemplos de SEFAZ que não seguem a risca as próprias orientações das Notas Técnicas, ou ainda informações conflitantes, e passíveis de dupla interpretação... Isso obrigou a todos a criação de remendos e IFs, para suportar todas as SEFAZ... A grande pergunta é se realmente o SEFAZ irá ter a coragem (ou a irresponsabilidade) de desativar a 3.10 e causar o caos em um sistema tributário que já um dos mais infernais do mundo...
  41. 16 points
    Você esta desenvolvendo um programa comercial e nem sabe usar sua IDE corretamente. Eu vi o topico ao qual você se refere, e acho um absurdo uma pessoa que se "diz" programador fazer uma pegunta como aquela, se você le-se a menssagem de erro veria que o delphi esta reclamando que não achou o pacote do quick report Required package 'QR5RunDXE4' not found ou seja não tem nada haver com o component ACBr. Então em resumo antes de reclamar de INSATISFAÇÂO lembre-se o forum e o componente é Open-source ou seja o codigo ta ai para você fazer modificação se achar necessario. E não fale que não tem boa vontande pois se não houve-se você estaria fazendo seu componente NFe e não baixando um já pronto que a comunidade e os desenvolvedores do projeto mantém.
  42. 15 points
    Olá Pessoal, Ocorreu uma alteração no salvamento dos arquivos de envio e de retorno dos eventos e da inutilização. O motivo dessa alteração foi que esses arquivos estavam sendo salvos em dois lugares distintos. No caso dos eventos eles estavam sendo salvos na pasta configurada em PathEvento e em PathSalvar. Já os de inutilização estavam sendo salvos na pasta configurada em PathInu e em PathSalvar. Com a alteração os arquivos de envio e de retorno passam a ser salvos somente na pasta configurada em PathSalvar. Por outro lado, o resultado final do processamento dos eventos bem como da inutilização, ou seja, os arquivos *-procEventoNFe.xml (no caso da NF-e) e o *-procInutNFe.xml (no caso da NF-e) vão continuar sendo salvos nas pastas configuradas em PathEvento e PathInu respectivamente. Desta forma fica fácil para o desenvolvedor pegar por exemplo todos os XMLs referente aos cancelamentos (pasta ...\Evento\Cancelamento) compactar e enviar para a contabilidade. Antes era preciso excluir os arquivos de envio e de retorno para que estes não fossem incluídos no arquivo compactado. Quero lembrar a todos que essa alteração foi realizada nos componentes: ACBrBPe (Bilhete de Passagem Eletrônico), ACBrNF3e (Nota Fiscal de Energia Elétrica Eletrônica), ACBrCTe (Conhecimento de Transporte Eletrônico), ACBrMDFe (Manifesto de Documentos Fiscais Eletrônicos) e ACBrNFe (Nota Fiscal Eletrônica).
  43. 15 points
    Configurações do ACBrMail para os principais serviços de emails do mercado outlook smtp: smtp.office365.com porta: 587 tsl : true; ssl : false; hotmail smtp: smtp.live.com porta: 587 tsl : true; ssl : false; gmail smtp: smtp.gmail.com porta: 465 tsl : true; ssl : true; ativar apps menos seguros no link https://myaccount.google.com/lesssecureapps obs.: autenticação por dois fatores, desativa automaticamente a permissão de apps menos seguros. 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.; 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; 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;
  44. 15 points
    Teste o SAC ACBr gratuitamente por 15 dias... saiba mais sobre a Conta Trial do SAC do ACBr Sobre A ACBrLib é um conjunto de bibliotecas compartilhadas, que torna possível o uso dos componentes do Projeto ACBr, em qualquer linguagem de programação. Cada componente principal do ACBr, foi encapsulado em uma Biblioteca independente. Exemplo: O componente ACBrPosPrinter (para impressão em EscPos), está encapsulado na biblioteca ACBrLibPosPrinter. Saiba mais sobre a ACBrLib em: https://www.projetoacbr.com.br/acbrlib/ Principais Características A ACBrLib é compilada em Windows (DLL) e Linux (SO), nas arquiteturas 32 e 64 bits, e convenções de chamada StdCall e Cdecl. Todos os Binários gerados para Windows, são versionados e assinados com o certificado digital do Projeto ACBr. Acompanham classes de Alto Nível, para facilitar o uso e integração com linguagens populares, como: Java, C#, VB e outras. O projeto ACBr e a ACBrLib, contam com uma vasta comunidade de usuários. O que ajuda muito no suporte, melhorias e contribuições. A ACBrLib e os componentes do Projeto ACBr são desenvolvidos em Object Pascal. A ACBrLib pode ser compilada com Lazarus /FPC Licença de uso Assim como todos os fontes do Projeto ACBr, a ACBrLib, Demos e Classes de Alto nível, são distribuídas em Código Aberto, usando a licença LGPL. http://licencas.softwarelivre.org/lgpl-3.0.pt-br.html https://pt.wikipedia.org/wiki/GNU_Lesser_General_Public_License Download Binários Link: https://www.projetoacbr.com.br/forum/files/category/36-acbrlib/ NOTA: Para baixar os binários, você precisa ser cadastrado no nosso fórum, e membro Ativo do SAC. Você pode criar uma conta Trial, em: https://www.projetoacbr.com.br/forum/sac/v2/cadastro/ Fontes Você pode baixar os Fontes do ACBr e da ACBrLib, direto do nosso repositório SVN. Veja instruções em: https://www.projetoacbr.com.br/fontes/ Exemplos de uso / Demos Link direto para download dos Demos por SVN: http://svn.code.sf.net/p/acbr/code/trunk2/Projetos/ACBrLib/Demos/ Documentação On-Line: https://acbr.sourceforge.io/ACBrLib/ACBrLib.html PDF: https://acbr.sourceforge.io/ACBrLib/ACBrLib.pdf Windows Help (CHM): https://acbr.sourceforge.io/ACBrLib/ACBrLib.chm Requisitos de Sistema Sistema Operacional: Windows XP ou superior 32/64; Linux 32/64 CPU: i386, x86_64 Dependências Alguns componentes do ACBr, fazem uso de bibliotecas de terceiros, como por exemplo: OpenSSL, e LibXML2. NOTA: Use bibliotecas da mesma arquitetura do seu sistema. Exemplo: Se você compila seu executável em 32 bits, precisará usar a ACBrLib e suas dependências, na versão 32 bits (mesmo que o Sistema Operacional seja 64 bits) Windows Você poderá encontrar as Dependências para a sua ACBrLib, no mesmo arquivo ZIP. Elas estão na Pasta “\dep\”. Linux Você precisará instalar as dependências, e criar os Links simbólicos necessários. Em nosso fórum, há um documento explicando como montar o ambiente no OpenSuse: https://www.projetoacbr.com.br/forum/files/file/413-desenvolvendo-no-linux-com-acbr/ Obter Suporte Gratuito Você pode obter suporte no Fórum do ACBr. Temos uma área específica para usuários da ACBrLib: https://www.projetoacbr.com.br/forum/forum/76-acbrlib/. Para criar um tópico, é necessário ter uma conta (gratuita) Profissional Se você precisa de Suporte Técnico especializado, diretamente com os desenvolvedores do ACBr. Você pode assinar o SAC do ACBr, saiba mais em: https://www.projetoacbr.com.br/forum/sac/sobre/ Como Instalar / Distribuir Windows O melhor lugar para copiar a ACBrLib e suas dependências, é na mesma pasta do seu Executável. Evite copiar os arquivos .DLL para diretórios do Sistema Operacional, como: Windows\System32 ou Windows\SysWow64 (isso evita conflito entre .DLLs) Não é necessário registrar as DLLs. Linux Como “root”, copie o arquivo .SO para a pasta /usr/lib ou /usr/lib64 (conforme o caso) Como usar: Consulte a documentação, para uma compreensão melhor. Copie/Instale a ACBrLib, conforme sugerido em: Como Instalar / Distribuir Verifique em Download, Exemplos de uso / Demos, se já existe para a sua linguagem, Classes de Alto nível, isso ajuda enormemente o uso da Biblioteca. Familiarize-se com o arquivo de configuração da ACBrLib (o arquivo é criado, se não existir, durante a Inicialização da ACBrLib) Chame o método de Inicialização da ACBrLib, LIB_inicializar (onde “LIB” seria o nome da ACBrLib utilizada exemplo: (POS, ETQ, NFE) Use os métodos da ACBrLib... Quando terminar, encerre a ACBrLib, chamando: LIB_Finalizar Histórico de mudanças Consulte na documentação, a sessão: “Histórico de Alterações”, de cada ACBrLib
  45. 15 points
    Responsável Técnico - Como fica o XML na prática? Com tantas alterações, ficou um pouco confuso entender quando e quais tags do grupo Responsável Técnico deverão ser enviadas. Segue então um resumo. Até 02/06/2019 Os XMLs deverão ser enviados sem este grupo, como tem sido feito até então. A partir de 03/06/2019 Para as UFs do AM, MS, PE, PR, SC e TO deverá ser incluído o grupo Responsável Técnico, porém sem as tags relativas ao idCSRT. Veja imagem a seguir. Após definição de data para exigência do idCSRT Quando as SEFAZ publicarem as datas para exigência destas tags, as mesmas passarão a ser exigidas no XML, caso contrário os mesmos passaram a ser rejeitados. A seguir, exemplo de XML com o grupo Responsável Técnico completo. Importante Até o presente momento nenhuma SEFAZ disponibilizou os mecanismos para geração do idCSRT, logo mesmo em homologação não é possível enviar estas tags. A partir de 07/05/2019 as UFs que optaram pela exigência do Grupo do Responsável Técnico ( AM, MS, PE, PR, SC e TO ), já aceitaram as tags de identificação também em ambiente de produção, porém rejeitarão os XMLs sem estas tags somente em 03/06/2019.
  46. 15 points
    Boa tarde a todos! Gostaria de parabenizar o trabalho e a dedicação de toda a equipe, patrocinadores e empresas envolvidas, foi uma grande oportunidade e privilegio participar com todos vocês...Pena que foi só um dia!? Agradeço a todos que estiveram envolvidos nesse grande projeto. Essa equipe é sensacional:
  47. 15 points
    Olá Pessoal, Agradeço do fundo do meu coração, a todos que participaram do 1o Dia do ACBr. Esperamos que sua experiência tenha sido tão boa quanto foi a nossa. Foi um dia muito especial, para o Projeto ACBr, pois somos uma comunidade de Desenvolvedores espalhada por todo o Brasil, e muitos de nós, nunca havíamos conversado pessoalmente… Há muito tempo eu idealizava a execução desse evento, mas sabia que não seria uma tarefa fácil… E realmente, projetar e executar um evento para mais de 400 participantes, se mostrou um desafio e tanto... Mas quando podemos contar com uma Equipe de colaboradores nota 10, os obstáculos são vencidos com mais facilidade. O ambiente estava descontraído, e como podemos ver pelas fotos, o riso rolava solto…. Creio ter sido um dia produtivo para os Congressistas, que além das Palestras, puderam conhecer de perto os Desenvolvedores, e os principais Fabricantes de Equipamentos para automação Comercial que estavam exibindo em primeira mão, produtos que ainda serão lançados em 2019. O Parque Tecnológico de Sorocaba, se mostrou um ótimo espaço… Com um amplo auditório, e 2 salas bem equipadas, conseguimos distribuir as palestras, baseado nas informações das inscrições. O amplo hall, todo envidraçado, e cercado por uma bela paisagem, foi o lugar perfeito para Networking, onde todos puderam conversar e ficar bem à vontade, durante os dois coffee break servidos… Tivemos um show de prêmios no final: Elgin 10 Kits SAT SDK + Impressora I9 Tanca 3 leitores TL-20 Dimep 2 SAT SDK Control iD: 1 Leitor Biométrico Bio, para cada CNPJ inscrito 4 Impressoras Print iD Embarcadero 1 kit Brindes Bematech 1 SAT Go (novo) Firebase 2 Livros, Guia de Migração para o Firebird 3 ACBr: Kit completo dos Produtos ACBr: 1a inscrição: Sebastião Donizete Ramos Usuário mais antigo do SAC: Geraldo José Rodrigues Usuário mais assíduo do SAC: Antonio Paulo Mangili Usuários mais distantes ao Norte/Nordeste: André Luiz Gurgel-RN e José Valber Aguiar-MA Usuários mais distantes ao Sul: Lucas Rebelato-RS e Dirlenio Batista-SC Já estamos subindo o material das Palestras, que foram apresentadas, nesse Link. Eles ficarão disponíveis para Download, para todos os membros que estiveram presentes no evento e para os usuários do SAC do ACBr. Você já pode encontrar algumas fotos do evento, nesse link. (só de ver as fotos, já dá saudades) Todas as palestras foram Filmadas, porém ainda estamos editando os vídeos, e pretendemos liberar até 4 palestras por mês… Sendo assim, se você perdeu alguma palestra, ou deseja recordar algum tópico, o vídeo será de grande ajuda… O acesso aos vídeos, será permitido a todos os participantes do Evento e usuários do SAC, através desse link Peço desculpas por algumas de nossas falhas, como por exemplo, o atraso de quase 30 min, no último bloco, antes do sorteio (justamente quando todos já estavam muito cansados) Sua opinião é muito importante para nós… Queremos aprender com nossos erros, para fazermos um evento cada vez melhor… Portanto, por favor preencha a nossa pesquisa de satisfação, clicando aqui nesse link. Se você precisa de um Certificado de Presença, poderá emitir o mesmo, clicando nesse link. As ideias já estão fervilhando para a 2a edição… Pretendemos abrir inscrições no início do próximo ano… Obrigado mais uma vez, e nos vemos na 2a edição do Dia do ACBr em 2019
  48. 15 points
    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.
  49. 15 points
    Boa tarde a todos, Teremos mudanças no layout do MDF-e, basicamente são quatro, a primeira é que agora será possível uma pessoa física desde de tenha Inscrição estadual emitir o MDF-e, sendo assim a propriedade CNPJ do emitente vai passar a se chamar CNPJCPF, a segunda se refere a consulta a Manifestos não encerrados que também vai aceitar o CPF sendo assim o campo passa a ser CNPJCPF, a terceira se refere ao modal aéreo que passa a ter um novo grupo <infEntregaParcial> e a quarta é o novo grupo chamado <infEmpresaSoft>. Este último grupo em um primeiro momento é opcional, ou seja, ele não precisa constar no XML, mas futuramente vai ficar a cargo de cada UF determinar a sua obrigatoriedade. Nesse grupo deveremos informar o CNPJ ou CPF do desenvolvedor, bem como o nome da empresa ou desenvolvedor, e-mail e telefone. O componente ACBrMDFe já foi alterado visando a geração desses grupos, estou apenas aguardando a liberação do ambiente de homologação para enviar para o repositório. Favor baixar e ler com atenção a Nota Técnica 2018/002 que se encontra no Portal Nacional do MDF-e. O Ambiente de Homologação vai ser liberado em 10/09/2018 e o de Produção em 15/10/2018.
  50. 15 points
    Vamos acalmar os ânimos ok? Não há o que possamos fazer para trazer toda a rede do Slashdot e Source Forge ao normal. Estamos fazendo o que podemos no momento. E ter um pouco de paciência não vai matar ninguém.
×
×
  • Create New...