Actualmente quando agendamentos os trabalhos que retratam mensagens de interface em erro temos um efeitos negativo, que é o facto do trabalho de agendamento fica em erro se não houver mensagens para tratar. Isto não faz sentido criando o rastro de trabalhos em erro que não deveriam existior porque não se trata de um erro. É aliás algo de muito positivo.
Status: Declined
Em vez de estarmos a definir na altura da sua criação no SR005 se a mensagem é de erro, informação , confirmação, etc, ter mais um parametro adicional no send_msg que passava que tipo de mensagem é que gostariamos de ter. Dava mais liberdade ao programador.
Por um lado evitava-se em ter mensagens com o mesmo texto mas apenas muda o tipo.
(by Serafim Folha)
Poderia ser interessante e ajudar na investigação de alguns problemas ter no campo data de criação de algumas tabelas como por exemplo a:
D0273 (unidades de trabalho)
D0359 (volumes)
Este campo era apenas preenchido na altura da criação do registo na tabela.
Poderia ser feito em conjunto com uma ideia já antiga de o std_datamod não ser mexido com a estatistica. Haveria ganhos na investigação de casos mais “estranhos”.
(by Serafim Folha)
Redesenhar o report de live upgarde de modo a apresentar a informação com leitura e que se perceba o que é que cada patch efetivamente contém, uma vez que actualmente em termos de experiência do utilizador é muito má.
Adicionalmente criar a possibilidade de seleccionar diversos patchs ao mesmo tempo e fazer com que o sistema proceda a sua respectiva instalação. Aqui até fará sentido ter a possibilidade de fazer isto em processo background e assim libertar o ecrã ou em processo como hoje onde vamos ter uma actulização online da evolução da instalação.
A barra de progresso terá também que ser revista, aproveitando as linhas de orientação que a equipa que está a tratar da próxima versão está a usar.
(by Vitor Dias)
Em alguns clientes quando existe pouco movimento no WPMS na saida de mensagens por exemplo, verifica-se que o serviço de saida está activo, mas fica com as mensagens em saida.
Se fizermos restart aos serviços é enviada com sucesso.
Podia-se fazer tambem um mecanismo de restart aos serviços para além de X em X trabalhos, uma outra opção de fazer restart aos serviços de X em X dias/horas.
(by Serafim Folha)
Por muitas vezes no IG019 (MF01 – Traduções das Tabelas Descrições Técnicas para Polaco), especificas frases completas aparecem repetidas (nas accoes, nos reportes, nas mensagens, etc.).
A minha ideia passaria por guardar todas as minhas (utilizador: isr-awozniak) traducoes diferentes numa tabela temporaria para ficar registado, para quando utilitario for correr, comparar se ja existe esta traducao na tabela temporaria e puderar aplicar traducao automaticamente. Tendo em conta codificacao em polaco. Assim evitaria traduzir a mesma coisa outra/quinta vez.
(by Anna Monika Wozniak)
Apresentar a estimativa do número de paletes completas e das paletes não completas à semelhança do que se fez com as UMAs.
Aumentar a informação presente no ecrã do AL062 de modo a se poder fazer uma primeira análise ao resultado do plano de transportes
(by Denise Mendez)
Passar a selecção multipla e poder ver as release notes
Hoje os testes são definidos a nível de objecto/metodo e não parece ser a melhor solução.
A ideia é passar a definição dos testes a nível de modificação:
1) quando se abre uma nova modificação já se poderiam definir alguns testes (que deveriam estar descritos nos tickets)
2) quando se altera o estado do metodo para “em teste” apareceria a lista de testes da modificação para verificar que está tudo
3) possibilidade de definir o teste para uma outra modificação que fica automaticamente ligada
4) decidir se é necessario intervir também na geração das vistas e na adicção de ficheiros à modificação