Possibilidade de enviar diversas informações no body de um email, multi-lingua. Teria que haver forma de disponibilizar por lingua um conjunto de informações para seguirem n obody de um email, eventualmente usando variáveis sobre valores que possam estar no outData de uma impressão por exemplo. ideia proposta pela JMR através dos tickets 20013315 e 20013396.
Status: Open
Criação de um report onde se pudesse executar um método, passando os parâmetros, necessários e se pudesse visualizar o retorno.
O objetivo seria se conseguir testar os métodos de forma mais simples.
Na apresentação de mensagens de erro ou alert no sistema (PC ou PDT) que indiquem o nº da UDT, apresentar antes o código do tipo de UDT, por exemplo 14- 0100306547.
Desta forma, os próprios clientes conseguem perceber qual é o tipo UDT/UDT que está a impedir avançar com determinado processo.
Ex.: ao tentar terminar a carga com um contentor que ainda está numa UDT de Info Etiqueta, o sistema dá mensagem de erro mas apenas apresenta o nº de UDT, e a ISR consegue consultar por SQL mas os clientes terão de procurar em todos os tipos de UDT.
Com a criação de novos layouts de impressão, surge a necessidade de poder determinar esses novos layouts de impressão.
Facilidade em determinar a impressão por determinados atributos como poe exemplo: Armazem, Estab. Destinatário,Terceiro destinatário,Empresa por conta
Sem ter de obrigrar o cliente a usar tipos de documentos diferentes, com o objectivo de poder deinir o conjunto de layouts pretendidos.
No AI003 hoje temos a possibilidade de listar um documento para verificar se cada linha está respondida ou não, em termos de interface. Mas para os clientes e a nível de suporte, seria útil conseguir listar que pedidos têm pelo menos uma linha por responder/fechar. Dependendo do negócio e do âmbito da pesquisa feita, isto poderá exigir a leitura de muitas linhas de pedido para verificar se existem linhas por responder. A minha sugestão, se possível, é que na criação de um pedido, as linhas deste sejam adicionadas a uma tabela que registe linhas por responder; depois ao longo do processo, à medida que uma linha ficasse respondida (porque foi faturada, anulada, um zero fechado, etc.) esta seria removida dessa tabela. Em última instância um pedido totalmente respondido já não teria linhas nesta nova tabela.
Assim, em conjugação com os filtros que decidirmos disponibilizar, a leitura desta tabela poderia ser bem menor e mais rápida, e permitiria a nível de consultas, listar pedidos com linhas por responder e ao clicar no mesmo verificar todo o detalhe (que poderia ser o que se consulta hoje a nível do AI003).
Ter a possibilidade de abrir um tile, atraves de pontos de referência, por exemplo ter um gráfico de barras com 3 barras, ao clicar na segunda barra, abrir o report com o filtro feito, idêntico ao que é feito no filtro de valor.
Ter a possibilidade de usar modificações locais para se fazer patchs com a configuração e assim passar da máquina de qualidade para produção.
Ter a capacidade de definir condições para o envio de email. Por exemplo no ID006, poder dizer que o envio de mail deve ocorrer se existirem contentores com menos de 5 dias de validade.
Mas este é só um exemplo. Outro seria enviar um email se um fornecedor entregar uma ordem de compra abaixo dos 50% de serviço.
Na GY sugerira: no AL118 ter a possibilidade de apresentar apenas as Udt’s configuradas para o armazém escolhido
Avaliar a possibilidade de alterar o AL102 para ter a funcionalidade dos registos em data, tendo em consideração o impacto de colocar esta alteração nalguns clientes, devido ao elevado nº de registos e alterações que fazem nos mesmos, o que pode provocar um aumento grande na tabela.
Ver na imagem exemplo da funcionalidade, que existe no caso do AD014.