Cleonir

No xml de retorno da consulta não vem. Vem somente a mensagem "(0) OPERACAO EFETUADA - SITUACAO DO TITULO = TITULO JA PAGO NO DIA" e os dados do Titulo que foi registrado. Mas não vem os dados do pagamento. Pelo menos neste teste que fiz, foi pago no mesmo dia da emissão. Mas acredito que se for pago num dia após a emissão irá vir da mesma forma, por que no manual esta assim. Isso é um problema por que não tem como saber certo que dia foi pago. Em anexo XML da Consulta. 165-2-retorno_registro.xml

Bom dia. Agora esta ok. Obrigado.

Opa. Foi mal. Dei uma pesquisada mas não encontrei nada.

Bom dia. Eu acho que com as alterações feitas para ajustar as logos. acabou dando problema no Layout com comprovante de entrega. A ultima guia esta indo para a segunda pagina. Não vou postar aqui o arquivo modificado por que tenho outras alterações referente ao Boleto Carne, em que infelizmente não foi aceito mas preciso manter para meu cliente.

Uma duvida. Não tem como pegar a data do pagamento na consulta no caso de liquidação ?

Boa tarde. Tive o mesmo problema. Com a solução do serginhoott resolveu a questão do HASH. Tive outro problema com o JUROS_MORA. Se CodigoMoraJuros = cjIsento não deve ser criado a tag DATA.

É pego a assinatura do Pagador.

O objetivo é para um canhoto ficar com o beneficiário retirado antes de entregar o carne para o pagador para controle interno, e o outro fica no carne que vai para o pagador. Seria mais ou menos a mesma lógica do Padrão Entrega, mas no formato de carne.

Bom dia. Em anexo PDF de exemplo. BOLETO.pdf

Segundo a nota técnica,  Publicação dessa NT, que estrutura o MDF-e de forma a possibilitar, entre outros benefícios: * Geração automática do CIOT, pelo Sistema MDF-e, tanto para as modalidades TACIndependente como TAC-Agregado;

Boa tarde. Esse infPag é informações dos pagamentos para os proprietários dos veículos de terceiros ? Nota Técnica: "Geração de informações para facilitar a negociação de direitos de recebimentos de fretes, por parte do TAC(Transportadores Autônomos de Cargas), junto a instituição financeira onde possui conta corrente, sem a interferência de atravessadores". Ou é referente aos pagamentos de que contratou o Frete, Remetente ou Destinatário do CTe no caso ? Não entendi direito isso.

Isso. Se desejarem alterarem o nome tranquilo. Não me veio um nome correto quando eu estava fazendo.

Um cliente meu solicitou um novo layout do Carne. Com recibo do pagador no lado esquerdo. Criei o lCarneReciboBeneficiario. Eu acho que isso que é interessante ter essa opção. Usei o mesmo do Carne já existente, quando informado o lCarneReciboBeneficiario alterará o Orientation para poLandscape e deixará visível o recibo do Beneficiário. Favor analisarem e se possível postarem no SVN. Só implementei no FortesReport, não trabalho com o FastReport. Em anexo arquivos alterados. ACBrBoletoFCFortesFr.dfm ACBrBoletoFCFortesFr.pas ACBrBoletoConversao.pas

Boa tarde. Finalmente consegui finalizar a homologação do UNICREDI CNAB 240 em anexo arquivo ajustado. Favor analisarem e postarem no SVN se possível. ACBrBancoUnicredRS.pas

Agora esta ok. Obrigado.

Bom dia. Para testar no demo, no componente ACBrBoleto que esta no dmForte configurar da seguinte forma, nas configurações do Banco o TipoCobrança selecionar cobBradesco, e no LayoutRemessa selecionar c240. só isso já irá reproduzir o problema quando gerar a remessa. Referente aos testes unitários, não testei, não sei direito como funciona. Vou ter que tirar um tempo para ver como funciona os testes unitários.

Boa tarde. Na Remessa do Bradesco CNAB 240 esta ficando com quantidade de caracteres por linha menor que 240, conferindo percebi que tem um trim no result da function TACBrBancoClass.GerarRegistroHeader240 ( NumeroRemessa: Integer ) : String; esta assim: Result:= Trim(ListHeader.Text); É muito provável que seja esse o problema. mas tem mais locais que esta assim. Fiz um teste aqui retirando esse trim do result do RegistroHeader e gerou com os 240 caracteres, mas ele adicionou uma quebra de linha a mais, não sei qual seria a melhor forma de resolver isso.

Bom dia. Também tive essa rejeição do "Cliente sem saldo" quando eu estava testando. Provavelmente você emitiu o CIOT com o tipo de pagamento eFRETE. Para esse tipo de pagamento o emitente no caso a transportadora deve conter saldo lá na eFRETE, por que no caso será a eFRETE que irá realizar os pagamentos.

Beleza. Agora esta ok. Obrigado...

Boa tarde Italo Jurisato Junior. Atualizei hoje e testei. Esta ok agora. Obrigado...

Boa Tarde. Hoje a eFrete me deu um Retorno. [09/04/2020 09:22:16] Suporte e-FRETE: Bom dia, quando você consulta o método (ConsultarTipoCarga) em ambiente de homologação nós encaminhamos esta requisição ao ambiente de homologação da ANTT e repassamos o resultado ao requisitante. O mesmo ocorre em produção, porém, a ANTT não possui a lista ainda, neste caso é retornado uma lista com apenas uma opção, e é esta opção que deve ser utilizada até que a ANTT passe a utilizar o campo, que a princípio ainda não existe previsão. Esta retornando isso: "0 - 1" que no caso o código é o zero. Adicionei o tpNaoAplicavel no final, o correto seria no inicio mas não sei se talvez não vai interferir em alguma outro coisa. Em anexo arquivos alterados. pcnCIOTW_eFrete.pas pcnConversaoCIOT.pas

Para resolver esse problema do CodigoTipoCarga, tive que criar um enumerado tpNaoAplicavel para o tpTipoCarga, quando for esse tpNaoAplicavel joguei o numero zero, por que na consulta dos tipos de carga só retornou o "0 - 1" que no caso o código é o zero. Só assim consegui enviar o CIOT. Criando a tag sem valor como a eFrete tinha solicitado também deu erro.

Consegui descobrir o problema da Viagem Padrão, testando com o SoapUi. O problema esta nos pagamentos, esta gerando de forma errada o xml. ajustes na procedure GerarPagamentos. em anexo arquivo alterado. pcnCIOTW_eFrete.pas

Boa tarde Italo. Para o Tipo de Viagem Padrão deve ser gerado a tag mas sem valor. Só criado a tag.

Boa noite Italo. Resolveu para o caso acima. Mas Continua o problema em produção. Que segundo a eFrete deve ser null para Tipo Viagem Padrão. Talvez adicionar um enumerado tpNull, resolveria. Mas eu ainda não consegui testar mandando null, por que agora estou com outro problema esta dando erro 400 para Tipo Viagem Padrão.