Quando produzimos um ficheiro csv para comunicação de mensagens, é utilizado ‘\”‘ para escape das aspas.
David Rodrigues da Logifrio, justamente, sublinha que o formato coreto seria “””.
Evidentemente não podemos alterar o existente sem dar a oportunidade, a quem já utiliza, de continuar no formato atual. Por isto seria oportuno adicionar um parâmetro de sistema que permita escolher o formato de escape pretendido.
Board: Ideas Box
Dou a CLOD como exemplo, mas imagino que aconteça noutros clientes, quando anulamos um contentor de expedição, o stock fica bloqueado, o que será necessário ir ao AL046, desbloqueá-lo. Não seria interessante, a própria ação fazer isso automaticamente?
Ticket onde aconteceu: #20020411 e #20020424
Report que recebe o inicio uma serie de reports, à semelhança do report wizard, e utiliza esse input para verificar a ultima serie utilizada, olhando para os reports, ações e menus. No fim, diz ao técnico qual serie a usar, na medida em que encontra a mais alta que existe, incrementa a 10 e devolve ao técnico como mensagem de erro.
Como bonus, poderia haver um botão ao lado que mostra todos os códigos breves e mostra também o mais alto + 1.
Esta ideia não originalmente minha, mas acho que não tem sentido o temporizador SLA do nosso portal dos tickets incrementar quando está do lado do cliente, até porque alguns deles demoram imenso a responder, apesar de pressão do nosso lado. Presumo que o nosso portal dos tickets, tenha forma de fazer isso.
Visto que agora já temos a funcionar uma API que se liga diretamente ao nosso sistema de tickets, acho que faria sentido adicionar uma campo na altura de consolidar um método, onde debaixo da nota técnica se pode colocar o nº do ticket que levou a que a alteração fosse feita, permitindo uma analise mais rápida no caso de se encontrar uma alteração que levou a algum problema, ou que o técnico não perceba o porquê de lá estar. Se não me falha a memória, as release notes e notas técnicas estão todas numa tabela em formato JSON, por isso não vejo mal a colocar lá mais uma chave que incluí o número do ticket.
Na criação de vistas o nome do campo do elemento, deveria ter o nome do campo na tabela+traduções. Pois leva a enganos… Sendo necessário abrir o SD002 para confirmar a descrição do campo.
Como é apresentado o elemento : “Linha ligada”, Linha execução
Como sugerido a apresentação do elemento: “Ord_legato_riga – Linha ligada”, Riga_prelievo – Linha execução
Visto que a Zolve está constantemente a abrir tickets para a instalação ou alteração de impressoras no CUPS, acho que faria sentido criar uma transação local, parecida com o IP001 onde se possa fazer as modificações ou instalações pretendidas. Estas alterações ficariam logo feitas em ambas as maquinas e talvez o cliente também poderia começar fazer estas alterações sozinho se viesse de dentro da aplicação.
vista de um armazem em 2D (num dashboard por exemplo) em que permita ver onde se encontra um operador, histórico de visita de um espaço num intervalo de tempo (para análise de ver se um determinado corredor é mais visitado p.e.). Mais possibilidades de informação relevante
No interface todas as mensagens de saída criadas, pelos utilizadores de um determinado grupo, conseguir que as mesmas ficassem Retidas. De modo a que o utilizador consiga efetuar a respetiva validação e Tratamento Manual caso o assim entenda.
Tendo em conta que as tabelas de descrição são sempre feitas da mesma maneira, até já havendo uma tabela dummy para fazer a copia, acho que faria sentido existir, no SD002, um pisco que permite criar de forma automática a tabela de descrição, utilizando as chaves definidas na tabela principal.
Outra coisa que se cria com alguma regularidade, são vistas que apenas ligam as tabelas principais com as de descrição, que também são sempre feitas da mesma forma, acho que também se poderia automatizar o processo inserindo as definições das colunas, wheres, joins etc. de forma automática.
