Na minha opinião é urgente dotar o WPMS desta funionalidade, pois o ganho de produtividade é muito grande quando comparado com a situação de hoje.
Actualmente temos duas situações que consomem tempo precioso nos nossos clientes quando fazem leitura de códigos de barras no PDT
A. Quando temos uma leitura de um código de barras num processo em PDT, hoje obrigamos que o operador carregue no botão confirmar no ecrã ou no TAB e ENTER para mudar o fócus e accionat o botão. Quando estamos a contar segundos isto é terrível.
Ainha sugestão neste caso é que a leitura de código de barras neste casos onde só existe uma leitura, seja sempre o ultimo campo de input do ecrã e após a leitura o sistema faça enter automático.
B. Quando o ecrã obriga à recolha de duas ou mais informações diferentes com leitura de código de barras (por exemplo ean do artigo e código de barras do espaço) ou com é necessário ler N coisas do mesmo tipo, como é o caso da carga onde é necssário ler de seguida n etiquetas de paletes.
Aqui o sistema deveria ou saltar com o TAB automático para o próximo campo de input, caso o numero de input esteja pré-definido ou fazer ENTER automático para gravar uma informação e pedir a próxima.
Para as situações A e B descritas acima acho que não podemos confirmar na configuração actualmente existente nas pistolas porque são válidas para toda a aplicação e encontrar forma de gerir isso dentro das definições dos reports do WPMS. O ideal era poder definir na definição das colunas dos reports de RF, se era um campo que permitisse a recolha via scanning, e se no fim da leitua deviamos accionar um TAB automático ou um ENTER automático.
(by Vitor Dias)
2 replies on “Leitura sequencial de códigos de barras”
Avaliação:
“Estou de acordo que não é possível utilizar a configuração existente.
Sugiro a escolha de uma ação e a preparação de uma função de visualização especifica para poder avaliar o sucesso tecnico e a satisfação na operação.”
Só para lembrar quem vai analisar esta ideia o tamanho do desafio …
Nos pdt a leitura de código de barras é feita por imager ou scanner e interpretada por um programa chamado scanbadge – ou equivalente – que transforma as barrinhas pretas e brancas em “input teclado”.
“Input teclado” significa – na pratica – fazer de conta que estamos a escrever com o teclado.
Assumimos por um momento que sabemos que o campo de input onde estamos pode ser preenchido com a leitura de um código de barras: depois quantos caracteres passamos ao campo seguinte? É que de facto não temos nada que nós permita saber que o scanbadge (ou o utilizador se está a introduzir a mão) acabou de enviar os números.
A não ser que pedimos ao próprio scanbadge de adicionar no fim alguma coisa (como fazemos para o 128UCC) para nós permitir saber que chegamos ao fim … passa ao próximo …
A pergunta lógica agora seria: e porque então não adicionar diretamente um TAB? Assim sem fazer nada o focus muda. Simples: porque até agora em alguns casos dava jeito passar ao campo seguinte e noutros não.
Talvez a solução passara para um mix: um carácter invisível que podemos ignorar normalmente a não ser que haja javascript – hoje já se pode usar mais até nos pdt – que de acordo com definições ou regras decide ou que fazer.