theiller

Olá, para o Sicoob no processo de homologação, existe uma área para validação do arquivo remessa: https://www.sicoob.com.br/validador-cnab240-cobranca?p_auth=KeQ8zP2T&p_p_id=validadorcnab_WAR_portalsicoobinternetsp&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-1&p_p_col_pos=1&p_p_col_count=2&_validadorcnab_WAR_portalsicoobinternetsp_java No CNAB 240 Header posição 72 DigitoVerificadorAgenciaConta, possui uma validação em que não aceita que seja definido vazio: "Valor informado diverge do valor default definido para o campo: 0", mas no forte o default é "bracos/espaço": PadRight(DigitoVerificadorAgenciaConta, 1, ' ') Como essa propriedade é tipo String e outros bancos permitirem passar "branco/espaço", uma validação de layout acredito que poderia/deveria ser tratado diretamente pelo componente, por se tratar de uma regra estrutural para validação no processo de homologação: PadRight(DigitoVerificadorAgenciaConta, 1, '0') Dessa forma evitaria codificar condições para bancos no processo cadastral / gerar remessa, situação já vivenciada em outros tópicos como esse: Segue unit em anexo com o ajuste ACBrBancoBancoob.pas

Ajustado devido regime caixa, necessário de popular bloco F525. Segue unit em anexo. ACBrEPCBlocos.pas

Favor corrigir falha na conversão de texto pra tipo: Unit: ACBrEPCBlocos Function: StrToInd_Rec AValue = '03' function StrToInd_Rec(const AValue: string):TACBrInd_Rec; begin if AValue = '01' then Result := crCliente else if AValue = '02' then Result := crAdministradora else if AValue = '03' then Result := crTituloDeCredito else if AValue = '04' then Result := crDocumentoFiscal else if AValue = '05' then Result := crItemVendido else if AValue = '99' then Result := crOutros else raise Exception.Create(format('Valor informado [%s] deve estar entre (01,02,03,04,05 e 99)',[AValue])); end;

Olá, Os bancos possuem os dados da agencia, conta, cedente e convenio. No Header do CNAB240 na identificação da empresa da empresa é passado o número do convenio, porem no CNAB400 esta sendo passado o numero do cedente. Já havia feito esse ajuste à tempos no fonte backup versão "Trunc" descontinuado, se possível avaliem para disponibilizar em SVN. Segue em anexo print do manual e fonte. Observação, esse fonte em anexo contem os ajustes documentos em outros dois (2) artigos: ACBrBancoBradesco.pas

Correção: Utilizei da função IIF indevidamente, o certo seria IfThen favor ajustar em fontes do anexo acima.

Olá, Fiz um ajuste para o arquivo de remessa Bradesco CNAB400 referente as instruções (Protesto/Baixa). Existe uma particularidade em que a "instrução1" refere-se ao código da operação, podendo ser para para (Protesto) ou (Baixa/Devolução), enquanto a "instrução2" refere-se aos dias equivalente ao código passada na "instrução1". O ACBrTitulo possui as propriedades Instrucao1, Instrucao2, DataBaixa e DataProtesto, geralmente a Instrucao1 é destinada ao protesto e a instrução2 destina a baixa/devolução, mas como dito acima no Bradesco CNAB400 não trata exatamente dessa forma. Identifiquei que no fonte existe o tratamento para o protesto inclusive passando um código direto, embora exista mais de um tipo de protesto possível ('06' e '05'), um outro caso é após os possíveis "elses" é utilizado o conteúdo real definido nas instuções 1 e 2 porem como existe um tratamento melhorado para o protesto (Comparando "DataProtesto"), creio que também deveria existir para o caso de baixa/devolução (Comparando "DataBaixa") e utilizar os valores direto das instruções em ultimo caso, pois geralmente tempos em nosso sistemas definições especificas para o código e dias para cada instrução (Protesto/Baixa). Fiz um ajuste para tratar o protesto conforme instrução com "IFF" para tratar o "legado" que já estava sendo passado valor fixo "06". Fiz um ajuste quanto a data baixa conforme condição já existente para o protesto. Segue em anexos: prints, manual, e fonte. Espero que possam avaliar/melhorar/disponibilizar em SVN. Observação: Nesse fonte já consta um outro ajuste realizado e documento em artigo: Bradesco_CNAB_400.pdf ACBrBancoBradesco.pas

Olá, Identifiquei uma falha na remessa Bradesco CNAB400 no registro tipo 2 referente aos campos de descontos. As posições referente aos valores (Data Desconto2, Valor Desconto2, Data Desconto3, Valor Desconto3) requerem dados numéricos, porem está sendo passado o caracteres "espaço em branco" que é considerado alfanumérico. Fiz o ajuste formatando o conteúdo corretamente, embora zerado e não através das propriedades especificas, pois como não faço uso desse recurso e já estava sendo passando um valor nulo, não me preocupei tanto quanto a associação. Também adicionei como comentário as posições especificas na concatenação da string que monta a linha. A análise foi feio através do manual e site de validação de arquivo remessa próprio Bradesco (aba Cobrança): https://banco.bradesco/assets/pessoajuridica/pdf/4008-524-0121-layout-cobranca-versao-portugues.pdf https://banco.bradesco/html/pessoajuridica/solucoes-integradas/outros/layout-de-arquivo.shtm Segue anexos para analise, e atualização do componente! ACBrBancoBradesco.pas

O ajuste está funcional!!!

Tambem passo por essas situações algumas vezes, mas avaliando sei caso comparei seus XML e notei que o fechamento de algumas tags possuem espaco, ex.: "<cEAN />", "<cEANTrib />", "<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />" "<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />" "<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />" já a tag "DigestValue" estão idênticos No xml do banco está com o padrao UTF-8 e no outro não, Porem no xml comum tem a informação de autorização <infProt> Você utilizou a mesma aplicação para gerar os dois XML? Segue anexo dos seus XML com algumas quebras de linha identificado os exemplos da comparação. 35160208957311000155550000001983351450305138-nfe.xml 35160208957311000155550000001983351450305138-nfe-banco.xml

Ok, obrigado!

Algum moderador poderia posta as mudanças?

Olá, Hoje 13.02.2015 a Sefaz BA está em modo contingencia SVCRS, e estive com alguns problemas. Após atualizar os fontes e continuar com o problema, identifiquei que a falha ocorre porque ao "DefinirServicoEAction" a BAHIA possui um tratamento diferenciado, porem deve ser apenas quando a "FormaEmissaão" for "teNormal", pois como está trabalhando em contingência não deve utilizar dessa outra URL. Identificado essa situação para os serviços de Status, Consulta e Inutilização. Segue anexo da unit alterada para ajuste em ACBr. ACBrNFeWebServices.pas

Tive problemas com o modelo FastReport, o pessoal do ACBr ainda não fez a correção: http://www.projetoacbr.com.br/forum/topic/16711-nfse-impressão-fr-campo-xitemlistaservico-incompleto/

Citei o caso em outro chamado também ajustei outro caso quando ao numero SVN, e postei o DFM, se puder subir para SVN agradeço.

Outra coisa que observei é sobre um outro campo que esta com o tamanho diferente do necessário é o campo "xItemListaServico" que esta apenas com 100 e existem textos de classificação de serviço que necessitam de muito mais. Esse caso eu tambem havia notificado no link abaixo: http://www.projetoacbr.com.br/forum/topic/16711-nfse-impressão-fr-campo-xitemlistaservico-incompleto/ CÓDIGO DE CLASSIFICAÇÃO DO SERVIÇO:1401 Conteúdo original XML: "Lubrificacao, limpeza, lustracao, revisao, carga e recarga, conserto, restauracao, blindagem, manutencao e conservacao de maquinas, veiculos, aparelhos, equipamentos, motores, elevadores ou de qualquer objeto (exceto pecas e partes empregadas, que ficam sujeitas ao ICMS)." Conteúdo registrado no cds apenas 100 caracteres: "Lubrificacao, limpeza, lustracao, revisao, carga e recarga, conserto, restauracao, blindagem, manute" Favor os ajustar no svn, segue o arquivo dfm com esse ajuste, alem do ajuste citado anteriomente ACBrNFSeDANFSeFRDM.dfm