sesistemas

Daniel Deu certo! Desculpa minha ignorância mais, da pra explicar o superficialmente o que eu desabilitei com este comando? pq eu tenho receito do que isto pode acarretar...

So pra constar, estou fazendo este processo da seguinte forma: Cadastrei um item no meu sistema com código "1"; Na tela de venda há um "edit", onde eu informo o código do item, ao ser pressionado "enter" é disparado o evento de venda do item; Assim sendo eu "teclo" : 1 "enter" 1 "enter" 1 "enter" 1 "enter" 1 "enter" .... Sei que a impressora demora a processar as vendas, porem apenas o primeiro 1 enter é processado, o restante das entradas de teclado são ignoradas; Acredito que seja alguma rotina interna do ACBR que limpe este cash;

Estou fazendo a entrava via teclado (usb); Mais valeu a dica da Fila vou dar uma olhada aqui no forum e ver o que eu encontro; E quanto ao ACBRLCB não estou usando...

Olá! Boa tarde! Ao serem executadas leituras consecutivas de códigos de barra para vendas, como é comum em supermercados; A cada item que eu uso o método “VendeItem”, eu tenho de aguardar a impressora imprimir para que eu possa passar novamente este item pelo leitor de código de barras... Isso torna o sistema muito lento para o usuário final... Em outra aplicação que tenho, (a qual faz a comunicação diretamente com a DLL e a impressora Bematech), Não precisei fazer nenhum tratamento para o próprio Windows armazena o buffer de entrada (seja pelo teclado ou seja pelo leitor de código de barras) e envia o comando para a impressora; Como vocês contornarão esta situação?

Para constar estas exceções estão ocorrendo tambem no programa de Exemplo do ACBR;

olá Bom dia! Não consegui identificar o motivo, e gostaria da Ajuda de vocês. Após executar os comandos do componente ACBR, são geradas algumas "Debugger Exception", similares a estas : Resposta "ValorLiquido" não Encontada Resposta "NumeroItem" não Encontada Resposta "COO" não Encontada Apesar das exceções os comandos (na maioria das vezes) são executados corretamente... (não consegui identificar o que impede o comando de ser executado corretamente) Estou usando uma Daruma FS700 Aqui esta o log do comando: -- 09:53:25:114 NumSerie TX -> [FS]R[200]078[185] 09:53:25:235 RX <- :[200]078DR0911BR000000310441 [CR][236] -- 09:53:27:272 NumSerie TX -> [FS]R[200]078[185] 09:53:27:394 RX <- :[200]078DR0911BR000000310441 [CR][236] -- 09:53:28:703 VendeItem( 1 , ACUCAR , 7.00 , 1 , 10 , 0 , UN , % , D , -1 ) TX -> [FS]F[207]0400010000001000000000000000018 1UN TACUCAR[255]. 09:53:29:938 RX <- :0000001[207]002000000001000[CR][250]

Neste caso O Remetente entrega a carga a transportadora "A" que realiza o transporte da mesma até uma parte do trajeto. Ela vai entregar para outra transportadora B. Isso não seria um redespacho, onde informamos o Recebedor (Transportadora ???

Em algum lugar devemos constar a empresa quem contratou a transportadora B?

Daniel, não existem outros comandos que retornem estes valores? Observei que atravez dos métodos "ACBrECF1.NumCOOInicial" e "ACBrECF1.DadosReducaoZ" Eu tenho o retorno do COO inicial, mais pelo que pude observar, é o COO inicial da redução Z que ainda será gerada... (D+1)

Este dados do documento anterior sai em algum lugar no DACTe ? Qual campo ?

Estou utilizando uma Daruma FS700 E estou tendo problemas para ter alguns dados da redução Z... Através do método “DadosUltimaReducaoZ”; O Campo “NumCOOInicial” é retornado em branco.... Também não consegui encontrar um local onde é informado a data em que foi gerada a redução Z; Vi em alguns tópicos que algumas impressoras não possuem esta informação... mais não vi solução viável para este problema... Como vocês contornaram esta situação? retReducaoZ.txt logImpressora 31-10-12-14.txt

Existe algum arquivo de alimentação dos componentes no caso de um CT-e de Complemento de Valores

o que séria ? xNome =>nome do componente vComp ==>Valor do componente

Alguém poderia me informar se a ACBr já tem alguma coisa desenvolvida para o CT-e Complementa ?

quando for SUBCONTRATAÇÃO também tenho que informar documentos anterior ? como assim ?

infCTeNorm.emiDocAnt.Add; infCTeNorm.emiDocAnt[0].idDocAnt.Add; infCTeNorm.emiDocAnt[0].idDocAnt[0].idDocAntEle.Add; infCTeNorm.emiDocAnt[0].idDocAnt[0].idDocAntEle[0].chave :='31121003341645000186570090000000051612534080'; // infCTeNorm.emiDocAnt[0].CNPJCPF := '66666666666'; infCTeNorm.emiDocAnt[0].IE := '123456789'; infCTeNorm.emiDocAnt[0].UF := 'pp'; infCTeNorm.emiDocAnt[0].xNome := 'xxxxxxxxxxxxxxxx'; que nome esta referindo ?

deu o seguinte erro: infCTeNorm.emiDocAnt[0].idDocAnt.Add;====> List index out of bounds (0)

Quando vou emitir um cte de redespacho, neste caso peguei de uma outra transportadora e vou continuar o transporte, devo informa a chave do CTe? qual campo ACBrCTe1.Conhecimentos.????????

e o redespacho Intermediário ??

Bom dia Alguém podeira me informa e quando utilizar redespacho Intermediário e uma subcontratação no tipo de serviço do CTe ??

Gravei na base de dados a chave_cte e protocolo.; Só gostaria de gerar o XML através de uma consulta, caso apagarem o mesmo.

Quando uso ACBrCTe1.Enviar parace que ele já salva o .xml. Tentei usar esta instrução na consulta ACBrCTe1.Conhecimentos.Items[0].SaveToFile; so que deu erro.

Boa Tarde Envia um XML do CTe para receita e deu tudo certo. O problema é que alguém apagou o arquivo .XML. Como faço para consultar e recriar o arquivo .XML.

Caso alguém tenha o mesmo problema... os métodos : "TACBrECF.IdentificaPAF(NomeVersao, MD5: String)" e "TACBrECF.CorrigeEstadoErro(ReducaoZ: Boolean);" Executam o cancelamento do cupom fiscal quando este esta aberto... Para evitar problemas com estes comandos passei a verificar se o cupom pode ser aberto, em caso positivo eu executo as funções; try ImpressoraACBR.TestaPodeAbrirCupom ; ImpressoraACBR.IdentificaPAF('Versão: '+VersaoExe,'MD5: ' + vgbMD5); except on e:Exception do begin MessageDlg(e.Message, mtError, [mbOK], 0); end; end ;

Boa tarde! uso Delphi 2010, Impressora Daruma FS700; No que diz respeito ao teste 077 do roteiro 1.12 "Queda de Energia Durante a Emissão de Cupom fiscal" Ao fazer os seguintes passos: 1 executar o aplicativo; 2 abrir um cupom; 3 desligar todo o equipamento; 4 Religar o equipamento novamente; 5 executar o aplicativo; no passo 5 o Cupom é cancelado automaticamente, apos ser executado o comando "TACBrECF.IdentificaPAF(NomeVersao, MD5: String)" durante a execução deste método é gerada uma exception de debug... mais por ser de "debug" não "cai" dentro do ecept do try... O log da impressora esta em anexo... Gostaria de saber como vocês fizeram com este teste... Pensei em verificar junto a impressora se o ultimo cupom esta cancelado... mas não consegui encontrar comando para este fim na impressora. Att Christino logImpressora 03-10-12-14.txt