Painel de líderes

Eu abri um chamado na prefeitura... recomendo fazerem o mesmo, porque isso esta virando uma palhaçada... se liga ninguém fala nada e nunca vai pro setor correto https://sp156.prefeitura.sp.gov.br/portal/servicos/informacao?t=668&servico=3383

Boa Tarde, Atualmente, na emissão de NFC-e, já existe a possibilidade de parametrizar a largura de geração do DANFCe em PDF, permitindo adequação conforme o modelo e a largura da impressora térmica utilizada. Porém, para a emissão de NF-e utilizando o DANFE Simplificado, a API do ACBR atualmente não disponibiliza configuração para definição da largura do PDF gerado. Conforme verificado em pesquisas e documentações relacionadas ao modelo simplificado, o DANFE pode ser emitido com largura mínima de aproximadamente 55mm, entretanto a geração atual pela API ocorre apenas no padrão fixo de 80mm. Dessa forma, sugiro a implementação de uma melhoria que permita parametrizar a largura de geração do PDF do DANFE Simplificado, da mesma forma que já ocorre atualmente com o DANFCe. Com essa alteração, será possível adequar a impressão a diferentes modelos de impressoras térmicas e layouts operacionais, proporcionando maior flexibilidade e melhor aproveitamento do papel utilizado nas impressões.

Boa tarde, Isso não é uma verdade, a questão é na consulta CEP e CNPJ que permite um determinado range de informações em sandbox. Logo mais nas proximas horas isso será alterado, o que ocorre é o cadastro via painel ao sair do campo cep ou cnpj ele está tentando consultar as informações. Se fizer o cadastro via comando na API (https://dev.acbr.api.br/docs/api#tag/Empresa/operation/CriarEmpresa) essa consulta não ocorre, portanto não tem esse bloqueio previsto para até as 17h o console ser ajustado para permitir cadastros lá tambem

Boa tarde. Resolvido com a atualização

Emite algumas agora e estão sendo autorizadas, mas demorando muito tanto para enviar o lote quanto para consultar, mas estão sendo autorizadas !!!

Agora tentei uma emissão, demorou muito mas ai foi enviado, mas na consulta para ver o lote se foi autorizado, deu Time Out, ai fui no site para ver e mostra autorizada, então eles lá estão mexendo mesmo...

Bom dia @SOADing, Hoje o ACBr tem varias soluções para emissão de NFSe. Temos o componente ACBrNFSeX para o Delphi e Lazarus, a DLL ACBrLibNFSe, a aplicação ACBrMonitor Plus e o ACBr API. Eu não sei lhe responder quanto ao ACBr API, mas os demais posso lhe afirmar que já atende essa mudança de layout para o Padrão Nacional realizada pelo provedor ISSNet (NotaControl). Inclusive já realizamos testes em ambiente de homologação. Uma informação que não temos é referente ao WebService de Produção, não temos a URL desse ambiente de nenhuma cidade. A URL de homologação é única para todas as cidades, agora a de produção não sabemos se será também única ou se cada cidade vai ter a sua. Você consegue essa informação para nós?

Essa alteração para o SVN, rev. 46034.

Bom dia Erro na leitura do XML na linha 126 do arquivo Publica.LerXML.pas O Endereco.CodigoPais é Integer, então dá erro de conversão de string para integer. Alterei para tcInt e funcionou corretamente. Publica.LerXml.pas

Pessoal, O Banco do Brasil publicou em seu portal uma atualização sobre a troca de certificados nas APIs (mTLS), o que tem gerado algumas dúvidas. Segue um resumo simples e direto com o que realmente importa. O prazo de validade dos certificados TLS está sendo reduzido globalmente, conforme decisão do CA/Browser Fórum. A mudança ocorrerá de forma gradual: Validade de 200 dias para certificados emitidos a partir de 15/03/2026 Validade de 100 dias para certificados emitidos a partir de 15/03/2027 Validade de 47 dias para certificados emitidos a partir de 15/03/2029 Leia a notícia na integra ( também contém o link de downlod ) aqui: Home - Portal de Apoio ao Desenvolvedor BB O que está acontecendo? Não é erro de navegador, Windows ou bug do BB. Trata-se de uma mudança global de segurança (TLS/SSL) definida pelo mercado, voltamos a citar conforme decisão do CA/Browser Fórum. Certificados agora têm validade menor O BB passará a trocar os certificados com mais frequência Isso afeta diretamente integrações com APIs Se não atualizar, sua aplicação pode parar de funcionar. Qual é o impacto? Se sua aplicação não estiver preparada: Falha na conexão HTTPS/mTLS Erros de certificado (SSL handshake, verify failed, etc.) APIs deixam de responder APIs que exigem certificado Algumas APIs do Banco do Brasil utilizam o protocolo mTLS (Mutual TLS) como camada adicional de segurança. Nessas APIs, além do uso de HTTPS, sua aplicação precisa apresentar um certificado digital próprio para que a conexão seja aceita. Abaixo você encontra a lista das APIs que exigem mTLS: Pagamentos em Lote Pix Extratos Serviços de Arrecadação BB Pay Débitos Veiculares PagBB Fundos de Investimento BB Pay Arrecadação Autorização de Débito Automático Fonte: Home - Portal de Apoio ao Desenvolvedor BB O que precisa ser feito? Regra principal Sempre adicionar o novo certificado ANTES de remover o antigo Download ( Home - Portal de Apoio ao Desenvolvedor BB ) prazo de validade dos certificados TLS está sendo reduzido globalmente) Exemplo prático (Windows) 1. Baixar o novo certificado (.cer) Arquivo fornecido pelo Banco do Brasil. 2. Abrir o gerenciador de certificados Pressione: Win + R Digite: certmgr.msc 3. Importar o certificado Caminho: Autoridades de Certificação Raiz Confiáveis → Certificados Depois: Botão direito → Todas as Tarefas → Importar 4. Durante a importação Selecionar: Arquivo .cer Opção: Colocar todos os certificados no repositório a seguir Repositório: Autoridades de Certificação Raiz Confiáveis Finalizar o processo. 5. Importante Manter certificado antigo e novo ao mesmo tempo Não remover o antigo antes da virada Testar a aplicação após importar Fonte BB e Download: Home - Portal de Apoio ao Desenvolvedor BB

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.