EliasCesar

Olá, Anexe o log do ACBrETQ por favor.

Disponibilizada versão 1.1.0.17.

Olá, Qual o modelo da balança que está sendo utilizada, e qual opção está selecionada em 'ACBrBAL.Modelo' ?? Por favor, anexe o log do ACBrBAL também.

Olá, Você está utilizando o demo do ACBrMTer? Anexe os logs gerados pelos componentes(ACBrMTer e ACBrBAL), por favor.

Acho que sei o que pode ser... Vi aqui no manual do Micro Terminal que ele possui uma opção de configuração chamada "Origem de Dados", onde ele informa qual interface enviou os dados(teclado, Serial1 ou Serial2). Porém o componente não está preparado pra receber essa informação. Tente refazer o teste desabilitando essa opção (pág. 19 do Manual).

O problema ocorre apenas no Fluxo de Vendas? Os comandos estão funcionando normalmente? (Enviar Texto, Limpa Display, Deslocar Linha, etc.) Tente configurá-lo com o protocolo VT100 - Esc para ver se ocorre o mesmo problema.

Nunca efetuei testes com esse modelo de Micro Terminal, mas dei uma olhada rápida no manual dele em: http://www.bematech.com.br/administrador/files/equipamento/suporte/1/Microterminais_Manual_FITBASICO.pdf Pelo que vi é possível configurá-lo com 3 tipos de protocolos: • VT100-STX / ETX; • VT100-ESC; • VT100-SB100. O primeiro parece ser compatível com nosso 'mtrSTX/ETX', o segundo com o 'mtrVT100' e o terceiro não é compatível com nenhuma das nossas opções. Verifique com qual protocolo o seu Micro Terminal está configurado ou configure ele seguindo esse manual. Depois efetue o teste com o protocolo referente.

Bom dia @nicolasbraz, Por favor, reproduza o problema utilizando o demo do ACBrMTer e anexe o log gerado para facilitar a análise.

Geralmente para impressoras Zebra a linguagem é essa mesmo (etqZPLII), Porém esse modelo parece trabalhar com a linguagem EPL2, conforme esse link: http://www.impressorazebra.com.br/zebra/tlp2844 Teste utilizando os dois tipos de linguagem e anexe os arquivos solicitados. Dessa forma ficará mais fácil de analisarmos.

Olá, Alterações estão disponíveis no SVN, Revs: 12952 e 12953. Não foi mantida a comparação com a string "LEITURA MEMÓRIA FISCAL" pelo risco de falhar caso o texto seja retornado pelo ECF sem acento por exemplo. Com essa alteração, a função irá verificar apenas o início das linhas buscando inicialmente pela string "CRZ" e depois pelo próprio número do CRZ. Dessa maneira acredito que ficará mais versátil e sem risco de falha caso algum ECF retorne a LMF de maneira um pouco diferente.

Olá, Foi aplicada a correção com um pequena alteração. Disponível no SVN, Rev: 12945 Obrigado pela contribuição.

Olá, Correção disponível no SVN, Rev: 12944 (Obs: O SVN do S.F. voltou a funcionar normalmente)

Olá @Augusto Fontana A alteração está disponível no SVN, Rev: 12898. Obrigado pela contribuição! -- ACBrBlocoX_ReducaoZ -- [-] Correção de problema ao truncar valores. Passado a utilizar TruncFix. (por: Augusto Fontana) Olá @Eduardo Muller Confirme se seus fontes realmente estão atualizados, pois o ACBr foi modificado para gerar conforme seu exemplo de "Xml ajustado".

Olá O tipo de Código de Barras 'F'(EAN13) sempre vai utilizar o dígito verificador correto. Caso seja informado o dígito incorreto ou não seja informado, ele será recalculado. Você pode utilizar outros tipos de códigos de barras que não possuem dígito verificador. Por exemplo: 'A' (3 of 9) ou 'E' (Code 128).

Foram efetuadas correções para atender as alterações nos tamanhos dos campos. Disponível no SVN, Rev: 12883.

Olá, Enviei a correção sugerida ao SVN, Rev: 12866. Obrigado pela contribuição.

Olá, Está sendo colocado o mesmo conteúdo nas propriedades "XML" e "XMLZipado"? Experimente popular apenas a propriedade "XML" e deixar a "XMLZipado" vazia, pois dessa forma o componente tentará compactá-lo automaticamente antes do envio. WebServices.EnviarReducaoZ.XML := stlArquivoXML.Text; if WebServices.EnviarReducaoZ.Executar then begin . . end;

Olá, Há algum tempo atrás fiz testes com o micro-terminal Gertec MT-720 junto à uma balança Filizola e funcionou corretamente. Nos seus testes ocorreu algum erro? Para facilitar a análise, anexe o log do componente ao caso, por favor.

Olá, Verifique que já existe uma função para a compactação do arquivo no componente (chamada "ZipFile()" e localizada em ACBrBlocoX_WebServices.pas). Caso seja informado o apenas xml na propriedade "XML", o próprio ACBr irá compactar o arquivo no momento do envio.

Olá Algum tempo atrás fiz uma bateria de testes com uma Elgin L42 e deu tudo certo sim, não tive nenhum problema com ela. Porém esse modelo L24 eu desconheço.

Olá, Recentemente foi efetuada uma refatoração de ACBrBAL e verifiquei que o código está incompatível com o novo padrão. Os trechos de código referentes à interpretação da resposta devem vir em "InterpretarRepostaPeso()". Outro detalhe é que no momento da interpretação da resposta, nunca está sendo devolvido o peso "Instável". Verifique o trecho: StatusPeso := ' '; if Length(Resposta) >= 1 then begin StatusPeso := 'E'; end; case StatusPeso of 'I': fpUltimoPesoLido := -1; { Instavel } 'E': fpUltimoPesoLido := StrToFloat(Resposta) / 100; { Estável } else fpUltimoPesoLido := 0; end;

Olá, Conforme citado por Daniel Foi criada uma nova propriedade "TACBrTEFD.ConfirmarAntesDosComprovantes" para possibilitar a confirmação das transações antes da impressão das vias do TEF. Caso essa propriedade esteja ligada, a confirmação das Transações será efetuada logo no início da procedure "ImprimirTransacoesPendentes". Também foi alterada a procedure "VerificarTransacoesPendentesClass(aVerificarCupom: Boolean)" para sempre que a nova propriedade estiver ativa, tentar verificar se o cupom foi finalizado ou não, possibilitando a reimpressão dos comprovantes. Dessa forma a propriedade "TACBrTEFDDial.InicializarConfirmandoTransacoes" pôde ser removida, pois esse controle ficou por parte da nova propriedade "ConfirmarAntesDosComprovantes".

Também não encontrei o trecho referente aos combustíveis no TXT. O layout seria algo como: [CombustivelXXX] cProdANP=XXXXXXXXX (Há um exemplo desse grupo no manual "ACBrMonitor.pdf").

Olá, Verifiquei que no xml não está sendo informado o grupo "comb"(Detalhamento Específico de Combustíveis). Quando é utilizado um CFOP de combustível esse grupo torna-se obrigatório. Segue lista de CFOP que obrigam essa informação de acordo com NT2012.003:

Olá, De acordo com a NT2015.003 o grupo ICMSUFDest deve ser informado "(...) nas vendas interestaduais para consumidor final, não contribuinte do ICMS", para emitentes de qualquer UF, não apenas em SP. Pelo que entendi, os valores passados pelo contador são referentes ao recolhimento "(...) aos cofres públicos paulistas ", que no caso será o imposto retido pela UF emitente. Dessa forma bate com o layout do campo pICMSInterPart que se refere ao imposto recolhido pela UF de destino. Ou seja: 2016 - 40% UF de Destino e 60% UF Emitente 2017 - 60% UF de Destino e 40% UF Emitente 2018 - 80% UF de Destino e 20% UF Emitente