Jump to content

110.png

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

botao_campanha_thulio.png

sem_ttulo-620.fw_-e1583866078274.png 

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

Saiba Mais

Balança SM100 performance surpreendente

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

Saiba Mais

Impressora de Etiquetas ELGIN - L42 PRO

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

Saiba mais

Leaderboard


Popular Content

Showing content with the highest reputation since 04/04/2019 in all areas

  1. 50 points
    Olá pessoal, Quem atualizou os fontes e reinstalou a Suite ACBr, pode ser que esteja recebendo essa mensagem de erro no momento que vai gerar a NF-e / CT-e / MDF-e / BP-e. Porque esta mensagem esta aparecendo para alguns e para outros não? Simples, quando o XML é gerado com base em alguns dados do documento fiscal é gerado a chave do mesmo. Essa mensagem de erro é devido a uma validação que foi implementada na função que gera a chave. Essa validação visa garantir que a sua Nota (por exemplo) não seja rejeitada pela regra de validação B03-10 que consta na Nota Técnica 2019/001. Como vocês podem ver na imagem acima, a aplicação dessa regra é obrigatória, ou seja, todas as SEFAZ-Autorizadoras devem implementar essa regra. Ela será implementada no dia 01/07/2019 no ambiente de Homologação e no dia 02/09/2019 no ambiente de Produção. A validação que foi implementada ao gerar a chave é exatamente a descrita na regra, ou seja, o valor de cNF não pode ser igual a nNF e a nenhum dos números listados na regra. Por curiosidade resolvi pegar o Manual da NF-e mais antigo que tenho (Março de 2009) veja o que esta escrito na definição do campo cNF: O Manual deixa claro que o numero atribuído a cNF tem que ser um numero aleatório. Portanto quem costuma atribuir a cNF o mesmo numero atribuído a nNF esta fazendo errado e agora não vai ter perdão, pois se insistir a SEFAZ não vai aceitar a nota. Mas a regra B03-10 da Nota Técnica 2019/001 não se refere apenas a NF-e / NFC-e? Sim, mas tenham certeza que essa regra de validação em breve vai ser implementada para os demais DF-e - Documentos Fiscais Eletrônicos. Alguém duvida disso? O que devo fazer para que a minha aplicação não pare com a mensagem de erro: Código Numérico inválido, Chave não Gerada ? Muito simples, vou dar como exemplo o fragmento de código da minha aplicação: Como é hoje, note que eu já gerava o código como sendo um numero aleatório: NotaFiscalVenda := (DM_VEN.NotasDocumento.AsInteger + 1); CodigoChave := Random(99999999) + 1; // +1 para garantir que não seja zero Como vai passar a ser, para ter uma garantia maior ainda: NotaFiscalVenda : =(DM_VEN.NotasDocumento.AsInteger + 1); CodigoChave := GerarCodigoDFe(NotaFiscalVenda); A função GerarCodigoDFe esta definida na Unit ACBrDFeUtil, logo você vai ter informar essa Unit em Uses do seu Form. Note que ela recebe como parâmetro o numero da nota, pois a função vai gerar o código aleatoriamente e vai validar o mesmo e pela regra o código não pode ser igual ao numero da nota. De forma semelhante você terão que fazer o mesmo nas suas aplicações que emitem CT-e, MDF-e e BP-e. É preferível fazer essa correção na aplicação agora do que receber dezenas ou até centenas de ligações de clientes que não estão conseguindo autorizar os seus documentos na SEFAZ. Fica ai a dica.
  2. 42 points
    Boa tarde a todos, Já esta disponível em nossa biblioteca a Nota Técnica 2019/001 que trata sobre novas regras de validação. Resumo da NT: · Dificultar utilização de código de segurança fraco · Melhorar o controle de documentos referenciados e da identificação do destinatário · Descrever benefícios fiscais e informações da tributação do ICMS com mais precisão · Criação de valor máximo para a base de cálculo do ICMS, por unidade federada · Melhor gerenciamento de informações sobre o destinatário, tanto no serviço de autorização de NF-e quanto no serviço de registro de EPEC Datas previstas para entrada em vigor: 01/07/2019 - Ambiente de Homologação; 02/09/2019 - Ambiente de Produção. Alterações no componente: Nenhuma, visto que essa NT trata de novas regras de validação a serem implementadas pelas SEFAZ-Autorizadoras. Novas Regras de Validação: Criada a Regra de Validação B03-10, para dificultar a utilização de um código de segurança fraco, ou seja, o valor de cNF não vai poder ser igual ao valor de nNF e sim um numero aleatório. Criadas regras de validação a documentos referenciados:  Regra de Validação BA10-40 foi alterada, possibilitando a utilização do CNPJ 8 (somente os 8 primeiros dígitos) com o objetivo de identificar que a nota foi emitida pelo mesmo contribuinte, a critério da unidade federada. Criada a Regra de Validação BA10-50, exigindo que uma contranota de produtor rural somente possa referenciar uma nota emitida por outro produtor rural, a critério da unidade federada. Criada a Regra de Validação BA20-20, impedindo que seja referenciado um documento fiscal de uso exclusivo para operações internas em uma operação destinada a outra unidade federada ou para o exterior. Criada a Regra de Validação BA20-30, impedindo referência a um Cupom Fiscal, a critério da unidade federada. Criadas regras de identificação do destinatário: Criada a Regra de Validação E03a-30, impedindo o uso simultâneo de IE e de identificação de estrangeiro para o destinatário. Criada a Regra de Validação E14-30, impedindo informação de país de destino “Brasil” em operações destinadas ao estrangeiro. Criada a Regra de Validação E16a-40, exigindo a indicação de “operação com consumidor final” quando se indica que a operação é destinada a não contribuinte. Criadas regras de validação tornando obrigatória a informação do Motivo da Desoneração e do Valor do ICMS desonerado, caso seja informado o Código do Benefício Fiscal: Criada a Regra de Validação I05f-10, impedindo a informação de um código de benefício fiscal juntamente com um CST que não prevê benefício fiscal, a critério da unidade federada. Criada a Regra de Validação I05f-20, impedindo a informação de um código de benefício fiscal que não corresponda ao CST utilizado, a critério da unidade federada. Criada a Regra de Validação I05f-30, exigindo que seja informado o valor do ICMS desonerado ou o motivo de desoneração quando se utiliza um código de benefício fiscal, a critério da unidade federada. Criada a Regra de Validação N07-10, exigindo informações sobre o diferimento quando se utiliza um CST de diferimento, a critério da unidade federada. Criada a Regra de Validação N12-84, exigindo o código de benefício fiscal quando se utiliza um CST de benefício fiscal, a critério da unidade federada. Criada a Regra de Validação N12-88, exigindo que o CST corresponda ao tipo de código de benefício fiscal informado, a critério da unidade federada. Criada a Regra de Validação N12-90, exigindo valor do ICMS desonerado e o motivo da desoneração, a critério da unidade federada. Criada a Regra de Validação N18-10, exigindo a informação do percentual da margem de valor Adicionado do ICMS ST Informada caso a modalidade de determinação da BC da ST seja MVA, a critério da unidade federada. Criada a Regra de Validação N18-20, não permitindo informação do percentual da margem de valor Adicionado do ICMS ST Informada caso a modalidade de determinação da BC da ST não for MVA, a critério da unidade federada. Criada a Regra de Validação W03-20, impedindo a informação de um valor de Base de Cálculo superior ao valor máximo estabelecido pela respectiva SEFAZ. Emitente: Criada a Regra de Validação 1C03-10, impedindo a informação de Razão Social do emitente diferente da existente no cadastro da SEFAZ. Destinatário: Criadas as Regras de Validação 5E17-10, 5E17-20, 5E1730, 5E17-40, 5E17-43, 5E17-46, 5E17-50, 5E17-60, 5E17-63, 5E17-70 e 5E17-80, para verificar se o destinatário está sendo informado corretamente ou se está em situação que o impeça de constar na NF-e como destinatário na operação com mercadoria ou prestação de serviços.  Serviço Autorização EPEC: Criadas as Regras de Validação 6P31-10, 6P31-20, 6P31-30, 6P31-40, 6P31-43, 6P31-46, 6P31-50, 6P31-60 e 6P31-63, para verificar se o destinatário está sendo informado corretamente ou se está em situação que o impeça de constar na NF-e como destinatário na operação com mercadoria ou prestação de serviços.
  3. 31 points
    O ACBr suporta impressoras USB ? Durante muito tempo, a resposta a essa pergunta foi: NÃO, você precisa usar a Porta COM, Spool do Windows (RAW), Compartilhamento de Rede ou algum outro método... Porém agora isso mudou... Agora componentes que usam o ACBrDevice, como por exemplo o ACBrPosPrinter (para Impressoras Não Fiscais) e o ACBrETQ (para Impressoras de Etiquetas), possuem suporte a portas USB de maneira nativo do Windows... Ou seja, sem a necessidade de DLLs externas... Isso significa que caso o seu equipamento esteja conectado ao PC, por uma Porta USB... Você poderá conectar os componentes do ACBr, simplesmente definindo na Propriedade Porta algo como "USB" Exemplos de uso: ACBrPosPrinter1.Porta := 'USB' - Tenta descobrir qual é a Primeira Impressora de Bobinas plugada na USB e faz uso dela, se encontrar.. ACBrPosPrinter1.Porta := 'USB:Elgin' - Tenta conexão em alguma Impressora USB, listada como sendo do Fabricante 'Elgin' ACBrPosPrinter1.Porta := 'USB:Sweda, SI-300S' - Tenta conexão na Impressora USB, do Fabricante "Sweda" e do Modelo "SI-300S". ACBrETQ1.Porta := 'USB' - Tenta descobrir qual é a Primeira Impressora de Etiquetas plugada na USB e faz uso dela, se encontrar.. ACBrETQ1.Porta := 'USB:Zebra, GC420t' - Tenta conexão com a Impressora USB do Fabricante "Zebra", e modelo "GC420t" Observe que essa nova implementação é totalmente diferente do método de Hook, onde usávamos a DLL do Fabricante, como túnel USB... Nesse novo cenário a comunicação USB é feita diretamente usando a API do Windows, ou seja, sem necessidade de DLLs externas. Para compreender um pouco mais, sobre esse método veja esse artigo O método de Hook ainda está disponível, usando o prefixo de porta, 'DLL:' Como os Equipamentos são identificados ? Todo Equipamento USB, possui um código de identificação do Fabricante, chamado de Vendor ID (VID), e também do Produto chamado de Product ID (PID). Essa numeração é controlada pela USB.ORG, e você pode encontras uma lista de Todos os "Vendors ID", nesse link A classe TACBrUSBIDDataBase, mantêm um Banco de Dados interno, chamado ACBrUSBID.ini, com o mapeamento dos principais Equipamentos do Mercado Brasileiro.. Esse Banco de Dados é um simples Arquivo do tipo INI, que é compilado como resource e adicionado ao componente... Clique aqui para ver o layout do Banco de Dados no Formato INI, observe os comentários no inicio do arquivo, com algumas instruções de como inserir novos equipamentos nele. Se você distribuir o arquivo ACBrUSBID.ini, na mesma pasta do Executável da sua aplicação, a classe TACBrUSBIDDataBase fará uso desse arquivo, ao invéz de usar o resource interno... Isso pode ser muito útil para atualizar a lista de Dispositivos conhecidos, sem necessitar compilar uma nova versão do programa, apenas atualizando o ACBrUSBID.ini Como posso listar os equipamentos identificados pelo ACBr ? Use a Força, leia os fontes... Vamos ver trechos de código, do Demo PosPrinterTeste {$IfDef MSWINDOWS} // Os métodos abaixo, somente estão disponíveis para compilação em Windows // Carrega a lista de Impressoras detectadas em: ACBrPosPrinter1.Device.WinUSB.DeviceList ACBrPosPrinter1.Device.WinUSB.FindUSBPrinters(); // Varre a lista de Impressoras USB detectadas, e adiciona as mesmas, nas opções de Porta for K := 0 to ACBrPosPrinter1.Device.WinUSB.DeviceList.Count-1 do cbxPorta.Items.Add('USB:'+ACBrPosPrinter1.Device.WinUSB.DeviceList.Items[K].DeviceName); {$EndIf} Como o ACBr nomeia os dispositivos ? O "DeviceName" será calculado, de acordo com as informações disponíveis no banco de Dados... Primeiro o ACBr usa a API do Windows para captura informações do VID (Vendor ID ou Fabricante) e o PID (Product ID ou Modelo), dos Equipamentos listados... Se o ACBr falhar nessa tarefa, o equipamento será ignorado (não será listado) Se for capturado com sucesso a descrição em FriendlyName, então ela será usada.. Caso contrário, o ACBr tentará compor o nome, baseado no VID e PID Se o VID do Fabricante for encontrado na sessão [Vendors] de ACBrUSBID.ini, então o VID será substituído pela Descrição do Fabricante... Observe que na sessão [Vendors], temos vários fabricantes que não são conhecidos no mercado Brasileiro, mas são de equipamentos OEM, de Empresas nacionais... Nós procuramos manter o nome Original do Fabricante, de acordo com a tabelas de VID da OSB.ORG Se o VID não tiver equivalência na relação de [Vendors] de ACBrUSBID.ini, então ele será listado com o próprio número VID, que são 4 algarismos em Hexadecimal... Exemplo: "0b1b" Procuramos pelo PID do Equipamento, na sessão específica do Fabricante. Se não houver uma chave com o PID, então o ACBr usará o próprio número PID, para Nomear o Modelo. O PID também é composto do 4 algarismos em Hexadecimal... Exemplo: "0001" Se encontrar uma entrada com o PID, dentro da sessão do Fabricante, então o ACBr usará a Descrição do Modelo, e poderá desprezar a descrição do Fabricante, se a Descrição do modelo possuir uma vírgula, Exemplo: 7008=Elgin, I9;1;1... Nesse caso será desprezada a descrição do Fabricante "20d1-Dascom" e será usada apenas a descrição do Modelo, "Elgin, I9". Detecção automática de Porta e Protocolo Como agora temos um Banco de Dados, que informa além da Descrição do equipamento, qual é o Tipo do mesmo e qual o protocolo que ele usa, então os componentes ACBrPosPrinter e ACBrETQ, podem fazer uso dessas informações... Ou seja, se o equipamento for detectado com sucesso, no momento da Ativação da Porta (durante a chamada ao método "Ativar"), será usado o Protocolo Definido no Banco de Dados. Se for detectado que o equipamento USB é na verdade uma porta COM virtual, então o ACBr irá preferir fazer uso da Porta COM virtual, chaveando para mesma, de forma transparente... Pois dessa forma ele tem um melhor suporte a leitura de informações do equipamento. Se for detectado que a porta USB possui um equipamento incompatível com o componente em questão, isso também será alertado... Exemplo, você tentar conectar em uma porta 'USB:Zebra, GC420t' no componente TACBrPosPrinter, então um erro será emitido, pois esse equipamento não é uma impressora de Bobinas Como a mágica funciona ? Reparem que foi adicionado ao repositório a Unit ACBrWinUSBDevice.pas, essa Unit implementa chamadas a SetupAPI do Windows, para detectar os Dispositivos USB que estão listados em uma determinada Classe de Equipamentos (Class GUID)... O estudo desse artigo, foi fundamental, para a criação dessa Unit. Uma vez capturada o nome da Interface do Equipamento USB (em TACBrUSBWinDevice.DeviceInterface), podemos acessá-lo usando funções de manipulação Arquivos da API do Windows, como: CreateFile, WriteFile, ReadFile. Nem todos os dispositivos USB implementam suporte aos métodos ReadFile ou WriteFile... ou seja, pode não funcionar em alguns dispositivos.. Se você souber qual é o nome da Interface USB do equipamento, poderá informar ela diretamente na propriedade "Porta" dos componentes... Exemplo: ACBrPosPrinter1.Porta := '\\?\usb#vid_1c8a&pid_3002#0000000000022#{28d78fad-5a12-11d1-ae5b-0000f803a8c2}'; Para dúvidas, suporte ou correções, por favor crie um novo tópico, clicando aqui Para testar, baixe uma nova versão do PosPrinterTeste.exe
  4. 25 points
    Terça, 07/05/2019 Se você está atento as notícias que enviamos periodicamente em nossos Boletins e publicamos aqui nessa área de Notícias do Fórum, já deve ter se preparado e atualizado seus sistemas... mas se ainda não o fez, por favor leia esse artigo, para evitar a parada da emissão de NFe/NFCe em seus clientes finais. Nas versões 1.00 a 1.10 da NT 2018.005, ficou estabelecido que no dia 07/05/2019 entrarão em vigor a exigência de novas validações relativas a NFe/NFCe. (Você pode achar todas as NTs na Biblioteca de nosso SVN) Porém, essas novas regras foram publicas com alguns complicadores, que podem ocasionar a paralisação da emissão de NFe/NFCe. Algumas Tags, somente podem ser enviadas em Produção, a partir do 07/05/19, porém são obrigatórias a partir dessa data. Hora, isso complica tudo.... Ou seja, se enviarmos a Tag em Produção antes de 07/05, o documento será rejeitado, mas se deixarmos de enviar a Tag após 07/05, o documento igualmente será rejeitado... Então, em outras palavras, o ENCAT espera que você aplique uma parametrização ou faça rollout, em TODOS os seus clientes finais, de um dia para outro!!! Afinal, não é uma boa prática de programação, inserir uma constante Hardcoded, como uma Data (07/05/19), na compilação do sistema final. Sem falar no fato de que não é incomum, algumas UFs não aplicarem a exigência na mesma Data publicada... O ENCAT agiu corretamente quando definiu a exigência das novas Tags, em homologação, em uma data anterior... Isso é ótimo, pois dá tempo para as Sw.Houses se ajustarem e testarem as modificações. Porém, o ENCAT poderia definir que as novas Tags são opcionais em Produção, até a data efetiva da exigência (07/05), quando então, passariam a ser obrigatórias... Isso daria tempo necessário, para as Sw.Houses aplicarem a atualização dos sistemas nos clientes finais, a fim de garantir que a emissão de documentos em produção já esteja funcionando Algumas Tags são exigidas ou não a critério da unidade Federativa Afinal o projeto NFe é ou não nacional ? É extremamente complicado para uma Sw.House saber o que pensa cada UF individualmente... A título de exemplo, a equipe do Projeto ACBr, efetuou uma pesquisa para saber se UFs exigiriam o Grupo de Responsável Técnico e se elas iriam ou não criar um portal para cadastro e identificação das Sw.Houses (idCSRT). Consultamos TODAS as SEFAZ, usando os canais (nem sempre) disponíveis, para submeter uma consulta... O resultado pode ser conferido em nosso Mapa Fiscal mas reparem em quantas UFs não conseguimos obter uma resposta clara... Conforme pode ser acompanhado ao longos das últimas versões da NT 2018.005, a exigência do Grupo Responsável Técnico sofreu diversas alterações, culminando na prorrogação indefinida para as informações relativas IDCSRT, e para as demais informações somente as UFs de AM, MS, PE, PR, SC e TO exigirão em 03/06, as demais UFs ou optaram por não exigir ou também deixaram para data futura.* Se para cada Grupo ou Tag novo, o ENCAT continuar adicionando o famigerado texto "A critério da UF", isso é receita para o CAOS na NFe... Um projeto que até então é o orgulho dos SEFAZ, e exemplo para o mundo todo, pode se perder em um emaranhado confuso de condições, que muitas vezes não são claras... Como eu posso me prevenir ? É necessário manter os fontes do Projeto ACBr atualizados em sua máquina, e permitir que a sua aplicação tenha flexibilidade de configuração da parametrização. Ou seja, permitir que o seu Suporte Técnico possa parametrizar de maneira rápida, a geração (ou não) de novas Tags, conforme o exigido pela UF do usuário final... Já pensou por exemplo, em "descer"para o PC do cliente final, uma parametrização da "nuvem"? Mas a final, quais são as modificações ? Ok.. vamos falar um pouco sobre cada uma delas... Grupo Responsável Técnico Este grupo teve algumas prorrogações ao longo das últimas versões da NT 2018.005, porém as UFs do AM, MS, PE, PR, SC e TO optaram por manter em 03/06/19* a exigência das informações deste grupo (exceto os dados relativos ao idCSRT). Para mais detalhes sobre o assunto acesse em nossa base de conhecimento, o tópico dedicado ao assunto escrito por nosso consultor @Italo Jurisato Junior Veja também, o nosso já citado, Mapa Fiscal ICMS Substituto Estas tags vem trazendo uma série de complicações aos desenvolvedores, desde que passou a ser aplicada já em ambiente de homologação. Com a entrada em produção, será necessário a atualização dos clientes, seja com uma nova versão das aplicações ou de forma mais simples, a parametrização para gerar as tags conforme a UF do mesmo. No tópico a seguir, o consultor @EMBarbosa dá orientações valiosas para minimizar o impacto em seus clientes. Identificação do Local de Retirada e Entrega Para mais detalhes sobre o assunto acesse em nossa base de conhecimento, o tópico dedicado ao assunto, escrito por nosso consultor @Italo Jurisato Junior Ainda não acabou... dia 20/05/19 tem mais mudanças... Fique atento as mudanças previstas para o dia 20/05, que podem impactar na autorização de NFCe... O ENCAT modificou a URL de consulta do QRCode, de praticamente todos os estados, e essas novas URL já são exigidas em homologação e deverão ser obrigatórios em Produção a partir de 20/05 Leia mais sobre esse assunto, no tópico abaixo, criado pela consultora @Juliana Tamizou. *Importante: Somente a exigência do Responsável Técnico será em 03/06/19, todos os demais itens permanecem em 07/05/19, por isso não deixe de se preparar
  5. 23 points
    Boa tarde, Conforme pôde ser observado por um grande número de membros da comunidade, desde os últimos dias de abril vinha ocorrendo na maioria das UFs a rejeição Endereço do site da UF de Consulta por chave de acesso diverge do previsto ao tentar enviar a NFCe em ambiente de homologação. Motivo da Rejeição Conforme foi divulgado posteriormente pela SEFAZ, de forma não oficial, ou seja, sem a publicação de NTs ou outras informações nos portais relativos a NFCe, esta rejeição passou a ocorrer devido a implementação da regra ZX03-20 existente na NT 2016.002 versão 1.61, a qual determina a validação da URL de Consulta por Chave de Acesso conforme tabela disponibilizada no portal do ENCAT. Estas validações entraram em vigor em ambiente de homologação no dia 22/04/2019 e em produção entrarão em 20/05/2019. Solução Os fontes do ACBr e por consequência o ACBrMonitorPlus SAC, foram atualizados com as URLs corretas conforme documentação disponível na página do ENCAT. Porém, em alguns casos, os endereços indicados pelo ENCAT ainda sim estavam incorretos. Com base no feedback de diversos usuários de nossa comunidade, novos ajustes foram enviados para o SVN do ACBr, no arquivo ACBrNFeServicos.ini Dicas para Minimizar o Impacto em seus clientes Se você utiliza o componente ACBrNFe para emissão da NFCe, procure sempre disponibilizar na mesma pasta do seu binário (executável) o arquivo ACBrNFeServicos.ini. Desta forma, o componente ACBrNFe, irá fazer uso do arquivo ACBrNFeServicos.ini existente no diretório, ao invés de usar as URLs internas, que são compiladas como "Resource", e anexadas ao componente... Isso é extremamente vantajoso, pois lhe confere grande agilidade na resolução de problemas de URLs... Caso sejam detectadas novas alterações de URLs, basta realizar a substituição do arquivo ACBrNFeServicos.ini, evitando portanto a necessidade de atualizar toda a aplicação. Eu não distribuo o ACBrNFeServicos.ini em meus instaladores? Preciso recompilar e atualizar meus clientes para que as novas URLs entrem em vigor ? Se você não quer ou não pode distribuir o ACBrNFeServicos.ini, na mesma pasta da sua aplicação, então não há outra maneira a não ser disponibilizar um novo binário para o seu cliente... Porém antes , faça um teste, é simples e rápido... Apenas copie o arquivo ACBrNFeServicos.ini no mesmo diretório de sua aplicação, e observe que as novas URLs serão utilizadas, pois o componente ACBrNFe irá priorizar o arquivo em disco. Ainda tem Dúvidas? Acesse os sub-fóruns sobre NFCe e crie um novo tópico relatando seu questionamento. Lembre-se que se for usuário do SAC Anual você também pode falar conosco pelo chat ACBr.
  6. 22 points
    Após uma atualização do Windows Update nos sistemas operacionais Windows 8 a 10, vários usuários começaram a ter problemas na conexão segura com o SEFAZ.... Onde geralmente foram exibidos os erros abaixo: Erro: 12175 - Um ou mais erros foram encontrados no certificado Secure Sockets Layer (SSL) enviado pelo servidor Erro: 12169 - O certificado SSL é inválido Erro: 12186 - Falha ao obter a Chave Privada do Certificado para comunicação segura Estes erros indicam uma falha na validação do certificado do servidor da SEFAZ, e entre as diversas causas que podem disparar este erro, podemos citar: Falta da cadeia de certificados instalado no cliente. Cadeia de certificados desatualizados. Erro no componente de validação do Windows. Erro no certificado da SEFAZ. SEFAZ enviou um certificado invalido. O problema foi confirmado pelo SEFAZ do PR, no comunicado abaixo: Para os usuários do Projeto ACBr, esse problema afetou apenas quem utiliza os componentes configurados com as bibliotecas Wincrypt ou CAPICOM pois os mesmo utilizam o sistema de validação do Windows. O problema não afetou usuários que usam a biblioteca OpenSSL. Em decorrência do problema, aplicamos um ajuste nos fontes da ACBrDFeSSL, visando ignorar erros na validação do certificado. Com isso a comunicação Segura ocorrerá normalmente... Os fontes alterados já se encontram no SVN... e excepcionalmente, efetuamos uma nova compilação do ACBrMonitorPLUS v 1.2.0.52, para os usuários do SAC Saiba mais sobre comunicação Segura do ACBr
  7. 21 points
    Olá pessoal, Sei que todos estão muito atarefados com seus programas por aí... Maaaasssss.... Precisamos de sua atenção para uma alteração nos componentes!!! Atualmente temos uma falta de padronização nas unidades de medidas das margens das impressões dos documentos fiscais. Cada impressão Report tem margens medidas com um formato. Isso não está bom. Note a tabela a seguir com as unidades de medidas das margens atual: DF-e Fortes Fast LazReport ESCPOS NF-e (Paisagem, Retrato, Inut, Evento, Simplificado) cm cm nd X NFC-e mm mm X X NFC-e (A4) cm mm X X SAT mm X X X CT-e (Evento) cm nd X X CT-e (A5, Retrato) nd nd X X CT-e (Inut, Inut Retrato) nd nd X X GNR-e nd nd nd X MDF-e (Retrato, Evento) cm nd X X NFS-e cm nd X X BP-e X X X X Legenda: mm – milímetros cm – centímetros nd – O componente poderia, mas não está atualizando as margens do report X – Não possui impressão nesse formato ou não interage com as margens. Nota: Os modelos em ESCPOS que existem não consideram as propriedades de margem. Afinal, não faz muito sentido mesmo. Como podem ver na tabela acima, muitos componentes não estão atualizando as margens. Isso significa que mesmo que configure uma margem, ela será simplesmente ignorada. Então a ideia é fazer com que esses componentes imprimam de acordo com a configuração. Além disso, queremos evitar qualquer possível confusão e por isso vamos padronizar as unidades de medidas. A unidade de medida escolhida foi milímetros (mm). Alguns dos motivos foram: A unidade de medida mm funciona bem tanto para impressões grandes (por exemplo A4) como para bobinas (80 mm); As pessoas estão acostumadas com mm porque é a unidade padrão de todos os geradores de relatório usados atualmente (Fast Report, Fortes Report, LazReport ...); Devido ao ponto anterior, usar mm vai nos poupar código de conversão de unidades; Mesmo que tivéssemos escolhido centímetros (cm), haveria quebra de compatibilidade por causa do SAT e NFC-e; Quando as alterações vão entrar em vigor? A previsão é que dia 14 de outubro, as alterações sejam enviadas ao SVN. Acreditamos que isso dá tempo suficiente, para conseguirmos avisar a todos e para que todos possam se preparar. As alterações já foram enviadas ao SVN. Veja nota no fim desse post. O que eu preciso verificar no meu aplicativo? A primeira coisa é verificar se você tem configuração de margem (seria bom que tivesse). Em caso afirmativo, como você está armazenando? Em que unidade está armazenando? cm ou mm? Vai ser necessário fazer alguma conversão? Verifique como você deseja manter a configuração? De posse das informações acima, faça um teste imprimindo todos os documentos que você usa. Isso vai ajudar você a prevenir qualquer problema antes de enviar o executável para o cliente. Sugerimos você a imprimir tanto antes como depois das alterações no componente. Assim você vai ter algo para comparar as impressões e ajustar as margens caso necessário. O que eu preciso fazer caso use o ACBrMonitor Plus? A nossa ideia é minimizar o impacto para quem usa o ACBrMonitor. Vamos colocar as informações o próximo post logo abaixo. Se ficarmos atentos a essas alterações, as impressões vão seguir o mesmo padrão e ninguém mais vai precisar se confundir. Atualização- 17/10/2019 As alterações já foram enviadas ao SVN. Agora todos os reports seguem o mesmo padrão: DF-e Fortes Fast LazReport ESCPOS NF-e (Paisagem, Retrato, Inut, Evento, Simplificado) mm mm mm X NFC-e mm mm X X NFC-e (A4) mm mm X X SAT mm X X X CT-e (Evento) mm mm X X CT-e (A5, Retrato) mm mm X X CT-e (Inut, Inut Retrato) mm mm X X GNR-e mm mm mm X MDF-e (Retrato, Evento) mm mm X X NFS-e mm mm X X BP-e X X X X Caso encontre algum problema, queira por favor criar um novo tópico.
  8. 20 points
    Olá pessoal, Foi publica a NT 2020/001 do MDF-e e ela já se encontra em nossa biblioteca. Resumo: O projeto MDF-e Integrado tem como objetivo a disponibilização, pelas Secretarias de Fazenda, de uma infraestrutura digital de documentos, legislações e processos voltados para a simplificação da emissão de documentos fiscais eletrônicos de transporte e integração, dentro de um ecossistema digital, que permite às Empresas Transportadoras de Cargas (ETC), Transportadores Autônomos de Cargas (TAC), ANTT, Administradores de Meios de Pagamentos e as próprias Secretarias de Fazenda, o aperfeiçoamento dos seus processos e compartilhamento de informações entre todos estes atores, a partir de um único documento e infraestrutura já consolidada e em uso por todos os envolvidos. Diante desse desafio, as Secretarias de Fazenda e o ENCAT, vêm nos últimos meses e em parceria com os diversos atores intervenientes, adotando uma série de ações estruturantes voltadas para superação das dificuldades atuais enfrentadas pelos órgãos de controle e geração de um ambiente operacional mais eficiente e competitivo, a exemplo das ações descritas abaixo: Aprovação de legislação nacional que normatizou o compartilhamento dos MDF-e dos 27 estados com os órgãos reguladores de transportes; Aprovação de legislação nacional que normatizou a obrigatoriedade de emissão do MDF-e em todas as operações de transporte, sejam elas intermunicipais ou interestaduais; Implantação da plataforma digital e registro de eventos eletrônicos que permitem ao transportador confirmar a entrega da mercadoria ao destinatário, possibilitando assim, a redução do prazo para o recebimento do frete por parte do caminhoneiro; Aprovação de legislação criando a Nota Fiscal Fácil (NFF), que permitirá aos contribuintes que operam com vendas de mercadorias e transportadores autônomos emitirem seus respectivos documentos fiscais de forma simplificada e a partir do seu próprio smartphone, conforme legislação publicada no D.O.U. do dia 19/12/2019 (Ajuste SINIEF No. 37 de 13 de dezembro de 2019); Publicação dessa NT, que estrutura o MDF-e de forma a possibilitar, entre outros benefícios: Geração automática do CIOT, pelo Sistema MDF-e, tanto para as modalidades TAC-Independente como TAC-Agregado; Automação do processo de fiscalização do Piso Mínimo do Frete (Tabela do Frete), nos termos da Resolução ANTT nº 5.849 de 16 de julho de 2019. Geração de informações para facilitar a negociação de direitos de recebimentos de fretes, por parte do TAC, junto a instituição financeira onde possui conta corrente, sem a interferência de atravessadores. Com essa NT temos: - Alterações de schema e regras de validação do MDF-e - Alterações no schema do modal rodoviário no grupo infANTT - Criação do evento de Pagamento da operação de transporte Portanto teremos um evento novo, criação do grupo Produto Predominante <prodPred> na parte geral do MDF-e, alteração no grupo informações do contratante, inclusão dos campos <xNome> e do <idEstrangeiro>, no modal rodoviário foi criado o grupo informações do pagamento do frete <infPag>. Novas Regras de Validação: Se modal rodoviário e indicador de pagamento for a prazo (tag:indPag=1): O grupo de informações a prazo deve ser informado (grupo:infPrazo). Implementação Obrigatória. Gera a Rejeição: 724. Se modal rodoviário, o grupo produto predominante deve estar informado (grupo: prodPred). Implementação Obrigatória. Gera a Rejeição: 725. Se modal rodoviário e MDF-e possuir apenas um DF-e transportado no grupo infDoc: O grupo de informações da carga lotação (infLotacao) deve estar informado. Implementação Facultativa. Gera a Rejeição: 726. Se modal rodoviário e informado grupo de pagamento, rejeitar se CNPJ/CPF do responsável pelo pagamento estiver inválido. Implementação Obrigatória. Gera a Rejeição: 727. Se moda rodoviário e informado grupo de pagamento, rejeitar se CNPJ do IPEF estiver inválido. Implementação Obrigatória. Gera a Rejeição: 728. Vai ocorrer alterações no componente? Sim Vai ocorrer alterações nos schemas? Sim Vou ter que adequar a minha aplicação? Sim Prazos: Ambiente de Homologação: 09/03/2020 Ambiente de Produção: 06/04/2020
  9. 20 points
    Olá Pessoal, O método Consultar agora possui um novo parâmetro chamado: AExtrairEventos. function Consultar(const AChave: String = ''; AExtrairEventos: Boolean = False) ; Boolean; Para quem utiliza os métodos direto da classe WebServices, deve acrescentar a seguinte linha: (...).WebServices.Consulta.ExtrairEventos := True ou False; O que ocorre quando o campo ExtrairEventos possui o valor True? Simples, quando realizamos um consulta a um DF-e além de retornar a sua situação é retornado também alguns eventos vinculados a ele, como por exemplo o evento de cancelamento. Se o valor de ExtrairEventos for True o método Consultar vai se encarregar de verificar se no retorno contem eventos, caso afirmativo eles serão extraídos e salvos em disco nas pastas conforme o seu tipo. Por exemplo, se no retorno tivermos o evento de cancelamento, será salvo na pasta: ...\Evento\Cancelamento o arquivo *-procEventoNFe.xml (caso estejamos consultando uma NF-e). Essa nova funcionalidade esta disponível nos componentes: ACBrBPe, ACBrCTe, ACBrMDFe, ACBrNF3e e ACBrNFe. Em breve tanto o ACBrMonitor quanto o ACBrLib vão passar a ter também essa funcionalidade. O que eu ganho com essa nova funcionalidade no método Consultar. Vamos supor que o seu cliente venha perder o XML da nota por exemplo, neste caso basta você ler os dados da nota do banco de dados, gerar e assinar o XML e por fim realizar uma consulta com o XML carregado, desta forma ao realizar a consulta a SEFAZ vai retornar o protocolo de autorização e o componente se encarrega de atualizar o XML acrescentando o protocolo nele, deixando-o assim um documento com validade jurídica. Mas se o seu cliente perder o XML de um evento como por exemplo o de cancelamento, não tinha como refazer o mesmo, pois não temos um método para consultar eventos, aliais a SEFAZ não possui um serviço para esse fim. Como dito acima o Consultar além de retornar a situação do documento e retorna também alguns eventos. Antes o componente ignorava esse conteúdo, mas agora foi implementado a extração dos eventos. Resumindo caso o seu cliente venha perder o XML de um evento (*-procEventoNFe.xml), lembre-se que o método Consultar pode recuperar ele novamente, desde que esse tipo de evento que foi perdido é retornado pelo Consultar. Espero que tenham gostado dessa nova funcionalidade.
  10. 19 points
    Olá pessoal, É com muita satisfação que comunicamos que agora os Fontes do Projeto ACBr, já foram ajustados para suportar o OpenSSL na versão 1.1.1 Antes de prosseguir, o que é OpenSSL ? "O OpenSSL é um kit de ferramentas robusto, de nível comercial e completo para os protocolos Transport Layer Security (TLS) e Secure Sockets Layer (SSL). É também uma biblioteca de criptografia de uso geral" https://www.openssl.org/ No Projeto ACBr, usamos o OpenSSL para diversas tarefas, como por exemplo: Comunicação Segura: Ele será necessário se você usa o componente ACBrMail, ou os componentes da aba ACBrTCP, que fazem comunicação Segura com sites, pelo protocolo HTTPS. A ACBrDFeSSL, que é usada por todos os componentes de Documentos Eletrônicos do ACBr, também podem usar o OpenSSL para comunicação Segura (como uma das opções) Criptografia: Ele é usado nos componentes ACBrEAD e pela ACBrDFeSSL para calcular e Verificar Hashs e Assinaturas digitais, usando diversos padrões de Criptografia O OpenSSL é uma excelente opção... na verdade, é a minha recomendação de uso, para quem usa certificados do tipo A1 A vantagem principal, é que com o OpenSSL, você está livre da necessidade de sempre manter o seu Windows Atualizado para que a comunicação segura com TLS1.2 funcione. Com o OpenSSL você poderia ter suporte a TLS1.2, mesmo no Windows XP. Como desvantagem, no ACBr, o OpenSSL, apenas suporta Certificados do tipo A1 Porque essa atualização é importante ? O principal motivo, é que as versões anteriores deixarão de ser suportadas e não mais receberão atualizações e correções, conforme podemos ver nessa página Mas outro motivo igualmente importante, é que atualmente é muito difícil de instalar uma versão antiga do OpenSSL em alguns sistemas Operacionais. Isso poderia ser um impedimento, para executar o ACBr em várias distribuições de Linux... A atualização dos fontes não foi um processo trivial, pois a API do OpenSSL recebeu modificações substanciais, desde a versão 1.0.x https://www.openssl.org/blog/blog/2018/09/11/release111/ https://wiki.tizen.org/Security/Tizen_5.X_Migration_from_OpenSSL_1.0.2_to_OpenSSL_1.1.1_guide Preciso atualizar meu cliente Final ? Não necessariamente... o código fonte do ACBr, é esperto o bastante para suportar todas as versões do OpenSSL, desde a série 0.9.8 até a 1.1.1.x. Mas é altamente recomendado que você atualize seus Scripts de Build, para usar e distribuir a última versão do OpenSSL no seu instalador automatizado... (veja como distribuir, abaixo) Lembre-se que se você precisa usar recursos mais novos, como comunicação segura com TLS1.2, precisará ter o seu OpenSSL atualizado, para versões mais novas... Todos os Scripts que geram os instaladores do ACBrMonitorPLUS e os pacotes da ACBrLib, assim o ACBrInstall_trunk2.exe, já foram atualizados para usar e distribuir as DLLs da nova versão 1.1.1.x Como o OpenSSL é distribuído ? Você pode encontrar versões compiladas do OpenSSL para praticamente qualquer Sistema Operacional existente... No SVN do ACBr, você encontrará as últimas versões das Bibliotecas compiladas para Windows em: http://svn.code.sf.net/p/acbr/code/trunk2/DLLs/OpenSSL/ Repare que em cada diretório, temos as pastas x86 (32 bits) e x64 (64 bits)... Se você compila seu programa em 32 bits, então você deve usar a versão 32 bits da DLL O OpenSSL é distribuído em em 2 arquivos. Sempre mantenha os dois arquivos juntos, e sempre use o par de arquivos da mesma versão. No Windows: Até a versão 1.0.x, os nomes dos arquivos eram: ssleay32.dll e libeay32.dll, e não havia distinção nos nomes das DLLs, entre as versões 32 e 64 bits. A partir da versão 1.1.0, os nomes dos arquivos mudaram para: libssl-1_1.dll e libcrypto-1_1.dll (32 bits) e libssl-1_1-x64.dll e libcrypto-1_1-x64.dll (64 bits) Tudo que você precisa fazer, é copiar o par de arquivos (libssl-1_1.dll e libcrypto-1_1.dll) para a mesma pasta do seu binário, ou seja, na mesma pasta onde está o seu .EXE (sim, você poderia copiar esses arquivos para o diretório System do Windows, mas isso deve ser evitado, pois pode causar conflitos com outras aplicações) As DLLs do OpenSSL que estão no repositório do ACBr, são compiladas com o Visual C Studio, portanto, será necessário que na máquina destino, exista as DLLs de RunTime do Visual C. Como centenas de programas tem essa mesma dependência, provavelmente as DLLs de RunTime já estão instaladas no seu Windows... Porém, caso você perceba o erro: "Este aplicativo não pôde ser iniciado porque não foi encontrado vcruntime140.dll", provavelmente o RunTime ainda não foi instalado, a solução nesse caso, é bastante simples, bastando instalar: http://svn.code.sf.net/p/acbr/code/trunk2/DLLs/Diversos/x86/VC_redist.x86.exe Você pode/deve, rodar esse procedimento no seu instalador, automatizado... isso pode ser feito de maneira silenciosa, e sem a intervenção do usuário... Veja esse artigo: No ACBrMonitorPLUS, usamos da seguinte maneira: VC_redist.x86.exe /install /passive /norestart No Linux: libssl.so.x.x.x - exemplos: libssl.so.1.1, libssl.so.10, libssl.so.1.1.1, libssl.so.1.1.0, libssl.so.1.0.2 , libssl.so.0.9.8, etc libcrypto.so.x.x.x - exemplos: libcrypto.so.1.1, libcrypto.so.10, libcrypto.so.1.1.1, libcrypto.so.1.1.0, libcrypto.so.1.0.2, libcrypto.so.0.9.8, etc O OpenSSL já vem instalado por padrão em várias distribuições Linux, caso contrário, use o seu gerenciador de pacotes, e instale o pacote "openssl" Veja mais sobre a distribuição de Bibliotecas em: https://acbr.sourceforge.io/ACBrLib/ComoInstalarDistribuir.html A nova rotina de Carga dinâmica das Bibliotecas do OpenSSL, que foram implementadas na Unit OpenSSLExt.pas, irá procura por vários nomes de arquivos, dando preferência para os arquivos mais novos. Ou seja, ela irá procurar pelas bibliotecas na versão 1.1.1.x, e não encontrando, procurará e pelas bibliotecas na versão 1.0.x ou inferiores Quer saber mais sobre como o ACBr usa o OpeSSL na criação e transmissão de Documentos Seguros ? Então de uma olhada nesse vídeo:
  11. 19 points
    Olá pessoal, Alguém já imaginou ou tem a necessidade de imprimir o boleto em uma impressora térmica? Pois bem, o @guilhermekm teve a necessidade, arregaçou as mangas e implementou um novo layout chamado lTermica80mm. Guilherme, muito obrigado pela colaboração, já esta disponível no repositório. Quero também agradecer ao @Doug Dela Bite pelos ajustes feitos na implementação do Guilherme, muito obrigado Douglas. Abaixo o Preview e a impressão do boleto feita em uma Epson TM-T20X. Esse layout esta disponível apenas para o Fortes Report, portanto convido aos mestres em Fast Report a fazerem o mesmo que o Guilherme e Douglas. Estou aguardando o layout para o Fast! Compatibilizei o LFM do Lazarus com o DFM do Delphi, sendo assim é para funcionar sem nenhum problema no Lazarus / Fortes Report. Veja aqui o tópico original:
  12. 19 points
    Bom dia a todos, Alguns desenvolvedores relataram problemas com os eventos, mais precisamente aqueles que carregam o XML do evento gerado pelas suas próprias aplicações. Detectamos que a SEFAZ sem querer querendo, resolveu utilizar códigos para novos eventos, códigos estes usados por outros eventos de outros tipos de Documentos Fiscais Eletrônicos. Como exemplo o código do evento Cancelamento por Substituição da NFC-e é o mesmo do evento de Encerramento do MDF-e. A função que converte o código em um enumerador acaba pegando o primeiro que ela encontra na lista, retornando um enumerador que não tem nada haver. A solução encontrada foi criar uma função de conversão para cada tipo de Documento Fiscal Eletrônico. Antes tínhamos a função StrToTpEvento, agora temos: StrToTpEventoNFe, StrToTpEventoCTe, StrToTpEventoMDFe e StrToTpEventoBPe. A função original: StrToTpEvento foi renomeada para StrToTpEvento_Old, função esta que não devemos mais utilizar pelo problema descrito acima. Pelo fato dela ter sido renomeada, quem a utiliza diretamente em alguma unit com certeza vai ocorrer erro de compilação. Para resolver esse problema, basta trocar o nome da função para a correspondente e se necessário incluir no uses uma das seguintes units: pcnConversaoNFe ou pcteConversaoCTe ou pmdfeConversaoMDFe ou pcnConversaoBPe. Observação: isso se você utiliza a função StrToTpEvento em alguma unit da sua aplicação, caso contrario não precisa se preocupar. Outra alteração que foi feita e que pode provocar uma exceção durante a execução da sua aplicação diz respeito ao código do documento fiscal. Desde o inicio nos manuais o ENCAT nos orienta a atribuir ao código do documento fiscal um numero aleatório, mas tem muitos desenvolvedores que simplesmente atribui o mesmo numero do documento fiscal. Exemplo da NF-e: O código do documento fiscais é o campo cNF que acaba recebendo o mesmo valor do numero do documento fiscal que é o campo nNF. Foi publicado a Nota Técnica 2019/001 que esta em anexo, nela temos a regra B03-10 que vai passar a comparar esses dois campos (cNF e nNF). A data de inicio dessa validação nas SEFAZ é: 01/07/2019 - Ambiente de Homologação e 02/09/2019 - Ambiente de Produção. A principio essa regra é valida somente para a NF-e e NFC-e, mas com certeza vai se estender para os demais tipos de documentos fiscais eletrônicos. Logo resolvemos incluir na função que gera a chave do documento a mesma validação a ser executada na SEFAZ, desta forma se os valores informados nos campos referente ao código e numero passarem pelo nosso validador, com certeza a sua nota não vai ser rejeitada na SEFAZ, quando essa regra for ativada. Vale lembrar que a regra B03-10 será obrigatória em todas as UF. Lembre-se, ao tentar emitir uma nota se aparecer a seguinte mensagem: Código Numérico inválido, Chave não Gerada, isso significa que o numero informado como código é exatamente igual ao numero do documento fiscal, no caso da NF-e /NFC-e (cNF = nNF). O valor de nNF tem que ser um numero sequencial. O valor de cNF tem que ser um numero aleatório. Na unit ACBrDFeUtil, criamos a função abaixo: function GerarCodigoDFe(AnDF: Integer): integer; Nela passamos como parâmetro o numero do documento fiscal, ou seja, o numero da nota (por exemplo) e ela gera aletoriamente e retorna o código para ser atribuído ao campo código (cNF, se tratando da NFe/NFCe). Essa função além de gerar o código aleatoriamente conforme orientação do ENCAT já valida conforme a regra B03-10. Observação: a função que gera a chave é utilizada pelos componentes: ACBrNFe, ACBrCTe, ACBrMDFe e ACBrBPe, logo a função que gera o código pode ser utilizada pelos desenvolvedores de qualquer um desses tipos de documentos fiscais. Prevenir é melhor do que remediar. NT2019_001 v1.00 - Regras de Validacao.pdf
  13. 19 points
    Olá pessoal, Com a NT 2018.005 foi introduzida uma nova rejeição para NFe: 938 - Rejeição: Não informada vBCSTRet, pST, vICMSSubstituto e vICMSSTRet. Os detalhes dessa rejeição foram alterados nas várias versões da NT, mas infelizmente isso já está causando algum problema (como podem ver nesse tópico aqui). Como é uma rejeição facultativa e cada UF tem uma legislação tivemos que adicionar uma nova propriedade no componente ACBrNFe para lidar com a situação. A nova propriedade se chama ForcarGerarTagRejeicao938. Após atualizar os componentes, não esqueça de reinstalar. O problema Como a descrição da rejeição explica, algumas UFs podem exigir a informação de algumas tags, como vICMSSubsituto, isso mesmo quando o valor da tag for zero. Por padrão o ACBrNFe não gera tags facultativas que são informadas com valor zero. E esse é o caso da tag vICMSSubstituto. Mas como essa é uma tag facultativa, não devia ser obrigatório para algumas UFs informá-la. E por isso, não podemos obrigar o ACBrNFe informar sempre. Assim a ideia é termos uma configuração que você possa alterar. Poderemos com essa propriedade forçar gerar a tag de acordo com a necessidade de seu cliente ou da UF dele. A solução A propriedade (ou configuração) criada ForcarGerarTagRejeicao938 foi adicionada no ACBrNFe de modo que pode ser acessada como no código abaixo: ACBrNFe1.Configuracoes.Geral.ForcarGerarTagRejeicao938:= fgtNunca; Ou talvez no Object Inspector como abaixo: Importante: Embora a propriedade esteja disponível para ser alterada no Object Inspector, você provavelmente vai querer parametrizar isso no seu aplicativo. Afinal, talvez você precise alterar essa propriedade de um cliente para outro, ou de uma data para outra. As opções são: fgtNunca -> Se o valor for zero, não vai forçar a geração da tag nunca; fgtSomenteProducao -> Força a tag ser gerada no ambiente de produção mesmo que o valor seja zero; fgtSomenteHomologacao -> Força a tag ser gerada no ambiente de homologação mesmo que o valor seja zero; fgtSempre -> mesmo que o valor seja zero, a tag será gerada sempre; A configuração padrão é fgtNunca conforme o comportamento do componente antes dessas alterações. Qual opção eu devo escolher? Como explicado, essa configuração foi necessária por causa de problemas em certas UFs. Então para escolher a melhor opção você precisa saber o que está sendo exigido no Webservice que você está acessando. Por exemplo, se você não está recebendo a rejeição, não há necessidade de alterar a configuração. Mas se está recebendo somente em homologação, quer dizer, a tag está sendo exigida somente em homologação, use a opção fgtSomenteHomologacao. E assim por diante.
  14. 18 points
    Bom dia. O Banco Central publicou informações sobre os planos de implantação dos Pagamentos Instantâneos no Brasil, o qual tem previsão de implementação em Novembro/2020. Os Pagamentos Instantâneos são as transferências monetárias eletrônicas na qual a transmissão da ordem de pagamento e a disponibilidade de fundos para o usuário recebedor ocorre em tempo real e cujo serviço está disponível durante 24 horas por dia, sete dias por semana e em todos os dias no ano. As transferências ocorrem diretamente da conta do usuário pagador para a conta do usuário recebedor, sem a necessidade de intermediários, o que propicia custos de transação menores. Conforme texto do BC, apresenta as seguintes vantagens... Sua implementação deve, além de aumentar a velocidade em que pagamentos ou transferências serão feitos e recebidos, também tem o potencial de alavancar a competitividade e a eficiência do mercado; baixar o custo, aumentar a segurança e aprimorar a experiência dos clientes; promover a inclusão financeira e preencher uma série de lacunas existentes na cesta de instrumentos de pagamentos disponíveis atualmente à população. Esse modelo está em linha com a revolução tecnológica em curso, possibilita a inovação e o surgimento de novos modelos de negócio e a redução do custo social relacionada ao uso de instrumentos baseados em papel. Para mais detalhes, clique aqui e acesse o portal do Banco Central. Att.
  15. 17 points
    Olá Pessoal, A SEFAZ-RS resolveu antecipar a liberação do ambiente de homologação. 02/03/2020 Implantada NT 2020.001 em Homologação Informamos que a NT 2020.001 que trata do MDF-e Integrado, encontra-se implantada no ambiente de homologação da SVRS. As regras de validação restritivas 725 e 726 deverão ser ativadas na próxima semana. Quero lembra-los que o componente ACBrMDFe já contempla todas as alterações publicadas na NT 2020/001, o programa exemplo foi alterado para exemplificar os novos campos, grupos bem como o novo evento. Os novos Schemas já estão disponíveis a um bom tempo. Na próxima versão do ACBrMonitor já vai estar disponível a atualização do manual do mesmo que mostra como gerar o arquivo INI do MDF-e com os novos campos e grupos, bem como gerar o arquivo INI do novo evento.
  16. 17 points
    Olá pessoal! Temos o prazer de informar que mais um novo componente foi adicionado ao projeto: ACBrLCDPR. O ACBrLCDPR foi criado para facilitar a geração do LCDPR - Livro Caixa Digital do Produtor Rural. Esse componente segue a mesma ideia de outros componentes para geração de arquivos como ACBrSPEDFiscal, ACBrSPEDPISCOFINS, ACBrSEF2, etc... Com ele você pode gerar o arquivo sem se preocupar com o layout do arquivo. A sua preocupação será apenas com as informações que precisa aprensentar. Como é um componente novo, temos consciência de que alguns ajustes talvez sejam necessários. Todos podem ficar à vontade reportar problemas. Podem fazer isso por criar um novo tópico com ajustes e anexar nele. Crie o tópico no subfórum ACBrTXT -> Outros (ACBrLFD, ACBrSEF2, etc). Mas queremos agradecer ao @Willian Hübner que pôs a mão na massa e fez a doação do componente que serviu como base dessa versão. Queremos também aproveitar a oportunidade para agradecer aos nossos usuários SAC. Seu apoio nos ajuda a continuar avançando.
  17. 16 points
    Em função do estado de emergência nacional para conter o surto viral de Corona Virus (COVID-19), O Projeto ACBr comunica aos membros: Conteúdos da área de vídeos do SAC ACBr estarão abertos para todo o público Como a orientação das autoridades de saúde é permanecer em casa, o Projeto ACBr entende que teremos de aproveitar o nosso tempo de uma forma diferente durante a quarentena. Como uma forma de solidariedade, os vídeos do SAC ACBr estarão abertos para todo o público (isso inclui o curso Dominando o ACBrMonitor) por tempo indeterminado. Você só precisa ser cadastrado no fórum para poder acessar livremente todos os nossos conteúdos gratuitamente. Os colaboradores do Projeto ACBr (inclusive os que trabalham em regime presencial) estarão trabalhando remotamente durante o período de Quarentena. Numa forma de zelar pela saúde de nossa equipe, todos os colaboradores do ACBr estarão trabalhando em seus respectivos lares. Dado a esse fato, pedimos a compreensão de todos os membros, que podem haver possíveis atrasos nas respostas do Fórum Aberto, Fórum do SAC e Chat ACBr. Todos os serviços citados continuarão em funcionamento seguindo às prerrogativas requiridas para a prevenção correta. Recomendamos à todos os membros que tomem as devidas previdências de segurança. Lavar as mãos e evitar aglomerações é o essencial, porém para conter a dissiminação do vírus, devemos ficar em nossos lares, abrindo mão de circular em locais públicos como bares, praças, praias, shoppings e etc sem necessidade. Cuidado com o contato com pessoas consideradas dentro do grupo de risco (pessoas idosas, com problemas respiratórios ou problemas graves de saúde em geral), pois o vírus tarda a manifestar seus sintomas, e muitas vezes os infectados acabam passando para outras pessoas antes mesmo de saberem que estão doentes. Independente da sua região, é tempo de estarmos unidos, porém não "juntos". Vamos aguardar esses tempos difíceis passarem para retomarmos nossas atividades normais, e esperamos que todos fiquem bem até lá. https://www.projetoacbr.com.br/forum/video/ https://www.projetoacbr.com.br/forum/video/browse/13-curso-dominando-o-acbrmonitor/
  18. 16 points
    Olá pessoal, Como alguns de vocês já notaram, estamos empenhados em fazer os componentes do projeto ACBr ficarem disponíveis em outras plataformas. Uma das maneiras que queremos fazer isso é por permitir que eles compilem em Delphi para Linux e Android. No entanto com isso precisamos fazer uma alteração nos pacotes existentes. Para que os componentes fiquem de acordo, os pacotes precisam ser separados em Designtime e Runtime. Não vou me delongar nesse necessidade no momento, mas quem quiser mais informações pode ver a documentação oficial do Delphi. Basicamente o significado é o seguinte: Pacote Runtime - O pacote é como se fosse um framework ou library encapsulando requisitos e disponibilizando classes e componentes que podem ser vinculados ao código, mas não a IDE. Pacote Designtime - O pacote é para ser instalado na IDE. Isso significa que ele altera a IDE, disponibilizando componentes ou editores de propriedades que são usados em tempo de design (design time ... dã...). Em menos palavras, é um pacote que joga o componente na lista de componentes do Delphi. Essa alteração já está em andamento e você vai notar vários novos pacotes iniciados por "DCLACBr" nas pastas relacionadas ao Delphi. Mas como temos muitos pacotes há ainda vários que precisam ser alterados para funcionar dessa maneira. Como era? E como está? Os pacotes anteriores eram criados como Designtime e Runtime ao mesmo tempo. Visto que algumas pessoas utilizam os pacotes apenas como runtime estamos mantendo os pacotes atuais como Runtime e movendo o código específico pra criar os pacotes Designtime . São esses pacotes Designtime que iniciam por "DCLACBr". ACBrInstall O ACBrInstall que está no SVN já está preparado para lidar com esses pacotes. Ele vai verificar os pacotes se que são apenas Runtime e procurar o Designtime correspondente. Além disso, você vai notar que o ACBrInstall agora lista outras plataformas por cada instalação do Delphi que você tiver. Mas ainda é preciso ajustes tanto nos componentes como no próprio ACBrInstall para que os pacotes sejam compilados para essas plataformas corretamente e para que os vários "path" do Delphi sejam corretamente configurados. Por exemplo, dependemos do projeto JCL para detectar outras plataformas (como Linux e Android). Como eles ainda não implementaram, talvez nós tenhamos que fazê-lo e disponibilizar para eles. Lazarus O Lazarus não tem tanto problemas com os pacotes serem RunTime e Designtime. Então ele não sofre do mesmo problema do Delphi. No entanto, com as mudanças nos arquivos, alguns pacotes do Lazarus tiveram que ser ajustados. Em especial o pacote ACBr_NFCe_DanfeRL.lpk foi removido. Os componentes dele agora se encontram no pacote ACBr_NFe_DanfeRL.lpk Conclusão Como sempre, uma alteração como essa pode gerar problemas e é por isso que estamos avisando a todos. Fiquem a vontade para criar novos tópicos para relatar problemas ou dificuldades. Apenas pedimos que tenham o cuidado de verificar o seguinte: A pasta inteira do ACBr está realmente atualizada? Você tentou reinstalar marcando a opção de apagar arquivos antigos? Já existe algum tópico sobre o assunto? Bom trabalho aí pessoal!
  19. 16 points
    Olá Pessoal, Já se encontra em nossa biblioteca a NT 2020/001 da NF-e segue abaixo um resumo sobre ela. Resumo: Este documento substituirá as Notas Técnicas(NT) 2012.002 e 2013.001 e tem por objetivo unificar as informações referentes à manifestação do destinatário na Nota Fiscal eletrônica (NF-e) modelo 55 e estender o serviço para ser usado também por Pessoa Física (CPF). A manifestação está prevista na cláusula décima-quinta-A do Ajuste SINIEF 7/2005, a qual permite que o destinatário da Nota Fiscal eletrônica confirme a sua participação na operação acobertada pela Nota Fiscal eletrônica emitida para o seu CNPJ/CPF, através dos eventos tratados a seguir. Conclusão: Não existe nenhuma implementação a ser feita no componente, simplesmente agora a pessoa física que possui um e-CPF (Certificado Digital) poderá realizar a Manifestação do Destinatário, ou seja, enviar para a SEFAZ um dos 4 tipos de eventos que engloba a Manifestação do Destinatário. O componente já esta apto a gerar o XML do respectivo evento com o CPF do destinatário em vez do CNPJ.
  20. 15 points
    Olá Pessoal, Ocorreu uma alteração no salvamento dos arquivos de envio e de retorno dos eventos e da inutilização. O motivo dessa alteração foi que esses arquivos estavam sendo salvos em dois lugares distintos. No caso dos eventos eles estavam sendo salvos na pasta configurada em PathEvento e em PathSalvar. Já os de inutilização estavam sendo salvos na pasta configurada em PathInu e em PathSalvar. Com a alteração os arquivos de envio e de retorno passam a ser salvos somente na pasta configurada em PathSalvar. Por outro lado, o resultado final do processamento dos eventos bem como da inutilização, ou seja, os arquivos *-procEventoNFe.xml (no caso da NF-e) e o *-procInutNFe.xml (no caso da NF-e) vão continuar sendo salvos nas pastas configuradas em PathEvento e PathInu respectivamente. Desta forma fica fácil para o desenvolvedor pegar por exemplo todos os XMLs referente aos cancelamentos (pasta ...\Evento\Cancelamento) compactar e enviar para a contabilidade. Antes era preciso excluir os arquivos de envio e de retorno para que estes não fossem incluídos no arquivo compactado. Quero lembrar a todos que essa alteração foi realizada nos componentes: ACBrBPe (Bilhete de Passagem Eletrônico), ACBrNF3e (Nota Fiscal de Energia Elétrica Eletrônica), ACBrCTe (Conhecimento de Transporte Eletrônico), ACBrMDFe (Manifesto de Documentos Fiscais Eletrônicos) e ACBrNFe (Nota Fiscal Eletrônica).
  21. 15 points
    Configurações do ACBrMail para os principais serviços de emails do mercado outlook smtp: smtp.office365.com porta: 587 tsl : true; ssl : false; hotmail smtp: smtp.live.com porta: 587 tsl : true; ssl : false; gmail smtp: smtp.gmail.com porta: 465 tsl : true; ssl : true; ativar apps menos seguros no link https://myaccount.google.com/lesssecureapps obs.: autenticação por dois fatores, desativa automaticamente a permissão de apps menos seguros. yahoo smtp: smtp.mail.yahoo.com.br porta: 587 tsl : true; ssl : false; password: não use a senha padrão da conta, precisará criar uma exclusiva para sua aplicação. siga os passos abaixo: criada pelo link https://login.yahoo.com/account/security#less-secure-apps e depois 'Gerenciar Senha de app', selecione 'Outro app' ,der um nome ao app, e clique gerar senha.; sendgrid smtp : smtp.sendgrid.net usuario: nome da conta senha : senha da conta tsl : true; ssl : false; porta: 465 Autor: @Aurino Locaweb From := '[email protected]'; FromName := 'Nome do Remetente'; Host := 'email-ssl.com.br'; Username := '[email protected]'; Password := 'Sua_Senha'; Port := '465'; SetTLS := False; SetSSL := True; SparkPost From := '[email protected]'; FromName := 'Nome do Remetente'; Host := 'smtp.sparkpostmail.com'; Username := 'SMTP_Injection'; Password := '8a93c971789791b0102d889dd8f5f9b40507288d'; // Sua API Key Port := '587'; SetTLS := True; SetSSL := False;
  22. 15 points
    Olá Pessoal, Venho informa-los que já esta disponível em nosso repositório o mais novo componente que agora se integra a suíte ACBr. ACBrNF3e - Nota Fiscal de Energia Elétrica Eletrônica. Esse componente segue os moldes dos demais componentes que emitem DF-e - Documentos Fiscais Eletrônicos. "O Projeto NF3e tem como objetivo a implantação de um modelo nacional de documento fiscal eletrônico (modelo 66) que venha substituir a sistemática atual de emissão da Nota Fiscal/Conta de Energia Elétrica (modelo 6), com validade jurídica garantida pela assinatura digital do emitente, simplificando as obrigações acessórias dos contribuintes e permitindo, ao mesmo tempo, o acompanhamento da emissão em tempo real pelo Fisco." Para saber mais sobre o NF3e convido a todos a visitarem o Portal da Nota Fiscal de Energia Elétrica Eletrônica - SVRS. Temos também em nossa biblioteca toda a documentação referente a esse novo modelo de documento fiscal, clique aqui para acessar nossa biblioteca. O que foi disponibilizado: Fontes do componente ACBrNF3e e os fontes do componente ACBrNF3eDANF3eESCPOS (usado para imprimir o DANF3E). Notem que existe a Nota Técnica 2020/001 onde apresenta 3 layouts de DANF3E, sendo dois no tamanho A4 (Retrato) e um a ser impresso em bobina. Convido a todos a contribuir com a implementação dos DANF3E tamanho A4 (Retrato) e refazer o layout em bobina segundo essa nova NT. Esta disponível também os pacotes de instalação dos dois componentes mencionados acima, tanto para o Delphi quanto para o Lazarus. E como de costume, também foi disponibilizado o programa exemplo tanto para o Delphi quanto para o Lazarus. Observação: O ACBrInstall_Trunk2 ainda não reconhece esse componente, logo a sua instalação deverá ser realizar através dos pacotes disponibilizados. Assim que possível estaremos disponibilizando uma nova versão do ACBrInstall_Trunk2 que vai instalar o ACBrNF3e e o componente para imprimir DANF3E automaticamente.
  23. 15 points
    Teste o SAC ACBr gratuitamente por 15 dias... saiba mais sobre a Conta Trial do SAC do ACBr Sobre A ACBrLib é um conjunto de bibliotecas compartilhadas, que torna possível o uso dos componentes do Projeto ACBr, em qualquer linguagem de programação. Cada componente principal do ACBr, foi encapsulado em uma Biblioteca independente. Exemplo: O componente ACBrPosPrinter (para impressão em EscPos), está encapsulado na biblioteca ACBrLibPosPrinter. Saiba mais sobre a ACBrLib em: https://www.projetoacbr.com.br/acbrlib/ Principais Características A ACBrLib é compilada em Windows (DLL) e Linux (SO), nas arquiteturas 32 e 64 bits, e convenções de chamada StdCall e Cdecl. Todos os Binários gerados para Windows, são versionados e assinados com o certificado digital do Projeto ACBr. Acompanham classes de Alto Nível, para facilitar o uso e integração com linguagens populares, como: Java, C#, VB e outras. O projeto ACBr e a ACBrLib, contam com uma vasta comunidade de usuários. O que ajuda muito no suporte, melhorias e contribuições. A ACBrLib e os componentes do Projeto ACBr são desenvolvidos em Object Pascal. A ACBrLib pode ser compilada com Lazarus /FPC Licença de uso Assim como todos os fontes do Projeto ACBr, a ACBrLib, Demos e Classes de Alto nível, são distribuídas em Código Aberto, usando a licença LGPL. http://licencas.softwarelivre.org/lgpl-3.0.pt-br.html https://pt.wikipedia.org/wiki/GNU_Lesser_General_Public_License Download Binários Link: https://www.projetoacbr.com.br/forum/files/category/36-acbrlib/ NOTA: Para baixar os binários, você precisa ser cadastrado no nosso fórum, e membro Ativo do SAC. Você pode criar uma conta Trial, em: https://www.projetoacbr.com.br/forum/sac/v2/cadastro/ Fontes Você pode baixar os Fontes do ACBr e da ACBrLib, direto do nosso repositório SVN. Veja instruções em: https://www.projetoacbr.com.br/fontes/ Exemplos de uso / Demos Link direto para download dos Demos por SVN: http://svn.code.sf.net/p/acbr/code/trunk2/Projetos/ACBrLib/Demos/ Documentação On-Line: https://acbr.sourceforge.io/ACBrLib/ACBrLib.html PDF: https://acbr.sourceforge.io/ACBrLib/ACBrLib.pdf Windows Help (CHM): https://acbr.sourceforge.io/ACBrLib/ACBrLib.chm Requisitos de Sistema Sistema Operacional: Windows XP ou superior 32/64; Linux 32/64 CPU: i386, x86_64 Dependências Alguns componentes do ACBr, fazem uso de bibliotecas de terceiros, como por exemplo: OpenSSL, e LibXML2. NOTA: Use bibliotecas da mesma arquitetura do seu sistema. Exemplo: Se você compila seu executável em 32 bits, precisará usar a ACBrLib e suas dependências, na versão 32 bits (mesmo que o Sistema Operacional seja 64 bits) Windows Você poderá encontrar as Dependências para a sua ACBrLib, no mesmo arquivo ZIP. Elas estão na Pasta “\dep\”. Linux Você precisará instalar as dependências, e criar os Links simbólicos necessários. Em nosso fórum, há um documento explicando como montar o ambiente no OpenSuse: https://www.projetoacbr.com.br/forum/files/file/413-desenvolvendo-no-linux-com-acbr/ Obter Suporte Gratuito Você pode obter suporte no Fórum do ACBr. Temos uma área específica para usuários da ACBrLib: https://www.projetoacbr.com.br/forum/forum/76-acbrlib/. Para criar um tópico, é necessário ter uma conta (gratuita) Profissional Se você precisa de Suporte Técnico especializado, diretamente com os desenvolvedores do ACBr. Você pode assinar o SAC do ACBr, saiba mais em: https://www.projetoacbr.com.br/forum/sac/sobre/ Como Instalar / Distribuir Windows O melhor lugar para copiar a ACBrLib e suas dependências, é na mesma pasta do seu Executável. Evite copiar os arquivos .DLL para diretórios do Sistema Operacional, como: Windows\System32 ou Windows\SysWow64 (isso evita conflito entre .DLLs) Não é necessário registrar as DLLs. Linux Como “root”, copie o arquivo .SO para a pasta /usr/lib ou /usr/lib64 (conforme o caso) Como usar: Consulte a documentação, para uma compreensão melhor. Copie/Instale a ACBrLib, conforme sugerido em: Como Instalar / Distribuir Verifique em Download, Exemplos de uso / Demos, se já existe para a sua linguagem, Classes de Alto nível, isso ajuda enormemente o uso da Biblioteca. Familiarize-se com o arquivo de configuração da ACBrLib (o arquivo é criado, se não existir, durante a Inicialização da ACBrLib) Chame o método de Inicialização da ACBrLib, LIB_inicializar (onde “LIB” seria o nome da ACBrLib utilizada exemplo: (POS, ETQ, NFE) Use os métodos da ACBrLib... Quando terminar, encerre a ACBrLib, chamando: LIB_Finalizar Histórico de mudanças Consulte na documentação, a sessão: “Histórico de Alterações”, de cada ACBrLib
  24. 15 points
    Responsável Técnico - Como fica o XML na prática? Com tantas alterações, ficou um pouco confuso entender quando e quais tags do grupo Responsável Técnico deverão ser enviadas. Segue então um resumo. Até 02/06/2019 Os XMLs deverão ser enviados sem este grupo, como tem sido feito até então. A partir de 03/06/2019 Para as UFs do AM, MS, PE, PR, SC e TO deverá ser incluído o grupo Responsável Técnico, porém sem as tags relativas ao idCSRT. Veja imagem a seguir. Após definição de data para exigência do idCSRT Quando as SEFAZ publicarem as datas para exigência destas tags, as mesmas passarão a ser exigidas no XML, caso contrário os mesmos passaram a ser rejeitados. A seguir, exemplo de XML com o grupo Responsável Técnico completo. Importante Até o presente momento nenhuma SEFAZ disponibilizou os mecanismos para geração do idCSRT, logo mesmo em homologação não é possível enviar estas tags. A partir de 07/05/2019 as UFs que optaram pela exigência do Grupo do Responsável Técnico ( AM, MS, PE, PR, SC e TO ), já aceitaram as tags de identificação também em ambiente de produção, porém rejeitarão os XMLs sem estas tags somente em 03/06/2019.
  25. 14 points
    O moderador e commiter do Projeto ACBr, @Régys Silveira, acaba de publicar em seu canal no YouTube, um excelente Curso de Firedac... São 19 vídeos, cobrindo tudo o que você precisa saber, sobre Firedac, do básico ao avançado... Se você ainda usa BDE, ou conectores de Banco de Dados antigos... assista o curso, e conheça todo o poder do FireDac Confira ainda, o Blog do Regys... https://regys.com.br/
  26. 14 points
    Há uns 6 anos atrás achei isso: tão verdade...
  27. 14 points
    Boa tarde Pessoal. Apenas repassando uma informação relacionada ao PAF-ECF / NFC-e: Foi publicado no dia 23/10 a noticia abaixo sobre NFC-e no portal da Secretaria de Estado da Fazenda de Santa Catarina (SEF-SC) Na última quarta-feira, 23/10, o secretário de Estado da Fazenda (SEF/SC), Paulo Eli, recebeu representantes da Associação Comercial e Industrial de Florianópolis (ACIF), da Associação Brasileira de Bares e Restaurantes de Santa Catarina (Abrasel) e da Câmara de Dirigentes Lojistas (CDL) de Florianópolis. O objetivo do encontro foi criar um grupo de trabalho com as entidades empresariais para a implantação da Nota Fiscal de Consumidor Eletrônica (NFC-e) em Santa Catarina. "Assumimos este compromisso, junto ao governador Carlos Moisés, de modernizar a máquina pública e Santa Catarina. Já iniciamos o processo e, até o próximo ano, iremos adotar a NFE-c", afirmou Eli. Empresário e membro do Conselho de Administração Nacional da Abrasel, Célio Salles reforçou que a medida é recebida com muita expectativa pelo setor varejista catarinense. "Há muito tempo estávamos aguardando esta notícia. Santa Catarina é um estado pioneiro e precisa atualizar seu sistema de acordo com o modelo nacional, que traz mais segurança e agilidade para o comerciante e o contribuinte", disse. Fonte: SEF/SC. http://www.sef.sc.gov.br/midia/noticia/2406
  28. 14 points
    Olá Pessoal, Já encontra-se disponível no repositório Trunk2 o mais novo componente ACBr - ACBrONE - Operador Nacional dos Estados. "O Operador Nacional dos Estados: ONE é o sistema responsável por integrar os documentos fiscais eletrônicos das Administrações Tributárias com as diversas tecnologias de identificação de veículos nas rodovias brasileiras. O sistema objetiva a geração dos eventos Registro de Passagem nos documentos fiscais transportados por intermédio da informação da placa do veículo e sua respectiva geolocalização, detectada por algum dispositivo ou tecnologia de monitoramento, o que auxilia nas ações de fiscalização de trânsito e de combate à sonegação." O texto acima foi retirado do Portal do Operador Nacional dos Estados - SVRS. Para mais informações visite o Portal. O manual do ONE já baixamos e se encontra em nossa biblioteca. Nas pastas: ...\Exemplos\ACBrDFe\ACBrONE\Delphi ===> temos o programa exemplo do componente. ...\Exemplos\ACBrDFe\Schemas\ONE ===> temos os schemas ...\Fontes\ACBrDFe\ACBrONE ===> temos os fontes ...\Pacotes\Delphi\ACBrDFe\ACBrONE ===> temos o pacote de instalação. Por enquanto o ACBrInstall_Trunk2 não esta preparado para instalar esse componente, logo será necessário a instalação manual através do Pacote. Observação1: apesar dos XMLs a serem enviados não precisam ser assinados digitalmente é preciso de um certificado digital para consumir os Webservices. Observação2: Não é qualquer empresa que pode usar o ONE é preciso que ela esteja cadastrada como uma Operadora.
  29. 14 points
    Implantação da versão 3.00a em Homologação Foi implantada a versão 3.00a do MDF-e na SVRS no ambiente de homologação às 13h30min do dia 14/06/2019. A versão de produção deverá ser implantada no dia 15 de julho de 2019. O componente ACBrMDFe já contempla essa nova versão. Esta faltando fazer o novo DAMDFE que vai conter além do código de barras o QR-Code, mas o novo DAMDFE só vai passar a ser exigido a partir de outubro de 2019. Comunicado sobre as datas de implantação da versão 3.00a Comunicamos que foi publicado a versão 3.00a do Manual de Orientação do Contribuinte do MDF-e e seus anexos. Reforçamos que esta nova versão prevista para entrar em homologação a partir do dia 14 de junho de 2019 e em produção a partir do dia 15 de julho de 2019, contempla a atualização do schema do MDF-e dentre outras modificações. Relativamente à definição dos padrões do QRCode previstos no arquivo XML do MDF-e, cuja especificação das configurações para impressão no DAMDFE estão detalhadas no Anexo II – Manual de Especificações Técnicas do DAMDFE, serão implementadas a partir de 07 de Outubro de 2019, quando entrará em vigor a obrigatoriedade de exibição do QRCode no layout do DAMDFE. Da mesma forma, as RV (regras de validação) G096 a G101 passarão a ser aplicadas em 01/07/2019 no ambiente de homologação e somente em 07 de Outubro de 2019 no ambiente de produção. Em nossa biblioteca você encontram os 3 Manuais (Visão Geral, Layout e DAMDFE) da versão 3.00a clique aqui para ter acesso.
  30. 13 points
    Porque devo assinar digitalmente meus executáveis ? O Produto final de quase todo desenvolvedor de Software para Windows, é gerar um arquivo compilado e executável, ou seja, um arquivo com a extensão .EXE ou .DLL As versões recentes do Windows, incorporaram recursos de segurança, como o SmartScreen, que podem causar alertas quando Binários não assinados são executados... O mesmo pode ocorre com módulos de Segurança de terceiros, instalados na máquina, como por exemplo: Antivírus e módulos de segurança bancários... Para evitar mensagens assustadoras, como a exibida abaixo, é necessário Assinar digitalmente o seu binário, com um certificado emitido por uma Autoridade Certificadora válida A título de exemplo, todos os binários distribuídos pelo Projeto ACBr, na área de Download do SAC ACBr, são assinados digitalmente com um certificado do Projeto ACBr... Reparem que não somente o Executável final, mas o instalador, também deve ser assinado.. Abaixo, temos a imagem de quando é executamos o Instalador do ACBrMonitorPLUS SAC Bem melhor, não ? Repare que o Fornecedor do binário, fica bem identificado na mensagem... Isso além de trazer mais confiança para o usuário final, ajuda os programas de segurança, a classificar de forma positiva, o seu Executável ou instalador, evitando bloqueios indevidos. Ok, gostei... mas como fazer para assinar meus executáveis ? O primeiro passo é comprar um Certificado do tipo "Code Signing"... Garanto que agora você pensou algo como: - Humm.. será que posso usar o meu certificado A1 ou A3 ? A resposta é NÃO... os certificados que usamos para os Documentos Fiscais eletrônicos brasileiros, não tem as características esperadas pelo Windows, para assinatura e validação de binários... Quanto aos certificados gerados de forma local, ou seja, os Self-Signed Certificates, eles funcionarão para a assinatura... e podem ser ótimos para testes... Mas eles não devem garantir o nível de confiabilidade ao seu binário, pois eles não são gerados por uma Autoridade Certificadora válida Algumas empresas Brasileiras, vendem o certificado do tipo Code Signing.. Veja por exemplo esse link... Porém o preço é praticamente "o valor de um Rim esquerdo"... (ps: veja mais empresas brasileiras, no post a seguir) Você pode comprar o Certificado do Tipo OV, que é bem mais barato... Na página da KSoftware tem um interessante artigo, descrevendo a diferença da versão OV x EV Eu preferi comprar nesse site gringo, porém isso pode exigir que você tenha um bom conhecimento de Inglês, pois o todo o processo de compra será feito em Inglês. Esse certificado, também exige um processo de validação... ou seja, a Empresa que irá emitir o certificado, precisa saber se você é você mesmo... A validação foi feita pela empresa Sectigo... eles enviam e-mails com links para você subir a documentação necessária... Como o certificado será emitido para uma Entidade Pessoa Jurídica, na etapa de envio de documentos de prova de identidade... eu enviei um PDF com o resultado da consulta de meu CNPJ, na Receita... Na etapa final de validação, eles efetuam uma ligação para o telefone de sua empresa, para fornecer um Token, que deve ser usado para gerar o certificado... portanto, o número de telefone na documentação que você enviar, deve ser um número que você possa atender... Achei o Site de Validação da Sectigo, bastante confuso... Eu preferi comprar a opção de 4 anos, para evitar esse penoso processo de compra, e pelos descontos oferecidos... Após todas as validações de identidade, eles lhe enviarão um Link para baixar o certificado em sua máquina... Será criado um arquivo PFX, e o processo de geração do Certificado na sua máquina, é muito semelhante a dos Certificados A1 brasileiros... Ufa.. já tenho o meu certificado em PFX... Como eu assino os binários ? Existem algumas ferramentas disponíveis... na página da KSoftware, você pode ler um tutorial, de como assinar usando o KSign Você poderá assinar binários facilmente, usando a interface gráfica deles: Para automatizar o processo de assinatura, você provavelmente ira preferir usar um utilitário de Linha de Comando... Repare que na mesma pasta onde o KSign foi instalado, existe o utilitário signtool.exe Use esse utilitário com a seguinte sintaxe: signtool.exe sign /du "http://seusite.com.br" /d "Descrição do seu Programa" /f "C:\Path\SeuCertificado.PFX" /p SenhaCertififcado /t "http://timestamp.comodoca.com" SeuBinario.exe sign -> Comando para assinatura /du -> Informa a URL do seu Site /d -> Informa uma descrição resumida do seu Programa /f -> Informa o Path completo para o seu Certificado (arquivo PFX) /p -> Informa a Senha para abertura do seu Certificado /t -> Informa um Servidor de Time Stamp, para que fique gravada a Data / Hora da assinatura Mas como assinar um Binário Windows, de dentro do Linux ?? Todo processo de Build e Deploy dos binários do ACBr, é executado em um Linux OpenSuse. A compilação de todas as plataformas que suportamos ocorre com Cross-Compiling, e automatizamos o processo de Build e Deploy, com o uso de Jenkins e Shell Scripts, Para transmitir o binário para fórum, criamos alguns utilitários que consomem a API do Invision Power Board Para a assinatura dos binários, creio que seria possível usar o próprio signtool.exe, com Wine... mas encontramos um interessante utilitário nativo em Linux, chamado osslsigncode, repare que a sintaxe é muito semelhante a do signtool.exe... osslsigncode sign -pkcs12 /path/SeuCertificado.pfx -pass SuaSenha -n "Descrição do seu Programa" -i http://seusite.com.br -t http://timestamp.comodoca.com -in SeuBinario.exe -out SeuBinario.exe.sign (como passo final, apague o arquivo original, SeuBinario.exe e renomeie SeuBinario.exe.sign para SeuBinario.exe)
  31. 13 points
    Bom dia a todos, Já esta disponível em nossa biblioteca a Nota Técnica 2019/001 versão 1.10 que trata sobre novas regras de validação. Essa nova versão é uma complementação da anterior que inclusive o seu resumo se encontra aqui. Resumo da NT:  • Criação/Alteração de regras de validação referentes a CST e Código de Benefício Fiscal, corrigindo algumas regras da versão anterior. • Criação de regra de validação correspondente rejeição 927, para informar os números dos itens em ordem sequencial. • Define que a regra de validação referente ao valor máximo da base de cálculo é por modelo de DF-e. Datas previstas para entrada em vigor: 22/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. Alterações na aplicação do desenvolvedor: Por conta da regra H02-10, a aplicação ao atribuir o numero do item ao campo: Prod.nItem, este tem que ser um numero sequencial, consecutivo e iniciado por 1. Para quem utiliza o ACBrMonitor, não precisa se preocupar, pois o mesmo utiliza um numero sequencial, consecutivo e iniciado por 1 para o numero do item. Novas Regras de Validação: Criada a Regra de Validação H02-10, com o objetivo de informar os números do item em ordem sequencial. Criadas regras de validação a Tributo - ICMS:  Criada a Regra de Validação N12-86, impedindo que se informe o código de benefício fiscal para CST de benefício fiscal, a critério da unidade federada. Rejeição 928: Informado código de benefício fiscal para CST sem benefício fiscal (campo cBenef) [nItem: nnn] Se informado CST e informado código de benefício fiscal: - Verificar se CST possui código de benefício fiscal, conforme tabela de código de benefício fiscal por UF. Observação 1: Implementação a critério da UF e por modelo de DF-e. Observação 2: Tabela de código de benefício fiscal por UF publicada no Portal Nacional da NF-e. Regras que tiveram seu (Campo-Seq) alterado bem como a sua redação: Regra N07-10 agora é N12-97. Rejeição 929: Informado CST de diferimento sem as informações de diferimento [nItem: nnn] Nova Redação: Não informados campos de valores do CST 51 (Diferimento): - modBC (id: N13), pRedBC (id: N14), vBC (id: N15), pICMS (id: N16), vICMSOp (id: N16a), pDif (id: N16b), vICMSDif (id: N16c), vICMS (id: N17). Observações: Implementação a critério da UF. Regra N12-84 agora é N12-85. Rejeição 930: CST com benefício fiscal e não informado o código de benefício fiscal (campo: cBenef) [nItem: nnn] Nova redação: Se informado CST e não informado código de benefício fiscal: - Verificar se CST exige código de benefício fiscal (tag: cBenef), conforme tabela de código de benefício fiscal por UF. Observação 1: Implementação a critério da UF, por modelo de DF-e e por CST. Observação 2: Tabela de código de benefício fiscal por UF publicada no Portal Nacional da NF-e Regra N12-88 agora é N12-94. Rejeição 931: Informado código de benefício fiscal (campo: cBenef) incompatível com CST e UF [nItem: nnn] Nova Redação: Se informado CST e informado código de benefício fiscal: - Verificar código de benefício fiscal está vigente e corresponde ao CST informado, conforme tabela de código de benefício fiscal por UF. Observação1: Tabela de código de benefício fiscal (cBenef) publicada no Portal Nacional da NF-e. Nota: Para itens sem benefício fiscal, a UF poderá exigir a informação da literal “SEM CBENEF” para alguns CST, vide tabela publicada no Portal Nacional da NF-e.
  32. 12 points
    Olá pessoal, Foi removido dos componentes ACBrBPe, ACBrCTe, ACBrMDFe, ACBrNFe e ACBrNF3e das units que geram o XML a propriedade AjustarTagNro. Essa propriedade foi acrescentada porque ao usar o OpenSSL, os campos string com menos de 3 caracteres geravam erros de validação. A motivação para a remoção dessa propriedade foi: Os componentes listados acima ao gerar o XML se o conteúdo do campo “nro” tiver apenas 1 ou 2 dígitos eram ajustados para 3 dígitos, consequentemente causando problemas na cidade de Barretos/SP, pois nessa cidade existem imóveis diferentes com numeração 10 e 010 (zero a esquerda) na mesma rua. Por incrível que pareça é zero mesmo e não a letra "O". Caso alguém venha ter problemas de validação com o campo nro, favor tratar da seguinte forma: ao alimentar o campo nro: nro := ExecutarAjusteTagNro(True, cNumero); Onde: cNumero é uma variável da sua aplicação que contem o numero do imóvel situado no logradouro. Devemos incluir em uses a unit pcnAuxiliar. A função ExecutarAjusteTagNro vai realizar o ajuste necessário para que o campo nro fique com no mínimo 3 dígitos.
  33. 12 points
    Já pensou em rodar o seu PDV ou ERP em Linux ? Há muito tempo os fontes do ACBr já compilavam em Linux através do Lazarus/FPC, e agora também é possível compilar o ACBr no Linux Ubuntu 64, com o Delphi Rio 10.3.3, usando a Linux FMX Mas quais são as vantagens de rodar em Linux ? Inúmeras vantagens.. o Linux é um Sistema Operacional, Livre, muito estável, seguro e robusto.. Não é a toa que grandes empresas, preferem rodar Linux em seu PDV (Carrefour, Pão de Açúcar, Droga Raia, etc..)... Um Linux bem configurado, é da filosofia Instale e Esqueça, e pode representar uma enorme economia, em atendimento no suporte técnico... Sem falar na evidente vantagem de custos de licenças, quando comparado ao Windows... Se você tiver um profissional "linuxer" na sua equipe, você ainda poderia criar uma distribuição Linux altamente personalizada para as necessidades do seu software, e permitir que o seu PDV/ERP seja carregado automaticamente, sem intervenção do usuário... Devo usar Lazarus ou Delphi ? Em ambos os casos, será necessário adaptações ou reescrita no seu código... Você deve evitar o uso de chamadas diretas a APIs do Windows, ou usar IFDEFs para isolar esses códigos... Você poderá encontrar muito exemplos de IFDEFs, nos fontes do ACBr. Se você já programa em Lazarus, deverá instalar o Lazarus em um Linux e testar a compilação do seu código usando a GTK2 ou QT... Se você programa em Delphi VCL, primeiro deverá converter seu sistema para FireMonkey (FMX)... Isso pode ser uma tarefa difícil se for feita manualmente, pois existem muitas diferenças entre a VCL e a FMX. Mas você pode contar com a ajuda de Ferramentas que ajudam na conversão, como a MidaConverter A Mida, gentilmente nos concedeu uma licença do Mida Converter... com isso, já iniciamos a migração dos Demos do ACBr de Delphi VCL, para Firemonkey.. Você poderá encontrá-los na pasta "Firemonkey", de cada Demo, exemplo: \ACBr\Exemplos\ACBrDFe\ACBrNFe\Firemonkey Veja abaixo, uma Imagem do Demo do ACBrNFe, já convertido para FireMonkey, e rodando no Linux Ubuntu 64 bits, com o Delphi 10.3.3, Linux FMX A FMX é o futuro do Delphi, a Embarcadero está investindo muitos recursos no aprimoramento da FMX... leia mais nessa página . Aplicações FMX são infinitamente mais bonitas que aplicações VCL, e os efeitos visuais que a FMX proporciona, são incríveis... Duvida ? Então veja o vídeo abaixo... Sempre será mais simples, migrar de Delphi VCL para Delphi FMX, do que de Delphi VCL para Lazarus... migrar de IDE é um processo "doloroso" e que necessita muito mais tempo, preparação e aprendizado... Não quero aqui, defender o Delphi ou o Lazarus... Acho que a questão de OpenSource, deve pesar apenas se o preço do Delphi for realmente um impedimento para você... Avalie muito bem o tempo e esforço necessário, em ambos os cenários...
  34. 12 points
    Olá pessoal, Foi publicado agora em dezembro/2019 um novo manual de especificação técnica do DANFE da NFC-e, trata-se da versão 5.1 desse manual. O que temos de novidade: 1. algumas correções que deixa mais claro o que pode e o que não pode ser impresso. 2. traz nessas correções as novas tags cMsg e xMsg que poderão estar presentes juntamente com as demais informações referente ao protocolo de autorização gerado pela SEFAZ-Autorizadora e o local correto da sua impressão. 3. apresenta o local correto de imprimir os valores de vFrete, vSeg, vDesc e vOutro que a critério da UF poderão estar discriminados por Itens. A versão 5.1 do Manual de Especificações Técnicas do DANFE da NFC-e se encontra em nossa biblioteca. Convido a todos a lerem. Observação: Os componentes para impressão do DANFE da NFC-e feitos em Fortes Report e EscPos já estão em conformidade com a versão 5.1 do manual, portanto procurem manter os fontes sempre atualizados.
  35. 12 points
    Nota: Atualizado em 05/11/19. Veja as configurações do ACBrMonitor no post do Júnior abaixo. Nota: Atualizado em 31/10/19 conforme post logo abaixo Olá a todos, Queremos informar que duas novas propriedades foram adicionadas ao DANFe em Fortes e que no momento estão funcionando apenas no formato retrato e Paisagem. São elas: ExpandirDadosAdicionaisAuto (padrão False) - Essa propriedade faz com que a área "Dados Adicionais" do DANFe se expanda para caber mais dados. Ela já existia no Fast Report e estamos trazendo ela pro Fortes também; ImprimeContinuacaoDadosAdicionaisPrimeiraPagina (padrão False) - Quando os "Dados Adicionais" não cabem no espaço reservado para eles, é criado um novo quadro "Continuação dos Dados Adicionais". As vezes esse quadro pode caber na primeira página, mas ele é jogado na página seguinte por questão de ficar na ordem do texto. Essa propriedade faz com que a continuação possa ser impresso na primeira página. Esse é o tópico que originou esse request Também enviamos uma alteração melhora (e muito) no uso do quadro "Dados Adicionais". O componente muitas vezes estava criando quebrando a linha desnecessariamente, causando até a impressão de uma página adicional quando isso não era necessário. Esperamos que isso os ajude a agradar seus clientes que querem economizar o número de páginas e os que preferem os dados na ordem certa, seja lá qual for o segmento que eles trabalhem. As alterações foram enviadas ao SVN na revisão 18063 18105. Agradecemos a todos que puderem testar e reportar qualquer problema. Pronto pessoal, obrigado pela atenção. Agora todo mundo voltando ao trabalho com animação!
  36. 12 points
    Olá Pessoal, A SEFAZ-MG esta gerando de forma indiscriminada namespace em todas as TAGs de retorno. Sendo que, segundo o Manual versão 7.02 (visão Geral da NF-e/NFC-e) item 3.2.1.2 que se refere a declaração namespace, deixa bem claro que o documento XML deverá ter uma única declaração de namespace no elemento raiz do documento. O retorno da SEFAZ-MG esta fugindo dessa regra e colocando o namespace e todas as TAGs do XML. Peço a todos que atualizem todos os fontes de todas as pastas e reinstale a suíte ACBr, pois enviamos para o repositório uma possível correção para o problema. Será disponibilizado uma nova versão do ACBrMonitor para que os usuários do mesmo tenham também o problema resolvido. Exemplo de como a SEFAZ-MG esta gerando o XML de retorno: Como deveria ser gerado, portanto o correto:
  37. 12 points
    30/08/2019 ATENÇÃO: Publicada a versão 1.30 da NT 2019.001 Publicada a versão 1.30 da NT 2019.001, que divulga novas regras de validação e atualiza regras existentes da NF-e/NFC-e versão 4.0, com os seguintes objetivos: • Informados os locais de publicação das tabelas de códigos de benefícios fiscais e de regras de validação opcionais por unidade federada • Novas datas de vigência para algumas regras de validação Publicada a tabela cBenef x CST atualizada até 30/08/2019 Assinado por: Coordenação Técnica do ENCAT Informações importantes nessa nova versão: 1.7 Comentários Sobre o Código de Benefício Fiscal O código de benefício fiscal (tag: cBenef), por tratar de situações particulares de cada unidade federada, tem sua definição também especificada pelas UF que o utilizam. Estas definições constam de tabela publicada no Portal Nacional da NF-e, na área “Diversos” da aba “Documentos”. Esta tabela tem sofrido atualizações com frequência maior do que a desejável, em virtude do fato que o uso dos códigos pelas empresas no ambiente de homologação tem evidenciado a necessidade de ações de correção de natureza emergencial por parte das Administrações Tributárias envolvidas. É esperado que em futuro próximo a tabela tenha a estabilidade necessária. 1.8 Novas Datas de Vigência para Algumas Regras de Validação Em função de necessidades ditadas pelas legislações de algumas unidades federadas, e atendendo a pleitos de contribuintes e de entidades associativas, as datas de início de exigência das regras de validação N12-85, N12-86, N12-90, N12-94 e N12-97 obedecerão ao disposto na tabela a seguir: UF Regra de validação N12-85 N12-86 N12-90 N12-94 N12-97 MT (3) (3) (2) (3) (*) PR (1) (1) (*) (2) (1) RJ (2) (2) (2) (2) (2) RS (2) (2) (2) (2) (2) demais UF (*) (*) (*) (*) (*) Onde a respectiva data de início de vigência corresponde a: (*) Regra de validação não será aplicada (1) Aplicação a partir de 02/09/2019 (2) Aplicação a partir de 01/10/2019 (3) Aplicação a partir de 01/01/2020 As datas aqui definidas, juntamente com todas as demais informações a respeito das regras de validação opcionais por UF, podem ser consultadas em tabela publicada no Portal Nacional da NFCe, na área “Regras de Validação” da aba “Desenvolvedor”. Para contribuintes estabelecidos no estado do Rio Grande do Sul, no caso das regras N12-85, N1286 e N12-94, o ambiente de autorização em produção, até 31/3/2020, e o ambiente de autorização em homologação até 09/2/2020, aceitarão três situações para o campo cBenef:  NULO (sem preenchimento do campo);  com a descrição "SEM CBENEF"; ou  com o código do benefício; neste último caso, é realizada a devida validação de compatibilidade com o CST informado.
  38. 12 points
    COMUNICADO IMPORTANTE Gostaríamos de comunicar que assinamos em 08/05/2019 um contrato que prevê a compra da operação de hardware da Bematech no Brasil pela empresa Elgin. Sujeito à aprovação pelo CADE (Conselho Administrativo de Defesa Econômica), o resultado da junção dessas operações ampliará de forma significativa a competitividade do mercado brasileiro no segmento de automação comercial. A operação Elgin-Bematech amplia a capacidade de inovação e entrega de valor aos clientes por meio da otimização do portfólio de hardware, geração de valor no ecossistema de distribuidores, revendas e assistências técnicas e liderança estratégica com foco na inovação de equipamentos e dispositivos inteligentes. Estamos bastante otimistas com o resultado dessa operação para todos e com os benefícios que em conjunto a nova companhia poderá levar aos seus stakeholders. A TOTVS segue com seu foco no mercado de software, bem como no desenvolvimento de novos negócios, conforme anunciado recentemente, na busca pelo crescimento esperado para esse e os próximos anos. Fonte: https://www.bematech.com.br/sobre-nos/
  39. 12 points
    Olá a todos, Para quem não sabe nas configurações do componente ACBrNFe, temos dentro do grupo Arquivos um subgrupo chamado DownloadNFe, que contem as propriedades PathDownload e SepararPorNome. Através dessas duas propriedades definimos o caminho onde os XML retornados pelo método DistribuicaoDFe vão ser salvos e se desejamos separar por nome ou não. A primeira alteração realizada foi a migração da definição dessas propriedades de configuração da unit ACBrNFeConfiguracoes para ACBrDFeConfiguracoes. A motivação para essa mudança é que a definição dessas propriedades também se encontravam nas units ACBrCTeConfiguracoes, ACBrMDFeConfiguracores e ACBrBPeConfiguracoes, agora temos em apenas um lugar, ou seja, na unit ACBrDFeConfiguracoes. Com essa mudança temos uma redução de código e caso futuramente tenhamos alguma correção ou melhoria, elas serão feitas em apenas um lugar, desta forma agilizando o tempo de manutenção do código. Como nem tudo são flores, quem tem em seu código as linhas para configurar o Download deverá fazer a seguinte alteração para que a aplicação seja compilada com sucesso (exemplo no caso da NF-e): Antes: ACBrNFe.Configuracoes.Arquivos.DownloadNFe.PathDownload Alteração: ACBrNFe.Configuracoes.Arquivos.DownloadDFe.PathDownload Falando em melhoria, antes tínhamos uma função chamada GetPathDownload que tem como finalidade gerar o Path final onde será gravado os XML referentes aos Resumos de Notas e Notas Completas. Agora além da função citada acima temos também a função GetPathDownloadEvento que tem como finalidade gerar o Path final onde será gravado os XML referentes aos Resumos de Eventos e Eventos Completos. O que motivou a criar essa nova função é que antes o DistribuicaoDFe ao salvar os XML referentes aos eventos estava usando o mesmo Path dos eventos enviados, ou seja, estava misturando os eventos enviados com os eventos baixados pelo DistribuicaoDFe. Resumindo, a primeira alteração visou a redução de código nos componentes ACBrNFe, ACBrCTe, ACBrMDFe e ACBrBPe e a segunda visou organização dos XML baixados pelo método DistribuicaoDFe. Qualquer duvida ou problemas, favor postar no fórum.
  40. 11 points
    Olá pessoal, Aproveitando os últimos minutos do segundo tempo, temos novidades para o inicio do ano que vem. Novidades da versão 1.40 da NT 2019/001 * Modifica a RV N12-94 para deixar mais específica a rejeição, criando assim a RV N12-98 com sua respectiva rejeição; A regra vai ser ativada a partir de 11/05/2020 em produção, verificando a existência e a vigência do cBenef. Assim, a RV N12-94, a partir dessa data, passará a verificar apenas se o cBenef é compatível com o CST. Essa nova regra permite que determinada UF possa validar apenas a existência do cBenef, caso não opte por validar a compatibilidade com o CST. A criação da RV N12-98 não traz impacto para os sistemas emissores que já estão preparados para a validação da RV N12-94, salvo o possível tratamento da mensagem da rejeição. Rejeição 946: Informado código de beneficio fiscal incorreto ou inexistente na UF. * Adiciona as exceções e modelos para as RV N12-85, N12-86, N12-90, N12-94, N12-97 e N12-98; Criação de Exceções para as Regras de Validação N12-85 (Se informado CST e não informado código de benefício fiscal), N12-86 (Se informado CST e informado código de benefício fiscal), N12-90 (Se CST de ICMS = (20, 30, 40, 41, 50, 70 ou 90)), N12-94 (Se informado CST e informado código de benefício fiscal), N12-97 (Não informados campos de valores do CST 51 (Diferimento)) e N12-98 (Se informado código de benefício fiscal) Trata-se de exceções que já haviam sido criadas e implementadas, tendo sido comunicadas por meio de aviso disponibilizado no Portal Nacional da NF-e. As Rejeições das Regras de Validação N12-85, N12-86, N12-90, N12-94 e N12-97 encontram-se no artigo referente a NT2019/001 versão 1.30 * Informa as Exceções e Datas aplicáveis as UF que ativaram as RV N12-85, N12-86, N12-90, N12-94 e N12-97; e que ativarão a N12-98; Quadro com datas de ativação das RV, respectivas exceções e possíveis modelos para UF que ativaram/estão ativando tais RV. Quadro já disponibilizado no Portal da NF-e. A única diferença é a indicação das opções de modelos (55; 65; ou 55/65). Tal quadro demonstra quais UF estão ativando as RV, bem como as exceções aplicadas e os modelos que de DF-e (55 e 65) em que se aplicam a tais RV. A tabela a seguir substitui a do item anterior (1.8), pois adiciona exceções e modelo aplicável. Na tabela a seguir encontram-se as Unidades da Federação que implementarão as Regras de Validação N12-85, N12-86, N12-90, N12-94, N12-97 e N12-98, previstas nesta Nota Técnica. Na legenda são encontradas as datas de aplicação, as exceções e os modelos aplicáveis (55/65), a critério da UF. Regra de validação - Aplicação e Exceções +----------------------------------------------------------------------------------------------------------+ | UF | N12-85 | N12-86 | N12-90 | N12-94 | N12-97 | N12-98 | +----------------------------------------------------------------------------------------------------------+ | PR | (D1), (55/65) | (D1), (55/65) | (D*) | (D2), (55/65) | (D1), (55/65) | (D3), (55/65) | +----------------------------------------------------------------------------------------------------------+ | RJ | (D2), (55/65) | (D2), (55/65) | (D2), (55/65) | (D2), (55/65) | (D2), (55/65) | (D3), (55/65) | | | (E2, E3) | (E2, E3) | (E2, E3) | (E2, E3) | (E2, E3) | (E2, E3) | +----------------------------------------------------------------------------------------------------------+ | RS | (D2), (55/65) | (D2), (55/65) | (D*) | (D*) | (D*) | (D3), (55/65) | | | (E3,E4) |(E3,E4) | | | | (E3,E4) | +----------------------------------------------------------------------------------------------------------+ |Demais UF | (D*) |(D*) | (D*) | (D*) | (D*) | (D*) | +----------------------------------------------------------------------------------------------------------+ Datas para aplicação das Regras de validação (D), com respectivo Modelo de DF-e: (D*) - Regra de validação não será aplicada; (D1) - Aplicação a partir de 02/09/2019; (D2) - Aplicação a partir de 01/10/2019; (D3) - Aplicação a partir de 11/05/2020 em Produção (Homologação: 16/03/2020) Aplicação aos Modelos de DF-e: (55); (65); ou (55/65) Exceções constantes nas Regras de Validação, a critério da UF: (E1) - Exceção 1: a RV não se aplica quando Finalidade de emissão da NF-e (tag: finNFe) igual a Devolução de Mercadoria e Identificador de local de destino da operação (tag: idDest) igual a Operação interestadual ou com o Exterior. (E2) - Exceção 2: a RV não se aplica quando Finalidade de emissão da NF-e (tag: finNFe) igual a Devolução de Mercadoria; (E3) - Exceção 3: a RV não se aplica quando Finalidade de emissão da NF-e (tag: finNFe) igual a NF-e de ajuste; (E4) - Exceção 4: a RV não se aplica quando Tipo de Operação (tag: tpNF) igual a Entrada. Observação: A Exceção 1, constante nas respectivas Regras de Validação, aplica-se a todas as UF. Assim, não necessita estar no quadro acima. As datas aqui definidas, juntamente com todas as demais informações a respeito das regras de validação opcionais por UF, podem ser consultadas em tabela publicada no Portal Nacional da NFC-e, na área “Regras de Validação” da aba “Desenvolvedor”. Para contribuintes estabelecidos no Estado do Rio Grande do Sul, as Regras de Validação N12-85 e N12-86 permitirão informar qualquer CST até 31/03/2020 no ambiente de autorização em produção, conforme tabela disponibilizada no Portal da NF-e. Em homologação, o contribuinte já pode testar a validação dessa Regras. A RV N12-94 será desativada para o Rio Grande do Sul a partir da publicação desta NT.  A RV N12-98 será ativada conforme as datas de homologação e produção previstas nesta NT. * Retira o modelo 65 da validação da RV B03-10 Datas de efetivação das modificações: Ambiente de Homologação: 16/03/2020 Ambiente de Produção: 11/05/2020 Como se tratam de regras de validação nos WebServices das SEFAZ-Autorizadoras, não se faz necessário nenhuma alteração nos fontes dos componentes e nem na aplicação. Para baixar a NT na integra favor acessar a nossa biblioteca.
  41. 11 points
    Olá pessoal, A SEFAZ do Pará não vai mais recepcionar as NF-e a partir do dia 02/09/2019. A partir dessa data os contribuintes do Pará devem encaminhar as suas notas para a SEFAZ-Virtual do Rio Grande do Sul. Conforme consta a noticia no site da SEFAZ-Pará. Para quem utiliza o componente ACBrNFe, deverá apenas atualizar os fontes recompilar a aplicação e distribuir a nova versão do mesmo para os seus clientes. Para quem utiliza o ACBrMonitor, vamos disponibilizar uma nova versão do mesmo, ai basta vocês atualizarem os seus clientes. Pela noticia da SEFAZ-Pará não teremos um período de transição, logo vamos nos preparar para a correria, pois dia 2 é uma segunda-feira. Detalhe importante não será necessário realizar nenhuma mudança na configuração do componente ou do Monitor, apenas atualizar.
  42. 11 points
    Uma maneira rápida de corrigir as URLs de sua aplicação que usa o ACBr, sem necessariamente instalar um novo programa, é atualizar o arquivo de Endereços dos WebServices, diretamente na máquina local Baixe o arquivo ACBrNFeServicos.ini, clicando na URL http://svn.code.sf.net/p/acbr/code/trunk2/Fontes/ACBrDFe/ACBrNFe/ACBrNFeServicos.ini (clique no link com o botão direito do Mouse, e Salvar Como..) Salve o arquivo ACBrNFeServicos.ini exatamente na mesma pasta do seu .EXE Feito isso, o ACBrNFe passará a carregar as URLs de WebServices desse arquivo, ao invés do resource interno do componente Lembre-se de atualizar o arquivo ACBrNFeServicos.ini a cada atualização do sistema
  43. 11 points
    Olá a todos! Devido a alguns usuários necessitarem de mais informações no canhoto do DANFe Retrato, foi criado uma nova propriedade que permite alterar o layout do canhoto: "PosCanhotoLayout". O @hleorj foi o culpado de termos isso implementado. Qual a ideia dessa propriedade? O objetivo de criar essa propriedade foi permitir a impressão do código de barras da chave de acesso no canhoto. Então, a propriedade PosCanhotoLayout tem no momento duas opções: prlPadro : Imprime o canhoto padrão prlBarra : Imprime o canhoto com chave de acesso  Veja as imagens abaixo do novo canhoto. Versão em Fortes Report: Versão em Fast Report:
  44. 10 points
    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.
  45. 10 points
    Boa tarde a todos, Já esta disponível em nossa biblioteca a Nota Técnica 2019/001 versão 1.20 que trata sobre as alterações nas regras de validação. Essa nova versão é uma complementação da anterior que inclusive o seu resumo se encontra aqui. Resumo da NT:  • Remoção da Regra 1C03-10 (A Regra 1C03-10 exigia que Razão Social do emitente informada na tag emit\xNome fosse exatamente igual ao cadastro da SEFAZ, o que se demonstrou problemático). • Correção na Descrição da Regra de Validação N12-90 (Retirada informação de aplicação somente em casos de operação interna). Se CST de ICMS = (20, 30, 40, 41, 50, 70 ou 90): - Verificar se informado o valor do ICMS desonerado (tag:vICMSDeson) e o Motivo da Desoneração (tag: motDesICMS). • Torna facultativas as regras N18-10 e N18-20 (Os tempos de implementação destas regras variam muito entre as diversas Sefaz autorizadoras, por isto a partir da versão 1.20 desta nota técnica estas regras são de aplicação facultativa). N18-10: Se o campo modBCST = “4” Margem Valor Agregado, obrigatório o preenchimento do campo pMVAST. N18-20: Se o campo modBCST <> “4” Margem Valor Agregado, não deverá ser preenchido o campo pMVAST . • Criado novo Valor para o Campo N18 (A tag modBCST passa a aceitar a opção “6=Valor da Operação”). Datas previstas para entrada em vigor: 26/08/2019 - Ambiente de Homologação; 02/09/2019 - Ambiente de Produção. Alterações no componente: Criado o valor dbisValordaOperacao, para o campo modBCST. Alterações na aplicação do desenvolvedor: Prever o uso do novo valor para os CST 10 e 30. Para quem utiliza o ACBrMonitor, basta atribuir o valor 6 ao campo modBCST para os CST 10 e 30 quando for o caso. Foi publicada uma nova tabela: cBenef x CST atualizada até 19/08/2019, a qual pode ser baixada aqui, além dos novos schemas para atender o novo valor do modBCST. Até o final desta semana estaremos disponibilizando os novos schemas para que semana que vem, vocês possam iniciar os testes em ambiente de homologação.
  46. 10 points
    Cross Compile de Linux para Win32 Baixe o Lazarus do Site oficial: https://www.lazarus-ide.org/ Exemplo de arquivos a serem baixados: lazarus-2.0.2-0.x86_64.rpm, fpc-3.0.4-1.x86_64.rpm, fpc-src-3.0.4-1.x86_64.rpm Instalar FPC e FPCSRC (em modo "root") rpm -U fpc* Instalar Lazarus (em modo "root") rpm -U lazarus* Testar a instalação do Lazarus (em modo normal) startlazarus Feche o Lazarus e acesse a pasta dos fontes do FPC cd /usr/share/fpcsrc/3.0.4 Compilar FPC em Win32 (em modo "root") make all OS_TARGET=win32 CPU_TARGET=i386 Instalar novas DCUs e Compilador no Linux (em modo "root") make crossinstall OS_TARGET=win32 CPU_TARGET=i386 INSTALL_PREFIX=/usr Editar /etc/fpc.cfg (em modo "root") Incluir antes da sessão "Linking" a linha -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/* Criar Link Simbólico para o compilador Win32 em /usr/bin (em modo "root") ln -s /usr/lib/fpc/3.0.4/ppcross386 /usr/bin/ppcross386 Configure o seu projeto, criando um novo Build Mode (em modo normal) Acesse Project Options -> Compiler Options -> Config and Target Target OS -> Win32 Target CPU -> i386 Se ocorrer erros na recompilação da IDE, e tiver dificuldades de descobrir o problema. Selecione em Mensagens, para não efetuar nenhum filtro Botão direito em Mensagems -> Filter non Urgent Messages -> Filter None Observe as mensagens, geralmente é acusada a falta de alguma Biblioteca compartilhada... No caso de dúvidas, por favor crie um novo tópico em: https://www.projetoacbr.com.br/forum/forum/12-object-pascal-delphi-lazarus/
  47. 10 points
    Bom dia a todos, 18/06/2019 Comunicado sobre as datas de implantação da versão 3.00a Comunicamos que foi publicado a versão 3.00a do Manual de Orientação do Contribuinte do CT-e/CT-e OS e seus anexos. Reforçamos que esta nova versão prevista para entrar em homologação a partir do dia 22 de Julho de 2019 e em produção a partir do dia 26 de Agosto de 2019, contempla a atualização do schema do CT-e, criação do Evento Comprovante de Entrega dentre outras modificações. Relativamente à definição dos padrões do QRCode previstos no arquivo XML do CT-e, cuja especificação das configurações para impressão no DACTE estão detalhadas no Anexo II – Manual de Especificações Técnicas do DACTE, serão implementadas a partir de 07 de Outubro de 2019, quando entrará em vigor a obrigatoriedade de exibição do QRCode no layout do DACTE. Da mesma forma, as RV G238 a G243 e N135 a N140 passarão a ser aplicadas em 02/09/2019 no ambiente de homologação e somente em 07 de Outubro de 2019 no ambiente de produção.
  48. 10 points
    Quais são as mudanças dessa nova versão 3.00a? Um breve resumo. Criação do Web Service síncrono de autorização Disciplina as regras para Uso Indevido Definição do QR Code do CT-e: RV´s 850 a 855 ; Definição da Consulta Pública resumida e consulta completa para atores do CT-e identificados pelo certificado digital; Eliminação do retCancCTe na resposta da consulta situação; Criação da tag ICMSST no evento EPEC e alteração da RV 642; RV 841 para informar fretamento no transporte de pessoas; Alteradas RV´s 837, 838, 839, 840: aplicar somente aos tipos Norm / Subst.; Unificação das regras de validação de chave de acesso: 592-596, 507, 610 => 236 701-708 => 842 (Chave do CT-e da ferrovia de origem) 591, 602-605, 508, 504 = > 843 (Chave da NF-e transportada) 544-549, 480, 538 => 844 (Chave do documento anterior) 450-454, 478, 479, 608 => 845 (Chave do CT-e multimodal) 761-768 => 846 (Chave do CT-e anulado) 769-776 => 847 (Chave do CT-e substituído) 777-784 => 849 (Chave CT-e complementado) 816-823 => 856 (Chave do CT-e cancelado referenciado no CT-e OS) 761-772, 615, 766-768 => 857 (Chave do CT-e OS anulados) 769-772, 616, 774-776 => 858 (Chave do CT-e OS substituído) 777-780, 785, 782-784 => 859 (Chave do CT-e OS complementados) RV 848: Validação chave de acesso do CT-e de anulação informado Criação do evento do comprovante de entrega (grifado no MOC em amarelo), RV´s 860, 863, 864, 865, 869, 870 e 871 Criação do evento de cancelamento do comprovante de entrega (grifado no MOC em amarelo), RV´s 866 RV do cancelamento associada ao comprovante de entrega: 862 RV de validação da IE do tomador na EPEC: Dispensa de validação da IE do tomador quando autorização de um CT-e EPEC RV para implementação a critério da UF para o responsável técnico: 867 Previsão de RV de implementação futura para o responsável técnico: 868 Exclusão da tag pICMSInterPart do leiaute do CT-e e CT-e OS (ver anexo I Leiaute). Em nossa biblioteca você encontram os 3 Manuais (Visão Geral, Layout e DACTE) da versão 3.00a clique aqui para ter acesso.
  49. 10 points
    CHAT ACBr - Novo recurso do Plano Anual - SAC Agora o ACBr tem seu chat exclusivo, utilizando a Plataforma de comunicação Flock, de forma semelhante as diversas outras ferramentas de comunicação instantânea existentes no mercado, porém com outros recursos interessantes, como: Integração com diversos serviços úteis Pode ser usado via Web, Desktop ou Mobile de forma fácil Permite a gestão de grupos de forma inteligente Você poderá participar de um chat privado, no qual estão todos os consultores do Projeto ACBr, além de diversos moderadores. Gostou da novidade? Para ter direito de participar deste grupo, basta ser assinante do SAC ACBr na modalidade Anual. Quer fazer parte desse Grupo? Clique aqui e contrate o SAC na modalidade Anual! Passo-a-passo para ingressar no Chat ACBr Assista ao vídeo, ou siga o tutorial abaixo: 1. Assim que confirmarmos sua inscrição no SAC Anual, você receberá um e-mail para cadastro no Flock, conforme imagem a seguir. Basta clicar em Join Now, e após a página do Flock ser aberta no navegador, aceite os termos de uso clicando em I Agree. 2. Insira seus dados de identificação e a seguir defina uma senha de acesso. 3. Após clicar em Next, você será direcionado a tela inicial do Flock, conforme imagem a seguir. 4. Pronto!! Agora basta clicar no grupo Assinantes SAC ACBr - Anual para aproveitar as vantagens de seu acesso exclusivo a mais este canal. Ainda em dúvida sobre as vantagens de ser assinante SAC Anual, fale com nossos consultores por email, telefone: (15) 2105-0750 ou ainda WhatsApp: (15) 99790-2976 Saiba mais sobre o Flock Ainda não é assinante do SAC na modalidade Anual? Clique aqui para contratar!
  50. 9 points
    Já temos a Data e Local Definidos... A segunda edição do Dia do ACBr, ocorrerá no Parque Tecnológico de Sorocaba, no dia 14 de Setembro de 2019 (Sábado). Reserve essa data na sua agenda, e não perca a chance de participar do 2o encontro da Maior Comunidade de Open Source para Automação Comercial do Brasil Em breve já devemos iniciar a construção de novo Site para a 2a edição do evento, com mais informações, como Grade, Palestrantes, Valor, duração etc...Além é claro, de abrir o acesso a inscrições com preços promocionais para o 1o Lote... (e lembrem-se que o primeiro inscrito recebe um brinde especial do ACBr) Quer Saber como foi o Evento anterior ? Acesse a página do Evento em: https://www.projetoacbr.com.br/diadoacbr/ Todas as palestras do evento anterior, foram Filmadas. No Link abaixo, você poderá ver a coleção de vídeos disponíveis... https://www.projetoacbr.com.br/forum/video/collection/4-dia-do-acbr-1a-edição/ Algumas palestras são abertas e podem ser assistidas por todos usuários do fórum... As demais estão disponíveis para os participantes do Evento anterior e usuários do SAC do ACBr, Como todas as palestras são filmadas, os usuários que se inscreverem no 2a edição do Dia do ACBr, não perderão nenhuma palestra... mesmo que elas ocorram de forma concomitante.. Quer ser um palestrante ? Se você tem interesse em palestrar ou ministrar Workshops, entre em contato conosco, de forma privada. Já estamos pensando na Grade de palestras e formato do evento... Por favor nos detalhe a sua ideia de palestra e porque você acha que o assunto é estratégico para o conhecimento da comunidade do ACBr.
×
×
  • Create New...