EMBarbosa

Muito obrigado pela contribuição. Fiz a implementação baseada nela com algumas modificações. Subi as alterações para o SVN na Revisão 18602. Pelo que vi está tudo certo. Mais uma vez obrigado. Estou fechando esse tópico que já serviu ao seu propósito. Queira por favor atualizar, testar e reportar qualquer problema em um novo tópico.

As últimas alterações para esses arquivos foram enviados ao SVN na revisão 18600. Convidamos a todos para testarem e reportar qualquer problema encontrado.

Claro. Você pode fazer a alteração e anexar aqui pra análise?

Não é a mesma hierarquia não. O C430 é filho do C425, já o C480 é filho do C470.

Você consegue criar um pequeno aplicativo que reproduz o problema?

Olá AutomoSistema, é necessário informar na tag IDE os campos UFIni e UFFim. Veja o seguinte modelo de MDFe: https://acbr.sourceforge.io/ACBrMonitor/ModeloMDFeINI.html Estou fechando esse tópico porque o assunto original já foi resolvido. Caso tenha outra dúvida, fique a vontade para abrir um novo tópico conforme a regra: 2.2 - Permaneça no assunto - Quando tiver uma dúvida diferente do assunto no tópico, poste em novo tópico. Não use algo equivalente a "aproveitando o gancho... [dúvida não relacionada com o tópico aqui]". Para mais informações sobre as regras, veja esse tópico:

Será que sua aplicação não está sendo bloqueada por um antivírus, programa de proteção bancária ou algo similar?

Você pode até criar uma classe no ACBrTEFD para isso. Mas não sei se é a melhor saída pra vocês.

Mas suporta o modo de troca de arquivo.

Acho que sim. Nesse caso, essa configuração deveria ser por máquina. A propósito, tivemos relatos de que algumas atualizações do Windows 10 corrigem esse problema. Sua máquina usa Windows 10? Está atualizado?

Olá AGrif... Que complicada está essa situação. Tente ver se a sugestão desse tópico resolve o seu problema:

Se usar um aplicativo de teste do fabricante funciona? Porque pode ser algum problema no equipamento.

Olhando pelo site deles, me parece que esse modelo específico só imprime em Raster, o que não é suportado pelo ACBrETQ. Outros modelos aceitam outros protocolos, como vocês podem ver no site: https://www.brother.co.jp/eng/dev/command/reference/index.aspx

Tudo bem! Agradecemos muito sua ajuda até o momento. Continue fazendo testes e qualquer coisa, pode criar um novo tópico.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 18505. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Agora só nos resta os C8xx C810 Itens do documento do cupom fiscal eletrônico – SAT (CF-E-SAT) (código 59) C815 Informações complementares das operações de saída de mercadorias sujeitas à substituiçãotributária (CF-E-SAT) (código 59) C870 Itens do documento do cupom fiscal eletrônico – SAT (CF-E-SAT) (código 59) C880 Informações complementares das operações de saída de mercadorias sujeitas à substituiçãotributária (CF-E-SAT) (código 59) Mais uma vez obrigado.

Que estranho. Ele está na lista de eventos no help, veja: http://docwiki.embarcadero.com/Libraries/Rio/en/FMX.NumberBox.TNumberBox_Events Mas realmente não tem no componente...

Não seria melhor mover o código para o evento OnValidate?

Acho que você enviou os arquivos sem as alterações.

Pelo log a balança não está respondendo nada. Você precisa verificar no manual da balança se há alguma configuração pendente e se o protocolo está correto. Também precisa verificar se as configurações da pora serial do componente estão corretas de acordo com a balança.

Isso aí.

Por mim está ótimo. Só não podemos esquecer de adicionar essa validação também no registro 9900 no arquivo ACBrSpedFiscal.pas.

Olá, Muito obrigado pela ajuda. Detectei um problema no registro 0002. Como conversamos antes, ele pode ou não ser informado, então precisamos verificar se ele foi realmente informado pelo usuário do componente antes de adicionar no arquivo SPED e no registro 9900. Essas são as opções que eu pensei: Validar o conteúdo do campo CLAS_ESTAB_IND ser diferente de ''; Validar a exigência dele, via campo IND_ATIV do registro 0000 ser igual a “0”. Usar uma lista como é feito com outros registros; Acho que a primeira opção é a mais viável. O que você acha? Com respeito as outras alterações, já estão no SVN. Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 18493. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Antes de enviar outros arquivos, queira atualizar para que não se percam as alterações que eu fiz. Mais uma vez obrigado.

Olá, Eu acho que o manual está equivocado de alguma forma. A questão é que o registro 0002 não é obrigatório para todos que apresentam. Apenas quando o campo IND_ATIV do registro 0000 for igual a “0” é que o registro 0002 deve ser informado. Então, considere o Registro 0005 que é sempre obrigatório e considere a situação em que o campo IND_ATIV do registro 0000 for igual a “1”. Como o Registro 0005 vai ser filho do registro 0002 se não existe registro 0002? Por outro lado, a hierarquia vai ficar mudando de um registro para o outro? Talvez precisemos testar vários arquivos de exemplo com o novo PVA para saber como eles realmente querem. A princípio queira manter o padrão atual do código, quer dizer, seguindo a hierarquia do Registro 0001.

Olá Leonardo. Que tipo de leitura você está querendo fazer? No QrCode não tem dados da nota, apenas um link para acessar a nota na web.