[ITAÚ - Novos códigos para protesto(81-82) CNAB400]

Bom Dia, ficou com o esperado, pode finalizar a solicitação.

Agradecemos a atenção.

[ITAÚ - Novos códigos para protesto(81-82) CNAB400]

@Alexandre de Paula, conseguiria algum retorno pra mim da situação da TK-4349 ?

[ITAÚ - Novos códigos para protesto(81-82) CNAB400]

Bom Dia...

Nas Duas últimas homologações que realizei com o banco Itaú tive a mesma Advertência, onde pedem para alterar o código enviado de protesto, mudando os atuais 34 e 35 para os novos 81 e 82.
Dados Repassados pelo banco:

 

Dados retirados do Manual:

 

Unit com a alteração:
ACBrBancoItau.pas

 

Desde já agradeço a atenão e aguardo um retorno.

[Tamanho Imagem Logo Empresa em ACBrBoletoFCFortesFr desproporcional]

Bom Dia...

Estava verificando os modelos de impressão de boleto e no dfm ACBrBoletoFCFortesFr.dfm o componente imgLogoEmpresaBoleto esta sem a propriedade Scaled marcada, fazendo com que a logo não apareça de forma correta.

Poderiam alterar isso?

 

ACBrBoletoFCFortesFr.dfm

[Códigos de retorno (92, 93, 94) não mapeados CECRED (AILOS) Cnab 240]

Bom dia,

Ok, obrigado, fiz atualização do componente e está tudo certo.

Em anexo botei a documentação que o banco nos passou.

MI - CBB - Manual CNAB 240 (1).pdf

[Códigos de retorno (92, 93, 94) não mapeados CECRED (AILOS) Cnab 240]

Boa Tarde,

No banco 085 AILOS (antigo CECRED) cnab 240, um cliente está recebendo no arquivo de retorno os códigos de ocorrências 92, 93 e 94, na qual o Acbr está retornando como "toTipoOcorrenciaNenhum" por falta de mapeamento desses códigos.

De acordo com o manual do banco páginas 37 e 38 esses códigos significam:

‘92’ = Inconsistência Negativação Serasa
‘93’ = Inclusão Negativação via Serasa
‘94’ = Exclusão Negativação Serasa

Fiz a inclusão dos códigos no mapeamento, porém, não encontrei nenhum Tipo de Ocorrência já cadastrado que faz menção a Serasa, dessa forma, utilizei uns mais genéricos:

92 - toRetornoEntradaNegativacaoRejeitada
93 - toRetornoInclusaoNegativacao
94 - toRetornoExclusaoNegativacao

Caso tenham uma sugestão diferente de Tipo de Ocorrências para esses códigos posso fazer a alteração, mas se essa alteração que fiz estiver tudo certo em anexo coloquei a Unit alterada.

Obs: Fiz o mapeamento dos códigos nas funções CodOcorrenciaToTipo, TipoOCorrenciaToCod e TipoOcorrenciaToDescricao

Obrigado.

ACBrBancoCecred.pas

[Erro 'is not a valid date and time' servidor Etherium componente ACBrNFSeX]

Concordo, realmente diferenças de formatações em retornos não faz nem sentido.

Vou entrar em contato com a prefeitura.

Obrigado!

[Erro 'is not a valid date and time' servidor Etherium componente ACBrNFSeX]

Boa tarde @Italo Giurizzato Junior

Desculpa a demora, ia mesmo comentar aqui o resultado de mais uns testes que fiz e vi sua resposta agora.

Enfim, realizando uns testes percebi que o problema ocorre apenas ao consultar a nfs-e por rps, eu havia mudado o exemplo para não fazer as consultas automaticamente no novo método de envio, pois assim eu já tinha pronto igual fazia no componente antigo e não ia precisar mudar praticamente nada no meu sistema, mas agora fiz uns testes deixando o exemplo como ele vem e ao enviar a nota pelo novo método "Emitir" e deixando o exemplo fazer a consulta automático deu certo, apenas quando tento chamar o serviço de consulta nfs-e por rps que acontece o problema acima mencionado.

Vou colocar em anexo o xml de retorno do envio com consulta automática e o de retorno da consulta de nfs-e por rps, realmente os dois xml's retornam com formatos diferentes nas datas.

Creio que vou mudar meu sistema para utilizar o Envio com consulta automática mesmo conforme o exemplo.

6685-comp-nfse.xml 75-lista-nfse-sinc.xml

[Erro 'is not a valid date and time' servidor Etherium componente ACBrNFSeX]

Bom dia,

Estou testando com o exe de exemplo do Acbr a cidade de Taubaté/SP provedor Etherium e o novo componente AcbrNfseX para posteriormente adicionar ao meu sistema esse município, porém, estou encontrando um problema descrito no título com o formato (DD/MM/YYYY) da data de emissão do xml de retorno desse município. Tag do retorno comp-nfse.xml: <DataEmissao>13/10/2022</DataEmissao>

Analisando os commits percebi que em Junho o Italo commitou novas variáveis configuráveis por provedor para tentar resolver esse problema. No caso do Etherium estavam configuradas como:

  FpFormatoDataRecebimento := tcDatUSA;
  FpFormatoDataEmissao := tcDatUSA;
  FpFormatoDataHora := tcDatUSA;

Fiz a troca dessas variáveis para o tipo tcDatVcto que utiliza formato DD/MM/YYYY.

A princípio o primeiro local que estava ocorrendo erro que era na Unit AcbrNfseXProviderABRASFv2 na função TratarRetornoConsultaNFSeporRps resolveu, porém, o mesmo erro ocorreu em outro local, nas funções LerDataEmissao e LerDataEmissaoRps:

function TNFSeR_ABRASFv2.LerDataEmissao(const ANode: TACBrXmlNode): TDateTime;
begin
  Result := ObterConteudo(ANode.Childrens.FindAnyNs('DataEmissao'), tcDatHor);
end;

Esse código acima fica na Unit ACBrNFSeXLerXml_ABRASFv2, conforme pode ser reparado, nas funções de leitura da data de emissão o componente não respeita o configurado no provedor e está usando fixo o tipo tcDatHor que tenta fazer a leitura com formato YYYY/MM/DD

Troquei manualmente esses tipos para tcdatVcto e conseguir enviar a nota, ler xml, fazer a impressão, realizar as consultas e fazer o cancelamento sem problemas.

Minha dúvida é, estou configurando algo errado já que pelo fórum percebi que algumas pessoas estão utilizando Taubaté com Etherium e nenhuma relatou esse problema?

Obs: Já utilizo diversos provedores de NFS-e com Acbr com o componente de Nfse antigo, esse é o primeiro provedor que uso o AcbrNfseX.

Agradeço a atenção.