Aggille Sistemas de Gestão

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,

Não vou mudar meu fonte que funciona em todos os bancos, exceto no banrisul... Comentei aquela linha na unit do ACBrBancoBanrisul, até que ela seja removida pelo pessoal do ACBR.. Não tem motivo para aquela linha existir, pois são informações diferenes... sds,

Bom dia pessoal... alguma retorno sobre esse tópico ? grato,

Bom dia... segue manual em anexo..retirado do site http://www.caixa.gov.br/Downloads/cobranca-caixa/Manual_de_Leiaute_de_Arquivo_Eletronico_CNAB_240.pdf o print que citei acima está na página 77.. na página 47 diz a localização da informação no header do arquivo. sds, Manual_de_Leiaute_de_Arquivo_Eletronico_CNAB_240.pdf

Ele é um arquivo normal que tem valor 5 na posicao 143 do header...é a única diferença...esse arquivo é recente. Aquele print que mandei acima é do manual atualizado

sim.. conforme citei ali em cima , nesses arquivos vêm os motivos de rejeição dos titulos...então o usuário tem que processar pra saber porque o titulos foi rejeitado... Sesses arquivos de retorno, vêm erros mais simples, como algum dado faltando, inconsistências no endereço, e coisas desse tipo . Depois de passar por essa validação, ai sim o titulo é enviado pro processamento, e ai sim, nesse caso vai ser retornado no arquivo de retorno no dia seguinte. esses arquivos geralmente vêm poucos minutos depois de serem enviados pelo sistema da caixa. ele segue todos os padrões do cnab240. segue em anexo um desses arquivo.... esse arquivo foi retornado porque o usuario preencheu o endereço de cobrança e nao colocou cidade nem uf.. . R240700011.ret

Mas é um arquivo padrão cnab240 normal.. e na prática, o programa da caixa baixa e coloca na pasta de retorno, dai quando o usuario vai processar, aparece o erro de que não é um arquivo cnab e ele fica sem saber porque a remessa foi rejeitada. Nesse arquivo estão as mensagens e os códigos de rejeição.

Quando enviamos um arquivo pra Caixa, padrão 240, e a mesma é rejeitada, ela vêm com o valor '5', na posição 143 do header.. E quando processamos, o ACBR diz que não é um arquivo de retorno, pois ele considera somente '2' como arquivo de retorno, ( unit ACBRBoleto, linha 4242 ) .. e cnforme o manual da caixa, os valores de retorno podem ser 2,3,4,5 Segue abaixo print do manual e em anexo unit alterada ( considerei que valor <> '1' considera retorno ). ACBrBoleto.pas

A propriedade SEUNUMERO para enviar o ID do titulo ( que depois é utilizada para localizar o titulo no banco de dados ), e o campo NumeroDocumento contém o número da duplicata 99999-99. Então preciso que venha o valor correto no campo SEUNUMERO. Do jeito que está não estou conseguindo processar os arquivos de retorno. Utilizo dessa forma pra todos os bancos a agora no Banrisul não funciona. Em suma, SEUNUMERO e NUMERODODOCUMENTO são informações diferentes.. a linha 822 na unit ACBtBancoBanrisul( SeuNumero := NumeroDocumento; _) não faz sentido...