-
Total de ítens
37 -
Registro em
-
Última visita
Últimos Visitantes
1.204 visualizações
theiller's Achievements
-
theiller started following Falha ACBrEPCBlocos StrToInd_Rec , Provedor CTAConsult - Retorno emissão RPS , ACBrBoleto - Tratamento dos campos de descontos 2 e 3 e 7 outros
-
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: NumeroNota Link CodigoVerificacao Segue exemplo do retorno xml em ambiente homologação Ajuste: Fontes\ACBrDFe\ACBrNFSeX\Provedores\CTAConsult.Provider.pas TACBrNFSeProviderCTAConsult.TratarRetornoEmitir 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
-
ACBrBoleto - Tratamento dos campos de descontos 2 e 3
theiller replied to theiller's tópico in ACBrBoleto
Correção: havia feito o ajuste fora do compilador, acabei invertendo os parâmetros da função. Segue arquivo banco santander corrigido. ACBrBancoSantander.pas -
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. ACBrBoleto.pas ACBrBancoSantander.pas
-
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. NFSe-WebISSv1-Vitoria-Conquista.zip pnfsNFSeW_ABRASFv1_Alterado.zip
-
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: Método: 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. ACBrNFSeDANFSeFR.pas
-
Sicred - Retornos 91 cnab 240, e 07 cnab 400 (Intensão de pagamento)
theiller replied to theiller's tópico in ACBrBoleto
Desculpe, acho que encaminhei o arquivo ajustado parcialmente, segue novo. AcbrBoletoSicredIntensaoPagamentoAjuste.rar -
Sicred - Retornos 91 cnab 240, e 07 cnab 400 (Intensão de pagamento)
theiller replied to theiller's tópico in ACBrBoleto
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. -
Sicred - Retornos 91 cnab 240, e 07 cnab 400 (Intensão de pagamento)
theiller replied to theiller's tópico in ACBrBoleto
AcbrBoletoSicredIntensaoPagamento.rar -
Sicred - Retornos 91 cnab 240, e 07 cnab 400 (Intensão de pagamento)
um tópico no fórum postou theiller ACBrBoleto
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. 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. pmdfeMDFeW.pas
-
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. pnfsNFSeR.pas
- 2 replies
-
- 1
-
- nfse
- valorissretido
-
(e 2 mais)
Tags:
-
Sicoob Header240 DigitoVerificadorAgenciaConta em "branco/espaço"
um tópico no fórum postou theiller ACBrBoleto
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;