Painel de líderes

Olá Pessoal, Vamos atualizar esse tópico. Já foi finalizado os ajustes nos componentes: ACBrBPe, ACBrCTe, ACBrNF3e, ACBrNFCom e ACBrNFe. Os fontes alterados bem como os Schemas e os programas exemplos dos 5 componentes mencionados acima já estão no SVN. Quero lembrar que ainda não é possível enviar o XML contendo os novos campos para a SEFAZ, uma vez que esta ainda não liberou o ambiente de homologação que esta previsto para 01/07/2025. Estamos trabalhando já no componente ACBrNFSeX, mas como dito anteriormente até a postagem desse tópico não foi publicado os Schemas. No que se refere a NFSe temos duas questões: 1. A NT publicada com as mudanças no layout referente a Reforma Tributária é no layout da NFS-e Padrão Nacional (não confundir com ABRASF). 2. Hoje o componente ACBrNFSeX atende 1848 cidades, algumas delas contrataram provedores que usam a versão 1 do layout da ABRASF, outras contrataram provedores que usam a versão 2 do layout da ABRASF e outras contrataram provedores que tem layout próprio. Não sabemos qual a atitude dos provedores que utilizam a versão 1 ou 2 do layout da ABRASF bem como os que tem o seu próprio layout no que se refere a Reforma Tributária. Eles vão alterar o layout que usam para adequar a Reforma ou vão abandonar o layout em uso e vão passar a usar o layout da NFS-e Padrão Nacional? Não temos a resposta para essa pergunta. Até a próxima pessoal.

Olá Pessoal, É com grande alegria que informo a todos que o componente ACBrNFe já esta em conformidade com a NT 2025/002 versão 1.01 referente a Reforma Tributária. Já se encontra no SVN os fontes, os Schemas e o programa exemplo em Delphi que exemplifica como alimentar os novos campos. Quero deixar bem claro que o ambiente de homologação só vai estar liberado em 01/07/2025 para recepcionar os XML com os novos campos referente a Reforma Tributária. Portanto nem adianta tentar enviar que o XML vai ser rejeitado.

Olá pessoal. Me chamaram com dúvidas, então seguem alguns esclarecimentos pra quem procurar o tópico: AcbrExtrato1.Banco.ArquivoCertificado, o arquivo da chave pública tem que estar na extensão .pem; AcbrExtrato1.Banco.ArquivoChavePrivada, o arquivo da chave privada tem que estar na extensão .key; Para extrair com ACBR: function ExtrairChavesCertificado(aPfx: string; aSenha: string; var aChavePub: string; var aChavePri: string): Boolean; var ACBrOpenSSLUtils1: TACBrOpenSSLUtils; begin ACBrOpenSSLUtils1 := TACBrOpenSSLUtils.Create(nil); try if FilesExists(aPfx) then ACBrOpenSSLUtils1.LoadPFXFromFile(aPfx, aSenha) else ACBrOpenSSLUtils1.LoadPFXFromStr(aPfx, aSenha); if aChavePri.Contains(':\') then WriteToFile(aChavePri, ACBrOpenSSLUtils1.PrivateKeyAsString, True) else aChavePri := ACBrOpenSSLUtils1.PrivateKeyAsString; if aChavePub.Contains(':\') then WriteToFile(aChavePub, ACBrOpenSSLUtils1.CertificateAsString, True) else aChavePub := ACBrOpenSSLUtils1.CertificateAsString; Result := aChavePri.Length > 0; finally ACBrOpenSSLUtils1.Free; end; end; //para chamar: ExtrairChavesCertificado("CaminhoArquivoPFX", "SenhaDoCertificado", "CainhoSalvarChavePublica.pem" "CaminhoSalvarChavePrivada.key");

Estranho pois não fiz alterações locais nesses arquivos. Acho que o melhor para mim no momento é fazer a instalação do zero. Obrigado pela resposta.

Olá @Vitor Antonio Mezzalira, Essa resourcestring sErroObjetoNaoPrenchido é da unit ACBrAPIBase, do pacote ACBrTCP. Muito provavelmente existem alterações locais que estão conflitando. Verifique se os fontes da ACBrTPC estão todos atualizados e tente novamente. Não deveria ser necessário fazer a instalação do zero, apenas garantir que todo o fontes está atualizado e sem conflitos locais. Porém não deixa de ser uma opção.

Entendi... Bom, vou tentar entrar em contato com a contabilidade de um cliente nosso aqui, para ver se descubro qual sistema eles usam e como funciona as consultas DFe deles, se tem configuração de horário, etc. Enquanto isso seguirei com os testes e análises a respeito dessa consulta. Muito obrigado @BigWings e @Renato Rubinho pelas informações fornecidas!

Eu diria pra nunca passar 0 a não ser que você não saiba qual é o último NSU que a sua aplicação recebeu. Passar 0 tem que reprocessar tudo, não tem nenhuma vantagem. Passando 0 ou 100 você ainda vai receber consumo indevido se consultar dentro do intervalo de 1 hora que o contador consultou. Passando o ultNSU 100 após a 1 hora de intervalo, você vai receber os NSU 101 em diante, mesmo o contador já tendo até o 150. Isso no meu entendimento e experiência.

seguiu os passos que o André postou acima?

Não, o sequencial de ultNSU baixado é único. Quando você faz a consulta passando ultNSU=0, são baixados todos os registros existentes dos últimos 90 dias e essa "posição do ultNSU" é "atualizada" assim como é atualizada quando você pesquisa pelo ultNSU. Quando você consulta passando o ultNSU, deve passar o ultNSU recebido na última consulta seja de onde for. Se for feito em paralelo por dois sistemas eles precisam compartilhar o ultNSU recebido e o que foi recebido por um, não será recebido pelo outro. A solução que vi em casos reportados é que a contabilidade baixa a noite, fazendo a primeira consulta por ultNSU=0 todos os dias, reprocessando tudo. Em contrapartida, durante o dia, o sistema do cliente também faz a primeira consulta por ultNSU=0 todos os dias, reprocessando tudo e depois segue pelo ultNSU. ...corrigindo a desinformação que passei anteriormente, o @BigWings está correto, você pode passar o ultNSU diferente entre os dois sistemas, bastando aguardar o tempo mínimo de 1h entre as consultas. Se você utiliza o componente do ACBr, uma alternativa é um sistema consumir o serviço de distribuição e compartilhar os xmls recebidos para o outro sistema importar, você pode fazer isso utilizando o método a seguir do componente: ACBrNFe.WebServices.DistribuicaoDFe.retDistDFeInt.LerXMLFromFile( 'c:\temp\20220307130102-dist-dfe.xml' ). O programa de exemplo mostra como utilizar esse recurso no próprio botão de consulta.

Olá Pessoal, É com grande alegria que informo a todos que o componente ACBrNFe já esta em conformidade com a NT 2025/002 versão 1.01 referente a Reforma Tributária. Já se encontra no SVN os fontes, os Schemas e o programa exemplo em Delphi que exemplifica como alimentar os novos campos. Quero deixar bem claro que o ambiente de homologação só vai estar liberado em 01/07/2025 para recepcionar os XML com os novos campos referente a Reforma Tributária. Portanto nem adianta tentar enviar que o XML vai ser rejeitado.

Foi publicada a versão 25.1.E das tabelas fornecidas pelo IBPT, às quais já se encontram também em nosso SVN. As novas tabelas tem a vigência de 20/04/2025 até 31/05/2025. Para cumprimento da Lei 12.741/12, também conhecida como "De Olho no Imposto", não se esqueça de realizar a atualização de seus clientes. Fonte: De Olho no Imposto

Olá pessoal! Foi publicado o Ato Diat N º 018/2025 que revoga na data de sua publicação o Ato Diat Nº 059/2023 efetivamente revogando a obrigatoriedade do preenchimento dos campos vICMSDeson e motICMSDeson nos documentos fiscais eletrônicos emitidos pelos contribuintes catarinenses.

Olá pessoal! Foi publicado o AJUSTE SINIEF Nº 2, DE 11 DE ABRIL DE 2025 que aumenta o prazo em que o fisco deve guardar os documentos fiscais eletrônicos emitidos. Em outras palavras, agora o fisco deve guardar o XML da NF-e, CT-e, MDF-e, NFC-e, BP-e, NF3e, CTe-OS, GTV-e, DC-e, NFCom e todos os seus eventos vinculados por um período de 11 anos. O ajuste entra em vigor na data de sua publicação e produz efeitos a partir do primeiro dia do mês subsequente. Vale mencionar: O prazo de guarda desses documentos pelos contribuintes permanece inalterado conforme artigo 174 da Lei N° 5.172, de Outubro de 1996: Em outras palavras, a Sefaz precisa guardar os XMLs por 11 anos e o contribuinte precisa guardar o XML por 5 anos.

Olá pessoal! Consta na página própria do aplicativo de manifestação do destinatário mantido pela Sefaz de São Paulo o seguinte aviso informando que o programa será descontinuado. Vale lembrar que as soluções do ACBr possuem os métodos necessários para realizar o processo de manifestação do destinatário e o mesmo é explicado no curso sobre a DistribuiçãoDFe o qual os membros PRO e Corporativo possuem acesso. Um agradecimento ao membro de nossa comunidade @Felipe Mariano por compartilhar a informação em nosso servidor do Discord.

Olá pessoal! Foi publicada a primeira nota técnica de 2025 para o MDF-e. Alterações Modificações no leiaute A tag tpCarga do grupo que recebe as informações do produto predominante (prodPred) passa a aceitar também o valor 12 - Granel Pressurizada. Altera a definição da tag nCompra do grupo vale pedágio para "Identificador do vale pedágio obrigatório - IDVPO". Modifica a definição das infPag e Comp do leiaute do modal rodoviário para "Informações do pagamento do contrato" e "Componentes do pagamento do contrato" respectivamente. A tag tppComp do grupo dos componentes de pagamento do contrato passa a aceitar o valor 04-Frete. A tag tpValePed do grupo do Vale Pedágio passa a aceitar os valores 01-TAG e 04-Leitura de placa. Além disso os valores 02 (cupom) e 03(cartão) deixam de ser aceitos. A tag CIOT do grupo infCIOT passa a ser opcional. O leiaute do modal aquaviário ganha o campo Maritime Mobile Service Identify (MMSI) opcional de tamanho 9 aceitando apenas números. Além das modificações de leiaute, os regex também são atualizados nos arquivos de schema para aceitar o CNPJ alfanumérico. Regras de validação Adiciona regras de validação solicitadas pela ANTT para validar: A presença do NCM do produto predominante. A presença das informações de pagamento para carga lotação. O preenchimento dos dados bancários de pagamento para TAC e equiparado a TAC. O preenchimento do CIOT para TAC e equiparado a TAC. Datas Implantação Homologação: 07/2025 Implantação Produção: 10/2025 E como fica o ACBr? As soluções do ACBr serão revisadas e quaisquer modificações necessárias serão disponibilizadas em tempo hábil para que possam realizar testes em homologação. Leia a nota técnica na íntegra AQUI.

Boa tarde @Eduardo Zambiazzi, Já esta no SVN.

Boa tarde, Criada a TK-6932 para avaliação. Obrigado pela contribuição.

Olá pessoal! Este tópico tem o objetivo de centralizar as informações disponíveis sobre a Reforma Tributária para facilitar e ajudar aqueles que estão buscando mais conhecimentos sobre o assunto para se preparar. Notas Técnicas 2025 Nota técnica com as modificações específicas para NF-e\NFC-e: Nota técnica com as modificações específicas para BP-e: Nota técnica com as modificações específicas para NF3e: Nota técnica com as modificações específicas para NFCom: 2024 Nota técnica com as modificações específicas para NF-e\NFC-e: Nota técnica com as modificações específicas para CT-e\CTe-OS\BP-e\NF3-e\NFCom: Nota Técnica com as modificações específicas para NFS-e: Modificações no ACBr Edições do Papo PRO ACBr (mais recentes primeiro) 2025 2024 Tópicos da Comunidade discutindo sobre o assunto.

Para o consumo de algumas APIs do BB como as API PIX e API Pagamento em Lote utilizando as soluções ACBr (Componentes Delphi/Lazarus, ACBrMonitorPlus e ACBrLib) é necessária a troca de certificados para Autenticação mTLS (Mutual TLS authentication). É um tipo de autenticação que ambos, cliente e servidor, apresentam certificados digitais para serem validados pelo par. Ou seja, no caso da API de Pagamentos, para conseguir efetuar um request (seja ele de envio de remessa, consulta, cancelamento, etc.) ele deverá apresentar o seu certificado, que será validado pelo BB. Da mesma forma, o BB disponibilizará o seu certificado, que será validado pelo cliente. Em caso de confirmação de ambos, a autenticação será efetuada. Os certificados autorizados pelo BB para a autenticação mútua são do tipo A1, em formato .pem, com a cadeia inteira (Certificado > Intermediarias > Raiz), emitidos por uma CA válida (exemplos: Digicert, Verisign, ICP Brasil). Passo a passo para envio de certificado no Portal Developers - Windows Caso já possua o certificado instalado em sua máquina, gentileza seguir o passo a passo indicado abaixo Roteiro para exportação de chave pública: No prompt do Windows digite: certmgr.msc Clique na pasta Pessoal e, em seguida, na pasta Certificados Clique com o botão esquerdo duas vezes sobre o certificado que deseja exportar e, na aba "Detalhes", selecione Copiar para Arquivo ... Clique em Avançar (na tela de bem-vindo ao assistente de para exportação de certificados) e, em seguida, novamente Avançar. Na tela a seguir mantenha a opção "Não, não exportar a chave privada”. Clique em Avançar e marque a opção X.509 codificado no base 64 (*.cer) A seguir aparecerá uma tela para você escolher o local e o nome do arquivo .CER a ser exportado . Salve o certificado com o nome Empresa para facilitar mais adiante. Você vai receber uma mensagem que foi exportado com êxito o certificado. Pronto, você exportou o certificado da Empresa a ser colado em campo específico no Portal Developers. Exportar os demais certificados (Certificado intermediário e Raiz do Certificado) Realizar os mesmos procedimentos acima. Dica! Se entre o primeiro certificado (raiz) e o último (certificado da empresa) existirem outros intermediários, repetir o procedimento para cada um deles, respeitando a ordem de cima pra baixo (intermediário1, Intermediário2 etc.). Exportar o certificado raiz O certificado Raiz é o primeiro da cadeia no Caminho de Certificação conforme exemplo abaixo: Selecione o Certificado Raiz, o primeiro de cima para baixo conforme indicado na imagem acima, e depois realize os mesmos procedimentos realizados com Certificado da empresa. Clique em Exibir Certificado > Detalhes > Copiar para arquivo > Avançar > Selecione o formato x.509 codificado na base 64 (*cer) e clique em Avançar. Salve o certificado com o nome Raiz para facilitar mais adiante. Acesse o Portal Developers. Selecione a API para a qual será encaminhado o certificado. Clique em Certificados. São duas opções disponíveis: • A primeira sobre “Como obter os certificados e identificar as requisições feitas pelo BB?”, que possibilita baixar o Certificado BB. • A segunda opção é a que será usada para enviar os seus certificados obtidos por uma CA (organização responsável pela emissão de Certificados Digitais) para o BB. Clique em Enviar Certificado. A tela apresentada mostra como adicionar a Cadeia de Certificados. Dica: Na maioria das vezes, existem 4 certificados. Um certificado da empresa, dois certificados intermediários e um certificado raiz. Clique duas vezes em Adicionar certificado, para incluir cada um deles no respectivo botão. IMPORTANTE: NÃO clicar em (Enviar), antes de inserir TODOS os certificados. O envio é feito somente ao final do processo. São duas formas de inserção do certificado: • fazendo a importação do certificado, clicando em Importar Certificado. É a melhor opção, pois o conteúdo do certificado é colado no campo respectivo, evitando alguma falha no processo de copiar/colar. OU • abrindo o certificado com um editor de texto (Bloco de Notas, Notepad++ ou similar), copiando todo o conteúdo do certificado (Ctrl+C) e colando (Ctrl+V) no campo. Importar Certificado: Podem ser importados os arquivos de certificados com extensão .pem, .ctr, .cer e .cert. Se, durante a importação do certificado for mostrada a mensagem de erro “Certificado em formato inválido”, como abaixo: verifique se há alguma inconsistência no arquivo, fazendo um teste na página: https://certlogik.com/decoder/ Este decodificador faz alguns ajustes na formatação do conteúdo. Experimente copiar o arquivo criado no decodificador e colar novamente no campo do certificado a ser enviado para o Banco do Brasil. Só isso já soluciona o problema de formato inválido. Após adicionar todos os certificados separadamente, conforme os passos informados acima, clique em Enviar. Será exibida rapidamente no canto superior direito a mensagem "Requisição feita com sucesso" e você será direcionado para a tela abaixo: O campo Número Solicitação é a identidade da requisição. Ele deverá ser informado quando você precisar se referir ao envio do certificado. O campo Situação passará para Sucesso assim que o certificado for internalizado, o que ocorre no mesmo dia.

Olá pessoal, Com o confinamento das pessoas por conta do Corona Vírus, o comercio varejista esta realizando a entrega de produtos comprados pelos clientes, não da forma tradicional, ou seja, presencial. Alguns estabelecimentos adotaram a Entrega (delivery), e com isso, resolveram cobrar uma taxa, que nada mais é do que o frete. Agora fica a duvida, como informar esse valor na NFC-e? 1 - Informar que a entrega será realizada a domicilio e que o frete é por conta do destinatário. Ide.indPres := pcEntregaDomicilio; // Valor 4 Transp.modFrete := mfContaDestinatario; // Valor 1 2 - Informar o Frete nos Itens e no Total Esse processo é análogo ao preenchimento de Frete, na NFe. Se você nunca necessitou trabalhar com Frete, veja abaixo, uma explicação de como calcular o mesmo, fornecida pelo colega @marcopoloviana, do Portal SAC Fiscal Primeiro Passo: Calcular o RATEIO DO VALOR DA ENTREGA entre os itens do cupom. Fórmula: (Valor do produto / Valor total dos produtos) x Valor do frete Exemplo: O cliente adquiriu 3 produtos nos valores de R$ 20,00, R$ 50,00 e R$ 30,00 respectivamente e pagou taxa de entrega de R$ 20,00. O valor total dos produtos no cupom foi de R$ 100,00. Fórmula: (Valor do produto / Valor total dos produtos) x Valor da entrega Produto 1: (R$ 20,00 / R$ 100,00) x R$ 20,00 = R$ 4,00 (vFrete item 1) Produto 2: (R$ 50,00 / R$ 100,00) x R$ 20,00 = R$ 10,00 (vFrete item 2) Produto 3: (R$ 30,00 / R$ 100,00) x R$ 20,00 = R$ 6,00 (vFrete item 3) Neste exemplo acima mostra que o valor da entrega foi divido em R$ 4,00, R$ 10,00 e R$ 6,00 respectivamente em cada produto totalizando R$ 20,00 da entrega. Segundo Passo: Informar o valor do frete de cada item: Prod.vFrete := ValorRateioFreteItem; // Veja explicação no Primeiro Passo Terceiro Passo: Informar os totais (frete e valor da nota). Total.ICMSTot.vFrete := ValorTotalFrete Total.ICMSTot.vNF := (ValorTotalProd) - (ValorTotalDesc) - (ValorTotalICMSDeson) + (ValorTotalFrete) + (ValorTotalOutro); OBS: Existem outros componentes no vNF, porém destacamos o que ocorre no delivery em geral. Esperamos ter ajudado.