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.
Status: Open
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.
Tomando como exemplo um artigo que seja gerido à CX/UN, ao aceder ao AL164, o 1º ecrã apresenta apenas os dados na UM base de stock (UN na Qt e Qt2), o que se pode tornar confuso e trabalhoso para os clientes, por obrigar a fazer conversões.
Avaliar a possibilidade de apresentar convertido nas 2 UM do artigo, como é o caso dos reports AL437 e AL438, ou seja, ao invés de UN/UN, CX/UN (no caso dos artigos geridos desta forma).
Sugiro que seja alterada a funcionalidade de report de tarefas nos tickets, de forma a colocar a data/hora de fim da tarefa, ao inves da duração da tarefa (nem sempre existe a duração que se pretende e é preciso andar a fazer mais do que um registo para a mesma tarefa. (Ex.: 7h + 15m; 8h + 30m)
Quando os clientes pretendem reabrir um ticket porque o assunto ainda não está resolvido ou pretendem obter mais informação, apenas têm um campo de input simples. Proponho que sejam disponibilizados neste ecrã os restantes elementos de edição de texto e submissão de imagens / ficheiros, de forma a que o cliente apenas tenha de submeter uma nota quando precisa de reabrir um ticket (o que acontece hoje em dia é submeterem por ex uma nota a indicar “Temos mais casos. Ver nota seguinte”, e depois de reaberto o ticket é que expõem os casos e adicionam ficheiros.