Jump to content

theiller

Membros
  • Content Count

    24
  • Joined

  • Last visited

Community Reputation

4 Neutral

About theiller

  • Rank
    Novato
  • Birthday 11/26/1989

Profile Information

  • Sexo
    Masculino
  • Localização
    Barreiras/BA

Recent Profile Visitors

578 profile views
  1. Ajustado devido regime caixa, necessário de popular bloco F525. Segue unit em anexo. ACBrEPCBlocos.pas
  2. 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;
  3. 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
  4. Correção: Utilizei da função IIF indevidamente, o certo seria IfThen favor ajustar em fontes do anexo acima.
  5. 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
  6. 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
  7. 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
  8. Algum moderador poderia posta as mudanças?
  9. 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
  10. 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/
  11. 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.
  12. 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
  13. Olá, Na impressão do DANFSE Modelo FastReport o número do RPS está sendo apresentado cortando o ultimo digito. Na unit "Fontes\ACBrNFSe\ACBrNFSeDANFSeFRDM.dfm" o "cdsIdentificacaoNumero" deve ter tamanho 16 e não 15. O problema ocorre porque o campo "Numero" em cdsIdentificacao->IdentificacaoRps está recebendo o valor formatado pela função "DFeUtil.FormatarNumeroDocumentoFiscalNFSe", que resulta 16 caracteres por conta do caracter ponto "." que é agregado na quinta casa após já ter sido formatado em 15 posições. Ex.: "0000.0000000123"(16) = "0000.000000012"(15) Trecho do arquivo ACBrNFSeDANFSeFRDM.pas with IdentificacaoRps do begin FieldByName('Numero').AsString := DFeUtil.FormatarNumeroDocumentoFiscalNFSe(Numero); Trecho do aquivo alterado ACBrNFSeDANFSeFRDM.dfm object cdsIdentificacaoNumero: TStringField FieldName = 'Numero' Size = 16 end Segue anexo do arquivo dfm alterado. ACBrNFSeDANFSeFRDM.dfm
×
×
  • Create New...