Jump to content
Notícias do ACBr

click.png

click.png

click.png

click.png

click.png

click.png

clube mobile


Cursos grátis para toda base ACBr
+ Promoção Clube Mobile para o ACBr Pro

Saiba mais

adriano santos

click.png

click.png

click.png

click.png

click.png

click.png

Júlio Cesar de Campos

Membros
  • Content Count

    20
  • Joined

  • Last visited

Community Reputation

1 Neutral

About Júlio Cesar de Campos

  • Rank
    Novato

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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.
  4. 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)
  5. 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; begi
  6. 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;
  7. 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?
  8. 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.
  9. 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.
  10. 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.
  11. 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 q
  12. 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.
  13. 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
  14. 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 d
  15. 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.
×
×
  • Create New...