gvgarcia

Bom dia! O erro 117 do Bradesco normalmente não está relacionado ao client_id/client_secret, mas sim ao certificado cliente utilizado na autenticação mTLS. Eu verificaria os seguintes pontos: O certificado cadastrado no portal do Bradesco é exatamente o mesmo que está sendo utilizado pelo ACBr? Se você gerou novas credenciais para o Pix, também gerou e vinculou um novo certificado à aplicação? O arquivo .key corresponde ao .pem utilizado? O certificado está dentro da validade? O erro ocorre tanto no Demo PIX do ACBr quanto na sua aplicação? Uma forma simples de testar é habilitar o nível máximo de logs do ACBr e verificar se o handshake TLS é concluído com sucesso.

Bom dia! Pelo que foi divulgado até o momento, a alteração do certificado do eSocial para a nova cadeia da Sectigo não exige nenhuma mudança específica na implementação do ACBr. A comunicação continuará funcionando normalmente desde que o ambiente onde a aplicação executa reconheça a nova cadeia de certificação.

Até o momento, não há uma nova mudança de regra estrutural prevista especificamente para junho/2026 em relação ao CBS e IBS. Os principais pontos de atenção são: Desde 01/01/2026, as empresas já devem emitir documentos fiscais com os campos de CBS e IBS conforme os novos layouts fiscais. O ano de 2026 continua sendo considerado um período de testes e adaptação, sem cobrança efetiva dos tributos para quem cumprir corretamente as obrigações acessórias. Em junho/2026 encerra-se o período inicial de tolerância para adequação dos sistemas e documentos fiscais, tornando ainda mais importante que as notas fiscais estejam sendo emitidas com os campos de CBS e IBS corretamente preenchidos. Os regulamentos da CBS e do IBS foram publicados recentemente (Decreto nº 12.955/2026 e Resolução CGIBS nº 6/2026), detalhando regras operacionais e obrigações acessórias. A partir de agosto/2026, a fiscalização poderá iniciar procedimentos relacionados ao preenchimento dessas informações, embora ainda exista previsão de prazo para regularização antes da aplicação de penalidades. Portanto, se o objetivo é se programar com os clientes, eu consideraria 01/01/2027 como a próxima grande virada, mas acompanharia de perto as publicações técnicas durante todo o segundo semestre de 2026.

Bom dia! O item na posição 2 (terceiro produto) está com o CST de PIS/COFINS igual a 49, que é um código inválido para o grupo PISNT (PIS Não Tributado). Os únicos CSTs aceitos nesse grupo são: 04, 05, 06, 07, 08 e 09. Por que funciona separado mas não junto? Quando emite separado, provavelmente esse produto específico não está sendo incluído, ou o sistema calcula o CST de forma diferente quando há apenas um item. Com os produtos juntos, o ACBr valida todos os itens e rejeita o CST 49 no item det[2]. Como resolver: 1. Identificar qual é o produto na posição [2] (terceiro da lista) e verificar o cadastro fiscal dele. 2. Corrigir o CST de PIS/COFINS desse produto para um código válido. 3. O CST 49 pertence ao grupo PISSN (saídas não classificadas), que é diferente do PISNT (o ACBr provavelmente está colocando o item no grupo errado por causa desse código). No sistema do cliente, vá no cadastro do produto que está na posição [2] da nota e corrija o CST PIS e CST COFINS para o valor adequado à situação fiscal do produto (geralmente 07 para isentos ou 08 para não incidência).

Bom dia! Pelo trecho enviado, realmente existe um operador "+" sem nenhuma expressão após ele, o que causaria erro de compilação. Antes de concluir que é um problema da revisão, poderia confirmar se a atualização foi realizada completamente e sem conflitos? Se possível, envie também algumas linhas antes e depois da linha 1080 (cerca de 10 linhas acima e abaixo) e informe a revisão/data exata do ACBr que está utilizando. Caso o arquivo tenha sido atualizado parcialmente ou ocorrido algum problema durante o download/merge, o código pode ter ficado incompleto. Com o trecho completo consigo avaliar se é um problema da revisão ou apenas uma inconsistência local na atualização.

Bom dia! Até onde consta no ACBr, a Elgin DP30 T não possui suporte nativo como modelo específico dentro do ACBrBAL. Ela possui comunicação serial RS-232, então a integração pode ser viável, porém normalmente depende do protocolo de comunicação da balança ou de uma implementação específica. Particularmente não cheguei a fazer leitura da Elgin DP30 T pelo ACBr. Se você tiver o manual de comunicação ou já estiver com o equipamento em mãos, podemos validar qual protocolo ela utiliza e verificar a melhor forma de integração.