leotelles

Sendo assim, irei tentar fazer a implementação do método.

@Daniel Simoes, agradeço a resposta, mas no caso do tópico mencionado por você o método de impressão de imagens existe, porém não estava imprimindo corretamente. No meu caso, o método ImprimirImagem não existe na unit ACBrETQZplII, então gostaria de saber se existe um motivo específico de ele não ter sido implementado para essa linguagem.

Boa tarde. Notei que na unit ACBrETQZplII não tem o método ImprimirImagem presente nas units ACBrETQEpl2 e ACBrETQPpla. Alguém sabe o motivo da ausência? Seria porque a linguagem ZPLII não aceita impressão de imagens ou simplesmente porque ninguém implementou ainda?

Amigos, confiram este outro tópico: Apesar de ser sobre uma impressora diferente, acredito que possa conter informações que ajudem a resolver o problema mencionado aqui.

Obrigado pela ajuda, @EliasCesar! Consegui solucionar aqui passando zero para os parâmetros Fonte e MultiplicadorH. Mudando apenas o MultiplicadorV eu consegui chegar nos tamanhos que eu queria.

Essa realmente é a solução para o problema. Obrigado, EliasCesar! Uma dica para quem enfrentou esse problema: aqui utilizamos o software Format Factory para converter imagens em bmp monocromático para pcx e tem dado certo. Citei o nome do software porque esse funcionou corretamente, já que testamos outros conversores sem sucesso.

Bom dia. Estou tentando implementar a impressão de etiquetas para a impressora Zebra S4M. Inicialmente estou usando o demo do ACBrETQ. O problema é que a fonte está minúscula, mesmo colocando valores altos para os parâmetros MultiplicadorH e MultiplicadorV. Já implementei etiquetas para as impressoras Argox e Elgin e nunca tive esse problema. Alguém que já trabalhou com a Zebra saberia me dizer se tem alguma coisa específica que eu deva fazer para funcionar corretamente? Estou usando a linguagem ZPLII. Desde já agradeço.

Apoio a ideia de criar uma propriedade dinâmica para alimentar a Versão do Layout, pois nossos clientes também estão tendo problemas com isso e não é interessante ter que ficar alterando um valor fixo no código fonte. Deixo minha sugestão para os colegas discutirem se é viável ou não.

Bom tarde. Estou com o seguinte problema ao utilizar o Fortes Report: eu crio uma TRLAngleLabel em tempo de execução já definindo o Height e o Width. Mas a largura e a altura que eu defini não são respeitadas. Estou criando com a propriedade AutoSize desabilitada, mas mesmo assim a label fica com o tamanho do texto que está no Caption e não com o tamanho que eu defini. Alguém já enfrentou algo do tipo e poderia me dar uma ajuda?

Acrescento mais algumas dúvidas: Quais tabelas devo criar? O cadastro de Conta Corrente terá o tipo da moeda da conta? Alguém pode me dar quaisquer dicas sobre o assunto?

Bom dia. Estou querendo implantar um controle de cotação de dólar no meu ERP, mas tenho várias dúvidas sobre isso... uma delas é a emissão de boleto. Alguém já passou por isso? Devo emitir o boleto em dólar?

Bom dia. De acordo com o mais recente (Fevereiro de 2017) manual do Banco Santander (CNAB 240), existem 3 valores que podem ser passados para o campo Forma de Cadastramento (posição 59 do segmento P do arquivo de remessa): '1' = Cobrança Registrada (Rápida e Eletrônica com Registro) '2' = Cobrança sem Registro ‘3’ = Cobrança Simples (Sem Registro sem pré-impresso e com pré-impresso) Porém, no método GerarRegistroTransacao240 da unit ACBrBancoSantander, só é passado '1' ou '2'. case ACBrBoleto.Cedente.TipoCarteira of tctSimples: sTipoCarteira := '2'; tctRegistrada: sTipoCarteira := '1'; else sTipoCarteira := '2'; end; sTipoCarteira + // 059 - 059 / Forma de Cadastramento = 1 Registrada / 2 Sem Registro Peço, por gentileza, que os moderadores analisem a possibilidade de alteração ou me instruam sobre como corrigir o problema. Seria necessário criar uma novo item para a propriedade ACBrBoleto.Cedente.TipoCarteira?

Boa tarde. Um de nossos clientes que utiliza boletos do Sicoob (cnab 240) está tendo problemas ao informar o sacador/avalista. Quando ele alimenta os campos referentes ao sacador/avalista e envia o arquivo de remessa para o banco, o sistema do Sicoob simplesmente não lê (não registra) a remessa. Se ele limpa os dados de sacador/avalista e envia o arquivo de remessa sem essas informações, o sistema do Sicoob lê normalmente o arquivo de remessa. Alguém poderia me ajudar a entender a causa desse problema, por favor? Obs: o nosso cliente tem uma conta no Bradesco também onde ele informa sacador/avalista e tudo funciona corretamente. Aparentemente esse é um problema específico do Sicoob.

Boa tarde. Estou com um problema que acredito não estar diretamente relacionado ao componente do ACBr, mas peço ajuda aos colegas, caso alguém já tenha enfrentado algo do tipo: Um de nossos clientes usa a impressora em modo econômico, definido através das preferências de impressão em Painel de Controle > Dispositivos e Impressoras (Windows). O usuário deseja alterar essa configuração, voltando para o modo normal de impressão apenas ao imprimir a nota fiscal no nosso sistema (utilizamos o ACBrNFe para gerar as impressões, através da ferramenta Fortes Report). Ao clicar em imprimir no nosso sistema, é aberta aquela tela de visualização da impressão gerada pelo Fortes Report. Nessa tela, é possível selecionar a impressora e clicar no botão Propriedades para alterar as configurações da impressão. A tela de propriedades é a mesma que é aberta ao ir em Painel de Controle > Dispositivos e Impressoras > Preferências de Impressão. O problema é que as alterações feitas nessa tela de configuração do Fortes não são respeitadas ao imprimir a nota. No caso, o usuário clica nas propriedades da impressora através da visualização do Fortes, clica na opção Modo Economia para desmarcá-la, imprime a nota e eis que a impressão continua saindo em modo econômico. Detalhe: se o usuário faz o mesmo procedimento em qualquer outro software instalado no computador (qualquer editor de texto, leitor de pdf, etc) o problema não ocorre, ou seja, a configuração alterada é respeitada, imprimindo exatamente como ele configurou. Apenas nas impressões geradas pelo nosso sistema (via ACBr + Fortes) a configuração alterada não é respeitada. Alguém já enfrentou esse problema ou tem alguma orientação que possa nos ajudar? Desde já agradeço.

Bom dia. Alguém sabe me dizer se existe um limite para o número de títulos por arquivo de remessa? Nosso cliente trabalha com o banco Bradesco.

Bom dia, @GumercinoICS. Isso vai depender do valor informado no campo CodigoMora. Por exemplo: o Banco do Brasil trabalha com os seguintes valores para o campo CodigoMora: 1 - Valor por Dia 2 - Taxa Mensal 3 - Isento Se o valor do campo CodigoMora for '1', o campo ValorMoraJuros será o valor diário. Se for '2', será o valor mensal. Verifique os manuais dos bancos que você trabalha para tratar corretamente cada caso.

Como as últimas informações da linha digitável do boleto são referentes ao valor do título, fizemos o seguinte teste: pegamos 4 boletos de contas à pagar da nossa empresa e tentamos pagar via internet através da nossa conta do Bradesco. Mudamos os últimos dígitos da linha digitável, para que o valor do título ficasse inferior ao valor original. Dos 4 boletos, apenas 2 o sistema do banco aceitou como válido, sendo que os outros 2 ele informou que o valor não estava correto. Você saberia me dizer se a verificação do valor do título é feita apenas através da linha digitável ou se existe outra maneira de os bancos buscarem essa informação? Por exemplo: como que o sistema do Bradesco valida o valor de um título emitido pelo Banco do Brasil? Apenas através da linha digitável? Ou existe algum tipo de base de dados comum entre todos os bancos? Suspeitamos que, no caso que eu apresentei, a pessoa foi no sistema online do banco e alterou os últimos dígitos da linha digitável.

O Pagamento foi feito via internet.

Boa tarde. Um de nossos clientes, que emite boletos do Banco do Brasil, entrou em contato conosco alegando que um de seus clientes conseguiu pagar um valor inferior ao valor original do boleto. Ex: o valor do boleto era R$ 2.000,00 e o cliente conseguiu pagar R$ 1.900,00. Detalhe: o nosso cliente não concede desconto para ninguém. Verificamos todos os parâmetros e inúmeros arquivos de remessa e realmente não foi enviada para o banco nenhuma informação sobre concessão de desconto ou abatimento, porém, nos arquivos de retorno que o banco envia, os descontos estão lá. Notamos que, curiosamente, este caso (pagar um valor inferior ao valor original) ocorreu várias vezes e (mais curiosamente ainda) todas as ocorrências são do mesmo cliente deste nosso cliente. Gostaria que vocês me ajudassem a entender o que está acontecendo. É possível pagar um valor inferior mesmo quando não é informado para o banco a concessão de desconto? Se for possível, há alguma maneira de "travar" isso? Alguém tem conhecimento da algum caso parecido com esse e tenha alguma informação que possa nos ajudar a esclarecer o assunto? Desde já agradeço.

Boa tarde. A mudança é necessária nos casos onde o usuário não informa valor de juros. Se o campo referente ao valor do juros estiver zerado, ao tentar imprimir boletos ou gerar arquivos de remessa, o sistema reporta o seguinte erro: "Código de Mora/Juros informado não é permitido para este banco!". Isso acontece em ambos os bancos (Itaú e Bradesco). Diante desse erro, acrescentei o valor '3' (que "teoricamente" seria isento de juros) nas units do Itaú e Bradesco. Após essa mudança, o erro deixou de ocorrer. Eu confesso que não consegui compreender porque o erro ocorre, sendo que, como você disse, Juliana, o Código de Mora não é utilizado nesses dois bancos. Mas o fato é que uma mensagem de erro é exibida caso o valor de juros seja zero e o campo fpCodigosMoraAceitos não contenha o valor '3'.

Bom dia, Juliana. Banco: Caixa Econômica Federal Layout: 240 Página do Manual: 12 Segmento: P Campo: 27.3P Descrição: Código do Juros de Mora Posição: 118 - 118 *C018 (pág. 31) Código do Juros de Mora Código adotado pela FEBRABAN para identificação do tipo de pagamento de juros de mora. 1 = Valor por Dia 2 = Taxa Mensal 3 = Isento 4 = Acata cadastramento na CAIXA Banco: Santander Layout: 240 Página do Manual: 3 Segmento: P Posição: 118 - 118 Descrição: Código do juros de mora Nota 21: CODIGO DE MORA (pág. 21) 1 = Valor por dia - Informar no campo o valor/dia a mora a ser cobrada. 2 = Taxa Mensal - Informar no campo taxa mensal o percentual a ser aplicado sobre valor do titulo que será calculado por dia de atraso. 3 = Isento 4 = Utilizar comissão permanência do Banco por dia de atraso 5 = Tolerância valor por dia (cobrar juros a partir de) 6 = Tolerância taxa mensal (cobrar juros a partir de) * Para o código igual 4, o campo “taxa mensal” não deverá conter informação. Em relação aos bancos Bradesco e Itaú (ambos layout 400), eu também não consegui encontrar nos manuais a informação sobre os valores que são aceitos para esse campo referente ao código de mora/juros, mas, nos testes que realizamos aqui, ocorreu o erro que eu apontei nessa postagem, ou seja, quando o valor de juros está zerado é exibida a mensagem de erro: "Código de Mora/Juros informado não é permitido para este banco!". Acrescentei o valor '3' no campo fpCodigosMoraAceitos (que antes só recebia os valores '1' e '2') e deu certo. Portanto, concluímos que o valor '3' é aceito por estes bancos e que o valor '3' representa o caso "Isento", ou seja, quando o valor de juros está zerado. Como não consegui encontrar as informações nos manuais, apenas acrescentei o '3' mesmo. Obs: segue em anexo a unit da Caixa atualizada, com as alterações feitas segundo o manual. De acordo com o manual do svn, os valores aceitos são: 1, 2, 3 e 4. Como eu analisei um manual desatualizado, acabei passando apenas os valores 1, 2 e 3 para o campo fpCodigosMoraAceitos. Peço desculpas por este equívoco. ACBrBancoCaixa.pas

Boa tarde. Após a solução do problema acima (que identificamos na unit do Banco do Brasil), resolvemos testar se o mesmo problema acontece nos outros bancos que nossos clientes utilizam. Verificamos que os seguintes bancos apresentam o mesmo problema: Bradesco, Caixa Econômica Federal, Itaú e Santander. Segue em anexo as units alteradas respeitando as particularidades de cada banco, segundo os manuais. Obs1: não analisamos todos os bancos suportados pelo ACBrBoleto, mas apenas os que os nossos clientes utilizam atualmente. Peço, por gentileza, que as units em anexo sejam analisadas e que alguém se disponha a verificar os demais bancos. Obs2: verifiquei também o banco Sicoob e o mesmo não apresenta o problema. ACBrBancoBradesco.pas ACBrBancoCaixa.pas ACBrBancoItau.pas ACBrBancoSantander.pas

Ok, Juliana. Obrigado!

Bom dia. Um de nossos clientes que emitem boleto pelo Banco do Brasil está tendo problemas ao tentar imprimir os boletos quando ele não informa valor de juros diários, ou seja, quando o campo ValorMoraJuros recebe zero. Ao tentar imprimir, o sistema reporta a seguinte mensagem: "Código de Mora/Juros informado não é permitido para este banco!". Verificando o manual do Banco do Brasil (layout 240), vimos que a posição referente ao código de mora/juros é a 118 do segmento P. Segundo o manual, esta posição aceita os seguintes valores: 1 - Valor por Dia 2 - Taxa Mensal 3 - Isento No método GerarRegistroTransacao240 da unit ACBrBancoBrasil temos o seguinte: IfThen(ValorMoraJuros > 0, '1', '3') + // 118 - Código de juros de mora: Valor por dia Analisando a linha acima, concluímos que se for informado um valor para os juros, a posição 118 vai receber "1", senão vai receber "3". Ambos (1 e 3) são valores aceitos, de acordo com o manual. No método TACBrBancoClass.create da unit ACBrBoleto temos o seguinte: fpCodigosMoraAceitos := '12'; Logo, para todos os bancos, os valores aceitos são: 1 e 2. Como o sistema está tentando passar "3" para esse campo, a mensagem de erro relatada pelo cliente está sendo exibida. A solução que encontramos foi acrescentar o valor "3" no campo fpCodigosMoraAceitos, mas apenas na implementação que há na unit ACBrBancoBrasil. Dessa maneira. constructor TACBrBancoBrasil.create(AOwner: TACBrBanco); begin inherited create(AOwner); fpDigito := 9; fpNome := 'Banco do Brasil'; fpNumero := 001; fpTamanhoMaximoNossoNum := 0; fpTamanhoConta := 12; fpTamanhoAgencia := 4; fpTamanhoCarteira:= 2; fpCodigosMoraAceitos := '123'; end; Segue em anexo a unit alterada para análise. ACBrBancoBrasil.pas

Bom dia. Um de nossos clientes que emite boletos do Itaú entrou em contato conosco alegando que, ao tratar o arquivo de retorno, alguns dos boletos que estavam sendo tratados e baixados não deveriam ser lidos pelo sistema, pois eram títulos que "sofreram a negativação expressa do Serasa". Pegamos o arquivo de retorno dele para analisar e notamos que esses boletos que ele chama de "negativados" apresentavam algumas características em comum: o valor recebido é de R$ 5,00 para todos e a data crédito (posições 296 a 301) está em branco. Segundo o cliente, apesar de esses boletos estarem presentes no arquivo de retorno e apresentarem informações sobre valor recebido, eles não deveriam ser baixados pelo nosso sistema. O único critério que usamos em nosso sistema para verificar se o título presente no arquivo de retorno será baixado ou não é justamente se o valor recebido for maior que zero. Como, nesse caso, o valor recebido de todos os boletos que o cliente afirma que não deveriam ser baixados é de R$ 5,00, eles foram baixados. Analisando o arquivo de retorno, notamos também que os demais boletos que o nosso sistema baixou estão com o campo data crédito (posições 296 a 301) preenchido, portanto, só os tais “boletos negativados” estão com esse campo vazio. Minhas dúvidas são as seguintes: alguém já lidou com um caso como esse? Esses tais “boletos negativados” realmente não devem ser baixados? Se não devem, por que apresentam valor recebido de R$ 5,00? Se devem, por que a data de crédito está em branco? Como tratar esse tipo de situação no sistema? Sei que a maioria das dúvidas não estão relacionadas diretamente ao componente ACBrBoleto, mas peço a ajuda de vocês para pelo menos termos um norte para a solução do problema. Banco: Itaú Carteira: 109 Layout: CNAB400