Jump to content

Curso Dominando o ACBrMonitor
Novo Módulo Soluções de Varejo
Assine o SAC ACBr em qualquer plano e tenha acesso

Saiba Mais

Balança SM100 performance surpreendente

Tecnologia Japonesa   Teclado e Visor resistentes a água
Consumo inteligente de etiquetas   Baixo custo de manutenção
Comunicação Ethernet e WIFI independentes

Saiba Mais

Impressora de Etiquetas ELGIN - L42 PRO

Protocolos PPLA, PPLB, ZPL, EPL (automático)
Porta USB padrão Opcionais: Ethernet, Serial, Paralela
Sensor de Etiquetas Móvel Garantia de 18 meses

Saiba mais

aocampioni

Usuários SAC
  • Content Count

    203
  • Joined

  • Last visited

Community Reputation

34 Excellent

3 Followers

About aocampioni

  • Rank
    Membro
  • Birthday 11/15/1973

Contact Methods

  • Website URL
    http://www.consultatec.com.br

Profile Information

  • Sexo
    Masculino
  • Localização
    São Joaquim da Barra

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Daniel, obrigado. Matou a pau, erro em uma máquina que tenho aqui que simula o mesmo ambiente que tem na maioria dos clientes. Windows 7. Um KB estava desatualizado nela (assim como em muitos dos clientes) e por isso não rodou a impressão. Rodei pela minha que tem windows 10 (no começo do post eu havia rodado na minha e deu erro 103) e não deu mais nenhum erro. Engraçado que pelo posprinter , lá na máquina que tem windows 7 funcionou. Mas é isso, acredito que está resolvido essa questão no ACBr. Obrigado mais uma vez e até mais.
  2. Pessoal, Boa tarde. Dando um retorno prometido sobre a situação é o seguinte. Em 90% do tempo não consigo usar mais os comandos a : Assignfile(iImp,'\\192.168.100.97\tp650'); Rewrite(iImp); <== agora o erro é i/o error 1265 Writeln(iImp,sCodigoInicializacaoImp); <== não chega aqui. Se eu coloco Assignfile(iImp,'\\192.168.100.97\tp650'); {$I-} Rewrite(iImp); <== engole o erro {$I+} Writeln(iImp,sCodigoInicializacaoImp); <== então dá i/o error 103 No posprinter, tudo resolvido, digo, no programa de exemplo. Ativação, impressão. Os arquivos texto que abro e leio utilizando o AssignFile também estão ok, mesmo estando em qualquer local, mesmo compartilhado. Analisando o antigo arquivo ACBrDevice e agora os novos ACBrDevice e ACBrDeviceSerial, a impressão que tenho é que muitos recursos são utilizados porque muitas classes são criadas de uma vez. (LPT, SERIAL, TXT, RAW). No meu datamodule que instancio quando crio de cara tem um ACBrECF pra caso a aplicação utilizar ECF já verificar o estado da impressora (se está em erro ou ainda em venda, caso caia a energia , já corrige o estado de erro). Quando entro na tela de vendas, tenho componentes de balança, leitor, gaveta, display, ou seja, muitas vezes se passa pelo device e instancia-se todas essas classes. Acho que o erro 1265 (que por acaso não encontrei gogleando) mais se parece com um MANY RESOURCES OPENED. Veja , não tenho competência pra isso tá, só minha impressão. No antigo ACBrDevice era apenas separado por tipos (fsDeviceType: dtTCP, dtSerial, dtFile, dtParallel dtUSB, dtRawPrinter) e a instância era 1 apenas e na hora de ver quem é quem perguntava-se pelo tipo mas depois cada tipo virou uma classe a ser instanciada. Mais alguma dica/sugestão do que ser feito ?
  3. ok Daniel, farei mais uns testes esse fim de semana e na segundona reporto como está tá ok. Obrigado pessoal. Abraço.
  4. Opa, vou verificar Waldir e aplicar esse workaround aqui no meu código, valeu. Abraço.
  5. Waldir e Daniel, Bom dia. Olha, olhando aqui com um pouco mais de calma (não consegui acompanhar todo fluxo pois me falta tempo e certa competência) mas notei que falta aplicar as diretivas também no arquivo ACBrDeviceRaw. No arquivo ACBrECFNaoFiscal não notei que precisa dessas diretivas se bem que há pontos em que elas 'calham'. A impressão, como o Waldir disse mesmo, é que após um assign pra começar a trabalhar com Reset ou Rewrite em algum ponto arquivo parace ser fechado antes de eu comandar Reset ou Rewrite, mas após acontecer pela primeira vez ele parece permanecer aberto (ou é ao contrário tá, como eu disse não tive tempo, nem competência, pra acompanhar o fluxo) pois se eu voltar pra executar novamente a rotina do sistema e não dá o erro. E aí ao final do processo tudo ocorre corretamente, mas, se eu for imprimir novamente dá o mesmo erro 103 e aí, denovo, se eu repetir em seguida ocorre normalmente. Então vamos lá, executo o processo; // primeira vez Assignfile(iImp,sPorta); {$I-} Rewrite(iImp); { aqui surge o erro 1ª vez } IOResult; {$I+} Writeln(iImp,sConfigInicial); // segunda vez Assignfile(iImp,sPorta); {$I-} Rewrite(iImp); { não acontece o erro mais } IOResult; {$I+} Writeln(iImp,sConfigInicial); // terceira vez Assignfile(iImp,sPorta); {$I-} Rewrite(iImp); { acontece erro novamente } IOResult; {$I+} Writeln(iImp,sConfigInicial); Claro que se eu fizer essa super ultra gambi, tudo funciona. try Assignfile(iImp,sPorta); try {$I-} Rewrite(iImp); IOResult; {$I+} except end; finally {$I-} Rewrite(iImp); IOResult; {$I+} end; Mas são muitos pontos e muitas situações dentro do meu software. Como na volta das revisões não peguei nada que me atrapalhasse resolvi voltar pra versão onde o ACBrDevice é único. Tá aí, foi o que consegui reproduzir. Se ajudar tá valendo. Obrigado por enquanto pessoal.
  6. Waldir, Sinceramente digo que me preocupo mas sei o que tem por traz de todo esse projeto. Essa sim é uma grande equipe de desenvolvimento, das melhores que já vi. Do outro lado, muitos usuários testando e é isso que fazcom que o ACBr seja esse sucesso que é hoje. Sei que será resolvido e o que nós usuários pudermos fazer para contribuir, faremos. Estou agora copiando essa versão de 06/01 para um diretório isolado e vou fazer um SVN Update nele lá e voltar algumas revisões pra chegar em 06/01 e de lá pra cá tentar identificar algo. Qualquer coisa posto aqui. Muito obrigado, abraço e bom dia.
  7. Então Waldir, muito estranho, eu fiz aplicação desse item que você mencionou em todas minhas chamadas, inclusive não só impressão, mas também quando eu precisei ler ou gravar arquivos textos em algumas rotinas. Fiz em todas mas não resolveu. Apenas gostaria de dizer, que aparentemente depois que o ACBrDeviceSerial entrou na jogada (pois eu não tinha ele quando atualizei em 06/01/2020) o erro começou a aparecer. Pode ser alguma coincidência. pode estar em alguma rotina nova, ou alguma outra alterada/melhorada, não sei. Fiz o teste na outra máquina que estava funcionando também, atualizei o ACBR lá com as últimas revisões até o dia 10/02 e o erro começou a acontecer também. Voltei essa versão que baixei em 06/01 e o erro não aconteceu mais. Fiquei preocupado pois agora não posso ter as últimas alterações no ACBr enquanto não descobrir o que pode estar ocorrendo de fato, mas sigo testando, com a versão / correções até 06/01 não estou tendo problemas. Até mais,
  8. Daniel, Confirmando apenas : - fiz o teste com o fonte que você me passou e continuou o problema. - fiz o teste com o fonte que você me passou, com instalação limpa do delphi e do acbr, o problema continuou, até ao abrir os projetos pela primeira vez dava o bendito erro io 103 e não só nas impressões com o writeln e o posprinter. - removi novamente todo acbr e instalei a versão anterior que eu tinha (sempre guardo) de 06/01/2020 e funcionou, sem problemas, tive que remover todos os ACBrDeviceSerial dos fontes onde tinha a unit ACBrDevice pois não está presente esse arquivo nessa versão. Então, verde funcionando, vermelho é só instalar que passo a ter erro io 103 até na hora de abrir o projeto, não só na impressão com o prosprinter ou usando o writeln. O que pode ser feito? Há mais algum teste que quer que eu faça? Até mais,
  9. Daniel, boa noite. Muitíssimo obrigado pelas prontas respostas, vou substituir a biblioteca agora e testar. Retorno mais breve possível. Até mais, Daniel, Passo a passo é o seguinte, entrei no demo, coloquei a porta de rede \\127.0.0.1\tp650, como eu disse é local mas poderia ser \\192.168.0.30\tp650 (que é como outra máquina da minha rede vê a minha) e daí ativei, desativei, ativei novamente e aqui já dá o erro. Lembrando, que pelo USB:Tanca local ou se tivesse RAW:Tanca-TP650 posso fazer o procedimento que o erro não acontece. Também não acontece com a impressora RAW:NPI0DE3D que é uma HP via cabo de rede. Até mais,
  10. Pessoal, Boa tarde. Notei um fatídico I/O error 103 após última atualização que fiz nessa semana, dia 10. Simplesmente não sei o que é, antes eu utilizava portas no sistema , mesmo com o ACBrPosPrinter ou com o famoso Rewrite dessa maneira: \\127.0.0.1\tp650 , tipo, impressoras compartilhadas em outras máquinas (claro que essa impressora é compartilhada mas tá local na minha máquina para testes) e agora obtenho esse erro; Basta tentar ativar ou desativar que o erro é provocado. Pra simular certinho, entrei no posprinter demo, dei ativar e não ocorreu o erro. Desativei e selecionei Cortar Papel e fui ativar novamente e deu erro na Função abrir arquivo: procedure TACBrDeviceLPT.AbrirArquivo; var CreateModeFlag: Integer; NomeArq: String; begin NomeArq := ObterNomeArquivo(fpPorta); if fsUsarStream then begin if IsTXTFilePort and FileExists(NomeArq) then CreateModeFlag := fmOpenReadWrite else CreateModeFlag := fmCreate; CreateModeFlag := CreateModeFlag or fmShareDenyWrite; // Tentando abrir o arquivo fsFileStream := TFileStream.Create(NomeArq, CreateModeFlag); fsFileStream.Seek(0, soEnd); // vai para EOF end else begin AssignFile(fsArqPrn, NomeArq); if IsTXTFilePort and FileExists(NomeArq) then Append(fsArqPrn) else Rewrite(fsArqPrn); =====> nessa linha dá o erro ao tentar ativar novamente. end; end; Não sei o que pode estar ocorrendo, agora nem os formulários que estão somente com o Rewrite funcionam. Passei todos os formulários de impressão para o PosPrinter mas ao ativar e desativar e ativar novamente dá esse problema do erro 103. Tentei usar o controle da porta mas o erro persiste. Interessante é, que se eu utilizar como USB:Tanca ou RAW:TANCA TP-650, local, o erro não acontece de forma nenhuma. Se a impressora compartilhada for detectada de forma local como RAW (caso da NPI0DE3D) o erro também não acontece. Posso desativar, mudar opções, ativar e imprimir que o erro não acontece nesse caso. Será que alguma mudança no ACBrDevice fez isso? Antes não havia necessidade de utilizar ACBrDeviceSerial e agora tenho que utilizar senão dá alguns erros na compilação. Tenho uma máquina com uma versão anterior do trunk2 com o ACBrDevice sem a presença do ACBrDeviceSerial e lá, o erro não acontece em nenhuma das simulações que fiz. Alguém tem alguma ideia do que pode estar ocorrendo ? Obrigado.
  11. Boa tarde estimado, Neste link tem um apanhado geral/mapeado de códigos de erro e de não atendimento das solicitações da NFe/NFCe: https://www.oobj.com.br/bc/article/erros-e-rejeições-na-emissão-de-nfe-e-nfce-mapeados-no-oobj-dfe-453.html No mais, todo resto se encontra em: http://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=tW+YMyk/50s= Espero que ajude, Até mais
  12. Boa tarde estimados, Para as empresas do simples, quando meu csosn = csosn500 eu preencho os campos com estes valores abaixo pICMSST := 0 ; vBCST := 0 ; vICMSST := 0 ; vBCSTRet := 0 ; pST := 0 ; vICMSSubstituto := 0.0001 ; vICMSSTRet := 0.0001 ; Ainda estou analisando o impacto, mas fiz isso e está validando sem nenhum problema. Verifique se resolve. Abraço.
  13. Estimados, bom dia! Estou com o mesmo problema, só que com a CPFL.
  14. Aloísio, Boa noite. O DANFE é apenas um DOCUMENTO AUXILIAR DA NOTA ELETRÔNICA e não possui validade fiscal, serve apenas pra acompanhar os itens durante o transporte, porém, há determinações na legislação que devem ser cumpridas. Depois de atendidas a legislação acerca das informações obrigatórias a serem observadas na DANFE, SIM, seu cliente poderia fazer uma propagandinha, como fez o fornecedor aí. O DANFE pode ser impresso em 'qualquer tipo' de papel, folhas soltas ou PRÉ-IMPRESSOS, do A4 (legislação e também tem largura mínima a observar) até o ofício 2 e por qualquer tipo de impressora desde que esta reproduza com fidelidade o código de barras obrigatório a ser impresso. Só não pode ser impresso em papel JORNAL, mesmo que o tamanho seja o previsto. Neste caso aí o fornecedor deve ter usado um pré-impresso talvez do tamanho ofício 2, pois sobraria justamente o espaço daquele rodapé abaixo, e veja, nas laterais, que está sobrando um pouco justamente porque o ofício 2 é 230 (maior que os 210 do A4). No caso, seu cliente poderia utilizar o WORD, por exemplo, e criar um formulário ofício 2 sinalizando um RODAPÉ, como deve ter feito o fornecedor dele. Não se vê muito essa prática por aí mas é uma boa, eu mesmo só concluí depois de ler novamente a legislação da DANFE e suas possibilidades.
×
×
  • Create New...