Ir para conteúdo
  • Cadastre-se

Joabe Geraldo

Membros
  • Total de ítens

    66
  • Registro em

  • Última visita

Últimos Visitantes

1.413 visualizações

Joabe Geraldo's Achievements

Enthusiast

Enthusiast (6/14)

  • First Post
  • Collaborator Rare
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges

16

Reputação

2

Community Answers

  1. Bom dia. Estou com problema com homologação de NFC-e em MG. Estou tendo a seguinte rejeição: Endereço do site da UF da consulta por chave de acesso diverge do previsto. Já atualizei o Acbr, refiz a instalação do componente e fiz build do sistema, conforme vi orientação em outro tópico e ainda sim não resolveu. Também copiei o arquivo AcbrNFeServicos.ini para a pasta do meu executável, e fiz várias simulações com diferentes URLS, inclusive com as que estão indicadas no portal da Sefaz de MG e mesmo assim não tive êxito. Alguém está conseguindo autorizar NFC-e em homologação em MG? Qual URL vocês estão utilizando?
  2. Oi @Renato Rubinho Eu editei os dados do emitente. Validei o arquivo nesse link que você me passou, ele validou corretamente. A Estrutura do XML atual está igual à de outros que haviam sido autorizados anteriormente. Creio ser mais um dos inúmeros problemas do ambiente da Sefaz MG. O meu cliente acabou emitindo o CT-e que deveria ser de Subsituição com a finalidade normal, indicando problemas na Sefaz nas informações complementares, conforme orientação da contabilidade.
  3. Bom dia, amigos Estou com um cliente com problema em um CT-e de substituição desde terça feira em MG. Ao Fazer a transmissão estamos obtendo o erro de "Lote em Processamento". A estrutura do XML está exatamente igual à outros CT-e de substituição que já foram autorizados anteriormente. Um fato curioso é que CTE-e com finalidade de Anulação e Normal estão sendo autorizados normalmente. Alguém tem alguma ideia ou já passou por isso? Obrigado 31220628990319000120570010000013291000002314-cte.xml
  4. Boa tarde. O AcbrEtq é compatível com Knup kp-1030 ? https://produto.mercadolivre.com.br/MLB-1689216033-impressora-de-etiquetas-tipo-zebra-compativel-ml-b2w-kp-1030-_JM?searchVariation=66397383178#searchVariation=66397383178&position=6&search_layout=grid&type=item&tracking_id=6683049b-bd39-4370-b239-cc4766d8eb1e
  5. Acabei de detectar que em um dos clientes que estavam com esse problema a contabilidade estava fazendo o uso do serviço com o certificado do cliente
  6. Estou passando pelo mesmo problema. Passando o ultNSU zerado também continuo obtendo o erro de consumo indevido.
  7. Boa tarde. Vou fazer o teste incluindo todos os escopos de cobrança. Obrigado @JHONLENON
  8. Boa tarde. Eu não consegui identificar qual escopo devo usar para fazer prorrogação do vencimento. Qual vocês estão usando ?
  9. Já resolvi o problema usando a opção TimeOutPorThread = True,e corrigindo a forma que e buscava o timeout das configurações do sistema. Obrigado
  10. Bom dia. MG está com paralisação programada desde sábado. Os clientes que utilizam WinCrypt, após o tempo configurado no AcbrNFe, obtém uma mensagem de erro de comunicação com a SEFAZ e a NFC-e é emitida em contingência. Porém os clientes que estão configurados com OpenSSL o Componente fica travado no envio, entra em loop, e não obtém mensagem de erro. Com isso o sistema não consegue entrar em contingência. Fazendo o debug verifiquei que o travamento ocorre no método function TDFeHttpOpenSSL.Enviar, da unit ACBrDFeHttpOpenSSL. O problema ocorre na linha OK := FHTTP.HTTPMethod('POST', AURL); Gostaria de saber se posso fazer alguma configuração para evitar este travamento. Minha configuração: with AcbrNFe1 do begin Configuracoes.WebServices.AjustaAguardaConsultaRet := False; Configuracoes.WebServices.AguardarConsultaRet := 0; Configuracoes.WebServices.IntervaloTentativas := 0; Configuracoes.WebServices.Tentativas := 5; Configuracoes.WebServices.Timeout := 2000; Configuracoes.Geral.SSLLib := libOpenSSL; ACBrNFe1.SSL.SSLType := LT_TLSv1_2; end
  11. Nossa indicação para os clientes é sempre de comprar o A1 mesmo, porém alguns contadores acabam convencendo o cliente a fazer o A3 e "somos obrigados" a usar. Obrigado pelo retorno @Felipe E. Resende Mesquita.
  12. Boa tarde. Já tivemos muitos casos de perda do certificado A3 há algum tempo. Uma das recomendações que tivemos foi não informar a senha do certificado no componente, dessa forma o usuário teria que informar toda vez que abrisse o sistema. Esta situação ainda persiste ou não existe mais problema em informar a senha no componente ? Obrigado
  13. Boa tarde. Obrigado @everson.turossi e @BigWings pelas respostas. Para não ter que criar uma outra cópia do arquivo .fr3 eu segui a dica do Everson. Eu estava configurando errado a propriedade Modelo, estava preenchendo com 'ppEscEpsonP2'. Depois dessa configuração a impressão saiu perfeita, do jeito que eu precisava. Obrigado pela atenção.
×
×
  • 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...