José M. S. Junior

Correto... Essa funcionalidade é recente, está nas novas versões.

Boa tarde, provavelmente na leitura do retorno está considerando o dígito verificado do nosso número. Por padrão o componente não lê o digito pois o mesmo já é calculado pelo componente, mas pode ser que alguns tenham sido implementados dessa forma. Note que após a leitura a propriedade volta a aceitar 12 digitos.

Pelo que entendi no outro post você utiliza o ACBrMonitor... Se sim, pode utilizar esses dois métodos: https://acbr.sourceforge.io/ACBrMonitor/CNPJConsultarCaptcha.html https://acbr.sourceforge.io/ACBrMonitor/CNPJConsultar.html

Bom dia, conseguiu identificar o problema na autenticação? Se possível compartilhe a solução, assim podemos investigar melhor o código genérico do erro... Quanto ao retorno, o nome dos campos são outros mesmo... Note que o problema é código do Beneficiário e não do Pagador, provavelmente é alguma inconsistência do cadastro do Beneficiário no Banco, precisa passar esse erro para eles analisarem.

Sim, mas a pasta Enviados são apenas os XMLs Criados pelo componente, note que são apenas as tags passadas pela aplicação comercial. A pasta Vendas que contem os XMLs autorizados e assinados pelo aparelho SAT, esse sim é retornado pelo SAT...

Precisa realizar um debug mesmo... tente identificar se o está tendo algum retorno na autenticação. Essa função fica na classe ACBrBoletoWS

Se está funcionando com os dados em homologação no demo era para funcionar com seus dados... Precisa tentar depurar para ver exatamente onde está ocorrendo esse erro. Quando a requisição do BB é XML mesmo... segue a documentação. Apenas a autenticação OAuth retorna um JSON, note que isso é tratado internamente no componente. Pode capturar esse retorno na função: ProcessarRespostaOAuth

Pode mostrar um exemplo dessa situação, com o log do Monitor?

Normalmente a Transportadora já trabalha com alguma específicas, neste caso precisaria entrar em contato com essas seguradoras que seu cliente (Transportadora) trabalha para solicitar a documentação. Algumas integram via WebService outras é por troca de arquivos mesmo...

Bom dia, verifique se todos os fontes do Boleto estão atualizados conforme está no SVN, se você utiliza classes do ACBr no seu projeto, precisa declarar a uses: ACBrBoletoConversao Dê uma olhada nesse tópico:

Bom dia, note que agora não é mais erro de comunicação com Serviço de Autenticação e sim erro na validação de credenciais. KeyUser é a chave padrão: J1234567 até onde eu sei está sendo utilizada essa chave também em produção, mas precisa confirmar com o Banco. Este IDClient já está liberado para integração em Homologação e Produção?

A libXML2 é a biblioteca padrão de assinatura do ACBr. Pode estar ocorrendo algum conflito com outra dll na máquina, o ideal seria realizar um teste em outro equipamento.

Bom dia Está utilizando a configuração STDCALL para a dll?

Esse erro é o retorno do próprio aparelho, infelizmente não é especifico qual é o erro... Normalmente é erro de dados no xml. Para validar o xml de venda pode utilizar uma ferramenta da Tanca o "InteliSat", esse aplicativo voce pode carregar o xml de venda e validar os dados http://www.tanca.com.br/drivers.php?cat=24&sub=43

Por favor anexe o log do ACBrMonitor. O procedimento de assinatura é o mesmo utilizado no envio... Verifique se instalou a versão 64bits, a versão 64 precisa ser instalada em outro diretório, pois as dependencias de libs mudam.

Boa tarde Está utilizando a dll atualizada do fabricante? Verifique também se está utilizando a mesma arquitetura da DLL com o ACBrMonitor (ex: Se Monitor estiver rodando X86 a dll do SAT precisa ser na mesma arquitetura)

Esse arquivo não pode ser salvo como XML. Deve ser um arquivo .INI (extensão .ini)

Boa tarde, CFe.ini seria o arquivo .ini com os dados do seu cupom. deve seguir o exemplo do manual para preenchimento das tags. Lembrando que pode passar o conteúdo desse arquivo .ini direto no parâmetro, vai funcionar da mesma forma, desde que as tags estejam devidamente preenchidas Precisa preencher apenas campos obrigatórios do SAT, veja esse arquivo simplificado: https://acbr.sourceforge.io/ACBrMonitor/ModeloCFeINISimplificadovalido.html

Boa tarde, no diretório do Demo ACBrBoleto tem um arquivo .txt (configWebService.txt) com os campos obrigatórios para Integração com BB. Se estiver utilizando a configuração HTTPLib com OpenSSL, precisa ter as dlls da openSSL no diretório do executável.

Boa tarde, por favor anexe seu arquivo.ini completo. O CNPJ não deve sem informado com mascara (ponto e barra)

Bom dia, você tem o manual atualizado com essas especificações? Se possível anexe o mesmo aqui para validação.

Boa tarde, o componente ACBrNFeDANFeRL tem a propriedade "ImprimeValor" onde pode definir Unidade Comercial, Tributável ou ambas.

Bom dia Seguindo o padrão Febraban do boleto impresso e também dos demais bancos implementados, quando o valor é por dia, o mesmo já é calculado baseado no percentual e informado o valor diário em R$ na impressão ... Aparentemente o pessoal utiliza assim para o Sicred. Outra opção é desmarcar a propriedade "ImprimirMensagemPadrão" e informar a própria mensagem com percentual em dias.

Bom dia O campo "MultaValorFixo" define se é Valor ou percentual, informe "1" para Valor e "0" para percentual.

Neste retorno não tem registros com os segmentos... Aparentemente está apenas as duas linhas do header e duas linhas do trailler.