theiller
-
Total de ítens
37 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por theiller
-
-
Correção: havia feito o ajuste fora do compilador, acabei invertendo os parâmetros da função.
Segue arquivo banco santander corrigido.
-
Identifiquei que na maioria dos bancos os campos de descontos 2 e 3 não estão sendo tratados da forma que é tratado os campos de descontos "1".
Na classe TACBrBancoClass possui duas funções que podem ser implementadas e tratam o desconto "1" mas não existem algo parecido para os campos de descontos 2 e 3.
function DefineCodigoDesconto(const ACBrTitulo: TACBrTitulo): String; virtual; function DefineDataDesconto(const ACBrTitulo: TACBrTitulo; AFormat: String = 'ddmmyyyy'): String; virtual;
Minha sugestão é também ter a mesma funcionalidade para os demais campos, facilitando e permitindo popular corretamente os registros de forma simples e reuso do código, ainda manda a função anterior já como deprecated.
function DefineCodigoDesconto(const ACBrTitulo: TACBrTitulo): String; virtual; deprecated 'Moved to the AnsiStrings unit'; //Utilizando para definir Código de Desconto na Remessa function DefineCodigoDescontoId(const ATipo: TACBrTipoDesconto; const AValor: Currency): String; virtual; //Utilizando para definir Código de Desconto na Remessa function DefineDataDesconto(const ACBrTitulo: TACBrTitulo; AFormat: String = 'ddmmyyyy'): String; virtual; deprecated 'Moved to the AnsiStrings unit'; //Utilizado para definir a Data de Desconto na Remessa function DefineDataDescontoId(const AData: TDateTime; const AValor: Currency; const AFormat: String = 'ddmmyyyy'): String; virtual; //Utilizado para definir a Data de Desconto na Remessa //... function TACBrBancoClass.DefineCodigoDesconto(const ACBrTitulo: TACBrTitulo): String; begin with ACBrTitulo do begin Result := DefineCodigoDescontoId(TipoDesconto, ValorDesconto); end; end; function TACBrBancoClass.DefineCodigoDescontoId( const ATipo: TACBrTipoDesconto; const AValor: Currency): String; begin if (AValor > 0) then begin case ATipo of tdValorFixoAteDataInformada : Result := '1'; tdPercentualAteDataInformada: Result := '2'; else Result := '1'; end; end else Result := '0'; end; function TACBrBancoClass.DefineDataDesconto(const ACBrTitulo: TACBrTitulo; AFormat: String): String; begin with ACBrTitulo do begin DefineDataDescontoId(DataDesconto, ValorDesconto, AFormat); end; end; function TACBrBancoClass.DefineDataDescontoId(const AData: TDateTime; const AValor: Currency; const AFormat: String): String; begin if (AValor > 0) then begin if (AData > 0) then Result := FormatDateTime(AFormat, AData) else Result := PadRight('', Length(AFormat), '0'); end else Result := PadRight('', Length(AFormat), '0'); end;
Assim simplifica o ajuste nas classes dos bancos, mantendo a mesma lógica do código:
Segue código com o ajuste.
-
Eu desde sempre utilizo: TACBrNFSe = class(TACBrDFe), mudou algo? ta no exemplo? vou conferir.
-
A cidade Vitoria da conquista-BA utiliza o provedor WebISS v1, ao tentar emitir uma NFSe recebi o retorno que a aliquota não era correspondente.
Fiz a verificação dos dados da versão do provedor WebISS, código do serviço, alíquota e valores...
Ao compararmos com um XML enviado diretamente pelo site da prefeitura na plataforma webiss, identificamos que a falha está na geração do XML de envio, que requer que a alíquota já esteja dividida pelo percentual (2.10 / 100 = 0.021).
Na análise do arquivo pnfsNFSeW_ABRASFv1.pas existe essa tipo de tratamento, porem para o webiss esta sendo passado o percentual direto ao invés de dividir por 100, como ja existe a regra para outros provedores.
Imagino que os desenvolvedores da região estejam preenchendo o objeto do acbr passando o valor já dividido, quando o correto deveria ser tratado pelo componente.
Então fiz um ajuste para considerar a possibilidade de passarem o valor já dividido ou o percentual, para evitar o erro pós atualização caso outros projetos estejam tratando isso diretamente no código de cada projeto:
//Retrocompatibilidade, se alguem estiver passando o valor da aliquota já dividida por 100 proWebISS: if (NFSe.Servico.Valores.Aliquota > 0) and (NFSe.Servico.Valores.Aliquota < 0.1) then Gerador.wCampo(tcDe4, '#25', 'Aliquota', 01, 05, 1, NFSe.Servico.Valores.Aliquota, DSC_VALIQ) else Gerador.wCampo(tcDe4, '#25', 'Aliquota', 01, 05, 1, (NFSe.Servico.Valores.Aliquota / 100), DSC_VALIQ);
Segue anexo do xml emitido pela própria plataforma assim como o arquivo fonte alterado.
-
Na NFSe e possível fazer a emissão informando o município de prestação e/ou incidência, em que podem ser diferentes, porem na impressão esta sendo impresso o nome da cidade de prestação em ambos.
Verfiquei com o XML esta correto e o arquivo de impressão também.
A falha foi identificada em:
Arquivo:
CitarFontes\ACBrDFe\ACBrNFSe\DANFSE\Fast\ACBrNFSeDANFSeFR.pas
Método:
CitarTACBrNFSeDANFSeFR.CarregaParametros
Atual:
FieldByName('MunicipioIncidencia').AsString := CodCidadeToCidade(StrToIntDef(CodigoMunicipio, 0)); // Antes:
Correção:
FieldByName('MunicipioIncidencia').AsString := CodCidadeToCidade(IfThen(MunicipioIncidencia > 0, MunicipioIncidencia, StrToIntDef(CodigoMunicipio, 0)));
Segue em anexo arquivo para análise e correção em repositório.
-
Desculpe, acho que encaminhei o arquivo ajustado parcialmente, segue novo.
-
Necessidade identificada devido essa ocorrência também carregar o valor recebido, embora não tenha a data de crédito.
Ao fazer a conciliação ocorreram conflitos de validações.
-
-
Atualização CNAB 240 e 400 banco sicred: Intenção de pagamento
Segue em anexo, manuais e ajustes dos fontes para atualização do SVN.
Criei mais um TACBrTipoOcorrencia: toRetornoIntensaoPagamento
ACBrBancoSicredi - TACBrBancoSicredi.CodMotivoRejeicaoToDescricao - ACBrBanco.ACBrBoleto.LayoutRemessa: 400
toRetornoIntensaoPagamento: case AnsiIndexStr(CodMotivo, ['00','H5']) of 0 : Result:= '00-Devolução de Comunicado pelos Correios'; 1 : Result:= 'H5-Recebimento de liquidação fora da rede Sicredi – VLB Inferior – Via Compensação '; else Result:= PadLeft(CodMotivo,2,'0') +' - Outros Motivos'; end;
ACBrBancoSicredi - TACBrBancoSicredi.TipoOcorrenciaToDescricao - ACBrBanco.ACBrBoleto.LayoutRemessa = c240
91: Result := '07-Intenção de pagamento';
ACBrBancoSicredi - TACBrBancoSicredi.TipoOcorrenciaToDescricao - ACBrBanco.ACBrBoleto.LayoutRemessa = c400
07: Result := '07-Intenção de pagamento';
ACBrBancoSicredi - TACBrBancoSicredi.CodOcorrenciaToTipo - ACBrBanco.ACBrBoleto.LayoutRemessa = c240
ACBrBancoSicredi - TACBrBancoSicredi.CodOcorrenciaToTipo - ACBrBanco.ACBrBoleto.LayoutRemessa = c400
ACBrBancoSicredi - TACBrBancoSicredi.TipoOCorrenciaToCod - ACBrBanco.ACBrBoleto.LayoutRemessa = c240
ACBrBancoSicredi - TACBrBancoSicredi.TipoOCorrenciaToCod - ACBrBanco.ACBrBoleto.LayoutRemessa = c400 -
Olá, tive problema ao tentar emitir MDFe:
SegCodBarra(Segundo código de barras) - Tamanho menor que o mínimo permitido
Esse campo deve ser preenchido quando o Documento NFe/CTe foi emitida em contingência (tpEmis in [2,5]
- FS-DA - Formulário de Segurança para Impressão de Documento Auxiliar
- FS-IA - Formulário de Segurança Impressor Autônomo
Acreditava que essa validação deveria estar nos Schemas, porem fiz a atualização dos arquivos e não resolveu.
Após depurar identifiquei que o problema encontra-se na geração do XML (ACBrDFe\ACBrMDFe\PCNMDFe\pmdfeMDFeW.pas), em que TGerador.wCampo esta sendo passado uma constante de validação tamanho min e max discrepante (44) ao manual MDFe (36), tanto para NFe quando para CTe.
CitarGerador.wCampo(tcStr, '#050', 'SegCodBarra', 44, 44, 0, MDFe.infDoc.infMunDescarga[i].infCTe[j].SegCodBarra, DSC_SEGCODBARRA);
...
Gerador.wCampo(tcStr, '#059', 'SegCodBarra', 44, 44, 0, MDFe.infDoc.infMunDescarga[i].infNFe[j].SegCodBarra, DSC_SEGCODBARRA);
Fiz o ajuste no arquivo, comentei as linhas e reescrevi abaixo com o tamanho correto. O documento MDFe foi autorizado.
Segue em anexo unit corrigida para atualização do code git.
-
1
-
O provedor de NFSe Saatri não possui a tag do ValorrIssRetido, controlando esse definição por outras tags, alem de ser necessário manter o valo do ISS populado, devido a isso, quando faz a consulta do RPS ou carga pelo XML, o valor do iss retido não fica preenchido, e apresenta o valor liquido errado.
Segue em anexo o ajuste necessário.
-
1
-
-
Olá, para o Sicoob no processo de homologação, existe uma área para validação do arquivo remessa:
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
-
Ajustado devido regime caixa, necessário de popular bloco F525.
Segue unit em anexo.
-
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; -
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:
-
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:
-
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!
-
1
-
-
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.
-
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.
-
Tive problemas com o modelo FastReport, o pessoal do ACBr ainda não fez a correção:
Provedor CTAConsult - Retorno emissão RPS
em ACBrNFSe
Postado · Editado por theiller
Algumas palavras incompletas
O provedor CTAConsult não retorna o "xml da nota fiscal autorizada", e sim um "xml do protocolo da autorização", foi identificado que existem algumas tags que não estão sendo carregadas, embora existam no xml e no classe de retorno:
Segue exemplo do retorno xml em ambiente homologação
Ajuste:
Response.Protocolo := ObterConteudoTag(ANode.Childrens.FindAnyNs('protocolo'), tcStr); Response.Situacao := ObterConteudoTag(ANode.Childrens.FindAnyNs('codigoStatus'), tcStr); Response.NumeroNota := ObterConteudoTag(ANode.Childrens.FindAnyNs('numeroNota'), tcStr); Response.Link := ObterConteudoTag(ANode.Childrens.FindAnyNs('linkPdfNota'), tcStr); Response.CodigoVerificacao := ObterConteudoTag(ANode.Childrens.FindAnyNs('chaveSeguranca'), tcStr);Segue em anexo o fonte atualizado.
CTAConsult.Provider.pas