BigWings

Tem acontecido se estiver usando o modo de envio assíncrono. Após o envio não está sendo capturado o número do recibo, e ao tentar fazer a consulta do mesmo, sendo vazio, está gerando a rejeição por falha no schema. A sugestão é usar o modo síncrono, já que o assíncrono está previsto pra ser desativado já no mês que vem, se não me falha a memória.

Verificar a questão das colunas e ativar a propriedade "ImprimeEmUmaLinha" do componente. Outra dica é configurar a "EspacoEntreLinhas" do PosPrinter, com um valor entre 30 ou 40, deve reduzir o espaçamento vertical, se esse é o problema do seu cliente.

Por que não tem como? Só vai ter o XML completo após a manifestação.

Precisa ver qual a quantidade de colunas que a impressora suporta, e configurar no componente. Para o ESC/POS, só precisa do driver USB, não passa pelo driver do Windows.

A princípio o componente só trazia as informações que a consulta da receita federal fornece. https://solucoes.receita.fazenda.gov.br/servicos/cnpjreva/cnpjreva_solicitacao.asp Com o bloqueio do acesso dessa página pelo reCaptcha o componente foi alterado pra usar APIs de terceiros, receitaws, cnpjws, brasilapi... Essas APIs podem trazer informações adicionais, como as inscrições estaduais vinculadas ao CNPJ, então foi adicionada a propriedade pra trazer a IE da sede da empresa. Outras possíveis informações que as APIs disponibilizam (regime tributário, por exemplo) nos JSONs não estão totalmente mapeadas como propriedades, então precisa modificar o componente pra fazer isso. Fique a vontade pra modificar o componente da forma que achar interessante, e anexar aqui os fontes alterados pra serem analisados e enviados para o SVN.

A chave mudou por causa da alteração do tpEmis. Alteração da data de emissão dentro do mesmo mês não vai mudar a chave, mas isso não quer dizer que você deva fazer isso. O correto é carregar o XML emitido em contingência e transmitir, sem alterações. Se transmitir dentro do prazo de 168 horas não terá problema.

Testei no Delphi 7 e instalou normal. Pode tentar instalar marcando a opção de apagar arquivos antigos.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

- Transmitir o MDFe emitido em contingência, sem alterações. - Encerrar o MDFe O MDFe já está operando normalmente, ainda está com erro na emissão?

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Ontem foram enviadas alterações pra esse problema. Atualize os fontes.

Informe a versão do documento ao preencher os dados: infMDFe.versao := 3.00; infCTe.versao := 4.00;

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Atualize os fontes.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Aumentar a configuração de timeout no componente. ACBrNFe.Configuracoes.WebServices.TimeOut := 30000;

Não saberia dizer, não uso CAPICOM há anos. A diferença para a emissão normal é na geração do QrCode que tem campos e hashs adicionais, talvez tenha algo nesse sentido que o CAPICOM não consegue gerar.

Mostre o seu código, a parte de assinatura e validação.

Esse erro indica falta da assinatura do XML. Sem assinar não tem o QrCode no DAMDFe, fica inválido. Sem validar corre o risco de ter rejeição quando for enviar.

É sim.

A contingência SVC é para NFe e CTe apenas. Para NFCe a contingência é apenas offline (tpEmis = 9). Mesmo caso do MDFe mas com tpEmis = 2.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.