RobertoSchuster

Boa tarde pessoal, Poderiam me tirar uma dúvida, por favor? Verifiquei que no Banco do Brasil, o tipo de ocorrência toRetornoTituloPagoEmCheque equivale a "46-Título pago com cheque, aguardando compensação". Ou seja, o título ainda não está liquidado. Ainda precisa de uma confirmação de liquidação através de outra ocorrência, correto?. Notei isso porque, até agora, na minha aplicação este tipo de ocorrência estava liquidando o boleto e o cliente reportou que este comportamento estava errado. Neste sentido, gostaria de saber como vocês estão tratando este tipo ocorrência e se isso vale para todos os bancos. Pergunto porque no Bradesco a descrição para este tipo de ocorrência não diz nada sobre "aguardando compensação" (16-Titulo Pago em Cheque - Vinculado"). Ou seja, será que o comportamento é o mesmo? Obrigado.

Verifiquei melhor e, na verdade, somente as units do Banco do Brasil e Caixa possuem este procedimento de "mascarar" o NumeroDocumento (na Caixa, acontece o mesmo com o campo SeuNumero). Bom, este é apenas um apontamento para contribuir, visto que o comportamento da leitura do retorno nestas duas units possui esta particularidade em relação às as demais. Comentei estas linhas aqui nos meus fontes sem problemas.

Boa tarde, Já verifiquei e não encontrei detalhamento sobre esta alteração. Juliana, é que agora não é mais possível saber com certeza se o valor em NumeroDocumento é realmente o NumeroDocumento, já que agora ele pode corresponder ao NossoNumero. Qual a vantagem em preencher NumeroDocumento com uma informação que não corresponde ao numero do documento, sendo que o campo NossoNumero já traz esta mesma informação? Ambos os campos estão disponíveis para serem utilizados. Obrigado pela atenção.

Bom dia, Verifiquei que, há algum tempo, o trecho de códio abaixo foi incluído nas funções "LerRetorno" de alguns bancos, como é o caso do LerRetorno240 da unit do Banco do Brasil. Como demorei pra atualizar os fontes, só agora isso impactou em mim. // quando o numero documento vier em branco if Trim(NumeroDocumento) = '' then NumeroDocumento := NossoNumero; Alguém, por gentileza, poderia me esclarecer por que isso foi incluído? Pergunto porque isso mudou a maneira que meu software encontra os boletos ao ler o retorno, uma vez que se tratam de dois campos distintos. Sei que posso simplesmente ir lá e comentar estas linhas, mas não seria mais democrático deixar que cada um trate desses dois campos em seu próprio software, em vez de "mascarar" o valor do campo NumeroDocumento diretamente na função LerRetorno? Att,

Boa tarde, Vou aproveitar e disponibilizar mais duas correções na geração da remessa do Cecred. Juliana, pode considerar este arquivo em vez do anterior. 1. Separação do campo Bairro, pois o mesmo estava sendo incluido no campo Endereço, o que resulta em rejeição no Internet Banking, conforme imagem abaixo. 2. Número de dias para protesto em branco se não houver instrução de protesto, conforme instruções repassadas pelo banco durante processo de homologação. Por gentileza, se possível, manter os números das posições nos comentários, pois facilita muito o entendimento e manutenção. Att, ACBrBancoCecred.pas

Bom dia Juliana, Acredito que a segunda instrução (posição 159 a 160) ficou faltando. Segue correção. Att, ACBrBancoCecred.pas

Obrigado Juliomar. Assim que possível eu posto os demais layouts do fortes (paisagem, etc), sem as "identações loucas".

Olá hleorj, Por enquanto ficaria meio na conta mão, pois não utilizo e não tenho o Fast instalado. Vamos aguardar se as alterações no Fortes serão aprovadas ou não.

Seguem fontes alterados para análise. Fiz sem linhas entre os volumes, caso precise posso incluir sem problemas. Também não defini um limite de volumes, já que ficou dinâmico. Se aprovado, posso incluir aos demais layouts (paisagem, continuo, etc). Att, ACBrNFeDANFeRLRetrato.pas ACBrNFeDANFeRLRetrato.dfm

Posso implementar. Assim que finalizar posto aqui para análise. (Se alguém já fez ou começou a implementar, por favor me avise.)

Bom dia Vinirg, Me deparei com o mesmo problema. Ainda em busca de uma solução. Laurivan, O que o Vinirg quis dizer é que antes era possível emitir a nota informando o Código de Regime Tributário incorreto propositalmente, possibilitando a realização de testes para clientes de diferentes regimes tributários. Era o que eu praticava aqui também, utilizava o próprio certificado da empresa (CRT=Simples Nacional) e podia emitir notas em homologação com tributação do regime normal (CRT=Regime Normal), por exemplo.

Bom dia, Realizei a migração do Trunk para o Trunk2, e escolhi utilizar o FortesReport para imprimir o DANFE da NF-e (antes eu utilizava o Rave). Um dos efeitos colaterais obtidos foi o problema relatado aqui neste post, pois antes eu conseguia imprimir o logo via stream. Neste sentido, fica aqui mais um voto para o possível commit das alterações do Gustavo (pelo menos em relação à impressão do logo). Alterei aqui no meu projeto e funcionou bem. Att, Roberto.

Boa tarde Juliomar, Problema corrigido em relação ao campo CNPJ / CPF. Mesmo em fonte 8 ainda cortava o último dígito, então defini para 7.5. Quanto aos demais campos circulados no primeiro post, verifiquei que seu tamanho também é definido de forma fixa no código, então não alterei (na minha opinião não precisaria ser tamanho fixo). Segue em anexo. ACBrDANFeCBRaveRetrato.pas Att,

Bom dia, Alguém mais com este problema?

Olá, Verifiquei no DANFE que em alguns campos o texto não estava completo, com o último dígito faltando, como o campo do Protocolo, em que o último dígito da hora não estava sendo exibido. Então, no componente DANFERaveCB, reduzi o tamanho nas propriedades TamanhoFonte_ANTT, e TamanhoFonte_DemaisCampos e resolveu para o campo Protocolo, pois a fonte diminuiu. No entanto, verifiquei que os campos FRETE POR CONTA e CNPJ / CPF, no grupo TRANSPORTADOR, bem como os campos no grupo FATURA/DUPLICATAS, não sofreram alterações no tamanho da fonte. Ou seja, todos os campos reduzem, menos eles. E justamente o CNPJ do transportador está cortando o último dígito. Para exemplificar, defini o tamanho da fonte 3 para tornar bem evidente a diferencia entre os campos que reduzem e os que não se alteram. Imagens abaixo e em anexo.