IBS Sistemas

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

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

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.

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

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

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

Concordo, realmente diferenças de formatações em retornos não faz nem sentido. Vou entrar em contato com a prefeitura. Obrigado!

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

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.