BigWings

Me parece um erro de validação do arquivo, indicando que a natureza de operação (natOp) não contém um valor válido. A natureza de operação deve conter uma string entre 1 e 60 caracteres. Verifique também a pasta de Schemas se está correta, use os Schemas da pasta ACBr\Exemplos\DFe\Schemas\CTe.

Lembrando que essa validação é da própria ANTT, nesse caso creio que cabe uma consulta junto à mesma.

Anexe os arquivos XML de envio e retorno do webservice para análise.

O campo forPag foi removido do layout do CTe a partir da versão 3.00. Ele é mantido no componente apenas por compatibilidade.

A resposta rápida pra esse caso seria usar o CFOP 6929. Mas é contraintuitivo emitir uma NFCe para uma mercadoria que vai ser destinada a outro estado, já que a NFCe destina-se a venda a consumidor final, presencial. Se a venda foi realmente presencial pode ser emitida NFe com CFOP 5929, idDest = 1 (interna), mesmo com endereço do destinatário sendo de fora do estado, desde que também seja informado operação presencial (indPres = 1) e sem frete (modFrete = 9). Também é preciso ver se a UF em questão (do emitente) permite o uso do CFOP 5929/6929 referenciando uma NFCe.

Testei o XML anexado e validou normal: https://dfe-portal.svrs.rs.gov.br/Mdfe/ValidadorXML

Significa que no XML a data/hora de emissão está superior à data/hora do webservice. Então verifique o relógio e fuso horário da máquina se estão corretos.

O erro indica um erro de leitura do XML. O teu XML tem quebras de linha, remova as quebras de linha do XML e tente de novo.

Pelos testes que fiz está tudo certo. Enviado ao repositório, rev. 17329. Obrigado @JeannyPaiva pela contribuição.

Notei remoção de algumas páginas no seu .fr3 em comparação com o .fr3 do repositório. A alteração foi feita sobre o último .fr3 do svn?

Disse lá em cima, a SEFAZ deve ter:

Correção no repositório, rev. 17327. Para MDFe não existe EPEC ou FSDA, apenas a contingência com tpEmis = 2. Favor atualizar os fontes e testar novamente.

Obrigado pelo interesse em contribuir. Não me pareceu correto ignorar descontos e acréscimo no valor a pagar. O mais correto seria usar a tag vNF como valor a pagar, da mesma forma como é feito no DANFE em EscPos. A soma de vProd + vServ seria o valor total.

Se você implementar a geração da tag no demo do ACBrNFe ocorre o mesmo problema?

Ao que parece você está preenchendo a tag descANP com uma string vazia. Então use o debug e verifique o conteúdo de QryAnpNOME.AsString no momento da atribuição à tag.

O emissor gratuito de MDFe foi descontinuado pela SEFAZ em outubro do ano passado, conforme aviso na página da SEFAZ-SP: http://mdfe.fazenda.sp.gov.br/ Ele não é mais compatível com o layout em vigor desde o dia 15/07/2019. Você deve procurar outra aplicação. PS: Separei o post em um novo tópico por não ter relação com o assunto onde foi postado originalmente.

Foi detectado um problema com a configuração fgtSempre caso informada diretamente no componente via object inspector, problema resolvido ontem mesmo na revisão 17317. Se a sua revisão está anterior a essa, atualize novamente os fontes. Configurando via código como você deixou entender, não deveria acontecer, entretanto. Então atualize novamente os fontes e teste, se ainda tiver problemas informe o passo a passo para reprodução.

Realmente é difícil dizer, apenas apontei uma possibilidade. Vejo que os arquivos parecem ter modificação posterior: A data/hora de criação dos arquivos pode dar uma ideia melhor do que aconteceu.

Se não me engano quando a configuração Arquivos.EmissaoPathNFe está False o ACBr usa a data atual da máquina para determinar a pasta a salvar. Então se a data do PC estava em Julho isso seria possível.

Se está tendo erro de validação e não rejeição, não é o mesmo assunto do tópico. Verifique a pasta de schemas. Se ainda tiver erro anexe o XML e em um novo tópico descrevendo melhor o problema.

Você pode definir um valor maior se quiser as linhas separadas ou um valor menor se quiser mais condensadas. Se deixar 0 é usado o espaçamento padrão da impressora que o ACBrMonitorPLUS não sabe qual é, assim não consegue calcular a altura máxima da região do QRCode e dados da NFCe, ficando assim os dados da NFCe limitados a altura do QRCode.

Mesmo configurando o espaçamento entre linhas?

Quando o emitente do MDFe estiver usando um veículo de terceiros, deve informar os dados do proprietário do veículo (CPF, RNTRC, etc) nos grupos veicTracao/prop e veicReboque/prop. Já o RNTRC da transportadora informado na tag rodo.infANTT.RNTRC deve estar associado ao CNPJ da mesma.

Exato, era possível antes o download pelos estados usuários da SVRS, hoje aparentemente não é mais possível.

A regra de validação é facultativa, cada UF decide se vai implementar ela ou não.