Aggille Sistemas de Gestão

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

Sem problemas.. Se precisar envio o manual rfid

Lendo o manual, tem o comando BY que define a largura da barra fina e a relação entre elas.. provavelmente o que acontece é que depois de imprimor o qrcode ele mantêm a largura do QR para o codigo de barras Vou testar aqui ocomando BY antes de imprimir o código de barras e já posto o resultado

Tenho um cliente que precisa que saia um código de barras EAN128 e uo QRCore na mesma etiqueta.. A primeira etiqueta sai certa, a partir da segunda a largura do código de barras sai enorme... Estou usando uma impressora Zebra imprimindo com ZPLII... Testei com o exemplo do ACBR e acontece a mesma coisa.. imprimo uma etiqueta, sai ok, imprimo um QRCode , e a proxima etiqueta sai com o codigo de barras errado Seguem fotos de exemplo

essas impressoras rfid elas "gravam" informações na etiqueta.. é uma etiqueta especial, que tem um chip que armazena valores e um transmissor de radio frequencia.. então é gravado ali o ID da etiqueta e depois os leitores da fábrica vão ler esses valores...

Seguem unit alteradas com comandos para gravar valores Hexadecimais e ASCII nas impressoras Zebra.. Criei 2 Procedures procedure ComandoGravaRFIDHexaDecimal(aValue:String); procedure ComandoGravaRFIDASCII( aValue:String ); Comandos tirados diretamente do manual ZPLII e testados em uma impressora Zebra ZD500R ACBrETQPpla.pasACBrETQEpl2.pasACBrETQClass.pasACBrETQ.pasACBrETQZplII.pas

Vou precisar também.. em breve vou ter um equipamento aqui pra teste... já li os manuais e a impressora que vou ter aqui é da marca Zebra.. na questão da impressão, são os mesmos comandos que já têm no ACBR, a problema é somente os comandos para gravar os dados no chip da etiqueta. Os comandos a princípio são bem simples.. vou fazer a implementação e quando tiver pronto coloco para apreciação. sds,

Essa informação SeuNumero, é a identificação do Numero na empresa, que está no Segmento T, posição 106 a 130 conforme a página 6 do manual do banrisul... não é a mesma coisa que o NossoNumero como está acontecendo hoje no componente creio que deveria ser esse o conteúdo da linha 822: SeuNumero := Trim(Copy(FSegT, 106, 25));;//NumeroDocumento; sds, Banrisul 240.pdf

isso.. pois são informações diferentes ..

boa tarde.. alguma novidade sobre esse tópico ?

a linha correta é 4542

Estou homologando um cliente no bradesco ele que mandar para negativação ao invés do protesto.. Conforme o manual do Bradesco cnab240 as opções são as seguinte na página 24. Código para Protesto Código adotado pela FEBRABAN para identificar o tipo de prazo a ser considerado para o protesto. Domínio: '1' = Protestar Dias Corridos '2' = Protestar Dias Úteis '3' = Não Protestar 4’ = Protestar Fim Falimentar Dias Úteis ‘5’ = Protestar Fim Falimentar - Dias Corridos ‘8’ = Negativação sem Protesto '9' = Cancelamento Protesto/Negativação Automático (somente válido p/ Código Movimento Remessa = '31' - Descrição C004) Essa informação vai na posição 221 do Segmento P.. No ACBR temos duas opções.. case TipoDiasProtesto of diCorridos : Result := '1'; diUteis : Result := '2'; else Result := '3'; e case CodigoNegativacao of cnNenhum : Result := '0'; cnProtestarCorrido : Result := '1'; cnProtestarUteis : Result := '2'; cnNaoProtestar : Result := '3'; cnNegativar : Result := '7'; cnNaoNegativar : Result := '8'; else Result := '0'; O Acbr está enviando TipoDiasProtesto, ou seja 1 ou 2... Vou alterar os fontes aqui e fazer os testes.. mas caso alguém já tenha passado por isso, me diga como configurar.. sds,

Quando não tem avalista, coloca sacado.SacadoAvalista.Pessoa := pOutras ou sacado.SacadoAvalista.Pessoa := pJuridica

sim... essa situação que reportei não acontece no cnab400...

então sem querer descobrimos outro problema no padrão 240.. hehehe.. Quanto a questão do padrão 400... isso é o Banrisul sendo Banrisul... hehehehe... no manual, no meu entender, diz claramente que é a mesma informação na posição 38 e na 117..... sds,

ACBrBancoBanrisul.pas

Na verdade, nessa posição 38 tam 25 ( SEUNUMERO ) ele deveria retornar a MESMA INFORMAÇÃO que é gerada pelo proprio ACBR na propriedade SEUNUMERO quando geramos o arquivo de remessa...no meu caso eu mando o ID da duplicata, que uso no arquivo de retorno pra localizar a duplicata pelo ID. Mas na unit ACBRBanrisul , na linha 822 ele desfaz isso, jogando o NOSSONUMERO dentro da propriedade SEUNUMERO, tornando inútil preencher o SEUNUMERO na remessa. Vai na unit ACBRBanrisul e comenta a linha 822 até que isso seja corrigido no ACBR.. Titulo := boletoAcbr.CriarTituloNaLista; Titulo.SEUNUMERO := TituloModel.ID O valor enviado em SEUNUMERO deve ser o mesmo no retorno. grato,