fernandoschulz

Boa tarde @João Paulo F. Bellucci No meu caso eu só voltei a versão, você implementou algo diferente do que tinha na versão anterior?

Boa Tarde, Fiz update no AcBr e tentando homologar um cliente no Santander obtive o mesmo problema do @João Paulo F. Bellucci, a remessa está sendo gerada com 399 caracteres. O problema está ali nas posições que o João já havia dito, estava assim na versão anterior: Copy(Cedente.Conta,Length(Cedente.Conta),1) + // 384 a 384 Cedente.ContaDigito + Space(6) + // 385 a 391 e que agora está assim: Cedente.ContaDigito + Space(6) + // 384 a 391 Até se for contar o dígito + 6 espaços, não fecha o número de posições que deveria ir de 384 a 391, Ex: "2XXXXXX" = "384, 385, 386, 387, 388, 389, 390" Por fim, de acordo com o manual do banco versão 2.15 Março/2017 página 16: Complemento Conta Cobrança (posições 384-385): preencher com a última posição da conta cobrança e com o dígito (CCCCCCCCC-D) Sendo assim, creio que a última alteração feita que informa apenas o dígito da conta não está correto. Agradeço a atenção.

Bom dia, Fiz um update agora e vi que foram incorporadas as alterações, vou botar uma versão no cliente e testar, mas creio que não irá gerar problemas, visto que as alterações estão iguais as que eu tinha feito e já está em produção no cliente, qualquer inconformidade eu retorno. Obrigado!! Fernando Schulz.

Bom dia @Juliomar Marchetti Preciso ressuscitar esse tópico só para confirmar com você, ninguém colaborou ainda com um tratamento nesse erro na qual o componente indica que o layout não é um cnab240 quando o retorno volta com código 5 "Remessa rejeitada " na posição 143 da primeira linha do retorno, certo? Estou perguntando porque achei estranho os tópicos onde foi conversado sobre isso serem tão antigos, e o tratamento ainda não existe. Caso ainda não tenha sido implementado, quando me sobrar um tempo posso fazer e colaborar, pois a mensagem de que o layout está errado está me dando bastante problema, tenho um cliente que por algum motivo bastante remessas dele são rejeitadas e fica gerando suporte. Obrigado, Fernando Schulz.

Pois então @Roberto.Godinho, também não acredito que isso iria gerar problemas, mas enfim, só para ter a informação no XML eu fiz assim, to colocando uma tag [OBS] dentro da discriminação dos serviços, aí antes de imprimir eu tiro tudo que está dessa tag para frente da propriedade de discriminação, e utilizo o que tenho salvo no banco para inserir nas outras informações como você me sugeriu. Agradeço a ajuda! (y)

Boa tarde @Roberto.Godinho Agradeço a resposta, realmente é uma solução bem simples, até implementei e funcionou como você disse, a dúvida que ficou é a seguinte, até onde eu sei a legislação federal não permite que uma NF-e seja impressa contendo informações que não estão no XML, será que a NFS-e não possui a mesma regra?

Bom dia Italo, Perdão, acho que deixei meio confusa minha mensagem, me enrolei com os nomes, essa parte de que o rps não tem a tag OutrasInformacoes to sabendo, tanto que atualmente nas notas que programo no braço eu uso a discriminação dos serviços para isso, e mesmo as que possuem a tag específica como a Betha, ela não aceita uma grande quantidade de caracteres e muitas vezes nem cabe a OBS inteira. Minha dúvida é, existe alguma forma de eu enviar uma observação e receber de volta e conseguir colocar isso na parte de Outras Informações da impressão do RPS no componente do ACBr? Agradeço desde já a atenção.

Boa tarde @Italo Jurisato Junior Precisei ressuscitar o tópico pois estou com dúvidas referente a essa observação e necessito de algumas dicas de como o pessoal está fazendo. Estou programando para o provedor Publica (Caçador-SC) Faço nfs-e a um bom tempo, a grande maioria fiz no braço até que comecei a utilizar o ACBr, porém, mesmo as notas enviadas por ACBr eu faço a impressão manualmente, mas decidi começar a usar a impressão do ACBr e cheguei nesse problema da observação (OutrasInformacoes). Nas notas que eu programei sempre utilizei a própria discriminação como você mesmo deu a ideia em alguns tópicos aqui para enviar as informações que necessito, porém no ACBr eu não sei como utilizaria ele, pois se eu enviar nessa tag, na hora da impressão vai sair na parte de descrição dos serviços ao invés do rodapé nas Outras Informações, tem alguma forma de fazer isso? se não tiver eu até tenho uma ideia e poderia implementar, criar uma variável parecida com a de QuebraLinha hoje, onde seria configurado uma tag informando que dali para frente é para sair na parte de OutrasInformacoes ao invés de descrição dos serviços. Ou se tiver alguma outra sugestão para mim. Agradeço a atenção.

@Luciano. Perdão, tens razão, a multa não sai em %, para resolver eu setei a propriedade ImprimirMensagemPadrao para false e criei minhas próprias instruções.

@Luciano. Essa questão da impressão é bucha mesmo, como te disse no meu pediram para ficar 237 mesmo, dessa forma já vimos que não tem padrão essa porcaria. Com relação a exibição não sei se já resolveu, mas enfim, se tu informar a propriedade CodigoMora := 2 tanto o valor de juros quanto de multa irão sair em % na impressão, quando homologuei precisei mudar isso tbm.

@Luciano. Olha, no meu caso não fiz nada disso aí, eu configurei todo o meu sistema como banco 237, como se o cliente estivesse usando Bradesco mesmo, aí na hora da impressão, gerar remessa e ler retorno o componente já está entendendo como banco 237 e não precisei alterar nada, porque até mesmo na impressão (no meu caso) deve sair como banco Bradesco (logo, código). Se informe com o suporte deles antes, porque eu fiz alterações para fazer a impressão do boleto com o código do banco que me passaram aquela vez (não lembro qual era), e no fim tive que voltar tudo porque não foi necessário, tbm fiquei meio perdido nesses códigos do banco e no fim não era para mudar nada.

Bom dia @Luciano. Não temos muitos clientes com Unicred, mas os poucos que homologamos está tudo certo, estão utilizando geração de remessa, leitura de retorno, impressão de boletos, tudo normal faz um tempo já. Se muda de região para região eu não sei te responder, mas creio que não. Att, Fernando Schulz.

Bom dia, Essas alterações serão disponibilizadas no svn? att, Fernando Schulz.

Oi @Juliana Tamizou, Sim, um responsável pelas homologações de remessas do Sicoob de Blumenau nos deu um ok nessa remessa gerada, e a partir disso nosso cliente está gerando as remessas e recebendo os retornos corretamente a alguns dias, e já tenho outro cliente com a remessa aprovada também.

Boa tarde @Juliomar Marchetti Pois então, essas alterações que fiz não foi em cima do manual e sim pelo que o validador do Sicoob me apresentou de erros, até porque o manual deles não deixa bem claro principalmente essa questão do número de registros do lote e do arquivo, por exemplo, no manual diz que nesses campos precisa o "Nr. de registros do lote" e "Nr. de registros do Arquivo" mas não deixa claro essa questão de você precisar multiplicar o nr. de registros pelo número de segmentos que esse registro tem, e nem que precisa somar as linhas dos cabeçalhos e rodapés, além disso, pelo que venho acompanhando o tópico aqui tem gente que conseguiu validar sem essas alterações, pelo menos tive essa impressão, então fico na dúvida se subir isso para o svn não vai acabar atrapalhando quem já está usando, isso se alguém já estiver usando o sicoob, mas infelizmente com essas alterações foi a única forma de conseguir validar, mas enfim, vou anexar o manual e a Unit que alterei. Agradeço a atenção. ACBrBancoBancoob.pas Layout Sicoob - Sistema Proprio.xls

Boa tarde, Realmente esse validador do Sicoob está uma novela mexicana, acabei tendo que voltar todas as alterações que foram feitas no AcBr e ainda mais duas correções que são o problema que o @michael_castilho e o @Luciano Jr. Mattiello estão tendo, o Sicoob me retornou assim na última validação que tentei fazer: Corrigir no header do arquivo remessa posições 33 a 52 o código do cedente Informado: '00000000000000000000' Correto: ' ' - Corrigir no header do arquivo remessa posições 164 a 166 o Nº da versão do layout do arquivo. Informado: '087' Correto: '081' - Corrigir no header do lote do arquivo remessa posições 014 a 016 o número da versão do layout do lote. Informado: '045' Correto: '040' Até aqui eu só voltei as alterações do AcBr - Corrigir no trailler do lote do arquivo remessa posições 018 a 023 a quantidade de registros no lote. Informado: '000011' Correto: '000014' - Corrigir no trailler do arquivo remessa posições 024 a 029 a quantidade de registros do arquivo. Informado: '000004' Correto: '000016' Esses dois acima tive que fazer o seguinte: No trailler do lote fiz assim: //IntToStrZero((3 * ARemessa.Count-1), 6) + //Quantidade de Registro da Remessa IntToStrZero(((4 * (ARemessa.Count-1))+2), 6) //alterei para 4 * pois são 4 segmentos por registro, e somei 2 pois é a linha do cabeçalho e rodapé do lote que precisam ser somados. No trailler do Header fiz assim: //IntToStrZero(ARemessa.Count, 6) + //Quantidade de registros do arquivo, inclusive este registro que está sendo criado agora} IntToStrZero(((4 * (ARemessa.Count-1))+4), 6) //Mesma coisa do de cima, 4* pois são 4 segmentos por registro, e + 4 por causa das linhas do cabeçado e rodapé do lote e do arquivo. Com todas as alterações acima validou tudo, e meu cliente já está usando a alguns dias. Obs: Não sei se a programação ficou a melhor possível, mais foi a forma que achei de validar, agora toda vez q faço update no meu componente AcBr preciso verificar as diferenças nessa Unit.

Boa tarde, Precisei adicionar mais um código de ocorrência, dessa vez foi o C7 no "toRetornoLiquidade", ocorria o mesmo erro do C6 acima, ficou assim: toRetornoLiquidado: //06 case AnsiIndexStr(CodMotivo, ['A8', 'C7', 'H5', 'H6', 'H8', 'X1', 'X2', 'X3', 'X4', 'X5', 'X0', 'X6', 'X7', 'X8', 'X9', 'XA', 'XB']) of 0: Result:= 'A8-Recebimento da liquidação fora da rede Sicredi - via compensação eletrônica'; 1: Result:= 'C7-Título já baixado'; 2: Result:= 'H5-Recebimento de liquidação fora da rede Sicredi - VLB Inferior - Via compensação'; 3: Result:= 'H6-Recebimento de liquidação fora da rede Sicredi - VLB Superior - Via compensação'; 4: Result:= 'H8-Recebimento de liquidação fora da rede Sicredi - Contingência Via Compe'; 5: Result:= 'X1-Regularização centralizadora - Rede Sicredi'; 6: Result:= 'X2-Regularização centralizadora - Compensação'; 7: Result:= 'X3-Regularização centralizadora - Banco correspondente'; 8: Result:= 'X4-Regularização centralizadora - VLB Inferior - via Compensação'; 9: Result:= 'X5-Regularização centralizadora - VLB Superior - via Compensação'; 10: Result:= 'X0-Pago com cheque'; 11: Result:= 'X6-Pago com cheque - bloqueado 24 horas'; 12: Result:= 'X7-Pago com cheque - bloqueado 48 horas'; 13: Result:= 'X8-Pago com cheque - bloqueado 72 horas'; 14: Result:= 'X9-Pago com cheque - bloqueado 96 horas'; 15: Result:= 'XA-Pago com cheque - bloqueado 120 horas'; 16: Result:= 'XB-Pago com cheque - bloqueado 144 horas'; else case StrToInt(CodMotivo) of 00: Result:= '00-Ocorrência aceita, liquidação normal'; else Result:= PadLeft(CodMotivo,2,'0') +' - Outros Motivos'; end; end;

Boa Noite, O erro " 'C6' is not a valid integer value" aconteceu com um cliente meu também, fiz as alterações citadas acima e funcionou sem problemas. att, Fernando Schulz.

Perdão, me equivoquei em uma informação, não foi homologado por e-mail, e sim pelo próprio painel online, segue: O último arquivo que enviamos (que foi homologado) ocorreu os seguintes erros no validador sicoobnet: 16092201.REM [LINHA 1] [POSIÇÃO 164 a 166] [TAMANHO 3] [MENSAGEM NUMERO DA VERSÃO DO LAYOUT DO ARQUIVO INVÁLIDO] [LINHA 2] [POSIÇÃO 14 a 16] [TAMANHO 3] [MENSAGEM Nº DA VERSÃO DO LAYOUT DO LOTE INVÁLIDO] [LINHA 43] [POSIÇÃO 4 a 7] [TAMANHO 4] [MENSAGEM QUANTIDADE DE REGISTROS NO LOTE INVÁLIDO] [LINHA 43] [POSIÇÃO 4 a 7] [TAMANHO 4] [MENSAGEM QUANTIDADE DE TÍTULOS EM COBRANÇA INVÁLIDO] [LINHA 44] [POSIÇÃO 24 a 29] [TAMANHO 6] [MENSAGEM QUANTIDADE DE REGISTROS DO ARQUIVO INVÁLIDO] --------- Aí após isso enviamos uma resposta ao atendente pelo próprio validador, pois ele já havia nos avisado que esses erros acima não estavam realmente incorretos, precisava alterar apenas o código do convênio de "0" para vazio " ": Em: 22/09/2016 17:52 | Status: Aguardando Sicoob Boa tarde, Foi enviado a remessa com o ajuste no Código do Convênio -------- E em seguida nos deram a seguinte resposta: Autor: Cleiton Mathias Paulo | Em: 28/09/2016 11:15 | Status: Aguardando Desenvolvedor Bom dia! O último arquivo enviado foi validado com sucesso em nosso sistema. Próximo passo é gerar pelo menos três boletos de teste com valores pequenos, efetuar a importação do arquivo remessa através do Sicoobnet Empresarial, e sendo processado com sucesso efetuar o pagamento dos mesmos em três bancos distintos. Att.

Boa tarde, Algumas mensagens acima eu escrevi que o validador estava me acusando erro de nr. de posições incorretas no meu arquivo, isso era pitocagem minha mesmo, não estava informado a propriedade "codigoMora" e isso estava fazendo com que o arquivo gerado ficasse com 1 posição a menos. Acabei conseguindo validar as remessas de dois clientes, porém tem dois detalhes: O primeiro é que eu tive que voltar a alteração feita na posição 33 à 52 do Header do Arquivo, onde o validador sicoobnet pedia para inserir 20 posições com "0", mas na verdade deve ser seguido o manual mesmo e ser inserido 20 espaços em brancos, basicamente comentei o que foi alterado e voltei a programação "space(20)" O segundo é que para validar não adianta usar aquele validador online (sicoobnet) que na teoria serve para nos ajudar, o sicoob não quer admitir mais como o volmir falou em algumas mensagens acima ele está com problema e acusando erros que não existem, precisa ser validado diretamente com algum atendente por e-mail, seguindo isso eu consegui validar as remessas.

Boa tarde, Só para deixar registrado, hoje aconteceu o mesmo erro em um cliente meu, veio o motivo igual ao dele " (Ex: 'H5 ') ".. utilizei a solução que ele postou acima e resolveu.

Bom dia, Alguém ainda está com problemas na remessa para a sicoob? após as últimas alterações de número de versão e etc.. esses erros pararam, porém agora o validador deles me retorna esse erro aqui: A linha 3 do arquivo tem o tamanho inválido.Erro ao criar o registro: SegmentoP Nº Linha: 3 Ele indica que o arquivo está com 239 posições e deveria ter 240, entrei em contato com o banco e o cara lá disse que é isso mesmo, que meu arquivo está com tamanho errado. Verifiquei o fonte do AcBr e vi que na posição 240 conforme o manual pede (Uso Exclusivo FEBRABAN/CNAB: Brancos) está sendo inserido apenas um campo em branco, e acredito que o validador deles está ignorando esse campo vazio, pois eu coloquei um "0" na posição 240 só para ver o que acontecia, e a remessa passou no validador deles sem erros. Obs: no arquivo atual que o acbr gera, se abrir ele com notepad++ a posição 240 existe como um espaço em branco mesmo, ou seja, está dentro do que o manual pede.

Boa tarde @ESSystem agradeço a resposta, Fiz as modificações solicitadas pelo banco ali das versões do layout e informar o código de convênio conforme manual e mandei a remessa para eles olharem, assim que tiver uma resposta eu falo aqui tbm, aí vamos trocando informações. att, Fernando Schulz.

Boa tarde, @ESSystem você conseguiu fazer a correção dos problemas que postou na primeira imagem? recebi hoje uma resposta do banco exatamente com os mesmo problemas, acabei de fazer um update no componente e percebi que não foram corrigidos, o primeiro por exemplo: "A linha 1 posição 33 até 52, campo Código do Convênio, possui valor inválido. O esperado é um numérico." Olhei no fonte e vi que continua sendo passado fixo 20 espaços em branco "space(20) + // 33 a 52 - Brancos" Obs: Se ninguém implementou ainda eu posso fazer as modificações necessárias e postar aqui para serem analisadas, na verdade eu até pretendo fazer isso já, só quero uma orientação de como proceder após efetuar as correções ou se alguém já fez as modificações necessárias. att, Fernando Schulz.

Boa tarde Claudiomir Infelizmente meu boleto não havia protesto, então eu indiquei com 0 a propriedade DataProtesto, mais vamos ver se posso te ajudar, na impressão do boleto, a mensagem está dizendo que deverá ser protestado 15 dias após o vencimento? se for isso, a propriedade DataProtesto do AcBr, está passando com 15 dias a mais que a propriedade DataVencimento? não sei se chegasse a olhar a unit do Bradesco, mais quando tem DataProtesto > 0 ele bota default 06 + DaysBetween entre a data de vencimento e protesto. Com relação ao Valor Mora, aqui é estranho, o meu homologou em %, até porque a Unit do Bradesco pega o valor que você informa na propriedade ValorMoraJuros e faz ela * 100, ou seja, para mandar em R$ teria que mudar a Unit do Bradesco. Algo que possa te ajudar talvez, as mensagens padrões do AcBr vem o juros e multa em R$, se você informar a propriedade CodigoMora := 2, elas saem em % na impressão, e essa propriedade nem é usada no Bradesco, então informar ela não vai mudar nada na remessa, só vai mudar a impressão mesmo. Exemplo: Cobrar juros de 0,5% por dia de atraso Cobrar multa de 2% após o vencimento Isso eu tive que fazer porque o banco me repassou que eu não poderia mandar na remessa o valor de juros e multa em % e na impressão do boleto mostrar em R$, talvez isso te ajude também.