joaolenosi

Bom dia! Na rotina do ACBr que realiza o processamento do arquivo de retorno, temos 3 campos de valores: Valor do documento Valor recebido Valor pago Como fazia bastante tempo que não atualizava a suíte de componentes do ACBr, gostaria de saber se houve alguma mudança em relação ao campo "valor do documento", pelo o que eu vi esse campo sempre armazenará o valor do título - o juros do título, correto? Sempre foi assim ou antes, o valor do documento era a soma do juros + o valor do título ?

Aqui é uma remessa que eu gerei antes de atualizar os componentes, e observe que a mesma estava correta. Estou conferindo o manual de implementação para ver se descubro qual posição está faltando. 25082021083232.REM

Bom dia, fazia um certo tempo que não atualizava os componentes ACBR, após a atualização, percebi que o ACBR está gerando Registro de Transação - Tipo 1, apenas com 399 caracteres. Existe algum campo novo que precisa alimentar? Segue a remessa com problema em anexo. 25082021082959.REM

Boa tarde, consegui sim! Mas não estou utilizando mais o ACBr, por causa que essa modalidade de registro de remessa por ws, é bem limitada. O BB disponibiliza uma API para você realizar a integração com o seu sistema, onde você pode realizar inúmeras operações que o envio por webservices não dispõem. Fale com o seu gerente do Banco do Brasil para ser cliente pliloto, aí lá eles criam um convênio e disponibilizam a documentação. Mas respondendo a sua pergunta, eu não me lembro exatamente como resolvi, mas acredito que tenha relação com os dados que você está configurando, se você tiver testando em homologação, você deve usar exatamente os dados que está no manual do web services bb ou os dados que vêm no exemplo do .txt do ACBr.

Tá certo! Está um pouco corrido aqui na empresa, mas vou da uma olhada.

kkk, então vou esperar por vocês, eu ia da uma olhada se dava certo refatorar, mas como vocês conhecem o acbr mais a fundo, deixo com vocês essa missão Verdade, e aparenta ser uma implementação bem simples. Eu estava implementando em PHP. Se precisarei de ajuda ou qualquer outra informação é só postar que eu respondo.

Já consegui gerar o token através do postman e registrar o boleto, tenho as requisições salvas aqui, se precisarem, posso anexar. Acredito que essa implementação não altera muita coisa, mas basicamente o que muda é que o payload deve ser em JSON, os endpoints são outros, possuem uma key diferente das que vocês usam hoje. Quanto a authorization acho que não muda nada, pois a primeira é a basic e a segunda o usa o OAuth 2.0 Bearer com o access token gerado.

Documentação restante: CBR - Alteração de Boletos Portal.pdf Documentação da API: https://developers-piloto.bb.com.br/#operation/listaBoletosId

Ah, essa documentação eles nem utilizam mais. Agora os endspoints são diferentes, e possuem uma nova documentação. vou anexar a nova documentação Vou enviar o restante da documentação no outro post, esse já atingiu o limite de 2mb Cobranças.json Accounts.json CBR - Listagem de Boletos Portal.pdf Modelo para o boleto de cobrança.pdf CBR - Geração de Boletos Portal.pdf

Mas exista alguma diferença entre o uso da API e do Webservices? Por que segundo o banco, são dois produtos distintos

Olá, boa tarde! Estou com uma dúvida em relação a implementação do ACBr para cobrança Online do Banco do Brasil. Analisando o código vi que a troca de informação é realizada utilizando XML, e foi baseada no manual de integração versão 1.4, com o respectivo endpoint para registrar boleto: https://cobranca.homologa.bb.com.br:7101/registrarBoleto Porém, em contato com o banco eles não dão suporte a essa implementação, eles disponibilizam uma API para registro de boletos, utilizando JSON como mecanismo de troca de informação. A minha dúvida é: o ACBr não sabia da existência dessa API para registro de boleto ou foi algum outro motivo especial? Ou o que o componente do ACBr realiza, é um serviço diferente do que esse outro que explanei ?

Olá, boa tarde! Estamos efetuando testes utilizando o client_id e secret_id disponibilizados no manual de integração junto com o respectivo convênio; Após realizar o processo de aquisição do token e utilizando-o nas requisições subsequentes, a requisição é efetuada, porém o XML recebido, retorna o seguinte erro: Convênio encerrado. E quando tentamos registrar o boleto com o convênio da nossa empresa, o XML retornado , informa que: o MCI não foi encontrado. E, utilizando as chaves que foram geradas no Portal developers BB juntamente com nosso convênio é retornado: Cliente não possui autorização para solicitar o escopo: cobranca.registro-boletos. Alguém tem alguma sugestão?

Entendi! Já que não tem o que ser feito para otimizar o download dos XMLs, então pode colocar o tópico como RESOLVIDO. Obrigado a todos que contribuíram;

Não baixo todas as notas, mas quando implementei essa funcionalidade no sistema, a ideia era saber quais notas que foram emitidas contra meu CNPJ, e ao realizar o download do XML completo, automaticamente o sistema cadastra todos os produtos novos que tem no XML e realiza a compra de mercadoria, mas o fato do download do XML não ser automático, está inviabilizando a funcionalidade. Entende? Vocês utilizam essa funcionalidade com qual intuito? Apenas de recuperar um eventual XML que por ventura foi perdido? Sei que existe alguns ramos que a legislação obriga a empresa se manifestar diante aquela nota fiscal mas não é o caso do meu seguimento.

Entendi, isso é muito chato, por que acaba inviabilizando o uso da funcionalidade. Alguém mais faz um tratamento diferenciado?