theiller

@Juliomar Marchetti Necessita passar os dois parametros, pois caso passe somente o Token retorna False para o fpAutenticado que faz o processo de gerar novo token. @EliasCesar O componente realmente trata o reuso do token da forma como citei no tópico, inclusive renova após a validade, porem existe alguma falha que retorna erro 500 ao tentar setar para reuso do token e validade recuperado.

Toda vez que fazia uma requisição, ocorria anteriormente uma outra requisição para obter novo token. Identifiquei que existe a possibilidade de reutilizar o mesmo token devido a expiração ser de 300 segundo (5 minutos), inclusive já existe o tratamento de renovação posterior essa data de validade, isso resulta em performance. Fiz uso dos metodos DoAntesAutenticar e DoDepoisAutenticar para interceptar o token, porem ao tentar usar o mesmo token na segunda requisição ocorre erro 400 bad request. Existe a necessidade de fazer algum outro tipo de ajuste? Esse problema já foi relatado/observado anteriormente? Talvez alguma configuração esteja ocorrendo a mais ou a menos quando se reusa o token. Vi que nos logs que o request estão iguais nas duas requisições, a que obteve pra utilizar o token e a que reutilizou o token. procedure TPSPServices.OnAntesAutenticar(var aToken: String; var aValidadeToken: TDateTime); begin aToken := FToken; aValidadeToken := FValidade; end; procedure TPSPServices.OnDepoisAutenticar(const aToken: String; const aValidadeToken: TDateTime); begin FToken := aToken; FValidade := aValidadeToken; end; Em questionamento ao suporte, foi confirmado que poderia reutilizar o token enquanto período válido, e fiz o teste utilizando o Postman que confirmou a possibilidade com retorno 200 e 401 posterior a validade. Flagship_postman_collection.zip

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

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

Desculpe, acho que encaminhei o arquivo ajustado parcialmente, segue novo. AcbrBoletoSicredIntensaoPagamentoAjuste.rar

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.

AcbrBoletoSicredIntensaoPagamento.rar

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

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