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?

Ninguém mais passou por essa situação?

Como posso minimizar isso? Para realizar o download eu tava usando essa função: DistribuicaoDFePorChaveNFe Aí troquei para: DistribuicaoDFe Tendo em vista que a segunda baixa todos os XMLS a partir do último NSU, e ficou mais rrápido, mas ainda assim, tem notas que não baixa o XML, está muito aleatório

Já está manifestada, veja o segundo print. Consultei a nota na SEFAZ e a mesma possui o evento vinculado, nos XMLS que anexei também mostra. O que pode está ocorrendo?

Boa tarde! Implementei a rotina para realizar o download dos XMLs emitidos contra meu CNPJ, porém não está usual, devido o fato do download do XML demorar muito tempo para realizar, e tem vezes que nem disponibilizar não disponibiliza. já debuguei meu código, e não consigo achar o problema, o evento é enviado normalmente, consulta a nota no site da SEFAZ, vejo que o evento está lá, porém o download não acontece, 99% das vezes retorna um 137. Segue o print da rotina e os XMLS que retornaram 1-eve.xml 1-ped-eve.xml 2102103519104364897100015555005000813235105362704401-procEventoNFe.xml

Ah, entendi! É por que os ajustes que eu realizei foram apenas para o CNAB 240.

Bom dia, eu já corrigi essa Unit faz algum tempo, inclusive eles já disponibilizaram a correção no SVN. Conforme pode ser visto aqui:

Acredito que só funcione em ambiente de produção. Fiz vários testes aqui e não obtive êxito. Pesquisei até alguns softwares que fazem isso, para vê se tinha a opção de baixar as notas contra meu CNPJ em ambiente de homologação, mas não achei nenhum software que faça isso.

Entendi, então neste caso você pode tentar ler uma tag do XML que só possua no XML COMPLETO, já que no RESUMIDO, vêm apenas algumas informações. Como por exemplo:

Já tentou assim?

Ah, desculpe, então eu que interpretei mal. Que eu saiba só tem como você baixa as notas que foram emitidas contra seu CNPJ. Me corrijam se eu estiver errado!