Júlio Cesar de Campos

Fiz da forma que o Italo falou. Só movi todos os componentes para baixo e depois para cima novamente. E a tarja de Encerramento e Cancelamento saiu em ambiente de produção. achei que seria igual à NF-e e CT-e que aparece uma tarja vermelha no código de barras. Obrigado a todos. Não gostaria de mexer nos fontes de vocês para me manter em dia com as atualizações, mas foi a saída mesmo.

Bom dia Felipe. Muito obrigado pelo contato. Talvez funcionasse, porém agora não está imprimindo mais nada do MDF-e com o erro Error reading RLMDFe.ExplicitLeft: Property ExplicitLeft does not exist. Então não consegui testar se em ambiente de produção funcionária.

Boa tarde. Passei o dia tentando atualizar o fortes e o SVN. Alguma coisa eu estava fazendo em ordem incorreta. Agora, depois de realizar uma instalação praticamente limpa, com o SVN mais recente e o Fortes igualmente, a mesagem de Error reading RLMDFe.ExplicitLeft: Property ExplicitLeft does not exist permanece. Não sei o quanto ajuda mas: A NF-e e CT-e não apresentam este erro. O MDF-e estava imprimindo corretamente até eu decidir atualizar o SVN(quinta feira). Agora não imprime o DaMDF-e e nem o evento do MDF-e gerando o erro acima.

Vou proceder com o procedimento com o fortes. E sobre o evento, realmente, mas parece ser exatamente o erro. Eu carrego o xml do evento cancelamento e o evento impresso é uma carta de correção com número de evento -99999 e em ambiente de produção. Depurei está linha(Result := RetEventoMDFe.LerXml; ) e os dados estão sendo lidos corretamente do xml( Cancelamento, número do evento, tipo homologação). Porém, nas linhas abaixo, os dados extraídos do RetEventoMDFe.InfEvento estão vazios(ID vazia, ambiente produção, etc)

Sei que vocês são ocupados e pedem o prazo de 24 horas. Porém, obviamente que fiquei tentando resolver por mim mesmo neste período. Imaginando se tratar de falta de atualização dos fontes da ACBR, decidi atualizar. Agora, em outro lugar, está dando essa mensagem quando tento gerar o danfe Error reading RLMDFe.ExplicitLeft: Property ExplicitLeft does not exist e o erro anterior, acontecia com o componente no seguinte lugar: pmdfeEnvEventoMDFe function TEventoMDFe.LerXMLFromString(const AXML: String): Boolean; var RetEventoMDFe: TRetEventoMDFe; begin RetEventoMDFe := TRetEventoMDFe.Create; try RetEventoMDFe.Leitor.Arquivo := AXML; Result := RetEventoMDFe.LerXml; { Essa função lê corretamente os valores do XML} with FEvento.Add do begin infEvento.Id := RetEventoMDFe.InfEvento.Id; { todos os valores deste objeto estão em branco e passam os dados em branco. InfEvento.cOrgao := RetEventoMDFe.InfEvento.cOrgao; infEvento.tpAmb := RetEventoMDFe.InfEvento.tpAmb; infEvento.CNPJCPF := RetEventoMDFe.InfEvento.CNPJCPF; infEvento.chMDFe := RetEventoMDFe.InfEvento.chMDFe; infEvento.dhEvento := RetEventoMDFe.InfEvento.dhEvento; infEvento.tpEvento := RetEventoMDFe.InfEvento.tpEvento; infEvento.nSeqEvento := RetEventoMDFe.InfEvento.nSeqEvento; infEvento.VersaoEvento := RetEventoMDFe.InfEvento.VersaoEvento; infEvento.detEvento.descEvento := RetEventoMDFe.InfEvento.detEvento.descEvento; infEvento.detEvento.nProt := RetEventoMDFe.InfEvento.detEvento.nProt; infEvento.detEvento.dtEnc := RetEventoMDFe.InfEvento.detEvento.dtEnc; infEvento.detEvento.cUF := RetEventoMDFe.InfEvento.detEvento.cUF; infEvento.detEvento.cMun := RetEventoMDFe.InfEvento.detEvento.cMun; infEvento.detEvento.xJust := RetEventoMDFe.InfEvento.detEvento.xJust; infEvento.detEvento.xNome := RetEventoMDFe.InfEvento.detEvento.xNome; infEvento.detEvento.CPF := RetEventoMDFe.InfEvento.detEvento.CPF; signature.URI := RetEventoMDFe.signature.URI; signature.DigestValue := RetEventoMDFe.signature.DigestValue; signature.SignatureValue := RetEventoMDFe.signature.SignatureValue; signature.X509Certificate := RetEventoMDFe.signature.X509Certificate; if RetEventoMDFe.retEvento.Count > 0 then begin FRetInfEvento.Id := RetEventoMDFe.retEvento.Items[0].RetInfEvento.Id; FRetInfEvento.tpAmb := RetEventoMDFe.retEvento.Items[0].RetInfEvento.tpAmb; FRetInfEvento.verAplic := RetEventoMDFe.retEvento.Items[0].RetInfEvento.verAplic; FRetInfEvento.cOrgao := RetEventoMDFe.retEvento.Items[0].RetInfEvento.cOrgao; FRetInfEvento.cStat := RetEventoMDFe.retEvento.Items[0].RetInfEvento.cStat; FRetInfEvento.xMotivo := RetEventoMDFe.retEvento.Items[0].RetInfEvento.xMotivo; FRetInfEvento.chMDFe := RetEventoMDFe.retEvento.Items[0].RetInfEvento.chMDFe; FRetInfEvento.tpEvento := RetEventoMDFe.retEvento.Items[0].RetInfEvento.tpEvento; FRetInfEvento.xEvento := RetEventoMDFe.retEvento.Items[0].RetInfEvento.xEvento; FRetInfEvento.nSeqEvento := RetEventoMDFe.retEvento.Items[0].RetInfEvento.nSeqEvento; FRetInfEvento.CNPJDest := RetEventoMDFe.retEvento.Items[0].RetInfEvento.CNPJDest; FRetInfEvento.emailDest := RetEventoMDFe.retEvento.Items[0].RetInfEvento.emailDest; FRetInfEvento.dhRegEvento := RetEventoMDFe.retEvento.Items[0].RetInfEvento.dhRegEvento; FRetInfEvento.nProt := RetEventoMDFe.retEvento.Items[0].RetInfEvento.nProt; FRetInfEvento.XML := RetEventoMDFe.retEvento.Items[0].RetInfEvento.XML; end; end; finally RetEventoMDFe.Free; end; end; Estou tentando corrigir ambos aqui.

Milhões de desculpas pela incompetência, mas não encontrei no fórum outra pessoa com o mesmo problema. Emiti um MDF-e e cancelei-o com sucesso. Agora quero imprimí-lo com a tarja de cancelamento(que estou supondo existir, visto que para o CT-e e NF-e vocês desenvolveram e li outras postagens de pessoas que não conseguiam tirar a tarja). Meu procedimento padrão(para CT-e e NF-e sempre foi o seguinte: ACBrMDFe1.Manifestos.LoadFromString(XML);//XML autorizado if cProtocoloCanc<>'' Then Begin ACBrMDFe1.DAMDFE.ProtocoloMDFE := cProtocoloCanc; ACBrMDFe1.DAMDFE.MDFeCancelada := True; End; ACBrMDFe1.Manifestos.Items[0].Imprimir; Porém no MDF-e a tarja de cancelamento não apareceu. Encontrei outra pessoa no forum falando sobre esse assunto e ela importava não só o XML autorizado, mas também o XML do evento. Então tentei o seguinte: ACBrMDFe1.Manifestos.LoadFromString(XML); if cProtocoloCanc<>'' Then Begin ACBrMDFe1.EventoMDFe.LerXMLFromString(XMLEvento); ACBrMDFe1.DAMDFE.ProtocoloMDFE := cProtocoloCanc; ACBrMDFe1.DAMDFE.MDFeCancelada := True; End; ACBrMDFe1.ImprimirEvento; O Items[0].imprimir, continua imprimindo o MDF-e sem tarja. o ImprimirEvento, imprime um documento com o título de carta de correção. Devo estar errando em alguma coisa muito básica pois todos os demais procedimentos foram simples de serem realizados. Estou em ambiente de homologação e utilizo o Fortes. Desde já agradeço.

Bom dia. Dois clientes meus começaram a dar este problema. Antes não utilizávamos ACBr e estamos adotando a ferramenta em todos os nossos clientes progressivamente. Dois clientes apresentaram o problema do provider=24. Um deles, troquei o ACBRSSLTYPE de LT_all para LT_TLSv1_2 e resolveu(pode ser o inverso que fiz, não lembro pois faz mais de um mês que resolvemos). Um segundo cliente surgiu agora. Nossa equipe de suporte disse que tentou isso(eu ainda vou fazer mais testes), mas tem algo que resolva definitivamente?

Bom dia @Felipe E. Resende Mesquita Estamos aguardando, mas estamos às cegas. O ambiente de homologação deveria ter implementado isso desde o dia 02/05 e ainda não está disponível. Amanhã (16/05/2018) será a data prevista de implementação em ambiente de produção, mas se nem em ambiente de homologação foi disponibilizado, não sabemos para quando podemos desenvolver para o cliente. Eu mesmo, consigo tirar NF-es em ambiente de homologação, mas não em produção. Vou ter que disponibilizar para o cliente, sem saber se realmente está disponível para ele.

Mesma situação aqui. Não estou conseguindo enviar o IndPag em SP. Nem a remoção da validação da duplicata mercantil quando informadas parcelas.

Só para constar, em um dos clientes, os cupons estavam para processamento desde o dia 12/11/17. Hoje, dia 08/12/2017, quase um mês após a emissão, eles foram aceitos pela receita e o SAT apagou a luz de cupons pendentes.

Bom dia Fabio. Eu acreditei que essa também seria a melhor opção, mas me deparei com vários problemas que eu acredito serem originados da receita, não da ACBR: Se o cliente envia muitos lotes para a receita e eu realizo uma consulta dos últimos 10 dias, ao invés de receber todos os lotes enviados nesses 10 dias, eu recebo alguns lotes de cada dia, tendo que realizar vários filtros no mesmo período para garantir que todos os lotes foram consultados. Com certa frequência, a receita dá erro de transmissão e não retorna nada(depende do dia, essa semana está ótima), e para garantir que a consulta é realizada com sucesso, tive que implementar loop de pelo menos 3 vezes. Há falta de ordenação no retorno da receita, é contornável mas eu perdi a confiança para descobrir um lote especifico. Utilizo a função para descobrir tempo sem transmissão e estamos implementado aos poucos nos clientes. Por enquanto considerei ser a melhor opção, mas para ver se o sat está consultando, não para descobrir se há pendencias nele.

Bom dia. Problema da receita, acontece igual a imagem. Enquanto a receita não processa esse lote, que já foi transmitido pelo sat, o sat mantem a luz acesa pois é o que está descrito para o SAT fazer no manual do fabricante.

Concordo, o Led é a mais confiável e já fica na mão do verdadeiro responsável (O cliente). Estamos querendo alertar somente para auxilia-los e esses clientes com exceções, que tem um lote parado para processamento, o Led nunca apaga, embora os CF-es estejam correto

Bom dia Rodrigo consegui verificar sim Um cliente estava com vários cupons pendentes, de vários dias quando corrigimos a internet do SAT, ele começou a transmitir A data da ultima transmissão foi atualizada para "agora", porém ele havia enviado somente um lote de CF-es. O CFe inicial também foi atualizado, pois ele não tinha problemas mas ficou assim: Data da ultima transmissão: Agora CF-e Inicial: Um cupom de 4 dias atrás CF-e Final: Igual ao ultimo emitido(pensa numa informação inutil) Se nesse momento a internet houvesse caído nesse momento, a data da ultima transmissão seria inutil. Porém em alguns minutos todos foram enviados. Outra forma de resolver meu problema, seria se o último CF-e emitido fosse na verdade o ultimo Cf-e transmitido. Aí seria uma informação util e eu poderia saber em que dia parou a transmissão baseado nesse dado.

E se DH_Ultima for menor que 5 dias e Lista_Final for de hoje, isso não significa que não exista pendencia a mais de 5 dias. E não tem como eu fazer uma comparação com o controle do sistema, pois o sistema não consegue retorno de quais cupons no intervalo foram transmitidos. Essa informação fica somente com o SAT e ele não disponibiliza para o AC.