Aggille Sistemas de Gestão

O Banco Inter gera o nosso numero e o numero do banco no arquivo de retorno.. portanto não dá pra emitir o boleto junto com a nota fiscal.. Tem que aguardar processar o arquivo de retorno pra depois emitir o boleto..

Estou fazendo alguns testes... o xml gerado pela versão nova é praticamente igual ao gerado pelo componente antigo... A diferença que ele coloca <tc:InfRps id="Rps_138"> e no componente antigo é <tc:InfRps>.. no caso do provedor ISS.net, o codigo do municipio tem que ser 999 em modo de homologação, e o componnente novo não aceita, pois valida o código do IBGE... Qualquer novidade coloco aqui nesse post...

também não consegui pelo provedor ISS.net de Novo Hamburgo / RS

Mais algumas informações... ACBrBoletoRet_BancoBrasil_API.pas

Fui utilizar a consulta detalhada da API do BB e reparei que não trazia todos os dados do retorno JSON.. Então implementei os principais dados de retorno.. com o tempo vou implementando todas as informações.. Segue a unit alterada.. já testei e funciona.. sds, ACBrBoletoRet_BancoBrasil_API.pas

No programa de testes do acbr dá o mesmo erro...

Boa tarde... Estou fazendo a migração para o ACBRNFSEx.. a migração em si é tranquila.. mas no envio das notas para o provedor ISSnet de Novo Hamburgo/RS, estou obtendo a seguinte mensagem: "O Servidor não pôde processar a solicitação. -->> Referência de objeto não definida para uma instância de um objeto." Comparei um xml do versão anterior ( que funciona ) e há apenas uma diferença: No xml gerado pelo ACBRNFSe: <LoteRps> <tc:NumeroLote>12</tc:NumeroLote> no xml gerado pelo ACBRNFSEx: <LoteRps id="Lote_13"> <tc:NumeroLote>13</tc:NumeroLote> No mais.. está tudo certo.. o pessoal do ISSnet disse que o cabeçalho não está correto.. por isso que não funciona.. mando em anexo 2 xmls.. o 128.xml gerado pelo componente antigo e 138.xml pelo componente novo.. sds, 128-rps.xml 138-rps.xml

Bom dia... Pode colocar sempre "cobrancas.boletos-info cobrancas.boletos-requisicao" em todas as operações... eu, por exemplo, coloco essa informação no cadastro da Carteira, então coloco sempre esse mesmo valor.. sds,

Meus clientes do Sicredi reclamaram essa semana que o NUMERO DO DOCUMENTO estava saindo errado nos boletos.. Então olhei o código da Unit AcbrBancoSicredi e encontrei essa linha. ANumeroDocumento := PadRight(IfThen(SeuNumero <> '', SeuNumero, NumeroDocumento), 10, ' '); Porém.. NumerodoDocumento e SeuNumero são informações diferentes... Número do documento é o numero da duplicata, exemplo 123456-1 SeuNumero é o ID do registro dentro do banco de dados. ( ID to Titulo ) Nessa linha, ele está assumindo que NumeroDoDocumento é o mesmo que SeuNumero ( quando esse é informado ). Portanto.. se eu informar a propriedade SeuNumero, ele vai associar NumeroDoDocumento ( e vai sair no boleto o ID do titulo ai invés do numero ) Se eu não informar SeuNumero, não consigo localizar o titulo dentro do banco no arquivo de retorno isso sempre funcionou bem... estranha essa alteração... sds,

Tive esse mesmo problema.. eram os scopes que estavam errados.. na propriedade ACBRBoleto.Cedente.CedenteWS.Scope coloca cobrancas.boletos-info cobrancas.boletos-requisicao

Quando o ACBR faz a consulta dos titulos pagos ou pendentes pela API, no retorno do banco do brasil não vem o campo SeuNumero nem o Nosso_Numero ( vem somente o numero do banco ). A Instrução do BB é de pegar o numero do banco, fazer outra chamado a API buscando individualmente o titulo por esse numero, dai sim, vem uma consulta mais completa. Acho que o ACBR ainda não implementou essa consulta individual. As vezes não é possivel localizar o titulo dentro do banco de dados pelo numero do banco. Dentro do numero do banco está contido o nosso numero, pelo qual se consegue localizar facilmente no banco de dados. Creio que quando o ACBR processa o retorno da API, seria simples pegar o numero do banco e extrair o nosso numero e preencher a propriedade , certo ? O BB disse que pretende implementar essas informações nas próximas versões da API, mas isso pode levar um certo tempo sds,

Quando o ACBR faz a consulta dos titulos pagos ou pendentes pela API, no retorno do banco do brasil não vem o campo SeuNumero nem o Nosso_Numero ( vem somente o numero do banco ). A Instrução do BB é de pegar o numero do banco, fazer outra chamado a API buscando individualmente o titulo por esse numero, dai sim, vem uma consulta mais completa. Acho que o ACBR ainda não implementou essa consulta individual. As vezes não é possivel localizar o titulo dentro do banco de dados pelo numero do banco. Dentro do numero do banco está contido o nosso numero, pelo qual se consegue localizar facilmente no banco de dados. Creio que quando o ACBR processa o retorno da API, seria simples pegar o numero do banco e extrair o nosso numero e preencher a propriedade , certo ? O BB disse que pretende implementar essas informações nas próximas versões da API, mas isso pode levar um certo tempo sds,

Já descobri.. eu tinha definidio uma pasta pra salvar os json e não tinha criado essa pasta.. só que ele não traz a mensagem do Exception.. Mas já tá resolvido.. Já enviei boletos em produção e deu certo a alteração dos dias e agende de protesto... Na imagem abaixo aparecem os dias e o agente negativador...

Quando envio em produção.. levanta essa exception.. Não sei se é por causa dessa operação.. o envio deu certo, Code 201 é inserido com sucesso..

Ok.. está pegando os valores das propriedades corretos... vou enviar um boleto em produção e aviso o resultado...

Bom dia... eu ja havia feito assim: if (Titulos.DiasDeNegativacao > 0) then begin Json.Add('quantidadeDiasNegativacao').Value.AsInteger := Titulos.DiasDeNegativacao; Json.Add('orgaoNegativador').Value := 10; end; em homologação funciona.. porém tem o orgao negativador, que conforme o pessoald o banco do brasil me informou , em produção esse campo é obrigatório.. eu coloquei 10 ( serasa ), mas creio que essa informação poderia estar na classe Banco ( ou titulos )... sds,

Posso implementar essa funcionalidade baseado na propriedade CodigoNegativacao... só precisaria criar a propriedade para o Agende de Negativação, que creio que seria na classe BANCO... sds,

Enviei um boleto de um cliente pela API do Banco do brasil. Ele utiliza Negativação ao invés de Protesto.. esse boleto enviado via API foi como protesto. Ohando os fontes do ACBR, percebi que esses campos estão comentados: //Json.Add('quantidadeDiasNegativacao').Value //Json.Add('orgaoNegativador').Value Existe a previsão implamentação para adicionar esses campos ? sds,

foi o que eu fiz... até questionei o pessoal do banco.. como aceitam espaços em um campo que é definido como numérico no layout...

Boa tarde.. Na geração dos arquivo de remessa do banco do Brasil, tem um campo Quantidade de dias para recebimento, posição 023 a 025 do registro tipo '5' ( página 8 do manual em anexo ). Quando não é informado o acbrboleto envia '000' IntToStrZero(wDiasPagto ,3) conforme linha 1143 da unit ACBRBancoBrasil. Conforme as notas 37 e 38 ( página 21 ), quando não quer limite de dias de pagamento, deve-se informar espaços ao invés de '000'. Quando de manda 000, o banco entende que não é para aceitar pagamento após o vencimento.. Segue em anexo manual do banco do brasil.. sds,Doc2627CBR641Pos7.pdfDoc2627CBR641Pos7.pdf

Fiz um teste aqui agora.. imprimi as mesmas etiquetas em arquivo txt antes de atualizar o acbr e depois de atualizar.. os arquivos ficaram idênticos.. portanto a implementação está OK.. Grato

Ok..vou testar...não tenho o hábito de utilizar o formatador de codigo do delphi e não utilizo nenhuma ferramenta pra isso.. Muito grato pela observação

Cliente ja esta usando em produção com.a implementacao que eu havia feito antes...vou atualizar e testar...obrigado..

Tem essa alteração também referente aos códigos de barras em ZPLII...

resolvi o problema.. O padrão ZPLII tem um comando específico pra ajustar a altura e a largura das barras, que deve ser emitido antes de imprimir o código de barras ( ^BY ) Então , na unit ACBrETQZplII criei um método ComandoTamanhoBarras( aBarraFina, aBarraLarga , aAlturaBarra:Integer ) que gera esse comando ( parâmetro aBarraLarga não tem funcionalidade, pois o padrão zplII calcula a barra larga proporcionalmente ao tamanho da barra fina ) function TACBrETQZplII.ComandoTamanhoBarras(aBarraFina, aBarraLarga , aAlturaBarra:Integer): String; begin result := '^BY' + intToStr( aBarraFina )+ ',,'+ intToStr( aAlturaBarra ); end; E o método ComandoImprimirBarras ficou assim: Result := ComandoCoordenadas(aVertical, aHorizontal) + ComandoTamanhoBarras(aBarraFina, aBarraLarga , aAlturaBarras ) + ComandoBarras(aTipoBarras, aOrientacao, aAlturaBarras, aExibeCodigo) + ComandoCampo(aTexto); Dessa forma funcionou perfeitamente Segue em anexo a unit alterada, porém ela contém os métodos de gravação RFID que implementei em outra thread... Mas implementando as alterações acima funciona corretamente. ACBrETQZplII.pas