IsRetail - Solutions for Retail BusinessApesar de termos vivido 18 anos sem isto penso que também é altura para fazermos algo de modo que os dias da semana sejam sempre ordenados pela ordem certa independentemente da descrição. Uma solução é acrescentar um campo à tabela que sirva de ordenação, de forma a que apareça sempre 2ª 3ª 4ª 5ª 6ª Sab, e Dom.
(by Vitor Dias)
Ter um report ou vários reports dentro ou fora do wms que nos indiquem por exemplo:
– Espaço em disco do servidor/servidores WPMS daquela instalação
– Consumo de memoria
– Estado da base de dados (memoria, espaço, etc) (por exemplo aproveitar a informação do script mysqltuner), Acesso directo ao log de erro da base de dados, etc.
– Outros parametros configuraveis (nº mensagens em erro, logins feitos no dia, impressões em erro, etc.)
Este report poderia ser possivel criar alertas de email
em tempos utilizamos uma ferramenta externa, o cacti, mas com a nova versão de php 5.5 e o novo sistema operativo centos deixou de funcionar com problemas de compilação e de acesso remoto.
(by Serafim Folha)
Integrar o local source das Traduções (MF11) no standard.
(by Vitor Dias)
Um dos problemas com que nos defrontamos regularmente é encontrar a D0198 desalinhada com a D0195.
A lógica de que no próximo movimento fazemos o alinhamento obriga-nos a usar um utilitário que está espalhado por praticamente para forçarmos esse alinhamento.
Aqui ou descobrimos as situações que provocam este desalinhamento (caminho complicado acho eu) ou introduzirmos um mecanismo que se possa agendar para regularmente garantir o alinhamento das duas tabelas.
Isto é fundamental porque na colunicação de stocks entre o WPMS e os ERPs usamos a D0198, que em muitas situações está errada, porque o valor diverge da D0195 que está certa.
(by Vitor Dias)
Com o novo módulo de transportes verifica-se que a tabela D0179 não é suficiente para ligar carros a reservas. Poderíamos mudar o campo garitta_prenota para a tabela D0178, e assim ficávamos com o cabeçalho do registo de portaria na D0179 e no detalhe as reservas a que o mesmo estava ligado.
(by Pedro Bras)
Na sequência dos diversos problemas que temos tido sobre determinação de filas e prioridades, em que ficamos com trabalhos em erro pois existem dependências de trabalhos e prioridades, gostaria de apresentar uma idéia, para vossa análise e quem sabe ser introduzida no vosso catálogo de melhorias.
Se a aplicação necessita de ter vários trabalhos a correr forçosamente na mesma fila, e com determinadas prioridades, como é caso da faturação, onde dizem que os seguintes trabalhos têm dependências (print do Pedro Brás do ticket 20007165):
Se é requisito da aplicação, porquê deixar na mão de utilizadores (mesmo que de IT) esse ónus de configuração que depois pode provocar erros?
Proposta: em vez da determinação ser por objeto método, apenas deveríamos determinar um pacote, do género “Pacote de faturação” para o pacote de faturação deste grupo de utilizadores ou deste armazém, ou deste armazém/equipa (Vários acesso) vou configurar o pacote de jobs “faturação”. Ou seja, para o armazém 5407 o pacote de faturação vai correr na fila “5407 – Só Fact”.
Por sua vez, de forma técnica, o sistema sabe que o “pacote de faturação” é constituído por um conjunto de objetos/métodos (os tais do pront acima) e esses sim tem dependência de correr entre eles, mas essa dependência era determinada de forma técnica por vós, sem o cliente, por configuração poder alterar isso. Assim, garantia-se que a ordem dos trabalhos não fica dependente de configuraçãoe corre conforme o sistema necessita.
Nos pequenos clientes temos por vezes erros de trabalhos/processos que não fazem sentido, por causa do serviço associado estar em cima à muito tempo.
Acontece por exemplo ele perder acesso aos numeradores, as mensagens ficam sem saida, etc.
A ideia seria ter um parametro de sistema para activar o restart automático dos serviços e que hora poderia ser feito.
Como temos para o SR005 para as mensagens, ter uma opção de mensagens locais que seria utilizada para localsources e assim evitar erros de encoding das páginas/ambientes.
Criar uma base de conhecimento de utilitários feitos pela equipa da ISRETAIL em sistema interno.
Objectivo do utilitário
Quem Fez
Data
Ticket Associado se existir
Para que ambiente
Se houver alterações registar ou criar novo utilitário. Poderia ser vantajoso termos acesso ao histórico do source do utilitários no caso de existir alterações (algo semelhante a um software controle de versões).
Depois conseguir criar bundle de utilitário e levar para clientes (IG019 ou por mc)
O que escrevemos hoje no momento da consolidação dos metodos não são bem release notes mas mais um log das alterações e do porque das mesmas.
Para ajudar quem cria verdadeiramente as release notes podiamos criar um report com possibilidade de:
1) alterar o titulo das modificações
2) escrever 2 textos (EN e PT) com a ajuda do:
3) texto principal do ticket ligado se existe
4) texto das alterações feitas
Os textos podiam ser revistos antes de qualquer publicação(?)
