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.

Obrigado Sergio, este é exatamente o mesmo processo que utilizamos, mas ele não permite descobrir pendencias de transmissão no intervalo ou o que pode ser feito com os cupons que estão com pendencia de transmissão. E não utilizamos a data de envio, pois isso pode não expressar a realidade quanto ao envio dos lotes pendentes, pois a ultima transmissão pode ser de hoje e o ultimo cupom represado ainda ser de 5 dias atrás, pois o tempo de conexão não foi suficiente para transmitir todos os dados

Bom dia. Nosso sistema, avisa o cliente que existem pendencias de transmissão de CF-e-SATs no aparelho SAT. Colocamos esse aviso, para identificar possíveis problemas de internet, assim, se o SAT estiver sem internet por X dias e o cliente não tiver ciencia disto, o sistema dará o alerta para que o cliente providencie a transmissão dos CF-es. Para tal, nós realizamos uma consulta ao sat, na abertura do sistema, e perguntamos qual o primeiro CF-e-SAT represado no aparelho, consultamos em nossa base a data de emissão deste CF-e e avisamos se deu mais de X dias. Pensávamos em talvez utilizar a data da última transmissão, mas ela não significa que todos os CF-es de 5 dias atrás foram transmitidos. Pode acontecer da última transmissão ser de hoje, mas só deu tempo de transmitir alguns dos CF-es antes de ocorrer nova interrupção na internet. Mas nos deparamos com um problema neste processo. Segundo a documentação da receita, o CF-e deve ser mantido como pendente no SAT enquanto não houve um retorno que foi processado, sendo assim, existem CF-es no intervalo que ainda não foram processados e estão sendo mantidos como pendentes, porém já foram enviados para a receita e não há o que fazer com eles(que eu tenha ciência). Exemplo: 1 - ok 2 - ok 3 - ok 4 - pendente 5 - ok 6 - ok 7 - pendente Se eu questionar o SAT ele vai me informar Ultimo CF-e transmitido 6 Primeiro pendente 4 Ultimo pendente 7 Nosso problema esta em, se houver passado dos 12 dias, não há mais o que fazer com esse CF-e, então iriamos deixar de avisar dele, mas não sabemos se existem outros CF-es pendentes no intervalo, somente sabemos o primeiro e o ultimo. Existe alguma forma de descobrirmos se existem mais cupons pendentes no intervalo? Alguem já passou por situação semelhante e conhece algo que possa ser feito com esse cupom 4 que foi pulado? Tentamos enviar em contingencia e ele não foi acolhido novamente.

O motivo eu não entendi. Tenho ainda um aplicativo compilado na versão anterior, ele ainda está rodando e ainda está enviando e-mails. Ele esta configurado para a porta 587 na Locaweb. Se eu atualizar, este aplicativo para de enviar os e-mails. Trocando a porta para 465, como você fez, ele volta a funcionar. Não precisei mexer na dll mesmo, mas a porta 587 não conseguiu enviar o e-mail na versão nova. Grato pelo seu exemplo. Ainda não testei no Gmail e no Hotmail novamente, mas se o e-mail voltou a ir, agora eu troco as portas na atualização para testar.

Boa tarde Juliomar. Testei com as dlls contidas nas seguintes pastas do SVN: \Acbr\ACBrFramework\Dll\x64 \Acbr\ACBrFramework\Dll\x86 \Acbr\branches\DLLs\Win32\OpenSSL \Acbr\branches\DLLs\Win64\OpenSSL \Acbr\tags\ACBrTrunk2015\DLLs\OpenSSL \Acbr\tags\ACBrTrunk2015\DLLs\OpenSSL\0.9.8.1 \Acbr\trunk2\DLLs\OpenSSL\0.9.8.1 \Acbr\trunk2\DLLs\OpenSSL\0.9.8.14 \Acbr\trunk2\DLLs\XMLSec\MinGW\32 \Acbr\trunk2\DLLs\XMLSec\MinGW\64 \Acbr\trunk2\Lib\Delphi\LibD7 \Acbr\trunk2\Lib\Delphi\LibD7\MinGW\32 \Acbr\trunk2\Lib\Delphi\LibD7\MinGW\64 Em todas essas pastas existiam a ssleay32 e libeay32 e foram testadas em par, ou seja, sempre colocando as duas DLLs da mesma pasta. Antes dos testes eu apaguei as mesmas da pasta do system e do delphi. Elas foram colocadas na pasta da minha aplicação(.exe). Mesmo retorno para todas as versões da DLL. Na versão anterior do ACBr ainda vai com as configurações que estão, testadas no Hotmail, Gmail e Locaweb.

Bom dia. Estou com o mesmo problema após ter atualizado o SVN Tentei com as ssleay32 e libeay32 existentes nas pastas: MinGW32 OpenSSL E outras que identifiquei com alteração de tamanho. Coloquei-as na pasta de meu executável, como já ocorria. Com a versão anterior vai, sem problemas. Testei com GMAIL, HOTMAIL e Locaweb. O exemplo da ACBr também não vai. Temos alguma possibilidade de testes ou procedimento que eu deva fazer?