Board: Ideas Box

Exportação dos dados visíveis num report

De momento conseguem-se exportar os dados de um report quer em pdf quer em excel. No entanto, como já foi reparado várias vezes, tanto pelos clientes como internamente, esta exportação devolve todos os dados vindos do servidor, filtrados somente pelos parâmetros de selecção do report, não tendo em conta os filtros extra aplicados nas colunas.

A ideia seria possibilitar exportar os dados que estão visíveis no report, tanto filtrados pelos parâmetros como pelas colunas. Para tal, alteraria-se a lógica actual de modo a aplicar os filtros das colunas nos resultados obtidos do servidor.

Deste modo, os dados obtidos na exportação iriam reflectir os dados tal e qual como são apresentados no report, não fazendo distinção entre dados filtrados pelos parâmetros de selecção e aqueles filtrados pelas colunas, tratando ambos os filtros como fazendo parte do sistema total de filtragem que providenciam os dados visíveis num report.
Passaria, portanto, a ser uma exportação dos dados visíveis no momento, estando ambos alinhados.

EVE – Funcionalidade de Restaurar Local Sources IG031

Criar uma nova ferramenta em EVE que permite-se restaurar (Exportar/Importar), todos os pontos de chamada do IG031 de um ambiente para outro ou até no próprio ambiente em caso de restauro da base dados.

Exportar definição da tabela para o nosso formato

Adicionar uma nova ação no SD002, para que seja possível exportar um .xlsx com a definição da tabela, mas com a estrutura que a nossa aplicação precisa para ser utilizada na importação (ID003, AI017)

Melhorar o sistema de pontuação dos filtros do EVE

Idea com origem na JM

Por cada report, são guardadas as execuções, re-execuções, as linhas devolvidas e o tempo necessário.

Com estes dados é actualizada uma pontuação que determina qual será o filtro automático.

Estudar formas de poder interferir no calculo do score para deixar nas mãos de quem parametriza o sistema maior controle.

Algumas ideias: excluir filtros que precisaram mais de x segundos, só considerar um filtro interessante depois de x re-execuções, …

Gerador de código php para métodos de leitura, de modo a automatizar as validações necessárias dos campos do ecrã de validação do Report.

De momento, sempre que se faz um método de leitura é necessário validar se os valores inseridos pelo utilizador, no ecrã de validação, estão correctos.

Para desenvolver estas validações o programador têm que escrever manualmente condições que diferem do tipo de campo do ecrã de validação,

A ideia seria, para Reports standard, haver um gerador de código php (um botão no SO018) que gera código com as condições necessárias para cada campo do ecrã de validação, a partir dos parâmetros de entrada.

Assim, é poupado tempo na criação de métodos de leitura para Reports Standard, ao mesmo tempo que a sua consistência se mantêm.

Quem executou um pedido?

Há clientes – Angelo da Staples – interessados em saber quem executou um pedido e a referencia ao documento recebido via interface.

Evidentemente não é assim tão linear já que um pedido pode ter vários intervenientes: pickers, execução de contentores completos, vitafilmadores, conferentes, quem carregou, …

Se esta ideia será julgada merecedora: a parte expositiva terá que ser bem pensada para manter uma boa leitura

Simulação envio da mensagem DOC para a AT

PAra efeitos de debug deveriamos ter um simuador para envio da mensagem ou algo mais prático, o request para a AT quando ficasse em erro ser escrito numa tabela.
Perde-se muito tempo a ver o que poderá ser o erro, e muitas vezes não podemos ligar o Debug nos clientes

Yard Management

Esta ideia vem de algumas conversas que tivemos quando o Yard Management começou a ser discutido com a Jerónimo Martins e, basicamente seria criar um layout como agora fazemos para o armazém, mas neste caso seria para o exterior do armazém. Neste momento salvo erro já é possível por exemplo ter um código das portas diferentes, para a rua e para o armazém. Com um layout exterior, poderíamos ver os Camiões e Galeras como são vistos os contentores dentro de um armazém, ou seja, para os veículos seria possível criar regras de extração e de alocação, assim como poderíamos criar uma tabela parecida com a D0204 mas para veículos. Aqui existe a possibilidade de usar IA visto que em vez de usar regras especificas, podemos usar o IA para saber onde alocar o veículo e ainda qual veículo deverá ser chamado para ser carregado.

Aqui ainda poderíamos também criar um log de manutenção por veículo que diria quando foi feita a última manutenção, a última lavagem etc… talvez algo semelhante aos serviços logísticos, mas para veículos sendo assim possível os utilizadores decidirem quais os serviços que serão necessários fazer algum rastreio.

Melhoria no report wizard

De momento, no report wizard, quando se entra no report para tratar das colunas do report que se está a criar, bem como no report para tratar dos parâmetros, e se seguir em frente sem guardar nesses ecrãs, no fim o report não vai ter as descrições de default como acontece por default no SR003 quando se adiciona um parâmetro ou uma coluna a um report.

Para solucionar essa situação, bem como para ficar a par do SR003 e evitar ocorrer o erro de não ter descrições por não guardar por lapso ou desconhecimento da mecânica, sugiro adicionar à acção ASYREP0142 o objecto FSYREP01 e o método updateColDesc e à acção ASYREP0145 o objecto FSYREP01 e método updateParDesc. Deste modo, se não se precisar de alterar as colunas e os parâmetros, pode-se seguir em frente sem se preocupar com a falta de descrições, sendo também mais user friendly.

Repositório de bugs

Por vezes, quando se desenvolve ou se pesquisa algo nos métodos ou reports, deparamo-nos com bugs, tanto de funcionalidade ou descrição.

Para não se estar a corrigir esses bugs e ligar a uma modificação de um desenvolvimento que não está relacionado, ou mesmo criar ticket e modificação nova para algo que possa ser mínimo, e de modo a não os perder no tempo, sugiro que se crie um repositório, talvez sobre a forma de uma nova tabela com report associado, só disponível para nós, onde se poderia adicionar esses bugs encontrados de modo a que de futuro, quem vai editar métodos/elementos, consiga saber que existe um ou mais bugs que foram previamente detectados, através de um pequeno indicador no SO018 e nos reports para o caso de elementos do mesmo. Assim, para além de alterar/corrigir o que tem de fazer, também se aproveitava para corrigir quaisquer bugs registados. Ao corrigir, bastaria eliminar da lista ou marcado como resolvido e quando.