December 7 2012 - May 31 2020
Showing content with the highest reputation since 12/07/2012 in all areas
ANSWERED Bye Bye CAPICOM
Código Numérico inválido, Chave não Gerada
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.
Nota Técnica 2019/001
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.
Extensão do suporte ao Delphi 7 até o fim do ano.
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.
ACBrDevice com suporte Nativo a USB no Windows
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
ANSWERED Versão 4.00 da NFe/NFCe com ACBr
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
ACBrDFe OpenSSL e TLS1.2
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/
Terça, 07/05/19, pode ser o dia do CAOS na emissão de NFe/NFCe
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
ANSWERED OpenSSL/XMLSec ou CAPICOM, dependencia de bibliotecas externas
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"
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".
NFCe - Rejeição: Endereço do site da UF de Consulta por chave de acesso diverge do previsto
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.
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:
Método Consultar com novo parâmetro
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.
Alteração para padronização das medidas de margens nos reports
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.
Regras E Orientações Gerais Para O Fórum Acbr...
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.
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
Informações sobre o Responsável Técnico
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/
Então, vamos falar francamente!
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!
Olá pessoal, Alguém já imaginou ou tem a necessidade de imprimir o boleto em uma impressora térmica? Pois bem, o @guilhermekm teve a necessidade, arregaçou as mangas e implementou um novo layout chamado lTermica80mm. Guilherme, muito obrigado pela colaboração, já esta disponível no repositório. Quero também agradecer ao @Doug Dela Bite pelos ajustes feitos na implementação do Guilherme, muito obrigado Douglas. Abaixo o Preview e a impressão do boleto feita em uma Epson TM-T20X. Esse layout esta disponível apenas para o Fortes Report, portanto convido aos mestres em Fast Report a fazerem o mesmo que o Guilherme e Douglas. Estou aguardando o layout para o Fast! Compatibilizei o LFM do Lazarus com o DFM do Delphi, sendo assim é para funcionar sem nenhum problema no Lazarus / Fortes Report. Veja aqui o tópico original:
Olá pessoal, 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.
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.
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.
ANSWERED Erro Webservice
Altere essas configurações no internet explorer
Novidades em 2020 para Pagamentos Instantâneos
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.
Fórum de Base de Conhecimento, aberto a todos
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...
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/
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.
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.
Novo componente - ACBrLCDPR para Livro Caixa Digital do Produtor Rural
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.
Solução Para Erro De Certificados Revogados (Opções Da Internet > Avançado)
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.
Homologação ACBr Impressora Não Fiscal Bematech MP-100S TH
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.
Separação dos pacotes Runtime E Designtime do Delphi
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!
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.
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.
Melhoria do código do ACBr com o uso da ferramenta FixInsight
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.
ANSWERED Projeto ACBr - Planos de Expansão
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
Chega ao fim a NFe 3.10
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...
ANSWERED Insatisfação
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.
Bancos suportados pelo ACBrBoleto
Boa tarde pessoal, Muitos de vocês já deve ter questionado quais são os bancos suportados pelo ACBr e e acabaram se deparando com a necessidade de checar diretamente nos fontes. Afim de trazer essa informação de forma mais rápida, segue relação até a data da publicação deste artigo. Veja relação acima em mais detalhes Código Febrabran Banco Carteiras Configuração no ACBr (Propriedade Tipo Cobrança) Obs 001 Banco do Brasil Todas cobBancoDoBrasil 003 Banco da Amazônia Todas cobBancoDaAmazonia 004 Banco do Nordeste Todas cobBancoDoNordeste 021 Banco Banestes Todas cobBanestes 033 Santander Todas cobSantander 041 Banrisul Todas cobBanrisul 070 BRB Todas cobBRB 091 Unicred RS Todas cobUnicredRS 085 Cecred Todas cobBancoCECRED 097 CredSis Todas cobCrediSIS 099 Uniprime Todas cobUniprime 104 Caixa Econômica Todas cobCaixaEconomica (Layout SIGCB) cobCaixaSicob (Layout Sicob) 136* Unicred ES Todas cobUnicredES 237 Bradesco Todas cobBradesco 341 Itau Todas cobItau 389 Banco Mercantil Todas cobBancoMercantil 748 Sicredi Todas cobSicred 756 Bancoob (Sicoob) Todas cobBancoob 399 HSBC Todas cobHSBC 422 Banco Safra Todas cobBancoSafra 047 Banese Todas cobBanese 745 CitiBank Todas cobCitiBank 246 Banco ABC Brasil Todas cobBancoABCBrasil 707 Banco Daycoval Todas cobDaycoval 084 Uniprime Todas cobUniprimeNortePR 643 Banco Pine Todas cobBancoPine O ACBr também suporta as variações de layout dos bancos acima, conforme relação a seguir. Código Febraban Banco Carteiras Correspondente Configuração no ACBr (Propriedade Tipo Cobrança) 756 Sicoob Todas Banco do Brasil cobBancoDoBrasilSICOOB 091 Banco Unicred RS Todas cobUnicredRS 136* Banco Unicred ES Todas cobUnicredES 136* Banco Unicred SC Todas Bradesco cobUnicredSC * Banco Bic Todas Bradesco cobBicBanco 133* Banco CreSol Todas Bradesco cobBancoCresolSCRS 756 Sicoob Todas Bradesco 756cobBradescoSICOOB 422 Safra Todas Bradesco cobSafraBradesco 643 Pine Todas Bradesco cobBancoPineBradesco *Código não localizado na tabela Febraban Importante: Este tópico será atualizado sempre que houver novas adições de bancos ou correspondentes. Para Utilização com o ACBrMonitorPlus, deve-se consultar as orientações existentes no Manual OnLine, o qual pode ser acessado aqui.
Mudanças no salvamento de arquivos de Envio e de Retorno
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).
Lançamento da ACBrLib
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
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
Provedores funcionando 100%
Bom dia a todos, Nesta postagem irei listar somente os provedores que estão funcionando 100% com o componente ACBrNFSe - Trunk2. Peço a todos que realizaram testes com um determinado provedor e obteve sucesso, ou seja, todas as funcionalidades oferecidas pelo provedor estão funcionando, por favor envie um e-mail para mim informando que o provedor xyz esta funcionando 100%. Não é para enviar duvidas ou relatar problemas, o fórum serve para essa finalidade. Antes de enviar o e-mail favor verificar se na lista abaixo consta o provedor em questão, só envie se não constar. Desde já o meu muito obrigado. Provedores funcionando 100%: 4R / Ábaco / ABase / Betha / BHISS / Ciga / Conam / Coplan / DBSeller / Digifred EGoverneISS / EL / Equiplano / FISSLex / Ginfes / Governa / GovDigital / ISSCuritiba / ISSNet / NFSeBrasil Pronim / Pronimv2 / Publica / PVH / Saatri / SimplISS / SystemPro / Thema / Tiplan / WebISS. No arquivo Cidades.ini temos 699 cidades e seus respectivos provedores.
Agnaldo, em nome da equipe agradecemos suas palavras, as vezes não damos uma resposta da qual o usuário espera, pois as vezes esperamos deles pelo ao menos esforço no aprendizado, já que não exigimos conhecimentos para manutenção ou desenvolvimento dessa Suite (ACBr). Do nosso lado, como todos, não somos também "magos" do "object pascal", mas nos esforçamos muito para nosso próprio aprendizado, e conseguirmos o conhecimento para manter tal projeto, pois estudamos a linguagem, a ferramenta (Delphi, Lazarus), e ainda os enormes manuais e Leis para cada um dos componentes, para que os mesmos atenda dentro dos padrões estabelecidos, e para tirar nosso estresse, ainda ajudamos nas dúvidas e aqui no fórum. Então em nome do ACBr gostaríamos que pelo ao menos, víssemos nas perguntas, clareza nas dúvidas, e enxergarmos que ela aconteceu mas deixou transparecer que houve esforço de quem a está fazendo antes de posta-la, pois aqui não ensinamos Delphi, Lazarus, Leis, aqui desenvolvemos componentes e a ajudamos a usa-lo, e seus usuários deviam pelo ao menos conhecer e dominar sua ferramenta de trabalho.
ANSWERED Não consigo baixar os fontes ACBr
Por favor leia com atenção o documento "Bem_Vindo_ao_Trunk2.pdf" Pessoal, O ACBr usa o SourceForge desde a sua fundação em 2005... Ou seja, o S.F. nos serviu muito bem, (e gratuitamente), por mais de 10 anos... O ACBr foi especialmente mais afetado, porque optamos por não criar ZIPs, com os fontes (Tags)... Na verdade, fazíamos isso no do projeto... mas é muito difícil fechar um Tag em um projeto com o tamanho do ACBr... então dotamos a premissa de usarmos o Trunk, e os "commiters" só devem subir para o Trunk código que esteja compilando sem erros... (mesmo isso é difícil quando se suporta várias IDEs e plataformas) O problema recente, em que estamos a mais de uma semana se acesso ao repositório dos fontes é realmente muito chato... Muitos estão vendo apenas um lado da estória, que é: "Eu quero baixar os fontes"... Mas acredite, não é simples migrar um repositório de fontes do tamanho do ACBr... Perderíamos todo o nosso histórico do SVN, e precisaríamos fazer ampla divulgação do novo endereço.... Vários dos serviços do Source Forge já estão no ar... e eles definiram como próxima tarefa restaurar os repositórios: http://sourceforge.net/blog/category/sitestatus/ Em virtude dos 10 anos de excelentes serviços prestados pelo Source Forge, ao nosso projeto, estou disposto a aguardar mais alguns dias pela resolução do problema... porém se isso não se concretizar, realmente teremos que iniciar o processo de migração para outro Host...
Bem vindo ao Trunk2
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.