Painel de líderes

Olá pessoal! Foi publicado no Diário Oficial da União o DESPACHO Nº 12, DE 29 DE ABRIL DE 2025. Essa publicação traz alterações importantes para NF-e modelo 55 e NFC-e modelo 65. A primeira delas é a proibição da emissão de nota fiscal de consumidor eletrônica - NFC-e, modelo 65 para CNPJ, conforme trecho: O AJUSTE SINIEF Nº 11, DE 29 DE ABRIL DE 2025 o qual se trata este artigo, detalha que o mesmo vai produzir efeitos a partir de 03/11/2025. A segunda é criação de um modelo de DANF-e Simplificado Varejo conforme trecho: O AJUSTE SINIEF Nº 12, DE 29 DE ABRIL DE 2025 o qual se trata este artigo, detalha que o mesmo vai produzir efeitos a partir de 03/11/2025 Vale mencionar que consultando tanto no Portal Nacional quanto no Portal da Sefaz RS na data de 02/05/2025 não constam publicações de NT ou MOC retratando como deve ser o leiaute do DANF-e Simplificado Varejo.

Opa, bom dia @Italo Giurizzato Junior! Entendi. No meu caso, por hora, controlei pelo valor de retenção. Se for 0, então eu não coloco nenhum responsável (rtNenhum). Caso haja, coloquei para trazer o valor do campo "responsavelretencao" da view que criamos para abastecer os dados da NFSe, dessa forma: { ISS Retido } if MeuDataSet.FieldByName('vrissretido').AsExtended > 0 then begin IssRetido := stRetencao; ResponsavelRetencao := ACBrNFSe.Provider.StrToResponsavelRetencao(OK, MeuDataSet.FieldByName('responsavel_retencao').AsString); end else begin IssRetido := stNormal; ResponsavelRetencao := rtNenhum; end; Sei que não é o ideal, mas estamos validando essa versão por enquanto em um único cliente que vai ser atendido pelo ajuste.

Olá, Ficamos felizes em informar que foram implementados e enviados ao SVN os programas de exemplo do SPED ECF em Delphi e Lazarus na Rev-38982. ..\ACBr\Exemplos\ACBrTXT\ACBrSPED\Delphi\ECF ..\ACBr\Exemplos\ACBrTXT\ACBrSPED\Lazarus\ECF Até mais,

Olá pessoal! Foi publicada em 08/05/2025 a Nota Técnica Conjunta 2025/001 para tratar do CNPJ Alfanumérico modificado pela Instrução Normativa 2229 de 15 de outubro de 2024, afetando os ambientes autorizadores da NFe, NFCe, CTe, CTe OS, GTVe, MDFe, BPe, BPe TM, NF3e e NFCom. Nova lei de formação do número do CNPJ O tamanho do CNPJ permanece sendo 14, no entanto, agora as oito primeiras posições que identificam a raiz e as 4 posições seguintes que identificam a ordem do estabelecimento inscrito aceitaram caracteres alfanuméricos (letras e números). Os dois últimos dígitos verificadores permanecerão aceitando somente números. O cálculo dos dois últimos dígitos verificadores também foi alterado para se aceitar as novas possibilidades. Alterações necessárias nos Documentos Fiscais Eletrônicos Campos do tipo CNPJ Os arquivos de schema dos diversos DFes que utilizam o CNPJ já foram atualizados previamente alterando a expressão regular para aceitar letras maiúsculas nas primeiras 12 posições: [A-Z0-9]{12}[0-9]{2} Observação: Algumas letras não devem ser aceitas no CNPJ Alfa, como I, O, U, Q e F, essa exclusão faz parte das solicitações feitas pela equipe técnica do ENCAT para a Receita Federal do Brasil e precisa ser confirmada. Regras de Validação Não se aplicam modificações nas regras de validação relacionadas, considerando que as mesmas visam autenticar a veracidade dos 2 últimos dígitos verificadores do CNPJ. A partir da implementação desta NT, o contribuinte pode considerar que os ambientes autorizadores já estão adequados ao novo cálculo proposto para o DV. Nota aos Autorizadores: As rotinas de validação de CNPJ devem rejeitar CNPJ Alfanuméricos informados anteriores a data de implantação de cada ambiente (homologação e produção), mesmo que seja admitida a informação na validação de schema (já modificado). A rejeição aplicada nesse caso será a de falha no cálculo do Digito verificador. Chave de Acesso ao Documento Fiscal Eletrônico A expressão regular que valida a chave de acesso passa a suportar letras nas 12 primeiras posições da informação correspondente ao CNPJ que compõe a chave. Cálculo do DV da Chave de Acesso Assim como o cálculo do DV para o CNPJ foi alterado, também será necessário modificar o cálculo do DV da chave de acesso seguindo a mesma lógica proposta, a fim de suportar o alfanumérico. Regras de Validação da Chave de Acesso De forma semelhante as regras de validação relacionadas ao CNPJ, a regra de validação da chave de acesso vai validar o DV da chave e portanto o contribuinte pode considerar que o novo cálculo já vai estar sendo utilizado pelos sistemas autorizadores. Nota aos Autorizadores: As rotinas de validação de Chave de acesso devem rejeitar chaves contendo CNPJ Alfanuméricos informados anteriores a data de implantação de cada ambiente (homologação e produção), mesmo que seja admitida a informação na validação de schema (já modificado). A rejeição aplicada nesse caso será a de falha no CNPJ informado na chave de acesso. Padrão do Código de Barras dos Documentos Auxiliares O padrão utilizado atualmente é CODE-128C que suporta apenas números. A sugestão é a adoção de um modelo híbrido, usando o CODE-128C quando houver somente caracteres numéricos e o CODE-128A que aceita letras e números quando houver CNPJ alfanumérico. Datas A previsão de geração dos primeiros CNPJ Alfanuméricos está definida para julho de 2026. E como fica o ACBr? O componente ACBrValidador utilizado em funções para validar o CNPJ alfanumérico já está adequado para aceitar CNPJs Alfanuméricos. Foi criada a #TK-7034 para revisão dos componentes e possíveis adequações que possam vir a ser necessárias. Qualquer novidade será divulgada neste tópico. Leia a nota técnica na íntegra AQUI.

Olá pessoal! Foi publicado no dia 06/05/2025 a tabela dos códigos de classificação tributária, também conhecidos como cClassTrib. O cClassTrib faz parte do conjunto de campos adicionados nos documentos fiscais eletrônicos para atender as mudanças propostas pela Reforma Tributária. A tabela conta com as seguinte colunas: CST-IBS/CBS Descrição CST-IBS/CBS cClassTrib Alíquota Descrição cClassTrib LC 214/25 LC 214/25 Crédito anterior (apenas ligados ao cClass) Crédito para frente (apenas ligados ao cClass) Tomador específico dIniVig dFimVig Tributação NFS-e Outro campo NFS-e Obs pRedAliq dIniVig dFimVig Crédito anterior (apenas ligados ao cClass) Crédito para frente (apenas ligados ao cClass) Exige NBS ou NCM Sem NBS, mas com códigos de serviço específicos Tomador específico ICMS, CBS ou Outro Título, Capítulo, Seção, Subseção A tabela pode ser encontrada em nosso biblioteca tools ou no portal oficial

note no exemplo quer dizer que se tu tem os dados e passar ele vai cancelar qualquer operação dentro do dia da operação. já se for outro dia só via operadora pra cancelar transações tef

Boa tarde! Obrigado pela resposta Juliomar. O campo EmpresaTipo retorna se é matriz ou filial. Não encontrei o campo que informa se é Simples Nacional ou Normal. Obrigado, João

Sobre a senha, precisa gravar via metodo, nao basta digitar a senha no INI, pois a solucao grava ela criptografada. Mas precisa informar tbm quais as configurações do certificado, no caso A1: #configurando certificado e ambiente ret_GravarValor = acbr_lib.NFE_ConfigGravarValor(self.ponteiro, "DFe".encode("utf-8"), "SSLCryptLib".encode("utf-8"), str(1).encode("utf-8")) if ret_GravarValor != 0: raise Exception(f"Erro ao SSLCryptLib: {ret_GravarValor}") ret_GravarValor = acbr_lib.NFE_ConfigGravarValor(self.ponteiro, "DFe".encode("utf-8"), "SSLHttpLib".encode("utf-8"), str(3).encode("utf-8")) if ret_GravarValor != 0: raise Exception(f"Erro ao SSLHttpLib: {ret_GravarValor}") ret_GravarValor = acbr_lib.NFE_ConfigGravarValor(self.ponteiro, "DFe".encode("utf-8"), "SSLXmlSignLib".encode("utf-8"), str(4).encode("utf-8")) if ret_GravarValor != 0: raise Exception(f"Erro ao SSLXmlSignLib: {ret_GravarValor}") ret_GravarValor = acbr_lib.NFE_ConfigGravarValor(self.ponteiro, "DFe".encode("utf-8"), "UF".encode("utf-8"), 'SP'.encode("utf-8")) if ret_GravarValor != 0: raise Exception(f"Erro ao UF: {ret_GravarValor}") #Utilizar arquivo PFX ret_GravarValor = acbr_lib.NFE_ConfigGravarValor(self.ponteiro, "DFe".encode("utf-8"), "ArquivoPFX".encode("utf-8"), ARQ_PFX.encode("utf-8")) if ret_GravarValor != 0: raise Exception(f"Erro ao ArquivoPFX: {ret_GravarValor}") #Utilizar arquivo SENHA_PFX ret_GravarValor = acbr_lib.NFE_ConfigGravarValor(self.ponteiro, "DFe".encode("utf-8"), "Senha".encode("utf-8"), SENHA_PFX.encode("utf-8")) if ret_GravarValor != 0: raise Exception(f"Erro ao SENHA_PFX: {ret_GravarValor}") ret_GravarValor = acbr_lib.NFE_ConfigGravar(self.ponteiro, self.config_str); if ret_GravarValor != 0: raise Exception(f"Erro ao NFE_ConfigGravar: {ret_GravarValor}") Sobre dll de Opensll baixe deste link e coloque na mesma para do ACBrLibNFE.DLL https://svn.code.sf.net/p/acbr/code/trunk2/DLLs/OpenSSL/1.1.1.10/x64/

Ele vai criar p vc.. ainda nao tive tempo de testar sua aplicação estou em uma reunião. veja se a senha openssl esta na mesma pasta onde esta a lib

acredito que possa ser qualquer uma das 3 q te enviei acima. não é para ter problemas.

Sim, está correto !

Reduzimos e convertemos para outros formatos, pode ser q este formato q anexou não seja o ideal. Segue o arquivo compactado. Por favor extrair os logos e realizar testes com eles. aguardamos um retorno. Brasao_Brusque_SantaCatarina_Bra.7z

Boa tarde @ArecoDesenv, Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e veja a inclusão dos novos campos na unit SigISSWeb.GravarXml. Faça novos testes.

Bom dia @SimpleIT - Soluções em Tecnologia. A resposta mais simples é não e a resposta mais detalhada seria um "depende". Deixe eu explicar melhor. A nota fiscal de serviço eletrônica tem escopo municipal, ou seja, notas emitidas na cidade A não partilham o mesmo ambiente da notas emitidas na cidade B. Então não tem como você fazer uma única consulta de CNPJ e receber as notas da cidade A e B juntas. A exceção a essa regra é o Padrão Nacional, que recebe as notas emitidas por prestadores de serviço MEI de todo o Brasil e também das cidades que aderiram a ele como padrão por completo. Então se você estiver usando o Padrão Nacional, você pode usar o método NFSE_ConsultarDFE que lhe permite consultar as notas por CNPJ e NSU, em uma lógica bem parecida com a DistribuiçãoDFe da NF-e. Mas se eu não estiver usando o Padrão Nacional, então não tem jeito? Alguns provedores implementam métodos baseados no leiaute sugerido pela ABRASF em sua versão 2.0X que permite a consulta de serviços prestados e serviços tomados por determinados filtros. Para esses casos, você receberia as notas do ambiente do município que está consultando, mas ainda assim, pode usar métodos como o NFSE_ConsultarNFSeServicoPrestadoPorNumero, NFSE_ConsultarNFSeServicoPrestadoPorPeriodo, NFSE_ConsultarNFSeServicoPrestadoPorTomador, NFSE_ConsultarNFSeServicoPrestadoPorIntermediario, NFSE_ConsultarNFSeServicoTomadoPorNumero, NFSE_ConsultarNFSeServicoTomadoPorPrestador, NFSE_ConsultarNFSeServicoTomadoPorTomador, NFSE_ConsultarNFSeServicoTomadoPorPeriodo e NFSE_ConsultarNFSeServicoTomadoPorIntermediario. E como eu sei se o provedor permite usar qualquer uma dessas consultas? Para isso, você pode utilizar o método NFSE_ObterInformacoesProvedor para lhe dizer quais são os métodos que o provedor configurado permite utilizar. Veja um exemplo de resposta:

Veja este video Ele vai te ajudar com algumas dúvidas sobre ACBrLibNFSe. Este tópico também é importante:

Olá, Foram enviadas ao SVN as implementações do Leiaute 11 do SPED ECF na Rev-38982. Os detalhes das alterações podem ser verificados nas páginas 588 a 597 do manual que foi disponibilizado em ..\ACBrTools\SPED\EFD ECF\Manual_de_Orientação_da_ECF_Leiaute_11_Abril_2025.pdf Até mais,

Há é não perguntei o obvio, o ACBr está atualizado e rodou o instalador?

Sim, mudou.

Abriu chamado junto ao sefaz para tentar sanar. pois ao que parece seria só o seu caso não houve mai relatos por desencargo o ACBr está atualizado e sem icones vermelhos na pasta e também o instalador rodado?

Se você já utiliza a ACBrLib, é provável que o título desta notícia tenha lhe causado alguma confusão. Já não existe um método para essa finalidade? Calma, eu vou explicar. O método NFSE_ObterXML, já existe na biblioteca há bastante tempo. Ele continua disponível, sem alterações, e pode ser utilizado normalmente para recuperar o XML de uma NFS-e que esteja carregada na memória da biblioteca. Percebeu a ênfase na palavra NFS-e? Quando falamos de outros documentos fiscais, como NF-e, CT-e ou MDF-e, o mesmo arquivo XML que a Lib gera e envia para o web service, é o arquivo que é devolvido pelo web service para à Lib, agora acrescido das informações de autorização. Mas, no caso da NFS-e, isso funciona de forma um pouco diferente. Quando falamos de NFS-e, dois arquivos XML diferentes são envolvidos no processo: Um deles XML do Recibo Provisório de Serviço (RPS) que é o arquivo que a Lib monta com as informações que você carrega nela e envia para o web service do provedor. O outro é o XML da Nota Fiscal de Serviços Eletrônica (NFS-e) que é devolvido pelo web service do provedor para a Lib. Por causa dessa diferença, foi adicionado na biblioteca ACBrLibNFSe, o novo método NFSE_ObterXMLRps para permitir a você recuperar o XML do RPS gerado pela Lib antes do envio ao web service. O novo método tem a mesma estrutura do ObterXML e versões da biblioteca compiladas depois das 16h53 do dia 08/05/2025 deverão englobar o mesmo.

Boa Tarde, gostaria de compartilhar um conteúdo que não localizei no fórum, meu cliente adquiriu a balança UPX EA-32, e tivemos dificuldade na configuração. Depois de muito pesquisar e falar com o suporte do fabricante, recebemos o procedimento abaixo, a ser executado no painel da balança: - Pressionar a Tecla Imprime e Soltar - Mensagem no Display ( SENHA ) - Digitar a SENHA 0000 - Pressionar a Tecla Imprime e Soltar - Mensagem no Display ( Conf No Par ) - Pressionar a tecla 1 Mensagem no Display ( IFabr ) - Digitar 1 - Pressionar a tecla 2 Mensagem no Display ( Luali ) - Digitar 1 - Pressionar a tecla 3 Mensagem no Display ( IAuto ) - Digitar 0 - Pressionar a tecla 5 Mensagem no Display ( I Cent ) - Digitar 3 - Pressionar a tecla 6 Mensagem no Display ( Print ) - Digitar 0 - Pressionar a tecla 7 Mensagem no Display ( CodBar ) - Digitar 0 - Pressionar a tecla 9 Mensagem no Display (Uer) - Digitar 1 - Pressionar a Tecla Tara - Mensagem no Display ( Brat ) – Digitar 3 - Mensagem no Display ( Tipo Prot ) – Digitar 0 - Mensagem no Display ( Cont ) – Digitar 0 - Mensagem no Display ( EnuCod ) – Digitar 1 - Mensagem no Display ( Conf No Par ) Digitar zero para Sair e Salvar Após o procedimento acima, deve se configurar o componente da seguinte forma: E para windows 10 utilizei o driver no link: https://drive.google.com/file/d/1ST0R8m8qwdr0DAbexs9jfeUY7yIMxmDc/view?usp=sharing

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 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.