Joel

Bom dia chefe, bacana, vou ver se consigo atualizar e fazer um teste, segunda feira é aquela correria, então já viu ne hehe. Muito obrigado, agradeço seu contato!

Opa bacana Juliana! Mais uma vez obrigado! Vamos estar no aguardo, enquanto isso vou contornando aqui hehe. Abraços!

Olá Juliana, obrigado pelo retorno. No meu caso, não vou utilizar o nosso número para baixar meus títulos, utilizo o meu numero. o problema é que, como na leitura do retorno existe uma validação, o nosso numero juntando com o ano que é colocado na frente fica maior que o máximo de 5 posições determinado na constante e no copy. Acredito que fica com uns 9 digitos por ai, e acaba sendo barrado na validação que comentei, não deixando eu fazer o retorno. Teria como ser flexivel este tamanho será ne? Ou ao menos validar o tamanho máximo do layout. Desculpe não havia visto este po

Bom dia pessoal tudo bem? Encontrei este post e acho que tem relação com o problema que encontrei esta semana em um cliente onde o nosso número está beeem grande. O meu problema se encontra no RETORNO, vi que estão com problema na emissão, mas eu não tenho este problema de emissão, mesmo com um número grande de nosso número. Baseado no tamanho máximo do nosso número que consta 20 posições (posicao 38 a 57) no layout cnab240, reparei em varios layouts de outros bancos além do sicredi, precisei alterar o limite máximo de caracteres deste campo para o tamanho permitido 20. uni

A sim, obrigado Juliana. Sim essa ordenação eu reparei. Mas somente ela não basta na forma que pensei. Se conseguíssemos divulgar a importância de padronizar o titulo entende? Tipo BANCO - PROBLEMA. Ao menos aqui no tópico do CBRBOLETO , iria funcionar legal. E ainda, se tivesse a ordenação por "titulo e data de atualização" juntos, ficaria ordenado pelo banco e a ultima data de atualização, seriá bem pratico para localizar seu tópico e teríamos menos tópicos repetidos.

Olá pessoal , na funçao GerarRegistroTransacao240 o campo TipoAvalista em caso de não existir precisa ser 0, atualmente 9. Segue unit alterada em anexo e layout cnab240 do sicred . Registro detalh Q está na pagina 48 coluna 154. {Avalista} case Sacado.SacadoAvalista.Pessoa of pFisica: TipoAvalista := '1'; pJuridica: TipoAvalista := '2'; else TipoAvalista := '0'; // alterado por joel takei 17/04/2019 end; Gostaria de dar uma sugestão aos moderadores, será que vocês não conseguem mudar a ordenação do forum par

Bom dia José, entendi a sua colocação. Pois olhando no código está assim: IfThen(ValorMoraJuros = 0, '3', '1') // 118 a 118 - Código do juro de mora então caso não tenha valor de mora ele envia 0, caso contrario envia 3. Até funciona sim, mas como existe o campo Titulo.CodigoMora no componente, e ele é utilizado não somente para este banco, eu preencho este campo sempre conforme exigências do banco. Este ifthen está fazendo uma "adaptação" para não usar este campo, porém como existe uma validação com uma variável no construtor e está desta forma: fpCodigo

olá Juliana, desculpe a demora, eu achei que havia marcado para seguir esta conversa, mas acho que não marquei e acabei não sabendo de sua resposta. Estranho que eu fiz esta alteração e para mim resolveu o erro na homologação. Verifiquei que esta variável é utilizada apenas para validação ou seja ela não é alterada em nenhum lugar do código, por isso não entendi porque no seu teste ele manteve assim. não encontrei outro local onde definisse estes valores.

Boa tarde pessoal. Precisamos atualizar a unit ACBrBancoSicredi; No seu construtor está: fpCodigosMoraAceitos := 'AB'; precisamos alterar para: fpCodigosMoraAceitos:= '012'; Segue unit alterada em anexo e manual do sicred cnab240. Muito obrigado! sicredi manual-cnab-240.pdf ACBrBancoSicredi.pas

Italo, rejeitada não consegui mais, pois era apenas em tela a validação, nem enviava a nota. Estou enviando em anexo a autorizada. Uma do meu sistema e a outra uma de entrada do fornecedor do meu cliente. Acredito que possa ser isso também, conforme nosso amigo comentou, deve ser conforme o código ANP ne, mas e agora que sem as 3 tags a nota de gás não vai? Vi este site dizendo isso: https://www.oobj.com.br/bc/article/rejeição-461-rejeição-informado-campos-de-percentual-de-glp-e-ou-glgnn-e-ou-glgni-para-produto-diferente-de-glp-como-resolver-755.html Rejeição 461:

Muito obrigado Italo! Grande abraço!

Ola Italo, concordo plenamente com você parceiro, porém, não sei se é problema no validador da receita sei lá, mas mesmo com valores zerados eles querem que as tags vão no xml, por isso da solicitação. Já fizemos os testes aqui na empresa e não vai sem as tags. Eu trabalho com muitas distribuidoras de gás. No xml de seus fornecedores o xml vem com as tags. Por favor se pudrr alterar, enquanto a receita não acerta seus validadores, agradeço

Algum moderador por favor subir estas correções para que possamos atualizar o fonte. obrigado! Corrigido as tags de pGLP, pGNn, pGNi Gerador.wCampo(tcStr, 'LA03', 'descANP', 02, 95, 1, nfe.Det.Prod.comb.descANP, DSC_DESCANP); if nfe.Det.Prod.comb.pGLP = 100 then Gerador.wCampo(tcDe2, 'LA03a', 'pGLP ', 01, 7, 1, nfe.Det.Prod.comb.pGLP, DSC_PGLP) else Gerador.wCampo(tcDe4, 'LA03a', 'pGLP ', 01, 7, 1, nfe.Det.Prod.comb.pGLP, DSC_PGLP); if nfe.Det.Prod.comb.pGNn = 100 then Gerador.wCampo(tcDe2, 'LA03b', 'p

Corrigido as tags de pGLP, pGNn, pGNi A ocorrencia dessas tags precisam ser 1 pois a receita exige essas tags quando por exemplo uma delas for igual 100% , quando o valor for quebrado elas já já vão de toda forma. Fiz a alteração a baixo no fonte, por favor se puderem subir a correção. Aproveitei e tirei uns if que não estavam fazendo nada. // if nfe.Det.Prod.comb.pGLP = 100 then // Gerador.wCampo(tcDe2, 'LA03a', 'pGLP ', 01, 7, 1, nfe.Det.Prod.comb.pGLP, DSC_PGLP) // else // Gerador.wCampo(tcDe4, 'LA03a', 'pGLP ', 01, 7, 0, nfe.Det.Prod.c

foi colocado novos parametros como a uf e se a busca é exata ou não. é preciso adaptar nossos códigos. o componente está ok.