Jump to content

charles.libano

Membros
  • Content Count

    52
  • Joined

  • Last visited

Community Reputation

21 Excellent

About charles.libano

  • Rank
    Membro

Profile Information

  • Sexo
    Masculino
  • Localização
    Juiz de Fora - MG

Recent Profile Visitors

487 profile views
  1. Amigos, Por desencargo de consciência, me tirem uma dúvida. Minha configuração atual é: oACBrNFE1.Configuracoes.Geral.SSLCryptLib := cryWinCrypt; oACBrNFE1.Configuracoes.Geral.SSLHttpLib := httpWinHttp; oACBrNFE1.Configuracoes.Geral.SSLXmlSignLib:= xsLibXml2; oACBrNFE1.SSL.SSLType := LT_TLSv1_2; Já está correto? Estou livre de ficar paralisado com a desativação do ssl? Obrigado. Charles
  2. Ítalo, Boa tarde. Fiz a alteração, reinstalei o ACBr e funcionou perfeitamente. Acho que esta alteração poderia subir para os fontes, já que não prejudica outras funcionalidades e corrige o erro da SEFAZ. Obrigado pela ajuda. Charles
  3. Bom dia a todos. Fiz um teste agora e em MG o cancelamento ainda está retornando com ns0 fora do padrão. Alguém pode me ajudar a resolver este problema? Acho que seria bom colocarmos no ACBr esta "correção do erro de MG". Quando consultamos no DFe uma NFCe de MG que foi cancelada, o retorno deveria vir o XML da transmissão com o protocolo do evento de cancelamento abaixo. Porém, pelo erro da SEF/MG, este retorno não vem, o que invalida o xml -NFeDFe.xml Se não for possível colocar nos fontes do ACBr, alguém pode me instruir como colocar nos meus fontes locais, pois a abstração é tamanha que nem sei onde mexer no ACBr nesta parte... Obrigado e desculpe a insistência, mas é crucial para meu sistema se manter correto sem grandes alterações, já que a equipe sou eu. rsrsrsrs. Charles
  4. Amigos, O Coordenador da NFCe de MG está de férias. Retorna somente no próximo mês. Assim sendo, não há outra alternativa a não ser removermos manualmente os name spaces errados. Há possibilidade de atualizar os componentes para estender esta funcionalidade de "corrigir" os erros da SEF/MG e então retornar -NFeDFe.xml corretamente através do ACBr? Não sei fazer isso... Obrigado. Charles
  5. Analisando melhor, o XML que você anexou não é o XML da NFe e sim o XML NFeDFe que agrupa o XML da NFe e a lista de eventos do mesmo: Ele é gerado com a extensão *-NFeDFe.xml. Você deve ter também um XML *-nfe.xml que é o XML da NFe com o protocolo de autorização apenas. Eu uso realmente como arquivo final o -NFeDFe.xml, renomeando-o. Ele terá NFe + eventos protocolados, ou seja, é um arquivo válido. O ACBr está montando normalmente o arquivo para os dois estados, mas como o retorno de MG vem fora do padrão (contendo os prefixos ns0:) acaba tornando o XML inválido. Há 2 meses, tivemos uma atualização do ACBr que removia os NameSpaces de MG no retorno da transmissão, devido aos retornos estarem vindo fora do padrão. Há possibilidade de atualizar os componentes para estender esta funcionalidade de "corrigir" os erros da SEF/MG e então retornar -NFeDFe.xml corretamente através do ACBr? Fazer uma reclamação na SEFAZ-MG a respeito dos prefixos, ou retirar manualmente os mesmos. Estou tentando telefonar diretamente para o Coordenador da NFCe de MG, para solicitar a correção deste erro através da STI. Obrigado pela ajuda. Charles
  6. @BigWings O XML que anexei foi feito com a propriedade False, ou seja, mantinha o original e o do cancelamento. Porém, quero o arquivo xml completo, ou seja, faço uma consulta ao DFe e ele me retorna a NFe autorizada, acrescida abaixo do protocolo do cancelamento. (Em MG isto não está funcionando) Entendi que colocando a propriedade True, isto aconteceria automaticamente, ou seja, o ACBr pegaria a NFe original e colocaria abaixo dela o protocolo do cancelamento, ficando exatamente igual ao anexo que enviei do RJ. Mas isso não aconteceu. Como em MG tudo ainda é novo, os contadores se confundem com 2 xml, sendo um deles da NFe transmitida e outro do cancelamento da mesma. Não há como manter 2 arquivos por enquanto. Alguma sugestão? Obrigado. Charles
  7. @BigWings Usei o comando: ACBrNFE1.Configuracoes.Geral.AtualizarXMLCancelado := True; Porém, não está sendo respeitado, não grava nada no xml final. Testei em RJ e MG. Alguma sugestão? Obrigado. Charles
  8. Boa tarde a todos. Estou com um erro que vou tentar explicar abaixo: Emito uma NFCe normalmente. Se eu cancelo esta NFCe, para pegar o arquivo dela com o protocolo de cancelamento anexado, utilizo a função ACBrNFe.Consultar Funciona perfeitamente para RJ. Porém, para MG, o arquivo não abre como um XML válido. Estou com os fontes do ACBr atualizados neste instante. Seguem 2 respostas de consulta, uma correta do RJ e a outra inválida de MG. Acontece tanto em homologação quanto em produção. Alguém tem ideia de que erro é esse? Obrigado Charles 33191108900996000101650010000142791774105611-nfe-canc.xml 31191118991455000181650010000003251228813241-nfe-canc.xml
  9. Olá a todos. Encontrei um erro na impressão do DANFCe em EscPos, quando utilizamos a funcionalidade de imprimir o qrCodeLateral. Fiz testes na Elgin I9 e na Epson TM-T20, ambas apresentaram o problema abaixo: Quando identificado o consumidor com CNPJ, Nome que ocupe 2 linhas, endereço + bairro que ocupe 2 linhas, cidade e uf na outra linha, não sai a linha do número e série da NFCe, nem a data e hora. Eu sugiro corrigir trocando a linha da NFC-e (número e série e data e hora) para vir antes da identificação do consumidor. E cortaria somente as sobras nas linhas da identificação (endereço), que julgo serem menos necessárias que a número/série. Eu mesmo faria esta correção, porém, não sei onde mexer nos códigos-fonte. Senão, terei que usar com qrCode embaixo nas NFCe identificadas o consumidor, o que aumentará em muito o consumo de papel, visto que a maioria dos clientes emitem mais de 1000 NFCe por dia, sendo quase 70% identificadas. Obrigado a todos. Charles
  10. MG gera somente o CSCid 000001 com o mesmo CSC para homologação e produção. Este erro mencionado ocorreu nos contribuintes que fizeram o cadastro através do Fale Conosco na mesma semana que liberaram o acesso ao Siare. Não sei informar o motivo, mas estes contribuintes não conseguem gerar nada em homologação. O que pode tentar (em 1 cliente meu funcionou) é entrar no Siare e gerar novamente o CSC. Como se fosse iniciar o processo. Primeiro gera em homologação e após 2 horas gera produção. Note que o CSC será o mesmo anterior, nada muda, acho que somente grava no servidor de homologação da Sefaz. Charles
  11. Amigos, Fiz o seguinte: Entro na contingência automaticamente ao detectar timeout ou erro de conexão. E para sair, criei 2 formas: tentando a cada meia hora ou então clicando no botão sair da contingência. Ah, e criei um monitor de contingências e pendências de canc/inut, além de editar xml recusados ao autorizar ctg. Fiz tudo ontem. rsrsrsrsrs. Obrigado a todos. Charles
  12. Bom dia. Conseguiram alguma solução para NFCe em MG em produção? Erro 12002 Timeout de requisição. Obrigado. Charles
  13. Bom dia, amigos. Faço todo o processo de contingência corretamente, ou seja, no timeout crio a nfe pendente, faço o clone do xml com nnf + 1, transmito em contingência. Quando retorna, envio as contingências para autorização e cancelo/inutilizo as pendentes. Imagine que emiti 10 nfce em contingência. Mas a dúvida que tenho é como detectar que devo sair da contingência após sefaz retornar ao normal? Se eu ficar tentando a cada nfce, terei que clonar todas e inutilizar ou cancelar muitas. Terei uma pasta de pendentes do tamanho da pasta de contingências a autorizar. Por outro lado, se eu ficar emitindo em contingência direta, pode ser que a sefaz já tenha retornado e eu não percebi na hora. Como vocês fazem esse processo de detectar a hora de sair da contingência? Nos exemplos e vídeos não fica bem claro como detectar a hora de parar de emitir em contingência (sair da contingência e emitir normal). Obrigado. Charles
  14. Coloquei o arquivo na pasta do exe e funcionou perfeitamente. Manterei assim e distribuirei conforme recomendado. Obrigado pela dica. Charles
×
×
  • Create New...