IsRetailTicket 20013701 aberto pelo cliente.
Como podemos agora encontrar quem e que processo adicionou esta quantidade de at´s neste contentor?
Podem ajudar-me com esta descoberta? Tentei o diário de contentores mas, os AT´s não ficam lá registados.
Temos alguma transação para ver esta informação? Se sim, qual? Se query, qual usam?
Se esta informação não está disponível via reports/transações aplicacionais, não acham interessante que a mesma esteja? Eventual melhoria para a vossa lista de melhorias?
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.
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