Ir para conteúdo
  • Cadastre-se

Mega Online

Membros Pro
  • Total de ítens

    463
  • Registro em

  • Última visita

Tudo que Mega Online postou

  1. Também estou com o mesmo problema. Estou orientando aguardar até a tarde para ver se volta.
  2. Boa Tarde, Existe algum limite para a quantidade de impressão dos componentes do valor da prestação no CTe? No manual do CTe esta informado que pode ser adicionados "n" componentes do valor da prestação. No Manual esta assim: " 211 Comp 2 Componentes do Valor da Prestação G 0 - n " Mas um cliente adicionou 20 componentes e na impressão saiu somente 12. Tem algo a configurar ou o limite no ACBrNFeMonitor e 12 mesmo? Obrigado!
  3. Também estou com o mesmo problema, ai aguardo uma hora depois volta a funcionar, aguém tem alguma solução? pq imagina um dos meus casos de um cliente que o MaxNSU dele é 11900 até chegar neste número, impossível, sendo que no máximo 5, 6 consultas consecutivas já retorna consumo indevido. Alguém já testou o seguinte caso: quando der consumo indevido, consultar usando o NSU específico de 1 em 1 até chegar no último NSU? usando o último parâmetro da função (apenas uma idéia)
  4. Boa Tarde, Como ficou a questão do ENCERRAMENTO pelo ACBrNFeMonitor? Obrigado!!
  5. Em fevereiro entrará em vigor o novo WebService NFeDistribuicaoDFe que substituirá o antigo NfeConsultaDest, já utilizo o componente do ACBr que está funcionando 100% com o NfeConsultaDest, o que devo fazer para o meu sistema entender este novo WebService NFeDistribuicaoDFe, tenho que mudar alguma configuração no componente, já baixei a atualização dos fontes pelo SVN.
  6. Boa tarde, Pessoal, qual o link para eu baixar a ultima versao do ACBrMonitor para NFC-e? No aguardo.
  7. Boa Tarde, Existe uma previsão de disponibilizar o ACBrNfeMonitor com MDF-e compilado? Obrigado!
  8. Não Andre, eu usei na "Criação do xml". Quando crio o xml, lanço as tag em um arquivo (.txt), depois eu renomeio este arquivo para ENTNFE.TXT e lanço na pasta do ACBrNFeMonitor, neste momento entendesse que o ACBrNFeMonitor seta as variaveis para NFC-e 65, devido a tag SetModeloDF("65"), porem como neste momento esta em contingencia, o arquivo xml não é enviado para o SEFAZ. Depois, ao estabilizar a rede, ou seja, nao estando mais em contingencia, vou enviar este arquivo já gerado e neste caso, não tem como eu enviar a tag SetModeloDF("65"), para setar o ACBrNFeMonitor, por isso ocorre o erro de modelo: Rejeicao: Modelo da NF-e diferente de 55. Sendo assim, eu fiz um teste, deixando na pasta de nosso sistema, um arquivo (.txt), com dados "falso", só para conter a tag SetModeloDF("65"), ai antes de enviar a NFC-e original, já gerada anteriormente, eu lanço este arquivo "falso" dentro da pasta do ACBrNFeMonitor, para setar e logo em seguida faço o envio do arquivo xml original, gerado anteriormente em contingencia. Ai da certo....
  9. Obrigado a todos pela ajuda. Por enquanto eu resolvi da seguinte maneira: Como observei que emitindo uma NFC-e em contingencia (removendo o cabo de rede), e logo em seguida, colocando o cabo de rede e enviando o xml já gerado anteriormente para o SEFAZ atraves do ACBrNFeMonitor, DEU CERTO, verifiquei que quando é criado o xml, é enviado a tag mod=65, no arquivo ENTNFE.TXT, onde provavelmente deve carregar/setar alguma variável no ACBrNFeMonitor, para ele tratar a nota como sendo uma NFC-e, sendo assim, antes de enviar uma NFC-e em contingencia, independente do tempo apos a geração ou fechando e abrindo o ACBrNFeMonitor, estou inserindo um arquivo ENTNFE.TXT, "falso", com a tag mod=65, somente para preparar o ACBrNFeMonitor, depois em seguida, enviou o xml CORRETO ref. a NFC-e gerado anteriormente, ai deu certo.
  10. Bom dia, Italo, desculpe, estou utilizando o ACBrNFeMonitor. O meu problema está no reenvio do xml, ou seja, na emissão da NFC-e em contingencia, estou gerando o xml, setando os campos MODELO e VERSAO, corretamente, porem o problema esta quando tento pegar este xml gerado em contingencia, no modelo 65 e versao 3.10 e tento envia-lo para o SEFAZ, através do ACBrNFeMonitor. No caso, o ACBrNFeMonitor teria que identificar que o xml pronto, já gerado anteriormente, que estou tentando enviar é uma xml do tipo NFC-e 65 e não NF-e 55.
  11. Boa tarde, Gostaria de saber qual a ultima versão do ACBrMonitor para NFCe e sua disponibilidade para download?
  12. Boa tarde, Desculpe estou utilizando o ACBrMonitor, neste caso, como faço para ele entender isso. No aguardo.
  13. Pessoal, ainda continuo com o problema, se alguém puder me ajudar: 90057->Rejeicao: Modelo da NF-e diferente de 55 Resumo: ao remover o cabo de rede e fazer uma NFC-e, esta é impressa em contingencia com sucesso, porem se fecharmos o ACBr e abrirmos de novo, conectar o cabo de rede novamente, e tentar enviar enviar esta NFC-e em contingencia, é apresentado a mensagem acima, na transmissão para o SEFAZ. Acredito que o ACBr esteja alimentando, como padrão 55 NFe, alguma "variável" de controle do tipo, não sendo possível, no futuro, faturar uma NFC-e em contingencia. Fiz um teste analisando o arquivo "ACBrNFeMonitor.ini", e este ficou idêntico antes e depois. Segue anexo o xml gerado. 51141009130769000107650010000900579000900571-nfe.xml
  14. Pessoal, fiz um teste aqui e deu certo, porem gostaria de saber se não seria um problema no ACBr, estou com a versão 2 0.9.0b. Gerei uma NFC-e em contingencia, removendo o cabo de rede, no ambiente de homologação, com o pensamento do ACBr carregar as "variaveis" e "arquivo" com o tipo 65 NFC-e, depois da impressão da contingencia, voltei o cabo de rede, alterei no ACBr para ambiente de produção e solicitei o envio da NFC-e do dia 10/10/14, que estava apresentando o erro citado acima, e deu certo seu enviou, consulta e impressão. Como se neste ponto e caso, o ACBr estivesse pronto para uma NFC-e. Alguem já viu isso? Sera que houve alguma correção em uma versao mais nova do ACBr?
  15. Não deu certo, ele apresenta erro: ERRO: Falha na validação dos dados da nota 3 Ocorreu um erro no Envio da Nota Fiscal! Quando começei o desenvolvimento da NFC-e, no manual o grande diferencial eram os 2 campos, A DATA e O MOTIVO da contingencia... acho que são obrigatórios.. O problema é que se eu gerar uma contingencia hoje e enviar, na homologação, dá certo, as vendas que estou tentando enviar para o SEFAZ, são as NFC-e em contingencia emitidas no dia 10/10/14.
  16. Pessoal, estou com varios clientes, já utilizando NFC-e e emitindo em contingencia, normal, porem em uma nova instalação, cliente novo, ao faturar uma NFC-e em contingencia esta sendo apresentado a mensagem de retorno: 3->Rejeicao: Modelo da NF-e diferente de 55 Porem no arquivo xml, está o modelo correto 65. Neste mesmo certificado, alterei o token de: DD13D34ADC9578DC287B5E6C298412D8 - Produção para cbd419b912d889d19bcb5ca74523a57 - Homologação e fiz uma NFC-e em Contigencia no ambiente de homologação e depois faturei, com sucesso, porem se volto o token para DD13D34ADC9578DC287B5E6C298412D8 e tento faturar no ambiente de produção o erro persiste. Estou montando a linha de comando: NFE.ENVIARNFE("C:\Executaveis\MegaFarma\Temp\51141009130769000107650010000000039000000038-nfe.xml", 1, 1, 1, ', 1) e inserindo na pasta do ACBr e o retorno é o mesmo. Obs: estas contingencias são do dia 10/10/14, sei que o faturamento deve ocorre em 24h, porem em pesquisa, identifiquei que não esta sendo bloqueado ainda, e também acredito que a mensagem seria outra, se este fosse o problema. Segue anexo o arquivo xml. 51141009130769000107650010000000039000000038-nfe.xml
  17. Segue abaixo o link para verificar a disponibilidade do servidor da SEFAZ no ambiente de homologação: http://hom.nfe.fazenda.gov.br/portal/disponibilidade.aspx?versao=2.00&tipoConteudo=Skeuqr8PQBY=
  18. André é isso mesmo, me ajudou muito, muito obrigado. Se trata de um cliente novo e este já tinha emitido a NFC-e 53 com outro numero de chave, trocamos a serie de 001 para 002 e deu certo. Obrigado.
  19. Estava tudo funcionando corretamente, porem hoje, está sendo apresentado a mensagem abaixo ao tentar Consultar uma NFC-e, depois de criado, validado e transmitido o arquivo xml NFCe. campo MM (mes) informado na Chave de Acesso e diferente do existente no BD. No caso, meu cliente é de MT e a data e o horário do Windows está correto, com o fuso horário -04:00 de Cuiaba. Arquivo_XML_NFCe.rar
  20. Pessoal, desculpe, parece que já foi corrigido na versao atual do ACBr.
  21. Allan Kardec Acho que consegui encontrar a solução, eu estava com o mesmo problema. Identifiquei que na linha 1575, do ACBrEPCBloco_F_Class, a variavel esta sendo preenchida corretamente, porem na linha 1691 esta sendo zerada FRegistroF550Count := FRegistroF550Count + RegF010.RegistroF550.Count; Linha 1575 FRegistroF550Count := FRegistroF560Count + RegF010.RegistroF560.Count; Linha 1691 - Nesta linha, no meu caso, como o Count do bloco F560 veio zerado, ele substituiu a variavel FRegistroF550Count que já tinha sido preenchida com a quantidade de linhas correta, ficando zerado, não sendo gerada no totalizador 9900; Sendo assim, eu ajustei a variavel FRegistroF550Count para FRegistroF560Count;
  22. Pessoal, estou com o seguinte problema: Na emissão de uma NFC-e, no estado de MT está sendo retornado a mensagem: "Data-Hora de Emissao posterior ao horario de recebimento", se o horário do Windows estiver correto, porém se eu alterar o horário do Windows para 1 hora antes dá certo a emissão da nota fiscal. O problema é que nosso sistema é homologado com o Farmácia Popular, onde a hora do windows tem que estar correta, neste caso, gostaria de saber qual o motivo de ter que ajustar o relógio do windows, deixando ele incorreto, para funcionar a emissão da NFC-e. Segue anexo, a NFC-e xml emitido, onde foi apresentado a mensagem acima. 51140807913556000118650010000900021000900020-nfe.xml
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.

The popup will be closed in 10 segundos...